Messages in this thread | | | Date | Wed, 18 May 2022 08:36:26 -0600 | Subject | Re: [PATCH net-next] net: PIM register decapsulation and Forwarding. | From | David Ahern <> |
| |
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.
| |