Message-ID: <20110218171225.GC1739639@jupiter.n2.diac24.net>
Date:	Fri, 18 Feb 2011 18:12:25 +0100
From:	David Lamparter <equinox@...c24.net>
To:	Dan Langlois <daniel.langlois@...mens.com>
Cc:	netdev@...r.kernel.org
Subject: Re: IGMPMSG_WRONGVIF only happens when true VIF is an OIF of correct
 IIF?

On Fri, Feb 18, 2011 at 04:46:56PM +0100, Dan Langlois wrote:
> Hi, I have a question about the IGMPMSG_WRONGVIF message.
> I have MRT_ASSERT enabled but do not receive notifications.
> However, if I enable MRT_PIM, I do get them.  I'm curious
> why MRT_ASSERT alone isn't sufficient.
> 
> This if-statement appears in ip_mr_forward() in net/ipv4/ipmr.c
> 
>        if (true_vifi >= 0 && net->ipv4.mroute_do_assert &&
>             /* pimsm uses asserts, when switching from RPT to SPT, 
>                so that we cannot check that packet arrived on an oif. 
>                It is bad, but otherwise we would need to move pretty
>                large chunk of pimd to kernel. Ough... --ANK
>              */      
>             (net->ipv4.mroute_do_pim ||
>              cache->mfc_un.res.ttls[true_vifi] < 255) && 
>             time_after(jiffies,
>                        cache->mfc_un.res.last_assert +
> MFC_ASSERT_THRESH)) {
>                 cache->mfc_un.res.last_assert = jiffies;
>                 ipmr_cache_report(net, skb, true_vifi,
> IGMPMSG_WRONGVIF);
>         }       
> 
> 
> By the time this statement is reached, it is known that the packet
> did not arrive on the expected incoming interface (IIF) and thus a
> "WRONGVIF" condition.  This if-statement decides whether a PIM-assert
> notification needs to be sent to the multicast routing daemon.
> 
> The part of this if-statement I'm questioning is:
>     (net->ipv4.mroute_do_pim ||
>      cache->mfc_un.res.ttls[true_vifi] < 255) &&
> 
> I read this as:
> "send WRONGVIF if PIM is enabled -OR-
> the packet arrived on an outgoing interface OIF of the correct IIF"
> 
> So this statement is always true when PIM is enabled.
> However, if only ASSERT is enabled, this statement is only true when
> a packet is reflected back on an OIF.
> 
> Why not always send the assert for any WRONGVIF condition regardless
> of the interface it came in on?  I mean, isn't that the point of
> enabling MRT_ASSERT in the first place?  If the assertions weren't
> wanted, just don't enable that feature, right?

The point of MRT_ASSERT is to aid in resolving duplication issues where
you end up with multiple mrouters thinking they're responsible for the
same subnet. This condition is indicated by more than 1 router on the
subnet having the subnet as OIF on the (*,G) or (S,G). Therefore, your
daemon receives the assertion if it is one of the forwarding mrouters,
which it will only be if it's an OIF.

If your daemon doesn't have the target subnet listed as oif, the
assumption is that a different mrouter has been elected to forward
packets for this G/S,G to this subnet. The kernel knows that your daemon
decided to not forward things to this subnet, so you are not involved in
duplicates, so you don't get an assert.

The "PIM or" is a kludge to make PIM work, as indicated by the comment
above the if. I'd have to refreshen my PIM knowledge to fully understand
it or explain it ;)

> In our system, multicast streams may get rerouted through a different
> VIF than what was first installed in the MFC cache.  I would very much
> like to get these WRONGVIF assertions in this case, which is NOT the
> case that a packet is seen on an OIF.
> 
> Of course I can simply enable MRT_PIM to get the messages, but in that
> case I don't understand the reason for having two separate toggles
> (MRT_ASSERT versus MRT_PIM).

I don't really understand you use case -- is this a case of another
router showing up on the subnet and directing traffic to it? If so, why
wasn't the first router directing traffic to it? Do you have a primary
multicast forwarder election system in place?


-David


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists