Re: [nsp] Q: EBGP Multihop

From: shinoclist (shinoclist@cyberway.com.sg)
Date: Thu Oct 19 2000 - 03:39:27 EDT


sorry for my igorance, what is this TTL thing?

thks,
Victor

----- Original Message -----
From: Daniel L. Golding <dan@netrail.net>
To: Josh Richards <jrichard@cubicle.net>
Cc: <cisco-nsp@puck.nether.net>
Sent: Thursday, October 19, 2000 10:18 AM
Subject: Re: [nsp] Q: EBGP Multihop

> Hmm. I set routing policy for a provider, and we do not do eBGP multihop,
> except for testing purposes (e.g. if someone needs a full view in a test
> lab). Why?
>
> 1) It is not necessary
>
> 2) It makes troubleshooting more difficult
>
> 3) If the customer doesn't understand the behavior, it can result in
> causing one provider's traffic to transit another's network, which is
> extrememly suboptimal. Yes, if they set TTL right, you're ok, but most
> folks have barely enough of a clue to set up BGP in the first place.
>
> 4) It is a "custom" setup, and most ISP's setup BGP customers through
> either a strictly defined procedure or an automated process (IRRd + PERL).
> Custom work required manhours from senior engineers, which is bad for the
> bottom line.
>
> 5) Customer reachability to the BGP peer requires a properly functioning
> IGP on the customer side for next hop reachability. ISPs loath to
> involve themselves in customer IGP issues.
>
> We mostly use it for testing, providing BGP views to router manufacturers,
> and for peering with route servers.
>
> - Dan Golding
>
> On Wed, 18 Oct 2000, Josh Richards wrote:
>
> > * SHI NOC List <shinoclist@cyberway.com.sg> [20001018 07:43]:
> > >
> > > I'd like to have some light in terms of EBGP multihop kind of
configuration.
> > >
> > > I know some provider doesn't run EBGP multihop with customer while the
> > > technology itself is in the market quite sometime.
> >
> > I don't know I'd exactly call it a technology, more like a feature of
the
> > protocol that is useful in some situations.
> >
> > > So is there any concern or reason that those provider are not willing
to
> > > run EBGP multihop?
> >
> > Because it doesn't apply to the application/situation? :-)
> >
> > Really...I mean there are uses for it where it may be legitimate to
configure
> > multihop (example: load balancing over 'n' T1 links to a provider so you
> > peer with their loopback address) but if there isn't a specific
situational
> > requirement than there is no reason to do it. And if there is a
specific
> > situational requirement -- you'll know it -- because there will be no
other
> > way to accomplish whatever you're trying to accomplish.
> >
> > To more directly answer your question: From the perspective of reasons
why
> > a service provider would have a strict policy against it:
> > - it may not be necessary for their environment/situation (i.e. they
never
> > connect to customers in ways that would require it)
> > - they've had some bad experience with it in the past (i.e. they
didn't
> > set the TTL parameter and had interesting consequences)
> > - they don't really have a reason -- they just don't do it because
they've
> > heard it's bad or something.
> >
> > If the ttl parameter (e.g. "ebgp-multihop 2") is not set you can get
strange
> > behavior (consider that there could very well be a path to your neighbor
> > via one of your other neighbors...). But if you have an application in
mind,
> > know why you are doing it, and set the ttl as low as possible there is
> > little reason to have some organization-wide policy saying "we don't do
> > ebgp-multihop *ever*". I'd expect that if there are service providers
who
> > have told you they won't do ebgp-multihop they either felt it was not
> > necessary for the situation at hand and there was another way to do it,
or
> > they just said it out of habit.
> >
> > -jr
> >
> > ----
> > Josh Richards [JTR38/JR539-ARIN]
> > <jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
> > Geek Research LLC - <URL:http://www.geekresearch.com/>
> > IP Network Engineering and Consulting
> >
>



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:19 EDT