Reliable GRE backup interface lab

I'm going through the reliable backup int lab for GRE, which I see was updated 7/7. 

Here is what I'm getting caught up on. 

  • Configure IPv4 static routes on R5 for R4’s Loopback0 interface via both the DMVPN cloud and Tunnel45.

Easy Enough

  • Configure IPv4 static routes on R4 for R5’s Loopback0 interface via both the DMVPN cloud and Tunnel45.

Easy Enough

  • The static routes on R4 and R5 via the DMVPN cloud should have a higher administrative distance than those on Tunnel45.

Ok. So I make the route to & 4 (dmvpn links) metric 2, giving routes to & 4 default metric of 1

  • Configure the backup interface feature on R4 and R5 so that if the Tunnel100 goes down, Tunnel45 is activated.

Here is where things get wonky. Now that I'm making tun45 the backup it goes into standby mode, thus giving the route to the DMVPN link, not tun100. 

Am I missing something or is there a line in the lab missing about putting in a route for tun100?
Looking at the lab config, the metrics are set to 10 and 20, but I dont think that matters, because there is no route for tun100, so the metrics could be 1000 and 2000, it would still drop the route for tun45 once it goes into standby mode to become the backup interface of tun100, giving the route to the DMVPN link, not tun100.


OK, I just verified what I was questioning. I config replaced back to Basic IP Addressing, flat out copied, pasted the config from the workbook, still the same results.
 R5(config)#do sh ip cef

  nexthop Tunnel0

This is due to tun45 being the backup int to tun100, and no route being set for tun100. 

All in all, I'm just questioning this so I can verify I'm not crazy :). I'm not trying to nit pick bugs. 


  • OK, It's expected. Nevermind everything I said. The lab is expecting traffic to use the DMVPN link. Tunnel 100 is only used for the keepalives, tun45 is the backup interface with the lower admin distance (I'm not sure why you would ever do that but ok). 

    Once the keepalives stop, tun45 comes up and becomes primary route, even over the DMVPN link. 

    Odd setup but I'm getting what the workbook is wanting now. 

  • Hi,

    I do agree that some of the tasks could be cleaned up a little. It would help if the solution mentioned which static routes we would have to remove before moving on to the next task. I assumed that the static route through Tunnel 100 was still present here so the whole task didn't make a lot of sense until I was looking at the solution and got what they really wanted to do. Clever task but maybe it could be re-phrased a little or state that the previous static route through Tu100 should be removed. There is a lot of implicit information in the wording and the word reliable is only mentioned in the task title. An additional bullet would help.

  • Zup guys!


    I'm guessing in terms of the route distances on this particular task, that it was a mistake? Here the backup interface isTunnel 45 and it will

    make sense that the higher administrative distance of the static routes for the loopbacks be throught this link and not the DMVPN cloud** (Tunnel100).

    Anyways the purpose of this lab is to proof the concept of GRE Keepalives and that you don't need to add extra overhead with the SLA features.  As soon as the keepalives expire on both routers, they'll teardown the primary tunnel along with the associate static route, the backup tunnel will come up along with its route.  So at the end the AD doesn't matter. Correct me if I'm wrong.



    **there should not be a route throught the DMVPN cloud at all since Tunnel 100 is a mere point to point GRE. Is true they share the same L2/L3 segment, but they aren't part of the DMVPN network (Not dynamic at all). - Assuming that you must wipe previous configs.
    "You must load the initial configuration files for the section, Basic IP Addressing"

    I recall on WB1 that this instructions were previous a not progressive/sequential task.  Am I right?

  • Just read again task:

    • Configure the backup interface feature on R4 and R5 so that if the Tunnel100 goes down, Tunnel45 is activated.

    See, again the purpose is to trigger the backup tunnel (45) to come up and reroute everything throught it.  They just want us to use

    Tunnel 100 as the trigger. 

    • If R4’s VLAN 100 interface is disabled, traffic is rerouted out on Tunnel45. ( Better distance )


    I got it wrong before, the static route through the DMVPN should never go down, it will remain as a floating one while tunnel 45 is up.

    Again, we are just using tunnel100's keepalives as a monitor/trigger mechanism and not SLA with object tracking.


    *English is not my primary language, and sometimes I tend not to read all the tasks thoroughly.  Sometimes things can get confusing pretty easily.

Sign In or Register to comment.