All things related to multicast

[Havard Eidnes <>]

> 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.

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.

Regards,

- Håvard