Age | Commit message (Collapse) | Author | Files | Lines |
|
When use update api delete a virtual address, no matter which IP want to delete, always delete the last one.
Type: fix
Signed-off-by: GaoChX <chiso.gao@gmail.com>
Change-Id: Ia67c06dd53a442740794e1884d1a4aaa06965398
|
|
we need cancel vrrp_vr_timer when deleting vrrp vr
Type: fix
Signed-off-by: luoyaozu <luoyaozu@chinatelecom.cn>
Change-Id: I8ea01f1943d6e3e60c4990c5be945de613bc8b53
|
|
Here is bug example:
vpp# create loopback interface
loop0
vpp# vrrp vr add loop0 vr_id 1 priority 100 192.168.1.1 192.168.1.2
vpp# vrrp vr del loop0 vr_id 1
vpp# vrrp vr add loop0 vr_id 1 priority 100 192.168.1.1 192.168.1.2
vrrp vr add: vrrp_vr_add_del returned -105
Type: fix
Signed-off-by: GaoChX <chiso.gao@gmail.com>
Change-Id: I3e0d086ac8fb52756339cff19b9a83911ec9748b
|
|
Add simple counter statistics to VRRP, based on a subset of those
defined in RFC8347.
Add an update API that allows in-place modification of an existing
instance. The method returns a vrrp_index which can be used both for
retrieving statistics and to modify non-key parameters. Also add a
delete method which will take that vrrp_index as parameter.
Type: improvement
Signed-off-by: Emanuele Di Pascale <lele84@gmail.com>
Change-Id: I2cd11467b4dbd9dfdb5aa748783144b4883dba57
|
|
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>
|
|
Type: fix
Signed-off-by: jinsh <jinsh11@chinatelecom.cn>
Change-Id: Id80601bc753c59c4ea95ff5f74f9b15c40c01e35
|
|
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>
|
|
when vrrp vr delete, vr->config.peer_addrs not free
Type: fix
Signed-off-by: jinsh <jinsh11@chinatelecom.cn>
Change-Id: I9ead188d6409412b475b5f6add767cb58f1af6e0
|
|
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
|
|
Type: refactor
Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Type: feature
Add a new plugin to support HA using VRRPv3 (RFC 5798).
Change-Id: Iaa2c37e6172f8f41e9165f178f44d481f6e247b9
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|