Made changes and updated the routemap applied counter in the following flows.
1.Increment the routemap applied counter when route map attached to a
redistribution list. The counter will be updated if the routemap exists.
2.Decrement when route map removed / modified from a redistribution list.
3.Increment/decrement when route map create/delete callback triggered.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
i.e changing/adding a match value to the existing routemap.
In Zebra , same update api called for all three add/delete/update operation.
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
Made changes and updated the routemap applied
counter in the following flows.
1.Increment the routemap applied counter when route map
attached to a redistribution list.
The counter will be updated if the routemap exists.
2.Decrement when route map removed / modified from a
redistribution list.
3.Increment/decrement when route map create/delete
callback triggered.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
Made the following changes.
1.Defined two apis in routemap-lib, one for increment and another for
decrement the applied counter.
2.Added a new configuration “show route-map-unused” to track all unused
routemaps.
3.called the corresponding route map update api when a route map attached
or detached from any redistribution list.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
This command was crashing. This fixes the crash
we are still not behaving quite correctly on
handling routes we have learned from those peers
covered by the network statement.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify EIGRP code to pass its used metric down to zebra.
Additionally update topotests to pass with these changes.
Fixes: #3703
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Based on the vulnerability mentioned in 793496 an attacker can craft an
LSA with MaxSequence number wtih invalid links and not set age to MAX_AGE
so the lsa would not be flush from the database.
To address the issue, check incoming LSA is MaxSeq but Age is not set
to MAX_AGE 3600, discard the LSA from processing it.
Based on RFC-2328 , When a LSA update sequence reaches MaxSequence
number, it should be prematurely aged out from the database with age set
to MAX_AGE (3600).
Ticket:CM-18989
Reviewed By:
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This reverts commit ec59a1559c.
Frr.init (called by frr.service) requires functions provided by
/etc/init.d/functions (part of the initscripts package).
Signed-off-by: Liam McBirnie <liam.mcbirnie@boeing.com>
Add a command to track if an interface should be in active-active
mode or not. This command is hidden at this time because it
is not finished fully.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zebra.sock data is the listener socket for the zapi protocol.
The rest of the zebra router does not need to see this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The client_list should be owned by the zebra_router data structure
as that it is part of global state information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The master thread handler is really part of the zrouter structure.
So let's move it over to that. Eventually zserv.h will only be
used for zapi messages.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
When we get into rib_process_result and the operation we are handling
is DPLANE_OP_ROUTE_UPDATE *and* the route entry being looked at
is a route replace, we currently have no way to decode to the old_re
and the re due to how we have stored context. As such they are the
same pointer.
As such the route replace for the same route type is causing the re
to set the installed flag and then immediately unset the installed
flag, leaving us in a state where the kernel has the route but
the rib thinks we are not installed.
Since the true old_re( the one being replaced by the update operation )
is going away( as that it zebra deletes the old one for us already )
this fix is not optimal but will get us moving forward.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Read the onlink flag from the kernel for routes and pass them
up and through to zebra so that we are consistent with what
the kernel is telling us.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we receive a valid message from the kernel that
is either a kernel or system route, we should trust
that the route is legit and just use it.
Old behavior:
K * 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1 inactive, 00:00:16
New Behavior:
K>* 172.22.0.0/15 [0/0] via 172.22.2.254, eva_dummy1, 00:02:35
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The route entry being displayed in debugs was displaying
the originating route type as a number. While numbers
are cool, I for one am not terribly interested in
memorizing them. Modify the (type %d) to a (%s) to
just list the string type of the route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Apparently 'f' means both OpenFabric and a Failed kernel
route installation.
Let's switch the 'f' for the failed kernel route installation
to 'r - rejected route'.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the nexthop->type is NEXTHOP_TYPE_IPV4_IFINDEX we
were writing the RTA_PREFSRC 2 times for the build_singlepath
and build_multipath functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some v6 attributes for the netlink_route_build_singlepath
code were being written two times for the NEXTHOP_TYPE_IPV6_IFINDEX
nexthop type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
