Archive for the ‘NHRP / DMVPN’ Category
When you starting talking about DMVPN you’ll typically hear it being described as a Phase I, II, or III type DMVPN network, so let’s quickly discuss the differences between these three DMVPN phases:
DMVPN Phase I: This phase involves configuring a single mGRE interface on the hub, and all the spokes are still static tunnels so you won’t get any dynamic spoke-to-spoke connectivity. The only advantage of the phase I setup is the fact the hub router’s configuration is much simpler.
DMVPN Phase II: This phase involves everysite being configured with mGRE interface so you get your dynamic spoke-to-spoke connectivity, no more static tunnel destination’s will be configured.
DMVPN Phase III: This phase expands on the scalability of the DMVPN network. This involve summarizing into the DMVPN cloud to provide (Remember EIGRP allows us to summarize out interfaces and BGP allows us to advertise aggregate addresses to neighbors). Along with configuring NHRP redirects and NHRP shortcut switching. NHRP redirects tells the source to find a better path to the destination it is trying to reach. NHRP shortcuts allow DMVPN to learn about other networks behind other DMVPN routers (kind of like ARP for DMVPN). However Phase III will get it’s own post later on.
Since I covered the basics of NHRP, now seems like the best time to tackle the configuration of DMVPN on Cisco IOS routers. I’m going simply build off of my last NHRP post, so we are going to have a single hub router and 2 spoke sites, we are going to adding encryption to our DMVPN using tunnel protection.
So lets first configure our IPSec parameters:
For a more in depth look at these commands refer to my older post Encrypted GRE tunnels.
Now that we have the IPSec parameters configured let’s go ahead and configure our tunnel interface for an encrypted DMVPN, so let’s start with the hub:
So there it is, the DMVPN hub, only a few these commands are typical of a normal GRE tunnel but most of them are specific to the DMVPN configuration. Let’s talk about a few these commands:
- ip nhrp authentication password: This command allows you to specify a password for your DMVPN network so not just any GRE tunnel can join your DMVPN cloud. (This is just one a few different mechanism to control who can participate within your DMVPN network)
- ip nhrp map multicast dynamic: This command allows NHRP to automatically map multicast traffic from other devices, without the need to statically configure each device. So this command is how our NHS builds its “nhrp database”
- ip nhrp network-id number: The NHRP network-id number ensures this DMVPN interface only participates within it’s own DMVPN network. Just in case you have more the one tunnel interface on the same router connected to two separate DMVPN clouds/networks.
- tunnel mode gre multipoint: This specifies the tunnel interface an GRE multipoint meaning this will be acting as single interfaces connected to multiple peers
- tunnel key number: This is another mechanism to keep your DMVPN network clean of any unwanted members, this is actually built into the GRE encapsulation itself, only GRE’s tunnels with the same tunnel key can communicate. So if the hub is using Tunnel key 10, then the spoke must use tunnel key 10 as well, if not then they will not be able to communicate.
Now let’s look at the spoke:
Now most of these commands are identical to that found on the hub, with the exception of the following:
- ip nhrp nhs 192.168.1.1: This commands specifies the Next Hop Server for the spoke
- ip nhrp map 192.168.1.1 10.1.1.1: This command maps the NHS GRE (protocol) address to it’s physical interface (NBMA) address.
- ip nhrp map multicast 10.1.1.1: This tells the NHC where to send its multicast traffic to.
And to reinforce that here is the configuration from the second spoke in this DMVPN network:
Identical to the first spoke (with the exception of the ip address).
So now that we have this configuration how do we verify our DMVPN is working, well let’s check our NHRP mappings along with our routing.
We issue the command sh ip nhrp this tells us we have NHRP mappings to both spokes 192.168.1.2 and 192.168.1.3.
Now let’s check the routing, I’ve configured these 3 routers to speak via eBGP:
So from this you’ll notice our hub has 2 eBGP adjacencies with our spokes, and we are are learning a few prefixes from those spokes.
But, now for the ultimate test, lets get spoke1 and spoke2 to create a direct tunnel between themselves.
From the top to bottom, you’ll notice Spoke2 only has NHRP mapping to the hub. I perform a traceroute to spoke1 and you see it bounce off the hub and then hit spoke1 I then perform the same traceroute a second later and it directly hits spoke1 bypassing the hub completely. Now when I issue the sh ip nhrp command you notice I still have my NHRP mapping to the hub at 192.168.1.1, but I also have a new NHRP mapping to spoke1 at 192.168.1.2. So our DMVPN is working successfully!
While this is a small victory, the topic of DMVPN is a fairly large one and we still have a few more topics to cover:
- How DMVPN interacts with IGPs. (Think about this one, some of the tools we rely on to prevent routing loops will be working against here)
- Different “phases” of DMVPN networks.
- Dual cloud DMVPN networks.
So stay tuned there is more to come!
DMVPN, a staple in any large scale VPN network, or a cheap internet backup solution for a primary MPLS network. We all know the great thing about DMVPN is the fact it creates a single mGRE tunnel interface in which multiple connections can be made to/from (trust me if you ever have to manage a router with 500+ GRE tunnels you will quickly learn to love DMVPN) and the fact that mGREs can create tunnels automatically between spokes putting less load on the hub router is another major advantage. It also increases network performance due the fact in a typical hub/spoke topology if two spokes need to communicate between themselves the hub router must decrypt the traffic from spoke1 and then encrypt it again to send it to spoke2, just for spoke2 to decrypt the data again when it receives the data (assuming you are running IPSec over your tunnels). So you have some double encryption/decryption/encapsulation going on there, not very optimal at all.
The question is how does DMVPN know how to create these tunnels, and what mechanism is it that allows DMVPN to create all these tunnels, well that would be NHRP Next Hop Resolution Protocol. NHRP works off a server/client relationship, where the NHRP clients (let’s call them next hop clients/NHCs) register with their next hop server (NHS), it’s the responsibility of the NHS to track all of its NHCs this is done with registration request and reply packets. When two spokes need to communicate between themselves the spokes send over a resolution request packet and the NHS responds with a resolution reply packet, with that information the spokes need to build a tunnel directly between themselves.
So let’s take a quick look at how process occurs between some Cisco routers:
Here is an overview of 2 NHC’s registering with their NHS:
Taking a closer look these NHRP packets they are comprised of a few different parts:
From top to bottom this packet starts off pretty normal, you see the normal L2/L3 information, and the GRE tunnel (since NHRP runs through a GRE tunnel) right after that we get to the NHRP portion of the packet. Now RFC 2332 defines these portions:
- Fixed Header – This portion is always the same, and just covers some basic information NHRP version, Ethertypes of the physical medium, address family information, and etc.
- Mandatory Part – This is where the NHRP packet type is defined (Registration request/reply, resolution request/reply, etc) and tunnel interface (Displayed as the protocol address) and physical interface (displayed as the NBMA address) IP addresses are contained.
- Client Information Entries CIE: Which contains specific information for clients such as MTU and hold down times.
Above is a quick screenshot of some of the NHRP packet types. You can the NHC at 10.1.3.1 attempts to register with 10.1.1.1 (the NHS) until the NHS sends its registration reply. Then you can see 10.1.3.1 sending a resolution request to the NHS, this represents the NHC at 10.1.3.1 attempting to reach the NHC at 10.1.2.1 after 10.1.3.1 receives its response from the NHS, 10.1.3.1 sends its it reply directly the NHC at 10.1.2.1. Clearing the NHRP cache on the Cisco router actually forces it to transmit a purge packets.
And now for a closer look:
The fixed header shown above, always includes the same information no matter which NHRP packet type is sent. Not too much to look at the NHRP version, address family, protocol type, and so forth.
The Mandatory Part of the header is what defines the NHRP packet type, this packet was the NHRP resolution request sent from the 10.1.3.1 (a NHC) to 10.1.1.1 (the NHS) when 192.168.1.3 attempted to ping 192.168.1.2 another NHC on the DMVPN network. Something I want to clarify here is the fact there are a lot of different IP addresses shown here. The Source NBMA address is the IP of the physical interface, the Source Protocol Address is the address of DMVPN tunnel on the NHC, and the Destination Protocol Address is the IP address of the DMVPN tunnel of the other NHC we are trying to reach. So NBMA Addresses are for physical interfaces and Protocol Addresses for the logical tunnels. After all that you’ll notice the Client Information Entry at the bottom. (Also keep in mind there are many other parts to the NHRP packet I did not show)
So there was a real quick and dirty run down on NHRP the protocol that makes DMVPN possible. It all really boils down to NHCs registering with the NHS, the NHS keeping all the NHC information in a cached local database, and the NHC’s asking for NHRP resolutions from the NHS when they want to spin up tunnels directly between NHCs. You can find a much more in depth discussion of NHRP in RFC 2332