Multiple ISPs and Multiple IP Ranges from Each ISP

No! That would break the internet's basic principle of hierarchical distribution of resources (addresses).

You can achieve redundancy for *outbound* traffic using some form of NAT-configuration where the NAT-device is able to detect that one of the connections is down. Redundancy for inbound connections is not possible.

To achieve what you really need requires that you obtain your own (provider independent - PI) addresspace. Your provider(s) should be able to tell you if it is possible, and if so what the policies and requirements for such configurations are in your region.

That's not entirely true. There are at least two ways to achieve redundancy without own IP address space:

1. Device supported

For example Cisco PIX allows you to define multiple peers for one VPN connection. If one peer fails, PIX will try the next IP address.

1. DNS method

Multi-homing devices (like Nortel Alteon Link Optimizer) act as DNS servers and to DNS queries they will return an IP address that is preferred at the time (this can be either fault tolerant based or load balancing based).

In article , Per Heldal wrote: :To achieve what you really need requires that you obtain your own :(provider independent - PI) addresspace. Your provider(s) should be able :to tell you if it is possible, and if so what the policies and :requirements for such configurations are in your region.

It would not -necessarily- have to be Provider Independant -- but you would need the agreement of the providers involved to put the address space into an AS and advertise routes to it. The backbone routers aren't going to be very happy about that if the address spaces are embedded in large blocks they would otherwise supernet, but their grumpiness would be reduced if the two ISPs involved were "close by" (in routing space) so that -most- of the net could continue to use a single route.

For example, the largest carrier by far in these parts is "MTS", so ARIN strongly encourages people to get address space from MTS -- including regional ISPs. Any regional ISP worth its salt isn't going to have a "single point of failure" just because it's address space was SWIP'd from a different ISP. But at some point there are effectively network boundaries for MTS address space, and as long as those several boundaries know to do the route splitting, the rest of the world only needs to know how to route to the MTS boundaries. If one then multihomed between the regional ISP and MTS directly, then it could all work even without "Provider Independant" IPs.

Sounds like a bad idea to me. Any decent provider that operate according to RIR-recommendations would filter "orphan" blocks. As you say, it is possible for two or more providers to cooperate in such a way that it is invisible to the rest of the world. However, such a configuration is a nightmare to maintain and I think you'll have a problem to find anybody willing to operate such a thing.

Despite possible workaround my recommendation remains: Use PI-space if you're big enough to qualify. If not, build redundancy with only *one* upstream. Any ISP who wants to be taken seriously as a supplier of business-critical communications already have serious redundancy built into their own network and the ability to offer redundant connections to customers (connect to more than one POP etc). I.e. choose a decent supplient instead of trying to build your own solutions for redundancy.

//Per

Only if you place requirements on applications. I was thinking industrial-strength redundancy that would also would allow e.g. TCP-sessions to stay active. There are workarounds if you lower the requirements somewhat.

This only works if you control the application/equipment at both ends of the packet-stream. The original question didn't indicate that.

DNS-based redundancy works ... to some extent. However, it requires off-site equipment (outside the address-block to be protected) or that you can buy such services elsewhere. Also, don't depend on it for "quick failover". No matter how much you lower your TTL there will always be enough caching servers and cacheing applications out there to give you plenty of problems. Now, you can always say it's their problem if they're not standards-compliant, but that's a whole other discussion.

//Per

Yes, you are right saying that one can't achieve high level redundancy using "cheap tricks". However people posting here are usually after the cheap tricks. Somebody who really wants and needs redundancy doesn't post a question here - he will hire a consultant.

True.

Again yes. I can see that you have been there, done that and probably got even the T-shirt.

In article , Jyri Korhonen wrote: :Yes, you are right saying that one can't achieve high :level redundancy using "cheap tricks". However people :posting here are usually after the cheap tricks. :Somebody who really wants and needs redundancy doesn't :post a question here - he will hire a consultant.

Unfortunately, -particularily- when it comes to redundancy, we are seeing a non-trivial number of people coming here who "really want and need redundancy", wanting to know which -one- statement they need to add (or which one radio box to click in the GUI) in order to achieve bi-directional packet-level load balancing -and- sub-10-second failover between different residentially-oriented broadband providers.

Some of those people realize quickly that it isn't quite that simple and that they'd best get someone in to help; but some of the people are quite persistant in their belief that not only should we be able to "just give them a few commands", but also that we should do so promptly and eagerly -- "I posted this a long time ago {55 minutes}, why hasn't someone answered yet!?!"

What!?! Am I the only one clued into the

ena conf t ip bidir load-balance all-link

and

ena conf t router ospf 1 area 0 subsecond-convergence

commands?

OK...admit it! How many of you *just* tried this! :)

The danger of hiring consultants is that there are too many stupid ones!

Right, now all we need is the same for PIX OS 7.0. And please don't mix OSPF into it because that will only confuse most inquirers.

I'm sensing a little bitterness. I can understand that because that's how these things work. In Finland we have a proverb

"Yksi hullu kysyy enemmän kuin kymmenen viisasta ehtii vastata."

which roughly translated means

"A madman can make so much questions that ten wise men can't manage to give the answers."

In your case that has often been only one wise man when you have single-handedly kept up PIX support here. Well, it may be cold comfort but I can say that if I have a PIX problem then my first thought is not "I'll call our provider" and not "I'll contact TAC". It is "I'll write to c.d.s.cisco and ask Walter".