pimd: fix problem with oif being re-added during ifchannel del
Series of events leading to the problem -
1. (S,G) has been pruned on the rp on downlink-1
2. a (*,G) join is rxed on downlink-1 without the source S. This
results in the (S,G,rpt) prune state being cleared on downlink-1.
As a part of the clear the ifchannel associated with downlink-1
is deleted.
3. The ifchannel_delete handling is expected to add downlink-1
as an inherited OIF to the channel OIL (which it does). However
it is also added in as an immediate OIF (accidentally) as the
ifchannel is still present (in the process of being deleted).
To avoid the problem defer pim_upstream_update_join_desired
evaluation until after the channel is deleted.
Relevant debug logs -
PIM: pim_ifchannel_delete: ifchannel entry (27.0.0.15,239.1.1.106)(downlink-1) del start
PIM: pim_channel_add_oif(pim_ifchannel_delete): (S,G)=(27.0.0.15,239.1.1.106): proto_mask=4 OIF=downlink-1 vif_index=7: DONE
PIM: pimd/pim_oil.c pim_channel_del_oif: no existing protocol mask 2(4) for requested OIF downlink-1 (vif_index=7, min_ttl=1) for channel (S,G)=(27.0.0.15,239.1.1.106)
PIM: pim_upstream_switch: PIM_UPSTREAM_(27.0.0.15,239.1.1.106): (S,G) old: NotJoined new: Joined
PIM: pim_channel_add_oif(pim_upstream_inherited_olist_decide): (S,G)=(27.0.0.15,239.1.1.106): proto_mask=2 OIF=downlink-1 vif_index=7 added to 0x6 >>>>>>>>>>>>>>>>>>
PIM: pim_upstream_del(pim_ifchannel_delete): Delete (27.0.0.15,239.1.1.106)[default] ref count: 2 , flags: 81 c_oil ref count 1 (Pre decrement)
PIM: pim_ifchannel_delete: ifchannel entry (27.0.0.15,239.1.1.106)(downlink-1) del end
Donald Sharp [Wed, 9 Oct 2019 17:50:42 +0000 (13:50 -0400)]
zebra: SO_PEERCRED is a getsockopt call
This code is effectively dead code. SO_PEERCRED is a getsockopt
call not *setsockopt* call. Additionally we are not doing
anything with the failed setsockopt call at all.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Satheesh Kumar K [Mon, 19 Aug 2019 09:06:00 +0000 (02:06 -0700)]
pimd: Use PIM EVPN MLAG Infra for syncing PIM MLAG Entries
Initially, MLAG Sync is happened at pim_ifchannel, this is mainly to
support even config mismatches(missing configuration of dual active).
But this causes more syncs for each entry.
and also it is not In-line with PIM EVPN. to avoid that moving to
pm_upstream based syncing.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Donald Sharp [Fri, 22 Nov 2019 21:16:26 +0000 (16:16 -0500)]
pimd: Skip nexthop lookup for register source in some cases
There exists the possibility that a RP exists as a anycast
pair for a lan segment. As such one side may receive
the register and properly handle the registration mechanics.
The one that does not receive the register packets will still
get S,G state and WRVIFWHOLE upcalls across the lan. In
this case notice that we have not received the Registration
packets and prevent nexthop lookups.
Ticket: CM-27466 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 20 Dec 2019 12:57:28 +0000 (07:57 -0500)]
pimd: There is nothing to do with a WRVIFWHOLE for iifp of pimreg
When the WRVIFWHOLE callback is made with a iifp of the pimreg
device we *know* that the packet is a PIM Register packet
( see net/ipv4/ipmr.c for kernel behavior ). As such
we know that we will shortly read the pim register packet
and handle it through those mechanics. There is nothing
to do here so we can move along.
Ticket: CM-27729 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Philippe Guibert [Wed, 19 Feb 2020 16:27:06 +0000 (17:27 +0100)]
zebra: when override flag is set, do not forget to update nht
this flag can be used when one routing daemon wants to force his route
to be injected prioritary with other routes, including selected routes.
for that, do not forget to update the new_selected pointer in the zebra
nexthop tracking algorithm.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
nhrpd: ignore zebra updates about our routes being deleted/added
nhrp listens for route entries to be deleted, in case some new routes
impact the current routes installed by nhrp. To prevent from
unconfiguring nhrp shortcut route, just prevent nhrp routes to be
processed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Sarita Patra [Tue, 3 Mar 2020 11:35:43 +0000 (03:35 -0800)]
pimd: fix crash seen while executing igmp related configuration
Issue 1:
1. Enable pim on an interface.
2. Configure query-interval or query max response time,
which results in pimd crash.
Root cause:
1. When pim is enabled on an interface, it creates a igmp socket
with querier_timer and other_querier time as NULL.
2. When query-interval/max_response_time is configured, it call the
function igmp_sock_query_reschedule() to reshedule the query. This
function check either of querier_timer or other_querier timer should
be running. Since in this case both are NULL, it results in crash.
Issue 2:
1. Enable pim on an interface.
2. Execute no ip igmp query-interval or query max response time,
which results in pimd crash.
Root cause:
1. When pim is enabled on an interface, it creates a pim interface
with querier_timer and other_querier time as NULL.
2. When no ip igmp query-interval/max_response_time is executed, it will
check either of querier_timer or other_querier timer should be running.
Since in this case both are NULL, it results in crash.
Fix:
When pim is enabled on an interface, it creates a igmp socket with
mtrace_only as true. So add a check if mtrace_only is true, then don't
reshedule the query.
Sarita Patra [Tue, 3 Mar 2020 11:31:22 +0000 (03:31 -0800)]
pimd: neighbor needed true in pim nexthop lookup
Issue:
Client---LHR---RP
1. Add kernel route for RP on LHR. Client send join
2. (*,G) will be get created in LHR and RP.
3. Kill the FRR on all the nodes
4. Start FRR only on LHR node
5. In LHR, (*, G) will be created with iif as unknown.
Root cause:
In the step 4, When LHR will receive igmp join, it will call
the function pim_ecmp_fib_lookup_if_vif_index which will look
for nexthop to RP with neighbor needed as false. So RPF lookup will
be true as the route is present in the kernel. It will create a
(*, G) channel_oil with incoming interface as the RPF interface
towards RP and install the (*,G) mroute in kernel.
Along with this (*,G) upstream gets craeted, which call the function
pim_rpf_update, which will look for the nexthop to RP with neighbor
needed as true. As the frr is not running in RP, no neighbor is present
on the nexthop interface. Due to which this will fail and will update
the channel_oil incoming interface as MAXVIFS(32).
Fix:
pim_ecmp_fib_lookup_if_vif_index() call the function pim_ecmp_nexthop_lookup
with neighbor_needed as true.
Mark Stapp [Mon, 2 Mar 2020 20:51:22 +0000 (15:51 -0500)]
zebra: allow multiple labels in LSP zapi message
The handlers for a couple of the main LSP-oriented zapi
messages explicitly limited themselves to a single out-label.
Allow multiple labels if the sender ... sends them.
So, we should trust directly connected routes the same way, assuming
the interface exists.
Old Behavior:
K 2.2.2.1/32 [0/0] is directly connected, unknown inactive, 00:00:39
New Behavior:
K>* 2.2.2.1/32 [0/0] is directly connected, test1, 00:00:03
As a bonus, this fixes the issues we were seeing with not removing
directly connected routes of certain interface types when
those interfaces go down/are deleted.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Donald Sharp [Mon, 24 Feb 2020 14:08:54 +0000 (09:08 -0500)]
bgpd: Cleanup indentation in bgp_route_refresh_receive
Some code in bgp_route_refresh_receive was spread across several
lines because of an end of line commit. Move comment to a place
to allow better formating.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
rbauduin [Mon, 17 Feb 2020 12:13:11 +0000 (13:13 +0100)]
doc: document attribute-unchanged directive
This directive was undocumented, but is the way to configure the
next-hop to be left unchanged for ipv6 setups (in ipv4, a route-map with
`set next-hop unchanged` works fine, but this is unavailable for ipv6) .
projects / mirror / frr.git / log