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>

0 files changed, 0 insertions, 0 deletions