Tunnel Route Selection and DMVPN Tunnel Protection Don’t Work Together

Cisco has introduced Tunnel Route Selection, another “somewhat” underdocumented feature in IOS release 12.4(11)T (reading the sparse documentation, it appears to be a half-baked kludge implemented for a specific customer). I was wondering for a long time why I would ever want to use this feature, until Floris Martens asked me a question about a redundant DMVPN network using two ISPs, and all of a sudden it all made a perfect sense.

Building redundant DMVPN networks with multiple ISPs is a pretty common scenario, so I’ve included it in the DMVPN – From Basics To Scalable Networks. However, when I tried to build a test lab, I could not get tunnel route-via to work in a protected DMVPN network. After a few hours, I had to conclude there’s no way to make tunnel route-via work with tunnel protection (you could probably make it work in combination with crypto maps in Phase I DMVPN configuration, but I definitely didn’t want to go down that route).

To add insult to injury, somehow Cisco’s programmers managed to lose the “tunnel route-via feature is on” part of the show interface printout when merging various IOS trains to produce 15.0(1)M. The feature works in 15.0(1)M, but there’s no way to check with a show printout whether it’s enabled or not.

7 comments:

  1. Hi, Ivan.

    I was configured a DMVPN topology with a "spoke" with two ISP connections (one dedicated and one DSL).
    when I asked me, what can it to do to control the tunnel establishing for a specific ISP?; I found the "tunnel route-via" command; for this reason I proced to probe it.
    For me this command work fineBOG-RT-01#sh ip route 192.168.162.0
    Routing entry for 192.168.162.0/24
    Known via "eigrp 1600", distance 90, metric 2758656, type internal
    Redistributing via eigrp 1600
    Last update from 10.249.249.249 on Tunnel32767, 00:01:26 ago
    Routing Descriptor Blocks:
    10.249.249.249, from 10.249.249.249, 00:01:26 ago, via Tunnel32767
    Route metric is 10258688, traffic share count is 13
    Total delay is 10110 microseconds, minimum bandwidth is 256 Kbit
    Reliability 254/255, minimum MTU 1400 bytes
    Loading 1/255, Hops 2
    10.248.248.249, from 10.248.248.249, 00:01:26 ago, via Tunnel32768
    Route metric is 10258688, traffic share count is 13
    Total delay is 10110 microseconds, minimum bandwidth is 256 Kbit
    Reliability 255/255, minimum MTU 1400 bytes
    Loading 1/255, Hops 2
    * 10.247.247.249, from 10.247.247.249, 00:01:26 ago, via Tunnel32766
    Route metric is 2758656, traffic share count is 48
    Total delay is 10110 microseconds, minimum bandwidth is 1024 Kbit
    Reliability 255/255, minimum MTU 1400 bytes
    Loading 1/255, Hops 2

    BOG-RT-01#
    BOG-RT-01#


    BOG-RT-01#sh ip nhrp brief
    Target Via NBMA Mode Intfc Claimed
    10.247.247.249/32 10.247.247.249 1XX.2XX.93.230 static Tu32766 < >
    10.249.249.249/32 10.249.249.249 1XX.XX.1.236 static Tu32767 < >
    10.248.248.249/32 10.248.248.249 1XX.2XX.93.230 static Tu32768 < >
    BOG-RT-01#


    BOG-RT-01#sh ip eigrp neig
    IP-EIGRP neighbors for process 1600
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    2 10.247.247.249 Tu32766 2 00:38:10 177 1062 0 5389
    1 10.248.248.249 Tu32768 2 00:51:31 180 1080 0 5390
    0 10.249.249.249 Tu32767 2 00:51:37 162 972 0 4590
    BOG-RT-01#
  2. I was do a debug for tunnel route-via, as you can see:

    BOG-RT-01#
    BOG-RT-01#debug tunnel route-via
    Tunnel route-via debugging is on
    BOG-RT-01#
    071441: Oct 2 10:12:49: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1X0.XXX.174.1
    071442: Oct 2 10:12:49: TUN-VIA: Tunnel32768 route-via action is forward
    071443: Oct 2 10:12:49: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071444: Oct 2 10:12:49: TUN-VIA: Tunnel32768 route-via action is forward
    071445: Oct 2 10:12:49: TUN-VIA: Tunnel32766 candidate route-via FastEthernet0/1.110, next hop 1XX.1XX.231.1
    071446: Oct 2 10:12:49: TUN-VIA: Tunnel32766 route-via action is forward
    071447: Oct 2 10:12:50: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071448: Oct 2 10:12:50: TUN-VIA: Tunnel32768 route-via action is forward
    071449: Oct 2 10:12:50: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071450: Oct 2 10:12:50: TUN-VIA: Tunnel32768 route-via action is forward
    071451: Oct 2 10:12:50: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071452: Oct 2 10:12:50: TUN-VIA: Tunnel32768 route-via action is forward
    071453: Oct 2 10:12:50: TUN-VIA: Tunnel32766 candidate route-via FastEthernet0/1.110, next hop 1XX.1XX.231.1
    071454: Oct 2 10:12:50: TUN-VIA: Tunnel32766 route-via action is forward
    071455: Oct 2 10:12:50: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071456: Oct 2 10:12:50: TUN-VIA: Tunnel32768 route-via action is forward
    071457: Oct 2 10:12:50: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071458: Oct 2 10:12:50: TUN-VIA: Tunnel32768 route-via action is forward
    071459: Oct 2 10:12:50: TUN-VIA: Tunnel32766 candidate route-via FastEthernet0/1.110, next hop 1XX.1XX.231.1
    071460: Oct 2 10:12:50: TUN-VIA: Tunnel32766 route-via action is forward
    071461: Oct 2 10:12:51: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    071462: Oct 2 10:12:51: TUN-VIA: Tunnel32768 route-via action is forward
    071463: Oct 2 10:12:51: TUN-VIA: Tunnel32768 candidate route-via FastEthernet0/0, next hop 1XX.1XX.174.1
    BOG-RT-01#
  3. I suppose you're using IPSec (without IPSec it works just fine). Are you sure the packets are actually exiting through the desired interface?

    Debugging printouts always suggest everything is dandy, but the packets just refuse to go out the desired interface.

    Last but not least - if you're positive the packets do go out as expected - which IOS release are you using?
  4. Does anyone know if Cisco has fixed this in 15.1M1?
  5. Just ran into this problem as well. Seemed like route-via was the perfect solution to my dual-ISP DMVPN setup, but won't work with the ipsec protection profle.

    I have 15.0(1)M7 though - so I'll be upgrading to try again with a more recent code revision.
    Replies
    1. Hey, Jere, did you ever give this a try with the newer IOS? Fixed or still broken?
  6. Awesome blog and quite an old article..
    I confirm "tunnel route-via" still does NOT work with "tunnel protection" on 15.1(4)M7.

    With two ISPs and equal 0/0 routes you got russian roulette :) GRE traffic simply doesn't flow the way specified.
    So, VRF is still the only solution.
Add comment
Sidebar