bonding: Extend arp_ip_target format to allow for a list of vlan tags.

/sys/class/net/<bond>/bonding/arp_ip_target and /proc/net/bonding/<bond> will display vlan tags if they have been configured by the user

Signed-off-by David Wilder <[email protected]>

---
drivers/net/bonding/bond_procfs.c | 5 ++++-
drivers/net/bonding/bond_sysfs.c | 9 ++++++---

2 files changed, 10 insertions(+), 4 deletions(-)

drivers/net/bonding/bond_procfs.c +4 -1

index 94e6fd7041ee..b07944396912 100644
@@ -111,6 +111,7 @@ static void bond_info_show_master(struct seq_file *seq)
 
 	/* ARP information */
 	if (bond->params.arp_interval > 0) {
+		char pbuf[BOND_OPTION_STRING_MAX_SIZE];
 		int printed = 0;
 
 		seq_printf(seq, "ARP Polling Interval (ms): %d\n",

@@ -125,7 +126,9 @@ static void bond_info_show_master(struct seq_file *seq)
 				break;
 			if (printed)
 				seq_printf(seq, ",");
-			seq_printf(seq, " %pI4", &bond->params.arp_targets[i].target_ip);
+			bond_arp_target_to_string(&bond->params.arp_targets[i],
+						  pbuf, sizeof(pbuf));
+			seq_printf(seq, " %s", pbuf);
 			printed = 1;
 		}
 		seq_printf(seq, "\n");

drivers/net/bonding/bond_sysfs.c +6 -3

index d7c09e0a14dd..870e0d90b77c 100644
@@ -286,13 +286,16 @@ static ssize_t bonding_show_arp_targets(struct device *d,
 					struct device_attribute *attr,
 					char *buf)
 {
+	char pbuf[BOND_OPTION_STRING_MAX_SIZE];
 	struct bonding *bond = to_bond(d);
 	int i, res = 0;
 
 	for (i = 0; i < BOND_MAX_ARP_TARGETS; i++) {
-		if (bond->params.arp_targets[i].target_ip)
-			res += sysfs_emit_at(buf, res, "%pI4 ",
-					     &bond->params.arp_targets[i].target_ip);
+		if (bond->params.arp_targets[i].target_ip) {
+			bond_arp_target_to_string(&bond->params.arp_targets[i],
+						  pbuf, sizeof(pbuf));
+			res += sysfs_emit_at(buf, res, "%s ", pbuf);
+		}
 	}
 	if (res)
 		buf[res-1] = '\n'; /* eat the leftover space */

Signature · 1 line

2.43.5

Quoted 3 lines · David Wilder

/sys/class/net/<bond>/bonding/arp_ip_target and /proc/net/bonding/<bond> will display vlan tags if they have been configured by the user

I don't think we need to do any of this, the sysfs and proc APIs
to bonding should not be updated to support new functionality. Netlink and /sbin/ip must do the right thing, but the other APIs are more or less frozen in the past.

       -J

Quoted 55 lines

Signed-off-by David Wilder <[email protected]>

---
drivers/net/bonding/bond_procfs.c | 5 ++++-
drivers/net/bonding/bond_sysfs.c | 9 ++++++---

2 files changed, 10 insertions(+), 4 deletions(-)

drivers/net/bonding/bond_procfs.c +4 -1

index 94e6fd7041ee..b07944396912 100644
@@ -111,6 +111,7 @@ static void bond_info_show_master(struct seq_file *seq)
 
      /* ARP information */
      if (bond->params.arp_interval > 0) {
+              char pbuf[BOND_OPTION_STRING_MAX_SIZE];
              int printed = 0;
 
              seq_printf(seq, "ARP Polling Interval (ms): %d\n",

@@ -125,7 +126,9 @@ static void bond_info_show_master(struct seq_file *seq)
                              break;
                      if (printed)
                              seq_printf(seq, ",");
-                      seq_printf(seq, " %pI4", &bond->params.arp_targets[i].target_ip);
+                      bond_arp_target_to_string(&bond->params.arp_targets[i],
+                                                pbuf, sizeof(pbuf));
+                      seq_printf(seq, " %s", pbuf);
                      printed = 1;
              }
              seq_printf(seq, "\n");

drivers/net/bonding/bond_sysfs.c +6 -4

index d7c09e0a14dd..870e0d90b77c 100644
@@ -286,13 +286,16 @@ static ssize_t bonding_show_arp_targets(struct device *d,
                                      struct device_attribute *attr,
                                      char *buf)
 {
+      char pbuf[BOND_OPTION_STRING_MAX_SIZE];
      struct bonding *bond = to_bond(d);
      int i, res = 0;
 
      for (i = 0; i < BOND_MAX_ARP_TARGETS; i++) {
-              if (bond->params.arp_targets[i].target_ip)
-                      res += sysfs_emit_at(buf, res, "%pI4 ",
-                                           &bond->params.arp_targets[i].target_ip);
+              if (bond->params.arp_targets[i].target_ip) {
+                      bond_arp_target_to_string(&bond->params.arp_targets[i],
+                                                pbuf, sizeof(pbuf));
+                      res += sysfs_emit_at(buf, res, "%s ", pbuf);
+              }
      }
      if (res)
              buf[res-1] = '\n'; /* eat the leftover space */
--

Quoted 2 lines

2.43.5

---
-Jay Vosburgh, [email protected]

The current implementation of the arp monitor builds a list of vlan-tags by following the chain of net_devices above the bond. See bond_verify_device_path(). Unfortunately, with some configurations, this is not possible. One example is when an ovs switch is configured above the bond.

This change extends the "arp_ip_target" parameter format to allow for a list of vlan tags to be included for each arp target. This new list of tags is optional and may be omitted to preserve the current format and process of discovering vlans.

The new format for arp_ip_target is:
arp_ip_target ipv4-address[vlan-tag\...],...

For example:
arp_ip_target 10.0.0.1[10/20]
arp_ip_target 10.0.0.1[] (used to disable vlan discovery)

The extended format of arp_ip_target is only supported by using the ip command when creating the bond. Module parameters and the sysfs file do not allow the use of the extended format.

Changes since V3:

1) Moved the parsing of the extended arp_ip_target out of the kernel and into userspace (ip command). A separate patch to iproute2 to follow shortly.
2) Split up the patch set to make review easier.

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

Any reason why this is incompatible with ns_ip6_target?

________________________________________
From: Hangbin Liu <[email protected]>
Sent: Monday, June 30, 2025 3:18 AM
To: David Wilder
Cc: [email protected]; [email protected]; [email protected]; Pradeep Satyanarayana; [email protected]; Adrian Moreno Zapata; Hangbin Liu
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Quoted 6 lines · David Wilder

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

Any reason why this is incompatible with ns_ip6_target?

Hi Hangbin

I am unable to get the existing ns_ip6_target code to function when the target is in a vlan. If the existing code is not working with vlans it makes no sense to specify the vlan tags.

This is what I think is happening:

In ns_send_all() we have this bit of code:

dst = ip6_route_output(dev_net(bond->dev), NULL, &fl6);

if (dst->error) {
        dst_release(dst);
        /* there's no route to target - try to send arp
         * probe to generate any traffic (arp_validate=0)
         */
        if (bond->params.arp_validate)
               bond_ns_send(slave, &targets[i], &in6addr_any, tags);
               <.......>
               continue;
}

ip6_route_output() is returning an error as there is no neighbor entry for the target. A ns is then sent with no vlan header. I found that the multicast ns (with no vlan header) is not passed to the vlan siblings with the target address so no reply is sent.

The ipv4 code is simmiler but the arp is sent as a brodcast. The broadcast arp will be propagated to the vlan sibling (in the linux vlan code).

This could be a testing issue, I am unsure. Can you help with a test case with the target in a vlan?

Quoted 40 lines

From: Hangbin Liu <[email protected]>
Sent: Monday, June 30, 2025 3:18 AM
To: David Wilder
Cc: [email protected]; [email protected]; [email protected]; Pradeep Satyanarayana; [email protected]; Adrian Moreno Zapata; Hangbin Liu
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Quoted 6 lines · David Wilder

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

Any reason why this is incompatible with ns_ip6_target?

Hi Hangbin

I am unable to get the existing ns_ip6_target code to function when the target is in a vlan. If the existing code is not working with vlans it makes no sense to specify the vlan tags.

This is what I think is happening:

In ns_send_all() we have this bit of code:

dst = ip6_route_output(dev_net(bond->dev), NULL, &fl6);

if (dst->error) {
        dst_release(dst);
        /* there's no route to target - try to send arp
         * probe to generate any traffic (arp_validate=0)
         */
        if (bond->params.arp_validate)
               bond_ns_send(slave, &targets[i], &in6addr_any, tags);
               <.......>
               continue;
}

ip6_route_output() is returning an error as there is no neighbor entry for the target. A ns is then sent with no vlan header. I found that the multicast ns (with no vlan header) is not passed to the vlan siblings with the target address so no reply is sent.

Quoted 5 lines

The ipv4 code is simmiler but the arp is sent as a brodcast. The broadcast arp will be propagated to the vlan sibling (in the linux vlan code).

This could be a testing issue, I am unsure. Can you help with a test case with the target in a vlan?

I can reproduce this issue. I guess it's because the IPv6 route code is different with IPv4. I will check this issue.

Thanks
Hangbin

Hi David,

Quoted 40 lines · Hangbin Liu

From: Hangbin Liu <[email protected]>
Sent: Monday, June 30, 2025 3:18 AM
To: David Wilder
Cc: [email protected]; [email protected]; [email protected]; Pradeep Satyanarayana; [email protected]; Adrian Moreno Zapata; Hangbin Liu
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Quoted 6 lines · David Wilder

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

Any reason why this is incompatible with ns_ip6_target?

Hi Hangbin

I am unable to get the existing ns_ip6_target code to function when the target is in a vlan. If the existing code is not working with vlans it makes no sense to specify the vlan tags.

This is what I think is happening:

In ns_send_all() we have this bit of code:

dst = ip6_route_output(dev_net(bond->dev), NULL, &fl6);

if (dst->error) {
        dst_release(dst);
        /* there's no route to target - try to send arp
         * probe to generate any traffic (arp_validate=0)
         */
        if (bond->params.arp_validate)
               bond_ns_send(slave, &targets[i], &in6addr_any, tags);
               <.......>
               continue;
}

ip6_route_output() is returning an error as there is no neighbor entry for the target. A ns is then sent with no vlan header. I found that the multicast ns (with no vlan header) is not passed to the vlan siblings with the target address so no reply is sent.

Quoted 5 lines

The ipv4 code is simmiler but the arp is sent as a brodcast. The broadcast arp will be propagated to the vlan sibling (in the linux vlan code).

This could be a testing issue, I am unsure. Can you help with a test case with the target in a vlan?

I looked into this recently, and you are right — ip6_route_output() returns an error dst. The root cause is that we cannot get the destination IPv6 address through the bond interface, because the source IPv6 address is configured on other interfaces, the VLAN sub-interface.

This is a key difference between IPv6 and IPv4:
In IPv4, it's possible to get a destination route via the bond even when the source IP is configured on a different interface. But in IPv6, the routing mechanism is stricter in requiring the source address to be valid on the outgoing interface.

I'm not sure how to fix this yet, as it's fundamentally tied to how IPv6 routing behaves.

From: Hangbin Liu <[email protected]>
Sent: Wednesday, August 6, 2025 9:38 PM
To: David Wilder
Cc: [email protected]; [email protected]; [email protected]; Pradeep Satyanarayana; [email protected]; Adrian Moreno Zapata
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Hi Hangbin

Quoted 59 lines

Hi David,

Quoted 40 lines · Hangbin Liu

From: Hangbin Liu <[email protected]>
Sent: Monday, June 30, 2025 3:18 AM
To: David Wilder
Cc: [email protected]; [email protected]; [email protected]; Pradeep Satyanarayana; [email protected]; Adrian Moreno Zapata; Hangbin Liu
Subject: [EXTERNAL] Re: [PATCH net-next v4 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

Quoted 6 lines · David Wilder

I have run into issues with the ns_ip6_target feature. I am unable to get the existing code to function with vlans. Therefor I am unable to support A this change for ns_ip6_target.

Any reason why this is incompatible with ns_ip6_target?

Hi Hangbin

I am unable to get the existing ns_ip6_target code to function when the target is in a vlan. If the existing code is not working with vlans it makes no sense to specify the vlan tags.

This is what I think is happening:

In ns_send_all() we have this bit of code:

dst = ip6_route_output(dev_net(bond->dev), NULL, &fl6);

if (dst->error) {
        dst_release(dst);
        /* there's no route to target - try to send arp
         * probe to generate any traffic (arp_validate=0)
         */
        if (bond->params.arp_validate)
               bond_ns_send(slave, &targets[i], &in6addr_any, tags);
               <.......>
               continue;
}

ip6_route_output() is returning an error as there is no neighbor entry for the target. A ns is then sent with no vlan header. I found that the multicast ns (with no vlan header) is not passed to the vlan siblings with the target address so no reply is sent.

Quoted 5 lines

The ipv4 code is simmiler but the arp is sent as a brodcast. The broadcast arp will be propagated to the vlan sibling (in the linux vlan code).

This could be a testing issue, I am unsure. Can you help with a test case with the target in a vlan?

I looked into this recently, and you are right — ip6_route_output() returns an error dst. The root cause is that we cannot get the destination IPv6 address through the bond interface, because the source IPv6 address is configured on other interfaces, the VLAN sub-interface.

This is a key difference between IPv6 and IPv4:
In IPv4, it's possible to get a destination route via the bond even when the source IP is configured on a different interface. But in IPv6, the routing mechanism is stricter in requiring the source address to be valid on the outgoing interface.

Quoted 2 lines

I'm not sure how to fix this yet, as it's fundamentally tied to how IPv6 routing behaves.

I am thinking that we don't need to do a route lookup as if we are sending from the bonding interface. We only need to find the interface we should send the packet through. As if we ran "ip route get <dest addr>".

Quoted 6 lines

Quoted 6 lines

This is a key difference between IPv6 and IPv4:
In IPv4, it's possible to get a destination route via the bond even when the source IP is configured on a different interface. But in IPv6, the routing mechanism is stricter in requiring the source address to be valid on the outgoing interface.

Quoted 6 lines

Quoted 2 lines

I'm not sure how to fix this yet, as it's fundamentally tied to how IPv6 routing behaves.

I am thinking that we don't need to do a route lookup as if we are sending from the bonding interface. We only need to find the interface we should send the packet through. As if we ran "ip route get <dest addr>".

Assuming I'm following correctly, the whole point of the route
lookup is to determine which interface the ARP (or NS for IPv6) should nominally sent through (based on the destination address). This serves two purposes:

- collecting the VLAN tags,

- insuring that the ARP / NS won't be sent on a logically
incorrect interface (e.g., its address corresponds to some totally unrelated interface).

So, really, I'm agreed that what we're really looking for is
"what is the proper output interface to use to send to destination X," which we can then check to see if that interface is logically connected to the bond (e.g., a VLAN atop the bond).

Is the solution to call ip6_route_output() with the flowi6_oif
set to zero? That seems to be what happens for the "ip route get" case in inet6_rtm_getroute() (he says, looking at the code but not running actual tests).