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>
Some bgp evpn memory contexts are not freed at the end of the bgp
process.
> =================================================================
> ==1208677==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 96 byte(s) in 2 object(s) allocated from:
> #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
> #1 0x7f93ace77233 in qcalloc lib/memory.c:106
> #2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084
> #3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302
> #4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347
> #5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482
> #6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091
> #7 0x7f93acf8082d in event_call lib/event.c:1996
> #8 0x7f93ace48931 in frr_run lib/libfrr.c:1232
> #9 0x563bb6880ae1 in main bgpd/bgp_main.c:557
> #10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Actually, the bgp evpn context may noy be used if adj rib in is unused.
This may lead to memory leaks. Fix this by freeing the context in those
corner cases.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When not configuring a route distinguisher, neither route-target,
the derived rd settings differ if config load applies with frr.conf
or not. For instance, the forged rd with frr.conf:
> # show bgp l2vpn evpn json
> "192.168.101.41:3":{
> "rd":"192.168.101.41:3",
and without:
> "192.168.101.41:2":{
> "rd":"192.168.101.41:2",
The defined rts also are impacted. Temporay fix this by using an
hardset configuration for all route distinguisher and route target
of the setups.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test that ensures that the 'match evpn vni' command works with bgp
evpn rt5 updates.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Issue:
During FRR restart, we fail to add some of the local interface's MAC
to the 'bgp mac hash'. Not having local MAC in the hash table can cause
lookup issues while receiving EVPN RT-2.
Currently, we have code to add local MAC(bgp_mac_add_mac_entry) while handling
interface add/up events in BGP(bgp_ifp_up/bgp_ifp_create). But the code
'bgp_mac_add_mac_entry' in bgp_ifp_create is not getting invoked as it
is placed under a specific check(vrf->bgp link check).
Fix:
We can skip this check 'vrf->bgp link existence' as the tenant VRF might
not have BGP instance but still we want to cache the tenant VRF local
MACs. So keeping this check in bgp_ifp_create inline with bgp_ifp_up.
Ticket: #4204154
Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com>
Add a test to control the json values of the incoming BGP update
received by an unnumbered BGP.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The 'show bgp ipv[4,6] json' command does not display the interface
value of the nexthop, when BGP sessions are unnumbered, whereas the
non json output displays it correctly. The below example indicates
'r1-eth0' wheras in json, the value is not displayed.
> r1# show bgp ipv4
> BGP table version is 3, local router ID is 10.254.254.1, vrf id 0
> Default local pref 100, local AS 101
> Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
> i internal, r RIB-failure, S Stale, R Removed
> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
> Origin codes: i - IGP, e - EGP, ? - incomplete
> RPKI validation codes: V valid, I invalid, N Not found
>
> Network Next Hop Metric LocPrf Weight Path
> *> 10.254.254.1/32 0.0.0.0 0 32768 ?
> *> 10.254.254.2/32 r1-eth0 0 0 102 ?
>
> Displayed 2 routes and 2 total paths
Fix this by adding an 'interface' keyword in the json attributes.
> "nexthops":[{"ip":"2001:db8:1::2","hostname":"r2","afi":"ipv6",
> "scope":"global"},{"interface":"r1-eth0","ip":"fe80::1868:d7ff:fe66:45ae",
> "hostname":"r2","afi":"ipv6","scope":"link-local","used":true}]}]
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When support for new style `get()` was added inadvertently stopped
generating other callbacks and prototypes. Fix this.
Signed-off-by: Christian Hopps <chopps@labn.net>
Move checking if the peer is active only after we apply defaults for address
families.
If the family got activated after applying the defaults we should reset last_reset
reason.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is actually not reset, and should be ignored showing it as last reset
under `show bgp neighbor`.
Fixes: 1e91f1d119 ("bgpd: Update failed reason to distinguish some NHT scenario")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The previous use of `lyd_new_path()` returns the first node created, rather
than the xpath target node. The code is lucky in the sense that it is
normally only creating a single node rather than a branch. Fix this to
use `lyd_new_path2()` which returns the target node to actually implement
the semantics expected by callers of `dnode_create()` (i.e., returning the
newly created target node).
Signed-off-by: Christian Hopps <chopps@labn.net>
Drop redundant function (duplicate), and reset counters for r2 instead of r1.
We check received capabilities on r2, hence we need to flush the counters on r2 too.
Fixes: d1cfd73060 ("tests: Check if ENHE capability can be handled dynamically")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
- Previously we sent selectors to all backends when a replace was
done, improve this to only send them to backends that provide
the selected state.
Signed-off-by: Christian Hopps <chopps@labn.net>
This is similar to notify and RPC parsers, but this is for normal datastore
data. This is initially used in handling datastore notifications being sent to
another backend client[s].
Signed-off-by: Christian Hopps <chopps@labn.net>
This commit moves DEFAULT_SRV6_IFNAME from isis_srv6.h to srv6.h
because there are other daemons that might want to use it (e.g. staticd).
Signed-off-by: Yuqing Zhao <galadriel.zyq@alibaba-inc.com>
This commit adds datastructures and helper functions required to support SRv6 in staticd.
* List of locators
* List of SIDs
* Data structure to represent an SRv6 SID
* Functions to allocate/deallocate an SRv6 SID
* Functions to allocate, deallocate and lookup a locator
* Function to initialize/Cleanup SRv6
Signed-off-by: Yuqing Zhao <galadriel.zyq@alibaba-inc.com>
Sometimes it's very useful to compare pointers from the gdb (and/or from the
logs) or just do some quick adhoc analysis.
```
donatas# sh ip bgp 1.1.1.0/24 internal
BGP routing table entry for 1.1.1.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
65002
127.0.0.1 (inaccessible, import-check enabled) from 127.0.0.1 (127.0.0.2)
Origin IGP, invalid, external
Last update: Thu Jan 16 16:49:53 2025
net: 0x63f3e6fc2ea0, path: 0x63f3e6fc2f50, pathext: 0x63f3e6faed00, attr: 0x63f3e6e8c550
flags net: 0x0, path: 0x1024, attr: 0x7
donatas#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The dg_update_list access is controlled by the dg_mutex in all
other locations. Let's just add a mutex usage around the initialization
of the dg_update_list even if it's part of the startup, just to keep
things consistent.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
