All things related to multicast

[Zenon Mousmoulas <>]

Not exactly: The default route points to the network 194.177.208.0/22,  
so the IP next hop for w.x.y.z is the BGP next hop for  
194.177.208.0/22, which is an MSDP peer as well.

However there is an interesting twist: When we send U (the equivalent  
of) FIRT in MBGP from both peerings, so that MSDP does not reject  
"internet" SAs, we've noticed that "show ip msdp summary" on their  
border router shows SAs "bouncing" from one peer to the other, e.g:

Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
<grnet-primary>  5408  Up       1w1d     0     627   <grnet-primary>
<grnet-second>    5408  Up       1w1d     0     933   <grnet-second>

Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
<grnet-primary>  5408  Up       1w1d     0     900   <grnet-primary>
<grnet-second>    5408  Up       1w1d     0     654   <grnet-second>


The only explanation we've managed to give so far is that SA  
announcements from both peers are accepted, effectively overriding the  
previous sa-cache table entries as they come in. If, however, a bgp  
next-hop peer-RPF check rule was to prevail, then I believe that SA  
announcements only from the primary peer should be accepted while the  
primary BGP peering is up, so we should not be seeing this "bouncing"  
effect.

On 11 Ιουν 2010, at 4:18 ΜΜ, Tyrone Kelly wrote:

> Is the network that the "ip default-network" command point to, Is it  
> not the bgp-next hop for the w.x.y.z nlri?
>
> -----Original Message-----
> From: Zenon Mousmoulas 
> [mailto:]
> Sent: Friday, June 11, 2010 2:24 AM
> To: 
>
> Cc: wg-multicast
> Subject: Re: inter-domain MSDP peering without BGP FIRT
>
> On 10 Ιουν 2010, at 9:32 ΜΜ, Bill Owens wrote:
>
> > On Thu, Jun 10, 2010 at 08:57:10PM +0300, Zenon Mousmoulas wrote:
> > > 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.
> >
> > How is the default route created - static, or supplied by the eBGP
> > peer? I just tried a quick experiment with an internal router that
> > has a static default:
>
> Quite similar to "ip route 0.0.0.0", the default route is installed
> with "ip default-network" (gateway of last resort) pointing to a
> network which is known by eBGP (announced from GRNET).
>
> > c7609#sh config | incl 0.0.0.0
> > ip route 0.0.0.0 0.0.0.0 199.109.35.1
> > c7609#conf t
> > Enter configuration commands, one per line.  End with CNTL/Z.
> > c7609(config)#ip mroute 0.0.0.0 0.0.0.0 199.109.35.1
> > c7609(config)#end
> > c7609#sh ip rpf 2.3.4.5
> > RPF information for ? (2.3.4.5)
> > RPF interface: GigabitEthernet1/1
> > RPF neighbor: nn-3550-ext.nysernet.net (199.109.35.1)
> > RPF route/mask: 0.0.0.0/0
> > RPF type: static
> > RPF recursion count: 0
> > Doing distance-preferred lookups across tables
>
> RPF information for ? (2.3.4.5)
>   RPF interface: <GRNET uplink>
>   RPF neighbor: w.x.y.z
>   RPF route/mask: 194.177.208.0/22
>   RPF type: unicast (bgp <U AS>)
>   RPF recursion count: 0
>   Doing distance-preferred lookups across tables
>
> > c7609#conf t
> > Enter configuration commands, one per line.  End with CNTL/Z.
> > c7609(config)#no ip mroute 0.0.0.0 0.0.0.0 199.109.35.1
> > c7609(config)#end
> > c7609#sh ip rpf 2.3.4.5
> > RPF information for ? (2.3.4.5) failed, no route exists
> >
> > Seems to indicate that the static mroute works. It would be
> > incorrect in this case, since the unicast default route points to
> > our commercial ISP connection, and the R&E side is native BGP/mBGP.
>
> So the difference is you have a static default route pointing to the
> IP next-hop, while they are pointing it to a network learnt via BGP
> from GRNET. However "ip default-network" does not have a multicast
> counterpart; perhaps they could use "ip route" and "ip mroute"  
> instead.
>
> However, the question is: does MSDP work for you in this case? Would
> it accept an SA where the originator would match this default route in
> an RPF lookup?
>
> Thanks,
> Z.