The mutex that wraps access to the output buffer
is being held for the entire time the data is
being generated to send down the pipe. Since
the generation has absolutely nothing to do
with the obuf, let's limit the mutex holding some.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The fpm_testing_topo1 didn't turn on the fpm_listener
sending the routes back to zebra to set the asic offload.
Modify the test to tell the fpm_listener to set the offloaded
flag and reflect the route back to the dplane_fpm_nl.c code.
Also modify zebra to expect a response to the underlying fpm listener.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In fpm_listener, when a error is detected it would
stop listening and not recover. Modify the code
to close the socket and allow the connection to
recover.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A recent code change 29122bc9b8
changed the passing of data up the fpm from passing the
tableid and vrf to the sonic expected tableid contains
the vrfid. This violates the assumptions in the code
that the netlink message passes up the tableid as the
tableid. Additionally this code change did not modify
the rib_find_rn_from_ctx to actually properly decode
what could be passed up. Let's just fix this and let
Sonic carry the patch as appropriate for themselves
since they are not the only users of dplane_fpm_nl.c
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In ebgp-multihop, there is a difference in reload behavior when TTL is
unspecified (meaning default 255) and when 255 is explicitly specified.
For example, when reloading with 'neighbor <neighbor> ebgp-multihop
255' in the config, the following difference is created. This commit
fixes that.
Lines To Delete
===============
router bgp 65001
no neighbor 10.0.0.4 ebgp-multihop
exit
Lines To Add
============
router bgp 65001
neighbor 10.0.0.4 ebgp-multihop 255
exit
The commit 767aaa3a80 is not sufficient and frr-reload needs to be
fixed to handle both unspecified and specified cases.
Signed-off-by: Nobuhiro MIKI <nob@bobuhiro11.net>
Currently FRR does not handle v6 recurisive resolution properly
when the route being recursed through changes and the most
significant bits of the route are not changed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The "static_simple" test has code for testing IPv6 routes, but it wasn't
even being run (duh.) Enable it, and also test IPv6 dst-src routes.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When a daemon wants to know about its routes, make it possible to have
that work for dst-src routes.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The staticd YANG conversion completely f*cked up dst-src routes.
Stupidly enough, the correct thing is much simpler as seen by the amount
of deletes in this commit.
This does, unfortunately, involve a rather annoying YANG edge case with
what should reasonably be an optional leaf as part of a list key, which
is not possible. It uses `::/0` as unconditional filler instead, since
that is semantically correct.
The `test_yang_mgmt` topotest needed to be adjusted after this to add
`src-prefix='::/0'`.
Fixes: 88fa5104a0 ("staticd : Configuration northbound implementation")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The Linux kernel doesn't support dst-src routes with NHGs as nexthop,
for some (rather dubious) caching reasons.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The json output of advertised-routes is incorrect, as there is a missing
brace with route-distinguisher:
observed with the bgp_vpnv4_noretain test:
> "bgpTableVersion":0,"bgpLocalRouterId":"192.0.2.1","defaultLocPrf":100,"localAS":65500,
> "advertisedRoutes": "192.0.2.1:1":{"rd":"192.0.2.1:1","10.101.0.0/24":{"prefix":"10.101.0.0/24",
expected:
> "bgpTableVersion":0,"bgpLocalRouterId":"192.0.2.1","defaultLocPrf":100,"localAS":65500,
> "advertisedRoutes": { "192.0.2.1:1":{"rd":"192.0.2.1:1","10.101.0.0/24":{"prefix":"10.101.0.0/24",
> ^
> missing brace
Fix this by adding the missing braces.
Fixes: 4838bac033 ("bgpd: neighbors received-routes/advertised-routes stringify changes")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test that check that the detailed command of show bgp advertised
neighbors 10.125.0.2 displays the locpref value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test that checks that the BGP route to 192.168.0.1 has all the
necessary json outputs. This route is chosen because it is a suppressed
route.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When aggregate is used, the suppressed information is not displayed in
the json attributes of a given path. To illustrate, the dump of the
192.168.2.1/32 path in the bgp_aggregate_address_topo1 topotest:
> # show bgp ipv4
> [..]
> s> 192.168.2.1/32 10.0.0.2 0 65001 i
>
> # show bgp ipv4 detail
> [..]
> BGP routing table entry for 192.168.2.1/32, version 17
> Paths: (1 available, best #1, table default, vrf (null), Advertisements suppressed by an aggregate.)
> Not advertised to any peer
> 65001 <---- missing suppressed flag
> 10.0.0.2 from 10.0.0.2 (10.254.254.3)
> Origin IGP, valid, external, best (First path received)
> Last update: Fri Jan 24 13:11:41 2025
>
> # show bgp ipv4 detail json
> [..]
> ,"192.168.2.1/32": [{"aspath":{"string":"65001","segments":[{"type":"as-sequence","list":[65001]}],"length":1},"origin":"IGP","valid":true,"version":17,
> "bestpath":{"overall":true,"selectionReason":"First path received"}, <---- missing suppressed flag
> "lastUpdate":{"epoch":1737720700,"string":"Fri Jan 24 13:11:40 2025\n"},
> "nexthops":[{"ip":"10.0.0.2","afi":"ipv4","metric":0,"accessible":true,"used":true}],
> "peer":{"peerId":"10.0.0.2","routerId":"10.254.254.3","type":"external"}}]
Fix this by adding the json information.
> # show bgp ipv4 detail
> [..]
> BGP routing table entry for 192.168.2.1/32, version 17
> Paths: (1 available, best #1, table default, vrf (null), Advertisements suppressed by an aggregate.)
> Not advertised to any peer
> 65001, (suppressed)
> 10.0.0.2 from 10.0.0.2 (10.254.254.3)
> Origin IGP, valid, external, best (First path received)
> Last update: Fri Jan 24 13:11:41 2025
>
> # show bgp ipv4 detail json
> [..]
> ,"192.168.2.1/32": [{"aspath":{"string":"65001","segments":[{"type":"as-sequence","list":[65001]}],"length":1},"suppressed":true,"origin":"IGP","valid":true,"version":17,
> "bestpath":{"overall":true,"selectionReason":"First path received"},
> "lastUpdate":{"epoch":1737720991,"string":"Fri Jan 24 13:16:31 2025"},
> "nexthops":[{"ip":"10.0.0.2","afi":"ipv4","metric":0,"accessible":true,"used":true}],"peer":{"peerId":"10.0.0.2","routerId":"10.254.254.3","type":"external"}}]
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This reverts commit 05cf9d03b3.
TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically.
When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID,
and at the same time the receiver sends AddPath capability "disable-addpath-rx"
(flag update) via dynamic capabilities, both peers are out of sync about the
AddPath state. The receiver thinks already he's not AddPath-capable anymore,
hence it tries to parse NLRIs as non-AddPath, while they are actually encoded
as AddPath.
AddPath capability itself does not provide (in RFC) any mechanism on backward
compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath).
This explains why we have failures in our CI periodically.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently when a directly connected peer is going down
BGP gets a call back for nexthop tracking in addition
the interface down events. On the interface down
event BGP goes through and sets up a per peer Q that
holds all the bgp path info's associated with that peer
and then it goes and processes this in the future. In
the meantime zebra is also at work and sends a nexthop
removal event to BGP as well. This triggers a complete
walk of all path info's associated with the bnc( which
happens to be all the path info's already scheduled
for removal here shortly). This evaluate paths
is not an inexpensive operation in addition the work
for handling this is already being done via the
peer down queue. Let's optimize the bnc handling
of evaluate paths and check to see if the peer is
still up to actually do the work here.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The application specific defines from rfc8919 were defined twice in the
isis tlv headers. Remove the second one.
Fixes: 5749ac83a8 ("isisd: add ASLA support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Document where relevant about the instance overload to table ID so users
know what to expect.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Implement the necessary data structures and code changes to support sending
table-direct routes to protocols running in different VRFs.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Duplicate next-hops are maintained for OSPF inter-area and AS
external routes in the OSPF routing table as long as they
correspond to LSAs for different adverting routers. The
intra-area route computation will not result in duplicate
next-hops.
Signed-off-by: Acee Lindem <acee@lindem.com>
OSPF topotest to test OSPF next-hop pruning on installation
into zebra routing table. Also fix multicast_pim_dr_nondr_test
topotest which had a duplicate OSPF route in the results.
Signed-off-by: Acee Lindem <acee@lindem.com>
X
Version requirement from a BuildRequire get dropped and don't get
reflected in Require's for the package. Specify it both ways for
Libyang as we require >= 2.1.128
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
