Configure redundant static WAN routes when ShoreTel is in the data center?

September 22nd, 2012

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 track 1
ip route 10
ip route

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 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.

2 responses to “Configure redundant static WAN routes when ShoreTel is in the data center?”

  1. DrVoIP says:

    Sample configuration using IOS 15 new configuration options!

    ip sla monitor 1
    type echo protocol ipIcmpEcho
    threshold 3
    frequency 5

    ip sla monitor schedule 1 life forever start-time now

    ip sla monitor 2
    type echo protocol ipIcmpEcho
    threshold 3
    frequency 5

    ip sla monitor schedule 2 life forever start-time now


    track 101 rtr 1 reachability
    track 102 rtr 2 reachability

  2. DrVoIP says:

    The IP SLA function has been updated with Version 15 IOS and the configuration is different, but the concepts are the same. You can also edit the IP Route table based on reachability and this will work for both static and dynamic routing options. Check your IOS version to note which IP SLA configuration options apply. Also note that you must have the DATA license option in your router for IP SLA to appear at all!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ask DrVoIP

ask drvoip

Network Readiness Assessment

drvoip readiness checklist

Is your network Ready?

Complimentary free download - DrVoIP VoIP Network Readiness Assessment Checklist (pdf)

Download Now ›

Training Videos

shoretel ipbx cisco cusm
shoretel ecc audio voice prompts
cisco uccx call back option
generic call queue cc admin


web stats

© Copyright 2020
Follow DrVoIP