-----Original Message----- From: Patrick W. Gilmore [mailto:patrick@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@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).