When stopping and restarting BGP daemon part of the configuration
remains. It should be cleared.
Particulary those are address-family parametes, like: distance,
ead-es-frag, disable-ead-evi-rx, disable-ead-evi-tx.
Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>
The rpki current state was ignored when calling for the 'show bgp ipvX
detail' command. Handle the support for this, with json support too.
> "rpkiValidationState" : "valid",
> "rpkiValidationState" : "invalid",
> "rpkiValidationState" : "not used",
> "rpkiValidationState" : "not found",
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
For JSON output we don't need newline to be printed.
Before:
```
"lastUpdate":{"epoch":1734490463,"string":"Wed Dec 18 04:54:23 2024\n"
```
After:
```
"lastUpdate":{"epoch":1734678560,"string":"Fri Dec 20 09:09:20 2024"
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add missing json attribute to BGP path.
Fixes: 82c298be73 ("bgpd: Show RPKI short state in `show bgp <afi> <safi>`")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we have a route-map that sets some attributes e.g. community or large-community,
and the route-map is applied for outgoing direction, everything is fine, but
we missed the point that `advertised-routes detail` was not using the applied
attributes to display and instead it uses what is received from the peer (original).
Let's fix this, and use what's already applied (advertise attributes), and
we can now see:
```
route-map r3 permit 10
match ip address prefix-list p1
set community 65001:65002
set extcommunity bandwidth 100
set large-community 65001:65002:65003
exit
!
...
address-family ipv4 unicast
neighbor 192.168.2.3 route-map r3 out
exit-address-family
...
```
The output:
```
r2# show bgp ipv4 neighbors 192.168.2.3 advertised-routes detail
BGP table version is 1, local router ID is 192.168.2.2, vrf id 0
Default local pref 100, local AS 65002
BGP routing table entry for 10.10.10.1/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.1.1 192.168.2.3
65001
0.0.0.0 from 192.168.1.1 (192.168.1.1)
Origin IGP, valid, external, best (First path received)
Community: 65001:65002
Extended Community: LB:65002:12500000 (100.000 Mbps)
Large Community: 65001:65002:65003
Last update: Thu Dec 19 17:00:40 2024
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit introduces meta queue to the BGP process_queue which is
helpful in having a priority of lists where some routes can be processed
earlier than 'other' routes. This is similar to how meta queue is
present in zebra.
After Fix:
---------
For testing, note that all 100.x routes are marked as Early routes which
got enqueued and dequeued first before Other routes in every batch of
updates. Also, the items are dequeued in FIFO order.
switch# cat /var/log/frr/bgpd.log | grep sub-queue
2024/12/06 19:19:42.788014 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:42.856127 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:42.856138 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:42.886715 BGP: [V64FH-G6883] 66.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.022835 BGP: [V64FH-G6883] 33.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.058842 BGP: [V64FH-G6883] 44.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.092365 BGP: [V64FH-G6883] 55.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.540770 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541233 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541523 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:43.602094 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.649083 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649092 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649148 BGP: [V64FH-G6883] 77.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.712282 BGP: [V64FH-G6883] 100.90.9.138/32 queued into sub-queue Early Route
2024/12/06 19:19:43.712314 BGP: [V64FH-G6883] 100.90.9.139/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817194 BGP: [V64FH-G6883] 100.90.8.58/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817205 BGP: [V64FH-G6883] 100.90.8.59/32 queued into sub-queue Early Route
2024/12/06 19:19:43.942464 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942530 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942550 BGP: [ZAPXS-9754G] 100.90.9.138/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942738 BGP: [ZAPXS-9754G] 100.90.9.139/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942763 BGP: [ZAPXS-9754G] 100.90.8.58/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942788 BGP: [ZAPXS-9754G] 100.90.8.59/32 dequeued from sub-queue Early Route
2024/12/06 19:19:44.558611 BGP: [ZAPXS-9754G] 66.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:44.893541 BGP: [ZAPXS-9754G] 33.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.171794 BGP: [ZAPXS-9754G] 44.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.453137 BGP: [ZAPXS-9754G] 55.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.685269 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.764752 BGP: [ZAPXS-9754G] 77.0.0.9/32 dequeued from sub-queue Other Route
With 'update-delay' feature (EOIU marker):
------------------------------------------
switch# vtysh -c "show run bgp" | grep update-delay
update-delay 40
switch# cat /var/log/frr/bgpd.log | grep sub-queue
2024/12/06 23:27:46.124461 BGP: [V64FH-G6883] 22.0.0.9/32 queued into sub-queue Other Route
2024/12/06 23:27:46.160224 BGP: [V64FH-G6883] 100.90.8.11/32 queued into sub-queue Early Route
2024/12/06 23:27:46.219663 BGP: [W9QTR-P4REP] EOIU Marker queued into sub-queue EOIU Marker
2024/12/06 23:27:46.269711 BGP: [ZAPXS-9754G] 100.90.8.11/32 dequeued from sub-queue Early Route
2024/12/06 23:27:46.270980 BGP: [ZAPXS-9754G] 22.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 23:27:46.404868 BGP: [RBX2V-K33CZ] EOIU Marker dequeued from sub-queue EOIU Markera
Ticket: #4200787
Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we have this construct:
for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) {
...
bgp_process();
}
This can induce an infinite loop. This happens because bgp_process
will move the unsorted items to the top of the list for handling,
as such it is necessary to hold the next pointer to the side
to actually look at each possible bgp_path_info.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If you have a bestpath list that looks something like this:
<local evpn mac route>
<learned from peer out swp60>
<learned from peer out swp57>
And a network event happens that causes the peer out swp60
to not be in an established state, yet we still have the
path_info for the destination for swp60, bestpath
will currently end up with this order:
<learned from peer out swp60>
<local evpn mac route>
<learned from peer out swp57>
This causes the local evpn mac route to be deleted in zebra( Wrong! ).
This is happening because swp60 is skipped in bestpath calculation and
not considered to be a path yet it stays at the front of the list.
Modify bestpath calculation such that when pulling the unsorted_list
together to pull path info's into that list when they are also
not in a established state.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The json display of the version attribute is originally an
integer. It has changed, most probably mistakenly.
> {
> "vrfId": 7,
> "vrfName": "vrf1",
> "tableVersion": 3,
> "routerId": "192.0.2.1",
> "defaultLocPrf": 100,
> "localAS": 65500,
> "routes": {
> "172.31.0.1/32": {
> "prefix": "172.31.0.1/32",
> "version": "1", <--- int or string ??
Let us fix it, by using the integer display instead.
Fixes: f9f2d188e3 ("bgpd: fix 'json detail' output structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we have (default enabled) enabled `bgp ebgp-require-policy`, then first check
it before applying the route-maps.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and
mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because
of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we
have at least one a valid nexthop.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Without the patch only the best path is displayed.
With the patch, display all paths including addpaths, but only for non-JSON
output to avoid breaking existing output.
E.g.:
```
munet> r2 shi vtysh -c 'sh ip bgp nei 192.168.2.3 advertised-routes'
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.254/32 192.168.2.3 0 0 65003 ?
* 172.16.16.254/32 192.168.2.4 0 0 65004 ?
*> 192.168.2.0/24 192.168.2.3 0 0 65003 ?
* 192.168.2.0/24 192.168.2.4 0 0 65004 ?
```
Before it was:
```
munet> r2 shi vtysh -c 'sh ip bgp nei 192.168.2.3 advertised-routes'
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.254/32 192.168.2.3 0 0 65003 ?
*> 192.168.2.0/24 192.168.2.3 0 0 65003 ?
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Fixing this since this wasnt implemented earlier.
Ticket :#4119692
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
We have this:
if ( (safi == SAFI_UNICAST) && ...)
do stuff
if ( (safi == SAFI_MPLS_VPN) && ... )
do stuff
this leads to having to test safi multiple times if safi is
SAFI_UNICAST. Let's make it a else if as that we know that
the safi is going to not change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In an attempt to make the code faster let's just pass
in the prefix instead of having to do a lookup a majillion
times again after we already have it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We iterated over all bgp_path_info's, but once we remove the path, we didn't
check for other paths under the same bgp_dest.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently the code to check to see if any input filters are
applicable is *before* the RFC 8212 check to see if we have
any filters at all. As such we have already tested for this,
so let's move this check for RFC 8212 to immediately before
the input filter test.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The nexthop reachability code was cut-n-pasted 2 times
with just a tiny bit of difference. If we ever change
that it becomes `fun` to keep them in sync. Since this
is more important than full on speed of code let's abstract
and get bgp_update() to be a bit easier to maintain.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The code is just arbitrarily checking to see if there are any
mac addresses associated with a prefix. This makes no
sense from the perspective that it can only happen as
an evpn route. Let's not make non-evpn people pay
the price to check this data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The variable is_loop_check is being set and then later
we test against it multiple times. Move the setting
of whether or not to check for as loops to where it
is tested against and stop testing it multiple times.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In the interest of speeding up code, there is no point in
attempting to see if a label is usable if the number of labels
passed in is 0. Since that is a much much quicker test than
the bgp_is_valid_label() call, let's test that first.
Additionally, there is no point in walking the label[] array
passed in unless we are in the if statement, so move it inside.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In bgp_update(), the two variables allowas_in and aspath_loop_count
are only used when peer->change_local_as is true. Move the retrieval
of the allowas_in data to inside the if statement to save some
(very) small amount of time in bgp_update not gathering this
data unless the particular peer has this set.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When you have multiple paths to a particular route and a single
path changes. In addition of the other paths are either in
hold down or not established or really just not selected you
could end up with a situation where the bestpath choosen
was a path that was in hold down.
Modify the code such that when there is nothing worse
in bestpath selection for the choosen path, but were
unable to do any sorting, just put the path on the top
of the list and declare it the winner. Else just
do the original and put it at the end.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix the display of the local label in show bgp.
> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
> Advertised to non peer-group peers:
> 192.168.1.2
> 65501
> 192.168.1.2 from 192.168.1.2 (172.16.2.2)
> Origin IGP, metric 0, valid, external, best (First path received)
> Remote label: 3
> Last update: Fri Oct 25 17:55:45 2024
Fixes: 67f67ba481 ("bgpd: Drop label_ntop/label_pton functions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This is just a small optimization but when calling path_info_cmp
hundreds of millions of times this adds up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgp_update is a very expensive call. Calling evpn_overlay_free
even when we have no evpn data to free is not trivial. Let's
limit the call into this function until we actually have data to
free.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For consistency between RIB and BGP, the aigp comparison should
be made after the local route check in bgp bestpath selection.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Extended communities can be transitive or non-transitive.
Like other attributes (e.g., MED) non-transitive extended communities SHOULD
be sent to the direct peer, but not forward them to eBGP peers next.
Before this patch, we never send non-transitive extended attributes to the
direct peers at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently the AIGP is always incremented when a route with the
attribute is advertised. That is incorrect when the nexthop is
unchanged, as is commonly the case in route reflection.
Adjust the AIGP for propagation only when the nexthop is set
to ourselves.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
OAD is treated as an _internal_ BGP peer, and some of the rules (including BGP
attributes) can be relaxed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fix several issues in sourcing AIGP attribute:
1) AIGP should not be set as default for a redistributed route or a
static network. It should be set by config instead.
2) AIGP sourced by "set aigp-metric igp-metric" in a route-map does
not set the correct value for a redistributed route.
3) When redistribute a connected route like loopback, the AGIP (with
value 0) is sourced by "set aigp-metric igp-metric", but the
attribute is not propagated as the attribute flag is not set.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
