Technical issues with Cisco routers and switches can also be resolved remotely with software that facilitates connection through the web.
Online desktop support software gives technical support teams that access. Access desktop , servers and network devices remotely.
The following link is to an IP SLA configuration on a Cisco router that does not use the monitor command option:
IP SLA Monitor Example for Fail-over Survivability of ISP
Cisco IP SLA MONITOR example configuration. The IP address have been changed but this is a working configuration I just recently implemented. This office, actually and remote office with warehouse, has a T1 line they wanted a custom application to use exclusively but also had a DSL that was connected to a Cisco ASA 5505 (it could have been a
Cisco 5510 or other). The ASA was also on the same LAN. The idea was simple, if the T1 fails, use the DSL for the custom application to connect to an online database source and server.
There are two tracker objects in a tracker list. The list uses a boolean AND,
track 10 rtr 20 reachability --> a ping to a target ip address for which there is ONLY a single static route to use the T1. This differs wit hthe IP SLA MONITOR vs. the IP SLA (with no MONITOR option available. Here, we had to use RTR instead of specifying the ip SLA number itself))
track 11 interface Serial0/1/0:0 line-protocol --> Interface status
track 20 list boolean and --> boolean AND, boolean AND means all conditions conditions have to be true , almost seems redundant but TAC did it this way on another remote office router.
object 10 --> tracker 10 shown above
object 11 --> tracker 11 shown above
ip route 4.2.2.2 255.255.255.255 192.168.1.11 track 20 --> tracked main route
ip route 4.2.2.2 255.255.255.255 192.168.1.1 100 --> alternate route is used if T1 is down
ip sla monitor 20 --> referenced in tracker 10
type echo protocol ipIcmpEcho 8.8.8.8 source-interface GigabitEthernet0/1 --> had to use the interface as source, using the ip address did not work (another bug, perhaps) , there is an explicit static route that says any traffic for 8.8.8.8 use the T1 (there are several ways to do this and you should test them on your router to be sure you can from the IOS command line ping and try all source interfaces before building this line. You can create the router using the next hop router for the T1 connection, or the route can be built by specifying the interface to source the ping from such as S0/1/0:0 on this router, or source the ping from the "inside" interface) So if there is a problem with the T1 the pings will time out.
timeout 1000 --> max ping reply time allowed in milliseconds
threshold 2
tag 20
frequency 5 --> status is checked every five seconds
ip sla monitor schedule 20 life forever start-time now --> scheduler for monitor 20
3 comments:
We had a similar problem at one of our offices and needed to test the T1 failover. We were able to test without having one of our IT staff members at the remote office but remoting with SSH into the router through the DSL link. Then we shut the interface down. Checked our routes to verify they have changed, tried one of the client apps to verify they were still able to connect to the server through the DSL they would normally connect with via the T1. One wee tested, we "unshut" the interface. In our case is was interface serial 0/1. So at the enable prompt go to configuration mode #config t then go to the interface level #int serial s0/1 , then ran the #shut command . #Show trackerad how ip route will how you the routes. Run ip route even before testing the failover so you have something to compare with for when you run shut command on the interface.
One of the problem that we have encountered while using multiple ISP connections on our Cisco ASA has been with VPNs. They can become a problem if not taken into consideration and appropriate configurations are made to accommodate VPN connectivity on the fail-over ISP. What we have found to happen is that when a fail-over to a backup ISP occurs, our VPN can connect but traffic is not passing through properly. It appears that packets will go out the network and encapsulated but responses are not returned properly. We particularly have seen this while using vmware edge firewalls for vcloud implementations.
One of the problem that we have encountered while using multiple ISP connections on our Cisco ASA has been with VPNs. They can become a problem if not taken into consideration and appropriate configurations are made to accommodate VPN connectivity on the fail-over ISP. What we have found to happen is that when a fail-over to a backup ISP occurs, our VPN can connect but traffic is not passing through properly. It appears that packets will go out the network and encapsulated but responses are not returned properly. We particularly have seen this while using vmware edge firewalls for vcloud implementations.
Post a Comment