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
Get a new ISP and fire whoever signed that contract before getting
the technical details correct.
Quick questions.
If both ISP publish my /22, what will happen if ISP1 goes down ?
Half the internet won't be able to reach me ? I'll have to call them
to remove the route manually ?
Charles.
The link that goes down will trigger that provider to remove the route,
traffic will swing and start coming in on the backup link.
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.
Jason Biel wrote:
The link that goes down will trigger that provider to remove the route,
traffic will swing and start coming in on the backup link.
This is assuming that 'ISP1' has the capability to advertise the OP's
route in the first place.
What if ISP1 is simply a customer of another ISP, using PA space, and
just reselling connectivity?
Charles, you really need to find out what others have asked... can the
ISP1 advertise your block of space for you, or do they really mean that
they *can't* do BGP at all.
Steve
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.
Good point on ISP1 Steve, being they are limited already, they might be just
reselling.
The can't do BGP.
They are already advertising two /24 for us. So they will advertise a
/22 if I ask them.
What if both annonce my /22 unweighted ?
I know I will loose failover in this scenario.
I am trying to figure out what will happen, traffic will flow inbound
from both in a round-robin like method ?
It will depend on the source of the traffic and how that peer follows AS
path into your providers.
I would guess that if one of them can't change their announcement when their
link to you is down, then make sure their announcement is the less
preferred.
The ISP that *can* remove their announcement when their link to you is down
should be the preferred path since their path is much more
likely to be actually up...
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.
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 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?
From http://en.wikipedia.org/wiki/Smiley
The two original text smileys, 
to indicate a joke and 
to mark
things that are not a joke were invented on September 19, 1982 by Scott
E. Fahlman, a research professor at Carnegie Mellon University's
Department of Computer Science. His original post at the CMU CS general
board, where he suggested the use of the smileys, was retrieved on
September 10, 2002 by Jeff Baird from an October 1982 backup tape of the
spice vax (cmu-750x) as proof to support the claim.[14]
In a message written on Fri, Feb 06, 2009 at 03:36:14PM -0500, Dean Anderson wrote:
Re Charles,
this is all about control, so you don't lose connectivity in case something
outside your control fails.
The best idea so far is the ebgp-multihop idea with your ISP's transit
provider. This means speaking BGP to them yourself and taking care that
the traffic takes the intended path, too (will usually work).
If you can spare the money, I'd set up my own hubs on the "mainland",
tunnel to them through each of my ISPs and use that hub for the
routing of all incoming traffic. This does of course mean additional
hardware, housing, local loops and probably additional transit
providers. It would nonetheless give you full control.
The second best idea so far is that the NANOG people could "talk" to
your ISP(s)...this has worked in more than one case.
So - where is your island, how's the weather, and are you hiring? 
Yours,
Elmar.
For the folks asking what island.
http://en.wikipedia.org/wiki/Magdalen_Islands
http://www.panoramio.com/user/45210
We are hiring if someone is interested
It's not like the Bahamas. I wish it was. It's alot colder here.
I've talked to ISP1 yesterday and they will let me know what they can
do. There's a chance...
I will also have to scale up. I don't think my Soekris with OpenBSD
can handle two full route of the Internet.
Any suggestions ?
Charles
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
This is quite neat, but the ISP may be multihomed and support BGP at
one edge (several transits, several peers), but not at their customer
facing edge.
Andy