[163757] in North American Network Operators' Group
Re: Multihop eBGP peering or VPN based eBGP peering
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Mon Jun 17 02:37:19 2013
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0186F4@ocsbs.ocosa.com>
Date: Mon, 17 Jun 2013 02:36:42 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 17, 2013, at 00:36 , "Otis L. Surratt, Jr." <otis@ocosa.com> =
wrote:
>> Any idea why more companies don't offer eBGP peering / multi hop
>> peering? Its very common for providers to offer single or double hop
>> peering, so why not 5 or 10 hops? In many cases people find it =
logical
>> to perform single or double hop peering, why is >peering any greater
>> always frowned upon. I understand the logic that you can't control =
the
>> path beyond a point, however I still see numerous advantages.
>=20
> The norm has always been if you are peering with someone you have =
router
> in the location you are peering. Thus, direct connection!!!=20
> But I've seen folks do what you are describing but in terms of their =
own
> networks thru use of GRE Tunnels. The main point of peering is having
> better connectivity and dropping traffic directly or closest to its
> destination.
First, inside your own network is not eBGP. iBGP has no hop limitation =
(well, 255). If you have you seen someone do eBGP "inside their own =
network", they were actually doing it between two separate networks they =
owned.
If you saw someone do eBGP over a GRE tunnel, that is a direct =
connection, not multi-hop. [Cue discussion from last week about multiple =
islands in the same ASN.]
>> One obvious advantages one is, imagine you east coast data centre and
>> you had a eBGP peering session with a west coast router, you'd be =
able
>> to control ingress via the west coast. (aka routing around an region
>> outage that is effecting ingress) For >example during the last =
hurricane
>> around New Jersey, numerous tier 1's were down towards the atlantic =
and
>> every peer for the atlantic was effected. One could have just made =
the
>> ingress via the west coast the logical route.=20
>=20
> I do see this advantage being an obvious workable logical one. =
However,
> large providers typically have their own network (layers 1-3) coast to
> coast if were talking USA. But in the case of the hurricane situation
> many were without power so you can have a router west coast and =
announce
> from that router but how will you get traffic back to east coast if
> that's your data center?=20
>=20
> You see you can have routers all over but if your data center (CDN) is
> without power you are done.
I do not see an advantage here.
You are on the east coast and you want to re-direct traffic to the west =
coast, so you announce a prefix to a west coast router and ask it to =
propagate that prefix to its peers. How do you guarantee that router has =
a route back to the east coast for that prefix?
Remember, a prefix announcement is a promise to deliver traffic to that =
prefix. You are suggesting asking a router to make a promise when that =
router has no guarantee of reachability. In your hurricane example, =
perhaps the west coast router reaches that prefix through one of the =
down east coast routers? Now you have blackholed that prefix when a =
router in, say, Chicago or Dallas would have announced it properly and =
had reachability.
If you want to control where a prefix ingresses another network, first =
you need a transit relationship with that network. Most modern transit =
networks have community-based signaling, allowing you to do what you =
suggest and more (e.g. "prepend to peer $X" or "do not announce to peer =
$Y").
--=20
TTFN,
patrick
