Message ID | 20220328081417.1427666-1-wintera@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | veth: Support bonding events | expand |
On Mon, 28 Mar 2022 10:14:16 +0200 Alexandra Winter wrote: > In case virtual instances are attached to an external network via veth > and a bridge, the interface to the external network can be a bond > interface. Bonding drivers generate specific events during failover > that trigger switch updates. When a veth device is attached to a > bridge with a bond interface, we want external switches to learn about > the veth devices as well. Can you please add an ASCII diagram of a setup your trying to describe? > Without this patch we have seen cases where recovery after bond > failover took an unacceptable amount of time (depending on timeout > settings in the network). > > Due to the symmetric nature of veth special care is required to avoid > endless notification loops. Therefore we only notify from a veth > bridgeport to a peer that is not a bridgeport. > > References: > Same handling as for macvlan: > 4c9912556867 ("macvlan: Support bonding events" > and vlan: > 4aa5dee4d999 ("net: convert resend IGMP to notifier event") When sending a single patch change you can put all the information in the commit message of the patch, the cover letter is only necessary for series of multiple patches.
On 29.03.22 04:14, Jakub Kicinski wrote: > On Mon, 28 Mar 2022 10:14:16 +0200 Alexandra Winter wrote: >> In case virtual instances are attached to an external network via veth >> and a bridge, the interface to the external network can be a bond >> interface. Bonding drivers generate specific events during failover >> that trigger switch updates. When a veth device is attached to a >> bridge with a bond interface, we want external switches to learn about >> the veth devices as well. > > Can you please add an ASCII diagram of a setup your trying to describe? | veth_a2 | veth_b2 | veth_c2 | ------o-----------o----------o------ \ | / o o o veth_a1 veth_b1 veth_c1 ------------------------- | bridge | ------------------------- bond0 / \ eth0 eth1 In case of failover from eth0 to eth1, the netdev_notifier needs to be propagated, so e.g. veth_a2 can re-announce its MAC address to the external hardware attached to eth1. Does that help? > >> Without this patch we have seen cases where recovery after bond >> failover took an unacceptable amount of time (depending on timeout >> settings in the network). >> >> Due to the symmetric nature of veth special care is required to avoid >> endless notification loops. Therefore we only notify from a veth >> bridgeport to a peer that is not a bridgeport. >> >> References: >> Same handling as for macvlan: >> 4c9912556867 ("macvlan: Support bonding events" >> and vlan: >> 4aa5dee4d999 ("net: convert resend IGMP to notifier event") > > When sending a single patch change you can put all the information > in the commit message of the patch, the cover letter is only necessary > for series of multiple patches. Thank you, I will do so in v2.