netdev - bonding in active/backup with ARP monitoring does not silently switch the slaves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 24 Nov 2020 18:44:18 +0000
From:   "Finer, Howard" <hfiner@...n.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: bonding in active/backup with ARP monitoring does not silently switch
 the slaves

We use the bond driver in an active-backup configuration with ARP monitoring. We also use the TIPC protocol which we run over the bond device. We are consistently seeing an issue in both the 3.16 and 4.19 kernels whereby when the bond slave is switched TIPC is being notified of the change rather than it happening silently.  The problem that we see is that when the active slave fails, a NETDEV_CHANGE event is being sent to the TIPC driver to notify it that the link is down. This causes the TIPC driver to reset its bearers and therefore break communication between the nodes that are clustered.
With some additional instrumentation in thee driver, I see this in /var/log/syslog:
<6> 1 2020-11-20T18:14:19.159524+01:00 LABNBS5B kernel - - - [65818.378287] bond0: link status definitely down for interface eth0, disabling it
<6> 1 2020-11-20T18:14:19.159536+01:00 LABNBS5B kernel - - - [65818.378296] bond0: now running without any active interface!
<6> 1 2020-11-20T18:14:19.159537+01:00 LABNBS5B kernel - - - [65818.378304] bond0: bond_activebackup_arp_mon: notify_rtnl, slave state notify/slave link notify
<6> 1 2020-11-20T18:14:19.159538+01:00 LABNBS5B kernel - - - [65818.378835] netdev change bearer <eth:bond0>
<6> 1 2020-11-20T18:14:19.263523+01:00 LABNBS5B kernel - - - [65818.482384] bond0: link status definitely up for interface eth1
<6> 1 2020-11-20T18:14:19.263534+01:00 LABNBS5B kernel - - - [65818.482387] bond0: making interface eth1 the new active one
<6> 1 2020-11-20T18:14:19.263536+01:00 LABNBS5B kernel - - - [65818.482633] bond0: first active interface up!
<6> 1 2020-11-20T18:14:19.263537+01:00 LABNBS5B kernel - - - [65818.482671] netdev change bearer <eth:bond0>
<6> 1 2020-11-20T18:14:19.367523+01:00 LABNBS5B kernel - - - [65818.586228] bond0: bond_activebackup_arp_mon: call_netdevice_notifiers NETDEV_NOTIFY_PEERS

There is no issue when using MII monitoring instead of ARP monitoring since when the slave is detected as down, it immediately switches to the backup as it sees that slave as being up and ready.    But when using ARP monitoring, only one of the slaves is 'up'.  So when the active slave goes down, the bond driver will see no active slaves until it brings up the backup slave on the next call to bond_activebackup_arp_mon.  Brining up that backup slave has to be attempted prior to notifying any peers of a change or else they will see the outage.  In this case it seems the should_notify_rtnl flag has to be set to false.    However, I also question if the switch to the backup slave should actually occur immediately like it does for MII and that the backup should be immediately brought up/switched to without having to wait for the next iteration.

As it currently is implemented there is no way to run TIPC over an active-backup ARP-monitored bond device.  I suspect there are other situations/uses that would likewise have an issue with the 'erroneous' NETDEV_CHANGE being issued.   Since TIPC (and others) have no idea what the dev is, it is not possible to ignore the event nor should it be ignored.  It therefore seems the event shouldn't be sent for this situation.   Please confirm the analysis above and provide a path forward since as currently implemented the functionality is broken.

Thanks,
Howard Finer