RE: bonding driver issue when configured for active/backup and using ARP monitoring

["Finer, Howard" <hfiner@rbbn.com>]

Thanks Jay.

 This is a dedicated link between our two machines.  The only thing provisioned on it is the bond device and the IP for that bond device.  There are no other addresses on it and no VLANs above it.

The arp_ip_target is not reachable via any other interface.  For example:
  ip route get 169.254.88.1
      169.254.88.1 dev bond0  src 169.254.99.1


Thanks,
Howard



From: Jay Vosburgh <jay.vosburgh@canonical.com>
Sent: Monday, January 4, 2021 9:51 PM
To: Finer, Howard <hfiner@rbbn.com>
Cc: andy@greyhouse.net; vfalico@gmail.com; netdev@vger.kernel.org
Subject: Re: bonding driver issue when configured for active/backup and using ARP monitoring

________________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________________

Finer, Howard <mailto:hfiner@rbbn.com> wrote:

>Please advise if there is any update here, and if not how we can go about
>getting an update to the driver to rectify the issue.

As it happens, I've been looking at this today, and have a
couple of questions about your configuration:

- Is there an IP address on the same subnet as the arp_ip_target
configured directly on the bond, or on a VLAN logically above the bond?

- Is the "arp_ip_target" address reachable via an interface
other than the bond (or VLAN above it)? This can be checked via "ip
route get [arp_ip_target]", i.e., if the target address for bond0 is
http://1.2.3.4, the command "ip route get http://1.2.3.4" will return something like

http://1.2.3.4 dev bond0 src [...]

If an interface other than bond0 (or a VLAN above it) is listed,
then there's a path to the arp_ip_target that doesn't go through the
bond.

The ARP monitor logic can only handle a limited set of
configurations, so if your configuration is outside of that it can
misbehave in some ways.

-J

---
-Jay Vosburgh, mailto:jay.vosburgh@canonical.com