if the local sticky mac delete request is received,
if there are associated neighbor entries present, mac's
only local flag is removed and marked as auto mac.
this results in next local mac learning automatically assumes
mac is sticky.
There is a case when bridge learning off is configured, user
configures sticky mac via bridge fdb add.
This MAC learns associated neighbor entry.
Later user deletes stick mac via bridge fdb del, this triggers
frr to delete mac but if there are neighbors present, frr marks
MAC as AUTO but does not remove sticky flag.
User enables bridge learning on which triggers
The mac to learn as dynamic entry and in absence of this
fix, the mac is marked as sticky.
Ticket:CM-24968
Reviewed By:CCR-8683
Testing Done:
Validated broken condition with internally reproduction
with fix and without.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
become stale entries.
Topology:
--------
Source
|
FHR
|
RP ------ LHR --- Recv1
|
Recv2
Root case :
-----------
When RP acts as a LHR i.e RP has a local receiver and registed for
the same group where LHR connected receiver also registered for the
same multicast group.When RP receives a (s,g) join form LHR , it
increments upstream ref count to two to track the Local membership
as well.But at the time of KAT expiry in RP , upstream reference
is not being removed Which is added to track local membership which
is causing to make these entries as stale in RP and FHR.
Fix : Made the change such that it removes the upstream reference
if it is added to track the local memberships.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
This fix aims to reduce the load on BGPD when certain
exisiting configurations are replayed.
Specifically, the fix prevents BGPD from processing
routes when the following already existing configurations
are replayed:
1) A match criteria is configured within a route-map.
2) When "call" is invoked within a route-map.
3) When a route-map is tied to a BGP neighbor.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Route map library creates a hash table to save the dependency binding.
route-map LRM permit 1
call rLRM
Whenever there is change in child routemap(rLRM), it tries to
find the dependency mapping with the child route map MATCH event
and it fails.The handing of match add and match delete was missing
to get the correct dependency,here it's LRM.
This fix would correct the flow to get the correct dependency.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Different versions of linux are assigned different interface
ifindexes. Mask that cabbage out.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
lcommunity_list_show uses the wrong macro to calculate the style.
Use the correct one LARGE_COMMUNITY_LIST_STANDARD.
Signed-off-by: vishaldhingra<vdhingra@vmware.com>
Noticed that a couple of the `show zebra ...` commands are missing
from the zebra documentation that I use a bunch. Let's add them
in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The Sub-TLVs of the Extended IPv4 reachability TLV were not being
displayed as expected. Fix this.
Suggested-by: Christian Franke chris@opensourcerouting.org
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
libyang 1.0 introduced a few changes in the user types API, and
these changes made FRR incompatible with libyang 1.x. In order to
ease our migration from libyang 0.x to libyang 1.x, let's disable
our libyang custom user types temporarily so that FRR can work
with both libyang 0.x and libyang 1.x. This should be especially
helpful to the CI systems during the transition. Once the migration
to libyang 1.x is complete, this commit will be reverted.
Disabling our libyang custom user types should have only
minimal performance implications when processing configuration
transactions. The user types infrastructure should be more important
in the future to perform canonization of YANG data values when
necessary.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
