All things related to multicast

[Zenon Mousmoulas <>]

On 13 Ιουν 2010, at 10:11 ΜΜ, Zenon Mousmoulas wrote:

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

We tried this theory by enabling "ip msdp rpf-peer rfc3618" on a  
similar setup running IOS 15.0M. A default static route is installed  
instead of "ip default-network", since the latter no longer seems to  
work on this IOS.

Unfortunately MSDP still rejects SAs in this fashion, so the "RPF-RIB"  
either does not work as documented or it is not included at all in  
peer-RPF lookups. I have no idea if this could be considered a bug or  
a feature...

Z.