3 Replies Latest reply on Jul 9, 2015 1:16 PM by levi

    Dual WAN (not internet) failover with probe & track

    brianwilliams New Member

      Good afternoon!

       

      I've run across a scenario that I'd like some assistance with. I think I got most of it, but I just want to make sure. So, in this scenario, I have 3 routers connected with a primary WAN and a secondary WAN. Each WAN circuit of the various sites are all layer 2 and I've gotten my layer 3 IP addresses traversing the WANs without an issue. Below is a sample of the IP addresses that I've using (changed the IP addresses for forum purposes):

       

      Site 1:

      LAN: 192.168.10.1 /24

      WAN1: 10.255.255.1 /29

      WAN2: 10.1.1.1 /29

       

      Site 2:

      LAN: 192.168.11.0 /24

      WAN1: 10.255.255.2 /29

      WAN2: 10.1.1.2 /29

       

      Site 3:

      LAN 192.168.12.0 /24

      WAN1: 10.255.255.3 /29

      WAN2: 10.1.1.3 /29

       

      So, WAN1 is my primary WAN and I have my static routes set up. I've even gone so far as to put weighted routes in for the secondary/failover WAN. What I'd like to do is set up two probe/tracks per site so that if any site detects it's primary circuit down to the other sites, it will automatically fail over to the secondary WAN and then fail back over when the primary is back online. I've actually configured something like this before for fail over internet circuits and I'm not entirely certain it's done the same way. Not to mention the article that I read was more or less for internet redundancy which isn't what I'm looking for. So, here is what I have so far for just one of the probes/tracks - and I'm hoping someone could assist and tell me if I'm configuring this correctly or not.

       

      Example:

       

      probe S1_TO_S2 icmp-echo

           period 5

           destination 10.255.255.2

           source-address 10.255.255.1

           tolerance consecutive fail 5 pass 3

           no shut

       

      track S1_TO_S2

           snmp trap state-change

           test if S1_TO_S2

           no shut

       

      ip access-list extended pingprobe

           permit icmp any 10.255.255.2

       

      route-map ICMP permit 10

           match ip address pingprobe

           set interface gigabit-ethernet 0/1 (this is my primary WAN interface)

       

      ip local policy route-map ICMP

       

      ip route 192.168.11.0 255.255.255.0 10.255.255.2 track S1_TO_S2

      ip route 192.168.11.0 255.255.255.0 10.1.1.2 100

      ------------------------

       

      According to the documentation, I'll need the route-map to force my ICMP traffic out of the primary interface. In the documentation (and in other implementations with internet failover) I would normally choose the route-map attribute "set ip next-hop XXXX" but in this case, I wasn't sure I could do that since I'm simply just pining across the WAN between sites. I'm not looking to ping an address outside of the primary WAN because, both primary and secondary WAN can route to the LAN addresses of the sites.

       

      So, could someone take a look and point me in the right direction? Normally I'd do this with eBGP using local_pref and distribute-lists to filter my routes - but with this particular set up with all Adtran routers, I figure network monitoring with track/probes would be best.

       

      Thanks!

       

      Brian Williams

        • Re: Dual WAN (not internet) failover with probe & track
          levi Employee

          brianwilliams:

           

          Thank you for asking this question in the support community forum.  Based on the information you've provided, it appears the concepts you have are correct.  You would need to repeat this process on all sites, for all connections.  The idea is the same as the first example in the Configuring Network Monitor in AOS guide.

           

          Although, everything will work with probes/tracks etc., as you mentioned at the end of you post, typically, this application would be better suited for a routing protocol, such as OSPF, RIP, or BGP.  There may be circumstances when routing protocols aren't feasible, and then you can do the probes/tracks, but if possible, a routing protocol may be a better design for this network application.

           

          I hope that makes sense, but please do not hesitate to reply to this post with any additional information or questions.  I will be happy to help in any way I can.

           

          Levi