mcohort: RE: MSDP Architecture

[Greg Shepherd <shep@juniper.net>]

On Fri, 11 Oct 2002, Mike O'Connor wrote:

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

So where are you getting the prefix to the source in safi.2??

Greg

> 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