Jason Biel wrote:

Charles,

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.

Perhaps ebgp-multihop with this ISP's upstream provider might offer you an advantage combined with this approach. Probably worth a try.

On Fri, Feb 6, 2009 at 11:14 AM, Charles Regan <charles.regan@gmail.com>wrote:

...

I'll explain. We are a small ISP on a very remote Island. We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2.

They are the only two we can get bandwidth.

So we are stuck with ISP1 that doesn't support BGP.

On Fri, Feb 6, 2009 at 12:48 PM, Azinger, Marla <marla.azinger@frontiercorp.com> wrote:

...

im curiouse. you probably had a reason for wanting to do that. So cant you find another ISP that will do what you want? Cheers Marla

-----Original Message----- From: Charles Regan [mailto:charles.regan@gmail.com] Sent: Friday, February 06, 2009 8:29 AM To: nanog@nanog.org Subject: One /22 Two ISP no BGP

I want to advertise my /22 to two different ISP on different POP.

I can't use BGP as ISP1 doesn't support it.

Any suggestions ?

Thanks, Charles

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

Leo Bicknell wrote:

In a message written on Fri, Feb 06, 2009 at 01:14:52PM -0400, Charles Regan wrote:

...

I'll explain. We are a small ISP on a very remote Island. We have a /22 from ARIN. We have a 20mbits pipe from ISP1 and 20mbits from ISP2.

Perhaps you could post the IP addresses on your end of both of these links?

I believe then NANOG may be able to shame the appropriate folks into doing BGP for you. :)

Leo's cogent answer actually caused me to go back and read the thread. :-) This is a group for network operations. Generally, we talk about public technical information, openly and transparently. What Island? What small ISP? Who are ISP1 and ISP2?