• Nikolay Aleksandrov's avatar
    net: bridge: add support for backup port · 2756f68c
    Nikolay Aleksandrov authored
    This patch adds a new port attribute - IFLA_BRPORT_BACKUP_PORT, which
    allows to set a backup port to be used for known unicast traffic if the
    port has gone carrier down. The backup pointer is rcu protected and set
    only under RTNL, a counter is maintained so when deleting a port we know
    how many other ports reference it as a backup and we remove it from all.
    Also the pointer is in the first cache line which is hot at the time of
    the check and thus in the common case we only add one more test.
    The backup port will be used only for the non-flooding case since
    it's a part of the bridge and the flooded packets will be forwarded to it
    anyway. To remove the forwarding just send a 0/non-existing backup port.
    This is used to avoid numerous scalability problems when using MLAG most
    notably if we have thousands of fdbs one would need to change all of them
    on port carrier going down which takes too long and causes a storm of fdb
    notifications (and again when the port comes back up). In a Multi-chassis
    Link Aggregation setup usually hosts are connected to two different
    switches which act as a single logical switch. Those switches usually have
    a control and backup link between them called peerlink which might be used
    for communication in case a host loses connectivity to one of them.
    We need a fast way to failover in case a host port goes down and currently
    none of the solutions (like bond) cannot fulfill the requirements because
    the participating ports are actually the "master" devices and must have the
    same peerlink as their backup interface and at the same time all of them
    must participate in the bridge device. As Roopa noted it's normal practice
    in routing called fast re-route where a precalculated backup path is used
    when the main one is down.
    Another use case of this is with EVPN, having a single vxlan device which
    is backup of every port. Due to the nature of master devices it's not
    currently possible to use one device as a backup for many and still have
    all of them participate in the bridge (which is master itself).
    More detailed information about MLAG is available at the link below.
    https://docs.cumulusnetworks.com/display/DOCS/Multi-Chassis+Link+Aggregation+-+MLAG
    
    Further explanation and a diagram by Roopa:
    Two switches acting in a MLAG pair are connected by the peerlink
    interface which is a bridge port.
    
    the config on one of the switches looks like the below. The other
    switch also has a similar config.
    eth0 is connected to one port on the server. And the server is
    connected to both switches.
    
    br0 -- team0---eth0
          |
          -- switch-peerlink
    Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    2756f68c
br_sysfs_if.c 10.6 KB