To avoid USE:
```
==587645==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000074050 at pc 0x55b34337d96c bp 0x7ffda59bb4c0 sp 0x7ffda59bb4b0
READ of size 8 at 0x604000074050 thread T0
0 0x55b34337d96b in bgp_attr_flush bgpd/bgp_attr.c:1289
1 0x55b34368ef85 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:111
2 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
3 0x7f7d41cdf81c in event_call lib/event.c:1980
4 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
5 0x55b343371e22 in main bgpd/bgp_main.c:510
6 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
7 0x55b3433769fd in _start (/usr/lib/frr/bgpd+0x2e29fd)
0x604000074050 is located 0 bytes inside of 40-byte region [0x604000074050,0x604000074078)
freed by thread T0 here:
#0 0x7f7d4207540f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122
1 0x55b343396afd in community_free bgpd/bgp_community.c:41
2 0x55b343396afd in community_free bgpd/bgp_community.c:28
3 0x55b343397373 in community_intern bgpd/bgp_community.c:458
4 0x55b34337bed4 in bgp_attr_intern bgpd/bgp_attr.c:967
5 0x55b34368165b in bgp_advertise_attr_intern bgpd/bgp_advertise.c:106
6 0x55b3435277d7 in bgp_adj_out_set_subgroup bgpd/bgp_updgrp_adv.c:587
7 0x55b34368f36b in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:125
8 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
9 0x7f7d41cdf81c in event_call lib/event.c:1980
10 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
11 0x55b343371e22 in main bgpd/bgp_main.c:510
12 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7f7d42075a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7f7d41c3c28e in qcalloc lib/memory.c:105
2 0x55b3433976e8 in community_dup bgpd/bgp_community.c:514
3 0x55b34350273a in route_set_community bgpd/bgp_routemap.c:2589
4 0x7f7d41c96c06 in route_map_apply_ext lib/routemap.c:2690
5 0x55b34368f2d8 in bgp_conditional_adv_routes bgpd/bgp_conditional_adv.c:107
6 0x55b34368ff58 in bgp_conditional_adv_timer bgpd/bgp_conditional_adv.c:301
7 0x7f7d41cdf81c in event_call lib/event.c:1980
8 0x7f7d41c1da37 in frr_run lib/libfrr.c:1214
9 0x55b343371e22 in main bgpd/bgp_main.c:510
10 0x7f7d41517082 in __libc_start_main ../csu/libc-start.c:308
```
And also a crash:
```
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
1 0x00007ff3b7048ce0 in core_handler (signo=6, siginfo=0x7ffc8cf724b0, context=<optimized out>)
at lib/sigevent.c:246
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
4 0x00007ff3b6bb8859 in __GI_abort () at abort.c:79
5 0x00007ff3b6c2326e in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7ff3b6d4d298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
6 0x00007ff3b6c2b2fc in malloc_printerr (
str=str@entry=0x7ff3b6d4f628 "double free or corruption (fasttop)") at malloc.c:5347
7 0x00007ff3b6c2cc65 in _int_free (av=0x7ff3b6d82b80 <main_arena>, p=0x555c8fa70a10, have_lock=0)
at malloc.c:4266
8 0x0000555c8da94bd3 in community_free (com=0x7ffc8cf72e70) at bgpd/bgp_community.c:41
9 community_free (com=com@entry=0x7ffc8cf72e70) at bgpd/bgp_community.c:28
10 0x0000555c8da8afc1 in bgp_attr_flush (attr=attr@entry=0x7ffc8cf73040) at bgpd/bgp_attr.c:1290
11 0x0000555c8dbc0760 in bgp_conditional_adv_routes (peer=peer@entry=0x555c8fa627c0,
afi=afi@entry=AFI_IP, safi=SAFI_UNICAST, table=table@entry=0x555c8fa510b0, rmap=0x555c8fa71cb0,
update_type=UPDATE_TYPE_ADVERTISE) at bgpd/bgp_conditional_adv.c:111
12 0x0000555c8dbc0b75 in bgp_conditional_adv_timer (t=<optimized out>)
at bgpd/bgp_conditional_adv.c:301
13 0x00007ff3b705b84c in event_call (thread=thread@entry=0x7ffc8cf73440) at lib/event.c:1980
14 0x00007ff3b700bf98 in frr_run (master=0x555c8f27c090) at lib/libfrr.c:1214
15 0x0000555c8da85f05 in main (argc=<optimized out>, argv=0x7ffc8cf736a8) at bgpd/bgp_main.c:510
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d410587bab)
I recieve the following error with GCC 9.4.0:
```
In file included from /usr/include/string.h:495,
from ./lib/zebra.h:23,
from bgpd/bgp_snmp_bgp4v2.c:7:
In function ‘memset’,
inlined from ‘bgp4v2PathAttrLookup’ at bgpd/bgp_snmp_bgp4v2.c:605:3,
inlined from ‘bgp4v2PathAttrTable’ at bgpd/bgp_snmp_bgp4v2.c:747:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10: error: ‘__builtin_memset’ offset [9, 20] from the object at ‘paddr’ is out of the bounds of referenced subobject ‘_v4_addr’ with type ‘struct in_addr’ at offset 4 [-Werror=array-bounds]
71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(cherry picked from commit 6eb79dd6f2)
We shouldn't set it blindly once the packet is received, but first we have to
do some sanity checks.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
With a BGP configuration with ipv4 peering, and ipv6 peering, an snmpwalk
is stopped while walking over the bgp4v2NlriTable
snmpwalk -c TEST -v2c -On -Ln 1.1.1.2 .1.3.6.1.3.5.1.1.4
[...]
.1.3.6.1.3.5.1.1.4.1.2.1.2.32.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = Gauge32: 13380
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0 = Gauge32: 0
>= .1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.1.0.24.0.0.0.0
The walk stopped because the index used in the NlriTable entries is
decrementing, and this is against the snmp specifications. Also, the
computed index is wrong, and does not match the provided
draft-ietf-idr-bgp4-mibv2-1 specification.
Fix this by computing a valid index, and by finding out the next
consecutive prefix.
The resulting changes do not break the walk, and the output is changed:
root@dut-vm:~# snmpwalk -v 2c -c public -Ln -On localhost 1.3.6.1.3.5.1.1.9.1
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.1.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Gauge32: 0
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.2.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.3.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.4.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = INTEGER: 1
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.200.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A C8 00 00
.1.3.6.1.3.5.1.1.9.1.5.1.1.1.1.10.244.0.0.24.1.10.125.0.2.1 = Hex-STRING: 0A F4 00 00
Fixes: c681e937d7 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 1)
Fixes: 2ce69011c4 (bgpd: Implement SNMP
BGP4V2-MIB (bgp4V2NlriTable), part 2)
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit fc3c9b177c)
If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.
In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.
In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c37119df45)
Treat-as-withdraw, otherwise if we just ignore it, we will pass it to be
processed as a normal UPDATE without mandatory attributes, that could lead
to harmful behavior. In this case, a crash for route-maps with the configuration
such as:
```
router bgp 65001
no bgp ebgp-requires-policy
neighbor 127.0.0.1 remote-as external
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 ebgp-multihop
neighbor 127.0.0.1 disable-connected-check
neighbor 127.0.0.1 update-source 127.0.0.2
neighbor 127.0.0.1 timers 3 90
neighbor 127.0.0.1 timers connect 1
!
address-family ipv4 unicast
neighbor 127.0.0.1 addpath-tx-all-paths
neighbor 127.0.0.1 default-originate
neighbor 127.0.0.1 route-map RM_IN in
exit-address-family
exit
!
route-map RM_IN permit 10
set as-path prepend 200
exit
```
Send a malformed optional transitive attribute:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff002b0200000003c0ff00010100eb00ac100b0b001ad908ac100b0b")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(100)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 6814f2e013)
If we send a crafted BGP UPDATE message without mandatory attributes, we do
not check if the length of the path attributes is zero or not. We only check
if attr->flag is at least set or not. Imagine we send only unknown transit
attribute, then attr->flag is always 0. Also, this is true only if graceful-restart
capability is received.
A crash:
```
bgpd[7834]: [TJ23Y-GY0RH] 127.0.0.1 Unknown attribute is received (type 31, length 16)
bgpd[7834]: [PCFFM-WMARW] 127.0.0.1(donatas-pc) rcvd UPDATE wlen 0 attrlen 20 alen 17
BGP[7834]: Received signal 11 at 1698089639 (si_addr 0x0, PC 0x55eefd375b4a); aborting...
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x6d) [0x7f3205ca939d]
BGP[7834]: /usr/local/lib/libfrr.so.0(zlog_signal+0xf3) [0x7f3205ca9593]
BGP[7834]: /usr/local/lib/libfrr.so.0(+0xf5181) [0x7f3205cdd181]
BGP[7834]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12980) [0x7f3204ff3980]
BGP[7834]: /usr/lib/frr/bgpd(+0x18ab4a) [0x55eefd375b4a]
BGP[7834]: /usr/local/lib/libfrr.so.0(route_map_apply_ext+0x310) [0x7f3205cd1290]
BGP[7834]: /usr/lib/frr/bgpd(+0x163610) [0x55eefd34e610]
BGP[7834]: /usr/lib/frr/bgpd(bgp_update+0x9a5) [0x55eefd35c1d5]
BGP[7834]: /usr/lib/frr/bgpd(bgp_nlri_parse_ip+0xb7) [0x55eefd35e867]
BGP[7834]: /usr/lib/frr/bgpd(+0x1555e6) [0x55eefd3405e6]
BGP[7834]: /usr/lib/frr/bgpd(bgp_process_packet+0x747) [0x55eefd345597]
BGP[7834]: /usr/local/lib/libfrr.so.0(event_call+0x83) [0x7f3205cef4a3]
BGP[7834]: /usr/local/lib/libfrr.so.0(frr_run+0xc0) [0x7f3205ca10a0]
BGP[7834]: /usr/lib/frr/bgpd(main+0x409) [0x55eefd2dc979]
```
Sending:
```
import socket
import time
OPEN = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\x00\x62\x01\x04\xfd\xea\x00\x5a\x0a\x00\x00\x01\x45\x02"
b"\x06\x01\x04\x00\x01\x00\x01\x02\x02\x02\x00\x02\x02\x46\x00\x02"
b"\x06\x41\x04\x00\x00\xfd\xea\x02\x02\x06\x00\x02\x06\x45\x04\x00"
b"\x01\x01\x03\x02\x0e\x49\x0c\x0a\x64\x6f\x6e\x61\x74\x61\x73\x2d"
b"\x70\x63\x00\x02\x04\x40\x02\x00\x78\x02\x09\x47\x07\x00\x01\x01"
b"\x80\x00\x00\x00")
KEEPALIVE = (b"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
b"\xff\xff\xff\xff\xff\xff\x00\x13\x04")
UPDATE = bytearray.fromhex("ffffffffffffffffffffffffffffffff003c0200000014ff1f001000040146464646460004464646464646664646f50d05800100010200ffff000000")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.2', 179))
s.send(OPEN)
data = s.recv(1024)
s.send(KEEPALIVE)
data = s.recv(1024)
s.send(UPDATE)
data = s.recv(1024)
time.sleep(1000)
s.close()
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d8482bf011)
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>
(cherry picked from commit 2d8e859585)
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>
(cherry picked from commit 78b6cadc16)
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>
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>
