All things related to multicast

[Zenon Mousmoulas <>]

On 11 Ιουν 2010, at 3:57 ΜΜ, Havard Eidnes wrote:

> > We (GRNET) have a downstream network (let's call them U) who  
> > receive a
> > partial routing table from us. U runs BGP and MSDP peerings on a
> > single border router (RP in their PIM domain) with two distinct GRNET
> > routers (anycast RPs in the GRNET domain, running full-mesh IBGP and
> > MSDP). The BGP peerings are setup in a primary/backup scheme (using
> > communities, local pref etc). BGP peerings carry both unicast and
> > multicast NLRIs, but we use separate sessions for IPv4 and IPv6.
> > Pretty standard stuff.
> >
> > Since U receive only a partial routing table, they rely on the
> > "default network" mechanism for internet routing. This gateway of  
> > last
> > resort is configured once and, AFAIK, can't be set separately per
> > NLRI. Since IOS (12.2SXF in their case) performs RPF lookups across
> > both the MRIB and the unicast RIB, it seems to work out fine: "show  
> > ip
> > rpf" points to the default network when no prefix matches the source,
> > with a "unicast" RPF type. However MSDP peer-RPF check fails: SA
> > announcements are rejected when no prefix matches the RP/Originator,
> > so the default network doesn't apply in this case, or so it seems.
> >
> > MSDP debug also logs messages like this:
> >
> > Jun  7 18:15:33: MSDP(0): <grnet-msdp-peer>: Peer RPF check failed  
> > for
> > w.x.y.z, used IBGP route's peer 0.0.0.0
> >
> > which don't make much sense.
> >
> > Judging from the above, it looks like we effectively can not
> > MSDP peer with a downstream network without announcing to them
> > (the equivalent of) FIRT in MBGP. Of course this is not a big
> > issue while the number of prefixes is low, however there are
> > still practical reasons against this, namely avoiding
> > incongruent routing.
>
> I've never seen problems like this, even with a reduced routing table.
> I'm not sure I have all the details to make a judgement as to what in
> section 10.1.3 of http://tools.ietf.org/html/rfc3618 fails in your
> case.

As I wrote earlier, I have a feeling the problem is related to the  
fact a lookup for the originator will not match a particular MBGP or  
BGP prefix. It will match the default route, which points to a network  
that is learnt via BGP, and the next-hop for that network is indeed  
the MSDP peer. However such an indirect match probably will not happen  
if the lookup is restricted to the (M)BGP RIB.

Looking at the implementation-specific Cisco rules[1], this peer-RPF  
check could therefore fail rule #7 under the "original" rule-set:

 •If the MBGP route for the RP is not found, the router looks up the  
BGP route for the RP. If neither the MBGP route nor the BGP route for  
the RP is found, the RPF check fails.


While under the new, "compliant" rule-set, it is noted that the "RPF- 
RIB" is included in lookups for the peer-RPF check: "The RPF-RIB  
represents the paths that are used for Protocol Independent Multicast  
(PIM) sparse mode (PIM-SM) RPF forwarding on the router." Since "show  
ip rpf" already shows it can resolve a lookup through such an indirect  
match, I believe the "RPF-RIB" could make a difference in this case.

I'm not sure how these translate in terms of RFC 3618, section 10.1.3  
rules, but (ii), (iii) and (iv) all seem relevant and should match in  
this case.

> One thing you could try to do is to configure the MSDP sessions
> between loopback interfaces at both ends of the session -- that's what
> we do.  I've opened my mouth about this here before, and come to a
> step I could not adequatly explain, so just let this serve as a hint
> without any attempts at further explanation from me in this round.

Well we're running EBGP peerings on the connected interfaces and MSDP  
follows the BGP setup. Personally I never quite saw the point in the  
argument about using loopbacks instead, not to mention it is of course  
preferable to keep the two together, from an administrative pov.  
Nonetheless I'd have no problem suggesting to try this out, but I just  
don't see how it could make any difference in this particular case.

Thanks,
Z.

[1] 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_msdp.html#wp1045913