Reuse subgroup_process_announce_selected(). It does the same as we do here
duplicating the logic.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Listing `.c` files in `$(…_OBJECTS):` does not have the desired effect.
(Also CLEANFILES is not needed, yang/subdir.am already has yang/*.c in
CLEANFILES anyway.)
Fixes: #13600
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
==13211==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000af158 at pc 0x55d48c5f1e38 bp 0x7fffd8a713d0 sp 0x7fffd8a713c0
READ of size 8 at 0x6020000af158 thread T0
#0 0x55d48c5f1e37 in rip_allow_ecmp ripd/rip_cli.c:98
#1 0x7f2ec125aa0f in cmd_execute_command_real lib/command.c:990
#2 0x7f2ec125ae90 in cmd_execute_command lib/command.c:1049
#3 0x7f2ec125b406 in cmd_execute lib/command.c:1217
#4 0x7f2ec137ca36 in vty_command lib/vty.c:551
#5 0x7f2ec137ce52 in vty_execute lib/vty.c:1314
#6 0x7f2ec1384f9e in vtysh_read lib/vty.c:2223
#7 0x7f2ec137041b in event_call lib/event.c:1995
#8 0x7f2ec12b54bf in frr_run lib/libfrr.c:1204
#9 0x55d48c5f0f32 in main ripd/rip_main.c:171
#10 0x7f2ec0ad9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
#11 0x55d48c5f1349 in _start (/usr/lib/frr/ripd+0x3b349)
0x6020000af158 is located 0 bytes to the right of 8-byte region [0x6020000af150,0x6020000af158)
allocated by thread T0 here:
#0 0x7f2ec18ccb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f2ec12d2e41 in qmalloc lib/memory.c:100
#2 0x7f2ec125a815 in cmd_execute_command_real lib/command.c:955
#3 0x7f2ec125ae90 in cmd_execute_command lib/command.c:1049
#4 0x7f2ec125b406 in cmd_execute lib/command.c:1217
#5 0x7f2ec137ca36 in vty_command lib/vty.c:551
#6 0x7f2ec137ce52 in vty_execute lib/vty.c:1314
#7 0x7f2ec1384f9e in vtysh_read lib/vty.c:2223
#8 0x7f2ec137041b in event_call lib/event.c:1995
#9 0x7f2ec12b54bf in frr_run lib/libfrr.c:1204
#10 0x55d48c5f0f32 in main ripd/rip_main.c:171
#11 0x7f2ec0ad9c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: heap-buffer-overflow ripd/rip_cli.c:98 in rip_allow_ecmp
Shadow bytes around the buggy address:
0x0c048000ddd0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa
0x0c048000dde0: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
0x0c048000ddf0: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fd
0x0c048000de00: fa fa fd fa fa fa fd fd fa fa 00 03 fa fa fd fa
0x0c048000de10: fa fa fd fa fa fa 00 00 fa fa fd fa fa fa 00 03
=>0x0c048000de20: fa fa 00 03 fa fa fd fa fa fa 00[fa]fa fa fa fa
0x0c048000de30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c048000de70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==13211==ABORTING
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The output of show bgp all json is inconsistent across Address-families
i.e. ipv4/ipv6 is a no pretty format while l2vpn-evpn is in a pretty
format. For huge scale (lots of routes with lots of paths), it is better
to use no_pretty format.
Before fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"l2VpnEvpn":{
"routes":{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
"prefixLen":352,
"paths":[
<SNIP>.............
After fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
"vrfId": 0,
"vrfName": "default",
"tableVersion": 1,
"routerId": "27.0.0.15",
"defaultLocPrf": 100,
"localAS": 65000,
"routes": { } }
,
"l2VpnEvpn":{
"routes":{"27.0.0.15:2":{"rd":"27.0.0.15:2","[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]","prefixLen":352,"paths":[[{"valid":true,"bestpath":true,"selectionReason":"First path received","pathFrom":"external","routeType":1,"weight":32768,"peerId":"(unspec)","path":"","origin":"IGP","extendedCommunity"
<SNIP>.............
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
In the json output of show bgp all json, the l2VpnEvpn afi-safi is
missing the 'routes' key making the json output format invalid.
Before Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]":{
"prefix":"[4]:[03:44:38:39:ff:ff:01:00:00:01]:[32]:[27.0.0.15]",
"prefixLen":352,
"paths":[
<SNIP>....................
After Fix:
torm-11# sh bgp all json
{
<SNIP>....................
"l2VpnEvpn":{
"routes":{
"27.0.0.15:2":{
"rd":"27.0.0.15:2",
"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
"prefixLen":352,
"paths":[
Issue: 3472865
Ticket:#3472865
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Currently, delayed reflooding on P2MP interfaces for LSAs received
from neighbors on the interface is unconditionally (see commit
c706f0e32b). In some cases, this
change wasn't desirable and this feature makes delayed reflooding
configurable for P2MP interfaces via the CLI command:
"ip ospf network point-to-multipoint delay-reflood" in interface
submode.
Signed-off-by: Acee <aceelindem@gmail.com>
There is no path in some functions where the ctx
has not already been de-refed. As such no need
to test for it's existence.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When running the pytests in parallel, calling pytest.exit() causes
the entire test run to be aborted. Which.... Is frankly not cool.
Let's notice the failure and move on to the next tests.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A bunch of tests rely on pre-generated config from
json files. These tests were not putting `exit` stanzas
and a bunch of the tests as a result are silently failing
to configure properly at all, as commands were being sent
to the wrong daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The test is performing these steps:
a) get timestamp of route installed in zebra
b) <make changes>
c) get new timestamp of route installed in zebra
If < 1 second happens between A and C the test
assumes that something went wrong, as that it is
testing to see if the route was reinstalled <yes I know>.
Just sleep 1 second after a) happens so that if a reinstall
happens we can easily see it, and we also know that if a
reinstall doesn't happen then the new timestamp will
always be 1 second or greater.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This can lead into some garbage outputs, that can't be decoded in utf-8 or so.
This was catched when testing 76b246aa1f.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Based on RFC-4760, if NEXT_HOP attribute is not
suppose to be set if MP_REACH_NLRI NLRI is used.
for IPv4 aggregate route only NEXT_HOP attribute
with ipv4 prefixlen needs to be set.
Testing Done:
Before fix:
----------
aggregate route:
*> 184.123.0.0/16 ::(TORC11) 0 32768 i
After fix:
---------
aggregate route:
*> 184.123.0.0/16 0.0.0.0(TORC11) 0 32768 i
* i peerlink-3 0 100 0 i
* uplink1 0 4435 5546 i
184.123.1.0/24 0.0.0.0(TORC11) 0 32768 i
s> 184.123.8.0/22 0.0.0.0(TORC11) 0 32768 i
Signed-off-by: Chirag Shah <chirag@nvidia.com>
