summaryrefslogtreecommitdiffstats
path: root/src/plugins/vrrp/vrrp.api
diff options
context:
space:
mode:
authorMatthew Smith <mgsmith@netgate.com>2020-09-16 16:41:26 -0500
committerMatthew Smith <mgsmith@netgate.com>2020-09-21 15:12:49 +0000
commit4b1b13315a3c532d45fb41cc3ce34a48ad72a757 (patch)
treeb77567b28daacfa31c789ac4ee44b7e0e3ca99d0 /src/plugins/vrrp/vrrp.api
parent8157a161c613c3cc83c1c4507ed141b21b9627b5 (diff)
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>
Diffstat (limited to 'src/plugins/vrrp/vrrp.api')
0 files changed, 0 insertions, 0 deletions