Olivier Dugeon [Thu, 7 Dec 2023 13:53:16 +0000 (14:53 +0100)]
ospfd: Correct SID check size
Segment Router Identifier (SID) could be an index (4 bytes) within a range
(SRGB or SRLB) or an MPLS label (3 bytes). Thus, before calling check_size
macro to verify SID TLVs size, it is mandatory to determine the SID type to
avoid wrong assert.
The NHG_DEL operation is done directly from ZAPI call, whereas
the NHG_ADD operation is done in the rib_nhg meta queue.
This may be problematic when ADD is followed by DEL. Imagine a
scenarion with two protocol NHIDs. <NH1> depends of <NH2> and
<NH3>. The deletion of <NH3> at the protocol level will trigger
2 messages to ZEBRA: NHG_ADD(<NH1>) and NHG_DEL(<NH3>).
Those operations are properly enqueued in ZAPI, but in the end,
the NHG_DEL is executed first. This causes NHG_ADD to unlink an
already freed NHG.
Fix this by consistently enqueuing NHG_DEL and NHG_ADD operations.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Mon, 6 Nov 2023 18:02:01 +0000 (13:02 -0500)]
bgpd: Ensure BGP does not stop monitoring nexthops
In some cases BGP can be monitoring the same prefix
in both the nexthop and import check tables. If this
is the case, when unregistering one bnc from one table
make sure we are not still registered in the other
Example of the problem:
r1(config-router)# address-family ipv4 uni
r1(config-router-af)# no network 192.168.100.41/32
r1(config-router-af)# exit
r1# show bgp import-check-table
Current BGP import check cache:
r1# show bgp nexthop
Current BGP nexthop cache:
192.168.100.41 valid [IGP metric 0], #paths 1, peer 192.168.100.41
if r1-eth0
Last update: Wed Dec 6 11:01:40 2023
BGP now believes it is only watching 192.168.100.41 in the nexthop
cache, but zebra doesn't have anything:
r1# show ip import-check
VRF default:
Resolve via default: on
r1# show ip nht
VRF default:
Resolve via default: on
So if anything happens to the route that is being matched for
192.168.100.41 bgp is no longer going to be notified about this.
The source of this problem is that zebra has dropped the two different
tables into 1 table, while bgp has 2 tables to track this. The solution
to this problem (other than the rewrite that is being done ) is to have
BGP have a bit of smarts about looking in both tables for the bnc and
if found in both don't send the delete of the prefix tracking to zebra.
Donald Sharp [Wed, 6 Dec 2023 13:33:31 +0000 (08:33 -0500)]
zebra: Add connected with noprefixroute
Add ability for the connected routes to know
if they are a prefix route or not.
sharpd@eva:/work/home/sharpd/frr1$ ip addr show dev dummy1
13: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether aa:93:ce:ce:3f:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.55.1/24 scope global noprefixroute dummy1
valid_lft forever preferred_lft forever
inet 192.168.56.1/24 scope global dummy1
valid_lft forever preferred_lft forever
inet6 fe80::a893:ceff:fece:3f62/64 scope link
valid_lft forever preferred_lft forever
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show int dummy1"
Interface dummy1 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 13 metric 0 mtu 1500 speed 0 txqlen 1000
flags: <UP,BROADCAST,RUNNING,NOARP>
Type: Ethernet
HWaddr: aa:93:ce:ce:3f:62
inet 192.168.55.1/24 noprefixroute
inet 192.168.56.1/24
inet6 fe80::a893:ceff:fece:3f62/64
Interface Type Other
Interface Slave Type None
protodown: off
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show ip route"
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:00:08
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr2 linkdown, 00:00:08
L>* 192.168.44.1/32 is directly connected, dummy2, 00:00:08
L>* 192.168.55.1/32 is directly connected, dummy1, 00:00:08
C>* 192.168.56.0/24 is directly connected, dummy1, 00:00:08
L>* 192.168.56.1/32 is directly connected, dummy1, 00:00:08
L>* 192.168.119.205/32 is directly connected, enp13s0, 00:00:08
sharpd@eva:/work/home/sharpd/frr1$ ip route show
default via 192.168.119.1 dev enp13s0 proto dhcp metric 100
169.254.0.0/16 dev virbr2 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.45.0/24 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
192.168.56.0/24 dev dummy1 proto kernel scope link src 192.168.56.1
192.168.119.0/24 dev enp13s0 proto kernel scope link src 192.168.119.205 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
sharpd@eva:/work/home/sharpd/frr1$ ip route show table 255
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
local 192.168.44.1 dev dummy2 proto kernel scope host src 192.168.44.1
broadcast 192.168.44.255 dev dummy2 proto kernel scope link src 192.168.44.1
local 192.168.45.1 dev virbr2 proto kernel scope host src 192.168.45.1
broadcast 192.168.45.255 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
local 192.168.55.1 dev dummy1 proto kernel scope host src 192.168.55.1
broadcast 192.168.55.255 dev dummy1 proto kernel scope link src 192.168.55.1
local 192.168.56.1 dev dummy1 proto kernel scope host src 192.168.56.1
broadcast 192.168.56.255 dev dummy1 proto kernel scope link src 192.168.56.1
local 192.168.119.205 dev enp13s0 proto kernel scope host src 192.168.119.205
broadcast 192.168.119.255 dev enp13s0 proto kernel scope link src 192.168.119.205
local 192.168.122.1 dev virbr0 proto kernel scope host src 192.168.122.1
broadcast 192.168.122.255 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Fixes: #14952 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Wed, 6 Dec 2023 13:24:01 +0000 (08:24 -0500)]
zebra: Add ability to note that a address is NOPREFIXROUTE
The linux kernel can send up a flag that tells us that the
connected address is not a PREFIXROUTE. Add the ability
to note this and pass it up from the data plane.
sharpd: fix deleting nhid when suppressing nexthop from nh group
When no nexthops are in a nexthop group, two successive events are
sent: NHG_DEL and NHG_ADD, but only the NHG_DEL one is necessary.
Fixes this by returning in the nhg_add() function.
Fixes: 82beaf6ae520 ("sharpd: fix deleting nhid when suppressing nexthop from nh group") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Chirag Shah [Tue, 5 Dec 2023 03:23:32 +0000 (19:23 -0800)]
bgpd: check bgp evpn instance presence in soo
(pi=pi@entry=0x55e86ec1a5a0, evp=evp@entry=0x7fff4edc2160)
at bgpd/bgp_evpn.c:3623
3623 bgpd/bgp_evpn.c: No such file or directory.
(gdb) info locals
bgp_evpn = 0x0
macvrf_soo = <optimized out>
ret = false
__func__ = <optimized out>
(pi=pi@entry=0x55e86ec1a5a0, evp=evp@entry=0x7fff4edc2160)
at bgpd/bgp_evpn.c:3623
(bgp=bgp@entry=0x55e86e9cd010, afi=afi@entry=AFI_L2VPN,
safi=safi@entry=SAFI_EVPN, p=p@entry=0x0,
pi=pi@entry=0x55e86ec1a5a0, import=import@entry=1,
in_vrf_rt=true,
in_vni_rt=true) at bgpd/bgp_evpn.c:4200
(import=1, pi=pi@entry=0x55e86ec1a5a0, p=p@entry=0x0,
safi=safi@entry=SAFI_EVPN, afi=afi@entry=AFI_L2VPN,
bgp=bgp@entry=0x55e86e9cd010) at bgpd/bgp_evpn.c:6266
afi=afi@entry=AFI_L2VPN, safi=safi@entry=SAFI_EVPN,
p=p@entry=0x7fff4edc2160, pi=pi@entry=0x55e86ec1a5a0)
at bgpd/bgp_evpn.c:6266
(peer=peer@entry=0x55e86ea35400, p=p@entry=0x7fff4edc2160,
addpath_id=addpath_id@entry=0, attr=attr@entry=0x7fff4edc4400,
afi=afi@entry=AFI_L2VPN, safi=<optimized out>,
safi@entry=SAFI_EVPN, type=9, sub_type=0, prd=0x7fff4edc2120,
label=0x7fff4edc211c, num_labels=1,
soft_reconfig=0, evpn=0x7fff4edc2130) at bgpd/bgp_route.c:4805
(peer=peer@entry=0x55e86ea35400, afi=afi@entry=AFI_L2VPN,
safi=safi@entry=SAFI_EVPN, attr=attr@entry=0x7fff4edc4400,
pfx=<optimized out>, psize=psize@entry=34,
addpath_id=0) at bgpd/bgp_evpn.c:4922
(peer=0x55e86ea35400, attr=0x7fff4edc4400, packet=<optimized out>,
withdraw=0) at bgpd/bgp_evpn.c:5997
(peer=peer@entry=0x55e86ea35400, attr=attr@entry=0x7fff4edc4400,
packet=packet@entry=0x7fff4edc43d0,
mp_withdraw=mp_withdraw@entry=0) at bgpd/bgp_packet.c:363
(peer=peer@entry=0x55e86ea35400, size=size@entry=161)
at bgpd/bgp_packet.c:2076
(thread=<optimized out>) at bgpd/bgp_packet.c:2931
Louis Scalbert [Thu, 30 Nov 2023 16:29:20 +0000 (17:29 +0100)]
staticd: fix changing to source auto in bfd monitor
When monitoring a static route with BFD multi-hop, the source IP can be
either configured or retrieved from NextHop-Tracking (NHT). After
removing a configured source, the source is supposed to be retrieved
from NHT but it remains to the previous value. This is problematic if
the user desires to fix the configuration of a incorrect source IP.
For example, theses two commands results in the incorrect state:
> ip route 10.0.0.0/24 10.1.0.1 bfd multi-hop source 10.2.2.2
> ip route 10.0.0.0/24 10.1.0.1 bfd multi-hop
When removing the source, BFD is unable to find the source from NHT via
bfd_nht_update() were called.
Force zebra to resend the information to BFD by unregistering and
registering again NHT. The (...)/frr-nexthops/nexthop northbound
apply_finish function will trigger a call to static_install_nexthop()
that does a call to static_zebra_nht_register(nh, true);
Renato Westphal [Thu, 23 Nov 2023 23:23:52 +0000 (20:23 -0300)]
ospfd: fix deferred shutdown handling
The ospfd cleanup code is relatively complicated given the need to
appropriately handle the "max-metric router-lsa on-shutdown (5-100)"
command. When that command is configured and an OSPF instance is
unconfigured, the removal of the instance should be deferred to allow
other routers sufficient time to find alternate paths before the
local Router-LSAs are flushed. When ospfd is killed, however, deferred
shutdown shouldn't take place and all instances should be cleared
immediately.
This commit fixes a problem where ospf_deferred_shutdown_finish()
was prematurely exiting the daemon when no instances were left,
inadvertently preventing ospf_terminate() from clearing the ospfd
global variables. Additionally, the commit includes code refactoring
to enhance readability and maintainability.
Renato Westphal [Thu, 23 Nov 2023 23:21:31 +0000 (20:21 -0300)]
ospfd: improve memory cleanup during shutdown
* On ospf_terminate(), proceed to clear the ospfd global variables even
when no OSPF instance is configured
* Remove double call to route_map_finish()
* Call ospf_opaque_term() to clear the opaque LSA infrastructure
* Clear the `OspfRI.area_info` and `om->ospf` global lists.
Philippe Guibert [Fri, 24 Nov 2023 15:38:31 +0000 (16:38 +0100)]
zebra: fix wrong nexthop id debug message
When allocating big protocol level identifiers, the number range is
big, and when pushing to netlink messages, the first nexthop group
is truncated, whereas the nexthop has been installed on the kernel.
> ubuntu2204(config)# nexthop-group A
> ubuntu2204(config-nh-group)# group 1
> ubuntu2204(config-nh-group)# group 2
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 1
> ubuntu2204(config-nh-group)# nexthop 192.0.2.130 loop1 enable-proto-nhg-control
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 2
> ubuntu2204(config-nh-group)# nexthop 192.0.2.131 loop1 enable-proto-nhg-control
> [..]
> 2023/11/24 16:47:40 ZEBRA: [VNMVB-91G3G] _netlink_nexthop_build_group: ID (179687500): group 17968/179687502
Igor Ryzhov [Tue, 14 Nov 2023 19:17:24 +0000 (20:17 +0100)]
mgmtd: validate candidate yang tree before creating a config diff
The candidate yang tree should be validated before `nb_config_diff` is
called. `nb_config_diff` ignores all prohibited operations and can
provide an empty change list because of this. For example, if a user
deletes a mandatory node from the candidate datastore and tries to make
a commit, they'll receive the "No changes found to be committed!" error,
because such a change is ignored by `nb_config_diff`. Instead, mgmtd
should tell the user that their candidate datastore is not valid and
can't be commited.
Donald Sharp [Tue, 14 Nov 2023 15:15:42 +0000 (10:15 -0500)]
zebra: Fix non-notification of better admin won
If there happens to be a entry in the zebra rib
that has a lower admin distance then a newly received
re, zebra would not notify the upper level protocol
about this happening. Imagine a case where there
is a connected route for say a /32 and bgp receives
a route from a peer that is the same route as the
connected. Since BGP has no network statement and
perceives the route as being `good` bgp will install
the route into zebra. Zebra will look at the new
bgp re and correctly identify that the re is not
something that it will use and do nothing. This
change notices this and sends up a BETTER_ADMIN_WON
route notification.
Keelan10 [Wed, 29 Nov 2023 11:49:58 +0000 (15:49 +0400)]
bgpd: Free Memory for SRv6 Functions and Locator Chunks
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks.
The list callback deletion functions have been set.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180
Direct leak of 544 byte(s) in 2 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591
#3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712
#4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758
#5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849
#6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299
#7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704
#8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164
#9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#10 0x7f8d1713f034 in event_call lib/event.c:1974
#11 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#12 0x55d5db99d19d in main bgpd/bgp_main.c:510
#13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135
#3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144
#4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#5 0x7f8d1713f034 in event_call lib/event.c:1974
#6 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#7 0x55d5db99d19d in main bgpd/bgp_main.c:510
#8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
Keelan10 [Wed, 29 Nov 2023 12:33:54 +0000 (16:33 +0400)]
zebra: Set Free Functions for Traffic Control Hash Tables
Configure hash table cleanup with specific free functions for `zrouter.filter_hash`, `zrouter.qdisc_hash`, and `zrouter.class_hash`.
This ensures proper memory cleanup, addressing memory leaks.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in tc_basic.test_tc_basic/r1.asan.zebra.15495
Direct leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c9e in tc_filter_alloc_intern zebra/zebra_tc.c:389
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c7c74 in zebra_tc_filter_add zebra/zebra_tc.c:409
#5 0x55645210755a in zread_tc_filter zebra/zapi_msg.c:3428
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c6e in tc_class_alloc_intern zebra/zebra_tc.c:239
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c784f in zebra_tc_class_add zebra/zebra_tc.c:293
#5 0x556452107ce5 in zread_tc_class zebra/zapi_msg.c:3315
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c3e in tc_qdisc_alloc_intern zebra/zebra_tc.c:128
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c753b in zebra_tc_qdisc_install zebra/zebra_tc.c:184
#5 0x556452108203 in zread_tc_qdisc zebra/zapi_msg.c:3286
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 228 byte(s) leaked in 3 allocation(s).
***********************************************************************************
```
Keelan10 [Wed, 29 Nov 2023 11:28:54 +0000 (15:28 +0400)]
bgpd: Free Memory for confed_peers in bgp_free
Release memory associated with `bgp->confed_peers` in the `bgp_free`
function to ensure proper cleanup. This fix prevents memory leaks related
to `confed_peers`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_confederation_astype.test_bgp_confederation_astype/r2.asan.bgpd.15045
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f5666787b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f56661867c7 in qrealloc lib/memory.c:112
#2 0x55a3b4736a40 in bgp_confederation_peers_add bgpd/bgpd.c:681
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7f5666720538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x7f5666186898 in qstrdup lib/memory.c:117
#2 0x55a3b4736adb in bgp_confederation_peers_add bgpd/bgpd.c:687
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
1. When an OSPF interface is deleted, remove the references in link-local
LSA. Delete the LSA from the LSDB so that the callback has accessibily
to the interface prior to deletion.
2. Fix a double free for the opaque function table data structure.
3. Assure that the opaque per-type information and opaque function table
structures are removed at the same time since they have back pointers
to one another.
4. Add a topotest variation for the link-local opaque LSA crash.
projects / mirror / frr.git / log