[c-nsp] BGP multihop between two sites

[John.Herbert at ins.com]

Ah I think I see. Assuming you have no default route learned via eBGP then (given 3 full routing tables, that's probably a fair assumption), the question becomes whether you can intelligently maintain a floating static default based on reachability to the next-hop IP, or if it's better to implement some kind of BGP peering between the two sites.

One possibility might be to consider a conditional static default route - use "ip sla" to test next hop reachability of a provider's router, then use the track command to monitor and apply to a floating default route (and of course, you can do this for more than one provider and provide a predetermined sequence of alternate default routes)

I am not personally a fan of iBGP "raw" over a public network (and that's what it would be since the ASNs are the same on both ends), as most of the protection features in IOS are focused on eBGP. GRE tunnel works, though there may be caveats depending on MTU/fragmentation issues and hardware switching support. Maintaining those BGP peers of course assumes that the remote IP in each case is known in one of the active eBGP sessions at all time. Probably a reasonable assumption if you're using provider-owned IPs to peer; maybe less so if you're using IPs that fall within your own larger block.

I may be misunderstanding something about your particular topology, so my apologies if so.

John.

________________________________
From: Randy McAnally [rsm at fast-serv.com]
Sent: Wednesday, September 02, 2009 21:10
To: Herbert, John; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] BGP multihop between two sites

> I'm not quite clear on the floating default? What is it floating "over"? If you are receiving a default in BGP,
> then are you / can you receive it from multiple providers for resiliency? And if so, under what circumstances
>  is the floating static ever active in your routing tables?

It's a high distance static default route in place, to keep packets flowing in case of an eBGP malfunction.  In this case, it was routing packets between locations because the prefixes were not in the routing tables.  This was not discovered until the provider the default pointed went down.

--
Randy <http://www.fastserv.com/>