Before:
r1# conf
r1(config)# router isis <area-tag>
r1(config-router)# set-overload-bit
<cr>
r1(config-router)# end
After:
r1# conf
r1(config)# router isis <area-tag>
r1(config-router)# set-overload-bit
<cr>
on-startup Set overload bit on startup
r1(config-router)# set-overload-bit on-startup
(0-86400) Set overload time in seconds
r1(config-router)# set-overload-bit on-startup 300
r1(config-router)# end
Signed-off-by: Isabella de Leon <ideleon@microsoft.com>
When bulk deleting prefix lists on shutdown the code
was calling plist_delete, which removed the item
from the master->str list, and then popping the next
item on the list and just dropping it on the floor.
The pop is not needed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Changed PIM_DEBUG_IGMP_TRACE to PIM_DEBUG_GM_TRACE and
PIM_DEBUG_IGMP_TRACE_DETAIL to PIM_DEBUG_GM_TRACE_DETAIL.
Hence, these macros can be used for both v6 and v4.
Issue: #11895
Co-authored-by: Sai Gomathi N <nsaigomathi@vmware.com>
Signed-off-by: Abhishek N R <abnr@vmware.com>
==1179738== 48 (40 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 29
==1179738== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1179738== by 0x493C8D5: qcalloc (memory.c:116)
==1179738== by 0x208F0C: ecommunity_dup (bgp_ecommunity.c:267)
==1179738== by 0x2B300C: conf_copy (bgp_updgrp.c:170)
==1179738== by 0x2B35BF: peer2_updgrp_copy (bgp_updgrp.c:277)
==1179738== by 0x2B5189: update_group_find (bgp_updgrp.c:826)
==1179738== by 0x2B70D0: update_group_adjust_peer (bgp_updgrp.c:1769)
==1179738== by 0x23DB7D: update_group_adjust_peer_afs (bgp_updgrp.h:519)
==1179738== by 0x243B21: bgp_establish (bgp_fsm.c:2129)
==1179738== by 0x244B94: bgp_event_update (bgp_fsm.c:2597)
==1179738== by 0x26B0E6: bgp_process_packet (bgp_packet.c:2895)
==1179738== by 0x498F5FD: thread_call (thread.c:2008)
==1179738== by 0x49253DA: frr_run (libfrr.c:1198)
==1179738== by 0x1EEC38: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
==536197== 400 (160 direct, 240 indirect) bytes in 4 blocks are definitely lost in loss record 19 of 21
==536197== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==536197== by 0x491C753: qcalloc (memory.c:116)
==536197== by 0x303FA9: aspath_dup (bgp_aspath.c:698)
==536197== by 0x304B2A: aspath_replace_specific_asn (bgp_aspath.c:1219)
==536197== by 0x256840: bgp_peer_as_override (bgp_route.c:1781)
==536197== by 0x256840: subgroup_announce_check (bgp_route.c:2216)
==536197== by 0x258345: subgroup_process_announce_selected (bgp_route.c:2804)
==536197== by 0x27F2CA: group_announce_route_walkcb (bgp_updgrp_adv.c:199)
==536197== by 0x4905A51: hash_walk (hash.c:285)
==536197== by 0x27E8D1: update_group_af_walk (bgp_updgrp.c:1866)
==536197== by 0x2809D3: group_announce_route (bgp_updgrp_adv.c:1022)
==536197== by 0x257DC4: bgp_process_main_one (bgp_route.c:3189)
==536197== by 0x257DC4: bgp_process_main_one (bgp_route.c:2975)
==536197== by 0x2581F7: bgp_process_wq (bgp_route.c:3330)
==536197== by 0x4961787: work_queue_run (workqueue.c:285)
==536197== by 0x4957745: thread_call (thread.c:2008)
==536197== by 0x4910B77: frr_run (libfrr.c:1198)
==536197== by 0x1ED6AC: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
==1174993== 252 (120 direct, 132 indirect) bytes in 3 blocks are definitely lost in loss record 77 of 100
==1174993== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1174993== by 0x493C8D5: qcalloc (memory.c:116)
==1174993== by 0x378E38: aspath_dup (bgp_aspath.c:698)
==1174993== by 0x2A39E2: route_set_aspath_replace (bgp_routemap.c:2259)
==1174993== by 0x4965C71: route_map_apply_ext (routemap.c:2664)
==1174993== by 0x27BCC8: bgp_input_modifier (bgp_route.c:1657)
==1174993== by 0x281AB9: bgp_update (bgp_route.c:3992)
==1174993== by 0x286368: bgp_nlri_parse_ip (bgp_route.c:5890)
==1174993== by 0x264D20: bgp_nlri_parse (bgp_packet.c:347)
==1174993== by 0x2682FE: bgp_update_receive (bgp_packet.c:1921)
==1174993== by 0x26AA67: bgp_process_packet (bgp_packet.c:2822)
==1174993== by 0x498F5FD: thread_call (thread.c:2008)
==1174993== by 0x49253DA: frr_run (libfrr.c:1198)
==1174993== by 0x1EEC38: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The "bgp_notify_" apis in bgp_packet.c generate a notification
to a peer, usually during error handling. The io pthread wants
to send notifications in a couple of cases during early
received-packet validation - but the existing api interacts
with the peer struct itself, and that's not safe.
Add a new api for use by the io pthread, and adjust the main
notify api so that it can avoid touching the peer struct.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
To resolve link dependencies of unordered interfaces, the commit
`520ebf72b27c2462ce8b0dc5a1d4cb83956df69c` has separated assignment of
`zif->link_ifindex` and `zif->link` from `netlink_interface()` during startup.
The fixup stage of `zebra_if_update_all_links()` goes into the last of
`interface_lookup_netlink()`, it can't be executed in the case of error in
above `netlink_parse_info()`s.
`RTM_GETTUNNEL` is not supported in linux kernel until 5.18, so
`netlink_parse_info()` will throw error with the previous versions.
If two conditions are met, (it is a common case)
1. Interfaces are created before frr restart/start
2. Linux kernel version < 5.18
the link dependencies will not be done, then evpn feature will be broken.
IMO we should just ignore this error.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Before it worked only when configured initially via CLI. Later, when we
receive a new route, that should match a decent MED, we just skip it, because
MED mismatch is not recalculated.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When using namespace VRF backend, and frr.conf contains:
vrf test
netns /run/netns/test
exit-vrf
FRR fails to start:
line 11: Failure to communicate[13] to zebra, line: netns /run/netns/test
Fix this by returning CMD_WARNING rather than CMD_WARNING_CONFIG_FAILED
when the same netns path is configured.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Don't hold the rcu lock in the bgp keepalive pthread: it
blocks the rcu pthread and prevents log-file deletion.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
It is not possible to build ospf_spf.c file with --disable-ospfapi because
ospf_apiserver.c has SUPPORT_OSPF_API around all function definitions and
that results in an undefined reference to the ospf_apiserver_notify_reachable
function error while building.
Signed-off-by: Michal Ruprich <mruprich@redhat.com>
