For auto configured value RD value comes as NULL,
switching back to original change will ensure to cover
for both auto and user configured RD value in JSON.
tor-11# show bgp vrf blue ipv4 unicast route-leak json
{
"vrf":"blue",
"afiSafi":"ipv4Unicast",
"importFromVrfs":[
"purple"
],
"importRts":"10.10.3.11:6",
"exportToVrfs":[
"purple"
],
"routeDistinguisher":"(null)", <<<<<
"exportRts":"10.10.3.11:10"
}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Just to make it simpler for compiling with a different default value.
No change to its default value.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Just to make it simpler for compiling with a different default value.
No change to its default value.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.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>
The more the vrf green is referenced in the import bgp command, the more
there are instances created. The below configuration shows that the vrf
green is referenced twice, and two BGP instances of vrf green are
created.
The below configuration:
> router bgp 99
> [..]
> import vrf green
> exit
> router bgp 99 vrf blue
> [..]
> import vrf green
> exit
> router bgp 99 vrf green
> [..]
> exit
>
> r4# show bgp vrfs
> Type Id routerId #PeersCfg #PeersEstb Name
> L3-VNI RouterMAC Interface
> DFLT 0 10.0.3.4 0 0 default
> 0 00:00:00:00:00:00 unknown
> VRF 5 10.0.40.4 0 0 blue
> 0 00:00:00:00:00:00 unknown
> VRF 6 0.0.0.0 0 0 green
> 0 00:00:00:00:00:00 unknown
> VRF 6 10.0.94.4 0 0 green
> 0 00:00:00:00:00:00 unknown
Fix this at import command, by looking at an already present bgp
instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.
> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
> #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x7f358e877233 in qcalloc lib/memory.c:106
> #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
> #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
> #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
> #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
> #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
> #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
> #8 0x7f358e98082d in event_call lib/event.c:1996
> #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
> #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
> #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.
Fixes: f153b9a9b6 ("bgpd: Ignore auto created VRF BGP instances")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Related: https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability
TL;DR; use 16 bytes long next-hops for point-to-point (unnumbered) links instead
of sending 32 bytes (::/LL, GUA/LL, LL/LL combinations).
For backward compatiblity we should handle even 32 bytes existing next hops.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
FRR supports dynamic capability which is useful to exchange the capabilities
without tearing down the session. ENHE capability was missed to be included
handling via dynamic capability. Let's add it too.
This was missed and asked in Slack that it would be useful.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
su_local and su_remote in the peer can change based upon
if we are initiating the remote connection or receiving it.
As such we need to treat it as a property of the connection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the route distinguisher set to 0:0.
Actually, the route distinguisher has been updated after the peer up
message is sent, and the information is not refreshed.
Create a hook API to handle route distinguisher config events: pre and
post configuration. Use that hook in BMP module to send peer down, and
peer up events when necessary.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
Releasing the vpn label from label pool chunk using bgp_lp_release routine whenever vpn session is removed.
bgp_lp_release will clear corresponding bit in the allocated map of the label pool chunk and increases nfree by 1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Anytime BGP gets a L3 VNI ADD/DEL from zebra,
- Walking the entire global routing table per L3VNI is very expensive.
- The next read (say of another VNI ADD/DEL) from the socket does
not proceed unless this walk is complete.
So for triggers where a bulk of L3VNI's are flapped, this results in
huge output buffer FIFO growth spiking up the memory in zebra since bgp
is slow/busy processing the first message.
To avoid this, idea is to hookup the BGP-VRF off the struct bgp_master
and maintain a struct bgp FIFO list which is processed later on, where
we walk a chunk of BGP-VRFs and do the remote route install/uninstall.
Ticket :#3864372
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>
if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status))
peer_notify_config_change(peer->connection);
else
bgp_session_reset_safe(peer, &nnode);
Let's add a bool return to peer_notify_config_change of whether or
not it should call the peer session reset. This simplifies
the code a bunch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We have about a bajillion tests of if we can
notify the peer and then we send a config change
notification. Let's just make a function that
does this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Deprecate gracefulRestartCapability which is inconsistent with an existing
format if advertised and received are printed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Slipped somehow that peer-groups with GR is just completely broken, but it was
working before.
Strikes again, that we MUST have more and more topotests.
Fixes: 15403f521a ("bgpd: Streamline GR config, act on change immediately")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This command did not allow the operator to display neighbor information
related to graceful-restart when used inside of a vrf.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Recent commit 4d0e7a49cf
brought in changes that moved a check for ret up
in the code, caused some code to be left around
and be effectively dead since it would never be called.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Introduce a command to stop bgpd from enabling IPv6 router advertisement
messages sending on interfaces.
Signed-off-by: Mikhail Sokolovskiy <sokolmish@gmail.com>
1. bgp coredump is observed when we delete default bgp instance
when we have multi-vrf; and route-leaking is enabled between
default, non-default vrfs.
Removing default router bgp when routes leaked between non-default vrfs.
- Routes are leaked from VRF-A to VRF-B
- VPN table is created with auto RD/RT in default instance.
- Default instance is deleted, we try to unimport the routes from all VRFs
- non-default VRF schedules a work-queue to process deleted routes.
- Meanwhile default bgp instance clears VPN tables and free the route
entries as well, which are still referenced by non-default VRFs which
have imported routes.
- When work queue process starts to delete imported route in VRF-A it cores
as it accesses freed memory.
- Whenever we delete bgp in default vrf, we skip deleting routes in the vpn
table, import and export lists.
- The default hidden bgp instance will not be listed in any of the show
commands.
- Whenever we create new default instance, handle it with AS number change
i.e. old hidden default bgp's AS number is updated and also changing
local_as for all peers.
2. A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- First problem with current behavior.
Define two vrfs with different ASNs and then add import between.
starting without any bgp config (no default instance)
A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- Second related problem. Start with a default instance and a vrf in a
different ASN. Do an import statement in the vrf for a bgp vrf instance
not yet defined and it auto-creates that bgp/vrf instance and it inherits
the ASN of the importing vrf
- Handle bgp instances with different ASNs and handle ASN for auto created
BGP instance
Signed-off-by: Kantesh Mundaragi <kmundaragi@vmware.com>
