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.
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.
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
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.
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :