Installing your ShoreTel HQ server at the Data Center is becoming a standard deployment practice to increase business continuity during network and power outages and other disasters.   One of the most common Ask DrVoIP question we hear is how to create redundant WAN paths to the data center using only simple static routes.  In a typical deployment scenario we see at least a two site scenario in which the ShoreTel is located in a "missile silo" or colocation facility and connects to an operational office site at another location.   The connectivity between the two locations is MAN (Metro Ethernet) or MPLS, but is usually has a VPN through a wide band Internet connection as a backup connection to assure business continuity should the MAN go down.    What is the best strategy for configuring this option? We recently had an opportunity to make use of a CISCO IOS feature, "IP SLA" and it worked remarkably well and is very easy to understand and configure.    In our real world scenario we have a two location ShoreTel deployment.  The HQ Server, ShoreGear registration switch and all the clients supporting data servers were located at the Colocation facility.   At the main office location there was a DVM, the required ShoreGear switches to support PRI PSTN connectivity and support users.   Two CISCO 2900 Series access routers connected the two site through a carrier provided Metro-E and two SonicWalls, provide a VPN connection through T1 Internet connections.   The trick was creating a scenario in which, should the Metro-E go down, there would be an automated failover of routing table to the backup VPN route. One of the problems with determining a carrier down situation, is that the router may not see a down or RED condition.   The router may in fact see a GREEN condition as the physical interface is in fact still operational.  This is where IP SLA (Service Level Agreement) really shines.   To configure an IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) echo operation, use the icmp-echo command in IP SLA configuration mode. icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface Think of the IP SLA as generating a "Ping <Destination-ip-address> - t"   or ping until fail.  The IP SLA generates a ping and when the ping is not returned, the interface is consider down.  The route is then removed from the routing table and the alternative route is brought on line.     There are a variety of ways to configure this route table update, but in this particular example we choose to use was to create alternative routes, based on the SonicWall VPN tunnel.  These default routes had an Administrative Distance higher than the primary route: ip route 0.0.0.0 0.0.0.0 10.100.8.1 track 1 ip route 0.0.0.0 0.0.0.0 200.1.1.42 10 ip route 200.1.10.40 255.255.255.252 200.1.1.42 The default route has a TRACK 1 reference that points to the actual IP SLA configuration below.  The default route statement is repeated with the secondary route option and the 10 makes this a more costly route.  The default route will be used until the IP SLA returns "unreachable" at which time the secondary route will become the primary route between locations.. The actual IP SLA configuration looked like this: track 1 ip sla 1 reachability ; ip sla 1 icmp-echo 10.100.8.1 source-interface GigabitEthernet0/0 threshold 2 timeout 1000 frequency 3 ip sla schedule 1 life forever start-time now The configuration is very simple, yet very powerful.   Should the "Track 1 = unreachable" then the default route will be replaced with the higher cost secondary route.  This happens quickly enough for there to be no service interruption.  When the track becomes reachable again, the route table is updated and all returns to normal! The actual trouble shooting of the SonicWall VPN took more time to resolve than this IP SLA took to configure and test.   This is just one of the strategies that can be employed to accomplish this vital task, but it is powerful and readily available and yet another reason to use CISCO routers in your deployment!   The following video recreates the actual network issue, routes and was created to prove out the revisions that needed to be made in the SonicWall to support the deployment. http://youtu.be/LRw-zuWXNoE