Multiple ISPs and Multiple IP Ranges from Each ISP

I have Multiple ISP Internet links and Multiple Valid IP ranges from
Each ISPs..

I have configured to use both ISP lines using Route Maps.

For Example let my First Range be 20.10.10.0/24 from ISP-A
let my Second Range be 30.10.10.0/24 from ISP-B. Traffic from First
range will use ISP-A's Internet Link and others will use ISP-B's link.

Now, I want to Enable Redundancy between these two links...If one fails
let it use the other.

My Question here is, Will My ISPs will Route the packet from the other
ISP.
Say Suppose, My Internet link to ISP-A is down.
Now, all my Internet traffic should go thru' ISP-B..that's, Will the
traffic from 20.10.10.0/24 will reach Public world thru' ISP-B..?

If it is possible how do i do that??

Can somebody help me on this??

Thanks in advance..

 

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.

2. 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).

 

: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.

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

 

:Yes, you are right saying that one can't achieve high
:level redundancy using "cheap tricks". However people
osting here are usually after the cheap tricks.
:Somebody who really wants and needs redundancy doesn't
ost 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!


--

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

 

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".