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]

To analyze this problem and to troubleshoot it would require more knowledge of your environment than we have got. But based on the little bit that we know so far, I will offer a couple of suggestions:

- I doubt that adding PBR caused the issue with RDP. And so I doubt that removing PBR will make the problem with RDP go away.

- It may well be that the problem with RDP is related to having the second ISP. But that does not mean that the problem is related to PBR.

- Does the second ISP route Internet traffic to you for the 69.x.x network? If so that might cause a couple of problems since the partial config that you posted shows that the outbound response traffic would be routed through ISP 1. So if the RDP request came through ISP 2 and the response goes through ISP 1 would that be a problem?

- you might also want to look at the firewall rules to see if there is any dependency in the rules for RDP about where the traffic came from or is going to.

HTH

Rick

[Darren Spezio]

Just to clarify RDP is working now as it should.But I'm not sure which part of the config is making that happen.

If a user at home RDPs to 69.x.x.x which forwards to an internal server on 10.x.x.x then it needs to go back out on 69.x.x.x so nothing gets dropped correct? and what in the config is telling it to go out that way?

[Richard Burts]

In one post you describe problems with RDP

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.

And now you say that RDP works as it should. So I am a bit confused.

There is not anything in the parts of the config that you posted that control what happens with RDP. I would guess that most of that is done on your firewall. Or is might be possible that there are parts of your router config that control RDP that you have not shared with us.

HTH

Rick

[Darren Spezio]

Sorry, I meant I was having problems when I set it up back in March, before this current config that is posted. This one is working for the RDP connections, I was just curious what in this posted config is making it work, because it seems like everything goes back out on 69.xxx which is what I want it to do. Back in March it would go out either one, which was the problem. I did have the 2nd IP in at that time ip route 0.0.0.0 0.0.0.0 108.xx.145 without making it floating - could that be it?

[Richard Burts]

If you had two static default routes and neither of them was floating it would mean that the router would use both of them resulting in some load sharing. It is possible that having some of the RDP traffic go out through ISP 2 could create a problem. If that is the case you might want to schedule some time to do some testing of failover between the ISPs. You would want to test and see if traffic fails over from ISP 1 to ISP 2 does that impact RDP traffic?

HTH

Rick

[Darren Spezio]

Great! again thank you for all of your help and patience, I feel like I learned a little something in the process.

I will be on vacation for a few days, and will post my findings to this discussion when I return.

Darren 

[Darren Spezio]

I'm getting this error in global config mode.

Inet-2900(config)#ip sla 1
^
% Invalid input detected at '^' marker.
 

[Gaurav Mahajan]

You need to upgrade from IPBase License to a minimum of data license or something higher (Security or UC license) to be able to run IP SLA command on any ISR G2 Router. Check the following URL for more clarification:

http://www.cisco.com/en/US/prod/collateral/routers/ps10616/white_paper_c11_556985.html#wp9000807

You can also optionally activate any of the Technology Licenses by following the steps below;

Router>enable

Router#configure terminal

Router(config)#license boot module c2900 technology-package securityk9

Router(config)#exit

Router#reload

please note that you may be prompted to accept End User Agreement in the activation process, that's fine.

That will give you 60 days of evaluation and you can run any of the commands supported while you purchase the license you need. The URL above will guide you on the license to upgrade to.