One /22 Two ISP no BGP
scg at gibbard.org
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
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.
More information about the NANOG