mcohort: RE: MSDP Architecture

["Mike O'Connor" <moc@es.net>]

> -----Original Message-----
> From: Greg Shepherd [mailto:shep@juniper.net] 
> Sent: Friday, October 11, 2002 10:56 AM
> To: Mike O'Connor
> Cc: mcohort@lists.uoregon.edu; Joe Burrescia
> Subject: Re: MSDP Architecture
> 
> 
> 
> 
> On Fri, 11 Oct 2002, Mike O'Connor wrote:
> 
> > Greg,
> >
> > I'd like to throw out an MSDP architecture issue to you and the 
> > mcohorts group. I'm running into problems with MSDP rule checking 
> > rejecting most of the SA's ESnet receives from it's peering with 
> > Abilene in Sunnyvale CA.
> >
> > The SA's are being rejected because the path to a particular SA may 
> > exit ESnet in New York rather than Sunnyvale. So the quick 
> and dirty 
> > solution
> 
> So you have safi.2 peering in NY AND Sunnyvale but only MSDP 
> in Sunnyvale?? This is not good. There are tricks to diverge 
> MSDP/MBGP peering inside your AS, but all external MSDP/MBGP 
> peering must be congruent.
> 
> Doing is right IS the quick solution. ;-)
> 
> Greg

We are trying to do it right. I do have an MSDP peering with Abilene in
NY, but the path out of Esnet for this particular German SA doesn't
route via Abilene. Given the current state of multicast support
wroldwide this alignment is no trivial task.

What are some of the tricks?

-Mike

> 
> > is to ignore the MSDP RPF rule checking and get the customer up and 
> > running. But then I have to concern myself with the consequences of 
> > ignoring the RPF rules, or solving world hunger by 
> attempting to align 
> > all of my MSDP peerings with BGP peerings and make sure all transit 
> > networks do the same.
> >
> > I mostly concerned with MSDP loops being created by 
> ignoring the RPF 
> > rules and there may be some evidence of this within the 
> last week. I 
> > had to turn on rule checking again and have not had the MSDP 
> > instability in our core return, it still exists on a few of 
> our peers 
> > though.
> >
> > One solution I've considered appears to turn the conventional MSDP 
> > architecture model inside out or upside down, which is 
> usually a fun 
> > thing to do as long as you don't hurt yourself.
> >
> > Core router mesh:
> > Currently the ESnet core routers are configured in an N^2 
> MSDP mesh, 
> > the peerings are type mesh-group so the SA's from other mesh group 
> > members are not forwarded to the rest of the group and MSDP 
> RFP rule 
> > checking is deactivated.
> >
> > MSDP peering:
> > Our MSDP peers are configured as standard, all SA's accepted from 
> > peers are forwarded to all peers and RPF rule checking is enforced.
> >
> > The quick and dirty solution to Abilene was to put this peering in 
> > it's own mesh group so the RPF rules could be bypassed.
> >
> > I've been thinking of converting our Core to MSDP standard, 
> to enforce 
> > rule checking between core routers and prevent loops through ESnet. 
> > I'd like to place the MSDP peers at each peering router in a local 
> > mesh-group in order to relax the MSDP rule checking to 
> them. Of course 
> > when we assume our peers are meshed, ESnet will no longer forward 
> > transit SA's between our peers but this is not our role anyway, we 
> > simply want to forward ESnet site SA's and receive SA's from each 
> > peer.
> >
> > By doing this we hope to gain more control over the routing 
> and rule 
> > checking, this could likely achieve larger MSDP SA acceptance 
> > resulting in fewer calls and happier customers.
> >
> > Comments and alternative approaches greatly appreciated.
> >
> > -Mike
> >
> > --
> > Mike O'Connor,                  E-mail: moc@es.net
> > Network Engineer                Energy Sciences Network (ESnet)
> > East coast: +1 631 344-7410     West coast: +1 510 486-7421
> > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> >
> >
> 



--
Mike O'Connor,                  E-mail: moc@es.net
Network Engineer                Energy Sciences Network (ESnet)
East coast: +1 631 344-7410     West coast: +1 510 486-7421
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)


-------------------------------------------------------------------
Archive:   http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort/
sub/unsub: http://darkwing.uoregon.edu/~llynch/mcastwks/mcohort.html