RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1951971 - [RFE] Bonding: add option ns_ipv6_target
Summary: [RFE] Bonding: add option ns_ipv6_target
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: kernel
Version: 9.0
Hardware: All
OS: Linux
high
medium
Target Milestone: beta
: 9.0
Assignee: Jonathan Toppins
QA Contact: LiLiang
URL:
Whiteboard:
Depends On:
Blocks: 1951910 2068988
TreeView+ depends on / blocked
 
Reported: 2021-04-21 09:01 UTC by Hangbin Liu
Modified: 2022-11-15 12:09 UTC (History)
4 users (show)

Fixed In Version: kernel-5.14.0-104.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-15 10:50:23 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/src/kernel centos-stream-9 merge_requests 905 0 None opened bonding: driver update for 9.1 2022-05-24 12:35:05 UTC
Red Hat Product Errata RHSA-2022:8267 0 None None None 2022-11-15 10:50:45 UTC

Description Hangbin Liu 2021-04-21 09:01:38 UTC 
Description of problem:

As we plan to deprecate teaming on RHEL9 and ask customers to move to bonding.
We need to fix the feature gaps between bonding and teaming. This bug is intend to add teaming feature 'nsna_ping' for bonding.

nsna_ping: it uses IPv6 Neighbor Solicitation / Neighbor Advertisement instead of arp to detect if link should be considered to be up. This is an alternative to arp_ping and becomes handy in pure-IPv6 environments.

There is no user case yet. But it should be useful in future for pure IPv6 environments.
Comment 2 Michal Schmidt 2021-08-31 14:08:24 UTC 
Not yet implemented in 9-Beta.
Comment 3 Hangbin Liu 2022-03-28 03:26:51 UTC 
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
Comment 5 LiLiang 2022-05-25 05:27:31 UTC 
Is the kernel mentioned by comment #4 available?
I can't find ns_ipv6_target under /sys/class/net/bond0/bonding using this kernel.
Comment 6 Hangbin Liu 2022-05-25 07:46:46 UTC 
(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.
Comment 7 Jonathan Toppins 2022-05-25 14:17:19 UTC 
(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.
Comment 8 LiLiang 2022-05-26 00:29:32 UTC 
This bz depends on bz #2068988, without new iproute2, I can't test this bz. Waiting...
Comment 9 Hangbin Liu 2022-05-26 06:37:48 UTC 
(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
Comment 10 LiLiang 2022-05-26 09:13:34 UTC 
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
Comment 11 Jonathan Toppins 2022-05-26 15:04:13 UTC 
(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.
Comment 12 LiLiang 2022-05-26 23:19:55 UTC 
(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.
Comment 13 LiLiang 2022-05-27 03:31:25 UTC 
(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.
Comment 14 Hangbin Liu 2022-05-27 04:41:32 UTC 
(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.
Comment 15 Hangbin Liu 2022-05-27 06:26:13 UTC 
(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.
Comment 16 LiLiang 2022-05-29 00:29:55 UTC 
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
Comment 17 Hangbin Liu 2022-05-30 09:57:22 UTC 
(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
Comment 18 LiLiang 2022-05-31 00:46:40 UTC 
Jon, Please see comment#17.
Comment 19 Jonathan Toppins 2022-06-01 14:47:17 UTC 
(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.
Comment 23 LiLiang 2022-06-04 01:33:09 UTC 
https://beaker.engineering.redhat.com/recipes/12078202#tasks
https://beaker.engineering.redhat.com/recipes/12087170#task145636698
Comment 24 LiLiang 2022-07-18 00:54:51 UTC 
(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?
Comment 25 Hangbin Liu 2022-07-18 09:01:30 UTC 
(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
Comment 26 LiLiang 2022-07-18 09:27:58 UTC 
(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.
Comment 27 Hangbin Liu 2022-07-19 08:00:27 UTC 
(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.
Comment 29 errata-xmlrpc 2022-11-15 10:50:23 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.