ASA with triple ISP redundancy

[shodan524]

Hi,

is it possible to configure cisco ASA with triple ISP redundancy. I mean if one ISP fails traffic passes to second, if second also fails passes to third ISP.

if anybody knows, please help

[Jouni Forss]

Hi,

Can't say I have ever tried anything else than Dual ISP and we usually handle Dual ISP setups outside the actual ASA firewall in our cases.

Have you configured a Dual ISP setup before?

Are you testing this setup on a lab/test device or trying to implement it to a live environment?

I guess I would start by trying out configuring ISP1 and ISP2 with Track/SLA configurations so that their default route would be monitored and removed from the routing table of the ASA if the remote peer was not reachable. ISP3 would have the "worst" default route which would be installed after the other 2 fail.

- Jouni

[Jon Marshall]

Hi Jouni

I was just thinking about this. The ASA will support up to 3 equal cost routes so that bit is good. The issue is to cycle between them you would need to -

1) configure a static to primary and track with IP SLA

2) configure a static to secondary with a higher AD than 1) and track with IP SLA

3) configure a static to third ISP with higher AD than 1) and 2)

the bit i am not sure about is 2). If you are tracking the route and the ping is successful then presumably because the AD is still higher it won't install the route until 1) fails.

Does this sound right ?

Jon

[Jouni Forss]

Hi Jon,

Actually the only times I have even used Dual ISP setups has been to test something out for users here. I have not actually set up one for our customers as the Dual ISP is usually done on some router platform with single link to the actual customer firewall.

What I was speculating above was the following situation.

• ISP1 has the best default route which is tracked.
• ISP1 default route track is bound to the ISP1 interface on the ASA and the ASA uses the ISP1 interface to monitor/poll the remote host
• ISP1 fails and ISP1 tracked default route is removed from the ASA routing table
• ISP2 default track is bound to the ISP2 interface on the ASA and the ASA uses the ISP2 interface to monitor/poll the remote host
• ISP2 Default route becomes after the previous ISP1 failure due to its default route being removed from the routing table
• ISP2 fails and the ISP3 would be the only interface holding a default route as the ISP1 and ISP2 tracked default routes would not be installed on the ASA while the tracked remote hosts were unreachable through the ISP1 and ISP2 links

This is my understanding of the setup atleast but as I said I have not really implemented these setups with ASAs so I can't be 100% sure that it operates like this.

But this could be tried by the user if he has the change to lab this out.

- Jouni

[Jon Marshall]

Jouni

That was the way i saw it working as well. The only doubt i had was the IP SLA on the 2) in my post. IP SLA removes a route if the ping fails and reinstalls it if the ping works. But with 2) the ping is working so it would try to install. But it wouldn't be able to because there is already a route in the table with a better AD.

So i was just wondering how the tracking would react to that ie. ping successful but can't install the route. I suspect it would work but it would definitely be one of those things i would want to test.

I really hope Dan comes through on my request because i need to get GNS3 up and running as soon as possible

Jon

[Jouni Forss]

I'm sorry but I must be missunderstanding something.

Which route would prevent the ISP2 default route being installed to the ASA routing table if we presume that the ISP1 link is failed because of the ICMP Echo poll failing through the ISP1 interface? The ISP1 default route should be removed from the routing table at this point and the ISP2 default should become active provided the ISP2 has not failed also.

- Jouni

[Jon Marshall]

Jouni

You are correct in what you say. It's probably the way i described it.

I was talking about when the ISP1 link is still up and running so the default route to ISP1 is still in the route table and being used. IP SLA for ISP2 is successful so IP SLA would then try and install the route. But it can't because the ISP1 route is still there and has a better AD.

So i was just wondering how IP SLA responded to that. I suspect it is not an issue because, as far as i know, IP SLA only removes routes ie. it doesn't install other routes, that is done in the same way any route is installed in the routing table.

It's just that i have only used IP SLA where a successful ping meant the route stayed in the routing table as opposed to here where a successful ping still means the route is not in the routing table.

Apologies for any confusion.

Jon