RCA: We are ignoring (*,G) prune when the RP in packet is not RP(G)
Fix:
According to RFC 4601 Section 4.5.2:
Received Prune(*,G) messages are processed even if the RP in the message does not match RP(G).
We have allowed starg prune to be processed in the scenario.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: Client1------LHR-----(int-1)RP(int-2)------client2
Client2 send IGMP join for group G.
Client1 send IGMP join for group G.
verify show ip mroute in RP, will have 2 OIL.
Client2 send IGMP leave.
Verify show ip mroute in RP, will still have 2.
Root cause: When RP receives IGMP join from client2, it creates
a (s,g) channel oil and add the interface int-2 into oil list and
set the flag PIM_OIF_FLAG_PROTO_IGMP to int-2
Client1 send IGMP join, LHR will send a (*,G) join to RP. RP will
add the interface int-1 into the oil list of (s,g) channel_oil and
will set the flag PIM_OIF_FLAG_PROTO_IGMP and PIM_OIF_FLAG_PROTO_PIM
to the int-1 and set PIM_OIF_FLAG_PROTO_PIM to int-2 as well. It is
happening because of the pim_upstream_inherited_olist_decide() and
forward_on() get all the oil and update the flag wrongly.
So now when client 2 sends IGMP prune, RP will not remove the int-2
from oil list since both PIM_OIF_FLAG_PROTO_PIM & PIM_OIF_FLAG_PROTO_IGMP
are set, it just unset the flag PIM_OIF_FLAG_PROTO_IGMP.
Fix: Introduced new flags in if_channel, PIM_IF_FLAG_MASK_PROTO_PIM
& PIM_IF_FLAG_MASK_PROTO_IGMP. If a if_channel is created because of
pim join or pim (s,g,rpt) prune received, then set the flag
PIM_IF_FLAG_MASK_PROTO_PIM. If a if_channel is created becuase of IGMP
join received, then set the flag PIM_IF_FLAG_MASK_PROTO_IGMP.
When an interface needs to be added into the oil list check if
PIM_IF_FLAG_MASK_PROTO_PIM or PIM_IF_FLAG_MASK_PROTO_IGMP is set, then
update oil flag accordingly.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue 1: "show ip pim interface traffic" not show prune TX/RX
Rootcause : not added the variable in the json
Fix : add prune TX/RX in show ip pim interface traffic json
Issue 2: "show ip pim rp-info" not shows the key iAmRp when it is false
Rootcause: Only display the key when the value is true.
Fix: add iAmRp as false in show ip pim rp-info json
Issue 3: "show ip pim rp-info" not showing outbound interface if it is empty
Rootcause: Only display when there is any OIL
Fix: When RP is not reachable then, the outbound interface is Unknown
The command "show ip pim rp-info json" not displaying the outbound
interafce if it is unknown
Signed-off-by: Sarita Patra <saritap@vmware.com>
S - Sparse Mode
C - indicates there is a member of the group directly connected to the router.
R -set on an (S, G) by the receipt of an (S, G) RP bit prune message.
F -This indicates that this router is a FHR and send register messages to RP to inform RP of this active source
P - OIL list is NULL. That means the router will send a prune.
T - At least one packet received via SPT.
Signed-off-by: Sarita Patra <saritap@vmware.com>
RCA: When configured more than 32(MAXVIS), the inerfaces that are configured
after 32nd interfaces have the value of MAXVIF.
This is used as index to access the free vif tracker of array size 32(MAXVIFS).
So the channel oil list pointer which is present as the next field in pim structure get corrupt, when updating free vif.
This gets accessed during rpf update resulting in crash.
Fix: Refrain from allocating mcast interface structure and throw config error when more than MAXVIFS are attempted to configure.
Max vif checks are exempted for vrf device and pimreg as vrf device will be the first interface and not expected to fail and pimreg has reserved vif.
vxlan tunnel termination device creation has this check and throw warning on max vif.
All other creation are through CLI.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Problem: Route node is not de referenced after search when pim debug events are
not enabled when pim_rp_find_match_group is called. So this memory will not get
released when route node is deleted after hitting this path.
RCA: Dereferencing is done inside debug condition.
Fix: Moving outside debug condition
Signed-off-by: Saravanan K <saravanank@vmware.com>
Root cause: The header display is put in common outside the vtysh/json if-else.
Fix: Brought inside vtysh condition.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: when (*,G) has some receiver and directly connected source sends traffic,
new (S,G) entry created is not inheriting the oil from (*,g)
RCA: pim_mroute_msg_nocache haven't assume FHR have (*,g) member ports
Fix : Added inherit oil from parent from (*,g) receivers to get added
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: When any interface is getting added/deleted in the outgoing
interface list, it calls pim_mroute_add() which is updating the
mroute_creation time without checking if the mroute is already
installed in the kernel.
Fix: Check if mroute is already installed, then dont refresh the
mroute_creation timer.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue: show ip mroute displays the mroute uptime (time when
mroute installed into the kernel) per oif.
This is confusing.
Fix: Display mroute uptime per (s,g) mroute entry.
Signed-off-by: Sarita Patra <saritap@vmware.com>
There exists a chain of events where calling pim_mlag_up_peer_deref
can free the up pointer. Prevent a use after free by returning
the up pointer as needed and checking to make sure we are
ok.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On shutdown processing we may have gotten a interface down event
which might clear the rpf interface and we might trigger a
work queue item on the vxlan_sg to send a NULL register.
Ensure that we cannot attempt to do the impossible.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
VRF deletion events here calling hash_clean() with
nothing to clean up the vxlan_sg's associated with it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pim receives a register packet, we will apply the
received source to the prefix list. If accepted normal
processing continues. If denied we will send a register
stop message to the source.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We already use the pim pointer a bunch off of pim_ifp->pim
just add another pim variable to allow us to shorten code
a bit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The memory type PIM_SPT_PLIST_NAME is specific to
SPT but we are going to store more prefix-list names
in pim, make it generic to allow for less confusion
in the future.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the (S,G) KAT expires we need to poll for activity before dropping the
entry as traffic may have been forwarded by the dataplane since the last
periodic poll cycle.
This only works if traffic is being forwarded by the kernel i.e. if the
entries were HW accelerated via an ASIC we may still miss out on last
minute activity on the mroute in the HW.
Ticket: CM-26871
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
An mroute can transition from non-origination to a vxlan origination
mroute. In that case we need to re-evaluate if the interfaces in the
OIL need to be muted; pimreg and termination device need to be muted (if
they were previously un-muted).
Dump in a problem state:
=======================
root@TORC11:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 * 239.1.1.100 y uplink-1 pimreg(I ), ipmr-lo( J )
1 36.0.0.11 239.1.1.100 n peerlink-3.4094 ipmr-lo( * ), uplink-1( J ), uplink-2( J ), peerlink-3.4094( V )
PS: ipmr-lo should have M set in (36.0.0.11,239.1.1.100)
Ticket: CM-26747
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Add a special catch to the test for pim_macro_chisin_pim_include
to allow the LHR to signal interest in joining upstream.
This will allow both the DR and non DR of the ActiveActive
situation to draw traffic to itself.
The non-DR will continue to not forward traffic.
Ticket: CM-26610
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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
Ticket: CM-26732
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Additional protocols were being set on the OIF proto-mask without
logs. Added logs in that area.
Also added start and end logs to ifchannel_delete to help
identify state machine changes that play out as a part of this
event handling.
Ticket: CM-26732
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This patch does two things:
1) Ensure the decoding of stream data between pim <-> zebra is properly
decoded and we don't read beyond the end of the stream.
2) In zebra when we are freeing memory alloced ensure that we
actually have memory to delete before we do so.
Ticket: CM-27055
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
(S,G) entries that inherit ipmr-lo into the OIL also inherit
the DF role from the parent (*, G) entry.
This change is done primarily to simplify the sync process and
to prevent the MLAG peers from having to track (S, G) activity etc.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
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>
There was some code missed during the upstreaming process
due to code squash. Identify and put into a commit
to keep code consistent and correct.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
