Multihop eBGP peering or VPN based eBGP peering

Mon Jun 17 13:25:45 UTC 2013

-----Original Message-----
From: Patrick W. Gilmore [mailto:patrick at ianai.net] 
Sent: Monday, June 17, 2013 1:37 AM
To: NANOG list
Subject: Re: Multihop eBGP peering or VPN based eBGP peering

On Jun 17, 2013, at 00:36 , "Otis L. Surratt, Jr." <otis at ocosa.com>
wrote:

>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.]

I know eBGP is not iBGP. And yes, it was two separate ASNs. The point
was in my experience, providers will prefer direction connection (you
can physically plug into switch port or router port) to establish an
eBGP session with you versus a GRE Tunnel. And some do not allow it.

>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").

" You see you can have routers all over but if your data center (CDN) is

without power you are done."

Patrick, I was saying "done" in terms of being over, no more, not
happening. :) 
But that was if you had all of the necessary network measures accounted
for and content served via the east coast data center only. 
But I did forget to clarify (not CDN, or single served content).

I was assuming the OP had the proper relationships network wise
(transit/private/public peering) so it would work when you put it all
together properly. 
I also, took into account the OP is a CDN so they probably have content
distributed at a minimum in separate regions anyway so it wouldn't
matter if the east coast DC is offline as the content is still reachable
via the west coast data center which would null and void the OPs
example. Like I explained, I was thinking the OP had the proper
relationships to re-direct traffic to the west coast at that point
that's why I said "I do see this advantage being an obvious workable
logical one." I didn't say it was perfect but workable (work was still
needed to complete it).