Zebra sends a `SRV6_SID_NOTIFY` notification to inform clients about the
result of a SID alloc/release operation. This commit adds a handler to
process a `SRV6_SID_NOTIFY` notification received from zebra.
If the notification indicates that a SID allocation operation was
successful, then it stores the allocated SID in the SRv6 database,
installs the SID into the RIB, and advertises the SID to the other BGP
routers.
If the notification indicates that an operation has failed, it logs the
error.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Make the `sid_register()` function non-static to allow other BGP modules
(e.g. bgp_zebra.c) to register SIDs.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, BGP allocates SIDs without interacting with Zebra.
Recently, the SRv6 implementation has been improved. Now, the daemons
need to interact with Zebra through ZAPI to obtain and release SIDs.
This commit extends BGP to request SIDs from Zebra instead of allocating
the SIDs on its own.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
When SRv6 VPN is unconfigured in BGP, BGP needs to interact with SID Manager to
release the SID and make it available to other daemons
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit extends BGP to process locator information received from
SRv6 Manager (zebra) and save the locator info in the SRv6 database.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Currently, when SRv6 is enabled in BGP, BGP requests a locator chunk
from Zebra. Zebra assigns a locator chunk to BGP, and then BGP can
allocate SIDs from the locator chunk.
Recently, the implementation of SRv6 in Zebra has been improved, and a
new API has been introduced for obtaining/releasing the SIDs.
Now, the daemons no longer need to request a chunk.
Instead, the daemons interact with Zebra to obtain information about the
locator and subsequently to allocate/release the SIDs.
This commit extends BGP to use the new SRv6 API. In particular, it
removes the chunk throughout the BGP code and modifies BGP to
request/save/advertise the locator instead of the chunk.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add an API to request information from the SRv6 SID Manager (zebra)
regarding a specific SRv6 locator.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Without this patch:
```
r1# sh ip bgp vrf CUSTOMER-A
BGP table version is 1, local router ID is 20.20.20.0, vrf id 4
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
192.168.2.0/24 192.168.179.5@0<
0 0 479 ?
Displayed 1 routes and 1 total paths
r1#
```
This is because the route is imported, next-hop is in a default VRF, and we should
evaluate an ultimate path info, not the current path info.
After:
```
r1# sh ip bgp vrf CUSTOMER-A
BGP table version is 1, local router ID is 20.20.20.0, vrf id 4
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.2.0/24 192.168.179.5@0<
0 0 479 ?
Displayed 1 routes and 1 total paths
r1#
```
In both cases next-hop in cache table is valid:
```
r1# sh ip bgp nexthop
Current BGP nexthop cache:
192.168.179.5 valid [IGP metric 0], #paths 2, peer 192.168.179.5
Resolved prefix 192.168.179.0/24
if r1-eth0
Last update: Thu Sep 5 11:24:37 2024
r1#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The "if_is_vrf" check is unnecessary because it’s already handled by
"if_get_vrf_loopback". Additionally, it ignores the default loopback and
could introduce potential bugs.
Fixes: 8b81f32e97 ("bgpd: fix label lost when vrf loopback comes back")
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
isisd is crashing when reading a ASLA sub-TLV with Application
Identifier Bit Mask length greater than 1 octet.
Set a limit of 8 bytes in accordance with RFC9479 and check that the
received value does not exceed the limit.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Link: https://www.rfc-editor.org/rfc/rfc9479.html#name-application-identifier-bit-
Fixes: 5749ac83a8 ("isisd: add ASLA support")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
If the neighbor is not configured with `neighbor X default-originate route-map ...`,
then this timer is useless.
Change the logic to be it disabled by default, but enabled automatically once the
route-map is configured for default-originate command.
Automatically assigned timer value is as before, 5 seconds.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Enabe/fix using a munet.yaml config file for topology configuration.
Easier test writing.
This also uses the standard `frrinit.sh` to launch and teardown
FRR, so we actually test what most users use.
Signed-off-by: Christian Hopps <chopps@labn.net>
Ticket: #4060069
show bgp vrf afi unicast statistics json output is not return in json
format for non exists vrf.
Fix:
Json output is formatted for non exists vrf cases.
Command supported:
```
show bgp vrf <VRFNAME> ipv4/ipv6 unicast statistics json
show bgp vrf <VRFNAME> l2vpn evpn statistics json
```
Before Fix:
```
leaf11#
leaf11# show bgp vrf test ipv4 unicast statistics json
View/Vrf test is unknown
leaf11#
leaf11#
leaf11# show bgp vrf test ipv6 unicast statistics json
View/Vrf test is unknown
leaf11#
leaf11#
leaf11# show bgp vrf default1 l2vpn evpn statistics json
View/Vrf default1 is unknown
leaf11#
```
After Fix:
```
leaf11#
leaf11# show bgp vrf test ipv4 unicast statistics json
{
"warning":"View/Vrf is unknown"
}
leaf11#
leaf11#
leaf11# show bgp vrf test ipv6 unicast statistics json
{
"warning":"View/Vrf is unknown"
}
leaf11#
leaf11# show bgp vrf default1 l2vpn evpn statistics json
{
"warning":"View/Vrf is unknown"
}
leaf11#
```
Ticket: #4060069
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
When applying the route-map, we always set rmap_type to know who triggered
this action. PEER_RMAP_TYPE_IMPORT/EXPORT was used as a dead-code, and
PEER_RMAP_TYPE_NOSET not used at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
With lots of update-groups, subgroups, this could be very tricky and the timer
is spawned even if it's totally unnecessary (default-originate is not enabled).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When trying to track down a MTYPE_TMP memory leak
it's harder to search for it when you happen to
have some usage of ttable_dump. Let's just give
it it's own memory type so that we can avoid
confusion in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
evpn has a concept of `local` tables where the evpn routes
are actually converted into underlying routes/neighbor
table entries( or vice versa ). Then this local route
is propagated to the global evpn l2vpn table and sent
to the peers. Certain show commands in evpn look
operate on the local table but make the output look
like the data has not been sent to the peer. This
is confusing for the operator. Modify the code
such that local tables get a `Local BGP table not advertised`
in the place where the code talks about whom has received
the data or not.
Example:
torm11# show bgp l2vpn evpn route vni 1000 mac 8a:a1:cc:73:a3:ac ip 45.0.0.5
BGP routing table entry for [2]:[0]:[48]:[8a:a1:cc:73:a3:ac]:[32]:[45.0.0.5]
Paths: (2 available, best #2)
Local BGP table not advertised
Route [2]:[0]:[48]:[8a:a1:cc:73:a3:ac]:[32]:[45.0.0.5] VNI 1000
Imported from 192.168.100.18:2:[2]:[0]:[48]:[8a:a1:cc:73:a3:ac]:[32]:[45.0.0.5], VNI 1000
65101 65005
192.168.100.18(leaf2) from leaf2(192.168.5.1) (192.168.100.14)
Origin IGP, valid, external
Extended Community: RT:65005:1000 ET:8
Last update: Thu Mar 21 14:29:04 2024
Route [2]:[0]:[48]:[8a:a1:cc:73:a3:ac]:[32]:[45.0.0.5] VNI 1000
Imported from 192.168.100.18:2:[2]:[0]:[48]:[8a:a1:cc:73:a3:ac]:[32]:[45.0.0.5], VNI 1000
65101 65005
192.168.100.18(leaf1) from leaf1(192.168.1.1) (192.168.100.13)
Origin IGP, valid, external, bestpath-from-AS 65101, best (Router ID)
Extended Community: RT:65005:1000 ET:8
Last update: Thu Mar 21 14:29:04 2024
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix show nhrp shortcut json
Fixes: 87b9e98203 ("nhrpd: add json support to show nhrp vty commands")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fully check the NHRP convergence after setting nhs1 down. Otherwise the
ping may pass because the previous shortcut is still present.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
After setting down nhs1, the test is checking that nhc1 routing table
matches routes in nhc1/nhrp_route.json. It is incorrect because it
checks that the NHRP route to nhs1 is still present but it should have
disappeared.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
