Skip to content

bonding: send GARP on bonding-slb port link/carrier down

Fernando Fernández Mancera requested to merge ff/garp_bond_slb into main

Summary

When a bond in balance-slb is created, the ports are enabled or disabled based on carrier and link state. If the link/carrier goes down, the port becomes disabled and we must make sure the MAC tables of the switches are updated properly so the traffic is redirected.

In order to solve this, we send a GARP or RARP broadcast packet on the bond. This fix cover 3 different balance-slb scenarios.

Scenario 1: The bond in balance-slb mode has IPv4 address configured and some ports connected. Here the bond is acting like active-backup as the packets will always have as source MAC the address of the bond interface. When a port goes down, NetworkManager will send a GARP broadcast announcing the address configured on the bond with the MAC address configured on the port.

Scenario 2: The bond in balance-slb mode is connected to a bridge and has some ports connected. The bridge has IPv4 configured. When a port goes down, NetworkManager will send a GARP broadcast announcing the address configured on the bridge with the MAC address configured on the port.

Scenario 3: The bond in balance-slb mode is connected to a bridge and has some ports connected. The bridge does not have IP configuration and therefore everything is L2. When a port goes down, NetworkManager will query the FDB table and filter the entries by the ones belonging to the bridge and the bond ifindexes. Then, it will send a RARP broadcast announcing every learned MAC address from FDB.

Resolves: https://issues.redhat.com/browse/RHEL-59567

Purpose

Update the MAC table of switches connected to the bond when one of the ports goes down so traffic is redirected properly and can reach the right port.

Checklist

Please read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/CONTRIBUTING.md before opening the merge request. In particular, check that:

  • the subject for all commits is concise and explicative
  • the message for all commits explains the reason for the change
  • the source is properly formatted
  • any relevant documentation is up to date
  • you have added unit tests if applicable
  • the NEWS file is updated when the change deserves to be mentioned, for example for new features, behavior changes, API deprecations, etc.
Edited by Fernando Fernández Mancera

Merge request reports