Re: [nsp] Q: EBGP Multihop

From: Daniel L. Golding (dan@netrail.net)
Date: Wed Oct 18 2000 - 22:18:56 EDT


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