Re: [PATCH net-next 0/4] mlxsw: Add VRRP support

[David Miller <davem@davemloft.net>]

From: Ido Schimmel <idosch@mellanox.com>
Date: Sat, 14 Jul 2018 11:39:50 +0300

> When a router that is acting as the default gateway of a host stops
> functioning, the host will encounter packet loss until the router starts
> functioning again.
> 
> To increase the reliability of the default gateway without performing
> reconfiguration on the host, a host can use a Virtual Router Redundancy
> Protocol (VRRP) Router. This virtual router is composed from several
> routers where only one is actually forwarding packets from the host (the
> master router) while the other routers act as backup routers. The
> election of the master router is determined by the VRRP protocol [1].
> 
> Packets addressed to the virtual router are always sent to the virtual
> router MAC address (IPv4: 00-00-5E-00-01-XX, IPv6: 00-00-5E-00-02-XX).
> Such packets can only be accepted by the master router and must be
> discarded by the backup routers.
> 
> In Linux, VRRP is usually implemented by configuring a macvlan with the
> virtual router MAC on top of the router interface that is connected to
> the host / LAN. The macvlan on the master router is assigned the virtual
> IP (VIP) that the host uses as its gateway.
> 
> In order to support VRRP in mlxsw, we first need to enable macvlan upper
> devices on top of mlxsw netdevs and their uppers. This is done by the
> first patch, which also takes care of sanitizing macvlan configurations
> that are not currently supported by the driver.
> 
> The second patch directs packets with destination MAC addresses as the
> macvlans to the router so that they will undergo an L3 lookup. This is
> consistent with the kernel's behavior where the macvlan's Rx handler
> will re-inject such packets to the Rx path so that they will be picked
> up by the IPvX protocol handlers and undergo an L3 lookup. Note that the
> driver prevents the macvlans from being enslaved to other devices, to
> ensure the packets will be picked up by the protocol handler and not by
> another Rx handler.
> 
> The third patch adds packet traps for VRRP control packets for both IPv4
> and IPv6. Finally, the last patch optimizes the reception of VRRP MACs
> by potentially skipping one L2 lookup for them.

Series applied, thank you.