| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Type: improvement
Currently, when the link goes down on an interface, routes that resolve
through that interface and created with Nexthop API are removed by the
kernel. However, IPv4 routes remain in the FIB because the kernel
doesn't send any notifications about that.
And for the plugin working with user-space applications that create
routes in the kernel using Nexthop API there should be a mechanism to
synchronize the FIB and the kernel in this case.
With this change, add two new startup configuration options to the
plugin to be able to control what should happen with static and dynamic
routes managed by the plugin on link down:
- del-static-on-link-down (disabled by default, delete routes created
with the linux-cp static FIB source on link down),
- del-dynamic-on-link-down (disabled by default, delete routes created
with the linux-cp dynamic FIB source on link down).
Then, monitor link state changes on interfaces for which a linux-cp pair
exists. If the link goes down on one of the interfaces, process routes
that resolve through that interface according to the new configurations.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I0fbaeeca3f3d1fcd22e8eebb08a0a4a3d0dfe5b8
|
|
Type: improvement
Currently, when an interface is brought down administratively, IPv4
routes that resolve through that interface remain in the FIB. However,
the kernel removes those routes but doesn't send any notifications about
that. Desynchronization between the kernel and VPP happens.
With this change, when a notification received from the kernel
indicating that an interface was brought down, in addition to bringing
the VPP interface down, walk the IPv4 FIB bound to that interface and
remove any entries that resolve through that interface and were added
with one of the linux-cp FIB sources.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I0cd14bb63c9e6616ae1c5739b17c3bf33b186bc2
|
|
Type: improvement
When dump of neighbors is requested, the replies will also include
neighbor entries for IPv6 multicast addresses:
GigabitEthernet0/8/0 S ff02::16 33:33:00:00:00:16
GigabitEthernet0/8/0 S ff02::1:ff76:7135 33:33:ff:76:71:35
GigabitEthernet0/8/0 S ff02::2 33:33:00:00:00:02
Such entries are not reported in netlink notification messages and
VPP is unlikely to use these.
With this change, ignore neighbor entries when the IP address is a
multicast address.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ic712aa4904f1d559f31fd89ff4541268e2340f84
|
|
Type: improvement
During synchronization, only the current actual set of entries is
loaded. If some entries are no longer present in the set being loaded
but present in VPP, they should be removed to fully syncronize.
With this change, add handlers for sync begin and end events. Begin
handlers will mark the entries as stale. End handlers will remove the
entries that are still marked as stale.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: I4f7e872af3e1c9ffa6c63bcc3984ec76def1bb43
|
|
Type: improvement
For some message types, timestamps are checked on netlink message to
decide whether the message should be applied. For notification messages
timestamps are expected to be always available.
With this change, before accessing the timestamp, make sure the message
info object that carries it is not null. If it is null, pass the check.
This is to be ready to process dump replies that will not need the
timestamp check and will have the message info object set to null.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
Change-Id: Ic7211c0d451d72f6a5248898b3a8f8e0bca8f7aa
|
|
Some possible side effects for multicast routes appears to be in
lcp_router_table_add_or_lock. so ff00/8 route will be processed
for ospf purposes the right way
Ignore IPv6 kernel routes
Skip adding auto routes into FIB
Type: fix
Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com>
Change-Id: I35f73d629a7fffca7f7d4547adc2549b72c2048f
|
|
Type: feature
please see FEATURE.yaml for details.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Signed-off-by: Pim van Pelt <pim@ipng.nl>
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I6255fd9953d0b03e6b4fe75b67a6845a7c206f74
Signed-off-by: Pim van Pelt <pim@ipng.nl>
|
Alexander Chernavin
Vladimir Ratnikov
Neale Ranns