summaryrefslogtreecommitdiffstats
path: root/src/plugins/vrrp/vrrp.c
AgeCommit message (Collapse)AuthorFilesLines
2022-02-22vrrp: fix thread synchronization issueMatthew Smith1-2/+3
Type: fix Fixes: 39e9428b90bc When a VRRP advertisement is received by a worker thread, the worker calls vl_api_rpc_call_main_thread() so the main thread will process the packet and make adjustments to VR state if necessary. The data being passed to the main thread included a pointer to the VRRP header in the received packet buffer. Since the main thread processes the RPC request asynchronously from the worker thread, it's possible for the worker to drop the packet and for the buffer to be overwritten before the main thread can process it. Copy the fields which may be needed by the main thread into a struct instead of passing a pointer to a packet buffer. Change-Id: I4e899e967df5a54776b521825a80e9cce1a94f5f Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2022-01-10vrrp: vrrp in unicast mode,interface not add virtual ip addresssjinsh1-3/+0
Type: fix Signed-off-by: jinsh <jinsh11@chinatelecom.cn> Change-Id: Id80601bc753c59c4ea95ff5f74f9b15c40c01e35
2022-01-03vrrp: fix support for VRs in different FIBsMatthew Smith1-15/+13
Type: fix Fixes: 4b1b13315a3c When adding or deleting a VR, multicast routes can be added or deleted. When the first VR is added, a local (dpo-receive) route is added. The route is deleted when the last VR is deleted. Perform the check on whether to add or delete the route on a per-FIB basis. Otherwise, if the route is only added after the first VR is added without regards to the FIB being used and a second VR is added later on an interface attached to a different FIB, the necessary route will not be added to the FIB used by the second interface. Change-Id: Ib30925ecf45c714cfe3ac6a223754bea918f10e3 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2021-12-20vrrp:fix vrrp vr delete case memory leakjinsh1-0/+1
when vrrp vr delete, vr->config.peer_addrs not free Type: fix Signed-off-by: jinsh <jinsh11@chinatelecom.cn> Change-Id: I9ead188d6409412b475b5f6add767cb58f1af6e0
2021-10-21fib: respect mfib entry flags on create with pathsPaul Atkins1-2/+2
When an mfib entry was created with both paths and entry_flags then the entry flags were being ignored. If there are no paths then the flags were passed into mfib_table_entry_update, but in the case where the entry didn't exist and there were paths and flags, the entry was created within mfib_table_entry_paths_update() which used a default of MFIB_ENTRY_FLAG_NONE. Pass the flags through into the mfib_table_entry_paths_update fn. All existing callers other than the create case will now pass in MFIB_ENTRY_FLAG_NONE. Type: fix Signed-off-by: Paul Atkins <patkins@graphiant.com> Change-Id: I256375ba2fa863a62a88474ce1ea6bf2accdd456
2020-12-14misc: move to new pool_foreach macrosDamjan Marion1-3/+3
Type: refactor Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772 Signed-off-by: Damjan Marion <damarion@cisco.com>
2020-10-24vrrp: asynchronous events on VR state changeMatthew Smith1-0/+2
Type: feature Add API message for an API client to subscribe/unsubscribe to receive an event when a VRRP VR changes state. Add code to build and send the events. Change-Id: Ie92cadd4850d4352c1aaa79c4b0a7daa0f3b04e7 Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2020-09-21vrrp: set up multicast for both address familiesMatthew Smith1-2/+14
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>
2020-09-04vrrp: improve RFC compliance for ARP/NDMatthew Smith1-36/+39
Type: fix The ARP/ND feature nodes reply to requests for a VR virtual IP address when a VR is in the master state. If the VR is in the backup state, the request is passed to the next node on the feature arc. This can cause an incorrect response to be sent. If some other feature (e.g. NAT) causes a virtual IP address to be configured as a "local" address on the system, a later node on the feature arc may respond to an ARP/ND request with the real MAC address of the interface. RFC 5798 says that a router must respond to ARP/ND requests for VR virtual IP addresses with the VR virtual MAC address. And it says a router must not respond to ARP/ND requests for VR virtual IP addresses when the VR is in the backup state. Ensure that ARP/ND requests for VR virtual IP addresses are dropped when in the backup state rather than allowing them to continue on the feature arc where another node may end up responding. In order to do this, enable/disable the feature nodes when leaving or entering the init state instead of the master state. Change-Id: I416f83e125cbf91deb90c3b6eb00ba3207de24ad Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2020-06-27vrrp: backup processes priority 255 advertisementMatthew Smith1-1/+33
Type: fix When accept mode is enabled, a backup VR will configure the VR virtual addresses locally and respond to packets sent to those addresses. This did not work when the primary VR is the address owner and sends advertisements using the virtual address as the source address. It also did not work when NAT was configured on the interface with the virtual address as the NAT pool address. In both cases, advertisements from other VRs would arrive and be dropped because they appeared to be spoofed - the source address would be an address that is configured as an interface address on the instance receiving it. When accept mode is enabled for a VR and the VR enters the master state, add an input feature on ip[46]-multicast for the interface which looks for VRRP advertisements, figures out whether they are for a VR which is configured with accept mode and is in the master state and kicks them straight to the VRRP nodes to avoid dropping them. Change-Id: I240ba1ee0b3fd6d693de729698c1181dc71bb08b Signed-off-by: Matthew Smith <mgsmith@netgate.com>
2020-02-13vrrp: add plugin providing vrrp supportMatthew Smith1-0/+1240
Type: feature Add a new plugin to support HA using VRRPv3 (RFC 5798). Change-Id: Iaa2c37e6172f8f41e9165f178f44d481f6e247b9 Signed-off-by: Matthew Smith <mgsmith@netgate.com>