Donald Sharp [Mon, 19 Sep 2022 16:34:18 +0000 (12:34 -0400)]
isisd: Fix memory leak on shutdown with prefix lists
==2623619==
==2623619== 6 bytes in 1 blocks are definitely lost in loss record 3 of 75
==2623619== at 0x483877F: malloc (vg_replace_malloc.c:307)
==2623619== by 0x4B55E4A: strdup (strdup.c:42)
==2623619== by 0x493C992: qstrdup (memory.c:128)
==2623619== by 0x1A9212: isis_instance_fast_reroute_level_1_remote_lfa_prefix_list_modify (isis_nb_config.c:1599)
==2623619== by 0x494837C: nb_callback_modify (northbound.c:1083)
==2623619== by 0x4948C6E: nb_callback_configuration (northbound.c:1352)
==2623619== by 0x494919D: nb_transaction_process (northbound.c:1473)
==2623619== by 0x4947DA9: nb_candidate_commit_apply (northbound.c:906)
==2623619== by 0x4947EBA: nb_candidate_commit (northbound.c:938)
==2623619== by 0x494EB9E: nb_cli_classic_commit (northbound_cli.c:64)
==2623619== by 0x494F3DC: nb_cli_apply_changes_internal (northbound_cli.c:250)
==2623619== by 0x494F4E2: nb_cli_apply_changes (northbound_cli.c:268)
==2623619== by 0x1BEF0F: isis_frr_remote_lfa_plist_magic (isis_cli.c:1899)
==2623619== by 0x1B7636: isis_frr_remote_lfa_plist (isis_cli_clippy.c:3406)
==2623619== by 0x48EBA75: cmd_execute_command_real (command.c:997)
==2623619== by 0x48EBD4E: cmd_execute_command_strict (command.c:1108)
==2623619== by 0x48EC1E6: command_config_read_one_line (command.c:1268)
==2623619== by 0x48EC35B: config_from_file (command.c:1313)
==2623619== by 0x4999CC1: vty_read_file (vty.c:2347)
==2623619== by 0x499A4AF: vty_read_config (vty.c:2567)
==2623619== by 0x4924B12: frr_config_read_in (libfrr.c:984)
==2623619== by 0x498F5E3: thread_call (thread.c:2008)
==2623619== by 0x49253DA: frr_run (libfrr.c:1198)
==2623619== by 0x14FC53: main (isis_main.c:273)
Abhishek N R [Mon, 29 Aug 2022 12:17:08 +0000 (05:17 -0700)]
pimd, pim6d: Changing IGMP to GM in few macro's.
Changing
IGMP_DEFAULT_ROBUSTNESS_VARIABLE to GM_DEFAULT_ROBUSTNESS_VARIABLE,
IGMP_GENERAL_QUERY_INTERVAL to GM_GENERAL_QUERY_INTERVAL,
IGMP_QUERY_MAX_RESPONSE_TIME_DSEC to GM_QUERY_MAX_RESPONSE_TIME_DSEC and
IGMP_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC to GM_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC
to accomodate both igmp and mld. And moved it to common file.
When R1 and R2 establish BGP session, R1 begins to send initial updates.
If R2 sends a route-refresh request before EoR, it's silently ignored
by R1, and routes received earlier have no chance to be processed again.
RFC7313 says, "for a BGP speaker that supports the BGP Graceful Restart,
it MUST NOT send a BoRR for an <AFI, SAFI> to a neighbor before it sends
the EoR for the <AFI, SAFI> to the neighbor." But it doesn't forbid
route-refresh request to be sent before receiving EoR.
To handle this scenario, postpone response to refresh request until EoR
is sent.
CID 1519843 (#2 of 2): Uninitialized scalar variable (UNINIT)
43. uninit_use_in_call: Using uninitialized value pkt_src->sin6_addr when calling gm_rx_process
Donald Sharp [Wed, 14 Sep 2022 17:48:31 +0000 (13:48 -0400)]
lib: Fix skip of every other plist deletion
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.
Abhishek N R [Wed, 14 Sep 2022 06:29:33 +0000 (23:29 -0700)]
pimd, pim6d: Changing IGMP to GM in debug macros.
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>
bgpd: Fix memory leak for `conf_copy()` - SoO ecommunity
==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)
==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)
bgpd: Fix memory leak for `set as-path replace` route-map command
==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)
Mark Stapp [Thu, 8 Sep 2022 20:14:36 +0000 (16:14 -0400)]
bgpd: avoid notify race between io and main pthreads
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.
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.
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.
Michal Ruprich [Tue, 6 Sep 2022 10:25:01 +0000 (12:25 +0200)]
ospfd: Adding SUPPORT_OSPF_API define in ospf_spf.c
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>
Sai Gomathi N [Thu, 1 Sep 2022 05:20:00 +0000 (22:20 -0700)]
pimd, pim6d: Changing IGMP to GM in debug macros
Changing
PIM_DO_DEBUG_IGMP_EVENTS to PIM_DO_DEBUG_GM_EVENTS
PIM_DO_DEBUG_IGMP_PACKETS to PIM_DO_DEBUG_GM_PACKETS
PIM_DO_DEBUG_IGMP_TRACE to PIM_DO_DEBUG_GM_TRACE
PIM_DO_DEBUG_IGMP_TRACE_DETAIL to PIM_DO_DEBUG_GM_TRACE_DETAIL
PIM_DONT_DEBUG_IGMP_EVENTS to PIM_DONT_DEBUG_GM_EVENTS
PIM_DONT_DEBUG_IGMP_PACKETS to PIM_DONT_DEBUG_GM_PACKETS
PIM_DONT_DEBUG_IGMP_TRACE to PIM_DONT_DEBUG_GM_TRACE
PIM_DONT_DEBUG_IGMP_TRACE_DETAIL to PIM_DONT_DEBUG_GM_TRACE_DETAIL
PIM_MASK_IGMP_EVENTS to PIM_MASK_GM_EVENTS
PIM_MASK_IGMP_PACKETS to PIM_MASK_GM_PACKETS
PIM_MASK_IGMP_TRACE to PIM_MASK_GM_TRACE
PIM_MASK_IGMP_TRACE_DETAIL to PIM_MASK_GM_TRACE_DETAIL
to be used for both IGMP and MLD debugs.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Philippe Guibert [Thu, 18 Aug 2022 15:22:33 +0000 (17:22 +0200)]
bgpd: associate appropriate family for redistributed connected addresses
When redistributing connected addresses, the address family has
to be figured out. The calculation was not done, the next-hop
address length was not set, and as consequence, the nexthop
is displayed like if it was an ipv6 address, which is wrong for
ipv4 addresses.
Calculate the family for connected addresses.
Change the topotests accordingly.
Fixes: ("7226bc40d606") bgpd: ignore NEXT_HOP for MP_REACH_NLRI Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
RFC4364 describes peerings between multiple AS domains, to ease
the continuity of VPN services across multiple SPs. This commit
implements a sub-set of IETF option b) described in chapter 10 b.
The ASBR to ASBR approach is taken, with an EBGP peering between
the two routers. The EBGP peering must be directly connected to
the outgoing interface used. In those conditions, the next hop
is directly connected, and there is no need to have a transport
label to convey the VPN label. A new vty command is added on a
per interface basis:
This command if enabled, will permit to convey BGP VPN labels
without any transport labels (i.e. with implicit-null label).
restriction:
this command is used only for EBGP directly connected peerings.
Other use cases are not covered.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 20 Sep 2021 14:05:40 +0000 (16:05 +0200)]
topotests: add bgp vpnv4 over gre test
This test ensures that MPLS VPN routes can be installed into a
gre interface with route-map l3vpn next-hop encapsulation command
set. On the other hand, if this command is not set, incoming bgp
routes are not considered as valid.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 20 Sep 2021 09:50:52 +0000 (11:50 +0200)]
bgpd: add resolution for l3vpn traffic over gre interfaces
When a route imported from l3vpn is analysed, the nexthop from default
VRF is looked up against a valid MPLS path. Generally, this is done on
backbones with a MPLS signalisation transport layer like LDP. Generally,
the BGP connection is multiple hops away. That scenario is already
working.
There is case where it is possible to run L3VPN over GRE interfaces, and
where there is no LSP path over that GRE interface: GRE is just here to
tunnel MPLS traffic. On that case, the nexthop given in the path does not
have MPLS path, but should be authorized to convey MPLS traffic provided
that the user permits it via a configuration command.
That commit introduces a new command that can be activated in route-map:
> set l3vpn next-hop encapsulation gre
That command authorizes the nexthop tracking engine to accept paths that
o have a GRE interface as output, independently of the presence of an LSP
path or not.
A configuration example is given below. When bgp incoming vpnv4 updates
are received, the nexthop of NLRI is 192.168.0.2. Based on nexthop
tracking service from zebra, BGP knows that the output interface to reach
192.168.0.2 is r1-gre0. Because that interface is not MPLS based, but is
a GRE tunnel, then the update will be using that nexthop to be installed.
pim6d: Update last_member_query_interval and last_member_query_count
When there is update in the configuration of last_member_query_interval
and last_member_query_count, call gm_ifp_update().
This will update cur_query_intv_trig and cur_lmqc of gm_ifp structure.
Donatas Abraitis [Tue, 30 Aug 2022 18:25:50 +0000 (21:25 +0300)]
bgpd: Add Origin Validation State extended community
```
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#
```
projects / mirror_frr.git / log