Return error if IPv6 address or prefix is passed as an argument
to "show ip route" command.
UT:
r1# show ip route 2::3/128
% Cannot specify IPv6 address/prefix for IPv4 table
r1#
r1# show ip route 2::3
% Cannot specify IPv6 address/prefix for IPv4 table
r1#
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
There is no connectivity by using the proposed srv6 path.
> From Carmine:
> This seg6-route tells rt1 to steer packets destined to fc00:0:9::1 over this path: rt1->rt2->-rt6.
> This path is not correct. Since we are installing this seg6-route on rt1,
> it means that a packet matching this seg6-route has already reached rt1.
> So rt1 should not be part of the path.
> The correct path should be rt2->rt6.
Fix this by changing the proposed seg6 route. Also, the ping test should
be swapped, because invalidating the RT1 locator does not have any
impacts on the built SRv6 path.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
sbfd will use bfdname for key hash, We introduced a bfd-name for every sbfd session, normal BFD sessions can leave it as NULL.
A unique bfd-name can be used to identify a sbfd session quickly. This is quite useful in our Srv6 deployment for path protection case.
For example, if use the sbfd session to protect the SRv6 path A-B-D, we would assign the name 'path-a-b-d' or 'a-b-d' to the session.
Signed-off-by: wumu.zsl <wumu.zsl@alibaba-inc.com>
EVPN imported routes AF is not AF_EVPN, in that case
the path info extra with EVPN is nver created.
In order to create evpn info under path extra, define
new api which does not specifically check for AF_EVPN
afi type.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
draft-uttaro-idr-bgp-oad says:
Extended communities which are non-transitive across an AS boundary MAY be
advertised over an EBGP-OAD session if allowed by explicit policy configuration.
If allowed, all the members of the OAD SHOULD be configured to use the same
criteria.
For example, the Origin Validation State Extended Community, defined as
non-transitive in [RFC8097], can be advertised to peers in the same OAD.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The code doesn't push more than one group (currently) so wouldn't hit the
bug yet, nice catch by coverity.
Signed-off-by: Christian Hopps <chopps@labn.net>
With recent BMP code, on a standard BMP config, the peer up and peer
down messages related to a BGP peer are sent twice, whereas they should
be send only once.
Fix this by better controlling the condition.
Fixes: f8a6933111 ("bgpd: bmp, handle imported bgp instances for peer up/down events")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
