vrrp: set up multicast for both address families 08/28908/4
authorMatthew Smith <mgsmith@netgate.com>
Wed, 16 Sep 2020 21:41:26 +0000 (16:41 -0500)
committerMatthew Smith <mgsmith@netgate.com>
Mon, 21 Sep 2020 15:12:49 +0000 (15:12 +0000)
commit4b1b13315a3c532d45fb41cc3ce34a48ad72a757
treeb77567b28daacfa31c789ac4ee44b7e0e3ca99d0
parent8157a161c613c3cc83c1c4507ed141b21b9627b5
vrrp: set up multicast for both address families

Type: fix

When a VR is added, multicast accept routes are added which allow
inbound packets sent to the VRRP group address on the interface of the
VR so advertisements from peers can be received. If this is the first
VR added, also add a local forward route for the VRRP group address so
the packets will be processed by the VRRP input nodes.

When deciding whether to add/delete the local forward route, the total
number of VRs configured was being checked. If there are no VRs
configured initially and a VR is added for IPv4, this check would
correctly see that this was the first VR and add an IPv4 route. If an
IPv6 VR was configured subsequently, this check would find that a VR
was already configured and incorrectly decide that no route needed to
be added and IPv6 VRRP advertisements from peers would be dropped
as a result. The opposite would occur if you first added an IPv6 VR
followed by adding an IPv4 VR - whichever address family was added
first would work correctly and the other one would not work.

Since a route is needed for each address family, check on the per
address family count of VRs when deciding whether to add/delete the
local forward route instead of checking on the global count of VRs.

Change-Id: I851a7ef8a4f9e4e370d08b0832284a13387eb083
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
src/plugins/vrrp/vrrp.c