lkml.org 
[lkml]   [2022]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH net-next] net: PIM register decapsulation and Forwarding.
From
On 5/18/22 8:16 AM, Ido Schimmel wrote:
> On Wed, May 18, 2022 at 12:08:35PM +0300, Ido Schimmel wrote:
>> On Tue, May 17, 2022 at 05:10:26PM -0700, Jakub Kicinski wrote:
>>> On Mon, 16 May 2022 04:29:06 -0700 Saranya Panjarathina wrote:
>>>> PIM register packet is decapsulated but not forwarded in RP
>>>>
>>>> __pim_rcv decapsulates the PIM register packet and reinjects for forwarding
>>>> after replacing the skb->dev to reg_dev (vif with VIFF_Register)
>>>>
>>>> Ideally the incoming device should be same as skb->dev where the
>>>> original PIM register packet is received. mcache would not have
>>>> reg_vif as IIF. Decapsulated packet forwarding is failing
>>>> because of IIF mismatch. In RP for this S,G RPF interface would be
>>>> skb->dev vif only, so that would be IIF for the cache entry.
>>>>
>>>> Signed-off-by: Saranya Panjarathina <plsaranya@gmail.com>
>>>
>>> Not sure if this can cause any trouble. And why it had become
>>> a problem now, seems like the code has been this way forever.
>>> David? Ido?
>>
>> 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.

\
 
 \ /
  Last update: 2022-05-18 16:40    [W:0.061 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site