If we do `no neighbor PG enforce-first-as`, it wasn't working because the flag
was inherited incorrectly for the members of the peer-group.
Fixes: 322462920e ("bgpd: Enable enforce-first-as by default")
Closes: https://github.com/FRRouting/frr/issues/17702
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before this fix, if rpki_sync_socket_rtr socket returns EAGAIN, then ALL routes
in the RIB are revalidated which takes lots of CPU and some unnecessary traffic,
e.g. if using BMP servers. With a full feed it would waste 50-80Mbps.
Instead we should try to drain an existing pipe (another end), and revalidate
only affected prefixes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
A memory leak happens when reconfiguring an already configured route
distinguisher on an L3VPN BGP instance. Fix this by freeing the previous
route distinguisher.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 0dd96287dd)
Without the fix:
```
show ip prefix-list test_1 10.20.30.96/27 first-match
<no result>
show ip prefix-list test_2 192.168.1.2/32 first-match
<no result>
```
With the fix:
```
ip prefix-list test_1 seq 10 permit 10.20.30.64/26 le 27
!
end
donatas# show ip prefix-list test_1 10.20.30.96/27
seq 10 permit 10.20.30.64/26 le 27 (hit count: 1, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.64/27
seq 10 permit 10.20.30.64/26 le 27 (hit count: 2, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.64/28
donatas# show ip prefix-list test_1 10.20.30.126/26
seq 10 permit 10.20.30.64/26 le 27 (hit count: 3, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.126/30
donatas#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit dd4c2acc2e)
Although trigger unknown, based on the backtrace in one of the internal
testing, we do see some delete in the Intf where we can have the peer
ifp pointer null and we try to dereference it while trying to install
the route leading to a crash
Skip updating the ifindex in such cases and since the nexthop is not
properly updated, BGP skips sending it to zebra.
BackTrace:
0 0x00007faef05e7ebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
1 0x00007faef0598fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
2 0x00007faef09900dc in core_handler (signo=11, siginfo=0x7ffdde8cb4b0, context=<optimized out>) at lib/sigevent.c:274
3 <signal handler called>
4 0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc,
nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273
5 bgp_zebra_announce_actual (dest=dest@entry=0x5560afcfa950, info=0x5560b21187d0, bgp=0x5560ace04df0) at bgpd/bgp_zebra.c:1521
6 0x00005560aad4bc85 in bgp_handle_route_announcements_to_zebra (e=<optimized out>) at bgpd/bgp_zebra.c:1896
7 0x00007faef09a1c0d in thread_call (thread=thread@entry=0x7ffdde8d7580) at lib/thread.c:2008
8 0x00007faef095a598 in frr_run (master=0x5560ac7e5190) at lib/libfrr.c:1223
9 0x00005560aac65db6 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:557
(gdb) f 4
4 0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc,
nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273
1273 in bgpd/bgp_zebra.c
(gdb) p pi->peer->ifp
$26 = (struct interface *) 0x0
Ticket :#4203904
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
The below command is not successfull on an existing as dot peer
> no neighbor 10.0.0.2 remote-as 1.1
> % Create the peer-group or interface first
Handle the case where the remote-as argument can be an ASNUM.
Fixes: 8079a4138d ("lib, bgp: add initial support for asdot format")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Separate zebra's ZAPI server socket handling into two phases:
an early phase that opens the socket, and a later phase that
starts listening for client connections.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 506097a1b9)
There is an extra space in the 'Displayed' line of show bgp command,
that should not be present.
Fix this by being consistent with the output of the other address
families.
Fixes: ("a1baf9e84f71") bgpd: Use single whitespace when displaying show bgp summary
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 561debab54)
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>
(cherry picked from commit c5d7815ccc)
If the desired state is the same - do nothing instead of resetting once again.
Fixes: bdb5ae8bce ("bgpd: Make suppress-fib-pending clear peering")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 7fb4c03f5b)
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>
(cherry picked from commit a0d2734e87)
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>
(cherry picked from commit 68358c0f92)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit f93e5aa166)
When trying to connect to a BGP peer that does not respons, the 'show
bgp neighbors' command does not give any indication on the local and
remote addresses used:
> # show bgp neighbors
> BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link
> Local Role: undefined
> Remote Role: undefined
> BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1
> BGP state = Connect
> [..]
> Connections established 0; dropped 0
> Last reset 00:00:04, Waiting for peer OPEN (n/a)
> Internal BGP neighbor may be up to 255 hops away.
> BGP Connect Retry Timer in Seconds: 120
> Next connect timer due in 117 seconds
> Read thread: off Write thread: off FD used: 27
The addressing information (address and port) are only available
when TCP session is established, whereas this information is present
at the system level:
> root@ubuntu2204:~# netstat -pan | grep 192.0.2.1
> tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV -
> tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd
Add the display for outgoing BGP session, as the information in
the getsockname() API provides information for connected streams.
When getpeername() API does not give any information, use the peer
configuration (destination port is encoded in peer->port).
> # show bgp neighbors
> BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link
> Local Role: undefined
> Remote Role: undefined
> BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1
> BGP state = Connect
> [..]
> Connections established 0; dropped 0
> Last reset 00:00:16, Waiting for peer OPEN (n/a)
> Local host: 192.0.2.1, Local port: 46084
> Foreign host: 192.0.2.150, Foreign port: 179
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 78ce63952a)
When attempting to get the src and destination addresses of a given
connection, the API may return the NULL pointer, but further code
in bgp_zebra_nexthop_set() already does a check about the given
pointer.
Relaxing the error code for all the returned adressing.
Fixes: 1ff9a34058 ("bgpd: bgpd-fsm-fix.patch")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit ba71303099)
Without this patch we set only the first path for the route (if multiple exist)
as LLGR stale and stop doing that for the rest of the paths, which is wrong.
Fixes: 1479ed2fb3 ("bgpd: Implement LLGR helper mode")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
If we set router-id, e.g. `router-id x.x.x.x`, then we have:
```
pc.donatas.net# show ip ospf | include Router ID
OSPF Routing Process, Router ID: x.x.x.x
```
But once we remove it (`no router-id x.x.x.x`), the old router-id remains.
This is kinda OK, but to be consistent with OSPFv3 we should use what Zebra
already has, instead of retaining the old one.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 1073e0f9b3)
A new command is `ospf router-id ...`, but the old one is also valid. Just a no
form was missed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 80bfe6784f)
Before this patch, if we set something like:
```
bgp extcommunity-list expanded 1234 permit admin
```
In running config we have:
```
bgp extcommunity-list 1234 seq 5 permit admin
```
That leads to incorrect rendering, even more the line can't be deleted.
With this fix we treat numbered community-list only if it's inside the range
1-500, otherwise it's a non-numbered clist.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 4c1ee29116)
The algorithm number is encoded on 8 bits and does not require
an unsigned 32 bit value to store the value.
Fixes: cc4926c128 ("isisd,yang: add algorithm-prefix-sid configuration tree")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 8e861a75e8)
we have
(gdb) p *path->attr->aspath
$1 = {refcnt = 3, segments = 0x0, json = 0x0, str = 0x55723d0b7470 "", str_len = 0, asnotation = ASNOTATION_PLAIN}
It looks like this aspath is empty, resulting in a size 0 and NULL pointer for path->attr->aspath->segments which leads to the SIGSEGV
fixe: return 0 when segments is null.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit ee2f1b85cf)
Introduce a command to stop bgpd from enabling IPv6 router advertisement
messages sending on interfaces.
Signed-off-by: Mikhail Sokolovskiy <sokolmish@gmail.com>
