Failover for 2 ISPs

[Darren Spezio]

I would like to create a failover for if ISP 1 to cut over to  ISP 2 should it go down.

interface GigabitEthernet0/0
description Outside-LightPath
ip address 173.x.x.162 255.255.255.252
duplex auto
speed auto
!
interface GigabitEthernet0/1
description To Firewall
ip address 69.x.x.209 255.255.255.240
ip nat inside
ip virtual-reassembly
ip policy route-map toGig02
duplex auto
speed auto
!
interface GigabitEthernet0/2
ip address 108.x.x.146 255.255.255.252
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source list 50 interface GigabitEthernet0/2 overload
ip route 0.0.0.0 0.0.0.0 173.x.x.161
!
ip access-list extended toGig02
permit tcp any any eq www
permit tcp any any eq 443
!
access-list 50 permit 69.x.x.208 0.0.0.15
!
no cdp run

route-map toGig02 permit 10
match ip address toGig02
set ip next-hop 108.x.x.145

[Richard Burts]

There is a mismatch between what the title of the post says you want to do and what this config actually does. The assignment of the route map as part of policy on Gig0/1 creates a Policy Based Routing that redirects WWW and HTTPS traffic to the second ISP. It does that all the time and so there is no failover. If the title of the post said you want to achieve load sharing then perhaps this config might achieve this. But it does not achieve failover.

For failover there needs to be something that identifies when the environment changes and that changes in routing are called for. For connection to two ISP that might turn out to be a routing protocol like BGP to determine the path through the primary ISP has failed. Or that solution might be something like a primary default route and a floating static default route with IP SLA tracking reachability to the primary ISP.

HTH

Rick

[Darren Spezio]

Yes, this is currently setup to load balance between the 2 ISPs and allow outside RDP connections to our internal servers using strictly the 69.xx address.

I'm confused as to how I should setup the IP SLA, since I only have the one default route - ip route 0.0.0.0 0.0.0.0 173.x.x.161.

[Richard Burts]

So the current situation is that you have load sharing configured and working. And the question is what do you need to change to provide failover?

There are several alternatives that you could consider for achieving failover. As I mentioned you might use a dynamic routing protocol such as BGP. But since it appears that you are not currently running a dynamic routing protocol this might not be an attractive alternative for you. So I will suggest a different approach to achieve failover. This approach will have two steps.

The first step toward achieving failover is to modify the PBR that you are currently using. The change would be to use the verify-availability option which can be used in PBR. This would involve setting up an IP SLA to track reachability of the ISP address used as the next-hop  in your route map. The advantage of this is that it would be aware of the reachability of the next hop address and if the next hop becomes not available then PBR would revert to normal routing until the next-hop becomes accessible again. So this provides failover for the WWW and HTTPS traffic.

The second step would provide failover for your traffic to your primary ISP. To achieve this you would configure a second static default route, but this route would be a floating static route. A floating static route is a static route with an administrative distance higher than the default distance of 1. (I like using administrative distance of 250 for floating static routes but you may use whatever value you like for this) After you configure the second static default route then you would configure IP SLA tracking for the primary default route. This will track reachability of the next hop of the primary default route and if it becomes not available then the primary default route will be withdrawn from the routing table and the floating static route will be used which will send traffic through the secondary ISP until the primary is reachable.

HTH

Rick

[Darren Spezio]

Thank you Rick for your detailed explanation. Some of this is out of my wheel house, but I'm trying to research and learn as I'm reading you answers.

#1 I'm not entirety sure I understand what the Gi0/2 is doing, is it only active when the primary ISP (1000MB) circuit gets exhausted, or is traffic going between the 2 ISPs simultaneously?

#2 I pulled the connection out on ISP 2 and the internet is up and happy, but it doesn't work if I pull the primary and leave the secondary ISP plugged, so isn't the secondary ISP already failing over to the primary?

[Richard Burts]

#1  The way that you have configured PBR traffic is going to both ISP simultaneously. You are directing all web traffic (WWW and HTTPS) to the ISP on Gig0/2 and all other traffic to ISP 1.

#2  You have no failover if ISP 1 fails and your failover if ISP 2 fails is not reliable. PBR will forward traffic as long as the outbound interface for the next hop is in the line protocol up state. If the outbound interface goes line protocol down then PBR stops forwarding. But as long as the interface is line protocol up state then PBR keeps forwarding no matter whether the next hop is reachable or not. When you pull the connection on the router then the interface goes line protocol down and PBR stops forwarding and uses the normal routing. But there are lots of things that can make the next hop not reachable and PBR would not fail over. This kind of issue happens with Ethernet interfaces and is the reason why Cisco introduced the verify availability option in PBR. If you add verify availability to your route map then you should have failover from ISP 2. To get failover for ISP 1 you need the floating static default route or something equivalent.

HTH

Rick

[Darren Spezio]

Would something like this work?

route-map toGig02 permit 10
match ip address toGig02
set ip next-hop 108.xx.146 verify-availability track 10

ip route 0.0.0.0 0.0.0.0 108.xx.145 250

ip sla 1
icmp-echo 173.xx.162
frequency 4
timeout 2000
threshold 100
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability

[Richard Burts]

This is a good start and has parts of the solution for both sets of changes. But neither part is yet complete.

The addition of verify-availability to the route map looks right. But it says to use 10. There is no 10 to track. Logically the track 10 would be testing reachability to 108.x.x.146 (which should actually be 108.x.x.145) So you need to add this ip sla and track to the config.

The config of the floating static route looks fine.

The ip sla that you have here should be checking on 173.x.x.161 rather than 162 (which is your own IP address). And then you need to add to the existing static default route the parameter that it should track 1.

HTH

Rick

[Darren Spezio]

I can't thank you enough for spending this time helping.

Does this look any better?

route-map toGig02 permit 10
match ip address toGig02
set ip next-hop 108.xx.145 verify-availability track 2

ip route 0.0.0.0 0.0.0.0 173.xx.161 track 1
ip route 0.0.0.0 0.0.0.0 108.xx.145 250 track 2

ip sla 1
icmp-echo 173.xx.161
frequency 4
timeout 2000
threshold 100
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability

ip sla 2
icmp-echo 108.xx.145
frequency 4
timeout 2000
threshold 100
ip sla schedule 2 life forever start-time now
track 2 ip sla 2 reachability

[Richard Burts]

Yes that does look better.

HTH

Rick

[Darren Spezio]

Awesome!

Do I really need this?

ip access-list extended toGig02
permit tcp any any eq www
permit tcp any any eq 443

[Richard Burts]

For PBR to work the route map must identify the traffic that matches some criteria which is usually an access list. That is what this access list is doing. So if you want PBR to work and to use both ISP simultaneously then yes you do need this access list.

HTH

Rick

[Darren Spezio]

Okay I guess my next question is do I need the PBR?

If I remove it will it affect the RDP connections to our internal servers using strictly the 69.xx address.

[Richard Burts]

To answer the first part of your question of do you need the PBR would require understanding of your environment and what your network requirements are. Since I do not know much about that I am not in a good place to say what you need or do not need. If you remove the PBR then you will no longer send web traffic through one provider and other traffic through the other provider. Whether this will satisfy your network requirements is not something that I can predict.

To answer the second part of your question is easier. If you remove the PBR I do not see it having any impact on the RDP connections to your internal servers.

HTH

Rick

[Darren Spezio]

I really don't need traffic separated between ISPs, since the primary is 1 gig and the 2nd ISP is 100mb.

My concern is that outside RDP connections to our internal servers use strictly the 69.xx address to forward inside. Which was something that I was having a problem when I added the 2nd ISP, it flipped between the 2 ISPs and some users were not able to RDP from home while others had no issue.