bgpd: fix addressing information of non established outgoing sessions
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:
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>
bgpd: remove useless control checks about TCP connection
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: 1ff9a340588a ("bgpd: bgpd-fsm-fix.patch") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: prompt should be given only for the real change
Prompt nothing for an empty (and failed) operation. Take
`bgp graceful-restart` as an example:
Before:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)#
```
After:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
anlan(config-router)#
```
The same command should be accepted, it is an empty operation. Take
`neighbor <X> graceful-restart-helper` as an example:
Before:
```
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
% The Graceful Restart command used is not valid at this moment.
anlan(config-router)#
```
After:
```
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)#
```
Donald Sharp [Thu, 11 Apr 2024 17:28:30 +0000 (13:28 -0400)]
bgpd: Increase install/uninstall speed of evpn vpn vni's
BGP receives notification from zebra about an vpn that
needs to be installed into the evpn tables. Unfortunately
this function was walking the entirety of evpn tables
3 times. Modify the code to walk the tree 1 time and
to just look for the needed route types as you go.
This reduces, in a scaled environment, processing
time of the zclient_read function from 130 seconds
to 95 seconds. For a up / down / up interface
scenario.
Signed-off-by: Rajasekar Raja <rajasekarr@vndia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Tue, 19 Mar 2024 23:30:41 +0000 (19:30 -0400)]
tests: Cleanup generate_support_bundle() to not fail
The Support bundle generation was/is failing in both
our upstream ci and locally. This cleans up the failures
that I am seeing such that tests now continue to run
instead of aborting the test run.
Donald Sharp [Mon, 8 Apr 2024 20:24:05 +0000 (16:24 -0400)]
zebra: Actually display I/O buffer sizes
An operator found a situation where zebra was
backing up in a significant way towards BGP
with EVPN changes taking up some serious amounts
of memory. The key lines that would have clued
us in on it were behind a dev build. Let's change
this.
Philippe Guibert [Thu, 21 Mar 2024 15:48:52 +0000 (16:48 +0100)]
bgpd: fix install BGP route with appropriate colored ext. community
When receiving a BGP update that includes a colored extended community,
the nexthop is tracked in the bgp nexthop tracking context, but the
color is never recorded. Adding to this, the BGP route is not prevented
from being installed without hte color.
Actually, the srte color is set only when the SRTE_COLOR attribute is set.
And that attribute value is only set when an ext. community is locally
created, or an srte value is set, but not when a BGP update with a color
ext. community is received.
Fix this by setting the SRTE_COLOR attribute on this last case.
Fixes: 442e2edcfaef ("bgpd: add functions related to srte_color management") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 28 Mar 2024 14:56:19 +0000 (15:56 +0100)]
topotests: fix ignore routes with linkdown
In topotest, a given interface has only the ignore routes bit turned
on for IPv6 only, whereas topotest is expected to turn it on for all
address families.
> # show interface
> Interface r2-r3-eth2 is up, line protocol is up
> [..]
> flags: <UP,BROADCAST,RUNNING,MULTICAST>
> Ignore all v6 routes with linkdown
> Type: Ethernet
> [..]
This is because the only the 'default' ipv6 ignore sysctl is set to
1. Set also the /proc/sys/net/conf/<family>/default/ignore_routes_with_linkdown
flag, to have same behaviour for ipv4 and ipv6.
Fixes: 4958158787ce ("tests: micronet: update infra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
ospfd: Implement non-broadcast support for point-to-multipoint networks
This extends non-broadcast support to point-to-multipoint networks.
Neighbors will be explicitly configured and polled in lieu of multicast
dicovery. Toptotests and documentation updates are included.
Additionally, the ospf neighbor commands have been greatly simplified taking
advantage of DEFPY() capabilities.
The AllOSPFRouters (224.0.0.5) is still joined for non-broadcast networks
since it is joined for NBMA networks. It seems this could be removed but
it should done be in a separate commit.
---------------------------------------------------------------------------- live log call -----------------------------------------------------------------------------
2024-03-29 18:12:22,608 INFO: r1: checking if daemons are running
2024-03-29 18:12:22,802 INFO: r2: checking if daemons are running
2024-03-29 18:12:22,911 INFO: r3: checking if daemons are running
2024-03-29 18:12:23,015 INFO: topo: Remove bgp peer-group PG1 remote-as neighbor should be retained
2024-03-29 18:12:25,605 INFO: topo: Re-add bgp peer-group PG1 remote-as neighbor should be established
----------------------------------------------------------- generated xml file: /tmp/topotests/topotests.xml -----------------------------------------------------------
========================================================================== 2 passed in 17.63s ==========================================================================
Philippe Guibert [Fri, 29 Mar 2024 11:07:14 +0000 (12:07 +0100)]
bgpd: add resolved_prefix visibility on nht
The nexthop tracking never displays the prefix that
has been used in ZEBRA to resolve its nexthop. This
information will be useful if some decision has to be
taken regarding any loops, that is to say if for instance
a BGP prefix is resolved over a prefix in ZEBRA that is
exactly the same.
Store the value in bgp nexthop context, and display it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Piotr Suchy [Thu, 28 Mar 2024 11:55:35 +0000 (12:55 +0100)]
vtysh, zebra: Fix malformed json output for multiple vrfs in command 'show ip route vrf all json'
Command 'show ip route vrf <vrf_name> json' returns a valid json object,
however if instead of <vrf_name> we specify 'all', we get an invalid json
object, like:
Philippe Guibert [Fri, 29 Mar 2024 07:35:34 +0000 (08:35 +0100)]
bgpd: fix srv6 memory leak detection
The asan memory leak has been detected:
> Direct leak of 16 byte(s) in 1 object(s) allocated from:
> #0 0x7f9066dadd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
> #1 0x7f9066779b5d in qcalloc lib/memory.c:105
> #2 0x556d6ca527c2 in vpn_leak_zebra_vrf_sid_update_per_af bgpd/bgp_mplsvpn.c:389
> #3 0x556d6ca530e1 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:451
> #4 0x556d6ca64b3b in vpn_leak_postchange bgpd/bgp_mplsvpn.h:311
> #5 0x556d6ca64b3b in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3751
> #6 0x556d6cb9f116 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3337
> #7 0x7f906685a6b6 in zclient_read lib/zclient.c:4490
> #8 0x7f9066826a32 in event_call lib/event.c:2011
> #9 0x7f906675c444 in frr_run lib/libfrr.c:1217
> #10 0x556d6c980d52 in main bgpd/bgp_main.c:545
> #11 0x7f9065784c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Fix this by freeing the previous memory chunk.
Fixes: b72c9e14756f ("bgpd: cli for SRv6 SID alloc to redirect to vrf (step4)") Fixes: 527588aa78b2 ("bgpd: add support for per-VRF SRv6 SID") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donatas Abraitis [Wed, 27 Mar 2024 17:08:38 +0000 (19:08 +0200)]
bgpd: Prevent from one more CVE triggering this place
If we receive an attribute that is handled by bgp_attr_malformed(), use
treat-as-withdraw behavior for unknown (or missing to add - if new) attributes.
Donald Sharp [Thu, 28 Mar 2024 16:27:38 +0000 (12:27 -0400)]
bgpd: Arrange peer notification to after zebra announce
Currently BGP attempts to send route change information
to it's peers *before* the route is installed into zebra.
This creates a bug in suppress-fib-pending in the following
scenario:
a) bgp suppress-fib-pending and bgp has a route with
2 way ecmp.
b) bgp receives a route withdraw from peer 1. BGP
will send the route to zebra and mark the route as
FIB_INSTALL_PENDING.
c) bgp receives a route withdraw from peer 2. BGP
will see the route has the FIB_INSTALL_PENDING and
not send the withdrawal of the route to the peer.
bgp will then send the route deletion to zebra and
clean up the bgp_path_info's.
At this point BGP is stuck where it has not sent
a route withdrawal to downstream peers.
Let's modify the code in bgp_process_main_one to
send the route notification to zebra first before
attempting to announce the route. The route withdrawal
will remove the FIB_INSTALL_PENDING flag from the dest
and this will allow group_announce_route to believe
it can send the route withdrawal.
For the master branch this is ok because the recent
backpressure commits are in place and nothing is going
to change from an ordering perspective in that regards.
Ostensibly this fix is also for operators of Sonic and
will be backported to the 8.5 branch as well. This will
change the order of the send to peers to be after the
zebra installation but sonic users are using suppress-fib-pending
anyways so updates won't go out until rib ack has been
received anyways.
Donald Sharp [Thu, 28 Mar 2024 16:25:05 +0000 (12:25 -0400)]
bgpd: Note when receiving but not understanding a route notification
When BGP has been asked to wait for FIB installation, on route
removal a return call is likely to not have the dest since BGP
will have cleaned up the node, entirely. Let's just note that
the prefix cannot be found if debugs are turned on and move on.
Donatas Abraitis [Wed, 27 Mar 2024 16:42:56 +0000 (18:42 +0200)]
bgpd: Fix error handling when receiving BGP Prefix SID attribute
Without this patch, we always set the BGP Prefix SID attribute flag without
checking if it's malformed or not. RFC8669 says that this attribute MUST be discarded.
Also, this fixes the bgpd crash when a malformed Prefix SID attribute is received,
with malformed transitive flags and/or TLVs.
BGP is now keeping a list of dests with the dest having a pointer
to the bgp_path_info that it will be working on.
1) When bgp receives a prefix, process it, add the bgp_dest of the
prefix into the new Fifo list if not present, update the flags (Ex:
earlier if the prefix was advertised and now it is a withdrawn),
increment the ref_count and DO NOT advertise the install/withdraw
to zebra yet.
2) Schedule an event to wake up to invoke the new function which will
walk the list one by one and installs/withdraws the routes into zebra.
a) if BUFFER_EMPTY, process the next item on the list
b) if BUFFER_PENDING, bail out and the callback in
zclient_flush_data() will invoke the same function when BUFFER_EMPTY
Changes
- rename old bgp_zebra_announce to bgp_zebra_announce_actual
- rename old bgp_zebra_withdrw to bgp_zebra_withdraw_actual
- Handle new fifo list cleanup in bgp_exit()
- New funcs: bgp_handle_route_announcements_to_zebra() and
bgp_zebra_route_install()
- Define a callback function to invoke
bgp_handle_route_announcements_to_zebra() when BUFFER_EMPTY in
zclient_flush_data()
The current change deals with bgp installing routes via
bgp_process_main_one()
Since installing/withdrawing routes into zebra is going to be changed
around to be dest based in a list,
- Retrieve the afi/safi to use based upon the dest's afi/safi
instead of passing it in.
- Prefix is known by the dest. Remove this arg as well