1 Reply Latest reply on Apr 19, 2017 11:18 PM by jayh

    Accessing router via secondary WAN interface after using PBRs

    tincg_cw New Member

      I have a NV3140 router installed where I have two different ISP connections. Both are Ethernet handoff connections. The router is currently configured with the primary WAN (Cable Connection) in GigEth 1 and the secondary WAN in GigEth 2 (Bonded T's with Eth Handoff). GigEth 3 is the LAN connection.

       

      The client has a remote application that they access in a hosted data center (static IP address). I configured a PBR to send only traffic destined to this remote data center location to go out GigEth2. It is working fine.

       

      The problem I'm encountering is that I'm unable to ping or ssh into the router via the secondary WAN connection. My hunch is that the traffic is coming into the secondary WAN connection but returning through the primary WAN connection and therefore never getting to me. I added the no ip policy-class WAN2 rpt-check and still no response.

       

      I need to be able to setup a remote ping to the secondary WAN interface for monitoring purposes. Also, today they had an extended outage and I couldn't remote into the router even though the secondary WAN remained up. I've run into this issue previously with dual WAN connections and need to figure out how to avoid it. We will ultimately be implementing a full autofailover between the two connections, but at a later date.

       

      Thank you,

       

      Chad

        • Re: Accessing router via secondary WAN interface after using PBRs
          jayh Hall_of_Fame

          This is a little tricky because you're manipulating traffic to the router itself rather than through it.

           

          Assume for this example that your secondary WAN interface is 172.16.1.1/30 and its gateway is 172.16.1.2.

           

          First create an access-list that captures traffic destined to the secondary WAN interface itself.

           

          ip access-list extended backup-gw-list

            permit ip any host 172.16.1.1

           

          Next create a route-map that matches traffic to that list and sets the next-hop as its gateway. All other traffic should follow default routing.

           

          route-map local-map permit 10

             match ip address backup-gw-list

             set ip next-hop 172.16.1.2

          route-map local-map permit 20

           

          Now set local policy routing to honor that route-map for traffic destined to the router itself.

           

          ip local policy route-map local-map

           

          For a backup-only scenario where you only need to access the secondary gateway if the primary is down, you can build a probe-and-track on the primary gateway, set your default route to track it, and put in a floating static default to the secondary gateway. Using the route-map should allow you to reach the unit via the secondary at all times regardless of the status of the primary.

           

          If you're doing this remotely, you might want to do a "reload in 15" first in case something gets fat-fingered and you lock yourself out before writing to memory. When all is good, do a "reload cancel" and then write mem.