Add the 'redistribute table-direct' command under the bgp address-family
node. Handle the table-direct support wherever needed in the BGP code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we have a prefix-list with one entry, and after some time we append a prefix-list
with some more additional entries, conditional advertisement is triggered, and the
old entries are suppressed (because they look identical as sent before).
Hence, the old entries are sent as withdrawals and only new entries sent as updates.
Force re-sending all BGP updates for conditional advertisement. The same is done
for route-refresh, and/or soft clear operations.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
For instance, it's not possible to resend FQDN capability without resetting
the session, so let's create some more elegant way to do that.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add an ability to enable/disable ORF capability dynamically without tearing
down the session.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If BGP starts with a l3vpn configuration, the 'pending' value
of the 'show bgp labelpool summary' command is set to 128,
whereas the 'pending' value is 0 if the l3vpn configuration is
applied after.
with no config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger: 1
> InUse: 1
> Requests: 0
> LabelChunks: 1
> Pending: 0
> Reconnects: 1
with config at startup:
> show bgp labelpool summary
> Labelpool Summary
> -----------------
> Ledger: 1
> InUse: 1
> Requests: 0
> LabelChunks: 1
> Pending: 128
> Reconnects: 1
When BGP configuration is applied at startup, the label request fails,
because the zapi connection with zebra is not yet up. At zebra
up event, the label request is done again, succeeds, decrements the
'pending_count' value in 'bgp_lp_event_chunk() function, then sets
the 'pending_count' value to the 'labels_needed' value.
This method was correct when label requests were asyncronous: the
'pending_count' value was first set, then decremented. In syncronous
label requests, the operations are swapped.
Fix this by incrementing the expected 'labels_needed' value instead.
Fixes: 0043ebab99 ("bgpd: Use synchronous way to get labels from Zebra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A label chunk is used by BGP for L3VPN or LU purposes,
by picking up labels from that chunk; but when those
labels are release, the label chunks are never released.
The below configuration sequence shows that the label
chunks are not released.
> router bgp 65500
> bgp router-id 1.1.1.1
> !
> address-family ipv4 unicast
> label vpn export auto
> rd vpn export 55:1
> rt vpn both 55:1
> export vpn
> import vpn
> [..]
> no label vpn export auto
> [..]
> # show bgp labelpool summary
> [..]
> LabelChunks: 1
> Pending: 128
> [..]
The '128' value stands for the default label chunk size,
which is not released after unconfiguration.
Fix this by checking after each label release, that
the label chunk is still used. If not, release it.
Reset the 'next_chunksize' value to the default value.
Fixes: 955bfd984f ("bgpd: dynamic mpls label pool")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP always asks zebra for a chunk of MPLS label even if it doesn't need it.
Fix this by correcting the rounding up "labels_needed" formula.
Fixes: 80853c2ec7 ("bgpd: improve labelpool performance at scale")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Today, when configuring BGP L3VPN mpls, the operator may
use that command to hardset a label value:
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export <hardset_label_value>
Today, BGP uses this value without checks, leading to potential
conflicts with other control planes like LDP. For instance, if
LDP initiates with a label chunk of [16;72] and BGP also uses the
50 label value, a conflict arises.
The 'label manager' service in zebra oversees label allocations.
While all the control plane daemons use it, BGP doesn't when a
hardset label is in place.
This update fixes this problem. Now, when a hardset label is set for
l3vpn export, a request is made to the label manager for approval,
ensuring no conflicts with other daemons. But, this means some existing
BGP configurations might become non-operational if they conflict with
labels already allocated to another daemon but not used.
note: Labels below 16 are reserved and won't be checked for consistency
by the label manager.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The original 'bgp label vpn export' code is confusing,
the 'no form' actions are mixed with the positive form.
Fix this by rewriting the code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The shallow copy of attr wasn't freed when there was no valid label for the momentand the function return therefore creating leaks. The leak below are solved by flushing the shallow copy of attr.
Address Sanitizer Error detected in bgp_vpnv6_per_nexthop_label.test_bgp_vpnv6_per_nexthop_label/r1.asan.bgpd.13409
=================================================================
==13409==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
#7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
#8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
#9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
#14 0x7f62ccb62b8f in event_call lib/event.c:1969
#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#16 0x5623b87e054b in main bgpd/bgp_main.c:510
#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969
#5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
#6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341
#7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220
#8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
#7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
#8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
#9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
#14 0x7f62ccb62b8f in event_call lib/event.c:1969
#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#16 0x5623b87e054b in main bgpd/bgp_main.c:510
#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 240 byte(s) in 6 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384
#5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 120 byte(s) in 3 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692
#5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595
#6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#7 0x7f62ccb62b8f in event_call lib/event.c:1969
#8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#9 0x5623b87e054b in main bgpd/bgp_main.c:510
#10 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7f62cd0c9d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f62ccac21c3 in qcalloc lib/memory.c:105
#2 0x5623b8810dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348
#5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x5623b89beabc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x5623b89beabc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
#7 0x5623b89beabc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
#8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
#9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
#14 0x7f62ccb62b8f in event_call lib/event.c:1969
#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#16 0x5623b87e054b in main bgpd/bgp_main.c:510
#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b892e86d in bgp_update bgpd/bgp_route.c:4969
#5 0x5623b893134d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
#6 0x5623b88e2a0e in bgp_nlri_parse bgpd/bgp_packet.c:341
#7 0x5623b88e4f7c in bgp_update_receive bgpd/bgp_packet.c:2220
#8 0x5623b88f0474 in bgp_process_packet bgpd/bgp_packet.c:3386
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88c13b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x5623b89bdebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x5623b89bdebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
#7 0x5623b89bdebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
#8 0x7f62cca45511 in cmd_execute_command_real lib/command.c:978
#9 0x7f62cca459d5 in cmd_execute_command lib/command.c:1036
#10 0x7f62cca45e54 in cmd_execute lib/command.c:1203
#11 0x7f62ccb6ee20 in vty_command lib/vty.c:591
#12 0x7f62ccb6f2cb in vty_execute lib/vty.c:1354
#13 0x7f62ccb77b95 in vtysh_read lib/vty.c:2362
#14 0x7f62ccb62b8f in event_call lib/event.c:1969
#15 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#16 0x5623b87e054b in main bgpd/bgp_main.c:510
#17 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 6 object(s) allocated from:
#0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88dc289 in evaluate_paths bgpd/bgp_nht.c:1384
#5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 24 byte(s) in 3 object(s) allocated from:
#0 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b893a406 in bgp_redistribute_add bgpd/bgp_route.c:8692
#5 0x5623b8a02b3b in zebra_read_route bgpd/bgp_zebra.c:595
#6 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#7 0x7f62ccb62b8f in event_call lib/event.c:1969
#8 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#9 0x5623b87e054b in main bgpd/bgp_main.c:510
#10 0x7f62cbae7c86 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 0x7f62cd0c9b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f62ccac1ee3 in qmalloc lib/memory.c:100
#2 0x5623b8810eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x5623b88be8eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x5623b88dc188 in evaluate_paths bgpd/bgp_nht.c:1348
#5 0x5623b88ddb0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x5623b88de027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x5623b8a03163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f62ccb92d8a in zclient_read lib/zclient.c:4425
#9 0x7f62ccb62b8f in event_call lib/event.c:1969
#10 0x7f62ccaa5462 in frr_run lib/libfrr.c:1213
#11 0x5623b87e054b in main bgpd/bgp_main.c:510
#12 0x7f62cbae7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s).
***********************************************************************************
Address Sanitizer Error detected in bgp_vpnv4_per_nexthop_label.test_bgp_vpnv4_per_nexthop_label/r1.asan.bgpd.10610
=================================================================
==10610==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969
#5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
#6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341
#7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220
#8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
#7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
#8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
#9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
#11 0x7f81fc007e20 in vty_command lib/vty.c:591
#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
#14 0x7f81fbffbb8f in event_call lib/event.c:1969
#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#16 0x55cdc9af854b in main bgpd/bgp_main.c:510
#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 280 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
#7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
#8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
#9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
#11 0x7f81fc007e20 in vty_command lib/vty.c:591
#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
#14 0x7f81fbffbb8f in event_call lib/event.c:1969
#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#16 0x55cdc9af854b in main bgpd/bgp_main.c:510
#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 240 byte(s) in 6 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384
#5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348
#5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581
#7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118
#8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f81fc562d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f81fbf5b1c3 in qcalloc lib/memory.c:105
#2 0x55cdc9b28dc8 in ecommunity_dup bgpd/bgp_ecommunity.c:252
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692
#5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595
#6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#7 0x7f81fbffbb8f in event_call lib/event.c:1969
#8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#9 0x55cdc9af854b in main bgpd/bgp_main.c:510
#10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9cd6abc in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode_magic bgpd/bgp_vty.c:9464
#7 0x55cdc9cd6abc in af_label_vpn_export_allocation_mode bgpd/bgp_vty_clippy.c:2809
#8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
#9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
#11 0x7f81fc007e20 in vty_command lib/vty.c:591
#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
#14 0x7f81fbffbb8f in event_call lib/event.c:1969
#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#16 0x55cdc9af854b in main bgpd/bgp_main.c:510
#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9cd5ebb in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9cd5ebb in af_label_vpn_export_magic bgpd/bgp_vty.c:9547
#7 0x55cdc9cd5ebb in af_label_vpn_export bgpd/bgp_vty_clippy.c:2868
#8 0x7f81fbede511 in cmd_execute_command_real lib/command.c:978
#9 0x7f81fbede9d5 in cmd_execute_command lib/command.c:1036
#10 0x7f81fbedee54 in cmd_execute lib/command.c:1203
#11 0x7f81fc007e20 in vty_command lib/vty.c:591
#12 0x7f81fc0082cb in vty_execute lib/vty.c:1354
#13 0x7f81fc010b95 in vtysh_read lib/vty.c:2362
#14 0x7f81fbffbb8f in event_call lib/event.c:1969
#15 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#16 0x55cdc9af854b in main bgpd/bgp_main.c:510
#17 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 56 byte(s) in 7 object(s) allocated from:
#0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9c4686d in bgp_update bgpd/bgp_route.c:4969
#5 0x55cdc9c4934d in bgp_nlri_parse_ip bgpd/bgp_route.c:6213
#6 0x55cdc9bfaa0e in bgp_nlri_parse bgpd/bgp_packet.c:341
#7 0x55cdc9bfcf7c in bgp_update_receive bgpd/bgp_packet.c:2220
#8 0x55cdc9c08474 in bgp_process_packet bgpd/bgp_packet.c:3386
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 6 object(s) allocated from:
#0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bf4289 in evaluate_paths bgpd/bgp_nht.c:1384
#5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 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 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bf4188 in evaluate_paths bgpd/bgp_nht.c:1348
#5 0x55cdc9bf5b0b in bgp_process_nexthop_update bgpd/bgp_nht.c:733
#6 0x55cdc9bf6027 in bgp_parse_nexthop_update bgpd/bgp_nht.c:934
#7 0x55cdc9d1b163 in bgp_read_nexthop_update bgpd/bgp_zebra.c:104
#8 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 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 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9bd93b3 in vpn_leak_from_vrf_update_all bgpd/bgp_mplsvpn.c:2005
#5 0x55cdc9bdafd5 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:287
#6 0x55cdc9bdafd5 in vpn_leak_label_callback bgpd/bgp_mplsvpn.c:581
#7 0x55cdc9bb2606 in lp_cbq_docallback bgpd/bgp_labelpool.c:118
#8 0x7f81fc0164b5 in work_queue_run lib/workqueue.c:266
#9 0x7f81fbffbb8f in event_call lib/event.c:1969
#10 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#11 0x55cdc9af854b in main bgpd/bgp_main.c:510
#12 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f81fc562b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f81fbf5aee3 in qmalloc lib/memory.c:100
#2 0x55cdc9b28eb8 in ecommunity_dup bgpd/bgp_ecommunity.c:256
#3 0x55cdc9bd68eb in vpn_leak_from_vrf_update bgpd/bgp_mplsvpn.c:1628
#4 0x55cdc9c52406 in bgp_redistribute_add bgpd/bgp_route.c:8692
#5 0x55cdc9d1ab3b in zebra_read_route bgpd/bgp_zebra.c:595
#6 0x7f81fc02bd8a in zclient_read lib/zclient.c:4425
#7 0x7f81fbffbb8f in event_call lib/event.c:1969
#8 0x7f81fbf3e462 in frr_run lib/libfrr.c:1213
#9 0x55cdc9af854b in main bgpd/bgp_main.c:510
#10 0x7f81faf80c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 1536 byte(s) leaked in 64 allocation(s).
***********************************************************************************
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Instead of scaling the bandwith to something between 1 and 100, just
send down the bandwidth Available for the link.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgp_orig is never NULL in the code path, and coverity is angry on this.
Let's remove this test at all.
Coverity 1566808
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
BGP is storing outgoing updates in a couple of different
fifo's. This is to ensure proper packet packing of
all bgp_dests that happen to use the same attribute.
How it's all put together currently: On initial update
BGP walks through all the bgp_dest's in a table. For each
path being sent a bgp_advertise is created. This bgp_advertise
is placed in fifo order on the bgp_synchronize->update queue.
The bgp_advertise has a pointer to the bgp_advertise_attr which
is associated iwth the actual attribute that is being sent to
it's peer. In turn this bgp_advertise is placed in a fifo off
of the bgp_advertise_attr structure. As such as we have paths
that share an attribute, the path/dest is placed on the
bgp_syncrhonize->update fifo as well as being placed on the fifo
associated with the advertised attribute.
On actual creation of a packet. The first item in the
bgp_synchronize->update fifo is popped. The bgp_advertise_attr
pointer is grabbed, we fill out the nlri part of the bgp packet
and then walk the bgp_advertise_attr fifo to place paths/dests in
the packet. As each path/dest is placed in the packet it is removed
from both the bgp_synchronize->update fifo and the bgp_advertise_attr
fifo.
The whole point of this change is to switch the *next, *prev
pointers in the bgp_advertise structure with a typesafe data
structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
At each EBGP boundary, BGP path attributes are modified as per [RFC4271], which includes stripping any IBGP-only attributes.
Some networks span more than one autonomous system and require more flexibility in the propagation of path attributes. It is worth noting that these multi-AS networks have a common or single administrative entity. These networks are said to belong to One Administrative Domain (OAD). It is desirable to carry IBGP-only attributes across EBGP peerings when the peers belong to an OAD.
This document defines a new EBGP peering type known as EBGP-OAD, which is used between two EBGP peers that belong to an OAD. This document also defines rules for route announcement and processing for EBGP-OAD peers.
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Changing Addpath type, and or disabling RX (receiving) flag, we can do this
without tearing down the session, and using dynamic capabilities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When we have RX/TX flags, but received only TX, we should clear RX flag, to avoid
receiving additional paths.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There is no match mechanism to match one community from the
incoming community-list. Add the 'any' keyword to the 'match
route-map' command of communit-list and large-community-list.
> match community-list AAA any
> match large-community-list AAA any
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
We should not allow exceeding the stream's length, and also software version
can't be larger than 64 bytes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fix printing link state ospf opaque data. pnt address was not moving
in the loop.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix an issue where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568380 (#1 of 1): Untrusted value as argument (TAINTED_SCALAR)
> 9. tainted_data: Passing tainted expression length to bgp_linkstate_nlri_value_display, which uses it as an offset
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix issues where an attacker may inject a tainted length value to
corrupt the memory.
> CID 1568378 (#1-6 of 6): Untrusted value as argument (TAINTED_SCALAR)
> 16. tainted_data: Passing tainted expression length to bgp_linkstate_tlv_attribute_value_display, which uses it as an offset. [show details]
Fixes: 7e0d9ff8ba ("bgpd: display link-state prefixes detail")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix comparaison of link state attributes pointers in
link_state_hash_cmp().
> CID 1568379 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return false;.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix illegal memory access bgp_ls_tlv_check_size() if type is 1253.
> CID 1568377 (#4 of 4): Out-of-bounds read (OVERRUN)
> 5. overrun-local: Overrunning array bgp_linkstate_tlv_infos of 1253 16-byte elements at element index 1253 (byte offset 20063) using index type (which evaluates to 1253).
Fixes: 7e0d9ff8ba ("bgpd: display link-state prefixes detail")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix the following coverity issue. attr cannot be NULL.
> CID 1568376 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking attr suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
Fixes: 8b531b1107 ("bgpd: store and send bgp link-state attributes")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When we accept a connection, we try to set TTL for the socket, but the socket
is not yet created/assigned and we are trying to set it on the wrong socket fd.
```
[Event] connection from 127.0.0.1 fd 25, active peer status 3 fd -1
can't set sockopt IP_TTL 255 to socket -1
bgp_set_socket_ttl: Can't set TxTTL on peer (rtrid 0.0.0.0) socket, err = 9
Unable to set min/max TTL on peer 127.0.0.1, Continuing
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Avoid having something like this in outputs:
Before:
```
munet> r1 shi vtysh -c 'show bgp dampening damp'
BGP table version is 10, local router ID is 10.10.10.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 From Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 (null) 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 (null) 65002 ?
Displayed 5 routes and 5 total paths
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.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 From Flaps Duration Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 2 00:03:10 (null) 65002 ?
Displayed 5 routes and 5 total paths
```
After:
```
munet> r1 shi vtysh -c 'show bgp dampening damp '
BGP table version is 10, local router ID is 10.10.10.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 From Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 00:00:00 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 00:00:00 65002 ?
Displayed 5 routes and 5 total paths
munet> r1 shi vtysh -c 'show bgp dampening flap'
BGP table version is 10, local router ID is 10.10.10.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 From Flaps Duration Reuse Path
*d 2001:db8:1::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:2::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:3::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:4::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
*d 2001:db8:5::1/128
2001:db8::2 2 00:00:15 00:00:00 65002 ?
Displayed 5 routes and 5 total paths
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When BGP is sending updates to peers on a neighbor up event
it was noticed that the bgp updates being sent were in reverse
order being sent to the first peer.
Imagine r1 -- r2 -- r3. r1 and r2 are ebgp peers and
r2 and r3 are ebgp peers. r1's interface to r2 is currently
shutdown. Prior to this fix the send order would look like this:
r1 -> r2 send of routes to r2 and then they would be installed in order
received:
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r2 would then send these routes to r3 and then they would be installed
in order received:
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
Not that big of a deal right? Well imagine a situation where r1 is
originating several ten's of thousands of routes. It sends routes to r2
r2 is processing routes but in reverse order and at the same time it
is sending routes to r3, in the correct order of the bgp table.
r3 will have the early 10.0.0.1/32 routes installed and start forwarding
while r2 will not have those routes installed yet( since they were at the
end and zebra is slightly slower for processing routes than bgp is ).
Ensure that the order sent is a true FIFO. What is happening is that
there is an update fifo which stores all routes. And off that FIFO
is a bgp advertise attribute list which stores the list of prefixes
which share the same attribute that allow for more efficient packing
this list was being stored in reverse order causing the problem for
the initial send. When adding items to this list put them at the
end so we keep the fifo order that is traversed when we walk through
the bgp table.
After the fix:
r2 installation order:
10.0.0.0 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.1 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.2 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.3 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.4 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.5 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.6 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.7 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.8 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.9 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.10 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.11 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
10.0.0.12 nhid 39 via 192.168.8.2 dev leaf2-eth5 proto bgp metric 20
r3 installation order:
10.0.0.0 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.1 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.2 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.3 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.4 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.5 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.6 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.7 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.8 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.9 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.10 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.11 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
10.0.0.12 nhid 12 via 192.168.61.2 dev spine2-eth1 proto bgp metric 20
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Append zebra and lib to use muliple SRv6 segs SIDs, and keep one
seg SID for bgpd and sharpd.
Note: bgpd and sharpd compilation relies on the lib and zebra files,
i.e if we separate this: lib or zebra or bgpd or sharpd in different
commits - this will not compile.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
currently snmpwalk give results such :
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6z.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6z.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
the expected result is the following
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv4.10.125.0.2 = INTEGER: ipv4(1)
BGP4V2-MIB::bgp4V2PeerRemoteAddrType.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 =
INTEGER: ipv6(2)
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv4.10.125.0.2 = Hex-STRING: 0A 7D 00 02
BGP4V2-MIB::bgp4V2PeerRemoteAddr.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Hex
-STRING: FD 00 01 25 00 00 00 00 00 00 00 00 00 00 00 03
in draft-ietf-idr-bgp4-mibv2-11
INDEX for Bgp4V2PeerEntry is define as follows
INDEX {
bgp4V2PeerInstance,
bgp4V2PeerRemoteAddrType,
bgp4V2PeerRemoteAddr
}
the peer instance is defined as follows
OBJECT bgp4V2PeerInstance
SYNTAX Unsigned32 (1..4294967295)
more this interpretation is conformant with the snmpwalk implementation
for instance we obtain the following result
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemotePort.1.ipv6.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Gauge32: 179
swBgp.bgp4V2.bgp4V2Objects.bgp4V2PeerTable.bgp4V2PeerEntry.bgp4V2PeerRemoteAs.1.ipv4.10.125.0.2 = Gauge32: 65200
since currently we are not supporting multi instance for bgp peer in
SNMP the bgp4V2PeerInstance value is set to 1 coforming to:
"Implementations that do not support multiple routing instances should return 1 for this object."
test is updated accordingly to fix.
currently index for bgp4V2NlriEntry is not coformant to MIB definition
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
currently an snmpwalk gives:
BGP4V2-MIB::bgp4V2PeerFsmEstablishedTime.1.ipv6z.10.125.0.2 = Gauge32: 103 seconds
BGP4V2-MIB::bgp4V2PeerFsmEstablishedTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Gauge32: 103 seconds
but ipv6z and dns are not the valid address type this must be ipv4 and
ipv6.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
snmpwalk exhibit the followinfg errors:
BGP4V2-MIB::bgp4V2PeerLastErrorReceivedTime.1.ipv6z.10.125.0.2 = Wrong Type (should be Timeticks): Gauge32: 0
BGP4V2-MIB::bgp4V2PeerLastErrorReceivedTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Wrong Type (should be Timeticks): Hex-STRING: 00 00 00 00 00 00 00 00
BGP4V2-MIB::bgp4V2PeerLastErrorSentTime.1.ipv6z.10.125.0.2 = Wrong Type (should be Timeticks): Gauge32: 178
BGP4V2-MIB::bgp4V2PeerLastErrorSentTime.2.dns.253.0.1.37.0.0.0.0.0.0.0.0.0.0.0.3 = Wrong Type (should be Timeticks): Hex-STRING: B2 00 00 00 00 00 00 00
Error: OID not increasing: BGP4V2-MIB::bgp4V2NlriIndex.1.4.10.200."".0.24.10.125.0.2
>= BGP4V2-MIB::bgp4V2NlriIndex.1.4.10.200."".0.24."".0.0.0
draft-ietf-idr-bgp4-mibv2-11 states the following
bgp4V2PeerLastErrorReceivedTime OBJECT-TYPE
SYNTAX TimeStamp
bgp4V2PeerLastErrorSentTime OBJECT-TYPE
SYNTAX TimeStamp
we set the correct values
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Add the ability to store a raw copy of the incoming BGP Link-State
attributes and to redistribute them as is to other routes.
New types of data BGP_ATTR_LS and BGP_ATTR_LS_DATA are defined.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add the "show bgp link-state link-state" following commands:
> r3# show bgp link-state link-state ?
> <cr>
> all Display the entries for all address families
> detail-routes Display detailed version of all routes
> json JavaScript Object Notation
> neighbors Detailed information on TCP and BGP neighbor connections
> regexp Display routes matching the AS path regular expression
> summary Summary of BGP neighbor status
> version Display prefixes with matching version numbers
> wide Increase table width for longer prefixes
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the "bgp default link-state" command to the "router bgp" context.
> router bgp 65000
> bgp default link-state
When this command is set, the "link-state/link-state" AFI/SAFI is
activated on all neighbors that are directly specified within the
"router bgp" unless explicitly deactivated:
> router bgp 65000
> bgp default link-state
> neighbor 10.0.0.1 remote-as 65001
> address-family link-state link-state
> no neighbor 10.0.0.1 activate
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Link-state prefixes are only intended to be read for a link-state
consumer (i.e. a controler). They cannot be installed in Forwarding
Information Base (FIB).
Do not announce them to zebra.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
BGP link-state prefixes are displayed in the form of NLRI-TYPE /
Prefix-Length.
> r2# show bgp all
>
> For address family: Link State
> BGP table version is 8, local router ID is 192.0.2.2, vrf id 0
> Default local pref 100, local AS 65002
> Network Next Hop Metric LocPrf Weight Path
> *> Link/153 0 65001 i
> *> IPv6-Prefix/77 0 65001 i
> *> IPv4-Prefix/57 0 65001 i
> *> Node/49 0 65001 i
> *> Node/45 0 65001 i
Add a lib prefix display hook in bgpd to display properly all the details.
> r2# show bgp all
>
> For address family: Link State
> BGP table version is 8, local router ID is 192.0.2.2, vrf id 0
> Default local pref 100, local AS 65002
> Network Next Hop Metric LocPrf Weight Path
> *> Link OSPFv3 ID:0xffffffffffffffff {Local {AS:4294967295 ID:4294967295 Area:4294967295 Rtr:10.10.10.11:2.2.2.2} Remote {AS:4294967295 ID:4294967295 Area:4294967295 Rtr:10.10.10.10:1.1.1.1} IPv4:10.1.0.1 Neigh-IPv4:10.1.0.2 IPv6:2001::1 Neigh-IPv6:2001::2 MT:0,2}/153
> 0 65001 i
> *> IPv6-Prefix OSPFv3 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10} MT:2 OSPF-Route-Type:1 IPv6:12:12::12:12/128}/77
> 0 65001 i
> *> IPv4-Prefix OSPFv2 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10:1.1.1.1} IPv4:89.10.11.0/24}/57
> 0 65001 i
> *> Node OSPFv2 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10:1.1.1.1}}/49
> 0 65001 i
> *> Node OSPFv2 ID:0x20 {Local {AS:65001 ID:0 Area:0 Rtr:10.10.10.10}}/45
> 0 65001 i
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When displaying the link-state prefixes with "show bgp link-state
link-state" command, the following output headers are not needed:
> 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
Do not display these headers for link-state SAFI.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
BGP Link-State prefixes are special prefixes that contains a lot of
data.
Extend the length of the prefix string buffer in order to display
properly this type of prefixes with the next commits.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Add the ability to send link-state prefixes that are in the BGP table.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add the ability to store link-state prefixes in the BGP table.
Store a raw copy of the BGP link state NLRI TLVs as received in the
packet in 'p.u.prefix_linkstate.ptr'.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
To show the TCP MSS value per neighbor you have to configure it, otherwise you
don't see the actual value.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Accept the BGP Link-State AFI/SAFI capability when received from a peer
OPEN message.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
following crash occurs:
at ./nptl/pthread_kill.c:44
at ./nptl/pthread_kill.c:78
at ./nptl/pthread_kill.c:89
context=0x7ffd06d3d300)
at /build/make-pkg/output/_packages/cp-routing/src/lib/sigevent.c:246
length=0x7ffd06d3da88, exact=1, var_len=0x7ffd06d3da90, write_method=<optimized out>)
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_snmp_bgp4v2.c:364
vp=vp@entry=0x7f7c88b584c0 <bgpv2_variables>, vp_len=vp_len@entry=102,
ename=ename@entry=0x7f7c88b58440 <bgpv2_trap_oid>, enamelen=enamelen@entry=8,
name=name@entry=0x7f7c88b58480 <bgpv2_oid>, namelen=namelen@entry=7,
iname=0x7ffd06d3e7b0, index_len=1, trapobj=0x7f7c88b53b80 <bgpv2TrapBackListv6>,
trapobjlen=6, sptrap=2 '\002')
at /build/make-pkg/output/_packages/cp-routing/src/lib/agentx.c:382
vp_len=vp_len@entry=102, ename=ename@entry=0x7f7c88b58440 <bgpv2_trap_oid>,
enamelen=enamelen@entry=8, name=name@entry=0x7f7c88b58480 <bgpv2_oid>,
namelen=namelen@entry=7, iname=0x7ffd06d3ec30, inamelen=16,
trapobj=0x7f7c88b53b80 <bgpv2TrapBackListv6>, trapobjlen=6, sptrap=2 '\002')
at /build/make-pkg/output/_packages/cp-routing/src/lib/agentx.c:298
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_snmp_bgp4v2.c:1496
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:48
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:1314
event=Receive_NOTIFICATION_message)
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_fsm.c:2665
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_packet.c:3129
at /build/make-pkg/output/_packages/cp-routing/src/lib/event.c:1979
at /build/make-pkg/output/_packages/cp-routing/src/lib/libfrr.c:1213
at /build/make-pkg/output/_packages/cp-routing/src/bgpd/bgp_main.c:510
it's due to function bgpv2PeerErrorsTable returning
return SNMP_STRING(msg_str);
with msg_str NULL rather the string ""
this commit avoid the issue.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
If we modify as-path with route-map and prepend with private ASNs, then we
advertise a new as-path without stripping private ASNs. Let's fix this, and
remove private ASNs despite if they were sent by the origin or prepended locally.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Not sure why this is needed, because it's reset on bgp_connect_success(),
when the session is UP.
When the session is reset, it clears those variables, and we are not able to
see what remote address was before, etc.
hostLocal, hostRemote reports Unknown for `show bgp neighbor json`.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The 'redistribute table' command can be used by configuration on a
non default BGP instance, but this command does not work for multiple
reasons:
- The route entries configured on a given table are always configured
from the default vrf. This constraint prevents from redistributing a
prefix from the default vrf to an other non default bgp instance.
- The importation of route entries requires 'ip import-table' on vrfs
and this command is not available
Fix this by preventing from configuring this kind of redistribution
on non default bgp instances.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
LLGR stale time is exchanged using OPEN messages. In order to
reduce stal time before doing an actual graceful restart + LLGR, it might be useful
to increase the time, but this is not possible without resetting the session.
With this change, it's possible to send dynamic capability with a new value, and
GR will respect a new reset time value when LLGR kicks in.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The BGP "no retain" VPN option avoids storing VPN prefixes that are not
imported in the incoming BGP table (aka. Adj RIB in). When a VPN import
policy is changed, BGP does a soft clear so that a prefix refresh is
requested from the peers. However, the import from local VPN prefixes
is never requested.
Fix this issue by requesting a local import refresh.
Fixes: a486300b26 ("bgpd: implement retain route-target all behaviour")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
https://www.rfc-editor.org/rfc/rfc2042.html
says: 255 reserved for development
In FRR, 255 is kinda used too BGP_ATTR_VNC, even more we allow setting 255 in CLI.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The pdest pointer is locked by the bgp_node_get so
unlocking it should be fine and it should still exist.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
dest could be freed by the first unlock, but should
not be due to our locking structure. Ensure coverity
understands this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Unsetting a flag after the dest has been possibly been
freed is not a good thing to do. Ensure that this
is not possible.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is incase it has been freed ( it wont due to locking )
and then we need to ensure that we can continue to use
the pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Again coverity believes that dest could be freed by a call
into bgp_dest_unlock_node, and it can if the lock count
is wrong. Let's fix that assumption for coverity
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The bgp_cleanup_routes function holds the lock for dest
while walking it. Ensure that coverity understands this
proposition.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Again the dest pointer should be still locked by the table walk. Ensure
that coverity is happy that this is not happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Again coverity believes that dest may be freed but it should not
be because of how locking is done. Make coverity happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The dest pointer may be freed( but should not be
due to locking ). Let's ensure that this assumption
is true and make coverity happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exist two spots in this function where the dest could be
freed, but is not due to locking, but coverity thinks it might
so let's make the function happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
But never really does due to locking, but since it can
we need to treat it like it does and ensure that FRR
is not making a mistake, by using memory after it
has been freed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
dest will not be freed due to lock but coverity does not know
that. Give it a hint. This change includes modifying bgp_dest_unlock_node
to return the dest pointer so that we can determine if we should
continue working on dest or not with an assert. Since this
is lock based we should be ok.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Pass through a bunch of BGP_EVENT_ADD's and make
the code use a proper connection instead of a
peer->connection. There still are a bunch
of places where peer->connection is used and
later commits will probably go through and
clean these up more.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify all the receive functions to pass around the actual
connection being acted upon. Modify the collision detection
function to look at the possible two connections.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Modify bgp_fsm_change_status to be connection oriented and
also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection
oriented as well. Attempt to make peer_xfer_conn a bit more
understandable because, frankly it was/is confusing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of BGP_EVENT_FLUSH is unnecessarily abstracting the
call into event_cancel_event_ready and in addtion the macro
was not always being used! Just convert to using the actual
event_cancel_event_ready function directly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently evpn passes into bgp_path_info_cmp the pfx_buf
uninitialized. The bgp_path_info_cmp functionality actually
expects this value to be initialized. Additionally the
evpn section of bgp_path_info_comp was resetting the
new_buf and exist_buf values that were already being
set above to the same values if !debug was on( which
precluded it ever from happening )
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
rfc7606 defines:
Attributes 17 (AS4_PATH), 18 (AS4_AGGREGATOR), 22 (PMSI_TUNNEL), 23 (Tunnel
Encapsulation Attribute), 26 (AIGP), 27 (PE Distinguisher Labels),
and 29 (BGP-LS Attribute) do have error handling consistent with
Section 8 and thus are not further discussed herein.
Section 8 defines:
The "treat-as-withdraw" approach is generally
preferred and the "session reset" approach is discouraged.
For any malformed attribute that is handled by the "attribute
discard" instead of the "treat-as-withdraw" approach, it is critical
to consider the potential impact of doing so.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
https://datatracker.ietf.org/doc/html/rfc6514#page-10 states:
A router that supports the PMSI Tunnel attribute considers this
attribute to be malformed if either (a) it contains an undefined
tunnel type in the Tunnel Type field of the attribute, or (b) the
router cannot parse the Tunnel Identifier field of the attribute as a
tunnel identifier of the tunnel types specified in the Tunnel Type
field of the attribute.
When a router that receives a BGP Update that contains the PMSI
Tunnel attribute with its Partial bit set determines that the
attribute is malformed, the router SHOULD treat this Update as though
all the routes contained in this Update had been withdrawn.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The command "show bgp all rpki notfound" includes not only RPKI
notfound routes but also RPKI valid and invalid routes in its results.
Fix the code to display only RPKI notfound routes.
Old output:
```
frr# show bgp all rpki notfound
For address family: IPv4 Unicast
BGP table version is 0, local router ID is 10.0.0.1, vrf id 0
Default local pref 100, local AS 64512
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
N x.x.x.0/18 a.a.a.a 100 0 64513 i
V y.y.y.0/19 a.a.a.a 200 0 64513 i
I z.z.z.0/16 a.a.a.a 10 0 64513 i
Displayed 3 routes and 3 total paths
```
New output:
```
frr# show bgp all rpki notfound
For address family: IPv4 Unicast
BGP table version is 0, local router ID is 10.0.0.1, vrf id 0
Default local pref 100, local AS 64512
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
N x.x.x.0/18 a.a.a.a 100 0 64513 i
Displayed 1 routes and 3 total paths
```
Signed-off-by: Ryo Nakano <ryo.z.nakano@gmail.com>
It was noticed that occassionally peering failed in a testbed
upon investigation it was found that the peer was not in the
peer hash and we saw these failure messages:
Aug 25 21:31:15 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: %NOTIFICATION: sent to neighbor 2001:cafe:1ead:4::4 4/0 (Hold Timer Expired) 0 bytes
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] Can't get remote address and port: Transport endpoint is not connected
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] %bgp_getsockname() failed for peer 2001:cafe:1ead:4::4 fd 27 (from_peer fd -1)
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 33554464] %Neighbor failed in xfer_conn
root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# vtysh -c 'show bgp peerhash' | grep 2001:cafe:1ead:4::4
root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr#
Upon looking at the code the peer_xfer_conn function can fail
and the bgp_establish code will then return before adding the
peer back to the peerhash.
This is only part of the failure. The peer also appears to
be in a state where it is no longer initiating connection attempts
but that will be another commited fix when we figure that one out.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Graceful-Restart restart time is exchanged using OPEN messages. In order to
reduce restart time before doing an actual graceful restart, it might be useful
to increase the time, but this is not possible without resetting the session.
With this change, it's possible to send dynamic capability with a new value, and
GR will respect a new reset time value.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
It was noticed that occassionally peering failed in a testbed
upon investigation it was found that the peer was not in the
peer hash and we saw these failure messages:
Aug 25 21:31:15 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: %NOTIFICATION: sent to neighbor 2001:cafe:1ead:4::4 4/0 (Hold Timer Expired) 0 bytes
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] Can't get remote address and port: Transport endpoint is not connected
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] %bgp_getsockname() failed for peer 2001:cafe:1ead:4::4 fd 27 (from_peer fd -1)
Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 33554464] %Neighbor failed in xfer_conn
root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# vtysh -c 'show bgp peerhash' | grep 2001:cafe:1ead:4::4
root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr#
Upon looking at the code the peer_xfer_conn function can fail
and the bgp_establish code will then return before adding the
peer back to the peerhash.
This is only part of the failure. The peer also appears to
be in a state where it is no longer initiating connection attempts
but that will be another commited fix when we figure that one out.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Capability was unset, but forgot to unset the role.
Fixes: 5ad080d37a ("bgpd: Handle Role capability via dynamic capabilities for SET/UNSET properly")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before this path we used session reset method, which is discouraged by rfc7606.
Handle this as rfc requires.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
```
donatas-pc(config-router)# timers bgp 8 12
% keeplive value 8 is larger than 1/3 of the holdtime, setting to 4
donatas-pc(config-router)# do sh run | include timers bgp
timers bgp 4 12
donatas-pc(config-router)#
```
Closes https://github.com/FRRouting/frr/issues/14287
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When the BGP 'redistribute table' command is used for a given route
table, and BGP configuration is flushed and rebuilt, the redistribution
does not work.
Actually, when flushing the BGP configuration with the 'no router bgp'
command, the BGP redistribute entries related to the 'redistribute table'
entries are not flushed. Actually, at BGP deletion, the table number is
not given as parameter in bgp_redistribute_unset() function, and the
redistribution entry is not removed in zebra.
Fix this by adding some code to flush all the redistribute table
instances.
Fixes: 7c8ff89e93 ("Multi-Instance OSPF Summary")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It was missed to handle UNSET Role capability using dynamic capabilities.
Also move length check before actually handling Role capability.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When bgp_stop finishes and it deletes the peer it is sending
back a return code stating that the peer was deleted, but
the code was operating like it was not deleted and continued
to access the data structure. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The return code from a event handling perspective
is an enum. Let's intentionally make it a switch
so that all cases are ensured to be covered now
and in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Straighten out the code to not mix the two. Especially
since bgp was assigning non enum values to the enum.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Shouldn't validate the label after 'decode_label'. If we validate
the label after 'decode_label', even the 'MPLS_INVALID_LABEL' will
be valid then.
Signed-off-by: Valerian_He <1826906282@qq.com>
```
3 0x00007f423aa42476 in __GI_raise (sig=sig@entry=11) at ../sysdeps/posix/raise.c:26
4 0x00007f423aef9740 in core_handler (signo=11, siginfo=0x7fffc414deb0, context=<optimized out>) at lib/sigevent.c:246
5 <signal handler called>
6 0x0000564dea2fc71e in route_set_aspath_prepend (rule=0x564debd66d50, prefix=0x7fffc414ea30, object=0x7fffc414e400)
at bgpd/bgp_routemap.c:2258
7 0x00007f423aeec7e0 in route_map_apply_ext (map=<optimized out>, prefix=prefix@entry=0x7fffc414ea30,
match_object=match_object@entry=0x7fffc414e400, set_object=set_object@entry=0x7fffc414e400, pref=pref@entry=0x0) at lib/routemap.c:2690
8 0x0000564dea2d277e in bgp_input_modifier (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, attr=attr@entry=0x7fffc414e770,
afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_UNICAST, rmap_name=rmap_name@entry=0x0, label=0x0, num_labels=0, dest=0x564debdd5130)
at bgpd/bgp_route.c:1772
9 0x0000564dea2df762 in bgp_update (peer=peer@entry=0x7f4238f59010, p=p@entry=0x7fffc414ea30, addpath_id=addpath_id@entry=0,
attr=0x7fffc414eb50, afi=afi@entry=AFI_IP, safi=<optimized out>, safi@entry=SAFI_UNICAST, type=9, sub_type=0, prd=0x0, label=0x0,
num_labels=0, soft_reconfig=0, evpn=0x0) at bgpd/bgp_route.c:4374
10 0x0000564dea2e2047 in bgp_nlri_parse_ip (peer=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50, packet=0x7fffc414eaf0)
at bgpd/bgp_route.c:6249
11 0x0000564dea2c5a58 in bgp_nlri_parse (peer=peer@entry=0x7f4238f59010, attr=attr@entry=0x7fffc414eb50,
packet=packet@entry=0x7fffc414eaf0, mp_withdraw=mp_withdraw@entry=false) at bgpd/bgp_packet.c:339
12 0x0000564dea2c5d66 in bgp_update_receive (peer=peer@entry=0x7f4238f59010, size=size@entry=109) at bgpd/bgp_packet.c:2024
13 0x0000564dea2c901d in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:2933
14 0x00007f423af0bf71 in event_call (thread=thread@entry=0x7fffc414ee40) at lib/event.c:1995
15 0x00007f423aebb198 in frr_run (master=0x564deb73c670) at lib/libfrr.c:1213
16 0x0000564dea261b83 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:505
```
With the configuration:
```
frr version 9.1-dev-MyOwnFRRVersion
frr defaults traditional
hostname ip-172-31-13-140
log file /tmp/debug.log
log syslog
service integrated-vtysh-config
!
debug bgp keepalives
debug bgp neighbor-events
debug bgp updates in
debug bgp updates out
!
router bgp 100
bgp router-id 9.9.9.9
no bgp ebgp-requires-policy
bgp bestpath aigp
neighbor 172.31.2.47 remote-as 200
!
address-family ipv4 unicast
neighbor 172.31.2.47 default-originate
neighbor 172.31.2.47 route-map RM_IN in
exit-address-family
exit
!
route-map RM_IN permit 10
set as-path prepend 200
exit
!
```
The issue is that we try to process NLRIs even if the attribute length is 0.
Later bgp_update() will handle route-maps and a crash occurs because all the
attributes are NULL, including aspath, where we dereference.
According to the RFC 4271:
A value of 0 indicates that neither the Network Layer
Reachability Information field nor the Path Attribute field is
present in this UPDATE message.
But with a fuzzed UPDATE message this can be faked. I think it's reasonable
to skip processing NLRIs if both update_len and attribute_len are 0.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is based on @donaldsharp's work
The current code base is the struct bgp_node data structure.
The problem with this is that it creates a bunch of
extra data per route_node.
The table structure generates ‘holder’ nodes
that are never going to receive bgp routes,
and now the memory of those nodes is allocated
as if they are a full bgp_node.
After splitting up the bgp_node into bgp_dest and route_node,
the memory of ‘holder’ node which does not have any bgp data
will be allocated as the route_node, not the bgp_node,
and the memory usage is reduced.
The memory usage of BGP node will be reduced from 200B to 96B.
The total memory usage optimization of this part is ~16.00%.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
For v4 nexthops, ifindex was being set. Modified the check to set
ifindex only for v6 nexthops. Also modified the check to set ifindex
only if the v6 nexthop matches peer's LL address.
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Make sure we don't exceed the maximum of BGP_MAX_SOFT_VERSION.
The Capability Length SHOULD be no greater than 64.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Found when fuzzing:
```
==3470861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xffff77801ef7 at pc 0xaaaaba7b3dbc bp 0xffffcff0e760 sp 0xffffcff0df50
READ of size 2 at 0xffff77801ef7 thread T0
0 0xaaaaba7b3db8 in __asan_memcpy (/home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgpd+0x363db8) (BuildId: cc710a2356e31c7f4e4a17595b54de82145a6e21)
1 0xaaaaba81a8ac in ptr_get_be16 /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/./lib/stream.h:399:2
2 0xaaaaba819f2c in bgp_attr_aigp_valid /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:504:3
3 0xaaaaba808c20 in bgp_attr_aigp /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3275:7
4 0xaaaaba7ff4e0 in bgp_attr_parse /home/ubuntu/frr_8_5_2/frr_8_5_2_fuzz_clang/bgpd/bgp_attr.c:3678:10
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Properly free the dynamically allocated memory held by `str` after its use.
The change also maintains the return value of `nb_cli_apply_changes` by using `ret` variable.
The ASan leak log for reference:
```
Direct leak of 55 byte(s) in 2 object(s) allocated from:
#0 0x7f16f285f867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f16f23fda11 in qmalloc ../lib/memory.c:100
#2 0x7f16f23a01a0 in frrstr_join ../lib/frrstr.c:89
#3 0x7f16f23418c7 in argv_concat ../lib/command.c:183
#4 0x55aba24731f2 in set_aspath_exclude_access_list_magic ../bgpd/bgp_routemap.c:6327
#5 0x55aba2455cf4 in set_aspath_exclude_access_list bgpd/bgp_routemap_clippy.c:836
#6 0x7f16f2345d61 in cmd_execute_command_real ../lib/command.c:993
#7 0x7f16f23460ee in cmd_execute_command ../lib/command.c:1052
#8 0x7f16f2346dc0 in cmd_execute ../lib/command.c:1218
#9 0x7f16f24f7197 in vty_command ../lib/vty.c:591
#10 0x7f16f24fc07c in vty_execute ../lib/vty.c:1354
#11 0x7f16f250247a in vtysh_read ../lib/vty.c:2362
#12 0x7f16f24e72f4 in event_call ../lib/event.c:1979
#13 0x7f16f23d1828 in frr_run ../lib/libfrr.c:1213
#14 0x55aba2269e52 in main ../bgpd/bgp_main.c:510
#15 0x7f16f1dbfd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
The BGP FSM was using the peer as the unit of work
but the FSM is connection focused. So let's switch
it over to using that.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
As part of the conversion to a `struct peer_connection` it will
be desirable to have 2 pointers one for when we open a connection
and one for when we receive a connection. Start this actual
conversion over to this in `struct peer`. If this sounds confusing
take a look at the bgp state machine for connections and how
it resolves the processing of this router opening -vs- this
router receiving an open. At some point in time the state
machine decides that we are keeping one of the two connections.
Future commits will allow us to untangle the peer/doppelganger
duality with this abstraction.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The status and ostatus are a function of the `struct peer_connection`
move it into that data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move PEER_THREAD_WRITES_ON and PEER_THREAD_READS_ON to
be a part of the `struct peer_connection` since this is
a connection oriented bit of data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move the peer->t_write and peer->t_read into `struct peer_connection`
as that these are properties of the connection.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
P# Please enter the commit message for your changes. Lines starting
BGP tracks connections based upon the peer. But the problem
with this is that the doppelganger structure for it is being
created. This has introduced a bunch of fragileness in that
the peer exists independently of the connections to it.
The whole point of the doppelganger structure was to allow
BGP to both accept and initiate tcp connections and then
when we get one to a `good` state we collapse into the
appropriate one. The problem with this is that having
2 peer structures for this creates a situation where
we have to make sure we are configing the `right` one
and also make sure that we collapse the two independent
peer structures into 1 acting peer. This makes no sense
let's abstract out the peer into having 2 connection
one for incoming connections and one for outgoing connections
then we can easily collapse down without having to do crazy
stuff. In addition people adding new features don't need
to have to go touch a million places in the code.
This is the start of this abstraction. In this commit
we'll just pull out the fd and input/output buffers
into a connection data structure. Future commits
will abstract further.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Properly free the dynamically allocated memory held by `str` after its use.
The change also maintains the return value of `nb_cli_apply_changes` by using 'ret' variable.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_set_aspath_replace.test_bgp_set_aspath_replace/r1.asan.bgpd.11586
=================================================================
==11586==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 92 byte(s) in 3 object(s) allocated from:
#0 0x7f4e2951db40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f4e28f19ea2 in qmalloc lib/memory.c:100
#2 0x7f4e28edbb08 in frrstr_join lib/frrstr.c:89
#3 0x7f4e28e9a601 in argv_concat lib/command.c:183
#4 0x56519adf8413 in set_aspath_replace_access_list_magic bgpd/bgp_routemap.c:6174
#5 0x56519adf8942 in set_aspath_replace_access_list bgpd/bgp_routemap_clippy.c:683
#6 0x7f4e28e9d548 in cmd_execute_command_real lib/command.c:993
#7 0x7f4e28e9da0c in cmd_execute_command lib/command.c:1051
#8 0x7f4e28e9de8b in cmd_execute lib/command.c:1218
#9 0x7f4e28fc4f1c in vty_command lib/vty.c:591
#10 0x7f4e28fc53c7 in vty_execute lib/vty.c:1354
#11 0x7f4e28fcdc8d in vtysh_read lib/vty.c:2362
#12 0x7f4e28fb8c8b in event_call lib/event.c:1979
#13 0x7f4e28efd445 in frr_run lib/libfrr.c:1213
#14 0x56519ac85d81 in main bgpd/bgp_main.c:510
#15 0x7f4e27f40c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 92 byte(s) leaked in 3 allocation(s).
***********************************************************************************
***********************************************************************************
Address Sanitizer Error detected in bgp_set_aspath_exclude.test_bgp_set_aspath_exclude/r1.asan.bgpd.10385
=================================================================
==10385==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 55 byte(s) in 2 object(s) allocated from:
#0 0x7f6814fdab40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f68149d6ea2 in qmalloc lib/memory.c:100
#2 0x7f6814998b08 in frrstr_join lib/frrstr.c:89
#3 0x7f6814957601 in argv_concat lib/command.c:183
#4 0x5570e05117a1 in set_aspath_exclude_access_list_magic bgpd/bgp_routemap.c:6327
#5 0x5570e05119da in set_aspath_exclude_access_list bgpd/bgp_routemap_clippy.c:836
#6 0x7f681495a548 in cmd_execute_command_real lib/command.c:993
#7 0x7f681495aa0c in cmd_execute_command lib/command.c:1051
#8 0x7f681495ae8b in cmd_execute lib/command.c:1218
#9 0x7f6814a81f1c in vty_command lib/vty.c:591
#10 0x7f6814a823c7 in vty_execute lib/vty.c:1354
#11 0x7f6814a8ac8d in vtysh_read lib/vty.c:2362
#12 0x7f6814a75c8b in event_call lib/event.c:1979
#13 0x7f68149ba445 in frr_run lib/libfrr.c:1213
#14 0x5570e03a0d81 in main bgpd/bgp_main.c:510
#15 0x7f68139fdc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 55 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Problem:
On GR helper, paths learnt from an interface based peer were linked
to bnc with ifindex=0. During restart of GR peer, BGP (unnumbered)
session (with GR restarter peer) goes down on GR helper but the routes
are retained. Later, when BGP receives an interface up event, it
will process all the paths associated with BNC whose ifindex matches the
ifindex of the interface for which UP event is received. However, paths
associated with bnc that has ifindex=0 were not being reinstalled since
ifindex=0 doesn't match ifindex of any interfaces. This results in
BGP routes not being reinstalled in zebra and kernel.
Fix:
For paths learnt from an interface based peer, set the
ifindex to peer's interface ifindex so that correct
peer based nexthop can be found and linked to the path.
Signed-off-by: Donald Sharp sharpd@nvidia.com
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Relax this handling (RFC 7606) only for eBGP peers.
More details: https://datatracker.ietf.org/doc/html/rfc7606#section-4
There are two error cases in which the Total Attribute Length value
can be in conflict with the enclosed path attributes, which
themselves carry length values:
* In the first case, the length of the last encountered path
attribute would cause the Total Attribute Length to be exceeded
when parsing the enclosed path attributes.
* In the second case, fewer than three octets remain (or fewer than
four octets, if the Attribute Flags field has the Extended Length
bit set) when beginning to parse the attribute. That is, this
case exists if there remains unconsumed data in the path
attributes but yet insufficient data to encode a single minimum-
sized path attribute. <<<< HANDLING THIS CASE IN THIS COMMIT >>>>
In either of these cases, an error condition exists and the "treat-
as-withdraw" approach MUST be used (unless some other, more severe
error is encountered dictating a stronger approach), and the Total
Attribute Length MUST be relied upon to enable the beginning of the
NLRI field to be located.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Before the patch:
```
donatas-laptop(config-router)# bgp confederation
identifier AS number in plain <1-4294967295> or dotted <0-65535>.<0-65535> format
peers Peer ASs in BGP confederation
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
