Commit Graph

1607 Commits

Author SHA1 Message Date
Rajasekar Raja
795bef98db bgpd: Fixing the show bgp <vrf> <afi> <safi> detail command
Adding support to show cmds like  show bgp vrf all detail, show bgp
<afi> <safi> detail & show bgp <vrf> <afi> <safi> detail

Issue:3168406
Ticket:#3168406

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2023-05-05 00:01:21 -07:00
Donatas Abraitis
786e2b8bdb Revert "MPLS allocation mode per next hop"
Broken tests, let's revert now.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-05-03 13:52:46 +03:00
Donatas Abraitis
99a1ab0b21
Merge pull request #12646 from pguibert6WIND/mpls_alloc_per_nh
MPLS allocation mode per next hop
2023-05-02 18:36:45 +03:00
Philippe Guibert
cf1c7e309e bgpd: configure explicit-null for local paths per address family
Until now, the bgp local paths were using the default null label
defined. It was not possible to select the null label for the ipv4
or the ipv6 address families.

This commit addresses this issues by adding two extra-parameters
to the BGP labeled-unicast command.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-04-27 17:05:35 +02:00
Donatas Abraitis
34a8441fe8
Merge pull request #13386 from donaldsharp/bgp_received_routes
bgpd: Fix `received-routes detail`
2023-04-26 11:07:00 +03:00
Donald Sharp
24dede9b30 bgpd: Fix received-routes detail
The command `show bgp ipv4 uni neigh A.B.C.D received-routes detail`
was not displaying anything.

Fix the code to display the received routes from the ones that
have been filtered.  In this case we need to fudge up a bgp_dest
and a bgp_path_info to make it work.

Old output:

janelle.pinkbelly.org# show bgp ipv4 uni neighbors 192.168.119.224 received-routes detail
BGP table version is 1711405, local router ID is 192.168.44.1, vrf id 0
Default local pref 100, local AS 64539

Total number of prefixes 3 (3 filtered)
janelle.pinkbelly.org#

New output:

janelle.pinkbelly.org# show bgp ipv4 uni neighbors 192.168.119.224 received-routes detail
BGP table version is 0, local router ID is 192.168.44.1, vrf id 0
Default local pref 100, local AS 64539
BGP routing table entry for 1.2.3.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  3291, (aggregated by 3291 192.168.122.1)
    192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
      Origin IGP, metric 0, invalid, external, atomic-aggregate, rpki validation-state: not found
      Community: 55:66
      Last update: Fri Apr 14 08:46:48 2023
BGP routing table entry for 1.2.3.4/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  3291
    192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
      Origin IGP, metric 0, invalid, external, rpki validation-state: not found
      Community: 33:44
      Last update: Fri Apr 14 08:46:48 2023
BGP routing table entry for 1.2.3.5/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  3291
    192.168.119.224 (inaccessible, import-check enabled) from 192.168.119.224 (192.168.122.1)
      Origin IGP, metric 0, invalid, external, rpki validation-state: not found
      Community: 33:44
      Last update: Fri Apr 14 08:46:48 2023

Total number of prefixes 3 (3 filtered)
janelle.pinkbelly.org# show bgp ipv4 uni
No BGP prefixes displayed, 0 exist
janelle.pinkbelly.org#

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-04-25 15:37:02 -04:00
Russ White
4855ca5e56
Merge pull request #13310 from opensourcerouting/feature/bgpd_node_target_extended_community
bgpd: Add Node Target Extended Communities support
2023-04-25 11:06:23 -04:00
Donald Sharp
852f96eb03 bgpd: All paths have already de-refed rd_str
Coverity points out that rd_str has already been
deref'ed in all paths leading to this spot.  No
need to keep at it.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-04-21 07:54:00 -04:00
Pooja Jagadeesh Doijode
6e076ba523 bgpd: Fix for ain->attr corruption during path update
1. Consider a established L2VPN EVPN BGP peer with soft-reconfiguartion
   inbound configured

2. When the interface of this directly connected BGP peer is shutdown,
   bgp_soft_reconfig_table_update() is called, which memsets the evpn buffer
   and calls bgp_update() with received attributes stored in ain table(ain->attr).
   In bgp_update(), evpn_overlay attribute in ain->attr (which is an interned
   attr) was modified by doing a memcpy

3. Above action causes 2 attributes in the attrhash (which were previously different)
   to match!

4. Later during fsm change event of the peer, bgp_adj_in_remove() is called
   to clean up the ain->attr. But, because 2 attrs in attrhash match, it causes
   BGP to assert in bgp_attr_unintern()

Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
2023-04-18 18:40:06 -07:00
Donatas Abraitis
c9a2561444 bgpd: Implement Node Target Extended Communities
kttps://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm

unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.2 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * 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.10.10.10/32   0.0.0.0                  0         32768 i

Total number of prefixes 1

unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.3 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes:  s suppressed, d damped, h history, * 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.10.10.10/32   0.0.0.0                  0         32768 i

Total number of prefixes 1

unet> sh r2 vtysh -c 'show ip bgp 10.10.10.10/32'
% Network not in table

unet> sh r3 vtysh -c 'show ip bgp 10.10.10.10/32'
BGP routing table entry for 10.10.10.10/32, version 1
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  192.168.1.1
  65001
    192.168.1.1 from 192.168.1.1 (192.168.1.1)
      Origin IGP, metric 0, valid, external, best (First path received)
      Extended Community: NT:192.168.1.3 NT:192.168.1.4
      Last update: Tue Apr 11 23:19:33 2023

unet>

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-04-14 21:04:40 +03:00
Donatas Abraitis
ea5a8e4d58 bgpd: Fix crash for show bgp ... neighbor received-routes detail|PREFIX
BGP: Received signal 11 at 1681287514 (si_addr 0x8, PC 0x559ab42eb1d9); aborting...
BGP: /lib/libfrr.so.0(zlog_backtrace_sigsafe+0x71) [0x7f4356b19af1]
BGP: /lib/libfrr.so.0(zlog_signal+0xf9) [0x7f4356b19cf9]
BGP: /lib/libfrr.so.0(+0xf5af5) [0x7f4356b4baf5]
BGP: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f43568ab420]
BGP: /usr/lib/frr/bgpd(prefix_rd2str+0x29) [0x559ab42eb1d9]
BGP: /usr/lib/frr/bgpd(route_vty_out_detail_header+0x7ca) [0x559ab43061ba]
BGP: /usr/lib/frr/bgpd(+0x1771a6) [0x559ab430a1a6]
BGP: /usr/lib/frr/bgpd(+0x177f06) [0x559ab430af06]
BGP: /usr/lib/frr/bgpd(+0x178c8b) [0x559ab430bc8b]
BGP: /usr/lib/frr/bgpd(+0x179e7e) [0x559ab430ce7e]
BGP: /lib/libfrr.so.0(+0x9417e) [0x7f4356aea17e]
BGP: /lib/libfrr.so.0(cmd_execute_command+0x111) [0x7f4356aea321]
BGP: /lib/libfrr.so.0(cmd_execute+0xd0) [0x7f4356aea4c0]
BGP: /lib/libfrr.so.0(+0x10d5de) [0x7f4356b635de]
BGP: /lib/libfrr.so.0(+0x10d81d) [0x7f4356b6381d]
BGP: /lib/libfrr.so.0(+0x110b03) [0x7f4356b66b03]
BGP: /lib/libfrr.so.0(event_call+0x81) [0x7f4356b5df91]
BGP: /lib/libfrr.so.0(frr_run+0xe8) [0x7f4356b11b58]
BGP: /usr/lib/frr/bgpd(main+0x385) [0x559ab4281d55]
BGP: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f43566c9083]
BGP: /usr/lib/frr/bgpd(_start+0x2e) [0x559ab428437e]
BGP: in thread vtysh_read scheduled from lib/vty.c:2833 vty_event()

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-04-13 23:37:06 +03:00
Philippe Guibert
f8141f4a65 bgpd: fix bgp label value when static route used
The BGP local label value is not re-set when the prefix
is either a network or an aggregate prefix. Ensure to
get the appropriate label value each time the 'need_imp_null_label()'
function has to return true.

Fixes: 7ee70320d3 ("bgpd: add cli command to control explicit-null label usage")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-04-12 17:45:48 +02:00
Philippe Guibert
7ee70320d3 bgpd: add cli command to control explicit-null label usage
In BGP labeled unicast address-family, it is not possible to
send explicit-null label values with redistributed or network
declared prefixes.
A new CLI command is introduced:

  > [no] bgp labeled-unicast explicit-null

When used, the explicit-null value for IPv4 ('0' value) or
IPv6 ('2' value) will be used.
It is necessary to reconfigure the networks or the
redistribution in order to inherit this new behaviour.

Add the documentation.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-04-11 16:08:09 +02:00
Trey Aspelund
8ed85db65c bgpd: add comments for 'json detail' show cmd code
The json structure changes used for 'json detail' show commands are not
very straightforward and might require code analysis to understand.
This addscommentary to the flow to explain the change in structure.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-03-31 22:40:54 +00:00
Donatas Abraitis
5d5de88256
Merge pull request #13148 from samanvithab/bgp_mem_leak_fix
bgpd : memory leak fix for aggregate-address on cleanup
2023-03-31 09:25:44 +03:00
Jafar Al-Gharaibeh
277eb2e580
Merge pull request #13060 from opensourcerouting/feature/allow_peering_with_127.0.0.1
bgpd: Allow peering via 127.0.0.0/8
2023-03-31 00:14:27 -05:00
Samanvitha B Bhargav
7a70d99038 bgpd : aggregate-address memory leak fix
Memory leaks are observed in the cleanup code. When “no router bgp" is executed,
cleanup in that flow for aggregate-address command is not taken care.

fixes the below leak:
    --
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #4 0x562bf42f1e55 in aggregate_addressv6_magic bgpd/bgp_route.c:8592
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #5 0x562bf42be3f5 in aggregate_addressv6 bgpd/bgp_route_clippy.c:341
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #12 0x7f163e593f16 in event_call lib/event.c:1995
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #14 0x562bf414e58d in main bgpd/bgp_main.c:505
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444:Direct leak of 152 byte(s) in 1 object(s) allocated from:
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #0 0x7f163e911037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #1 0x7f163e4b9259 in qcalloc lib/memory.c:105
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #2 0x562bf42ebbd5 in bgp_aggregate_new bgpd/bgp_route.c:7239
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #3 0x562bf42f14e8 in bgp_aggregate_set bgpd/bgp_route.c:8421
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #4 0x562bf42f1cde in aggregate_addressv4_magic bgpd/bgp_route.c:8543
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #5 0x562bf42bd258 in aggregate_addressv4 bgpd/bgp_route_clippy.c:255
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #6 0x7f163e3f1e1b in cmd_execute_command_real lib/command.c:988
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #7 0x7f163e3f219c in cmd_execute_command lib/command.c:1048
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #8 0x7f163e3f2df4 in cmd_execute lib/command.c:1215
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #9 0x7f163e5a2d73 in vty_command lib/vty.c:544
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #10 0x7f163e5a79c8 in vty_execute lib/vty.c:1307
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #11 0x7f163e5ad299 in vtysh_read lib/vty.c:2216
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #12 0x7f163e593f16 in event_call lib/event.c:1995
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #13 0x7f163e47c839 in frr_run lib/libfrr.c:1185
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #14 0x562bf414e58d in main bgpd/bgp_main.c:505
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-    #15 0x7f163de66d09 in __libc_start_main ../csu/libc-start.c:308
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-
    ./bgp_local_asn_dot.test_bgp_local_asn_dot_agg/r3.bgpd.asan.3410444-SUMMARY: AddressSanitizer: 304 byte(s) leaked in 2 allocation(s).

Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
2023-03-30 00:19:20 -07:00
Donald Sharp
8e8ed2e1fb bgpd: Fix debug output for route-map names when using a unsuppress-map
Log is printing this with this config:

2023-03-28 07:36:47.007 [DEBG] bgpd: [Q9J6Z-09HRR] 192.168.119.120 [Update:SEND] 1.2.3.33/32 is filtered by route-map '(null)'

Here's the config:

 address-family ipv4 unicast
  network 1.2.3.33/32
  network 1.2.3.34/32
  aggregate-address 1.2.3.0/24 summary-only
  redistribute table 33 route-map foo
  neighbor 192.168.119.120 route-map DENY in
  neighbor 192.168.119.120 unsuppress-map UNSUPPRESS

ip prefix-list UNSUPPRESS seq 5 permit 1.2.3.4/32
ip prefix-list UNSUPPRESS seq 10 permit 1.2.3.5/32
ip prefix-list UNSUPPRESS seq 15 permit 1.2.3.6/32

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-28 08:34:24 -04:00
Donatas Abraitis
c4e3d5569f
Merge pull request #13086 from donaldsharp/suppress_fib_pending
bgpd: Ensure suppress-fib-pending works with network statements
2023-03-27 21:55:58 +03:00
Donatas Abraitis
6cddc4c866 bgpd: Allow self next-hop if bgp allow-martian-nexthop is enabled
For instance, if we receive the routes from the peer with the next-hop as me,
but those routes shares the same network, we can fake the next-hop.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-24 14:42:38 +02:00
Donald Sharp
24a58196dd *: Convert event.h to frrevent.h
We should probably prevent any type of namespace collision
with something else.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
e16d030c65 *: Convert THREAD_XXX macros to EVENT_XXX macros
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
4f830a0799 *: Convert thread_timer_remain_XXX to event_timer_remain_XXX
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
8c1186d38e *: Convert thread_execute to event_execute
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
907a2395f4 *: Convert thread_add_XXX functions to event_add_XXX
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
e6685141aa *: Rename struct thread to struct event
Effectively a massive search and replace of
`struct thread` to `struct event`.  Using the
term `thread` gives people the thought that
this event system is a pthread when it is not

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:17 -04:00
Donald Sharp
cb37cb336a *: Rename thread.[ch] to event.[ch]
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system.  There is a continual
problem where people are confusing `struct thread` with a true
pthread.  In reality, our entire thread.c is an event system.

In this commit rename the thread.[ch] files to event.[ch].

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24 08:32:16 -04:00
Donatas Abraitis
6927446645
Merge pull request #13074 from donaldsharp/hash_clean_and_free
*: Add a hash_clean_and_free() function
2023-03-23 14:08:29 +02:00
Donald Sharp
3fdb2079f6 bgpd: Ensure suppress-fib-pending works with network statements
The flag for telling BGP that a route is expected to be installed
first before notifying a peer was always being set upon receipt
of a path that could be accepted as bestpath.  This is not correct:
imagine that you have a peer sending you a route and you have a
network statement that covers the same route.  Irrelevant if the
network statement would win the flag on the dest was being set
in bgp_update.  Thus you could get into a situation where
the network statement path wins but since the flag is set on
the node, it will never be announced to a peer.

Let's just move the setting of the flag into bgp_zebra_announce
and _withdraw.  In _announce set the flag to TRUE when suppress-fib
is enabled.  In _withdraw just always unset the flag as that a withdrawal
does not need to wait for rib removal before announcing.  This will
cover the case when a network statement is added after the route has
been learned from a peer.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-22 11:35:28 -04:00
Philippe Guibert
f8ac50d4b6 bgpd: correctly initialize the IP nexthop of redistributed routes
This is a preliminary work to export redistributed routes from
a given VRF in an VPN network. The exportation works well, when
the label allocation is based on an per-vrf mode, but not on
a per nexthop mode.

To associate a label with a connected nexthop, the nexthop
tracking contexts are used. Until today, there was no tracking
context for redistributed routes. But when using this vpn
allocation mode, one needs to know whether the route is directly
connected or not. When using the nexthop tracking context, the
nexthop attribute of the bgp update needs to have the nexthop
properly set. This was not the case for the mp_nexthop_global_in
attribute which was empty.

This commit is mandatory in order to later use nexthop tracking
context.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-03-22 12:06:29 +01:00
Philippe Guibert
f081a1924c bgpd: remove ATTR_NEXT_HOP for redistributed ipv6 nexthops
This commit addresses an issue with an MPLS VPN network
redistributing static routes that are exported to the VPN,
and where the labels are allocated per next-hop.

For that purpose, the nexthop of the static routes is
checked against the nexthop tracking. The validation
of a valid nexthop will trigger the use of a unique
label for all prefixes using that destination.

However, the nexthop fails to be validated, with the
following message:

 > evaluate_paths: prefix 172:31::14/128 (vrf vrf1), ignoring path due to
 > martian or self-next-hop

The reason is due to the way the attr is created.
By default, the ATTR_NEXTHOP attribute is set for
all prefixes, whereas this flag should only be valid
for IPv4. In the case there is an IPv6 nexthop, remove
the ATTR_NEXTHOP flag.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-03-22 12:06:29 +01:00
Donald Sharp
7fd8ca9a48 bgpd: Add vrf name and peer name to some bgp debugs
Some debugs were especially hard to figure out in bgp_route.c

a) If using a %p pointer to print the bgp_path_info this
is pretty useless.  Print where it came from instead
b) Use A.B.C.D/M(VRFNAME) when outputing the prefix

Just basically give more useful information.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-21 15:06:00 -04:00
Russ White
69de86621f
Merge pull request #12997 from opensourcerouting/fix/free_duped_bgp_stuff_for_aggregate
bgpd: Free dup'ed attributes for aggregate routes with route-maps
2023-03-21 10:27:19 -04:00
Donald Sharp
d8bc11a592 *: Add a hash_clean_and_free() function
Add a hash_clean_and_free() function as well as convert
the code to use it.  This function also takes a double
pointer to the hash to set it NULL.  Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-21 08:54:21 -04:00
Donald Sharp
090109617e
Merge pull request #12999 from opensourcerouting/fix/bgp_leaks_random_stuff
bgpd: aggregate routes memory leak for aspath
2023-03-16 19:12:55 -04:00
Donatas Abraitis
9bea1b4bec bgpd: Unlock dest if we return earlier for aggregate install
If the bgp is in shutdown state or so, do not forget to unlock the dest node.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-15 13:34:55 +02:00
Donatas Abraitis
e11791f475 bgpd: Free dup'ed attributes for aggregate routes with route-maps
If route-map deny match is returned, we should free previously dup'ed
attributes: aspath, community, large community, extended community.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-15 11:35:00 +02:00
Russ White
52b5aeed95
Merge pull request #12990 from opensourcerouting/fix/rename_bgp_afi_node_lookup
bgpd: Drop afi from lookup functions (not used)
2023-03-14 10:16:16 -04:00
Donatas Abraitis
59d6b4d6ab bgpd: Rename bgp_afi_node_lookup() to bgp_safi_node_lookup()
afi not used in this function, reduce a bit.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-14 12:01:56 +02:00
Donald Sharp
115ccb9acf lib, bgpd: Add more debugs to GR Capability exchange
a) Make it legible what type of message is being passed
back and forth instead of having to guess it from
the insufficient debugs

b) Make it explicit which bgp instance is sending this
data

c) Cleanup bgp_zebra_update to have a cleaner api

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-09 08:36:51 -05:00
Donatas Abraitis
84ef27fca3 bgpd: Intern attributes before putting into rib-out
```
==21860==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 2 object(s) allocated from:
    0 0x7f8065294d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
    1 0x7f8064cfd216 in qcalloc lib/memory.c:105
    2 0x5646b7024073 in ecommunity_dup bgpd/bgp_ecommunity.c:252
    3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
    4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
    5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
    6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
    7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
    8 0x7f8064cc6acd in hash_walk lib/hash.c:270
    9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
    10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
    11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
    12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
    13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
    14 0x7f8064d891fb in thread_call lib/thread.c:1991
    15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
    16 0x5646b6feca67 in main bgpd/bgp_main.c:505
    17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

Indirect leak of 16 byte(s) in 2 object(s) allocated from:
    0 0x7f8065294b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    1 0x7f8064cfcf01 in qmalloc lib/memory.c:100
    2 0x5646b7024151 in ecommunity_dup bgpd/bgp_ecommunity.c:256
    3 0x5646b7153585 in route_set_ecommunity_lb bgpd/bgp_routemap.c:2925
    4 0x7f8064d459be in route_map_apply_ext lib/routemap.c:2675
    5 0x5646b7116584 in subgroup_announce_check bgpd/bgp_route.c:2374
    6 0x5646b711b907 in subgroup_process_announce_selected bgpd/bgp_route.c:2918
    7 0x5646b717ceb8 in group_announce_route_walkcb bgpd/bgp_updgrp_adv.c:184
    8 0x7f8064cc6acd in hash_walk lib/hash.c:270
    9 0x5646b717ae0c in update_group_af_walk bgpd/bgp_updgrp.c:2046
    10 0x5646b7181275 in group_announce_route bgpd/bgp_updgrp_adv.c:1030
    11 0x5646b711a986 in bgp_process_main_one bgpd/bgp_route.c:3303
    12 0x5646b711b5bf in bgp_process_wq bgpd/bgp_route.c:3444
    13 0x7f8064da12d7 in work_queue_run lib/workqueue.c:267
    14 0x7f8064d891fb in thread_call lib/thread.c:1991
    15 0x7f8064cdffcf in frr_run lib/libfrr.c:1185
    16 0x5646b6feca67 in main bgpd/bgp_main.c:505
    17 0x7f8063f96c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-03 17:33:51 +02:00
Philippe Guibert
b1ff5529c7 bgpd: debug trace retrieve real peer origin of path info
The BGP path info debugging information should dump the
real peer information for imported prefixes.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-28 22:00:25 +01:00
Philippe Guibert
8cd3d07097 bgpd: generalize imported peer in bgp best selection function
The bgp_path_info_cmp() function needs to get the peer of
imported prefixes in many parts of the algorithm. Use two
local variables to get the original peer either for vpn
imported prefixes or from standard prefixes.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-28 22:00:25 +01:00
Russ White
516444e6b1
Merge pull request #12618 from pguibert6WIND/vpnv4_ecmp
Vpnv4 ecmp
2023-02-28 15:49:05 -05:00
Donatas Abraitis
69a9680a78 bgpd: Free aggregate route memory on shutdown
Memory leak happens on shutdown or if BGP already deconfigured.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-27 22:15:07 +02:00
Philippe Guibert
cefda028bb bgpd: best path calculation uses peer from imported prefixes
Until now, when calculating the bgp bestpath route, the peer
comparison could not be performed for imported prefixes, as
the peer origin could not be retrieved. As consequence, the
reason why a given prefix as chosen was wrong: "Locally
configured route" was the main reason, whereas the prefix
was imported from a remote peer.

Fix this by searching for the real peer.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-26 09:44:16 +01:00
Russ White
eb9f54b872
Merge pull request #12805 from karlquan/kquan_self_orig
bgpd: BGP troubleshooting - Add a keyword self-originate to display o…
2023-02-21 08:38:07 -05:00
Russ White
f48c8a92fb
Merge pull request #12854 from opensourcerouting/fix/bgp_withdraw_attr_not_used
bgpd: Drop struct attr from bgp_withdraw()
2023-02-21 08:18:37 -05:00
Russ White
ba755d35e5
Merge pull request #12248 from pguibert6WIND/bgpasdot
lib, bgp: add initial support for asdot format
2023-02-21 08:01:03 -05:00
Donatas Abraitis
bf0c616383 bgpd: Drop struct attr from bgp_withdraw()
It's not used at all.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-21 11:35:59 +02:00
Donatas Abraitis
5ef2911d23
Merge pull request #12791 from taspelund/loc_rib_json_fix
bgpd: fix 'json detail' output structure
2023-02-17 20:24:33 +02:00
Donald Sharp
8383d53e43
Merge pull request #12780 from opensourcerouting/spdx-license-id
*: convert to SPDX License identifiers
2023-02-17 09:43:05 -05:00
Trey Aspelund
f9f2d188e3 bgpd: fix 'json detail' output structure
"show bgp <afi> <safi> json detail" was incorrectly displaying header
information from route_vty_out_detail_header() as an element of the
"paths" array. This corrects the behavior for 'json detail' so that a
route holds a dictionary with keys for "paths" and header info, which
aligns with how we structure the output for a specific prefix, e.g.
"show bgp <afi> <safi> <prefix> json".

Before:
```
ub20# show ip bgp json detail
{
 "vrfId": 0,
 "vrfName": "default",
 "tableVersion": 3,
 "routerId": "100.64.0.222",
 "defaultLocPrf": 100,
 "localAS": 1,
 "routes": { "2.2.2.2/32": [
  {                           <<<<<<<<<  should be outside the array
    "prefix":"2.2.2.2/32",
    "version":1,
    "advertisedTo":{
      "192.168.122.12":{
        "hostname":"ub20-2"
      }
    }
  },
  {
    "aspath":{
      "string":"Local",
      "segments":[
      ],
      "length":0
    },
<snip>
```

After:
```
ub20# show ip bgp json detail
{
 "vrfId": 0,
 "vrfName": "default",
 "tableVersion": 3,
 "routerId": "100.64.0.222",
 "defaultLocPrf": 100,
 "localAS": 1,
 "routes": { "2.2.2.2/32": {
"prefix": "2.2.2.2/32",
"version": "1",
"advertisedTo": {
  "192.168.122.12":{
    "hostname":"ub20-2"
  }
}
,"paths": [
  {
    "aspath":{
      "string":"Local",
      "segments":[
      ],
      "length":0
    },
```

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-02-16 16:05:16 +00:00
vivek
d2d71b042e bgpd: Prevent multipathing among EVPN and non-EVPN paths
Ensure that a multipath set is fully comprised of EVPN paths (i.e.,
paths imported into the VRF from EVPN address-family) or non-EVPN
paths. This is actually a condition that existed already in the code
but was not properly enforced.

This change, as a side effect, eliminates the known trigger condition
for bad or missing RMAC programming in an EVPN deployment, described
in tickets CM-29043 and CM-31222. Routes (actually, paths) in a VRF
routing table that require VXLAN tunneling to the next hop currently
need some special handling in zebra to deal with the nexthop (neigh)
and RMAC programming, and this is implemented for the entire route
(prefix), not per-path. This can lead to the bad or missing RMAC
situation, which is now eliminated by ensuring all paths in the route
are 'similar'.

The longer-term solution in CL 5.x will be to deal with the special
programming by means of explicit communication between bgpd and zebra.
This is already implemented for EVPN-MH via CM-31398. These changes
will be extended to non-MH also and the special code in zebra removed
or refined.

Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
Acked-by:      Trey Aspelund <taspelund@nvidia.com>
Acked-by:      Anuradha Karuppiah <anuradhak@nvidia.com>
Acked-by:      Chirag Shah <chirag@nvidia.com>

Ticket: CM-29043
Testing Done:
1. Manual testing
2. precommit on both MLX and BCM platforms
3. evpn-smoke - BCM and VX

Results described in the ticket
2023-02-16 07:44:50 -05:00
vivek
de692a4ebe bgpd: Fix deterministic-med check for stale paths
When performing deterministic MED processing, ensure that the peer
status is not checked when we encounter a stale path. Otherwise, this
path will be skipped from the DMED consideration leading to it potentially
not being installed.

Test scenario: Consider a prefix with 2 (multi)paths. The peer that
announces the path with the winning DMED undergoes a graceful-restart.
Before it comes back up, the other path goes away. Prior to the fix, a
third router that receives both these paths would have ended up not
having any path installed to the prefix after the above events.

Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>

For internal use:
Ticket: CM-32032
Testing done: Multiple manual testing
2023-02-16 07:42:39 -05:00
Karl Quan
83856649b3 bgpd: BGP troubleshooting - Add a keyword self-originate to display only self-originated prefixes when looking at the BGP table for a given address-family
Add a keyword self-originate" to extend current CLI commands to filter out self-originated routes only

a\) CLI to show ipv4/ipv6 self-originated routes
	"show [ip] bgp [afi] [safi] [all] self-originate [wide|json]"

b\) CLI to show evpn self-originated routes
    "show bgp l2vpn evpn route [detail] [type <ead|macip|multicast|es|prefix|1|2|3|4|5>] self-originate [json]"

Signed-off-by: Karl Quan <kquan@nvidia.com>
2023-02-15 14:14:28 -08:00
Philippe Guibert
c1aa9e7f90 bgpd: handle network rd parameter in network configuration
The bgp network command creates static routes with an optional
route-distinguisher parameter for VPN and EVPN address families.
Store the rd parameter in those static routes. This will be used
by the 'show running-config' later.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-10 10:27:23 +01:00
Philippe Guibert
fa566a94af bgpd: store the route-distinguisher from config as a string
The route-distinguisher string can be expressed in different
ways when the AS number is part of the RD. And the configured
string value has to be kept intact.
The following vty commands store the string value internally:
- router bgp / address-family ipv4 unicast / rd vpn export <>
- router bgp / address-family l2vpn evpn / rd <>
- router bgp / address-family l2vpn evpn / vni <> / rd <>

The vty commands where RD is configured in the below places is
not considered:
- router bgp / rfapi related commands
- router bgp / address-family xxx xxx / network .. rd <>

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-10 10:27:23 +01:00
Philippe Guibert
4a8cd6ad7f bgpd: support for as notation format for route distinguisher
RD may be built based on an AS number. Like for the AS, the RD
may use the AS notation. The two below examples can illustrate:

RD 1.1:20 stands for an AS4B:NN RD with AS4B=65536 in dot format.
RD 0.1:20 stands for an AS2B:NNNN RD with AS2B=0.1 in dot+ format.

This commit adds the asnotation mode to prefix_rd2str() API so as
to pick up the relevant display.

Two new printfrr extensions are available to display the RD with
the two above display methods.
- The pRDD extension stands for dot asnotation format
- The pRDE extension stands for dot+ asnotation format.
- The pRD extension has been renamed to pRDP extension

The code is changed each time '%pRD' printf extension is called.
Possibly, the asnotation may change the output, then a macro defines
the asnotation mode to use. A side effect of forging the mode to
use is that the string could not be concatenated with other strings
in vty_out and snprintfrr. Those functions have been called multiple
times. When zlog_debug needs to display the RD with some other string,
the prefix_rd2str() old API is used instead of the printf extension.

Some code has been kept untouched:
- code related to running-config. Actually, wherever an RD is displayed,
its configured name should be dumped.
- bgp rfapi code
- bgp evpn multihoming code (partially done), since the logic is
missing to get the asnotation of 'struct bgp_evpn_es'.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-10 10:27:23 +01:00
Philippe Guibert
e84c7c12f2 bgpd: modify bgp as number output
A json AS number API is created in order to output a
given AS number. In order to keep backward compatibility,
if the as-notation uses a number, then the json is encoded
as an integer, otherwise the encoding will be a string.

For what is not relevant to running-configuration, the
as-notation mode is the one used for the BGP instance.

Also, the vty completion gets the configured 'as_pretty'
string value, when an user wants to get the available
BGP instances.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-10 10:27:23 +01:00
Philippe Guibert
17571c4ae7 bgpd: aspath list format binds on as-notation format
Each BGP prefix may have an as-path list attached. A forged
string is stored in the BGP attribute and shows the as-path
list output.

Before this commit, the as-path list output was expressed as
a list of AS values in plain format. Now, if a given BGP instance
uses a specific asnotation, then the output is changed:

new output:
router bgp 1.1 asnotation dot
!
 address-family ipv4 unicast
  network 10.200.0.0/24 route-map rmap
  network 10.201.0.0/24 route-map rmap
  redistribute connected route-map rmap
 exit-address-family
exit
!
route-map rmap permit 1
 set as-path prepend 1.1 5433.55 264564564
exit

ubuntu2004# do show bgp ipv4
BGP table version is 2, local router ID is 10.0.2.15, vrf id 0
Default local pref 100, local AS 1.1
Status codes:  s suppressed, d damped, h history, * 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
 *> 4.4.4.4/32       0.0.0.0                  0         32768 1.1 5433.55 4036.61268 ?
 *> 10.0.2.0/24      0.0.0.0                  0         32768 1.1 5433.55 4036.61268 ?
    10.200.0.0/24    0.0.0.0                  0         32768 1.1 5433.55 4036.61268 i
    10.201.0.0/24    0.0.0.0                  0         32768 1.1 5433.55 4036.61268 i

The changes include:
- the aspath structure has a new field: asnotation type
The ashash list will differentiate 2 aspaths using a different
asnotation.
- 3 new printf extensions display the as number in the wished
format: pASP, pASD, pASE for plain, dot, or dot+ format (extended).

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-10 10:27:23 +01:00
David Lamparter
acddc0ed3c *: auto-convert to SPDX License IDs
Done with a combination of regex'ing and banging my head against a wall.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-09 14:09:11 +01:00
Trey Aspelund
3880b4ece4 bgpd: prefix match for advertised/received-routes
This introduces the option for a user to lookup one specific prefix in
the advertised-routes or received-routes table of a peer.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-02-08 21:06:10 +00:00
Trey Aspelund
aa9bf57eb8 bgpd: add 'detail' option to bestpath-routes
Introduce 'detail' keyword for 'show bgp <afi> <safi> bestpath-routes'.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-02-08 20:55:00 +00:00
Donatas Abraitis
96475dfde9
Merge pull request #12707 from donaldsharp/missed_enums
Missed enums
2023-02-07 22:22:27 +02:00
Donatas Abraitis
1aa2c93e2c bgpd: Drop struct bgp from vpn_leak_to_vrf_withdraw()
Not used at all, just drop it.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-06 18:44:11 +02:00
Donald Sharp
d7c6467ba2 lib, bgpd: Add ability to specify that some json output should not be pretty
Initial commit: 23b2a7ef52
changed the json output of `show bgp <afi> <safi> json` to
not have pretty print because when under a situation where
there are a bunch of routes with a large scale ecmp show
output was taking forever and this commit cut 2 minutes out
of vtysh run time.

Subusequent commit: f4ec52f7cc
changed this back.

When upgrading to latest version the long run time was noticed
due to testing.  Let's add back this functionality such that
FRR can have reduced run times with vtysh when it's really
needed.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-02-02 10:28:19 -05:00
Donald Sharp
33303f08bf
Merge pull request #12713 from opensourcerouting/fix/json_naming_deprecation
*: Drop deprecated incorrect JSON fields with wrong naming
2023-02-01 15:39:18 -05:00
Donald Sharp
58cf0823bf bgpd: Add missing enum's to case statement
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-01-31 12:29:08 -05:00
Donald Sharp
ea768492f1
Merge pull request #12695 from opensourcerouting/format-warnings
build: `-Wformat-nonliteral -Wformat-security`
2023-01-31 09:01:32 -05:00
Donatas Abraitis
1ce23106eb *: Drop deprecated incorrect JSON fields with wrong naming
Deprecation cycle already passed.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-31 10:18:28 +02:00
Donald Sharp
367b458cb4 bgpd: bgp_update and bgp_withdraw never return failures
These two functions always return 0.  As such any and all
tests against this make no sense.  Remove the return 0
to a void and follow the chain, logically, to remove all
the dead code.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-01-30 16:02:23 -05:00
David Lamparter
e678b143a9 bgpd: fix format string mess in AS-path printing
This was done *very* weirdly.  Make it slightly less so.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-01-27 12:01:20 +01:00
Philippe Guibert
f7a0eb6a17 bgpd: encode properly vpnv6 nexthop
This change updates the nexthop attribute length
accordingly to the safi used. Actually, with the
previous commit, the length calculated was not
aligned with the real nexthop length. Such packet
received by remote peer was malformed, and this
was resulting in breaking vpnv6 peering.

Fix this by updating appropriately the real
nexthop length.

Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-01-23 16:43:51 +01:00
Donatas Abraitis
cfd01fc0ac Revert "bgpd: optimal router reflection cli and fsm changes"
This reverts commit 70cd87ca02.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-17 18:15:28 +02:00
Russ White
e2fd75fce2
Merge pull request #12584 from pguibert6WIND/bgp_imported_distance
bgpd: imported vpn entries get appropriate distance
2023-01-17 10:16:46 -05:00
Philippe Guibert
a04f1c42eb bgpd: imported vpn entries get appropriate distance
MPLS VPN networks can either peer with iBGP or eBGP. When
calculating the distance to send to zebra, the imported prefix
is never sent with distance information, even if the vty
command is used under the ipv4 unicast address family:

router bgp 65505 vrf vrf1
 address-family ipv4 unicast
  distance bgp 26 27 28
  [vpn config]

The observation is that the distance sent to zebra for an
imported prefix is still 20:

[..]
VRF vrf1:
B>  192.168.0.0/24 [20/0] via 2.2.2.2 (vrf default) (recursive), label 20, weight 1, 00:00:12
  *                          via 10.125.0.6, ntfp3 (vrf default), label implicit-null/20, weight 1, 00:00:12

The expectation is that the incoming prefix has to follow the
distance that is configured, or the distance derived from the peer
relationship established by the parent prefix.

In the case, an iBGP relationship is done, and no distance
configuration is done, the below show is expected:

   [..]
   VRF vrf1:
   B*>  192.168.0.0/24 [200/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12

In the case an iBGP relationship is done, and distance configuration
is performed as below:
   [..]
   distance bgp 21 201 41
   [..]

Then the below show is expected:

   [..]
   VRF vrf1:
   B*>  192.168.0.0/24 [201/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12

To get this behaviour, get the peer origin where the prefix is coming
from.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-01-17 13:24:33 +01:00
Donatas Abraitis
25851bf0a1 bgpd: Do not send routes back received from a peer
Before this patch, we needed to explicitly define a neighbor to be SOLO
(= separate update-group). Let's ease this functionality for an operator to
avoid confusions.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-14 21:30:07 +02:00
Donald Sharp
2bb8b49ce1 Revert "Merge pull request #11127 from louis-6wind/bgp-leak"
This reverts commit 16aa1809e7, reversing
changes made to f616e71608.
2023-01-13 08:13:52 -05:00
Donatas Abraitis
2d02b3372d
Merge pull request #12622 from taspelund/adj-rib-json
bgpd: add "detail" for advertised/received-routes
2023-01-11 15:25:48 +02:00
Donatas Abraitis
01dbc4b384
Merge pull request #12577 from louis-6wind/fix-bgp-evpn-all
bgpd: fix show bgp all with evpn
2023-01-11 14:20:16 +02:00
Trey Aspelund
e960b4ca06 bgpd: add "detail" for advertised/received-routes
Introduce a "detail" keyword for per-neighbor/per-afi-safi
advertised-routes and received-routes show commands.
Includes json support.

Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-01-10 20:05:08 +00:00
Donatas Abraitis
c6b077a56e bgpd: Fix the number of arguments for frrtrace()
For bgp_path_info_add_with_caller().

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-05 09:19:43 +02:00
Donatas Abraitis
b6e91c32e8
Merge pull request #12458 from liron-ze/aggre-route-withdraw
bgpd: Fix aggregated routes are withdrawn abnormally.
2023-01-04 22:50:16 +02:00
Louis Scalbert
0adc5bbb21 bgpd: fix show bgp all with evpn
Fix crash on "show bgp all" when BGP EVPN is set.

> #0  raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007fdfe03cf53c in core_handler (signo=11, siginfo=0x7ffdebbffe30, context=0x7ffdebbffd00) at lib/sigevent.c:261
> #2  <signal handler called>
> #3  0x00000000004d4fec in bgp_attr_get_community (attr=0x41) at bgpd/bgp_attr.h:553
> #4  0x00000000004eee84 in bgp_show_table (vty=0x1a790d0, bgp=0x19d0a00, safi=SAFI_EVPN, table=0x19f6010, type=bgp_show_type_normal, output_arg=0x0, rd=0x0, is_last=1, output_cum=0x0,
>     total_cum=0x0, json_header_depth=0x7ffdebc00bf8, show_flags=4, rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11329
> #5  0x00000000004f7765 in bgp_show (vty=0x1a790d0, bgp=0x19d0a00, afi=AFI_L2VPN, safi=SAFI_EVPN, type=bgp_show_type_normal, output_arg=0x0, show_flags=4,
>     rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11814
> #6  0x00000000004fb53b in show_ip_bgp_magic (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050, viewvrfname=0x0, all=0x1395390 "all", aa_nn=0x0, community_list=0,
>     community_list_str=0x0, community_list_name=0x0, as_path_filter_name=0x0, prefix_list=0x0, accesslist_name=0x0, rmap_name=0x0, version=0, version_str=0x0, alias_name=0x0,
>     orr_group_name=0x0, detail_routes=0x0, uj=0x0, detail_json=0x0, wide=0x0) at bgpd/bgp_route.c:13040
> #7  0x00000000004fa322 in show_ip_bgp (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050) at ./bgpd/bgp_route_clippy.c:519
> #8  0x00007fdfe033ccc8 in cmd_execute_command_real (vline=0x19c9300, filter=FILTER_RELAXED, vty=0x1a790d0, cmd=0x0, up_level=0) at lib/command.c:996
> #9  0x00007fdfe033c739 in cmd_execute_command (vline=0x19c9300, vty=0x1a790d0, cmd=0x0, vtysh=0) at lib/command.c:1056
> #10 0x00007fdfe033cdf5 in cmd_execute (vty=0x1a790d0, cmd=0x19c9eb0 "show bgp all", matched=0x0, vtysh=0) at lib/command.c:1223
> #11 0x00007fdfe03f65c6 in vty_command (vty=0x1a790d0, buf=0x19c9eb0 "show bgp all") at lib/vty.c:486
> #12 0x00007fdfe03f603b in vty_execute (vty=0x1a790d0) at lib/vty.c:1249
> #13 0x00007fdfe03f533b in vtysh_read (thread=0x7ffdebc03838) at lib/vty.c:2148
> #14 0x00007fdfe03e815d in thread_call (thread=0x7ffdebc03838) at lib/thread.c:2006
> #15 0x00007fdfe0379b54 in frr_run (master=0x1246880) at lib/libfrr.c:1198
> #16 0x000000000042b2a8 in main (argc=7, argv=0x7ffdebc03af8) at bgpd/bgp_main.c:520

Link: https://github.com/FRRouting/frr/issues/12576
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2022-12-29 17:05:01 +01:00
Russ White
9d6ac4fc9e
Merge pull request #12562 from opensourcerouting/fix/add_frrtrace_points_for_peer_lock_unlock
bgpd: A bit more tracepoints for lttng
2022-12-27 15:07:57 -05:00
Russ White
7430278a2f
Merge pull request #12558 from donaldsharp/bgp_static_route_mem_leak
bgpd: static routes are leaked on shutdown
2022-12-27 15:07:17 -05:00
Russ White
962ae985ee
Merge pull request #12515 from opensourcerouting/fix/show_ip_bgp_detail_weird_output
bgpd: Show the real prefix for `show bgp detail`
2022-12-27 15:05:55 -05:00
Donatas Abraitis
eb473185d7 bgpd: Add lttng tracepoints for bgp_path_info_add/free
```
[00:05:25.690812414] (+0.000004699) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "10.0.0.6/32", peer = "10.0.0.3", dest_lock = 2, peer_lock = 8 }
[00:05:25.690816732] (+0.000004318) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "10.0.0.71/32", peer = "10.0.0.3", dest_lock = 2, peer_lock = 9 }
[00:05:25.690821251] (+0.000004519) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "10.0.0.72/32", peer = "10.0.0.3", dest_lock = 2, peer_lock = 10 }
[00:05:25.690826050] (+0.000004799) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "192.168.13.0/24", peer = "10.0.0.3", dest_lock = 1, peer_lock = 11 }
[00:05:25.690830438] (+0.000004388) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "192.168.24.0/24", peer = "10.0.0.3", dest_lock = 2, peer_lock = 12 }
[00:05:25.690834666] (+0.000004228) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "192.168.35.0/24", peer = "10.0.0.3", dest_lock = 2, peer_lock = 13 }
[00:05:25.690839145] (+0.000004479) donatas-pc frr_bgp:bgp_path_info_add: { cpu_id = 4 }, { caller = "bgp_update", prefix = "192.168.67.0/24", peer = "10.0.0.3", dest_lock = 2, peer_lock = 14 }
[00:05:26.361779328] (+0.670940183) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.2/32", peer = "10.0.0.2", dest_lock = 3, peer_lock = 13 }
[00:05:26.361790669] (+0.000011341) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.3/32", peer = "10.0.0.3", dest_lock = 3, peer_lock = 13 }
[00:05:26.361792282] (+0.000001613) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.4/32", peer = "10.0.0.3", dest_lock = 5, peer_lock = 12 }
[00:05:26.361912420] (+0.000120138) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.4/32", peer = "10.0.0.2", dest_lock = 4, peer_lock = 12 }
[00:05:26.361914153] (+0.000001733) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.5/32", peer = "10.0.0.3", dest_lock = 5, peer_lock = 11 }
[00:05:26.361915425] (+0.000001272) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.5/32", peer = "10.0.0.2", dest_lock = 4, peer_lock = 11 }
[00:05:26.361916878] (+0.000001453) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.6/32", peer = "10.0.0.3", dest_lock = 5, peer_lock = 10 }
[00:05:26.361920645] (+0.000003767) donatas-pc frr_bgp:bgp_path_info_free: { cpu_id = 7 }, { caller = "bgp_path_info_unlock", prefix = "10.0.0.6/32", peer = "10.0.0.2", dest_lock = 4, peer_lock = 10 }
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-23 10:04:41 +02:00
Donald Sharp
f9d6087c51 bgpd: static routes are leaked on shutdown
Shutdown of bgp results in both the bgp_path_info,
bgp_dest and bgp_table's not being freed because
the bgp_path_info remains locked.

Effectively static routes are scheduled for deletion but bgp_process
skips the work because the work queue sees that the bgp router
is marked for deletion.  Effectively not doing any work and leaving
data on the floor.

Modify the code when attempting to put into the work queue to
notice and not do so but just unlock the path info.

This is effectively the same as what goes on for normal peering
as that it checks for shutdown and just calls bgp_path_info_free
too.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-21 12:11:56 -05:00
Donatas Abraitis
27bb782a98 bgpd: Adopt show bgp detail-routes command for L3VPN outputs as well
```
unet> sh pe2 vtysh -c 'sh ip bgp ipv4 vpn detail-routes'
BGP table version is 4, local router ID is 10.10.10.20, vrf id 0
Default local pref 100, local AS 65001
Route Distinguisher: 192.168.2.2:2
BGP routing table entry for 192.168.2.2:2:10.0.0.0/24, version 1
not allocated
Paths: (1 available, best #1)
  Not advertised to any peer
  65000
    192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
      Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received)
      Extended Community: RT:192.168.2.2:2
      Originator: 10.10.10.20
      Remote label: 2222
      Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:172.16.255.1/32, version 2
not allocated
Paths: (1 available, best #1)
  Not advertised to any peer
  65000
    192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
      Origin incomplete, localpref 50, valid, sourced, local, best (First path received)
      Extended Community: RT:192.168.2.2:2
      Originator: 10.10.10.20
      Remote label: 2222
      Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:192.168.1.0/24, version 3
not allocated
Paths: (1 available, best #1)
  Not advertised to any peer
  65000
    192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
      Origin incomplete, localpref 50, valid, sourced, local, best (First path received)
      Extended Community: RT:192.168.2.2:2
      Originator: 10.10.10.20
      Remote label: 2222
      Last update: Tue Dec 20 13:01:20 2022
BGP routing table entry for 192.168.2.2:2:192.168.2.0/24, version 4
not allocated
Paths: (1 available, best #1)
  Not advertised to any peer
  65000
    192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self
      Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received)
      Extended Community: RT:192.168.2.2:2
      Originator: 10.10.10.20
      Remote label: 2222
      Last update: Tue Dec 20 13:01:20 2022

Displayed  4 routes and 4 total paths
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-20 13:13:34 +02:00
Donatas Abraitis
81dcd88113 bgpd: Set routes detail flag when using flowspec detailed command
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-20 12:19:37 +02:00
Donatas Abraitis
509d82bd49 bgpd: Add show ip bgp <afi> <safi> detail command version
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-20 12:19:37 +02:00
Donatas Abraitis
67799a4893 bgpd: Rename BGP_SHOW_OPT_DETAIL to BGP_SHOW_OPT_JSON_DETAIL
This option used only for JSON detailed output.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-20 12:19:37 +02:00
Donatas Abraitis
9a1aae2dde bgpd: Show the real prefix for show bgp detail
Absolutely not possible to read the output and even distinguish the prefix
we are looking for.

Before:

```
donatas-pc# show ip bgp detail
BGP table version is 12, local router ID is 192.168.10.17, vrf id 0
Default local pref 100, local AS 65002
Status codes:  s suppressed, d damped, h history, * 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
  65001
    2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
    (fe80::a00:27ff:fe5e:d19e) (used)
      Origin incomplete, metric 0, valid, external, multipath
      Last update: Tue Dec 13 22:53:16 2022
  65001
    192.168.10.124 from 192.168.10.124 (200.200.200.202)
      Origin incomplete, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
      Last update: Tue Dec 13 22:53:16 2022
  65001
    2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
    (fe80::a00:27ff:fe5e:d19e) (used)
      Origin IGP, metric 0, valid, external, multipath
      Last update: Tue Dec 13 22:53:16 2022
  65001
    192.168.10.124 from 192.168.10.124 (200.200.200.202)
      Origin IGP, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
      Last update: Tue Dec 13 22:53:16 2022
```

After:

```
donatas-pc# show ip bgp detail
BGP table version is 12, local router ID is 192.168.10.17, vrf id 0
Default local pref 100, local AS 65002
BGP routing table entry for 10.0.2.0/24, version 1
Paths: (2 available, best #2, table default)
  Advertised to non peer-group peers:
  2a02:4780:abc::2
  65001
    2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
    (fe80::a00:27ff:fe5e:d19e) (used)
      Origin incomplete, metric 0, valid, external, multipath
      Last update: Tue Dec 13 22:47:16 2022
BGP routing table entry for 10.0.2.0/24, version 1
Paths: (2 available, best #2, table default)
  Advertised to non peer-group peers:
  2a02:4780:abc::2
  65001
    192.168.10.124 from 192.168.10.124 (200.200.200.202)
      Origin incomplete, metric 0, valid, external, otc 65001, multipath, best (Neighbor IP)
      Last update: Tue Dec 13 22:47:16 2022
BGP routing table entry for 10.10.100.0/24, version 2
Paths: (2 available, best #2, table default)
  Advertised to non peer-group peers:
  2a02:4780:abc::2
  65001
    2a02:4780:abc::2 from 2a02:4780:abc::2 (200.200.200.202)
    (fe80::a00:27ff:fe5e:d19e) (used)
      Origin IGP, metric 0, valid, external, multipath
      Last update: Tue Dec 13 22:47:16 2022
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-20 12:19:37 +02:00
Louis Scalbert
667a4e92da bgpd: move mp_nexthop_prefer_global boolean attribute to nh_flag
Previous commits have introduced a new 8 bits nh_flag in the attr
struct that has increased the memory footprint.

Move the mp_nexthop_prefer_global boolean in the attr structure that
takes 8 bits to the new nh_flag in order to go back to the previous
memory utilization.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2022-12-16 15:07:00 +01:00
Louis Scalbert
6030b8b40d bgpd: update route leaking when a VRF loopback is received
At bgpd startup, VRF instances are sent from zebra before the
interfaces. When importing a l3vpn prefix from another local VRF
instance, the interfaces are not known yet. The prefix nexthop interface
cannot be set to the loopback or the VRF interface, which causes setting
invalid routes in zebra.

Update route leaking when the loopback or a VRF interface is received
from zebra.

At a VRF interface deletion, zebra voluntarily sends a
ZEBRA_INTERFACE_ADD message to move it to VRF_DEFAULT. Do not update if
such a message is received. VRF destruction will destroy all the related
routes without adding codes.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2022-12-16 14:52:47 +01:00
Louis Scalbert
f0cde006f0 bgpd: display the IGP metric of the ultimate path in route details
Display IGP metric of the ultimate path in the command
"show bgp vrf X ipv(4|6)".

Fixes: da0c0ef70c ("bgpd: VRF-Lite fix best path selection")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2022-12-15 17:10:56 +01:00
liuze03
704e189e59 bgpd: Fix aggregated routes are withdrawn abnormally.
The withdraw message and announcement message of a prefix are received continuously within 50ms, which may lead to abnormal aggregation route reference count.
    Steps to reproduce:
    --------------------------
    step1:
    local config aggregate route 111.0.0.0/24
    received route:111.0.0.1/32 111.0.0.02/32
    ref_count:2

    step2:
    peer withdraw 111.0.0.1/32 and network 111.0.0.1/32 in 50ms
    received route:111.0.0.1/32 111.0.0.02/32
    ref_count:1

    step3:
    peer withdraw 111.0.0.1/32
    received route:111.0.0.02/32
    ref_count:0
    aggregate route will be withdrawn abnormally

Signed-off-by: liuze03 <liuze03@baidu.com>
2022-12-14 11:40:24 +08:00
Donatas Abraitis
819e67670c bgpd: Free memory allocated by info_make() when hitting maximum-prefix
```
Direct leak of 112 byte(s) in 1 object(s) allocated from:
    0 0x7feb66337a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    1 0x7feb660cbcc3 in qcalloc lib/memory.c:116
    2 0x55cc3cba02d1 in info_make bgpd/bgp_route.c:3831
    3 0x55cc3cbab4f1 in bgp_update bgpd/bgp_route.c:4733
    4 0x55cc3cbb0620 in bgp_nlri_parse_ip bgpd/bgp_route.c:6111
    5 0x55cc3cb79473 in bgp_update_receive bgpd/bgp_packet.c:2020
    6 0x55cc3cb7c34a in bgp_process_packet bgpd/bgp_packet.c:2929
    7 0x7feb6610ecc5 in thread_call lib/thread.c:2006
    8 0x7feb660bfb77 in frr_run lib/libfrr.c:1198
    9 0x55cc3cb17232 in main bgpd/bgp_main.c:520
    10 0x7feb65ae5082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s).
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-09 20:07:59 +02:00