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

[Jakub Kicinski <kuba@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!