cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
New Contributor III

WAN Link Redundancy (WLR)

Jump to solution

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.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Valued Contributor
Valued Contributor

Re: WAN Link Redundancy (WLR)

Jump to solution

Meyerj66,

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

ip route 0.0.0.0  0.0.0.0 ppp 1

ip route 0.0.0.0  0.0.0.0 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 1.1.1.1 and a backup route would go to 2.2.2.1.

1. Configure the probe:

probe ping1 icmp-echo

  destination 1.1.1.1

  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 0.0.0.0 0.0.0.0 2.2.2.1 100

4. Configure PBR:

ip access-list extended ping1

  permit icmp any host 1.1.1.1

route-map probeping1 permit 10

  match ip address ping1

  set ip next-hop 1.1.1.1

  set interface null 0

ip local policy route-map probeping1

5. Associate track with primary route:

ip route 0.0.0.0 0.0.0.0 1.1.1.1 track ping1

This configuration will invalidate the route to 1.1.1.1 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 1.1.1.2 255.255.255.252

  media-gateway ip primary

  access-policy Public1

!

interface eth 0/1

  ip address 2.2.2.2 255.255.255.252

  media-gateway ip primary

  access-policy Public2

!

interface eth 0/2

  ip address 192.168.1.254 255.255.255.0

  access-policy Private

!

ip access-list extended matchall

  permit ip any any

!

ip policy-class Private

  nat source list matchall address 1.1.1.2 overload policy Public1

  nat source list matchall address 2.2.2.2 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 1.1.1.2 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 2.2.2.2.  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,

David

View solution in original post

3 Replies
Highlighted
Valued Contributor
Valued Contributor

Re: WAN Link Redundancy (WLR)

Jump to solution

Meyerj66,

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

ip route 0.0.0.0  0.0.0.0 ppp 1

ip route 0.0.0.0  0.0.0.0 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 1.1.1.1 and a backup route would go to 2.2.2.1.

1. Configure the probe:

probe ping1 icmp-echo

  destination 1.1.1.1

  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 0.0.0.0 0.0.0.0 2.2.2.1 100

4. Configure PBR:

ip access-list extended ping1

  permit icmp any host 1.1.1.1

route-map probeping1 permit 10

  match ip address ping1

  set ip next-hop 1.1.1.1

  set interface null 0

ip local policy route-map probeping1

5. Associate track with primary route:

ip route 0.0.0.0 0.0.0.0 1.1.1.1 track ping1

This configuration will invalidate the route to 1.1.1.1 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 1.1.1.2 255.255.255.252

  media-gateway ip primary

  access-policy Public1

!

interface eth 0/1

  ip address 2.2.2.2 255.255.255.252

  media-gateway ip primary

  access-policy Public2

!

interface eth 0/2

  ip address 192.168.1.254 255.255.255.0

  access-policy Private

!

ip access-list extended matchall

  permit ip any any

!

ip policy-class Private

  nat source list matchall address 1.1.1.2 overload policy Public1

  nat source list matchall address 2.2.2.2 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 1.1.1.2 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 2.2.2.2.  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,

David

View solution in original post

Highlighted
New Contributor III

Re: WAN Link Redundancy (WLR)

Jump to solution

Very helpful. Thank you for your assistance.

On Wed, Apr 11, 2012 at 12:35 PM, david <

Highlighted
Valued Contributor
Valued Contributor

Re: WAN Link Redundancy (WLR)

Jump to solution

Meyerj66,

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.

Thanks!

David