On the subject of ebgp-multihop, we just installed a simplex satellite
link from an upstream provider. We are running ebgp-multihop on the
link. From our router, it will take at most 15 hops to reach the BGP peer,
since we have no other connection to them. Would this affect
performance? Are there any other possible ways to do this? Is there
anyone on the list using the same kind of setup?
Im thinking of static routes but acccdg to our upstream, they discourage
this kind of solution as a matter of policy(duh).
=>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
=>>
=>
-- Cheers,Paul P. Pongco Mosaic Communications Inc.
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:19 EDT