Re: Multihop eBGP peering or VPN based eBGP peering

["Patrick W. Gilmore" <patrick () ianai net>]

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.
>
> The norm has always been if you are peering with someone you have router
> in the location you are peering. Thus, direct connection!!! 
> 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. 
>
> 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? 
>
> 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").

-- 
TTFN,
patrick