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.
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#
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#
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?
I have 15.0(1)M7 though - so I'll be upgrading to try again with a more recent code revision.
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.