Fix vni table output broken by 8304dabfab
The "Imported from" output was not getting delimitted by a newline
after the mentioned commit. This fixes that and retains the output
wanted by the original change.
Before:
'''
Route [2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd] VNI 30/10 Imported from 2.2.2.2:4:[2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 16:04:59 2022
'''
After:
'''
Route [2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6] VNI 30/10
Imported from 2.2.2.2:4:[2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 17:02:28 2022
'''
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add new `show bgp vni ...` command to docs. This command
is used to show the per-VNI EVPN tables in BGP.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Both install_evpn_route_entry_in_vni_mac() and
install_evpn_route_entry_in_vni_ip() will unlock the bgp_dest when
install_evpn_route_entry_in_vni_common() returns, so there's no need to
unlock the bgp_dest inside the _common function. Let's let the new
wrappers handle the cleanup of the dest.
Ticket: #3119673
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Add add show bgp vni <VNI|all> json commands.
This is very similar to the old `show bgp evpn l2vpn vni route json`
commands but adds a new `macTable` object under the normal output.
This may change in the future but doing it like this for now
VNI ALL:
```
{
"1002":{
"vni":1002,
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
VNI 1002:
```
{
"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]":{
"prefix":"[2]:[0]:[48]:[00:00:00:00:00:00]:[128]:[fe80::202:ff:fe00:9]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
...
...
...
"numPrefix":4,
"numPaths":7,
"macTable":{
"[2]:[0]:[48]:[00:02:00:00:00:09]":{
"prefix":"[2]:[0]:[48]:[00:02:00:00:00:09]",
"prefixLen":352,
"paths":[
[
{
"valid":true,
"pathFrom":"external",
```
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add some neigh deletion debugs for when the neigh isn't
found or there is a MAC mismatch on what was sent and found.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Re-work the bgp vni table to use separately keyed tables for type2
routes.
So, with type2 routes, we have the main table keyed off of the IP and a
new MAC table keyed off of MACs.
By separating out the two, we are able to run path selection separately
for the neigh and mac. Keeping the two separate is also more in-line
with what happens in zebra (they are managed comptletely seperate).
With this change type2 routes go into each table like so:
```
Remote MAC-IP -> IP Table & MAC Table
Remote MAC -> MAC Table
Local MAC-IP -> IP Table
Local MAC -> MAC Table
```
The difference for local is necessary because we should not ever allow
multiple paths for a local MAC.
Also cleaned up the commands for querying the vni tables:
```
show bgp vni all type ...
show bgp vni VNI type ...
```
Old commands will be deprecated in a separate commit.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
If we add/modify community/large/ext lists without sequence numbers, and
doing frr-reload.py, then rules with sequence numbers (show running-config
always adds sequence numbers) will be deleted and new ones will be re-added.
This could lead to blackholing for some time.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
We locate the sync path with the highest seq number for normalizing
local path to the same seq. With the change to maintain the VNI RT table
by IP address (instead of MAC&IP) we need additional changes to skip
paths with a different mac address than the local one we are trying to
normalize.
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Add some special handling to accept lower seq routes for local
known routes when not ready. This aligns the code back a bit more
to where it was before to fix seen issues with sync routes.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Use the IP addr of type2/macip routes only for the hash/key
of the VNI table and carry the MAC in a path_info_extra attribute.
There is exists situations that can be hit during extended MAC mobility events
where two MACs could be pointing to the same IP in our global table. It
is requires very specific timings.
When that happens, BPG would (because we key'd on both MAC and IP)
install both into it's VNI table as separate entries, but zebra only
knows/needs to know about a single IP -> MAC relationship for it's VNI
table's type2 routes. So it was compleletly undeterministic which one
zebra would end up with in these timing situations.
With these changes, we move BGP's VNI table to key'd the same as Zebra's
and now a single IP will have multiple path_info's with a path_info_extra
that is carrying the MAC info for each path.
BGP will then run best path to deterministically decide which one to send to
zebra during the occasions where there exist's two possible MACs.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
When an SRv6 locator is unset, all the SRv6 SIDs allocated from the
locator are removed. Before freeing the memory allocated for an SRv6
SID, we check if the pointer to the SID is `NULL`.
However, checking for `NULL` before freeing memory is useless.
This PR aims to improve the code's readability by removing the
useless `NULL` checks.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Currently, if `bgp max-med on-startup` is configured, after BGP session
is established for the first time, a timer for the specified time is
started. When the timer is expired, an UPDATE message should be sent to
reflect changes in the routes' MED value. The problem is that the routes
are being suppressed because based on the attributes they look like they
have not changed. However, in the case of max-med, the value is copied
to the packet directly from `bgp->maxmed_value`, not from the
attributes. Thus, changes in this case cannot be detected by comparing
attributes.
With this fix, avoid route suppressing when the `max-med on-startup`
timer expires and initiates an UPDATE.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
With this fix, make "no match rpki" in a route-map actually remove the
node in the candidate configuration instead of creating it.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
RpAddress is showing wrong value in
"show ipv6 pim bsm-database" cli. This is fixed now.
Issue: #12089
Signed-off-by: Sarita Patra <saritap@vmware.com>
Updating topojson script's assert messages,
which will help in better debugging, when
test will fail.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
This mostly happens only for large configuration files, where the default
restart-time (-T, --restart-time / 20s) is not enough.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The bgp_gr_restart_retain_routes test is looking for specific output
that does not include the routes nexthop id:
def _bgp_check_kernel_retained_routes():
output = (
r2.cmd("ip route show 172.16.255.1/32 proto bgp dev r2-eth0")
.replace("\n", "")
.rstrip()
)
expected = "172.16.255.1 via 192.168.255.1 metric 20"
diff = topotest.get_textdiff(
output, expected, "Actual IP Routing Table", "Expected IP RoutingTable"
)
if diff:
return False
return True
While the output includes nexthop group id's now:
root@r2:# ip route show 172.16.255.1 proto bgp dev r2-eth0
172.16.255.1 nhid 8 via 192.168.255.1 metric 20
Let's just mark r2 as not to use nexthop groups for installation
and this test issue will go away.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
No mistake, just to unify style for the parameter of function address - remove
ampersand. In current code, only this one place of `hook_register()`s needs
to be made.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Add a knob to accept lower seq number in evpn updates
from BGP in Zebra.
Note: Knob is enabled by default
Signed-off-by: Stephen Worley <sworley@nvidia.com>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
