The function ecommunity_str2com_internal appears to want to handle
the ecommunity_token_rt6 enum but skips over it. Commit
9a659715df tried to add this but I really
don't see how this is going to behave correctly. Add the
ecommunity_token_rt6 case to the switch statement so it is handled
appropriately?
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The function ecommunity_str2com_internal appears to want to handle
the ecommunity_token_rt6 enum but skips over it. Commit
9a659715df tried to add this but I really
don't see how this is going to behave correctly. Add the
ecommunity_token_rt6 case to the switch statement so it is handled
appropriately?
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The test was sometimes failing around the sleep(4) for
waiting for the routes to be installed. Instead of blindly
sleeping let's check to see that the routes are actually
there in zebra and then continue on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There existed the idea, from Volta, that a nexthop group would not have
the same nexthops installed -vs- what FRR actually sent down. The
dplane would notify you.
With the addition of 06525c4f99
the code was put behind a bit of a wall controlled the usage
of it.
The flag ROUTE_ENTRY_USE_FIB_NHG flag was being used
to control which set was being sent up to concerned parties
in nexthop tracking. Put this flag behind the wall and
do not necessarily set it when we receive a data plane
notification about a route being installed or not.
Fixes: #12706
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Run under Github Actions, and restrict commit messages, structure, with, etc.
Enforce using only our specified prefixes for commit messages. It reduces the
work release managers do when _crafting_ release notes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before this, if the peer disables sending FQDN capability, the old hostname
still (STALE) exists and is misleading in the outputs of `show bgp ...`.
Especially when using with `bgp default show-hostname`, etc.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
These two functions always return 0. As such any and all
tests against this make no sense. Remove the return 0
to a void and follow the chain, logically, to remove all
the dead code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When listening on a multicast group. No need to actually
fail the operation when it's already being used.
Let's not treat the Address already in use error message
as one that is stopping everything from working. Especially
since multiple interface events cause this to happen.
Without this, if config is read in before full connection
to zebra, babel will never establish neighbors.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Moves the old/new IP comparison into handle_tunnel_ip_change instead of
expecting the caller to do the check on their own.
Also changes handle_tunnel_ip_change to return void since it only ever
returned 0 in all cases.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When processing a new local VNI, we were always walking the global EVPN
table to look for routes that needed to be removed due to a martian
nexthop change (specifically a tunnel-ip change).
Since the martian TIP table is global (all VNIs) + the walk is also in
the global table (all VNIs), we can trust that any new TIP from any VNI
would result in routes getting removed from the global table and
unimported from all live (L2)VNIs.
i.e.
The only time this update is actionable is if we are adding/removing an
IP from the martian TIP table, and we do not need to walk the table for
normal refcount adjustments.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
