Zhiyuan Wan [Mon, 3 Apr 2023 08:21:15 +0000 (16:21 +0800)]
ospfd: Support show intra-area network type in 'show ip ospf route' command
User can now use 'show ip ospf route detail' command to distinguish
intra-area stub network and transit network.
Transit network will be displayed as 'N T prefix ...'.
NOTICE: Json output format has been changed, intra-area transit networks
will have a new attribute 'transit' and value is 'true'.
And 'adv' (means advertise router) change to 'advertisedRouter'.
Example output:
bsp-debianrt-exp1# show ip ospf route detail
Codes: N - network T - transitive
IA - inter-area E - external route
D - destination R - router
============ OSPF network routing table ============
N T 10.0.0.0/24 [32] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
N 10.0.30.0/24 [33] area: 0.0.0.0
via 192.168.124.67, ens192
adv 10.0.0.5
...
Christian Hopps [Sat, 15 Jul 2023 04:04:05 +0000 (00:04 -0400)]
tests: backtraces/cores now fail tests
Previously we just raised an error for the test file with possibly all tests
passing. Now we fail any test that produces new backtraces or cores. This
just works a lot better with analysis and even CI.
Also be less verbose to the console after failure runs, just show error
level and above logs. The log files still capture all levels (DEBUG).
Christian Hopps [Fri, 14 Jul 2023 22:21:55 +0000 (18:21 -0400)]
vtysh: track and fix file-lock use in the workaround from 2004
There's a workaround in the code from a bug from back in 2004, it ends
and re-enters config mode anytime an `exit` is done from a level below
the top-level config node (e.g., from a `router isis` node). We need to
re-enter config mode with or without a lock according to how we actually
entered it to begin with.
Christian Hopps [Fri, 14 Jul 2023 20:13:54 +0000 (16:13 -0400)]
lib: mgmtd: only clear pending for the in-progress command
The lock/unlocks are being done short-circuit so they are never pending;
however, the handling of the unlock notification was always resuming the command
if pending was set. In all cases pending is set for another command. For example
implicit commit locks then when notified its done unlocks which was clearing the
set-config pending flag and resuming that command incorrectly.
Donald Sharp [Fri, 14 Jul 2023 16:14:20 +0000 (12:14 -0400)]
bgpd: Prevent use after free
When running bgp_always_compare_med, I am frequently seeing a crash
After running with valgrind I am seeing this and a invalid write
immediately after this as well.
==311743== Invalid read of size 2
==311743== at 0x4992421: route_map_counter_decrement (routemap.c:3308)
==311743== by 0x35664D: peer_route_map_unset (bgpd.c:7259)
==311743== by 0x306546: peer_route_map_unset_vty (bgp_vty.c:8037)
==311743== by 0x3066AC: no_neighbor_route_map (bgp_vty.c:8081)
==311743== by 0x49078DE: cmd_execute_command_real (command.c:990)
==311743== by 0x4907A63: cmd_execute_command (command.c:1050)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
==311743== by 0x1F7655: main (bgp_main.c:505)
==311743== Address 0x9ec2180 is 64 bytes inside a block of size 120 free'd
==311743== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==311743== by 0x495A1BA: qfree (memory.c:130)
==311743== by 0x498D412: route_map_free_map (routemap.c:748)
==311743== by 0x498D176: route_map_add (routemap.c:672)
==311743== by 0x498D79B: route_map_get (routemap.c:857)
==311743== by 0x499C256: lib_route_map_create (routemap_northbound.c:102)
==311743== by 0x49702D8: nb_callback_create (northbound.c:1234)
==311743== by 0x497107F: nb_callback_configuration (northbound.c:1578)
==311743== by 0x4971693: nb_transaction_process (northbound.c:1709)
==311743== by 0x496FCF4: nb_candidate_commit_apply (northbound.c:1103)
==311743== by 0x496FE4E: nb_candidate_commit (northbound.c:1136)
==311743== by 0x497798F: nb_cli_classic_commit (northbound_cli.c:49)
==311743== by 0x4977B4F: nb_cli_pending_commit_check (northbound_cli.c:88)
==311743== by 0x49078C1: cmd_execute_command_real (command.c:987)
==311743== by 0x4907B44: cmd_execute_command (command.c:1068)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
==311743== by 0x1F7655: main (bgp_main.c:505)
==311743== Block was alloc'd at
==311743== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==311743== by 0x495A068: qcalloc (memory.c:105)
==311743== by 0x498D0C8: route_map_new (routemap.c:646)
==311743== by 0x498D128: route_map_add (routemap.c:658)
==311743== by 0x498D79B: route_map_get (routemap.c:857)
==311743== by 0x499C256: lib_route_map_create (routemap_northbound.c:102)
==311743== by 0x49702D8: nb_callback_create (northbound.c:1234)
==311743== by 0x497107F: nb_callback_configuration (northbound.c:1578)
==311743== by 0x4971693: nb_transaction_process (northbound.c:1709)
==311743== by 0x496FCF4: nb_candidate_commit_apply (northbound.c:1103)
==311743== by 0x496FE4E: nb_candidate_commit (northbound.c:1136)
==311743== by 0x497798F: nb_cli_classic_commit (northbound_cli.c:49)
==311743== by 0x4977B4F: nb_cli_pending_commit_check (northbound_cli.c:88)
==311743== by 0x49078C1: cmd_execute_command_real (command.c:987)
==311743== by 0x4907B44: cmd_execute_command (command.c:1068)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
Effectively the route_map that is being stored has been freed already
but we have not cleaned up properly yet. Go through and clean the
code up by ensuring that the pointer actually exists instead of trusting
it does when doing the decrement operation.
lib: fix on-match when added to existing route-map entry
Currently, "on-match (next|goto)" only works if already present in a
route-map entry when the route-map is applied to the routes. However, if
the command is added to an existing route-map entry, the route-map is
not reapplied to the routes in order to accommodate the changes. And
service restart is needed. The problem is that setting the command
doesn't signal about the change to the listener (i.e. to a routing
daemon).
With this fix, signal to the listener about addition of "on-match
(next|goto)" to a route-map entry.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
anlan_cs [Mon, 22 May 2023 10:32:23 +0000 (18:32 +0800)]
zebra: Fix wrong vrf change procedure
Currently the vrf change procedure for the deleted interface is after
its deletion, it causes problem for upper daemons.
Here is the problem of `bgp`:
After deletion of one **irrelevant** interface in the same vrf, its
`ifindex` is set to 0. And then, the vrf change procedure will send
"ZEBRA_INTERFACE_DOWN" to `bgpd`.
Normally, `bgp_nht_ifp_table_handle()` should igore this message for
no correlation. However, it wrongly matched `ifindex` of 0, and removed
the related routes for the down `bnc`.
Adjust the location of the vrf change procedure to fix this issue.
Donald Sharp [Wed, 5 Jul 2023 13:28:50 +0000 (09:28 -0400)]
ospf6d: Convert ospf6_lsa_unlock to a better api
Make the ospf6_lsa_unlock take the same parameters
that the ospf_lsa_unlock does to make it consistent
and to also ensure that no-one can make the mistake
of getting the pointer cleared up.
Mark Stapp [Wed, 28 Jun 2023 19:33:57 +0000 (15:33 -0400)]
tests: add route-install test using NHRP tunnel
Add a test-case to the NHRP test that installs routes over the
NHRP tunnel endpoint routes. This confirms that zebra will use
NHRP routes when validating incoming routes from other daemons
(sharpd in this test).
Mark Stapp [Wed, 28 Jun 2023 12:11:41 +0000 (08:11 -0400)]
zebra: use NHRP routes as valid in nexthop check
Treat NHRP-installed routes as valid, as if they were
CONNECTED routes, when checking candidate routes'
nexthops for validity. This allows use of NHRP by an
IGP, for example, that doesn't normally want recursive
nexthop resolution.
Donald Sharp [Mon, 10 Jul 2023 14:40:38 +0000 (10:40 -0400)]
bgpd: Fix table manager to use the synchronous client
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
Donald Sharp [Mon, 10 Jul 2023 14:40:38 +0000 (10:40 -0400)]
bgpd: Fix table manager to use the synchronous client
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
David Schweizer [Mon, 10 Jul 2023 13:46:05 +0000 (15:46 +0200)]
tests: fix BGP delayopen timer expiration test
The changes allow the test to correctly pass in case the connection
between two peers is be established in less than 0.5 seconds after the
delayopen timer expires.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
Donald Sharp [Mon, 3 Jul 2023 20:12:16 +0000 (16:12 -0400)]
tests: bgp_flowspec expand timings
Attempt to set the hold time in the bgp flowspec exabgp
config. In addition it was noticed that upstream bgp_flowspec
tests are still not negotiating peering within the time frame
specified. This is because the first tcp packet is missed
and no keepalive/hold time are negotiated and exabgp will
not attempt a reconnect for quite some time. Make this
test slower when things go south.
Donald Sharp [Sat, 1 Jul 2023 17:30:12 +0000 (13:30 -0400)]
tests: isis_tilfa_topo1 fails sometimes due to insufficient time
The isis_tilfa_topo1 test is failing because insufficient time was
given for isis to converge on the system under system load. Extend
the time and decrease the hello-interval timers to give it more
of a chance to converge.
Donald Sharp [Sat, 1 Jul 2023 17:27:52 +0000 (13:27 -0400)]
tests: zebra_rib route-map run times fixup
I have a local test run where the sharp route-map usage
was being checked for 5 seconds. I saw usages going up
for each 1 second check and the 5th one was at 497 out
of 500. Looks like the system was really loaded. Let's
give it more time to coalesce under heavy load.
Donald Sharp [Thu, 29 Jun 2023 19:12:57 +0000 (15:12 -0400)]
tests: Look for zlog_backtrace in ci system
There are parts of our daemons that upon certain types
of errors that a zlog_backtrace is auto-generated.
It is desirable for this to be caught and have the
test auto-failed.
Issue: #13787 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgpd: Get 1 or 2 octets for Sub-TLV length (Tunnel Encap attr)
The total number of octets of the Sub-TLV Value field. The Sub-TLV Length field
contains 1 octet if the Sub-TLV Type field contains a value in the range from
0-127. The Sub-TLV Length field contains two octets if the Sub-TLV Type field
contains a value in the range from 128-255.
Chirag Shah [Sat, 8 Jul 2023 20:17:12 +0000 (13:17 -0700)]
tools: fix ospf area stub summary in frr-reload
OSPFv2 no area x stub no-summary only resets
'no-summary' config. From frr-reload if the config
line 'area x stub no-summary' is removed then
it needs to remove completely. Before this change
it took two frr-roload to remove the config which is
inconsistent behavior.
Fix is to frr-reload to add extra line to delete
'no area x stub'.
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub no-summary
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub no-summary
exit
changed frr.conf:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Lines To Delete
===============
router ospf
no area 0.0.0.1 stub <<<< newly added
router ospf vrf sym_1
no area 0.0.1.2 stub <<<< newly added
router ospf
no area 0.0.0.1 stub no-summary
router ospf vrf sym_1
no area 0.0.1.2 stub no-summary
After fix new running-config post reload:
i
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Before fix running-config post 1st reload:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub
exit
Chirag Shah [Sat, 8 Jul 2023 01:19:54 +0000 (18:19 -0700)]
bgpd: fix evpn zclient_send_message return code
In scaled EVPN route sync from bgp to zebra, return
code can be ZCLIENT_SEND_BUFFERED which was treated
as error and leads to route install/uninstall failure.
Following error logs were seen:
2023-07-07T17:05:59.640899+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC 33554471] 0: Failed to uninstall EVPN IMET route in VNI 478
2023-07-07T17:05:59.640913+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC 33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 465 IP table
2023-07-07T17:05:59.640927+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC 33554471] 0: Failed to uninstall EVPN IMET route in VNI 465
2023-07-07T17:05:59.640940+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC 33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 173 IP table
Once source VTEP withdraws, DUT VTEP still has stale entries
root@vtep12:mgmt:~# bridge -d -s fdb show | grep 27.0.0.5 | wc -l
12990
After fix:
Once source VTEP withdraws, DUT VTEP still is able to delete entries
root@vtep12:mgmt:/home/cumulus# bridge -d -s fdb show | grep 27.0.0.5 |
wc -l
0
Zapi stats:
Client: bgp
[32/133]
------------------------
FD: 76
Connect Time: 00:26:17
Nexthop Registry Time: 00:26:11
Nexthop Last Update Time: 00:23:31
Client will Not be notified about it's routes status
Last Msg Rx Time: 00:21:33
Last Msg Tx Time: 00:23:31
Last Rcvd Cmd: ZEBRA_REMOTE_MACIP_ADD
Last Sent Cmd: ZEBRA_NEXTHOP_UPDATE
zebra: Fix crash when `dplane_fpm_nl` fails to process received routes
When `dplane_fpm_nl` receives a route, it allocates memory for a dplane
context and calls `netlink_route_change_read_unicast_internal` without
initializing the `intf_extra_list` contained in the dplane context. If
`netlink_route_change_read_unicast_internal` is not able to process the
route, we call `dplane_ctx_fini` to free the dplane context. This causes
a crash because `dplane_ctx_fini` attempts to access the intf_extra_list
which is not initialized.
To solve this issue, we can call `dplane_ctx_route_init`to initialize
the dplane route context properly, just after the dplane context
allocation.
(gdb) bt
#0 0x0000555dd5ceae80 in dplane_intf_extra_list_pop (h=0x7fae1c007e68) at ../zebra/zebra_dplane.c:427
#1 dplane_ctx_free_internal (ctx=0x7fae1c0074b0) at ../zebra/zebra_dplane.c:724
#2 0x0000555dd5cebc99 in dplane_ctx_free (pctx=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:869
#3 dplane_ctx_free (pctx=0x7fae2aa88c98, pctx@entry=0x7fae2aa78c28) at ../zebra/zebra_dplane.c:855
#4 dplane_ctx_fini (pctx=pctx@entry=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:890
#5 0x00007fae31e93f29 in fpm_read (t=) at ../zebra/dplane_fpm_nl.c:605
#6 0x00007fae325191dd in thread_call (thread=thread@entry=0x7fae2aa98da0) at ../lib/thread.c:2006
#7 0x00007fae324c42b8 in fpt_run (arg=0x555dd74777c0) at ../lib/frr_pthread.c:309
#8 0x00007fae32405ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007fae32325a2f in clone () from /lib/x86_64-linux-gnu/libc.so.6
zebra: Abstract `dplane_ctx_route_init` to init route without copying
The function `dplane_ctx_route_init` initializes a dplane route context
from the route object passed as an argument. Let's abstract this
function to allow initializing the dplane route context without actually
copying a route object.
This allows us to use this function for initializing a dplane route
context when we don't have any route to copy in it.
In the function ospf_lsa_translated_nssa_new the newly created lsa is lock however, the return lsa from ospf_lsa_new already has a lock. Therefore removing the addition lock resolve the leak below.
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
bgpd: Show neighbors software version if description is not set
Also, this is visible only if `capability software-version` is enabled.
Example:
```
r1# show ip bgp summary
IPv4 Unicast Summary (VRF default):
BGP router identifier 192.168.1.1, local AS number 65001 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 725 KiB of memory
projects / matthieu / frr.git / log