bgpd: Do not process VRF import/export to/from auto created VRF instances
Fixes the crash:
```
(gdb) bt
0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:44
1 __pthread_kill_internal (signo=11, threadid=124583315603008) at ./nptl/pthread_kill.c:78
2 __GI___pthread_kill (threadid=124583315603008, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
3 0x0000714ed0242476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
4 0x0000714ed074cfb7 in core_handler (signo=11, siginfo=0x7ffe6d9792b0, context=0x7ffe6d979180) at lib/sigevent.c:258
5 <signal handler called>
6 0x000060f55e33ffdd in route_table_get_info (table=0x0) at ./lib/table.h:177
7 0x000060f55e340053 in bgp_dest_table (dest=0x60f56dabb840) at ./bgpd/bgp_table.h:156
8 0x000060f55e340c9f in is_route_injectable_into_vpn (pi=0x60f56dbc4a60) at ./bgpd/bgp_mplsvpn.h:331
9 0x000060f55e34507c in vpn_leak_from_vrf_update (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, path_vrf=0x60f56dbc4a60) at bgpd/bgp_mplsvpn.c:1575
10 0x000060f55e346657 in vpn_leak_from_vrf_update_all (to_bgp=0x60f56da52070, from_bgp=0x60f56da75af0, afi=AFI_IP) at bgpd/bgp_mplsvpn.c:2028
11 0x000060f55e340c10 in vpn_leak_postchange (direction=BGP_VPN_POLICY_DIR_TOVPN, afi=AFI_IP, bgp_vpn=0x60f56da52070, bgp_vrf=0x60f56da75af0) at ./bgpd/bgp_mplsvpn.h:310
12 0x000060f55e34a692 in vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3737
13 0x000060f55e3d91fc in router_bgp (self=0x60f55e5cbc20 <router_bgp_cmd>, vty=0x60f56e2d7660, argc=3, argv=0x60f56da19830) at bgpd/bgp_vty.c:1601
14 0x0000714ed069ddf5 in cmd_execute_command_real (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, up_level=0) at lib/command.c:1002
15 0x0000714ed069df6e in cmd_execute_command (vline=0x60f56da32a80, vty=0x60f56e2d7660, cmd=0x0, vtysh=0) at lib/command.c:1061
16 0x0000714ed069e51e in cmd_execute (vty=0x60f56e2d7660, cmd=0x60f56dbf07d0 "router bgp 100\n", matched=0x0, vtysh=0) at lib/command.c:1227
17 0x0000714ed076faa0 in vty_command (vty=0x60f56e2d7660, buf=0x60f56dbf07d0 "router bgp 100\n") at lib/vty.c:616
18 0x0000714ed07719c4 in vty_execute (vty=0x60f56e2d7660) at lib/vty.c:1379
19 0x0000714ed07740f0 in vtysh_read (thread=0x7ffe6d97c700) at lib/vty.c:2374
20 0x0000714ed07685c4 in event_call (thread=0x7ffe6d97c700) at lib/event.c:1995
21 0x0000714ed06e3351 in frr_run (master=0x60f56d1d2e40) at lib/libfrr.c:1232
22 0x000060f55e2c4b44 in main (argc=7, argv=0x7ffe6d97c978) at bgpd/bgp_main.c:555
(gdb)
```
Donald Sharp [Fri, 26 Jul 2024 18:15:40 +0000 (14:15 -0400)]
tests: Fix test_bgp_vpnv6_per_nexthop_label.py to handle timing changes
So the test script is making changes to a vpn configuration by
changing something fundamental about the vpn. This is causing
a window where routes we are interested in are:
present ( from pre-change ) then
withdrawn ( the test change causes this ) then
present ( with the new data )
The test code was trying to test for this by checking
to see if the prefix was there, but due to timing issues
it's not always there when we look for it.
Modify the test to get the vpn table version prior to
the change( as that it should not be moving around ) and
then change the test for the prefix to look for a version
that is later than the vpn's table version. Then we know
that it is *after* everything has stabilized again.
Donald Sharp [Fri, 26 Jul 2024 18:02:31 +0000 (14:02 -0400)]
tests: Fix test_bgp_vpnv4_per_nexthop_label.py to handle timing changes
So the test script is making changes to a vpn configuration by
changing something fundamental about the vpn. This is causing
a window where routes we are interested in are:
present ( from pre-change ) then
withdrawn ( the test change causes this ) then
present ( with the new data )
The test code was trying to test for this by checking
to see if the prefix was there, but due to timing issues
it's not always there when we look for it.
Modify the test to get the vpn table version prior to
the change( as that it should not be moving around ) and
then change the test for the prefix to look for a version
that is later than the vpn's table version. Then we know
that it is *after* everything has stabilized again.
Louis Scalbert [Thu, 25 Jul 2024 07:34:10 +0000 (09:34 +0200)]
isisd: fix building asla at first flex-algo config
When an color affinity is set on an interface before configuring the
flex-algorithm, the ASLA (Application Specific Link-Attribute) sub-TLV
is not build. Flex-algo fails to build the paths when a affinity
constraint is required because of the lacking of information contained
in ASLA. There are no problems when the configuration order is reversed.
For example:
> affinity-map red bit-position 1
>
> interface eth2
> link-params
> affinity red
>
> router isis 1
> mpls-te on
> flex-algo 129
> dataplane sr-mpls
> advertise-definition
> affinity include-any green
In isis_link_params_update_asla(), the ASLA sub-TLV is not build when
the list of flex-algos is empty.
Update ASLA when the first flex-algorithm is configured.
bgpd: Keep the last reset reason before we reset the peer
If we send a notification, there is no point setting the last_reset, because
bgp_notify_send() sets last_reset to PEER_DOWN_NOTIFY_SEND (almost everywhere).
bgpd: Set the last_reset if we change the password also
```
donatas.net(config-router)# do show ip bgp summary failed
IPv4 Unicast Summary:
BGP router identifier 1.1.1.1, local AS number 65001 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 24 KiB of memory
Under some circumstances it might happen that the session is quickly UP in the
middle of `clear bgp ...` and `shutdown`. That leads to session be UP, and
the stale routes being cleared quickly.
Christian Hopps [Tue, 23 Jul 2024 21:42:07 +0000 (17:42 -0400)]
lib: mgmtd: fix too early daemon detach of mgmtd
Correct FRR startup counts on a daemon's vty socket to be open when the
parent process exits. The parent process waits for `frr_check_detach()`
to be called by the child before exiting. The problem is when the
`FRR_MANUAL_VTY_START` flag is set the vty socket was not opened but
`frr_check_detach()` was called anyway.
Instead add a bool option for `frr_check_detach()` to be called when the
socket is opened with `frr_vty_serv_start()`, and do so when "manually"
calling said function (i.e., when FRR_MANUAL_VTY_START is set).
The `FRR_MANUAL_VTY_START` flag is only set by mgmtd. The reason we
wait to open the vty socket is so that mgmtd can parse the various
daemon specific config files it has taken over, after the event loop has
started, but before we receive any possible new config from `vtysh`.
David Lamparter [Tue, 23 Jul 2024 17:21:42 +0000 (10:21 -0700)]
build: fix a few python string escape warnings
When using a regex (or anything that uses `\?` escapes) in python, raw
strings (`r"content"`) should be used so python doesn't consume the
escapes itself. Otherwise we get either broken behavior and/or
`SyntaxWarning: invalid escape sequence '\['`
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Rajasekar Raja [Mon, 22 Jul 2024 17:13:19 +0000 (10:13 -0700)]
bgpd: backpressure - Avoid use after free
Coverity complains there is a use after free (1598495 and 1598496)
At this point, most likely dest->refcount cannot go 1 and free up
the dest, but there might be some code path where this can happen.
Fixing this with a simple order change (no harm fix).
Rajasekar Raja [Wed, 17 Jul 2024 06:34:15 +0000 (23:34 -0700)]
bgpd: backpressure - fix ret value evpn_route_select_install
The return value of evpn_route_select_install is ignored in all cases
except during vni route table install/uninstall and based on the
returned value, an error is logged. Fixing this.
Dave LeRoy [Thu, 18 Jul 2024 17:19:30 +0000 (10:19 -0700)]
nhrpd: Fixes auth no redirect bug
The nhrp_peer_forward() routine was not explicitly handling the
Authentication Extension in the switch statement and instead fell
through to the default case which checked whether this was an
unhandled Compulsory extension and errored out, never forwarding
the Resolution Request.
Dave LeRoy [Wed, 17 Jul 2024 17:37:44 +0000 (10:37 -0700)]
nhrpd: Fixes auth config change bug
Freeing auth-token does not set nifp->auth_token to NULL.
Explicitly set auth_token to NULL when deleting auth config in order
for write config logic to succeed.
Loïc Sang [Wed, 17 Jul 2024 12:40:09 +0000 (14:40 +0200)]
bgpd: do not update leak label at loopback up down
The up/down state of the lo loopback interface does not determine the
availability of the default vrf-lite.
Do not update leak label at lo loopback up/down change.
Fixes: b45c5cd959 ("bgpd: update route leak when vrf state changes") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Loïc Sang <loic.sang@6wind.com>
Loïc Sang [Tue, 16 Jul 2024 12:03:11 +0000 (14:03 +0200)]
bgpd: fix label lost when vrf loopback comes back
VRF-label association drops when the VRF loopback goes down, however, it
does not return once the interface is enabled again.
Logs show that when VRF loopback goes down, a label drop message is sent
to zebra and immediately resent label installation to zebra, trigged by
"vpn_leak_postchange_all()":
2024/07/16 13:26:29 BGP: [RVJ1J-J2T22] ifp down r1-cust1 vrf id 7
2024/07/16 13:26:29 BGP: [WA2QY-06STJ] vpn_leak_zebra_vrf_label_withdraw: deleting label for vrf VRF r1-cust1 (id=7)
2024/07/16 13:26:30 BGP: [S82AC-6YAC8] vpn_leak_zebra_vrf_label_update: vrf VRF r1-cust1: afi IPv4: setting label 80 for vrf id 7
Since the interface is down, the netlink message is not send to kernel.
Once the interface comes back, zebra ignore the installation assuming
the label is already seen.
To fix this, add a check for the interface status before attempting to
reinstall the label.
ospfd: fix internal ldp-sync state flags when feature is disabled
When enabling "mpls ldp-sync" under "router ospf" ospfd configures
SET_FLAG(ldp_sync_info->flags, LDP_SYNC_FLAG_IF_CONFIG) so internally knowing
that the ldp-sync feature is enabled. However the flag is not cleared when
turning of the feature using "nompls ldp-sync"!
https://github.com/FRRouting/frr/issues/16375
Signed-off-by: Christian Breunig <christian@breunig.cc>