Fun in the Lab: Sniffer Tracing a DMVPN Tunnel Startup

Fun in the Lab: Sniffer Tracing a DMVPN Tunnel Startup

DMVPN’s per-tunnel QoS is really cool. Is this post about per-tunnel QoS? Actually… no. 🙂  This is the post PRIOR to that post.  🙂   This is the post that will familiarize you with the environment we will be do doing the per-tunnel QoS in.  This is the post where you get to download the sniffer trace of a DMVPN tunnel coming up in a nice clean lab environment and what the NHRP looks like prior to us putting per-tunnel QoS on.

Why a sniffer trace? Cause I’m a sniffer trace kinda girl.  It’s how I learn and how I “see” the underlying flow which helps me put the puzzle pieces together.  Documentation and show commands help me… but everything seems to “sink in deeper” if I can sniff the wire.

So for those of you who learn like I do….  let’s go play in the lab!

First… you may want to grab the actual pcap file we are going to be looking at together

dmvpn_tunnel_startup.pcap    <– it is on my public dropbox and I plan to keep it there for a few years.  🙂

Ready?

dmvpn_tunnel2_topo

 

 

 

 

 

 

 

 

 

 

Welcome to our little lab environment.  Again… this will be the environment we will also be using for the DMVPN per-tunnel QoS post which (in theory) is next.  Quick summary of what we are looking at here.

  • INET side of my larger IWAN play environment
  • No “DIA” (direct internet access) for the branches to keep things “simpler” for now
  • No encryption enabled so we can sniff and see everything

We are going to start with the “WAN” facing interfaces administratively shut down so we can capture the DMVPN coming up and then the EIGRP over it.  See the little “wireshark” logo up between Foxtrot14 and the INET cloud? This is where we are going to put our sniffer.


Quick Side Note: Completely new to DMVPN?  I’m not sure if looking at this sniffer trace is going to clear that up for you.  🙂  I will suggest you read a little first on DMVPN and understand a little more about mGRE as well as NHRP.  mGRE and NHRP are key to the “magic” that is behind DMVPN.  I would also suggest if you are going to be running DMVPN in your environment that you utilize CiscoLive’s “On Demand Library”.  There are recordings of every breakout session from every CiscoLive around the world for the past few years.  And it is …. get this…. free.


Frames 1 thru 10 (below) are just some ARP, STP, and CDP.  Feel free to look at them…. but we aren’t going to go into more detail on any of those here.

capture_1_thru_10

 

 

 

 

“Who is echo12″” you might ask.  Foxtrot14 actually connects to a layer 2 switch named “echo12” via vlan 214.  It is that layer 2 switch that connects to the sole “INET” core router. I do this for ease of sniffing.

Onto the first “DMVPN” magic.  We will find this on the wire with frame 11 (NHRP registration request) and frame 12 (NHRP registration reply)

  • Frame 11 is the NHRP registration request from Echo3’s NBMA IP address 21.21.102.6 TO Foxtrot14’s NBMA IP address 21.21.1.2.
  • Frame 12 is the NHRP registration reply from Foxtrot14’s NBMA IP address 21.21.1.2 to Echo3’s NBMA IP address 21.21.102.6

flow

 

 

 

 

 

 

 

 

 

 

 

So what does this look like on the wire?

 

wire

 

 

 

 

 

 

 

 

 

 

 

 

 

What is RFC2332?  It is the RFC for NHRP.  Again, NHRP is one of the key pieces of magic that DMVPN utilizes.  DMVPN is  based on NHRP version 1 but Cisco has made (and continues to make) really great extensions to the protocol that we can use between Cisco devices.

How did Echo3 know where to go to?  The configs for the tunnel interface on Echo3.  Let’s look at them

echo3_tunnel2a

 

 

 

 

 

 

 

 

See how Echo3 is statically configured to know the destination physical IP address it is trying to get to is 21.21.1.2?

“What happened to the dynamic part of this?” you ask —  Well, obviously while the hub can be dynamic and just sit there and listen… someone has to start the call.  🙂

Wow, that is a lot of configuration, do I have to do all of that?” you ask — No.  But everything I put in there has a reason for being in there.  Once you know what your branch DMVPN design is… you can pretty much be “cookie cutter” with the branch tunnel configs — changing really only two things at each branch

1) 4th Octet: 10.99.2.x   &   2) Tunnel Source Interface: If your branches vary here

Note: While I have not played with it myself, it is my understanding that you can also use DNS to lookup the hub.

If you continue on in the sniffer trace you will see

  • Echo3 and Foxtrot14 exchanging NHRP registration request/reply, followed by
  • EIGRP neighboring up over the mGRE tunnel – 10.99.2.1 with 10.99.2.102, and then
  • NHRP exchange between Branch1-R2 and Foxtrot14
  • EIGRP neighboring up over the mGRE tunnel – 10.99.2.1 with 10.99.2.101

What does all this look like via the CLI and show commands?

foxtrot14_dmvpn

 

 

 

 

 

 

 

foxtrot14_tunnel

 

 

 

 

 

 

 

And then, of course, finally our EIGRP neighbor.

eigrp

 

 

 

Eh… Voila… our DMVPN is up along with our EIGRP neighbors. 🙂

 

  • Tim Martin

    kewl stuff here Fish, thanks for sharing