Bug 1951971
| Summary: | [RFE] Bonding: add option ns_ipv6_target | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Hangbin Liu <haliu> |
| Component: | kernel | Assignee: | Jonathan Toppins <jtoppins> |
| kernel sub component: | Bonding | QA Contact: | LiLiang <liali> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | high | CC: | jarod, jtoppins, mschmidt, network-qe |
| Version: | 9.0 | Keywords: | FutureFeature, Triaged |
| Target Milestone: | beta | Flags: | pm-rhel:
mirror+
|
| Target Release: | 9.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-5.14.0-104.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 10:50:23 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1951910, 2068988 | ||
|
Description
Hangbin Liu
2021-04-21 09:01:38 UTC
Not yet implemented in 9-Beta. Hi Jonathan, Assign this bug to you. Here are the kernel commits 696c65444120 ipv6: separate ndisc_ns_create() from ndisc_send_ns() 1fcd5d448c59 Bonding: split bond_handle_vlan from bond_arp_send 841e95641e4c bonding: add extra field for bond_opt_value 4e24be018eb9 bonding: add new parameter ns_targets 129e3c1bab24 bonding: add new option ns_ip6_target Please help review if anything needs to be updated. e.g. Do we need to add correspond arp_validate, arp_interval options for IPv6 NS? Thanks Hangbin Is the kernel mentioned by comment #4 available? I can't find ns_ipv6_target under /sys/class/net/bond0/bonding using this kernel. (In reply to LiLiang from comment #5) > Is the kernel mentioned by comment #4 available? > I can't find ns_ipv6_target under /sys/class/net/bond0/bonding using this > kernel. The newly added bond options only support netlink config. Please use the latest iproute2 for testing. (In reply to LiLiang from comment #5) > Is the kernel mentioned by comment #4 available? > I can't find ns_ipv6_target under /sys/class/net/bond0/bonding using this > kernel. Going forward any new bonding options will be netlink only. This in general will be the case for the majority of network options across all network devices. QE will need to switch to testing with netlink as the primary configuration method and treat legacy methods like sysfs and module options as secondary methods. This bz depends on bz #2068988, without new iproute2, I can't test this bz. Waiting... (In reply to LiLiang from comment #8) > This bz depends on bz #2068988, without new iproute2, I can't test this bz. > Waiting... You can download upstream iproute2[1] and build it yourself.... [1] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git Thanks Hangbin. ns_ip6_target works on this MR kernel, but I also found some problems. 1. can't set ipv6 link local address as ns_ip6_target [root@dell-per730-02 ~]# ip link add name bond0 type bond mode 1 ns_ip6_target fe80::1e1b:dff:fe9f:6802 arp_validate 3 arp_interval 1000 Error: Invalid IPv6 addr6. 2. The actual ns_ip6 packets sending interval is 2*arp_interval e.g. when arp_interval is 1000, the actual sending interval is 2000 # ip link add name bond0 type bond mode 1 ns_ip6_target 2001:11:11::1 arp_interval 1000 # ip link set enp5s0f0 master bond0 # ip link set enp5s0f1 master bond0 [root@dell-per730-02 ~]# tcpdump -i enp5s0f0 -Q out icmp6 -enn dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp5s0f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 04:10:34.870263 a0:36:9f:f5:b1:18 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:11:11::1, length 24 04:10:36.918262 a0:36:9f:f5:b1:18 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:11:11::1, length 24 04:10:38.966273 a0:36:9f:f5:b1:18 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:11:11::1, length 24 04:10:41.014262 a0:36:9f:f5:b1:18 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:11:11::1, length 24 3. Can't see current ns_ip6_target setting from "cat /proc/net/bond0/bonding" [root@dell-per730-02 ~]# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v5.14.0-98.mr905_220524_1244.el9.x86_64 Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: None MII Status: down MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Peer Notification Delay (ms): 0 ARP Polling Interval (ms): 1000 ARP Missed Max: 2 ARP IP target/s (n.n.n.n form): Slave Interface: enp5s0f0 MII Status: going down Speed: 10000 Mbps Duplex: full Link Failure Count: 3 Permanent HW addr: a0:36:9f:f5:b1:18 Slave queue ID: 0 Slave Interface: enp5s0f1 MII Status: going back Speed: 10000 Mbps Duplex: full Link Failure Count: 2 Permanent HW addr: a0:36:9f:f5:b1:19 Slave queue ID: 0 (In reply to LiLiang from comment #10) > 1. can't set ipv6 link local address as ns_ip6_target expected behavior according to the code. > 2. The actual ns_ip6 packets sending interval is 2*arp_interval > e.g. when arp_interval is 1000, the actual sending interval is 2000 controlled by arp_interval infrastructure > 3. Can't see current ns_ip6_target setting from "cat /proc/net/bond0/bonding" This probably should be added, can be done later as it is not technically a bug as the list can be obtained via netlink. This is just a completeness thing. (In reply to Jonathan Toppins from comment #11) > (In reply to LiLiang from comment #10) > > 1. can't set ipv6 link local address as ns_ip6_target > > expected behavior according to the code. > > > 2. The actual ns_ip6 packets sending interval is 2*arp_interval > > e.g. when arp_interval is 1000, the actual sending interval is 2000 > > controlled by arp_interval infrastructure But ip4 arp packets sending interval is correct. > > > 3. Can't see current ns_ip6_target setting from "cat /proc/net/bond0/bonding" > > This probably should be added, can be done later as it is not technically a > bug as the list can be obtained via netlink. This is just a completeness > thing. (In reply to Jonathan Toppins from comment #11) > (In reply to LiLiang from comment #10) > > 1. can't set ipv6 link local address as ns_ip6_target > > expected behavior according to the code. > > > 2. The actual ns_ip6 packets sending interval is 2*arp_interval > > e.g. when arp_interval is 1000, the actual sending interval is 2000 > > controlled by arp_interval infrastructure If bond interface doesn't have ipv6 address, then the ns_ip6 sending interval is 2*arp_intreval. If bond interface have ipv6 address, then the ns_ip6 sending interval is normal. Anyway, I don't think this is a problem. (In reply to LiLiang from comment #13) > (In reply to Jonathan Toppins from comment #11) > > (In reply to LiLiang from comment #10) > > > 1. can't set ipv6 link local address as ns_ip6_target > > > > expected behavior according to the code. Set lladdr as NS target should be accepted. I will post a fix for that. > > > > > 2. The actual ns_ip6 packets sending interval is 2*arp_interval > > > e.g. when arp_interval is 1000, the actual sending interval is 2000 > > > > controlled by arp_interval infrastructure > > If bond interface doesn't have ipv6 address, then the ns_ip6 sending > interval is 2*arp_intreval. > If bond interface have ipv6 address, then the ns_ip6 sending interval is > normal. > > Anyway, I don't think this is a problem. Interesting. I will check this issue. (In reply to Hangbin Liu from comment #14) > > Interesting. I will check this issue. OK, I checked the issue. Before you set an address on the bond and choose an active slave. The bond will select a slave as new_slave and send arp/ns on that port, which means the ARP/NS is not sent on each slave with every arp interval. If you try "tcpdump -i any -nn -l ip6" you will find that on every arp interval bond will send an ARP/NS packet, but with a different slave. So this behavior is expected. Hangbin, Do we need to reopen this to wait your new patches? Anyway, Regression test passed, the failure is because a case problem, I have fixed it: https://beaker.engineering.redhat.com/recipes/12051200#tasks Current version doesn't support lladdr as ns_ip6_target, and no ns_ip6_target info in cat /proc/net/bond0/bonding. Liang (In reply to LiLiang from comment #16) > Hangbin, > > Do we need to reopen this to wait your new patches? > > Anyway, Regression test passed, the failure is because a case problem, I > have fixed it: https://beaker.engineering.redhat.com/recipes/12051200#tasks > > Current version doesn't support lladdr as ns_ip6_target, and no > ns_ip6_target info in cat /proc/net/bond0/bonding. The iproute2 patch has not been backported yet. And I don't think there has users using this feature now. So either we backport the fixes in this bug or open a new bug works for me. This depends on Jon's choice. Thanks Hangbin Jon, Please see comment#17. (In reply to Hangbin Liu from comment #17) > (In reply to LiLiang from comment #16) > > Hangbin, > > > > Do we need to reopen this to wait your new patches? > > > > Anyway, Regression test passed, the failure is because a case problem, I > > have fixed it: https://beaker.engineering.redhat.com/recipes/12051200#tasks > > > > Current version doesn't support lladdr as ns_ip6_target, and no > > ns_ip6_target info in cat /proc/net/bond0/bonding. > > > The iproute2 patch has not been backported yet. And I don't think there has > users using this feature now. > So either we backport the fixes in this bug or open a new bug works for me. > This depends on Jon's choice. We do not need the fixes immediately. The feature doesn't crash the kernel and the "fixes" really just add additional capability. https://beaker.engineering.redhat.com/recipes/12078202#tasks https://beaker.engineering.redhat.com/recipes/12087170#task145636698 (In reply to Hangbin Liu from comment #17) > (In reply to LiLiang from comment #16) > > Hangbin, > > > > Do we need to reopen this to wait your new patches? > > > > Anyway, Regression test passed, the failure is because a case problem, I > > have fixed it: https://beaker.engineering.redhat.com/recipes/12051200#tasks > > > > Current version doesn't support lladdr as ns_ip6_target, and no > > ns_ip6_target info in cat /proc/net/bond0/bonding. > > > The iproute2 patch has not been backported yet. And I don't think there has > users using this feature now. > So either we backport the fixes in this bug or open a new bug works for me. > This depends on Jon's choice. Do we have bug for this problem? (In reply to LiLiang from comment #24) > > Do we have bug for this problem? Yes, we have - Bug 2068988 - [RFE] iproute backport bond: add ns_ip6_target option (In reply to Hangbin Liu from comment #25) > (In reply to LiLiang from comment #24) > > > > Do we have bug for this problem? > > Yes, we have > - Bug 2068988 - [RFE] iproute backport bond: add ns_ip6_target option with bz2068988 verified iproute, lladdr still can't be used as ns_ip6_target: [root@dell-per730-16 ~]# rpm -q iproute iproute-5.18.0-1.el9.x86_64 [root@dell-per730-16 ~]# ip link add name bond0 type bond mode 1 ns_ip6_target fe80:123:456::789 arp_validate 3 arp_interval 2000 Error: Invalid IPv6 addr6. (In reply to LiLiang from comment #26) > (In reply to Hangbin Liu from comment #25) > > (In reply to LiLiang from comment #24) > > > > > > Do we have bug for this problem? > > > > Yes, we have > > - Bug 2068988 - [RFE] iproute backport bond: add ns_ip6_target option > > with bz2068988 verified iproute, lladdr still can't be used as ns_ip6_target: > > [root@dell-per730-16 ~]# rpm -q iproute > iproute-5.18.0-1.el9.x86_64 > [root@dell-per730-16 ~]# ip link add name bond0 type bond mode 1 > ns_ip6_target fe80:123:456::789 arp_validate 3 arp_interval 2000 > Error: Invalid IPv6 addr6. This is expected, as we haven't backported the fix patches. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: kernel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:8267 |