forked from FRRouting/frr
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add FRR Icon to README #1
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
f2bd4d1
to
0a339a6
Compare
🐔 Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
0a339a6
to
e79a755
Compare
sworleys
added a commit
that referenced
this pull request
Nov 12, 2019
This code is called from the zebra main pthread during shutdown but the thread even is schedule via the zebra dplane pthread. Hence, we should be using the `thread_cancel_async()` API to cancel the thread event on a different thread. This is only ever hit in the rare case that we still have work left to do on the update queue during shutdown. Found via zebra crash: (gdb) bt \#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 \#1 0x00007f4e4d3f7535 in __GI_abort () at abort.c:79 \#2 0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()", file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92 \FRRouting#3 0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c", line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101 \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 \FRRouting#5 0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274 \FRRouting#6 0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202 \FRRouting#7 0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599 \FRRouting#8 0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024 \FRRouting#9 0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483 (gdb) down \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 1185 assert(master->owner == pthread_self()); (gdb) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
added a commit
that referenced
this pull request
Nov 12, 2019
This code is called from the zebra main pthread during shutdown but the thread even is schedule via the zebra dplane pthread. Hence, we should be using the `thread_cancel_async()` API to cancel the thread event on a different thread. This is only ever hit in the rare case that we still have work left to do on the update queue during shutdown. Found via zebra crash: (gdb) bt \#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 \#1 0x00007f4e4d3f7535 in __GI_abort () at abort.c:79 \#2 0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()", file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92 \FRRouting#3 0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c", line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101 \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 \FRRouting#5 0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274 \FRRouting#6 0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202 \FRRouting#7 0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599 \FRRouting#8 0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024 \FRRouting#9 0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483 (gdb) down \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 1185 assert(master->owner == pthread_self()); (gdb) Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
added a commit
that referenced
this pull request
Nov 12, 2019
This code is called from the zebra main pthread during shutdown but the thread event is scheduled via the zebra dplane pthread. Hence, we should be using the `thread_cancel_async()` API to cancel the thread event on a different pthread. This is only ever hit in the rare case that we still have work left to do on the update queue during shutdown. Found via zebra crash: ``` (gdb) bt \#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 \#1 0x00007f4e4d3f7535 in __GI_abort () at abort.c:79 \#2 0x00007f4e4d3f740f in __assert_fail_base (fmt=0x7f4e4d559ee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f4e4d9071d0 "master->owner == pthread_self()", file=0x7f4e4d906cf8 "lib/thread.c", line=1185, function=<optimized out>) at assert.c:92 \FRRouting#3 0x00007f4e4d405102 in __GI___assert_fail (assertion=assertion@entry=0x7f4e4d9071d0 "master->owner == pthread_self()", file=file@entry=0x7f4e4d906cf8 "lib/thread.c", line=line@entry=1185, function=function@entry=0x7f4e4d906b68 <__PRETTY_FUNCTION__.15817> "thread_cancel") at assert.c:101 \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 \FRRouting#5 0x000055b40c291845 in zebra_dplane_shutdown () at zebra/zebra_dplane.c:3274 \FRRouting#6 0x000055b40c27ee13 in zebra_finalize (dummy=<optimized out>) at zebra/main.c:202 \FRRouting#7 0x00007f4e4d8d1416 in thread_call (thread=thread@entry=0x7ffcbbc08870) at lib/thread.c:1599 \FRRouting#8 0x00007f4e4d8a1ef8 in frr_run (master=0x55b40ce35510) at lib/libfrr.c:1024 \FRRouting#9 0x000055b40c270916 in main (argc=8, argv=0x7ffcbbc08c78) at zebra/main.c:483 (gdb) down \FRRouting#4 0x00007f4e4d8d095a in thread_cancel (thread=0x55b40d01a640) at lib/thread.c:1185 1185 assert(master->owner == pthread_self()); (gdb) ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
added a commit
that referenced
this pull request
Nov 14, 2019
We were not connecting the default zebra_ns to the default ns->info at namespace initialization in zebra. Thus, when we tried to use the `ns_walk_func()` it would ignore the default zebra_ns since there is no pointer to it from the ns struct. Fix this by connecting them in `zebra_ns_init()` and, if the default ns is not found, exit with failure since this is not recoverable. This was found during a crash where we fail to cancel the kernel_read thread at termination (via the `ns_walk_func()`) and then we get a netlink notification trying to use the zns struct that has already been freed. ``` (gdb) bt \#0 0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 \#1 0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 \#2 0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254 \FRRouting#3 <signal handler called> \FRRouting#4 0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269 \FRRouting#5 0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043 \FRRouting#6 0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384 \FRRouting#7 0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940, count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932 \FRRouting#8 0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406 \FRRouting#9 0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599 \FRRouting#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024 \FRRouting#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483 ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
added a commit
that referenced
this pull request
Nov 14, 2019
We were not connecting the default zebra_ns to the default ns->info at namespace initialization in zebra. Thus, when we tried to use the `ns_walk_func()` it would ignore the default zebra_ns since there is no pointer to it from the ns struct. Fix this by connecting them in `zebra_ns_init()` and, if the default ns is not found, exit with failure since this is not recoverable. This was found during a crash where we fail to cancel the kernel_read thread at termination (via the `ns_walk_func()`) and then we get a netlink notification trying to use the zns struct that has already been freed. ``` (gdb) bt \#0 0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 \#1 0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 \#2 0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254 \FRRouting#3 <signal handler called> \FRRouting#4 0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269 \FRRouting#5 0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043 \FRRouting#6 0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384 \FRRouting#7 0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940, count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932 \FRRouting#8 0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406 \FRRouting#9 0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599 \FRRouting#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024 \FRRouting#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483 ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
added a commit
that referenced
this pull request
Nov 15, 2019
We were not connecting the default zebra_ns to the default ns->info at namespace initialization in zebra. Thus, when we tried to use the `ns_walk_func()` it would ignore the default zebra_ns since there is no pointer to it from the ns struct. Fix this by connecting them in `zebra_ns_init()` and, if the default ns is not found, exit with failure since this is not recoverable. This was found during a crash where we fail to cancel the kernel_read thread at termination (via the `ns_walk_func()`) and then we get a netlink notification trying to use the zns struct that has already been freed. ``` (gdb) bt \#0 0x00007fc1134dc7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 \#1 0x00007fc1134c7535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 \#2 0x00007fc113996f8f in core_handler (signo=11, siginfo=0x7ffe5429d070, context=<optimized out>) at lib/sigevent.c:254 \FRRouting#3 <signal handler called> \FRRouting#4 0x0000561880e15449 in if_lookup_by_index_per_ns (ns=0x0, ifindex=174) at zebra/interface.c:269 \FRRouting#5 0x0000561880e1642c in if_up (ifp=ifp@entry=0x561883076c50) at zebra/interface.c:1043 \FRRouting#6 0x0000561880e10723 in netlink_link_change (h=0x7ffe5429d8f0, ns_id=<optimized out>, startup=<optimized out>) at zebra/if_netlink.c:1384 \FRRouting#7 0x0000561880e17e68 in netlink_parse_info (filter=filter@entry=0x561880e17680 <netlink_information_fetch>, nl=nl@entry=0x561882497238, zns=zns@entry=0x7ffe542a5940, count=count@entry=5, startup=startup@entry=0) at zebra/kernel_netlink.c:932 \FRRouting#8 0x0000561880e186a5 in kernel_read (thread=<optimized out>) at zebra/kernel_netlink.c:406 \FRRouting#9 0x00007fc1139a4416 in thread_call (thread=thread@entry=0x7ffe542a5b70) at lib/thread.c:1599 \FRRouting#10 0x00007fc113974ef8 in frr_run (master=0x5618823c9510) at lib/libfrr.c:1024 \FRRouting#11 0x0000561880e0b916 in main (argc=8, argv=0x7ffe542a5f78) at zebra/main.c:483 ``` Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 30, 2019
Address Sanitizer is reporting this issue: ==26177==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120000238d8 at pc 0x7f88f7c4fa93 bp 0x7fff9a641830 sp 0x7fff9a641820 READ of size 8 at 0x6120000238d8 thread T0 #0 0x7f88f7c4fa92 in if_delete lib/if.c:290 #1 0x42192e in ospf_vl_if_delete ospfd/ospf_interface.c:912 #2 0x42192e in ospf_vl_delete ospfd/ospf_interface.c:990 FRRouting#3 0x4a6208 in no_ospf_area_vlink ospfd/ospf_vty.c:1227 FRRouting#4 0x7f88f7c1553d in cmd_execute_command_real lib/command.c:1073 FRRouting#5 0x7f88f7c19b1e in cmd_execute_command lib/command.c:1132 FRRouting#6 0x7f88f7c19e8e in cmd_execute lib/command.c:1288 FRRouting#7 0x7f88f7cd7523 in vty_command lib/vty.c:516 FRRouting#8 0x7f88f7cd79ff in vty_execute lib/vty.c:1285 FRRouting#9 0x7f88f7cde4f9 in vtysh_read lib/vty.c:2119 FRRouting#10 0x7f88f7ccb845 in thread_call lib/thread.c:1549 FRRouting#11 0x7f88f7c5d6a7 in frr_run lib/libfrr.c:1093 FRRouting#12 0x412976 in main ospfd/ospf_main.c:221 FRRouting#13 0x7f88f73b082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) FRRouting#14 0x413c78 in _start (/usr/local/master/sbin/ospfd+0x413c78) Effectively we are in a shutdown phase and as part of shutdown we delete the ospf interface pointer ( ifp->info ). The interface deletion code was modified in the past year to pass in the address of operator to allow us to NULL out the holding pointer. The catch here is that we free the oi and then delete the interface passing in the address of the oi->ifp pointer, causing a use after free. Fixes: FRRouting#5555 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 7, 2020
================================================================= ==13611==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe9e5c8694 at pc 0x0000004d18ac bp 0x7ffe9e5c8330 sp 0x7ffe9e5c7ae0 WRITE of size 17 at 0x7ffe9e5c8694 thread T0 #0 0x4d18ab in __asan_memcpy (/usr/lib/frr/zebra+0x4d18ab) #1 0x7f16f04bd97f in stream_get2 /home/qlyoung/frr/lib/stream.c:277:2 #2 0x6410ec in zebra_vxlan_remote_macip_del /home/qlyoung/frr/zebra/zebra_vxlan.c:7718:4 FRRouting#3 0x68fa98 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 FRRouting#4 0x556add in main /home/qlyoung/frr/zebra/main.c:309:2 FRRouting#5 0x7f16eea3bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 FRRouting#6 0x431249 in _start (/usr/lib/frr/zebra+0x431249) This decode is the result of a buffer overflow because we are not checking ipa_len. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 7, 2020
================================================================= ==3058==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f5bf3ef7477 bp 0x7ffdfaa20d40 sp 0x7ffdfaa204c8 T0) ==3058==The signal is caused by a READ memory access. ==3058==Hint: address points to the zero page. #0 0x7f5bf3ef7476 in memcpy /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:134 #1 0x4d158a in __asan_memcpy (/usr/lib/frr/zebra+0x4d158a) #2 0x7f5bf58da8ad in stream_put /home/qlyoung/frr/lib/stream.c:605:3 FRRouting#3 0x67d428 in zsend_ipset_entry_notify_owner /home/qlyoung/frr/zebra/zapi_msg.c:851:2 FRRouting#4 0x5c70b3 in zebra_pbr_add_ipset_entry /home/qlyoung/frr/zebra/zebra_pbr.c FRRouting#5 0x68e1bb in zread_ipset_entry /home/qlyoung/frr/zebra/zapi_msg.c:2465:4 FRRouting#6 0x68f958 in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2611:3 FRRouting#7 0x55666d in main /home/qlyoung/frr/zebra/main.c:309:2 FRRouting#8 0x7f5bf3e5db96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 FRRouting#9 0x4311d9 in _start (/usr/lib/frr/zebra+0x4311d9) the ipset->backpointer was NULL as that the hash lookup failed to find anything. Prevent this crash from happening. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 8, 2020
Running with --enable-address-sanitizer I am seeing this: ================================================================= ==19520==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020003ef850 at pc 0x7fe9b8f7b57b bp 0x7fffbac6f9c0 sp 0x7fffbac6f170 READ of size 6 at 0x6020003ef850 thread T0 #0 0x7fe9b8f7b57a (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x55e33d1071e5 in bgp_process_mac_rescan_table bgpd/bgp_mac.c:159 #2 0x55e33d107c09 in bgp_mac_rescan_evpn_table bgpd/bgp_mac.c:252 FRRouting#3 0x55e33d107e39 in bgp_mac_rescan_all_evpn_tables bgpd/bgp_mac.c:266 FRRouting#4 0x55e33d108270 in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:291 FRRouting#5 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 FRRouting#6 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 FRRouting#7 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 FRRouting#8 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 FRRouting#9 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 FRRouting#10 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#11 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#12 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#13 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 FRRouting#14 0x55e33d09c189 in _start (/usr/lib/frr/bgpd+0x168189) 0x6020003ef850 is located 0 bytes inside of 16-byte region [0x6020003ef850,0x6020003ef860) freed by thread T0 here: #0 0x7fe9b8fabfb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0) #1 0x7fe9b8ce4ea9 in qfree lib/memory.c:129 #2 0x55e33d10825c in bgp_mac_remove_ifp_internal bgpd/bgp_mac.c:289 FRRouting#3 0x55e33d108893 in bgp_mac_del_mac_entry bgpd/bgp_mac.c:351 FRRouting#4 0x55e33d21412d in bgp_ifp_down bgpd/bgp_zebra.c:257 FRRouting#5 0x7fe9b8cbf3be in if_down_via_zapi lib/if.c:198 FRRouting#6 0x7fe9b8db303a in zclient_interface_down lib/zclient.c:1549 FRRouting#7 0x7fe9b8db8a06 in zclient_read lib/zclient.c:2693 FRRouting#8 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#9 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#10 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#11 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7fe9b8fac518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fe9b8ce4d93 in qcalloc lib/memory.c:110 #2 0x55e33d106b29 in bgp_mac_hash_alloc bgpd/bgp_mac.c:96 FRRouting#3 0x7fe9b8cb8350 in hash_get lib/hash.c:149 FRRouting#4 0x55e33d10845b in bgp_mac_add_mac_entry bgpd/bgp_mac.c:303 FRRouting#5 0x55e33d226757 in bgp_ifp_create bgpd/bgp_zebra.c:2644 FRRouting#6 0x7fe9b8cbf1e6 in if_new_via_zapi lib/if.c:176 FRRouting#7 0x7fe9b8db2d3b in zclient_interface_add lib/zclient.c:1481 FRRouting#8 0x7fe9b8db87f8 in zclient_read lib/zclient.c:2659 FRRouting#9 0x7fe9b8d7b95a in thread_call lib/thread.c:1599 FRRouting#10 0x7fe9b8cd824e in frr_run lib/libfrr.c:1024 FRRouting#11 0x55e33d09d463 in main bgpd/bgp_main.c:477 FRRouting#12 0x7fe9b879409a in __libc_start_main ../csu/libc-start.c:308 Effectively we are passing to bgp_mac_remove_ifp_internal the macaddr that is associated with the bsm data structure. There exists a path where the bsm is freed and then we immediately pass the macaddr into bgp_mac_rescan_all_evpn_tables. So just make a copy of the macaddr data structure before we free the bsm Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 18, 2020
==25402==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x533302 in calloc (/usr/lib/frr/zebra+0x533302) #1 0x7fee84cdc80b in qcalloc /home/qlyoung/frr/lib/memory.c:110:27 #2 0x5a3032 in create_label_chunk /home/qlyoung/frr/zebra/label_manager.c:188:3 FRRouting#3 0x5a3c2b in assign_label_chunk /home/qlyoung/frr/zebra/label_manager.c:354:8 FRRouting#4 0x5a2a38 in label_manager_get_chunk /home/qlyoung/frr/zebra/label_manager.c:424:9 FRRouting#5 0x5a1412 in hook_call_lm_get_chunk /home/qlyoung/frr/zebra/label_manager.c:60:1 FRRouting#6 0x5a1412 in lm_get_chunk_call /home/qlyoung/frr/zebra/label_manager.c:81:2 FRRouting#7 0x72a234 in zread_get_label_chunk /home/qlyoung/frr/zebra/zapi_msg.c:2026:2 FRRouting#8 0x72a234 in zread_label_manager_request /home/qlyoung/frr/zebra/zapi_msg.c:2073:4 FRRouting#9 0x73150c in zserv_handle_commands /home/qlyoung/frr/zebra/zapi_msg.c:2688:2 When creating label chunk that has a specified base, we eventually are calling assign_specific_label_chunk. This function finds the appropriate list node and deletes it from the lbl_mgr.lc_list but since the function uses list_delete_node() the deletion function that is specified for lbl_mgr.lc_list is not called thus dropping the memory. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 18, 2020
The only two safi's that are usable for zebra for installation of routes into the rib are SAFI_UNICAST and SAFI_MULTICAST. The acceptance of other safi's is causing a memory leak: Direct leak of 56 byte(s) in 1 object(s) allocated from: #0 0x5332f2 in calloc (/usr/lib/frr/zebra+0x5332f2) #1 0x7f594adc29db in qcalloc /opt/build/frr/lib/memory.c:110:27 #2 0x686849 in zebra_vrf_get_table_with_table_id /opt/build/frr/zebra/zebra_vrf.c:390:11 FRRouting#3 0x65a245 in rib_add_multipath /opt/build/frr/zebra/zebra_rib.c:2591:10 FRRouting#4 0x7211bc in zread_route_add /opt/build/frr/zebra/zapi_msg.c:1616:8 FRRouting#5 0x73063c in zserv_handle_commands /opt/build/frr/zebra/zapi_msg.c:2682:2 Collapse Sequence of events: Upon vrf creation there is a zvrf->table[afi][safi] data structure that tables are auto created for. These tables only create SAFI_UNICAST and SAFI_MULTICAST tables. Since these are the only safi types that are zebra can actually work on. zvrf data structures also have a zvrf->otable data structure that tracks in a RB tree other tables that are created ( say you have routes stuck in any random table in the 32bit route table space in linux ). This data structure is only used if the lookup in zvrf->table[afi][safi] fails. After creation if we pass a route down from an upper level protocol that has non unicast or multicast safi *but* has the actual tableid of the vrf we are in, the initial lookup will always return NULL leaving us to look in the otable. This will create a data structure to track this data. If after this event you pass in a second route with the same afi/safi/table_id, the otable will be created and attempted to be stored, but the RB_TREE_UNIQ data structure when it sees this will return the original otable returned and the lookup function zebra_vrf_get_table_with_table_id will just drop the second otable. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 11, 2020
Upper level clients ask for default routes of a particular family This change ensures that they only receive the family that they have asked for. Discovered when testing in ospf `default-information originate` ================================================================= ==246306==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffa2e8 at pc 0x7ffff73c44e2 bp 0x7fffffffa090 sp 0x7fffffffa088 READ of size 16 at 0x7fffffffa2e8 thread T0 #0 0x7ffff73c44e1 in prefix_copy lib/prefix.c:310 #1 0x7ffff741c0aa in route_node_lookup lib/table.c:255 #2 0x5555556cd263 in ospf_external_info_delete ospfd/ospf_asbr.c:178 FRRouting#3 0x5555556a47cc in ospf_zebra_read_route ospfd/ospf_zebra.c:852 FRRouting#4 0x7ffff746f5d8 in zclient_read lib/zclient.c:3028 FRRouting#5 0x7ffff742fc91 in thread_call lib/thread.c:1549 FRRouting#6 0x7ffff7374642 in frr_run lib/libfrr.c:1093 FRRouting#7 0x5555555bfaef in main ospfd/ospf_main.c:235 FRRouting#8 0x7ffff70a2bba in __libc_start_main ../csu/libc-start.c:308 FRRouting#9 0x5555555bf499 in _start (/usr/lib/frr/ospfd+0x6b499) Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 1, 2020
Show if this malformed under `show [ip] bgp <prefix>`: ``` eva# sh ip bgp 103.79.124.0/22 BGP routing table entry for 103.79.124.0/22 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.201.136 64539 15096 6939 7545 7545 136001, (aggregated by 0(malformed) 0.0.0.0) 192.168.201.136 from 192.168.201.136 (192.168.201.136) Origin IGP, valid, external, best (First path received) Last update: Thu Mar 26 10:02:07 2020 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 9, 2020
Implement tests to verify BGP link-bandwidth and weighted ECMP functionality. These tests validate one of the primary use cases for weighted ECMP (a.k.a. Unequal cost multipath) using BGP link-bandwidth: https://tools.ietf.org/html/draft-mohanty-bess-ebgp-dmz The included tests are: Test #1: Test BGP link-bandwidth advertisement based on number of multipaths Test #2: Test cumulative link-bandwidth propagation Test FRRouting#3: Test weighted ECMP - multipath with next hop weights Test FRRouting#4: Test weighted ECMP rebalancing upon change (link flap) Test FRRouting#5: Test weighted ECMP for a second anycast IP Test FRRouting#6: Test paths with and without link-bandwidth - receiver should resort to regular ECMP Test FRRouting#7: Test different options for processing link-bandwidth on the receiver Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jun 11, 2020
================================================================= ==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138 READ of size 8 at 0x60d0000115c8 thread T0 #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041 #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234 #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205 FRRouting#3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229 FRRouting#4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541 FRRouting#5 0x55cb9ceba0af in sigint zebra/main.c:176 FRRouting#6 0x55cb9ceba0af in sigint zebra/main.c:130 FRRouting#7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103 FRRouting#8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396 FRRouting#9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092 FRRouting#10 0x55cb9ce931d8 in main zebra/main.c:488 FRRouting#11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09) ================================================================= Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jun 11, 2020
================================================================= ==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138 READ of size 8 at 0x60d0000115c8 thread T0 #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041 #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234 #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205 FRRouting#3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229 FRRouting#4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541 FRRouting#5 0x55cb9ceba0af in sigint zebra/main.c:176 FRRouting#6 0x55cb9ceba0af in sigint zebra/main.c:130 FRRouting#7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103 FRRouting#8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396 FRRouting#9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092 FRRouting#10 0x55cb9ce931d8 in main zebra/main.c:488 FRRouting#11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09) ================================================================= Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Sep 25, 2020
This problem was reported by the sanitizer - ================================================================= ==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138 READ of size 8 at 0x60d0000115c8 thread T0 #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041 #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234 #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205 FRRouting#3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229 FRRouting#4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541 FRRouting#5 0x55cb9ceba0af in sigint zebra/main.c:176 FRRouting#6 0x55cb9ceba0af in sigint zebra/main.c:130 FRRouting#7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103 FRRouting#8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396 FRRouting#9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092 FRRouting#10 0x55cb9ce931d8 in main zebra/main.c:488 FRRouting#11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09) ================================================================= Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 6, 2020
Current code in bgp bestpath selection would accept the newest locally originated path as the best path. Making the selection non-deterministic. Modify the code to always come to the same bestpath conclusion when you have multiple locally originated paths in bestpath selection. Before: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Notice the route choosen depends on order received Fixed behavior: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Ticket: CM-31490 Found-by: Trey Aspelund <taspelund@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 8, 2020
The bgp_l3vpn_to_bgp_vrf test is looking for a prefix on multiple routers that the ordered received is non-deterministic. As such the regex's are failing occassionaly when the route is received in an unexpected order. One possible order: (FRRouting#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c: COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M Paths: (2 available, best #1, table default)^M Advertised to non peer-group peers:^M 192.168.1.1^M Local^M 99.0.0.3 from 0.0.0.0 (99.0.0.3)^M Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M Community: 0:67^M Extended Community: RT:89:123^M Large Community: 12:34:56^M Last update: Wed Oct 7 11:12:22 2020^M Local^M 192.168.1.1 from 192.168.1.1 (192.168.1.1)^M Origin IGP, metric 98, localpref 123, valid, internal^M Community: 0:67^M Extended Community: RT:52:100 RT:89:123^M Large Community: 12:34:56^M Last update: Wed Oct 7 11:12:41 2020: R:89 ce3 Redundant route 1 details c 1 0 Second possible order: (FRRouting#89) scripts/check_routes.py:120 COMMAND:ce3:vtysh -c "show bgp ipv4 uni 6.0.1.0":2 available, best .*192.168.1.1.* Local.* 99.0.0.3 from 0.0.0.0 .99.0.0.3.* Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best .Weight.* Community: 0:67.* Extended Community: RT:89:123.* Large Community: 12:34:56.* Local.* 192.168.1.1 from 192.168.1.1 .192.168.1.1.* Origin IGP, metric 98, localpref 123, valid, internal.* Community: 0:67.* Extended Community: RT:52:100 RT:89:123.* Large Community: 12:34:56:pass:Redundant route 1 details c: COMMAND OUTPUT:BGP routing table entry for 6.0.1.0/24^M Paths: (2 available, best #2, table default)^M Advertised to non peer-group peers:^M 192.168.1.1^M Local^M 192.168.1.1 from 192.168.1.1 (192.168.1.1)^M Origin IGP, metric 98, localpref 123, valid, internal^M Community: 0:67^M Extended Community: RT:52:100 RT:89:123^M Large Community: 12:34:56^M Last update: Wed Oct 7 11:14:45 2020^M Local^M 99.0.0.3 from 0.0.0.0 (99.0.0.3)^M Origin IGP, metric 200, localpref 50, weight 32768, valid, sourced, local, best (Weight)^M Community: 0:67^M Extended Community: RT:89:123^M Large Community: 12:34:56^M Last update: Wed Oct 7 11:14:27 2020: R:89 ce3 Redundant route 1 details c 0 1 BGP displays the paths in the order received since it's just a linked list. For this test modify/add the luCommands to track that we may receive the paths in a non-deterministic order. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Quentin Young <qlyoung@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 19, 2020
When zebra is running with debugs turned on there is a use after free reported by the address sanitizer: 2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing 2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3 ================================================================= ==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8 READ of size 8 at 0x608000011d28 thread T0 #0 0x555555705ab5 in re_list_const_first zebra/rib.h:222 #1 0x555555705b54 in re_list_first zebra/rib.h:222 #2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248 FRRouting#3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286 FRRouting#4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320 FRRouting#5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291 FRRouting#6 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#8 0x55555561a578 in main zebra/main.c:455 FRRouting#9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 FRRouting#10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429) 0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78) freed by thread T0 here: #0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f) #1 0x7ffff739ccad in qfree lib/memory.c:129 #2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746 FRRouting#3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240 FRRouting#4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245 FRRouting#5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286 FRRouting#6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320 FRRouting#7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291 FRRouting#8 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#10 0x55555561a578 in main zebra/main.c:455 FRRouting#11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037) #1 0x7ffff739cb98 in qcalloc lib/memory.c:110 #2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515 FRRouting#3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576 FRRouting#4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607 FRRouting#5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012 FRRouting#6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049 FRRouting#7 0x55555571788b in rib_add zebra/zebra_rib.c:3327 FRRouting#8 0x5555555e584a in connected_up zebra/connected.c:254 FRRouting#9 0x5555555e42ff in connected_announce zebra/connected.c:94 FRRouting#10 0x5555555e4fd3 in connected_update zebra/connected.c:195 FRRouting#11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340 FRRouting#12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213 FRRouting#13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350 FRRouting#14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941 FRRouting#15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402 FRRouting#16 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#18 0x55555561a578 in main zebra/main.c:455 FRRouting#19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first This is happening because we are using the dest pointer after a call into rib_gc_dest. In process_subq_route, we call rib_process() and if the dest is deleted dest pointer is now garbage. We must reload the dest pointer in this case. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 30, 2020
Sample Configuration with prefix-list and community match rules --------------------------------------------------------------- R1 ------- R2(DUT) ------- R3 Router2# show running-config Building configuration... Current configuration: ! frr version 7.6-dev-MyOwnFRRVersion frr defaults traditional hostname router log file /var/log/frr/bgpd.log log syslog informational hostname Router2 service integrated-vtysh-config ! debug bgp updates in debug bgp updates out ! debug route-map ! ip route 20.20.0.0/16 blackhole ipv6 route 2001:db8::200/128 blackhole ! interface enp0s9 ip address 10.10.10.2/24 ! interface enp0s10 ip address 10.10.20.2/24 ! interface lo ip address 2.2.2.2/32 ! router bgp 2 bgp log-neighbor-changes no bgp ebgp-requires-policy neighbor 10.10.10.1 remote-as 1 neighbor 10.10.20.3 remote-as 3 ! address-family ipv4 unicast neighbor 10.10.10.1 soft-reconfiguration inbound neighbor 10.10.20.3 soft-reconfiguration inbound neighbor 10.10.20.3 advertise-map ADV-MAP non-exist-map EXIST-MAP exit-address-family ! ip prefix-list DEFAULT seq 5 permit 1.1.1.5/32 ip prefix-list DEFAULT seq 10 permit 1.1.1.1/32 ip prefix-list EXIST seq 5 permit 10.10.10.10/32 ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0 ip prefix-list IP1 seq 5 permit 10.139.224.0/20 ip prefix-list T2 seq 5 permit 1.1.1.5/32 ! bgp community-list standard DC-ROUTES seq 5 permit 64952:3008 bgp community-list standard DC-ROUTES seq 10 permit 64671:501 bgp community-list standard DC-ROUTES seq 15 permit 64950:3009 bgp community-list standard DEFAULT-ROUTE seq 5 permit 65013:200 ! route-map ADV-MAP permit 10 match ip address prefix-list IP1 ! route-map ADV-MAP permit 20 match community DC-ROUTES ! route-map EXIST-MAP permit 10 match community DEFAULT-ROUTE match ip address prefix-list DEFAULT-ROUTE ! line vty ! end Router2# Router2# show ip bgp 0.0.0.0 BGP routing table entry for 0.0.0.0/0 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 10.10.10.1 10.10.20.3 1 10.10.10.1 from 10.10.10.1 (10.139.224.1) Origin IGP, metric 0, valid, external, best (First path received) Community: 64848:3011 65011:200 65013:200 Last update: Tue Oct 6 02:39:42 2020 Router2# Sample output with non-exist-map when default route present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 4, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 10.10.10.1 0 0 1 i *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 4 routes and 4 total paths Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 4, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i <<<<<<<<< non-exist-map : 0.0.0.0/0 is present so, 10.139.224.0/20 not advertised Total number of prefixes 2 Sample output with non-exist-map when default route not present in table ------------------------------------------------------------------------ Router2# show ip bgp BGP table version is 5, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 3 routes and 3 total paths Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 5, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i *> 10.139.224.0/20 0.0.0.0 0 1 ? <<<<<<<<< non-exist-map : 0.0.0.0/0 is not present so, 10.139.224.0/20 advertised Total number of prefixes 3 Router2# Sample output with exist-map when default route present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 8, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 10.10.10.1 0 0 1 i *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 4 routes and 4 total paths Router2# Router2# Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 8, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 0.0.0.0 0 1 i *> 1.1.1.1/32 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i *> 10.139.224.0/20 0.0.0.0 0 1 ? <<<<<<<<< exist-map : 0.0.0.0/0 is present so, 10.139.224.0/20 advertised Total number of prefixes 4 Router2# Sample output with exist-map when default route not present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 9, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 3 routes and 3 total paths Router2# Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 9, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.5/32 0.0.0.0 0 1 i <<<<<<<<< exist-map : 0.0.0.0/0 is not present so, 10.139.224.0/20 not advertised Total number of prefixes 1 Router2# Signed-off-by: Madhuri Kuruganti <k.madhuri@samsung.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 30, 2020
The fields in the broadcast/p2p union struct in an isis circuit are initialized when the circuit goes up, but currently this step is skipped if the interface is passive. This can create problems if the circuit type (referred to as network type in the config) changes from broadcast to point-to-point. We can end up with the p2p neighbor pointer pointing at some garbage left by the broadcast struct in the union, which would then cause a segfault the first time we would dereference it - for example when building the lsp, or computing the SPF tree. compressed backtrace of a possible crash: #0 0x0000555555579a9c in lsp_build at frr/isisd/isis_lsp.c:1114 #1 0x000055555557a516 in lsp_regenerate at frr/isisd/isis_lsp.c:1301 #2 0x000055555557aa25 in lsp_refresh at frr/isisd/isis_lsp.c:1381 FRRouting#3 0x00007ffff7b2622c in thread_call at frr/lib/thread.c:1549 FRRouting#4 0x00007ffff7ad6df4 in frr_run at frr/lib/libfrr.c:1098 FRRouting#5 0x000055555556b67f in main at frr/isisd/isis_main.c:272 isis_lsp.c: 1112 case CIRCUIT_T_P2P: { 1113 struct isis_adjacency *nei = circuit->u.p2p.neighbor; 1114 if (nei && nei->adj_state == ISIS_ADJ_UP Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
sworleys
pushed a commit
that referenced
this pull request
Dec 1, 2020
Current code in bgp bestpath selection would accept the newest locally originated path as the best path. Making the selection non-deterministic. Modify the code to always come to the same bestpath conclusion when you have multiple locally originated paths in bestpath selection. Before: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Notice the route choosen depends on order received Fixed behavior: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Ticket: CM-31490 Found-by: Trey Aspelund <taspelund@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 1, 2020
We are using data after it has been freed and handed back to the OS. Address Sanitizer output: error 23-Nov-2020 18:53:57 ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55f825998f58 bp 0x7fffa5b0f5b0 sp 0x7fffa5b0f5a0 error 23-Nov-2020 18:53:57 READ of size 4 at 0x631000024838 thread T0 error 23-Nov-2020 18:53:57 #0 0x55f825998f57 in lde_imsg_compose_parent_sync ldpd/lde.c:226 error 23-Nov-2020 18:53:57 #1 0x55f8259ca9ed in vlog ldpd/log.c:48 error 23-Nov-2020 18:53:57 #2 0x55f8259cb1c8 in log_info ldpd/log.c:102 error 23-Nov-2020 18:53:57 FRRouting#3 0x55f82599e841 in lde_shutdown ldpd/lde.c:208 error 23-Nov-2020 18:53:57 FRRouting#4 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666 error 23-Nov-2020 18:53:57 FRRouting#5 0x55f825ac3815 in thread_call lib/thread.c:1681 error 23-Nov-2020 18:53:57 FRRouting#6 0x55f825998d5e in lde ldpd/lde.c:160 error 23-Nov-2020 18:53:57 FRRouting#7 0x55f82598a289 in main ldpd/ldpd.c:320 error 23-Nov-2020 18:53:57 FRRouting#8 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) error 23-Nov-2020 18:53:57 FRRouting#9 0x55f825982579 in _start (/usr/lib/frr/ldpd+0xb3579) error 23-Nov-2020 18:53:57 error 23-Nov-2020 18:53:57 0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860) error 23-Nov-2020 18:53:57 freed by thread T0 here: error 23-Nov-2020 18:53:57 #0 0x7fe3f8a4d7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) error 23-Nov-2020 18:53:57 #1 0x55f82599e830 in lde_shutdown ldpd/lde.c:206 error 23-Nov-2020 18:53:57 #2 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666 error 23-Nov-2020 18:53:57 FRRouting#3 0x55f825ac3815 in thread_call lib/thread.c:1681 error 23-Nov-2020 18:53:57 FRRouting#4 0x55f825998d5e in lde ldpd/lde.c:160 error 23-Nov-2020 18:53:57 FRRouting#5 0x55f82598a289 in main ldpd/ldpd.c:320 error 23-Nov-2020 18:53:57 FRRouting#6 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) error 23-Nov-2020 18:53:57 error 23-Nov-2020 18:53:57 previously allocated by thread T0 here: error 23-Nov-2020 18:53:57 #0 0x7fe3f8a4dd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) error 23-Nov-2020 18:53:57 #1 0x55f825998cb7 in lde ldpd/lde.c:151 error 23-Nov-2020 18:53:57 #2 0x55f82598a289 in main ldpd/ldpd.c:320 error 23-Nov-2020 18:53:57 FRRouting#3 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) error 23-Nov-2020 18:53:57 The fix is to put this in global space. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 1, 2020
error 26-Nov-2020 14:35:02 ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55cefae977e9 bp 0x7ffdd3546860 sp 0x7ffdd3546850 error 26-Nov-2020 14:35:02 READ of size 4 at 0x631000024838 thread T0 error 26-Nov-2020 14:35:02 #0 0x55cefae977e8 in ldpe_imsg_compose_parent_sync ldpd/ldpe.c:256 error 26-Nov-2020 14:35:02 #1 0x55cefae9ab13 in vlog ldpd/log.c:53 error 26-Nov-2020 14:35:02 #2 0x55cefae9b21f in log_info ldpd/log.c:102 error 26-Nov-2020 14:35:02 FRRouting#3 0x55cefae96eae in ldpe_shutdown ldpd/ldpe.c:237 error 26-Nov-2020 14:35:02 FRRouting#4 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585 error 26-Nov-2020 14:35:02 FRRouting#5 0x55cefaf93875 in thread_call lib/thread.c:1681 error 26-Nov-2020 14:35:02 FRRouting#6 0x55cefae97304 in ldpe ldpd/ldpe.c:136 error 26-Nov-2020 14:35:02 FRRouting#7 0x55cefae5a2e2 in main ldpd/ldpd.c:322 error 26-Nov-2020 14:35:02 FRRouting#8 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) error 26-Nov-2020 14:35:02 FRRouting#9 0x55cefae525e9 in _start (/usr/lib/frr/ldpd+0xb35e9) error 26-Nov-2020 14:35:02 error 26-Nov-2020 14:35:02 0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860) error 26-Nov-2020 14:35:02 freed by thread T0 here: error 26-Nov-2020 14:35:02 #0 0x7f4ef21e37a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) error 26-Nov-2020 14:35:02 #1 0x55cefae96e91 in ldpe_shutdown ldpd/ldpe.c:234 error 26-Nov-2020 14:35:02 #2 0x55cefae99254 in ldpe_dispatch_main ldpd/ldpe.c:585 error 26-Nov-2020 14:35:02 FRRouting#3 0x55cefaf93875 in thread_call lib/thread.c:1681 error 26-Nov-2020 14:35:02 FRRouting#4 0x55cefae97304 in ldpe ldpd/ldpe.c:136 error 26-Nov-2020 14:35:02 FRRouting#5 0x55cefae5a2e2 in main ldpd/ldpd.c:322 error 26-Nov-2020 14:35:02 FRRouting#6 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) error 26-Nov-2020 14:35:02 error 26-Nov-2020 14:35:02 previously allocated by thread T0 here: error 26-Nov-2020 14:35:02 #0 0x7f4ef21e3d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) error 26-Nov-2020 14:35:02 #1 0x55cefae9725d in ldpe ldpd/ldpe.c:127 error 26-Nov-2020 14:35:02 #2 0x55cefae5a2e2 in main ldpd/ldpd.c:322 error 26-Nov-2020 14:35:02 FRRouting#3 0x7f4ef0c33b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) Clean this problem up in the same way as the previous commit Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 28, 2021
rfc7999: A BGP speaker receiving an announcement tagged with the BLACKHOLE community SHOULD add the NO_ADVERTISE or NO_EXPORT community as defined in [RFC1997], or a similar community, to prevent propagation of the prefix outside the local AS. The community to prevent propagation SHOULD be chosen according to the operator's routing policy. Sent: ``` router bgp 65534 no bgp ebgp-requires-policy neighbor 192.168.0.2 remote-as 65030 ! address-family ipv4 unicast redistribute connected neighbor 192.168.0.2 route-map spine out exit-address-family ! ! ip prefix-list self seq 5 permit 192.168.100.1/32 ! route-map spine permit 10 match ip address prefix-list self set community blackhole ! ``` Received: ``` spine1-debian-9# show ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32 Paths: (1 available, best #1, table default, inform peer to blackhole prefix) Not advertised to any peer 65534 192.168.0.1 from 192.168.0.1 (192.168.100.1) Origin incomplete, metric 0, valid, external, best (First path received) Community: blackhole no-advertise Last update: Thu Jan 21 12:56:39 2021 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 19, 2021
In a sym-IRB setup the remote ES may not be installed if the tenant VRF is not present locally. To allow that case while retaining the fast-failover benefits for the case where the tenant VRF is locally present we use the following approach - 1. If ES is present in the tenant VRF we use the L3NHG for installing the MAC-IP based tenant route. This allows for efficient failover via L3NHG updates. 2. If the ES is not present locally in the corresponding tenant VRF we fall back to a non-NHG multi-path based routing approach. In this case individual routes are updated when the ES links flap. PS: #1 can be turned off entirely by disabling use-l3-nhg in BGP. Ticket: CM-30935 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 19, 2021
There are two changes in this commit - 1. Maintain a list of global MAC-IP routes per-ES. This list is maintained for quick processing on the following events - a. When the first VTEP/PE becomes active in the ES-VRF, the L3 NHG is activated and the route can be sent to zebra. b. When there are no active PEs in the ES-VRF the L3 NHG is de-activated and - - If the ES is present in the VRF - The route is not installed in zebra as there are no active PEs for the ES-VRF - If the ES is not present in the VRF - The route is installed with a flat multi-path list i.e. without L3NHG. This is to handle the case where there are no locally attached L2VNIs on the ES (for that tenant VRF). 2. Reinstall VRF route when an ES is installed or uninstalled in a tenant VRF (the global MAC-IP list in #1 is used for this purpose also). If an ES is present in the VRF we use L3NHG to enable fast-failover of routed traffic. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 19, 2021
This problem was reported by the sanitizer - ================================================================= ==24764==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000115c8 at pc 0x55cb9cfad312 bp 0x7fffa0552140 sp 0x7fffa0552138 READ of size 8 at 0x60d0000115c8 thread T0 #0 0x55cb9cfad311 in zebra_evpn_remote_es_flush zebra/zebra_evpn_mh.c:2041 #1 0x55cb9cfad311 in zebra_evpn_es_cleanup zebra/zebra_evpn_mh.c:2234 #2 0x55cb9cf6ae78 in zebra_vrf_disable zebra/zebra_vrf.c:205 FRRouting#3 0x7fc8d478f114 in vrf_delete lib/vrf.c:229 FRRouting#4 0x7fc8d478f99a in vrf_terminate lib/vrf.c:541 FRRouting#5 0x55cb9ceba0af in sigint zebra/main.c:176 FRRouting#6 0x55cb9ceba0af in sigint zebra/main.c:130 FRRouting#7 0x7fc8d4765d20 in quagga_sigevent_process lib/sigevent.c:103 FRRouting#8 0x7fc8d4787e8c in thread_fetch lib/thread.c:1396 FRRouting#9 0x7fc8d4708782 in frr_run lib/libfrr.c:1092 FRRouting#10 0x55cb9ce931d8 in main zebra/main.c:488 FRRouting#11 0x7fc8d43ee09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#12 0x55cb9ce94c09 in _start (/usr/lib/frr/zebra+0x8ac09) ================================================================= Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 19, 2021
When zebra is running with debugs turned on there is a use after free reported by the address sanitizer: 2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing 2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3 ================================================================= ==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8 READ of size 8 at 0x608000011d28 thread T0 #0 0x555555705ab5 in re_list_const_first zebra/rib.h:222 #1 0x555555705b54 in re_list_first zebra/rib.h:222 #2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248 FRRouting#3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286 FRRouting#4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320 FRRouting#5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291 FRRouting#6 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#8 0x55555561a578 in main zebra/main.c:455 FRRouting#9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 FRRouting#10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429) 0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78) freed by thread T0 here: #0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f) #1 0x7ffff739ccad in qfree lib/memory.c:129 #2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746 FRRouting#3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240 FRRouting#4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245 FRRouting#5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286 FRRouting#6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320 FRRouting#7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291 FRRouting#8 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#10 0x55555561a578 in main zebra/main.c:455 FRRouting#11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037) #1 0x7ffff739cb98 in qcalloc lib/memory.c:110 #2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515 FRRouting#3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576 FRRouting#4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607 FRRouting#5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012 FRRouting#6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049 FRRouting#7 0x55555571788b in rib_add zebra/zebra_rib.c:3327 FRRouting#8 0x5555555e584a in connected_up zebra/connected.c:254 FRRouting#9 0x5555555e42ff in connected_announce zebra/connected.c:94 FRRouting#10 0x5555555e4fd3 in connected_update zebra/connected.c:195 FRRouting#11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340 FRRouting#12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213 FRRouting#13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350 FRRouting#14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941 FRRouting#15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402 FRRouting#16 0x7ffff7450e9c in thread_call lib/thread.c:1581 FRRouting#17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099 FRRouting#18 0x55555561a578 in main zebra/main.c:455 FRRouting#19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first This is happening because we are using the dest pointer after a call into rib_gc_dest. In process_subq_route, we call rib_process() and if the dest is deleted dest pointer is now garbage. We must reload the dest pointer in this case. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Mar 19, 2021
Current code in bgp bestpath selection would accept the newest locally originated path as the best path. Making the selection non-deterministic. Modify the code to always come to the same bestpath conclusion when you have multiple locally originated paths in bestpath selection. Before: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Notice the route choosen depends on order received Fixed behavior: eva# conf eva(config)# router bgp 323 eva(config-router)# address-family ipv4 uni eva(config-router-af)# redistribute connected eva(config-router-af)# network 192.168.161.0/24 eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:02:52 2020 eva(config-router-af)# no redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (1 available, best #1, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# redistribute connected eva(config-router-af)# do show bgp ipv4 uni 192.168.161.0 BGP routing table entry for 192.168.161.0/24 Paths: (2 available, best #2, table default) Not advertised to any peer Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin incomplete, metric 0, weight 32768, valid, sourced Last update: Wed Sep 16 15:03:32 2020 Local 0.0.0.0(eva) from 0.0.0.0 (192.168.161.245) Origin IGP, metric 0, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (Origin) Last update: Wed Sep 16 15:03:03 2020 eva(config-router-af)# Ticket: CM-31490 Found-by: Trey Aspelund <taspelund@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 5, 2021
Sample Configuration with prefix-list and community match rules --------------------------------------------------------------- R1 ------- R2(DUT) ------- R3 Router2# show running-config Building configuration... Current configuration: ! frr version 7.6-dev-MyOwnFRRVersion frr defaults traditional hostname router log file /var/log/frr/bgpd.log log syslog informational hostname Router2 service integrated-vtysh-config ! debug bgp updates in debug bgp updates out ! debug route-map ! ip route 20.20.0.0/16 blackhole ipv6 route 2001:db8::200/128 blackhole ! interface enp0s9 ip address 10.10.10.2/24 ! interface enp0s10 ip address 10.10.20.2/24 ! interface lo ip address 2.2.2.2/32 ! router bgp 2 bgp log-neighbor-changes no bgp ebgp-requires-policy neighbor 10.10.10.1 remote-as 1 neighbor 10.10.20.3 remote-as 3 ! address-family ipv4 unicast neighbor 10.10.10.1 soft-reconfiguration inbound neighbor 10.10.20.3 soft-reconfiguration inbound neighbor 10.10.20.3 advertise-map ADV-MAP non-exist-map EXIST-MAP exit-address-family ! ip prefix-list DEFAULT seq 5 permit 1.1.1.5/32 ip prefix-list DEFAULT seq 10 permit 1.1.1.1/32 ip prefix-list EXIST seq 5 permit 10.10.10.10/32 ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0 ip prefix-list IP1 seq 5 permit 10.139.224.0/20 ip prefix-list T2 seq 5 permit 1.1.1.5/32 ! bgp community-list standard DC-ROUTES seq 5 permit 64952:3008 bgp community-list standard DC-ROUTES seq 10 permit 64671:501 bgp community-list standard DC-ROUTES seq 15 permit 64950:3009 bgp community-list standard DEFAULT-ROUTE seq 5 permit 65013:200 ! route-map ADV-MAP permit 10 match ip address prefix-list IP1 ! route-map ADV-MAP permit 20 match community DC-ROUTES ! route-map EXIST-MAP permit 10 match community DEFAULT-ROUTE match ip address prefix-list DEFAULT-ROUTE ! line vty ! end Router2# Router2# show ip bgp 0.0.0.0 BGP routing table entry for 0.0.0.0/0 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 10.10.10.1 10.10.20.3 1 10.10.10.1 from 10.10.10.1 (10.139.224.1) Origin IGP, metric 0, valid, external, best (First path received) Community: 64848:3011 65011:200 65013:200 Last update: Tue Oct 6 02:39:42 2020 Router2# Sample output with non-exist-map when default route present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 4, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 10.10.10.1 0 0 1 i *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 4 routes and 4 total paths Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 4, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i <<<<<<<<< non-exist-map : 0.0.0.0/0 is present so, 10.139.224.0/20 not advertised Total number of prefixes 2 Sample output with non-exist-map when default route not present in table ------------------------------------------------------------------------ Router2# show ip bgp BGP table version is 5, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 3 routes and 3 total paths Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 5, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i *> 10.139.224.0/20 0.0.0.0 0 1 ? <<<<<<<<< non-exist-map : 0.0.0.0/0 is not present so, 10.139.224.0/20 advertised Total number of prefixes 3 Router2# Sample output with exist-map when default route present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 8, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 10.10.10.1 0 0 1 i *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 4 routes and 4 total paths Router2# Router2# Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 8, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 0.0.0.0 0 1 i *> 1.1.1.1/32 0.0.0.0 0 1 i *> 1.1.1.5/32 0.0.0.0 0 1 i *> 10.139.224.0/20 0.0.0.0 0 1 ? <<<<<<<<< exist-map : 0.0.0.0/0 is present so, 10.139.224.0/20 advertised Total number of prefixes 4 Router2# Sample output with exist-map when default route not present in table -------------------------------------------------------------------- Router2# show ip bgp BGP table version is 9, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.10.10.1 0 0 1 i *> 1.1.1.5/32 10.10.10.1 0 0 1 i *> 10.139.224.0/20 10.10.10.1 0 0 1 ? Displayed 3 routes and 3 total paths Router2# Router2# Router2# Router2# show ip bgp neighbors 10.10.20.3 advertised-routes BGP table version is 9, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 2 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 Network Next Hop Metric LocPrf Weight Path *> 1.1.1.5/32 0.0.0.0 0 1 i <<<<<<<<< exist-map : 0.0.0.0/0 is not present so, 10.139.224.0/20 not advertised Total number of prefixes 1 Router2# Signed-off-by: Madhuri Kuruganti <k.madhuri@samsung.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 22, 2021
When dumping data about prefixes in bgp. Let's dump the rpki validation state as well: Output if rpki is turned on: janelle# show rpki prefix 2003::/19 Prefix Prefix Length Origin-AS 2003:: 19 - 19 3320 janelle# show bgp ipv6 uni 2003::/19 BGP routing table entry for 2003::/19 Paths: (1 available, best #1, table default) Not advertised to any peer 15096 6939 3320 ::ffff:4113:867a from 65.19.134.122 (193.72.216.231) (fe80::e063:daff:fe79:1dab) (used) Origin IGP, valid, external, best (First path received), validation-state: valid Last update: Sat Mar 6 09:20:51 2021 janelle# show rpki prefix 8.8.8.0/24 Prefix Prefix Length Origin-AS janelle# show bgp ipv4 uni 8.8.8.0/24 BGP routing table entry for 8.8.8.0/24 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 100.99.229.142 15096 6939 15169 65.19.134.122 from 65.19.134.122 (193.72.216.231) Origin IGP, valid, external, best (First path received), validation-state: not found Last update: Sat Mar 6 09:21:25 2021 Example output when rpki is not configured: eva# show bgp ipv4 uni 8.8.8.0/24 BGP routing table entry for 8.8.8.0/24 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: janelle(192.168.161.137) 64539 15096 6939 15169 192.168.161.137(janelle) from janelle(192.168.161.137) (192.168.44.1) Origin IGP, valid, external, bestpath-from-AS 64539, best (First path received) Last update: Sat Mar 6 09:33:51 2021 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 22, 2021
The following error is shown when running the OSPFv3 tests 2021-03-16 23:37:44,792 INFO: Function returned global name 'data_rid' is not defined 2021-03-16 23:37:44,792 INFO: Retry [#1] after sleeping for 2s 2021-03-16 23:37:46,794 INFO: Verifying OSPF6 neighborship on router r1: 2021-03-16 23:37:46,993 INFO: Output for command [ show ipv6 ospf6 neighbor ] on router r1: Neighbor ID Pri DeadTime State/IfState Duration I/F[State] 2.2.2.2 1 00:00:03 Full/PointToPoint 00:00:01 r1-r2-eth0[PointToPoint] Fix the "data_rid" warning by using the correct variable Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 22, 2021
In a sym-IRB setup the remote ES may not be installed if the tenant VRF is not present locally. To allow that case while retaining the fast-failover benefits for the case where the tenant VRF is locally present we use the following approach - 1. If ES is present in the tenant VRF we use the L3NHG for installing the MAC-IP based tenant route. This allows for efficient failover via L3NHG updates. 2. If the ES is not present locally in the corresponding tenant VRF we fall back to a non-NHG multi-path based routing approach. In this case individual routes are updated when the ES links flap. PS: #1 can be turned off entirely by disabling use-l3-nhg in BGP. Ticket: CM-30935 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Apr 22, 2021
There are two changes in this commit - 1. Maintain a list of global MAC-IP routes per-ES. This list is maintained for quick processing on the following events - a. When the first VTEP/PE becomes active in the ES-VRF, the L3 NHG is activated and the route can be sent to zebra. b. When there are no active PEs in the ES-VRF the L3 NHG is de-activated and - - If the ES is present in the VRF - The route is not installed in zebra as there are no active PEs for the ES-VRF - If the ES is not present in the VRF - The route is installed with a flat multi-path list i.e. without L3NHG. This is to handle the case where there are no locally attached L2VNIs on the ES (for that tenant VRF). 2. Reinstall VRF route when an ES is installed or uninstalled in a tenant VRF (the global MAC-IP list in #1 is used for this purpose also). If an ES is present in the VRF we use L3NHG to enable fast-failover of routed traffic. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
sworleys
pushed a commit
that referenced
this pull request
Jul 2, 2021
Display gateway IP attribute in show command "show bgp l2vpn evpn route type prefix [json]" dev# sh bgp l2vpn evpn 100.0.0.21 BGP routing table entry for 10.100.0.2:1000:[5]:[0]:[32]:[100.0.0.21] Paths: (1 available, best #1) Advertised to non peer-group peers: 10.0.1.1 Route [5]:[0]:[32]:[100.0.0.21] VNI 1000 Gateway IP 50.0.2.21 203 10.100.0.2 from 0.0.0.0 (10.100.0.2) Origin IGP, metric 0, valid, sourced, local, best (First path received) Extended Community: ET:8 RT:102:1000 Rmac:72:48:54:da:7f:13 Last update: Mon Jun 29 12:29:05 2020 Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
sworleys
pushed a commit
that referenced
this pull request
Jan 26, 2022
``` exit1-debian-11# sh ip bgp 10.10.10.10/32 BGP routing table entry for 10.10.10.10/32, version 14 Paths: (1 available, best #1, table default) Not advertised to any peer 65000, (stale) 192.168.0.2 from 192.168.0.2 (0.0.0.0) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Wed Jan 19 17:13:51 2022 Time until Graceful Restart stale route deleted: 117 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
sworleys
pushed a commit
that referenced
this pull request
May 18, 2022
When the connection goes up, the timer is not stopped and if we have a subsequent GR event we have an old timer which is not as we expect. Before: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 95 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:27:53 2022 Time until Long-lived stale route deleted: 23 <<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 08:43:29 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:43:30 2022 Time until Long-lived stale route deleted: 17 <<<<<<<<<<<<<<< ``` After: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 79 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (0.0.0.0) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:18 2022 Time until Long-lived stale route deleted: 24 <<<<<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 09:05:25 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:29 2022 Time until Long-lived stale route deleted: 29 <<<<<<<<<<<<<< ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
sworleys
pushed a commit
that referenced
this pull request
May 18, 2022
Fixing the crash: > #0 0x0000560aa80f8e30 in lspdb_const_find (h=<error reading variable: Cannot access memory at address 0x7fff5e95efe8>, item=<error reading variable: Cannot access memory at address 0x7fff5e95efe0>) at ./isisd/isis_lsp.h:64 > #1 0x0000560aa80f8e9d in lspdb_find (h=0x560aaa1ed3b8, item=0x7fff5e95f050) at ./isisd/isis_lsp.h:64 > #2 0x0000560aa80f92f9 in lsp_search (head=0x560aaa1ed3b8, id=0x7fff5e95f200 "") at isisd/isis_lsp.c:100 > FRRouting#3 0x0000560aa8113d69 in spf_adj_list_parse_tlv (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, id=0x560aad331a78 "", desig_is_id=0x0, pseudo_metric=0, metric=3, oldmetric=false, subtlvs=0x0) at isisd/isis_spf.c:1330 > FRRouting#4 0x0000560aa811419d in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1429 > FRRouting#5 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > FRRouting#6 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > (...) > #65507 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65508 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65509 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65510 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65511 0x0000560aa8114313 in isis_spf_build_adj_list (spftree=0x560aaa1f09d0, lsp=0x560aaa1f4e50) at isisd/isis_spf.c:1455 > #65512 0x0000560aa8114f09 in isis_run_spf (spftree=0x560aaa1f09d0) at isisd/isis_spf.c:1775 > #65513 0x0000560aa8115057 in isis_run_spf_with_protection (area=0x560aaa1ed3b0, spftree=0x560aaa1f09d0) at isisd/isis_spf.c:1801 > #65514 0x0000560aa8115311 in isis_run_spf_cb (thread=0x7fff5f15e5a0) at isisd/isis_spf.c:1859 > #65515 0x00007f90bac66dcc in thread_call (thread=0x7fff5f15e5a0) at lib/thread.c:2002 > #65516 0x00007f90bac013ee in frr_run (master=0x560aa9f5cb40) at lib/libfrr.c:1196 > #65517 0x0000560aa80e7da2 in main (argc=2, argv=0x7fff5f15e7b8, envp=0x7fff5f15e7d0) at isisd/isis_main.c:273 Fixes: 7b36d36 ("isisd: make the SPF code more modular") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
sworleys
pushed a commit
that referenced
this pull request
May 18, 2022
``` route-map tstas permit 10 set as-path replace 1 exit ``` Before: ``` donatas-laptop(config-router-af)# do show ip bgp 10.10.10.10/32 BGP routing table entry for 10.10.10.10/32, version 13 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.10.65 65000 1 2 3 123 192.168.10.65 from 192.168.10.65 (10.10.10.11) Origin IGP, metric 0, valid, external, best (First path received) Last update: Mon Apr 25 10:39:50 2022 ``` After: ``` donatas-laptop(config-router-af)# do show ip bgp 10.10.10.10/32 BGP routing table entry for 10.10.10.10/32, version 15 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.10.65 65000 65010 2 3 123 192.168.10.65 from 192.168.10.65 (10.10.10.11) Origin IGP, metric 0, valid, external, best (First path received) Last update: Mon Apr 25 10:40:16 2022 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
sworleys
pushed a commit
that referenced
this pull request
Aug 16, 2022
Fixing the crash: > #0 0x0000560aa80f8e30 in lspdb_const_find (h=<error reading variable: Cannot access memory at address 0x7fff5e95efe8>, item=<error reading variable: Cannot access memory at address 0x7fff5e95efe0>) at ./isisd/isis_lsp.h:64 > #1 0x0000560aa80f8e9d in lspdb_find (h=0x560aaa1ed3b8, item=0x7fff5e95f050) at ./isisd/isis_lsp.h:64 > #2 0x0000560aa80f92f9 in lsp_search (head=0x560aaa1ed3b8, id=0x7fff5e95f200 "") at isisd/isis_lsp.c:100 > FRRouting#3 0x0000560aa8113d69 in spf_adj_list_parse_tlv (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, id=0x560aad331a78 "", desig_is_id=0x0, pseudo_metric=0, metric=3, oldmetric=false, subtlvs=0x0) at isisd/isis_spf.c:1330 > FRRouting#4 0x0000560aa811419d in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1429 > FRRouting#5 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > FRRouting#6 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > (...) > #65507 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65508 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65509 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1ff8e0, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65510 0x0000560aa81141fe in spf_adj_list_parse_lsp (spftree=0x560aaa1f09d0, adj_list=0x560aaa214480, lsp=0x560aaa1f4e50, pseudo_nodeid=0x0, pseudo_metric=0) at isisd/isis_spf.c:1442 > #65511 0x0000560aa8114313 in isis_spf_build_adj_list (spftree=0x560aaa1f09d0, lsp=0x560aaa1f4e50) at isisd/isis_spf.c:1455 > #65512 0x0000560aa8114f09 in isis_run_spf (spftree=0x560aaa1f09d0) at isisd/isis_spf.c:1775 > #65513 0x0000560aa8115057 in isis_run_spf_with_protection (area=0x560aaa1ed3b0, spftree=0x560aaa1f09d0) at isisd/isis_spf.c:1801 > #65514 0x0000560aa8115311 in isis_run_spf_cb (thread=0x7fff5f15e5a0) at isisd/isis_spf.c:1859 > #65515 0x00007f90bac66dcc in thread_call (thread=0x7fff5f15e5a0) at lib/thread.c:2002 > #65516 0x00007f90bac013ee in frr_run (master=0x560aa9f5cb40) at lib/libfrr.c:1196 > #65517 0x0000560aa80e7da2 in main (argc=2, argv=0x7fff5f15e7b8, envp=0x7fff5f15e7d0) at isisd/isis_main.c:273 The fix is similar to the crash fix included in d9884a7 ("isisd: Prepare IS-IS for Link State support"). The fix was: > diff --git a/isisd/isis_lsp.c b/isisd/isis_lsp.c > index 94353a5bc8..92d329f035 100644 > --- a/isisd/isis_lsp.c > +++ b/isisd/isis_lsp.c > @@ -2166,7 +2178,7 @@ int isis_lsp_iterate_ip_reach(struct isis_lsp *lsp, int family, uint16_t mtid, > if (lsp->hdr.seqno == 0 || lsp->hdr.rem_lifetime == 0) > return LSP_ITER_CONTINUE; > > - /* Parse main LSP. */ > + /* Parse LSP */ > if (lsp->tlvs) { > if (!fabricd && !pseudo_lsp && family == AF_INET > && mtid == ISIS_MT_IPV4_UNICAST) { > @@ -2236,13 +2248,17 @@ int isis_lsp_iterate_ip_reach(struct isis_lsp *lsp, int family, uint16_t mtid, > } > } > > - /* Parse LSP fragments. */ > - for (ALL_LIST_ELEMENTS_RO(lsp->lspu.frags, node, frag)) { > - if (!frag->tlvs) > - continue; > + /* Parse LSP fragments if it is not a fragment itself */ > + if (!LSP_FRAGMENT(lsp->hdr.lsp_id)) > + for (ALL_LIST_ELEMENTS_RO(lsp->lspu.frags, node, frag)) { > + if (!frag->tlvs) > + continue; > > - isis_lsp_iterate_ip_reach(frag, family, mtid, cb, arg); > - } > + if (isis_lsp_iterate_ip_reach(frag, family, mtid, cb, > + arg) > + == LSP_ITER_STOP) > + return LSP_ITER_STOP; > + } > > return LSP_ITER_CONTINUE; > } Fixes: 7b36d36 ("isisd: make the SPF code more modular") Fixes: 5e56a50 ("isisd: fix infinite loop when parsing LSPs") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
sworleys
pushed a commit
that referenced
this pull request
Oct 5, 2022
``` spine1-debian-11# sh ip bgp 100.100.100.101/32 BGP routing table entry for 100.100.100.101/32, version 21 Paths: (1 available, best #1, table default) Not advertised to any peer Local fe80::ca5d:fd0d:cd8:1bb7 from eth3 (172.17.0.3) (fe80::ca5d:fd0d:cd8:1bb7) (used) Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received) Extended Community: OVS:invalid Last update: Wed Aug 31 19:31:46 2022 spine1-debian-11# sh ip bgp 100.100.100.100/32 BGP routing table entry for 100.100.100.100/32, version 17 Paths: (1 available, best #1, table default) Not advertised to any peer Local fe80::ca5d:fd0d:cd8:1bb7 from eth3 (172.17.0.3) (fe80::ca5d:fd0d:cd8:1bb7) (used) Origin incomplete, metric 0, localpref 100, valid, internal, best (First path received) Extended Community: OVS:not-found Last update: Wed Aug 31 19:31:46 2022 spine1-debian-11# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
sworleys
pushed a commit
that referenced
this pull request
Dec 9, 2022
The rl_callback_handler_install function manual says this: Set up the terminal for Readline I/O and display the initial expanded value of prompt. Save the value of lhandler to use as a handler function to call when a complete line of input has been entered. The handler function receives the text of the line as an argument. As with readline(), the handler function should free the line when it is finished with it. Adding a free removes this memory leak that I am seeing with address sanitizer enabled; SUMMARY: AddressSanitizer: 99 byte(s) leaked in 5 allocation(s).: 2022-12-05 07:50:57,231 INFO: topolog.r7: vtysh result: Hello, this is FRRouting (version 8.5-dev). Copyright 1996-2005 Kunihiro Ishiguro, et al. r7# clear log cmdline-targets r7# conf t r7(config)# log file staticd.log debug r7(config)# log commands r7(config)# log timestamp precision 3 r7(config)# ================================================================= ==976989==ERROR: LeakSanitizer: detected memory leaks Direct leak of 99 byte(s) in 5 object(s) allocated from: #0 0x49cadd in malloc (/usr/bin/vtysh+0x49cadd) #1 0x7fc57135d8e8 in xmalloc build/shlib/./xmalloc.c:59:10 SUMMARY: AddressSanitizer: 99 byte(s) leaked in 5 allocation(s). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 9, 2022
Config data was being freed just prior to it being used for cleanup in shutdown. Prevent this from happening. ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-================================================================= ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142:==2274142==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d00000c880 at pc 0x0000004d94d1 bp 0x7ffd46637810 sp 0 x7ffd46637808 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-READ of size 4 at 0x61d00000c880 thread T0 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #0 0x4d94d0 in ldp_rtr_id_get /home/sharpd/frr8/ldpd/ldpd.c:983:20 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #1 0x56ff92 in gen_ldp_hdr /home/sharpd/frr8/ldpd/packet.c:47:19 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #2 0x56a4b0 in send_notification_full /home/sharpd/frr8/ldpd/notification.c:49:9 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#3 0x56c4b3 in send_notification /home/sharpd/frr8/ldpd/notification.c:117:2 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#4 0x573fb7 in session_shutdown /home/sharpd/frr8/ldpd/packet.c:666:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#5 0x4e2ef1 in adj_del /home/sharpd/frr8/ldpd/adjacency.c:145:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#6 0x55d425 in ldpe_shutdown /home/sharpd/frr8/ldpd/ldpe.c:231:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#7 0x55a9a0 in ldpe_dispatch_main /home/sharpd/frr8/ldpd/ldpe.c:631:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#8 0x7f0c00c035e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#9 0x5586f2 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:138:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#10 0x4d46d2 in main /home/sharpd/frr8/ldpd/ldpd.c:339:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#11 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#12 0x429cb9 in _start (/usr/lib/frr/ldpd+0x429cb9) ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-0x61d00000c880 is located 0 bytes inside of 2008-byte region [0x61d00000c880,0x61d00000d058) ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-freed by thread T0 here: ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #0 0x4a3aad in free (/usr/lib/frr/ldpd+0x4a3aad) ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #1 0x4de6c8 in config_clear /home/sharpd/frr8/ldpd/ldpd.c:2001:2 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #2 0x55d12d in ldpe_shutdown /home/sharpd/frr8/ldpd/ldpe.c:211:2 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#3 0x55a9a0 in ldpe_dispatch_main /home/sharpd/frr8/ldpd/ldpe.c:631:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#4 0x7f0c00c035e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#5 0x5586f2 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:138:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#6 0x4d46d2 in main /home/sharpd/frr8/ldpd/ldpd.c:339:3 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#7 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142-previously allocated by thread T0 here: ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #0 0x4a3ea2 in calloc (/usr/lib/frr/ldpd+0x4a3ea2) ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #1 0x4d6146 in config_new_empty /home/sharpd/frr8/ldpd/ldpd.c:1967:10 ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- #2 0x558678 in ldpe /home/sharpd/frr8/ldpd/ldpe.c:134:11 -- ./isis_rlfa_topo1.test_isis_rlfa_topo1/rt8.ldpd.asan.2274142- FRRouting#4 0x7f0c00476d09 in __libc_start_main csu/../csu/libc-start.c:308:16 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 9, 2022
On shutdown a use after free was being seen of a route table. Basically the pointer was kept around and resent for cleanup. Probably something needs to be unwound to make this better in the future. Just cleaning up the use after free. ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-================================================================= ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929:==911929==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000127a00 at pc 0x7fb9ad546f5b bp 0x7ffc3cff0330 sp 0x7ffc3 cff0328 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-READ of size 8 at 0x606000127a00 thread T0 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #0 0x7fb9ad546f5a in route_table_free /home/sharpd/frr8/lib/table.c:103:13 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #1 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #2 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#3 0x6b9158 in zebra_ns_disabled /home/sharpd/frr8/zebra/zebra_ns.c:116:9 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#4 0x7fb9ad43f0f5 in ns_disable_internal /home/sharpd/frr8/lib/netns_linux.c:273:4 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#5 0x7fb9ad43e634 in ns_disable /home/sharpd/frr8/lib/netns_linux.c:368:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#6 0x7fb9ad43e251 in ns_delete /home/sharpd/frr8/lib/netns_linux.c:330:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#7 0x7fb9ad43fbb3 in ns_terminate /home/sharpd/frr8/lib/netns_linux.c:524:3 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#8 0x54f8de in zebra_finalize /home/sharpd/frr8/zebra/main.c:232:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#9 0x7fb9ad5655e6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#10 0x7fb9ad3d3343 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#12 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#13 0x443549 in _start (/usr/lib/frr/zebra+0x443549) ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-0x606000127a00 is located 0 bytes inside of 56-byte region [0x606000127a00,0x606000127a38) ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929-freed by thread T0 here: ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #0 0x4bd33d in free (/usr/lib/frr/zebra+0x4bd33d) ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #1 0x7fb9ad42cc80 in qfree /home/sharpd/frr8/lib/memory.c:141:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- #2 0x7fb9ad547305 in route_table_free /home/sharpd/frr8/lib/table.c:141:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#3 0x7fb9ad546f04 in route_table_finish /home/sharpd/frr8/lib/table.c:61:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#4 0x6b94ba in zebra_ns_disable_internal /home/sharpd/frr8/zebra/zebra_ns.c:141:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#5 0x6b9692 in zebra_ns_early_shutdown /home/sharpd/frr8/zebra/zebra_ns.c:164:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#6 0x7fb9ad43f228 in ns_walk_func /home/sharpd/frr8/lib/netns_linux.c:386:9 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#7 0x55014f in sigint /home/sharpd/frr8/zebra/main.c:194:2 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#8 0x7fb9ad50db99 in frr_sigevent_process /home/sharpd/frr8/lib/sigevent.c:130:6 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#9 0x7fb9ad560d07 in thread_fetch /home/sharpd/frr8/lib/thread.c:1775:4 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#10 0x7fb9ad3d332d in frr_run /home/sharpd/frr8/lib/libfrr.c:1197:9 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#11 0x550b48 in main /home/sharpd/frr8/zebra/main.c:476:2 -- ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- FRRouting#7 0x7fb9acd30d09 in __libc_start_main csu/../csu/libc-start.c:308:16 ./bfd_vrf_topo1.test_bfd_vrf_topo1/r2.zebra.asan.911929- Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Dec 9, 2022
When changing the peers sockunion structure the bgp->peer list was not being updated properly. Since the peer's su is being used for a sorted insert then the change of it requires that the value be pulled out of the bgp->peer list and then put back into as well. Additionally ensure that the hash is always released on peer deletion. Lead to this from this decode in a address sanitizer run. ================================================================= ==30778==ERROR: AddressSanitizer: heap-use-after-free on address 0x62a0000d8440 at pc 0x7f48c9c5c547 bp 0x7ffcba272cb0 sp 0x7ffcba272ca8 READ of size 2 at 0x62a0000d8440 thread T0 #0 0x7f48c9c5c546 in sockunion_same lib/sockunion.c:425 #1 0x55cfefe3000f in peer_hash_same bgpd/bgpd.c:890 #2 0x7f48c9bde039 in hash_release lib/hash.c:209 FRRouting#3 0x55cfefe3373f in bgp_peer_conf_if_to_su_update bgpd/bgpd.c:1541 FRRouting#4 0x55cfefd0be7a in bgp_stop bgpd/bgp_fsm.c:1631 FRRouting#5 0x55cfefe4028f in peer_delete bgpd/bgpd.c:2362 FRRouting#6 0x55cfefdd5e97 in no_neighbor_interface_config bgpd/bgp_vty.c:4267 FRRouting#7 0x7f48c9b9d160 in cmd_execute_command_real lib/command.c:949 FRRouting#8 0x7f48c9ba1112 in cmd_execute_command lib/command.c:1009 FRRouting#9 0x7f48c9ba1573 in cmd_execute lib/command.c:1162 FRRouting#10 0x7f48c9c87402 in vty_command lib/vty.c:526 FRRouting#11 0x7f48c9c87832 in vty_execute lib/vty.c:1291 FRRouting#12 0x7f48c9c8e741 in vtysh_read lib/vty.c:2130 FRRouting#13 0x7f48c9c7a66d in thread_call lib/thread.c:1585 FRRouting#14 0x7f48c9bf64e7 in frr_run lib/libfrr.c:1123 FRRouting#15 0x55cfefc75a15 in main bgpd/bgp_main.c:540 FRRouting#16 0x7f48c96b009a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) FRRouting#17 0x55cfefc787f9 in _start (/usr/lib/frr/bgpd+0xe27f9) 0x62a0000d8440 is located 576 bytes inside of 23376-byte region [0x62a0000d8200,0x62a0000ddd50) freed by thread T0 here: #0 0x7f48c9eb9fb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0) #1 0x55cfefe3fe42 in peer_free bgpd/bgpd.c:1113 #2 0x55cfefe3fe42 in peer_unlock_with_caller bgpd/bgpd.c:1144 FRRouting#3 0x55cfefe4092e in peer_delete bgpd/bgpd.c:2457 FRRouting#4 0x55cfefdd5e97 in no_neighbor_interface_config bgpd/bgp_vty.c:4267 FRRouting#5 0x7f48c9b9d160 in cmd_execute_command_real lib/command.c:949 FRRouting#6 0x7f48c9ba1112 in cmd_execute_command lib/command.c:1009 FRRouting#7 0x7f48c9ba1573 in cmd_execute lib/command.c:1162 FRRouting#8 0x7f48c9c87402 in vty_command lib/vty.c:526 FRRouting#9 0x7f48c9c87832 in vty_execute lib/vty.c:1291 FRRouting#10 0x7f48c9c8e741 in vtysh_read lib/vty.c:2130 FRRouting#11 0x7f48c9c7a66d in thread_call lib/thread.c:1585 FRRouting#12 0x7f48c9bf64e7 in frr_run lib/libfrr.c:1123 FRRouting#13 0x55cfefc75a15 in main bgpd/bgp_main.c:540 FRRouting#14 0x7f48c96b009a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Feb 9, 2023
Address Sanitizer found this: ================================================================= ==418623==ERROR: LeakSanitizer: detected memory leaks Direct leak of 128 byte(s) in 4 object(s) allocated from: #0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732) #1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27 #2 0x7feaeaba40f4 in nexthop_group_new /home/sharpd/frr8/lib/nexthop_group.c:270:9 FRRouting#3 0x56859b in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:950:9 FRRouting#4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2 FRRouting#5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10 FRRouting#6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12 FRRouting#7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2 FRRouting#8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 FRRouting#9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3 FRRouting#10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2 FRRouting#11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16 Indirect leak of 576 byte(s) in 4 object(s) allocated from: #0 0x4bd732 in calloc (/usr/lib/frr/zebra+0x4bd732) #1 0x7feaeab8f798 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27 #2 0x7feaeab9b3f8 in nexthop_new /home/sharpd/frr8/lib/nexthop.c:373:7 FRRouting#3 0x56875e in netlink_route_change_read_unicast /home/sharpd/frr8/zebra/rt_netlink.c:960:15 FRRouting#4 0x5651c2 in netlink_route_change /home/sharpd/frr8/zebra/rt_netlink.c:1204:2 FRRouting#5 0x54af15 in netlink_information_fetch /home/sharpd/frr8/zebra/kernel_netlink.c:407:10 FRRouting#6 0x53e7a3 in netlink_parse_info /home/sharpd/frr8/zebra/kernel_netlink.c:1184:12 FRRouting#7 0x548d46 in kernel_read /home/sharpd/frr8/zebra/kernel_netlink.c:501:2 FRRouting#8 0x7feaeacc87f6 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 FRRouting#9 0x7feaeab36503 in frr_run /home/sharpd/frr8/lib/libfrr.c:1198:3 FRRouting#10 0x550d38 in main /home/sharpd/frr8/zebra/main.c:476:2 FRRouting#11 0x7feaea492d09 in __libc_start_main csu/../csu/libc-start.c:308:16 SUMMARY: AddressSanitizer: 704 byte(s) leaked in 8 allocation(s). Fix this! Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Feb 9, 2023
ASAN reported the following memleak: ``` Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x4d4342 in calloc (/usr/lib/frr/bgpd+0x4d4342) #1 0xbc3d68 in qcalloc /home/sharpd/frr8/lib/memory.c:116:27 #2 0xb869f7 in list_new /home/sharpd/frr8/lib/linklist.c:64:9 FRRouting#3 0x5a38bc in bgp_evpn_remote_ip_hash_alloc /home/sharpd/frr8/bgpd/bgp_evpn.c:6789:24 FRRouting#4 0xb358d3 in hash_get /home/sharpd/frr8/lib/hash.c:162:13 FRRouting#5 0x593d39 in bgp_evpn_remote_ip_hash_add /home/sharpd/frr8/bgpd/bgp_evpn.c:6881:7 FRRouting#6 0x59dbbd in install_evpn_route_entry_in_vni_common /home/sharpd/frr8/bgpd/bgp_evpn.c:3049:2 FRRouting#7 0x59cfe0 in install_evpn_route_entry_in_vni_ip /home/sharpd/frr8/bgpd/bgp_evpn.c:3126:8 FRRouting#8 0x59c6f0 in install_evpn_route_entry /home/sharpd/frr8/bgpd/bgp_evpn.c:3318:8 FRRouting#9 0x59bb52 in install_uninstall_route_in_vnis /home/sharpd/frr8/bgpd/bgp_evpn.c:3888:10 FRRouting#10 0x59b6d2 in bgp_evpn_install_uninstall_table /home/sharpd/frr8/bgpd/bgp_evpn.c:4019:5 FRRouting#11 0x578857 in install_uninstall_evpn_route /home/sharpd/frr8/bgpd/bgp_evpn.c:4051:9 FRRouting#12 0x58ada6 in bgp_evpn_import_route /home/sharpd/frr8/bgpd/bgp_evpn.c:6049:9 FRRouting#13 0x713794 in bgp_update /home/sharpd/frr8/bgpd/bgp_route.c:4842:3 FRRouting#14 0x583fa0 in process_type2_route /home/sharpd/frr8/bgpd/bgp_evpn.c:4518:9 FRRouting#15 0x5824ba in bgp_nlri_parse_evpn /home/sharpd/frr8/bgpd/bgp_evpn.c:5732:8 FRRouting#16 0x6ae6a2 in bgp_nlri_parse /home/sharpd/frr8/bgpd/bgp_packet.c:363:10 FRRouting#17 0x6be6fa in bgp_update_receive /home/sharpd/frr8/bgpd/bgp_packet.c:2020:15 FRRouting#18 0x6b7433 in bgp_process_packet /home/sharpd/frr8/bgpd/bgp_packet.c:2929:11 FRRouting#19 0xd00146 in thread_call /home/sharpd/frr8/lib/thread.c:2006:2 ``` The list itself was not being cleaned up when the final list entry was removed, so make sure we do that instead of leaking memory. Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
sworleys
pushed a commit
that referenced
this pull request
Feb 9, 2023
``` donatas-pc# show bgp all detail-routes For address family: IPv4 Unicast BGP table version is 11, local router ID is 192.168.10.17, vrf id 0 Default local pref 100, local AS 65002 BGP routing table entry for 10.0.2.0/24, version 1 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.10.124 65001 192.168.10.124 from 192.168.10.124 (200.200.200.202) Origin incomplete, metric 0, valid, external, otc 65001, best (First path received) Last update: Tue Dec 20 12:11:52 2022 BGP routing table entry for 10.10.100.0/24, version 2 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.10.124 65001 192.168.10.124 from 192.168.10.124 (200.200.200.202) Origin IGP, metric 0, valid, external, otc 65001, best (First path received) Last update: Tue Dec 20 12:11:52 2022 BGP routing table entry for 172.16.31.1/32, version 3 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.10.124 65001 192.168.10.124 from 192.168.10.124 (200.200.200.202) Origin incomplete, metric 0, valid, external, otc 65001, best (First path received) Last update: Tue Dec 20 12:11:52 2022 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
sworleys
pushed a commit
that referenced
this pull request
Feb 9, 2023
``` unet> sh pe2 vtysh -c 'sh ip bgp ipv4 vpn detail-routes' BGP table version is 4, local router ID is 10.10.10.20, vrf id 0 Default local pref 100, local AS 65001 Route Distinguisher: 192.168.2.2:2 BGP routing table entry for 192.168.2.2:2:10.0.0.0/24, version 1 not allocated Paths: (1 available, best #1) Not advertised to any peer 65000 192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received) Extended Community: RT:192.168.2.2:2 Originator: 10.10.10.20 Remote label: 2222 Last update: Tue Dec 20 13:01:20 2022 BGP routing table entry for 192.168.2.2:2:172.16.255.1/32, version 2 not allocated Paths: (1 available, best #1) Not advertised to any peer 65000 192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self Origin incomplete, localpref 50, valid, sourced, local, best (First path received) Extended Community: RT:192.168.2.2:2 Originator: 10.10.10.20 Remote label: 2222 Last update: Tue Dec 20 13:01:20 2022 BGP routing table entry for 192.168.2.2:2:192.168.1.0/24, version 3 not allocated Paths: (1 available, best #1) Not advertised to any peer 65000 192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self Origin incomplete, localpref 50, valid, sourced, local, best (First path received) Extended Community: RT:192.168.2.2:2 Originator: 10.10.10.20 Remote label: 2222 Last update: Tue Dec 20 13:01:20 2022 BGP routing table entry for 192.168.2.2:2:192.168.2.0/24, version 4 not allocated Paths: (1 available, best #1) Not advertised to any peer 65000 192.168.2.1 from 0.0.0.0 (10.10.10.20) vrf RED(4) announce-nh-self Origin incomplete, metric 0, localpref 50, valid, sourced, local, best (First path received) Extended Community: RT:192.168.2.2:2 Originator: 10.10.10.20 Remote label: 2222 Last update: Tue Dec 20 13:01:20 2022 Displayed 4 routes and 4 total paths ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
sworleys
pushed a commit
that referenced
this pull request
Feb 9, 2023
Fix crash on "show bgp all" when BGP EVPN is set. > #0 raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fdfe03cf53c in core_handler (signo=11, siginfo=0x7ffdebbffe30, context=0x7ffdebbffd00) at lib/sigevent.c:261 > #2 <signal handler called> > FRRouting#3 0x00000000004d4fec in bgp_attr_get_community (attr=0x41) at bgpd/bgp_attr.h:553 > FRRouting#4 0x00000000004eee84 in bgp_show_table (vty=0x1a790d0, bgp=0x19d0a00, safi=SAFI_EVPN, table=0x19f6010, type=bgp_show_type_normal, output_arg=0x0, rd=0x0, is_last=1, output_cum=0x0, > total_cum=0x0, json_header_depth=0x7ffdebc00bf8, show_flags=4, rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11329 > FRRouting#5 0x00000000004f7765 in bgp_show (vty=0x1a790d0, bgp=0x19d0a00, afi=AFI_L2VPN, safi=SAFI_EVPN, type=bgp_show_type_normal, output_arg=0x0, show_flags=4, > rpki_target_state=RPKI_NOT_BEING_USED) at bgpd/bgp_route.c:11814 > FRRouting#6 0x00000000004fb53b in show_ip_bgp_magic (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050, viewvrfname=0x0, all=0x1395390 "all", aa_nn=0x0, community_list=0, > community_list_str=0x0, community_list_name=0x0, as_path_filter_name=0x0, prefix_list=0x0, accesslist_name=0x0, rmap_name=0x0, version=0, version_str=0x0, alias_name=0x0, > orr_group_name=0x0, detail_routes=0x0, uj=0x0, detail_json=0x0, wide=0x0) at bgpd/bgp_route.c:13040 > FRRouting#7 0x00000000004fa322 in show_ip_bgp (self=0x6752b0 <show_ip_bgp_cmd>, vty=0x1a790d0, argc=3, argv=0x19cb050) at ./bgpd/bgp_route_clippy.c:519 > FRRouting#8 0x00007fdfe033ccc8 in cmd_execute_command_real (vline=0x19c9300, filter=FILTER_RELAXED, vty=0x1a790d0, cmd=0x0, up_level=0) at lib/command.c:996 > FRRouting#9 0x00007fdfe033c739 in cmd_execute_command (vline=0x19c9300, vty=0x1a790d0, cmd=0x0, vtysh=0) at lib/command.c:1056 > FRRouting#10 0x00007fdfe033cdf5 in cmd_execute (vty=0x1a790d0, cmd=0x19c9eb0 "show bgp all", matched=0x0, vtysh=0) at lib/command.c:1223 > FRRouting#11 0x00007fdfe03f65c6 in vty_command (vty=0x1a790d0, buf=0x19c9eb0 "show bgp all") at lib/vty.c:486 > FRRouting#12 0x00007fdfe03f603b in vty_execute (vty=0x1a790d0) at lib/vty.c:1249 > FRRouting#13 0x00007fdfe03f533b in vtysh_read (thread=0x7ffdebc03838) at lib/vty.c:2148 > FRRouting#14 0x00007fdfe03e815d in thread_call (thread=0x7ffdebc03838) at lib/thread.c:2006 > FRRouting#15 0x00007fdfe0379b54 in frr_run (master=0x1246880) at lib/libfrr.c:1198 > FRRouting#16 0x000000000042b2a8 in main (argc=7, argv=0x7ffdebc03af8) at bgpd/bgp_main.c:520 Link: FRRouting#12576 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🐔