Re: [PATCH net-next] net: PIM register decapsulation and Forwarding.

From: Jakub Kicinski <kuba@kernel.org>
To: David Ahern <dsahern@kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>,
	Saranya Panjarathina <plsaranya@gmail.com>,
	netdev@vger.kernel.org, Saranya_Panjarathina@dell.com,
	davem@davemloft.net, yoshfuji@linux-ipv6.org,
	edumazet@google.com, pabeni@redhat.com,
	linux-kernel@vger.kernel.org, g_balaji1@dell.com,
	Nikolay Aleksandrov <razor@blackwall.org>
Subject: Re: [PATCH net-next] net: PIM register decapsulation and Forwarding.
Date: Wed, 18 May 2022 09:18:30 -0700	[thread overview]
Message-ID: <20220518091830.2db448f2@kernel.org> (raw)
In-Reply-To: <6f18ea96-0ba6-23ba-9d74-ebe76b42c828@kernel.org>

On Wed, 18 May 2022 08:36:26 -0600 David Ahern wrote:
> >> Trying to understand the problem:
> >>
> >> 1. The RP has an (*, G) towards the receiver(s) (receiver joins first)
> >> 2. The RP receives a PIM Register packet encapsulating the packet from
> >> the source
> >> 3. The kernel decapsulates the packet and injects it into the Rx path as
> >> if the packet was received by the pimreg netdev
> >> 4. The kernel forwards the packet according to the (*, G) route (no RPF
> >> check)
> >>
> >> At the same time, the PIM Register packet should be received by whatever
> >> routing daemon is running in user space via a raw socket for the PIM
> >> protocol. My understanding is that it should cause the RP to send a PIM
> >> Join towards the FHR, causing the FHR to send two copies of each packet
> >> from the source: encapsulated in the PIM Register packet and over the
> >> (S, G) Tree.
> >>
> >> If the RP already has an (S, G) route with IIF of skb->dev and the
> >> decapsulated packet is injected into the Rx path via skb->dev, then what
> >> prevents the RP from forwarding the same packet twice towards the
> >> receiver(s)?
> >>
> >> I'm not a PIM expert so the above might be nonsense. Anyway, I will
> >> check with someone from the FRR teams who understands PIM better than
> >> me.  
> > 
> > We discussed this patch in FRR slack with the author and PIM experts.
> > The tl;dr is that the patch is working around what we currently believe
> > is an FRR bug, which the author will try to fix.
> > 
> > After receiving a PIM Register message on the RP, FRR installs an (S, G)
> > route with IIF being the interface via which the packet was received
> > (skb->dev). FRR also sends a PIM Join towards the FHR and eventually a
> > PIM Register Stop.
> > 
> > The current behavior means that due to RPF assertion, all the
> > encapsulated traffic from the source is dropped on the RP after FRR
> > installs the (S, G) route.
> > 
> > The patch is problematic because during the time the FHR sends both
> > encapsulated and native traffic towards the RP, the RP will forward both
> > copies towards the receiver(s).
> > 
> > Instead, the suggestion is for FRR to install the initial (S, G) route
> > with IIF being the pimreg device. This should allow decapsulated traffic
> > to be forwarded correctly. Native traffic will trigger RPF assertion and
> > thereby prompt FRR to: a) Replace the IIF from pimreg to the one via
> > which traffic is received b) Send a PIM Register Stop towards the FHR,
> > instructing it to stop sending encapsulated traffic.
> >   
> 
> Thanks for diving into the problem and for the detailed response.

+1, thanks Ido!