3 Replies Latest reply on Apr 25, 2012 12:06 PM by david

    WAN Link Redundancy (WLR)

    meyerj66 New Member

      I have a TA908e. Customer has two (2) ISP connections with static IP's. How would I set up WLR so if the primary connection goes down the secondary kicks in.

        • Re: WAN Link Redundancy (WLR)
          david Employee



          Thanks for posting!  The most common means of fail-over is to use higher administrative distance default routes.  Below is an example.


          ip route ppp 1

          ip route ppp 2  10


          In this example, adding "10" as the administrative distance keeps the "ppp 2" route from being used as long as "ppp 1" is up.  However, this configuration will only fail over if the PPP interface goes down.  Network problems further upstream could prevent service.  Also, ethernet WAN connections can often have problems with IP connectivity even though the ethernet interface never goes down.  In these cases, our Network Monitor feature will help determine when a default route change should take place.  Below is an example taken from Network Monitoring in AOS (DOC-1646).  You can use that link for more detailed information.  In this example, a primary route exists through and a backup route would go to


          1. Configure the probe:

          probe ping1 icmp-echo


            period 10

            tolerance consecutive fail 3

            no shutdown


          2. Configure the track:

          track ping1

            test if probe ping1


          3. Configure the administrative distance of the secondary link:

          ip route 100


          4. Configure PBR:

          ip access-list extended ping1

            permit icmp any host


          route-map probeping1 permit 10

            match ip address ping1

            set ip next-hop

            set interface null 0


          ip local policy route-map probeping1


          5. Associate track with primary route:

          ip route track ping1


          This configuration will invalidate the route to in the event that we have 3 consecutive failures to receive an ICMP echo response on that primary interface.  Of course, you will want to change the IP addresses, ping probe tolerances, etc. to fit your specific application.


          There are a couple of other significant considerations when setting up multiple WAN connections.  First, if you are doing NAT for a private LAN behind the Adtran unit, you will need to make sure your firewall rules allow for NAT to fail over quickly and use the appropriate public IP address.


          ip firewall fast-nat-failover


          interface ppp 1

            ip address

            media-gateway ip primary

            access-policy Public1


          interface eth 0/1

            ip address

            media-gateway ip primary

            access-policy Public2


          interface eth 0/2

            ip address

            access-policy Private


          ip access-list extended matchall

            permit ip any any


          ip policy-class Private

            nat source list matchall address overload policy Public1

            nat source list matchall address overload


          Please take note of the "policy Public1" associated with the first NAT statement.  This optional parameter ensures that the source IP address will be changed to only if the traffic is destined for the interface on which "Public1" is applied, in this example the PPP 1 interface.  In the fail-over scenario, this condition would not be met, so the new outbound session would fall through to the rule which will change the source IP address to  Additional information for firewall settings can be found in Configuring the Firewall in AOS (DOC-1657).


          The last significant consideration would be your SIP registrations.  Once your TA908e has switched over to the backup link, we want to make sure a SIP registration goes out this new link so that inbound calls will use the reachable IP address.  The route table change will not directly trigger a SIP registration, so we can just use short registration timers to make sure the new registration occurs within a relatively short window.   Consider a case where the network SIP registrar provides a 5 minute (300 second) expire time on our registrations.  We would rather not wait five minutes for the new registration, so we can use the following command to ensure that new registrations are sent every 30 seconds (270 seconds prior to expiration).


          voice trunk T01 type sip

            registrar threshold absolute 270


          Hope this helps,


          • Re: WAN Link Redundancy (WLR)
            david Employee



            I went ahead and flagged this post as “Assumed Answered”.  If any of the responses on this thread assisted you, please mark them as Correct or Helpful answers as the case may be with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.