One /22 Two ISP no BGP

Sat Feb 7 21:23:19 UTC 2009

On Fri, 6 Feb 2009, Jason Biel wrote:

> As I mentioned earlier, you'll want to have one provider announce the /22
> unweighted and the other announce it weighted.  Just pick the better of the
> two providers as the primary.  Don't base it soley off bandwidth, but check
> your SLA and any recent outage occurances.
>
> Traffic will flow in via the primary until that link to you drops, the
> provider will remove the route, and traffic will come in the back up route.

This is unlikely to work, on a couple of levels.

Given the same prefix-length on both announcements, you're unlikely to 
have much luck keeping traffic off your back-up path as Jason suggests. 
This means you'll need to have ways to withdraw the routes through both 
providers if their respective links fail, rather than just being able to 
withdraw the routes from one.

I'm not sure what he means by doing a "weighted" announcement.  If he 
means using the Cisco "weight" attribute, it's local to the router where 
it's set and won't propagate upstream.  Your upstream providers could use 
that to control how traffic exits their networks, but not how traffic gets 
to them.

Indeed, given two routing announcements of the same route to two different 
upstream providers who connect to the rest of the Internet in different 
ways, the announcing network has very little control over which route will 
be followed.  Once an announcement is out there, routing decisions get 
made according to the policies of the networks sending traffic in the 
announcing network's direction, which are generally based more on customer 
relationships than on topological distance or anything that can be set on 
the announcing end.

The usual way to attempt to influence inbound traffic flow is with AS path 
prepending -- making one path into a network look artifically long so that 
the other will look comparitively short.  This partly works.  Those who 
don't have any other reason to prefer one path over the other will prefer 
the shortest one.  But it's not going to shift 100 percent of inbound 
traffic.  The upstream provider, and their upstream providers, and anybody 
upstream from them, will probably all be using the BGP local-preference 
attribute to prefer paths they get paid for over paths they don't, and 
local-preference trumps AS path length no matter how many prepends are 
put into a path.

As others here have suggested, you could have the provider that won't do 
BGP with you tie their own BGP announcement to your interface, such that 
if the interface facing you goes down the route will go away.  Or you 
could have them use Cisco's conditional routing feature to only announce 
your route if they stop seeing your route being announced through your 
other provider.  The problem with both of these approaches is that they 
depend on some BGP routing flexibility on the part of your upstream 
provider, and if your upstream provider were flexible in terms of how they 
handle BGP for customers we wouldn't be having this discussion.

If you did want to follow Jason's suggestion of having primary/backup 
providers, such that inbound routing decisions are made based on whether 
the primary one is up, the tool you've probably got available is to 
announce more and less specific routes.   Barring filters in your 
upstream providers' networks, a more specific route will always be chosen 
over a less specific one.  So, if you've got a /22, you could have your 
non-BGP-speaking provider announce it as a /22 on your backup link, and 
announce it yourself as two /23s on your BGP-aware primary link.  That 
should more or less work, at the cost of having two more routes in the 
global routing table and getting you some dirty looks from peers who will 
consider it irresponsible.

That said, if you've got the resources, I think tunneling over the 
uncooperative provider to somebody who will do BGP with you on the 
mainland is probably a better answer.

-Steve