DMVPN Explained

Published on December 2016 | Categories: Documents | Downloads: 28 | Comments: 0 | Views: 406
of 46
Download PDF   Embed   Report

Comments

Content

3/19/2014

DMVPN Explained

Blog Home | INE Home | Members | Contact Us | Subscribe

Free Resources View Archives All Access Pass CCIE Bloggers
Aug 02

DMVPN Explained
64 Comments Posted by Petr Lapukhov, 4xCCIE/CCDE in VPN

DMVPN stands for Dynamic Multipoint VPN and it is an effective solution for dynamic secure overlay networks. In short, DMVPN is combination of the following technologies: 1) Multipoint GRE (mGRE) 2) Next-Hop Resolution Protocol (NHRP) 4) Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP) 3) Dynamic IPsec encryption 5) Cisco Express Forwarding (CEF)

20
Tw eet

Assuming that reader has a general understanding of what DMVPN is and a solid understanding of IPsec/CEF, we are going to describe the role and function of each component in details. In this post we are going to illustrate two major phases of DMVPN evolution: 1) Phase 1 – Hub and Spoke (mGRE hub, p2p GRE spokes) 2) Phase 2 – Hub and Spoke with Spoke-to-Spoke tunnels (mGRE everywhere) As for DMVPN Phase 3 – “Scalable Infrastructure”, a separate post is required to cover the subject. This is due to the significant changes made to NHRP resolution logic (NHRP redirects and shortcuts), which are better being illustrated when a reader has good understanding of first two phases. However, some hints about Phase 3 will be also provided in this post. Note: Before we start, I would like to thank my friend Alexander Kitaev, for taking time to review the post and providing me with useful feedback. Multipoint GRE Let us start with the most basic building component of DMVPN – multipoint GRE tunnel. Classic GRE tunnel is point-to-point, but mGRE generalizes this idea by allowing a tunnel to have “multiple” destinations.
http://blog.ine.com/2008/08/02/dmvpn-explained/ 1/46

3/19/2014

DMVPN Explained

This may seem natural if the tunnel destination address is multicast (e.g. 239.1.1.1). The tunnel could be used to effectively distribute the same information (e.g. video stream) to multiple destinations on top of a multicast-enabled network. Actually, this is how mGRE is used for Multicast VPN implementation in Cisco IOS. However, if tunnel endpoints need to exchange unicast packets, special “glue” is needed to map tunnel IP addresses to “physical” or “real” IP addresses, used by endpoint routers. As we’ll see later, this glue is called NHRP.

Note, that if you source multiple mGRE tunnels off the same interface (e.g. Loopback0) of a single router, then GRE can use special “multiplexor” field the tunnel header to differentiate them. This field is known as “tunnel key” and you can define it under tunnel configuration. As a matter of fact, up to IOS 12.3(14)T or 12.3(11)T3 the use of “tunnel key” was mandatory – mGRE tunnel would not come up, until the key is configured. Since the mentioned versions, you may configure a tunnel without the key. There were two reasons to remove the requirement. First, hardware ASICs of 6500 and 7600 platforms do not support mGRE tunnel-key processing, and thus the optimal switching performance on those platforms is penalized when you configure the tunnel key. Second, as we’ll see later, DMVPN Phase 3 allows interoperation between different mGRE tunnels sharing the same NHRP network-id only when they have the same tunnelkey or have no tunnel-key at all (since this allows sending packets “between” tunnels). Generic NHRP Now let’s move to the component that makes DMVPN truly dynamic – NHRP. The protocol has been defined quite some time ago in RFC 2332 (year 1998) to create a routing optimization scheme inside NBMA (non-broadcast multiple-access) networks, such as ATM, Frame-Relay and SMDS (anybody remembers this one nowadays? The general idea was to use SVC (switched virtual circuits) to create temporary shortcuts in non-fully meshed NBMA cloud. Consider the following schematic illustration, where IP subnet 10.0.0.0/24 overlays partial-meshed NBMA cloud. NHRP is similar in function to ARP, allowing resolving L3 to L2 addresses, but does that in more efficient manner, suitable for partially meshed NBMA clouds supporting dynamic layer 2 connections.
http://blog.ine.com/2008/08/02/dmvpn-explained/ 2/46

3/19/2014

DMVPN Explained

The following is simplified and schematic illustration of NHRP process. In the above topology, in order for R1 to reach R4, it must send packets over PVCs between R1-R2, R2-R3 and finally R3-R4. Suppose the NMBA cloud allows using SVC (Switched virtual circuits, dynamic paths) – then it would be more reasonable for R1 to establish SVC directly with R4 and send packets over the optimal way. However, this requires R1 to know NMBA address (e.g. ATM NSAP) associated with R4 to “place a call”. Preferably, it would be better to make R1 learn R4 IP address to NSAP (NBMA address) mapping dynamically. Now assume we enable NHRP on all NBMA interfaces in the network. Each router in topology acts as either NHC (Next-Hop Client) or NHS (Next-Hop Server). One of the functions of NHC is to register with NHS its IP address mapped to NBMA Layer 2 address (e.g. ATM NSAP address). To make registration possible, you configure each NHC with the IP address of at least one NHS. In turn, NHS acts as a database agent, storing all registered mappings, and replying to NHC queries. If NHS does not have a requested entry in its database, it can forward packet to another NHS to see if it has the requested association. Note that a router may act as a Next-Hop server and client at the same time. Back to the diagram, assume that R2 and R3 are NHSes, R1 and R4 are NHCs. Further, assume R4 is NHC and registers its IP to NBMA address mapping with R4 and R1 thinks R2 is the NHS. Both R2 and R3 treat each other as NHS. When R1 wants to send traffic to R4 (next-hop 10.0.0.4), it tries to resolve 10.0.0.4 by sending NHRP resolution request to R2 – the configured NHS. In turn, R2 will forward request to R3, since it has no local information. Obviously, modern networks tend not to use ATM/SMDS and Frame-Relay SVC too much, but one can adopt NHRP to work with “simulated NBMA” networks, such as mGRE tunnels. The NBMA layer maps to “physical” underlying network while mGRE VPN is the “logical” network (tunnel internal IP addressing). In this case, mGRE uses NHRP for mapping “logical” or “tunnel inside” IP addresses to “physical” or real IP addresses. Effectively, NHRP perform the “glue” function described above, allowing mGRE endpoints discovering each other’s real IP address. Since NHRP defines a server role, it’s natural to have mGRE topology lay out in Hub-and-Spoke manner (or combination of hubs and spokes, in more advanced cases). Let’s see some particular scenarios to illustrate NHRP functionality with mGRE. NHRP Phase 1 With NHRP Phase 1 mGRE uses NHRP to inform the hub about dynamically appearing spokes. Initially, you configure every spoke with the IP address of the hub as the NHS server. However, the spoke’s tunnel mode is GRE (regular point-to-point) tunnel with a fixed destination IP that equals to the physical address of the hub. The spokes can only reach the hub and only get to other spoke networks across the hub. The benefit
http://blog.ine.com/2008/08/02/dmvpn-explained/ 3/46

3/19/2014

DMVPN Explained

of Phase 1 is simplified hub router configuration, which does not require static NHRP mapping for every new spoke.

As all packets go across the hub, almost any dynamic routing protocol would help with attaining reachability. The hub just needs to advertise a default route to spokes, while spokes should advertise their subnets dynamically to the hub. Probably it makes sense to run EIGRP and summarize all subnets to 0.0.0.0/0 on the hub, effectively sending a default route to all spokes (if the spokes do not use any other default route, e.g. from their ISPs). Configure spokes as EIGRP stubs and advertise their respective connected networks. RIP could be set up in similar manner, by simply configuring GRE tunnels on spokes as passive interfaces. Both EIGRP and RIP require split-horizon disabled on the hub mGRE interface in order to exchange subnets spoke to spoke. As for OSPF, the optimal choice would be using point-to-multipoint network type on all GRE and mGRE interfaces. In addition to that, configure ip ospf database filter-all out on the hub and set up static default routes via tunnel interfaces on the spokes (or static specific routes for corporate networks). Here is a sample configuration. The detailed explanation of NHRP commands and “show” commands output follows the example. mGRE + NHRP Phase 1 + EIGRP
R 1 : ! !H u br o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 ! !T u n n e ls o u r c e ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! !V P Nn e t w o r k ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! !m G R Et u n n e l !
http://blog.ine.com/2008/08/02/dmvpn-explained/ 4/46

3/19/2014

DMVPN Explained

i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 12 5 5 . 2 5 5 . 2 5 5 . 0 n oi pr e d i r e c t s i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s td y n a m i c i pn h r pn e t w o r k i d1 2 3 n oi ps p l i t h o r i z o ne i g r p1 2 3 i ps u m m a r y a d d r e s se i g r p1 2 30 . 0 . 0 . 00 . 0 . 0 . 05 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3 R 2 : ! !S p o k eR o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 e i g r ps t u bc o n n e c t e d ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! !G R Et u n n e l ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 22 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3 R 3 : ! !S p o k eR o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 e i g r ps t u bc o n n e c t e d ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 32 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0
http://blog.ine.com/2008/08/02/dmvpn-explained/ 5/46

3/19/2014

DMVPN Explained

t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3

Note that only the hub tunnel uses mGRE encapsulation, and spokes use regular point-to-point GRE tunnels. Now, let’s look at the NHRP commands used in the example above. The most basic command ip nhrp map [Logical IP] [NBMA IP] – creates a static binding between a logical IP address and NBMA IP address. Since mGRE is treated by NHRP as NMBA medium, logical IP corresponds to the IP address “inside” a tunnel (“inner”) and the NBMA IP address corresponds to the “outer” IP address (the IP address used to source a tunnel). (From now on, we are going to call “inner” IP address and simply “IP address” or “logical IP address” and the “outer” IP address as “NBMA address” or “physical IP address”). The use of static NHRP mappings is to “bootstrap” information for the spokes to reach the logical IP address of the hub. The next command is ip nhrp map multicast dynamic|[StaticIP] and its purpose is the same as “frame-relay map… broadcast”. The command specifies the list of destination that will receive the multicast/broadcast traffic originated from this router. Spokes map multicasts to the static NBMA IP address of the hub, but hub maps multicast packets to the “dynamic” mappings – that is, the hub replicates multicast packets to all spokes registered via NHRP. Mapping multicasts is important in order to make dynamic routing protocol establish adjacencies and exchange update packets. The ip nhrp nhs [ServerIP] command configures NHRP client with the IP address of its NHRP server. Note the “ServerIP” is the logical IP address of the hub (inside the tunnel) and therefore spokes need the static NHRP mappings in order to reach it. The spokes use the NHS to register their logical IP to NBMA IP associations and send NHRP resolution request. (However, in this particular scenarios, the spokes will not send any NHRP Resolutions Requests, since they use directed GRE tunnels – only registration requests will be sent). The commands ip nhrp network-id and ip nhrp authentication [Key] identify and authenticate the logical NHRP network. The [ID] and the [Key] must match on all routers sharing the same GRE tunnel. It is possible to split an NBMA medium into multiple NHRP networks, but this is for advanced scenarios. As for the authentication, it’s a simple plain-text key sent in all NHRP messages. While the “network-id” is mandatory in order for NHRP to work, you may omit the authentication. Next command is ip nhrp holdtime that specifies the holdtime value set in NHRP registration requests. The NHS will keep the registration request cached for the duration of the hold-time, and then, if no registration update is receive, will time it out. The NHS will also send the same hold-time in NHRP resolution responses, if queried for the respective NHRP association. Note that you configure the ip nhrp holdtime command on spokes, and spoke will send registration requests every 1/3 of the hold-time seconds. However, if you also configure the ip nhrp registration timeout [Timeout] on a spoke, the NHRP registration requests will be sent every [Timeout] sends, not 1/3 of the configured hold-time. The hold-time value sent in NHRP Registration Requests will remain the same, of course. Now let’s move to the show commands. Since it’s only the hub that uses the NHRP dynamic mappings to resolve the spokes NBMA addresses, it is useful to observe R1 NHRP cache:
R a c k 1 R 1 # s h o wi pn h r pd e t a i l 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 0 : 1 6 : 5 9 ,e x p i r e0 0 : 0 0 : 3 0 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e du s e d N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 0 : 1 1 : 3 4 ,e x p i r e0 0 : 0 0 : 5 5 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e du s e d N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3

As we can see, the logical IP “10.0.0.2” maps to NBMA address “150.1.2.2” and the logical IP 10.0.0.3 maps to NBMA address 150.1.3.3. The “authoritative” flag means that the NHS has learned about the NHRP mapping directly from a registration request (the NHS “serves” the particular NHC). The “unique” flag means that the NHRP registration request had the same “unique” flag set. The use of this flag is to prevent duplicate NHRP mappings in cache. If unique mapping for a particular logical IP is already in the NHRP cache and another NHC tries to register the same logical IP with the NHS, the server will reject the registration, until the unique entry expires. Note that by default IOS routers set this flag in registration
http://blog.ine.com/2008/08/02/dmvpn-explained/ 6/46

3/19/2014

DMVPN Explained

request, and this can be disabled by using ip nhrp registration no-unique command on a spoke. Sometimes this may be needed when spoke change its NBMA IP address often and needs to re-register a new mapping with the hub. The last flag, called “used” flag, means that the router uses the NHRP entry to switch IP packets. We will discuss the meaning of this flag in NRHP process switching section below. Also, note the “expires” field, which is a countdown timer, started from the “holdtime” specified in the Registration Request packet. Let’s see the NHRP registration and reply process flows on the NHS.
R a c k 1 R 1 # d e b u gn h r p N H R Pp r o t o c o ld e b u g g i n gi so n R a c k 1 R 1 # d e b u gn h r pp a c k e t N H R Pa c t i v i t yd e b u g g i n gi so n

First, R3 tries to register its Logical IP to NBMA IP mapping with the hub. Note the specific NHRP packet format, split in three parts. 1) (F) – fixed part. Specifies the version, address family (afn) and protocol type (type) for resolution, as well as subnetwork layer (NBMA) type and length (shtl and sstl). Note that “shtl” equals 4, which is the length of IPv4 address in bytes, and “sstl” is for “subaddress” field which is not used with IPv4. 2) (M) – mandatory header part. Specifies some flags, like “unique” flag and the “Request ID”, which is used to track request/responses. Also includes are the source NBMA address (tunnel source in GRE/mGRE) and the source/destination protocol IP addresses. Destination IP address is the logical IP address of the hub and the source IP address is the logical IP address of the spoke. Using this information hub may populate the spoke logical IP address to NBMA IP address mapping. 3) (C-1) – CIE 1, which stands for “Client Information Element” field. While it’s not used in the packets below, in more advanced scenarios explored later, we’ll see this filed containing the information about networks connected to requesting/responding routers. Also note the NAT-check output, which is Cisco’s extension used to make NHRP work for routers that tunnel from behind the NAT.
N H R P :R e c e i v eR e g i s t r a t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" u n i q u e " ,r e q i d :2 6 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 1 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 5 5 ,m t u :1 5 1 4 ,h d _ t i m e :6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=1 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 3 . 3 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 3 . 3 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 3 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 3 . 3

After processing the request, the router responds with NHRP Registration Reply. Note that the (M) header did not change, just the source and destination logical IP address of the packet are reversed. (R1->R3)
N H R P :S e n dR e g i s t r a t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 1 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 0 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" u n i q u e " ,r e q i d :2 6 s r cN B M A :1 5 0 . 1 . 3 . 3
http://blog.ine.com/2008/08/02/dmvpn-explained/ 7/46

3/19/2014

DMVPN Explained

s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 1 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 5 5 ,m t u :1 5 1 4 ,h d _ t i m e :6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :1 0 1b y t e so u tT u n n e l 0

Now the NHS receives the Registration Request from R2, and adds the corresponding entry in its NHRP cache
N H R P :R e c e i v eR e g i s t r a t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" u n i q u e " ,r e q i d :3 8 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 1 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 5 5 ,m t u :1 5 1 4 ,h d _ t i m e :6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=1 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 2 . 2 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 2 . 2 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 2 . 2 N H R P :S e n dR e g i s t r a t i o nR e p l yv i aT u n n e l 0 v r f0 ,p a c k e ts i z e :1 0 1 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 0 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" u n i q u e " ,r e q i d :3 8 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 1 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 5 5 ,m t u :1 5 1 4 ,h d _ t i m e :6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :1 0 1b y t e so u tT u n n e l 0

We see how NRHP Phase 1 works now. The spokes register their associations with the hub via NHRP and the hub learns their NBMA addresses dynamically. At the same time, spokes use point-to-point tunnels to speak to the hub and reach each other. Note that EIGRP is not the only protocol suitable for use with NHRP Phase 1. OSPF is also a viable solution, thank to point-to-multipoint network type and database filter-all out command. See the example below for OSPF configuration with NHRP Phase 1: mGRE + NHRP Phase 1 + OSPF
R 1 : ! !H u br o u t e r ! r o u t e ro s p f1 2 3 r o u t e r i d1 0 . 0 . 0 . 1 n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 12 5 5 . 2 5 5 . 2 5 5 . 0 n oi pr e d i r e c t s i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s td y n a m i c
http://blog.ine.com/2008/08/02/dmvpn-explained/ 8/46

3/19/2014

DMVPN Explained

i pn h r pn e t w o r k i d1 2 3 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t i po s p fd a t a b a s e f i l t e ra l lo u t R 2 : ! !S p o k eR o u t e r ! r o u t e ro s p f1 2 3 n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 r o u t e r i d1 0 . 0 . 0 . 2 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 22 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t ! i pr o u t e0 . 0 . 0 . 00 . 0 . 0 . 0T u n n e l 0 R 3 : ! !S p o k eR o u t e r ! r o u t e ro s p f1 2 3 n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 r o u t e r i d1 0 . 0 . 0 . 3 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 32 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t ! i pr o u t e0 . 0 . 0 . 00 . 0 . 0 . 0T u n n e l 0
http://blog.ine.com/2008/08/02/dmvpn-explained/ 9/46

3/19/2014

DMVPN Explained

As we said, the main benefit of using NHRP Phase 1 is simplified configuration on the hub router. Additionally, spoke routers receive minimal routing information (it’s either summarized or filtered on the hub) and are configured in uniform manner. In most simple case, spoke routers could be configured without any NHRP, by simply using point-to-point GRE tunnels. This scenario requires the hub to create a static NHRP mapping for every spoke. For example: mGRE + NHRP Phase 1 + OSPF + Static NHRP mappings
R 1 : ! !H u br o u t e r ! r o u t e ro s p f1 2 3 r o u t e r i d1 0 . 0 . 0 . 1 n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 12 5 5 . 2 5 5 . 2 5 5 . 0 n oi pr e d i r e c t s i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a p1 0 . 0 . 0 . 21 5 0 . 1 . 2 . 2 i pn h r pm a p1 0 . 0 . 0 . 31 5 0 . 1 . 3 . 3 i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 2 . 2 i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 3 . 3 i pn h r pn e t w o r k i d1 2 3 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t i po s p fd a t a b a s e f i l t e ra l lo u t R 2 : ! !S p o k eR o u t e r ! r o u t e ro s p f1 2 3 n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 r o u t e r i d1 0 . 0 . 0 . 2 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 22 5 5 . 2 5 5 . 2 5 5 . 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t ! i pr o u t e0 . 0 . 0 . 00 . 0 . 0 . 0T u n n e l 0 R 3 : ! !S p o k eR o u t e r ! r o u t e ro s p f1 2 3
http://blog.ine.com/2008/08/02/dmvpn-explained/ 10/46

3/19/2014

DMVPN Explained

n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5a r e a0 r o u t e r i d1 0 . 0 . 0 . 3 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 32 5 5 . 2 5 5 . 2 5 5 . 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e ld e s t i n a t i o n1 5 0 . 1 . 1 . 1 t u n n e lk e y1 2 3 i po s p fn e t w o r kp o i n t t o m u l t i p o i n t ! i pr o u t e0 . 0 . 0 . 00 . 0 . 0 . 0T u n n e l 0

The disadvantage of NHRP Phase 1 is the inability to establish spoke-to-spoke shortcut tunnels. NHRP Phase 2 resolves this issue and allows for spoke-to-spoke tunnels. To better understand the second phase, we first need to find out how NHRP interacts with CEF – the now default IP switching method on most Cisco routers. Consider the topology and example configuration that follows. See the detailed breakdown after the configuration. mGRE + NHRP Phase 2 + EIGRP

R 1 : ! !H u br o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 1 . 12 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 12 5 5 . 2 5 5 . 2 5 5 . 0 n oi pr e d i r e c t s
http://blog.ine.com/2008/08/02/dmvpn-explained/ 11/46

3/19/2014

DMVPN Explained

i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s td y n a m i c i pn h r pn e t w o r k i d1 2 3 n oi ps p l i t h o r i z o ne i g r p1 2 3 n oi pn e x t h o p s e l fe i g r p1 2 3 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3 R 2 : ! !S p o k eR o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 e i g r ps t u bc o n n e c t e d ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 2 . 22 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 22 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3 R 3 : ! !S p o k eR o u t e r ! r o u t e re i g r p1 2 3 n oa u t o s u m m a r y n e t w o r k1 0 . 0 . 0 . 00 . 2 5 5 . 2 5 5 . 2 5 5 e i g r ps t u bc o n n e c t e d ! i n t e r f a c eL o o p b a c k 0 i pa d d r e s s1 5 0 . 1 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eL o o p b a c k1 i pa d d r e s s1 0 . 0 . 3 . 32 5 5 . 2 5 5 . 2 5 5 . 0 ! i n t e r f a c eT u n n e l 0 i pa d d r e s s1 0 . 0 . 0 . 32 5 5 . 2 5 5 . 2 5 5 . 0 i pn h r pa u t h e n t i c a t i o nc i s c o i pn h r pm a pm u l t i c a s t1 5 0 . 1 . 1 . 1 i pn h r pm a p1 0 . 0 . 0 . 11 5 0 . 1 . 1 . 1 i pn h r pn h s1 0 . 0 . 0 . 1 i pn h r pn e t w o r k i d1 2 3 i pn h r pr e g i s t r a t i o nt i m e o u t3 0 i pn h r ph o l d t i m e6 0 t u n n e ls o u r c eL o o p b a c k 0 t u n n e lm o d eg r em u l t i p o i n t t u n n e lk e y1 2 3

Note that both spokes use mGRE tunnel encapsulation mode, and the hub sets the originating router nexthttp://blog.ine.com/2008/08/02/dmvpn-explained/ 12/46

3/19/2014

DMVPN Explained

hop IP address in “reflected” EIGRP updates (by default EIGRP sets the next-hop field to “0.0.0.0” – that is, to self). By the virtue of the EIGRP configuration, the subnet “10.0.2.0/24” (attached to R2) reaches to R3 with the next-hop IP address of “10.0.0.2” (R2). It is important that R3 learns “10.0.2.0/24” with the next hop of R2 logical IP address. As we see later, this is the key to trigger CEF next-hop resolution. The mGRE encapsulation used on spokes will trigger NHRP resolutions since now this is NBMA medium. Now, assuming that traffic to 10.0.2.0/24 does not flow yet, check the routing table entry for 10.0.2.2 and the CEF entries for the route and its next-hop:
R a c k 1 R 3 # s h o wi pr o u t e1 0 . 0 . 2 . 2 R o u t i n ge n t r yf o r1 0 . 0 . 2 . 0 / 2 4 K n o w nv i a" e i g r p1 2 3 " ,d i s t a n c e9 0 ,m e t r i c3 1 0 1 7 2 4 1 6 ,t y p ei n t e r n a l R e d i s t r i b u t i n gv i ae i g r p1 2 3 L a s tu p d a t ef r o m1 0 . 0 . 0 . 2o nT u n n e l 0 ,0 0 : 0 9 : 5 5a g o R o u t i n gD e s c r i p t o rB l o c k s : *1 0 . 0 . 0 . 2 ,f r o m1 0 . 0 . 0 . 1 ,0 0 : 0 9 : 5 5a g o ,v i aT u n n e l 0 R o u t em e t r i ci s3 1 0 1 7 2 4 1 6 ,t r a f f i cs h a r ec o u n ti s1 T o t a ld e l a yi s1 0 0 5 0 0 0m i c r o s e c o n d s ,m i n i m u mb a n d w i d t hi s9K b i t R e l i a b i l i t y2 5 5 / 2 5 5 ,m i n i m u mM T U1 4 7 2b y t e s L o a d i n g1 / 2 5 5 ,H o p s2 R a c k 1 R 3 # s h o wi pc e f1 0 . 0 . 2 . 2 1 0 . 0 . 2 . 0 / 2 4 ,v e r s i o n4 8 ,e p o c h0 0p a c k e t s ,0b y t e s v i a1 0 . 0 . 0 . 2 ,T u n n e l 0 ,0d e p e n d e n c i e s n e x th o p1 0 . 0 . 0 . 2 ,T u n n e l 0 i n v a l i da d j a c e n c y R a c k 1 R 3 # s h o wi pc e f1 0 . 0 . 0 . 2 1 0 . 0 . 0 . 0 / 2 4 ,v e r s i o n5 0 ,e p o c h0 ,a t t a c h e d ,c o n n e c t e d 0p a c k e t s ,0b y t e s v i aT u n n e l 0 ,0d e p e n d e n c i e s v a l i dg l e a na d j a c e n c y

Note that CEF prefix for “10.0.2.0/24” is invalid (but not “glean”), since “10.0.0.2” has not yet been resolved. The CEF prefix for “10.0.0.2” has “glean” adjacency, which means the router needs to send an NHRP resolution request to map the logical IP to NBMA address. Therefore, with CEF switching, NHRP resolution requests are only sent for “next-hop” IP addresses, and never for the networks (e.g. 10.0.2.0/24) themselves (the process-switching does resolve any prefix as we’ll see later). Go ahead and ping from R3 to “10.0.3.3” and observe the process:
R a c k 1 R 3 # p i n g1 0 . 0 . 2 . 2 T y p ee s c a p es e q u e n c et oa b o r t . S e n d i n g5 ,1 0 0 b y t eI C M PE c h o st o1 0 . 0 . 2 . 2 ,t i m e o u ti s2s e c o n d s : ! ! ! ! ! S u c c e s sr a t ei s1 0 0p e r c e n t( 5 / 5 ) ,r o u n d t r i pm i n / a v g / m a x=3 6 / 8 0 / 1 8 0m s

Check the mappings on the hub router. The only two entries registered are the VPN IP addresses of R2 and R3, together with the respective NBMA IP addresses. Note the “expire” field, which, as mentioned above, counts the time for the entry to expire based on the “holdtime” settings of the registering router’s interface. Later we will see how CEF uses this countdown timer to refresh or delete CEF entries for the next-hop IP address
R a c k 1 R 1 # s h o wi pn h r p 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 0 : 1 6 : 3 3 ,e x p i r e0 0 : 0 0 : 4 3 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e d N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 R e q u e s t e r :1 0 . 0 . 0 . 3R e q u e s tI D :7 9 8 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 0 : 1 6 : 3 4 ,e x p i r e0 0 : 0 0 : 5 1 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e d N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3
http://blog.ine.com/2008/08/02/dmvpn-explained/ 13/46

3/19/2014

DMVPN Explained

R e q u e s t e r :1 0 . 0 . 0 . 2R e q u e s tI D :8 1 3 C h e c kt h em a p p i n g so nR 2( n o t et h a tR 2n o wh a sm a p p i n gf o rR 3 ’ s n e x t h o pa s s o c i a t e dw i t hi t sN B M AI Pa d d r e s s ) R a c k 1 R 2 # s h o wi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 0 : 1 4 : 5 2 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 5 : 4 9 ,e x p i r e0 0 : 0 0 : 1 0 T y p e :d y n a m i c ,F l a g s :r o u t e ra u t h o r i t a t i v eu n i q u el o c a l N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 ( n o s o c k e t ) 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 3 0 ,e x p i r e0 0 : 0 0 : 2 9 T y p e :d y n a m i c ,F l a g s :r o u t e ru s e d N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 T h es a m ec o m m a n do u t p u to nR 3i ss y m m e t r i ct ot h eo u t p u to nR 2 : R a c k 1 R 3 # s h o wi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 0 : 1 4 : 0 0 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 0 5 ,e x p i r e0 0 : 0 0 : 5 4 T y p e :d y n a m i c ,F l a g s :r o u t e r N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 0 : 0 1 : 4 6 ,e x p i r e0 0 : 0 0 : 1 3 T y p e :d y n a m i c ,F l a g s :r o u t e ra u t h o r i t a t i v eu n i q u el o c a l N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 ( n o s o c k e t )

Now check the CEF entry for R2’s next-hop IP address on R3:
R a c k 1 R 3 # s hi pc e f1 0 . 0 . 0 . 2 1 0 . 0 . 0 . 2 / 3 2 ,v e r s i o n6 5 ,e p o c h0 ,c o n n e c t e d 0p a c k e t s ,0b y t e s v i a1 0 . 0 . 0 . 2 ,T u n n e l 0 ,0d e p e n d e n c i e s n e x th o p1 0 . 0 . 0 . 2 ,T u n n e l 0 v a l i da d j a c e n c y

The CEF entry for “10.0.0.2” is now valid, since NHRP mapping entry is present. If the next-hop for the prefix “10.0.2.0/24” was pointing toward the hub (R1) (e.g. if the hub was using the default ip next-hop-self eigrp 123) then the NHRP lookup will not be triggered, and cut-through NHRP entry will not be installed. Let’s see the debugging command output on R1, R2 and R3 to observe how the routers collectively resolve the next-hop IP addresses when R3 pings R1:
R a c k 1 R 1 # d e b u gn h r p N H R Pp r o t o c o ld e b u g g i n gi so n R a c k 1 R 1 # d e b u gn h r pp a c k e t N H R Pa c t i v i t yd e b u g g i n gi so n R a c k 1 R 2 # d e b u gn h r p N H R Pp r o t o c o ld e b u g g i n gi so n R a c k 1 R 2 # d e b u gn h r pp a c k e t N H R Pa c t i v i t yd e b u g g i n gi so n R a c k 1 R 3 # d e b u gn h r p N H R Pp r o t o c o ld e b u g g i n gi so n R a c k 1 R 3 # d e b u gn h r pp a c k e t N H R Pa c t i v i t yd e b u g g i n gi so n

It all starts when R3 tries to route a packet to “10.0.2.2” and finds out it has “glean” adjacency for its nexthop of “10.0.0.2”. Then, R3 attempt to send NHRP resolution request directly to R2, but fails since R2
http://blog.ine.com/2008/08/02/dmvpn-explained/ 14/46

3/19/2014

DMVPN Explained

NMBA address is unknown. At the same time, the original data packet (ICMP echo) follows to R2 across the hub (R1).
R a c k 1 R 3 # N H R P :M A C A D D R :i f _ i nn u l ln e t i d i n0i f _ o u tT u n n e l 0n e t i d o u t1 2 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 0 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :S e n d i n gp a c k e tt oN H S1 0 . 0 . 0 . 1o nT u n n e l 0 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 0 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 2 N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 3 ,d s t :1 0 . 0 . 0 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 9 4 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :E n c a p s u l a t i o nf a i l e df o rd e s t i n a t i o n1 0 . 0 . 0 . 2o u tT u n n e l 0

Next, R3 tries to send resolution request to the NHS, which is R1. The resolution request contains information about source NBMA address of R3, and source protocol (logical IP) addresses of R3 and R2.
R a c k 1 R 3 # N H R P :A t t e m p t i n gt os e n dp a c k e tv i aN H S1 0 . 0 . 0 . 1 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 1 . 1 N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 3 ,d s t :1 0 . 0 . 0 . 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 9 4 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :8 1b y t e so u tT u n n e l 0

The Resolution Request from R3 arrives to NHS. In essence, R3 tries to resolve the “glean” CEF adjacency using NHRP the same way it uses ARP on Ethernet. Note that request only mentions logical IP addresses of R3 (“10.0.0.3”) and R2 (“10.0.0.2”) and NBMA address of R3.
R a c k 1 R 1 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 9 4 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 3 . 3 N H R P :n h r p _ r t l o o k u py i e l d e dT u n n e l 0 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 3 . 3 N H R P :n e t i d _ o u t1 2 3 ,n e t i d _ i n1 2 3 N H R P :n h r p _ c a c h e _ l o o k u p _ c o m pr e t u r n e d0 x 8 5 5 C 7 B 9 0 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 3 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 3 . 3
http://blog.ine.com/2008/08/02/dmvpn-explained/ 15/46

3/19/2014

DMVPN Explained

The NHS has the NHRP mapping for “10.0.0.2” in its NHRP cache – R2 registered this associating with R1. The NHS may immediately reply to the client. Note the “(C-1)” – CIE header in the NHRP reply packet. While the “(M)” (mandatory) header contains the same information received in request packet from R3, the CIE header contains the actual NHRP reply, with the mapping information for R2. This is because the NHS considers R2 to be the “client” of it, and therefore it sends the actual information in CIE header. Note the “prefix” length of 32 – this means the reply is just for one host logical IP address.
R a c k 1 R 1 # N H R P :S e n dR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 9 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 0 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 9 4 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :3 2 ,m t u :1 5 1 4 ,h d _ t i m e :3 4 2 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 2 . 2 c l i e n tp r o t o c o l :1 0 . 0 . 0 . 2 N H R P :1 0 9b y t e so u tT u n n e l 0

At this point, R2 receives the original data packet from R3 (ICMP echo) and tries to send a response back. The problem is that the destination IP address for the echo reply is “10.0.3.3” and the next-hop is “10.0.0.3”, which has “glean” CEF adjacency. Again, R2 replies back across the hub and send a Resolution Request packet: first, directly R3 – this attempt fails – then it sends the resolution request to the NHS.
R a c k 1 R 2 # N H R P :M A C A D D R :i f _ i nn u l ln e t i d i n0i f _ o u tT u n n e l 0n e t i d o u t1 2 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 0 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :S e n d i n gp a c k e tt oN H S1 0 . 0 . 0 . 1o nT u n n e l 0 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 0 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 3 N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 2 ,d s t :1 0 . 0 . 0 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :1 0 1 2 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :E n c a p s u l a t i o nf a i l e df o rd e s t i n a t i o n1 0 . 0 . 0 . 3o u tT u n n e l 0 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aN H S1 0 . 0 . 0 . 1 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 1 . 1 R a c k 1 R 2 # N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 2 ,d s t :1 0 . 0 . 0 . 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :1 0 1 2 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :8 1b y t e so u tT u n n e l 0 N H R P :M A C A D D R :i f _ i nn u l ln e t i d i n0i f _ o u tT u n n e l 0n e t i d o u t1 2 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 0 . 3o nl i s t( T u n n e l 0 ) .
http://blog.ine.com/2008/08/02/dmvpn-explained/ 16/46

3/19/2014

DMVPN Explained

N H R P :N on o d ef o u n d . N H R P :S e n d i n gp a c k e tt oN H S1 0 . 0 . 0 . 1o nT u n n e l 0

R3 finally receive the Resolution Reply from the NHS, and now it may complete the CEF adjacency for “10.0.0.2”. Since that moment, it switches all packets to “10.0.2.2” directly via R2, not across R1.
R a c k 1 R 3 # N H R P :R e c e i v eR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 9 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 9 4 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :3 2 ,m t u :1 5 1 4 ,h d _ t i m e :3 4 2 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 2 . 2 c l i e n tp r o t o c o l :1 0 . 0 . 0 . 2 N H R P :n e t i d _ i n=0 ,t o _ u s=1 N H R P :C h e c k i n gf o rd e l a y e de v e n t1 5 0 . 1 . 2 . 2 / 1 0 . 0 . 0 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :N on e e dt od e l a yp r o c e s s i n go fr e s o l u t i o ne v e n tn b m as r c : 1 5 0 . 1 . 3 . 3n b m ad s t : 1 5 0 . 1 . 2 . 2

The resolution request that R2 sent before in attempted to resolve the NBMA address for “10.0.0.3” arrives to R1. Since the NHS has all the information in its local cache (R3 registered its IP to NBMA address mapping) it immediately replies to R2. Note the CIE header in the NHRP reply packet, which contains the actual mapping information.
R a c k 1 R 1 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :1 0 1 2 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 2 . 2 N H R P :n h r p _ r t l o o k u py i e l d e dT u n n e l 0 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 2 . 2 N H R P :n e t i d _ o u t1 2 3 ,n e t i d _ i n1 2 3 N H R P :n h r p _ c a c h e _ l o o k u p _ c o m pr e t u r n e d0 x 8 4 8 E F 9 E 8 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 2 . 2 R a c k 1 R 1 # N H R P :S e n dR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 9 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 0 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :1 0 1 2 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :3 2 ,m t u :1 5 1 4 ,h d _ t i m e :2 4 2 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 3 . 3 b c l i e n tp r o t o c o l :1 0 . 0 . 0 . 3 N H R P :1 0 9b y t e so u tT u n n e l 0

At last, R2 receive the reply to its original request, and now it has all the information to complete the CEF
http://blog.ine.com/2008/08/02/dmvpn-explained/ 17/46

3/19/2014

DMVPN Explained

entry for “10.0.0.3” and switch packets across the optimal path to R3. At this moment both spokes have symmetric information to reach each other
R a c k 1 R 2 # N H R P :R e c e i v eR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 9 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :1 0 1 2 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 0 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :3 2 ,m t u :1 5 1 4 ,h d _ t i m e :2 4 2 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 3 . 3 c l i e n tp r o t o c o l :1 0 . 0 . 0 . 3 N H R P :n e t i d _ i n=0 ,t o _ u s=1 N H R P :C h e c k i n gf o rd e l a y e de v e n t1 5 0 . 1 . 3 . 3 / 1 0 . 0 . 0 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :N on e e dt od e l a yp r o c e s s i n go fr e s o l u t i o ne v e n tn b m as r c : 1 5 0 . 1 . 2 . 2n b m ad s t : 1 5 0 . 1 . 3 . 3

Timing out NHRP entries Now that we know that CEF resolves the next-hop information via NHRP, how does it time-out the unused cut-through tunnel? As we remember, each NHRP entry has countdown expire timer, initialized from the registration hold-time. Every 60 seconds global NHRP process runs on a router and checks the expire timer on all NHRP entries. If the expire timer for an NHRP entry is greater than 120 seconds, nothing is done to the corresponding CEF entry. If the timer is less than 120 seconds, the NHRP process marks the corresponding CEF entry as “stale” but still usable. As soon as the router switches an IP packet using the “stale” entry, it triggers new NHRP resolution request, and eventually refreshes the corresponding NHRP entry as well as CEF entry itself. If no packet hits the “stale” CEF entry, the NHRP mapping will eventually time-out (since the router does not send any “refreshing” requests) and the corresponding CEF entry will become invalid. This will effectively tear down the spoke-to-spoke tunnel. NHRP Phase 2 Conclusions Let us quickly recap what we learned so far about NHRP Phase 2 and CEF. Firstly, this mode requires all the spokes to have complete routing information with the next-hop preserved. This may limit scalability in large networks, since not all spokes may accept full load of routing updates. Secondly, CEF only resolve the next-hop information via NHRP, not the full routing prefixes. Actually, the second feature directly implies the first limitation. As we noted, the no ip next-hop-self eigrp 123 command is required to make spoke-tospoke tunnels work with CEF. However, they added the command only in IOS version 12.3. Is there a way to make spoke-to-spoke tunnels work when the next-hop is set to “self” (the default) in EIGRP updates? Actually, there are few ways. First and the best one – do not use old IOS images to implement DMVPN Actually, it is better to use the latest 12.4T train images with DMVPN Phase 3 for the deployment – but then again those images are from the “T”-train! OK, so the other option is get rid of EIGRP and use OSPF, with the network type “broadcast”. OSPF is a link-state protocol – it does not hide topology information and does not mask the next-hop in any way (well, at least when the network-type is “broadcast”). However, the limitation is that the corresponding OSPF topology may have just two redundant hubs – corresponding to OSPF DR and BDR for a segment. This is because every hub must form OSPF adjacencies with all spokes. Such limitation is not acceptable in large installations, but still works fine in smaller deployments. However, there is one final workaround, which is probably the one you may want to use in the current CCIE lab exam – disable CEF on spokes. This is a very interesting case per se, and we are going to see now NHRP works with process switching. NHRP Phase 2 + EIGRP next-hop-self + no CEF In this scenario, EIGRP next-hop self is enabled on R1 (the hub). Now R3 sees 10.0.2.0/24 with the next
http://blog.ine.com/2008/08/02/dmvpn-explained/ 18/46

3/19/2014

DMVPN Explained

hop of R1. Disable CEF on R2 and R3, and try pinging 10.0.2.2 off R3 loopback1 interface.
R 3s e e st h er o u t eb e h i n dR 2a sr e a c h a b l ev i aR 1 R a c k 1 R 3 # s h o wi pr o u t e1 0 . 0 . 2 . 2 R o u t i n ge n t r yf o r1 0 . 0 . 2 . 0 / 2 4 K n o w nv i a" e i g r p1 2 3 " ,d i s t a n c e9 0 ,m e t r i c3 1 0 1 7 2 4 1 6 ,t y p ei n t e r n a l R e d i s t r i b u t i n gv i ae i g r p1 2 3 L a s tu p d a t ef r o m1 0 . 0 . 0 . 1o nT u n n e l 0 ,0 0 : 0 9 : 5 5a g o R o u t i n gD e s c r i p t o rB l o c k s : *1 0 . 0 . 0 . 1 ,f r o m1 0 . 0 . 0 . 1 ,0 0 : 0 9 : 5 5a g o ,v i aT u n n e l 0 R o u t em e t r i ci s3 1 0 1 7 2 4 1 6 ,t r a f f i cs h a r ec o u n ti s1 T o t a ld e l a yi s1 0 0 5 0 0 0m i c r o s e c o n d s ,m i n i m u mb a n d w i d t hi s9K b i t R e l i a b i l i t y2 5 5 / 2 5 5 ,m i n i m u mM T U1 4 7 2b y t e s L o a d i n g1 / 2 5 5 ,H o p s2

R3 pings “10.0.2.2”, sourcing packet off “10.0.3.3”. Since CEF is disabled, the system performs NHRP lookup to find the NBMA address for “10.0.2.2”. This is opposed to CEF behavior that would only resolve the next-hop for “10.0.2.2″ entry. Naturally, the router forwards NHRP request to R3’s NHS, which is R1. At the same time, R3 forwards the data packet (ICMP echo) via its current next-hop – “10.0.0.1”, that is via the hub.
R a c k 1 R 3 # N H R P :M A C A D D R :i f _ i nn u l ln e t i d i n0i f _ o u tT u n n e l 0n e t i d o u t1 2 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 2 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :S e n d i n gp a c k e tt oN H S1 0 . 0 . 0 . 1o nT u n n e l 0 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 2 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 2 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 1 . 1 N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 3 ,d s t :1 0 . 0 . 2 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 0 0 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :8 1b y t e so u tT u n n e l 0 N H R P :M A C A D D R :i f _ i nn u l ln e t i d i n0i f _ o u tT u n n e l 0n e t i d o u t1 2 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 2 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :S e n d i n gp a c k e tt oN H S1 0 . 0 . 0 . 1o nT u n n e l 0

Resolution Request arrives to R1 (the NHS). Since R1 has no mapping for “10.0.2.2” (R2 only registers the IP address 10.0.0.2 – its own next-hop IP address), the NHS looks up into routing table, to find the next-hop towards 10.0.2.2. Since it happens to be R2’s IP “10.0.0.2”, the NHS then tries to forward the resolution request towards the next router on the path to the network requested in resolution message – to R2. Thanks to R2’s NHRP registration with R1, the NHS now knows R2’s NBMA address, and successfully encapsulates the packet. In addition, R1 forwards the data packet from R1 to R2, using its routing table. Obviously, the data packet will arrive to R2 a little bit faster, since NHRP requires more time to process and forward the request.
R a c k 1 R 1 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 0 0
http://blog.ine.com/2008/08/02/dmvpn-explained/ 19/46

3/19/2014

DMVPN Explained

s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 3 . 3 N H R P :n h r p _ r t l o o k u py i e l d e dT u n n e l 0 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 3 . 3 N H R P :n e t i d _ o u t1 2 3 ,n e t i d _ i n1 2 3 N H R P :n h r p _ c a c h e _ l o o k u p _ c o m pr e t u r n e d0 x 0 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 2 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 2 . 2 N H R P :F o r w a r d i n gR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 1 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 2 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 4 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 0 0 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :1 0 1b y t e so u tT u n n e l 0

Now the data packet (ICMP echo) has arrived to R2. R2 generates the response (ICMP – echo reply from “10.0.2.2” to “10.0.3.3”) and now R2 needs the NMBA address of “10.0.3.3” (CEF is disabled on R2). As usual, R2 generates a resolutions request to its NHS (R1). At the same time, R2 sends the response packet to R3’s request across the hub, since it does not know the NBMA address of R3.
R a c k 1 R 2 # N H R P :S e n dR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 s r c :1 0 . 0 . 0 . 2 ,d s t :1 0 . 0 . 3 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :8 1b y t e so u tT u n n e l 0

Soon after the data packet arrived, R2 receives the Resolution Request from R3 forwarded by R1. Since R2 is the egress router on NBMA segment for the network “10.0.2.2”, it may reply to the request.
R a c k 1 R 2 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 4 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 0 0 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :n h r p _ r t l o o k u py i e l d e dL o o p b a c k 1 N H R P :n e t i d _ o u t0 ,n e t i d _ i n1 2 3 N H R P :W ea r ee g r e s sr o u t e rf o rt a r g e t1 0 . 0 . 2 . 2 ,r e c e v i e dv i aT u n n e l 0 N H R P :R e d i s tm a s kn o w1 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 3 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 3 . 3
http://blog.ine.com/2008/08/02/dmvpn-explained/ 20/46

3/19/2014

DMVPN Explained

Note that R2 replies with the full prefix found in its routing table – “10.0.2.0/24”, not just single host “10.0.2.2/32” (this feature is critical for DMVPN Phase 3). This information is encapsulated inside “(C-1)” part of the NHRP reply packet (Client Information Element 1) which describes a client – network connected to the router (R2). The “prefix” field is “/24” which is exactly the value taken from the routing table. Also note, that R2 learned R3’s NBMA address from the Resolution Request, and now replies directly to R3, bypassing R1. The “stable” flag means that the querying/replying router directly knows the source or destination IP address in the resolution request/reply.
R a c k 1 R 2 # N H R P :S e n dR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 2 9 s r c :1 0 . 0 . 0 . 2 ,d s t :1 0 . 0 . 0 . 3 < -N B M Aa d d r e s s e so fR 2 / R 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 0 0 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 4 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 2 . 2 c l i e n tp r o t o c o l :1 0 . 0 . 2 . 2 N H R P :1 2 9b y t e so u tT u n n e l 0

At this moment, Resolution Request from R2 for network “10.0.3.3″ reaches R1 – the NHS. Since the NHS has no information on “10.0.3.3″, it forwards the request to R3 – the next-hop found via the routing table on path to “10.0.3.3″.
R a c k 1 R 1 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :8 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 2 . 2 N H R P :n h r p _ r t l o o k u py i e l d e dT u n n e l 0 N H R P :T u 0 :F o u n da n ds k i p p i n gd y n a m i cm u l t i c a s tm a p p i n g N B M A :1 5 0 . 1 . 2 . 2 N H R P :n e t i d _ o u t1 2 3 ,n e t i d _ i n1 2 3 N H R P :n h r p _ c a c h e _ l o o k u p _ c o m pr e t u r n e d0 x 0 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 3 . 3 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 3 . 3 N H R P :F o r w a r d i n gR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 1 s r c :1 0 . 0 . 0 . 1 ,d s t :1 0 . 0 . 3 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 4 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :1 0 1b y t e so u tT u n n e l 0

Back to R3. At this point, it received the ICMP reply for the original ICMP echo packet. Now R3 receives the NHRP Resolution Reply to its original Resolution Request directly from R2. This allows R3 to learn that “10.0.2.0/24” is reachable via NMBA IP address “150.1.2.2”. Note that CIE field “(C-1)” in the reply packet,
http://blog.ine.com/2008/08/02/dmvpn-explained/ 21/46

3/19/2014

DMVPN Explained

which tells R3 about the whole “10.0.2.0/24” network – the “prefix” is set to “24”.
R a c k 1 R 3 # N H R P :R e c e i v eR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 2 9 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 0 0 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 2 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 4 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 2 . 2 c l i e n tp r o t o c o l :1 0 . 0 . 2 . 2 N H R P :n e t i d _ i n=0 ,t o _ u s=1 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 2 . 2 N H R P :C h e c k i n gf o rd e l a y e de v e n t1 5 0 . 1 . 2 . 2 / 1 0 . 0 . 2 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :N on e e dt od e l a yp r o c e s s i n go fr e s o l u t i o ne v e n tn b m as r c : 1 5 0 . 1 . 3 . 3n b m ad s t : 1 5 0 . 1 . 2 . 2 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 2 . 2o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d .

Finally, the Resolution Request from R2, forwarded by R1 (the NHS) arrives to R3. The local router performs lookup for 10.0.3.3 and finds this to be directly connected network, with the prefix of /24. Therefore, R3 generates a Resolution Reply packet and sends it directly to R2, bypassing R1. This packet tells R2 to map logical IP “10.0.3.0/24” to NBMA address “150.1.3.3”.
R a c k 1 R 3 # N H R P :R e c e i v eR e s o l u t i o nR e q u e s tv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 0 1 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 4 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hs r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :0 ,p r e f :0 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=0 N H R P :n h r p _ r t l o o k u py i e l d e dL o o p b a c k 1 N H R P :n e t i d _ o u t0 ,n e t i d _ i n1 2 3 N H R P :W ea r ee g r e s sr o u t e rf o rt a r g e t1 0 . 0 . 3 . 3 ,r e c e v i e dv i aT u n n e l 0 N H R P :R e d i s tm a s kn o w1 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 2 . 2 N H R P :S e n dR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 2 9 s r c :1 0 . 0 . 0 . 3 ,d s t :1 0 . 0 . 0 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 4 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 3 . 3 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :1 2 9b y t e so u tT u n n e l 0

At last, R2 receives the response to its Resolution Request, and everything is stable now. R2 and R3 know how to reach “10.0.3.0/24” and “10.0.2.0/24” respectively.
R a c k 1 R 2 # N H R P :R e c e i v eR e s o l u t i o nR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :1 2 9
http://blog.ine.com/2008/08/02/dmvpn-explained/ 22/46

3/19/2014

DMVPN Explained

( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r o u t e ra u t hd s t s t a b l eu n i q u es r c s t a b l e " ,r e q i d :9 1 9 s r cN B M A :1 5 0 . 1 . 2 . 2 s r cp r o t o c o l :1 0 . 0 . 0 . 2 ,d s tp r o t o c o l :1 0 . 0 . 3 . 3 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :2 4 ,m t u :1 5 1 4 ,h d _ t i m e :3 6 0 a d d r _ l e n :4 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tN B M A :1 5 0 . 1 . 3 . 3 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :n e t i d _ i n=0 ,t o _ u s=1 N H R P :N A T c h e c k :m a t c h e dd e s t i n a t i o na d d r e s s1 5 0 . 1 . 3 . 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t1 5 0 . 1 . 3 . 3 / 1 0 . 0 . 3 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :N on e e dt od e l a yp r o c e s s i n go fr e s o l u t i o ne v e n tn b m as r c : 1 5 0 . 1 . 2 . 2n b m ad s t : 1 5 0 . 1 . 3 . 3 N H R P :C h e c k i n gf o rd e l a y e de v e n t0 . 0 . 0 . 0 / 1 0 . 0 . 3 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d .

Now let’s look at NHRP caches of all three routers:
R a c k 1 R 1 # s h o wi pn h r p 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 1 : 0 0 : 4 7 ,e x p i r e0 0 : 0 4 : 0 2 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e d N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 1 : 0 0 : 4 7 ,e x p i r e0 0 : 0 4 : 2 3 T y p e :d y n a m i c ,F l a g s :a u t h o r i t a t i v eu n i q u er e g i s t e r e d N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 R a c k 1 R 2 # s h o wi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 1 : 5 6 : 3 0 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 1 0 . 0 . 0 . 3 / 3 2v i a1 0 . 0 . 0 . 3 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 2 4 ,e x p i r e0 0 : 0 5 : 3 5 T y p e :d y n a m i c ,F l a g s :r o u t e ri m p l i c i t N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 1 0 . 0 . 2 . 0 / 2 4v i a1 0 . 0 . 2 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 2 4 ,e x p i r e0 0 : 0 5 : 3 5 T y p e :d y n a m i c ,F l a g s :r o u t e ra u t h o r i t a t i v eu n i q u el o c a l N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 ( n o s o c k e t ) 1 0 . 0 . 3 . 0 / 2 4v i a1 0 . 0 . 3 . 3 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 2 4 ,e x p i r e0 0 : 0 5 : 3 5 T y p e :d y n a m i c ,F l a g s :r o u t e r N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 R a c k 1 R 3 # s h o wi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 1 : 5 6 : 0 0 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 1 0 . 0 . 0 . 2 / 3 2v i a1 0 . 0 . 0 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 0 2 ,e x p i r e0 0 : 0 5 : 5 7 T y p e :d y n a m i c ,F l a g s :r o u t e ri m p l i c i tu s e d N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 1 0 . 0 . 2 . 0 / 2 4v i a1 0 . 0 . 2 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 0 2 ,e x p i r e0 0 : 0 5 : 5 7 T y p e :d y n a m i c ,F l a g s :r o u t e ru s e d N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2 1 0 . 0 . 3 . 0 / 2 4v i a1 0 . 0 . 3 . 3 ,T u n n e l 0c r e a t e d0 0 : 0 0 : 0 2 ,e x p i r e0 0 : 0 5 : 5 7 T y p e :d y n a m i c ,F l a g s :r o u t e ra u t h o r i t a t i v eu n i q u el o c a l N B M Aa d d r e s s :1 5 0 . 1 . 3 . 3 ( n o s o c k e t )

The “implicit” flag means that the router learned mapping without explicit request, as a part of other router’s reply or request. The “router” flag means that the mapping is either for the remote router or for a network behind the router. The “(no-socket)” flag means that the local router will not use this entry and trigger IPSec socket creation. The “local” flag means the mapping is for the network directly connected to the local router. The router uses those mappings when it loses connection to the local network, so that the NHC may send a purge request to all other clients, telling that the network has gone and they must remove their mappings.
http://blog.ine.com/2008/08/02/dmvpn-explained/ 23/46

3/19/2014

DMVPN Explained

Here is an example. Ensure R3 has the above-mentioned mappings, and then shut down the Loopback1 interface, observing the debugging command output on R3 and R2. R3 sends purge request directly to R2, since it knows R2 requested that mapping.
R a c k 1 R 3 # N H R P :R e d i s tc a l l b a c k :1 0 . 0 . 3 . 0 / 2 4 N H R P :I n v a l i d a t i n gm a pt a b l e sf o rp r e f i x1 0 . 0 . 3 . 0 / 2 4v i aT u n n e l 0 N H R P :C h e c k i n gf o rd e l a y e de v e n t1 5 0 . 1 . 3 . 3 / 1 0 . 0 . 3 . 3o nl i s t( T u n n e l 0 ) . N H R P :N on o d ef o u n d . N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 2 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 2 . 2 N H R P :S e n dP u r g eR e q u e s tv i aT u n n e l 0 v r f0 ,p a c k e ts i z e :7 3 s r c :1 0 . 0 . 0 . 3 ,d s t :1 0 . 0 . 0 . 2 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r e p l yr e q u i r e d " ,r e q i d :3 6 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :7 3b y t e so u tT u n n e l 0

R2 receives Purge Request from R3. Note that the “reply required” flag is set. Hence, R2 must confirm that it deleted the mapping with a Purge Reply packet. R2 will erase the corresponding mapping learned via “10.0.0.3” and generate a response packet
R a c k 1 R 2 # N H R P :R e c e i v eP u r g eR e q u e s tv i aT u n n e l 0 v r f0 ,p a c k e ts i z e :7 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r e p l yr e q u i r e d " ,r e q i d :3 6 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :n e t i d _ i n=1 2 3 ,t o _ u s=1 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 3 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 3 . 3

R2 first tries to send the Purge Reply to R3 directly, using the NBMA address of R3. Note that CIE header mentions the network erased from the local mappings list
R a c k 1 R 2 # N H R P :S e n dP u r g eR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :7 3 s r c :1 0 . 0 . 0 . 2 ,d s t :1 0 . 0 . 0 . 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r e p l yr e q u i r e d " ,r e q i d :3 6 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :7 3b y t e so u tT u n n e l 0 N H R P :I n v a l i d a t i n gm a pt a b l e sf o rp r e f i x1 0 . 0 . 3 . 0 / 2 4v i aT u n n e l 0 N H R P :A t t e m p t i n gt os e n dp a c k e tv i aD E S T1 0 . 0 . 0 . 1 N H R P :E n c a p s u l a t i o ns u c c e e d e d . T u n n e lI Pa d d r1 5 0 . 1 . 1 . 1

http://blog.ine.com/2008/08/02/dmvpn-explained/

24/46

3/19/2014

DMVPN Explained

R3 receives the reply to its purge request and now it knows that R2 is consistent.
R a c k 1 R 3 # N H R P :R e c e i v eP u r g eR e p l yv i aT u n n e l 0v r f0 ,p a c k e ts i z e :7 3 ( F )a f n :I P v 4 ( 1 ) ,t y p e :I P ( 8 0 0 ) ,h o p :2 5 5 ,v e r :1 s h t l :4 ( N S A P ) ,s s t l :0 ( N S A P ) ( M )f l a g s :" r e p l yr e q u i r e d " ,r e q i d :3 6 s r cN B M A :1 5 0 . 1 . 3 . 3 s r cp r o t o c o l :1 0 . 0 . 0 . 3 ,d s tp r o t o c o l :1 0 . 0 . 0 . 2 ( C 1 )c o d e :n oe r r o r ( 0 ) p r e f i x :0 ,m t u :1 5 1 4 ,h d _ t i m e :0 a d d r _ l e n :0 ( N S A P ) ,s u b a d d r _ l e n :0 ( N S A P ) ,p r o t o _ l e n :4 ,p r e f :0 c l i e n tp r o t o c o l :1 0 . 0 . 3 . 3 N H R P :n e t i d _ i n=0 ,t o _ u s=1

Timing out NHRP entries with Process-Switching The last question is how NHRP times out unused entries in case of process-switching mode. Recall the “used” flag set for NHRP mapping. Every time a packet is process-switched using the respective NHRP entry, it is marked as “used”. The background NHRP process runs every 60 seconds, and check the expire timers for each NHRP entry. If the “used” flag is set and expire timer for the entry is greater than 120 seconds then the process clears the flag (and every new packet will refresh it). If the timer is less than 120 seconds and the flag is set, IOS generates a refreshing NHRP request. However, if the flag is not set, the system allows the entry to expire, unless another packet hits it and makes active. The above-described behavior of NHRP with process switching allows for one interesting feature. The hub router may now summarize all information sent down to spokes say into one default route. This will not affect the spokes, for they will continue querying next-hop information for every destination prefix sent over the mGRE tunnel interface, and learning the optimal next-hop. It would be great to combine this “summarization” feature with the performance of CEF switching. This is exactly what they implemented with DMVPN Phase 3. However, Phase 3 is subject to a separate discussion. Integrating IPsec Haven’t we forgotten something for DMVPN Phase 1/Phase 2? That was IPsec, the components that provides confidentiality and integrity checking to mGRE/NHRP. Now, compared with the complexity of NHRP operations, IPsec integration is straightforward. First, the hub needs to know how to authentication all the spokes using IKE. The most scalable way is to use X.509 certificates and PKI, but for the simplicity, we will just use the same pre-shared key on all routers. Note that we need to configure the routers with a wild-card pre-shared key, in order to accept IKE negotiation requests from any other dynamic peer. As for IPsec Phase 2, we need dynamic crypto maps there, since the hub has no idea of the connecting peer IP addresses. Fortunately, Cisco IOS has a cute feature called IPsec profiles, designed for use with tunnel interfaces. The profile attaches to a tunnel interface and automatically considers all traffic going out of the tunnel as triggering the IPsec Phase 2. The IPsec phase proxy identities used by the IPsec profile are the source and destination host IP addresses of the tunnel. It makes sense to use IPSec transport mode with mGRE as the latter already provides tunnel encapsulation. Besides, IOS supports some features, like NAT traversal only with IPSec transport mode. Let’s review an example below and explain how it works. mGRE + NHRP Phase 2 + Spoke-to-spoke tunnels + IPsec
R 1 : c r y p t oi s a k m pp o l i c y1 0
http://blog.ine.com/2008/08/02/dmvpn-explained/ 25/46

3/19/2014

DMVPN Explained

e n c r y p t i o n3 d e s a u t h e n t i c a t i o np r e s h a r e h a s hm d 5 g r o u p2 ! c r y p t oi s a k m pk e y0C I S C Oa d d r e s s0 . 0 . 0 . 00 . 0 . 0 . 0 ! c r y p t oi p s e ct r a n s f o r m s e t3 D E S _ M D 5e s p 3 d e se s p m d 5 h m a c m o d et r a n s p o r t ! c r y p t oi p s e cp r o f i l eD M V P N s e tt r a n s f o r m s e t3 D E S _ M D 5 ! i n t e r f a c eT u n n e l0 t u n n e lp r o t e c t i o ni p s e cp r o f i l eD M V P N R 2&R 3 : c r y p t oi s a k m pp o l i c y1 0 e n c r y p t i o n3 d e s a u t h e n t i c a t i o np r e s h a r e h a s hm d 5 g r o u p2 ! c r y p t oi s a k m pk e y0C I S C Oa d d r e s s0 . 0 . 0 . 00 . 0 . 0 . 0 ! c r y p t oi p s e ct r a n s f o r m s e t3 D E S _ M D 5e s p 3 d e se s p m d 5 h m a c m o d et r a n s p o r t ! c r y p t oi p s e cp r o f i l eD M V P N s e tt r a n s f o r m s e t3 D E S _ M D 5 ! i n t e r f a c eT u n n e l0 t u n n e lp r o t e c t i o ni p s e cp r o f i l eD M V P N

Start with any spoke, e.g. R3. Since the router uses EIGRP on Tunnel 0 interface, a multicast packet will eventually be send out of the tunnel interface. Thanks to the static NHRP multicast mapping, mGRE will encapsulate the EIGRP packet towards the hub router. The IPsec profile will see GRE traffic going from “150.1.3.3” to “150.1.1.1”. Automatically, ISAKMP negotiation will start with R1, and authentication will use pre-shared keys. Eventually both R1 and R3 will create IPsec SAs for GRE traffic between “150.1.3.3” and “150.1.1.1”. Now R3 may send NHRP resolution request. As soon as R3 tries to send traffic to a network behind R2, it will resolve next-hop “10.0.0.2” to the IP address of 150.1.2.2. This new NHRP entry will trigger ISAKMP negotiation with NBMA address 150.1.2.2 as soon as router tries to use it for packet forwarding. IKE negotiation between R3 and R2 will start and result in formation of new SAs corresponding to IP address pair “150.1.2.2 and 150.1.3.3” and GRE protocol. As soon as the routers complete IPsec Phase 2, packets may flow between R2 and R3 across the shortcut path. When an unused NHRP entry times out, it will signal the ISAKMP process to terminate the respective IPsec connection. We described the process for timing out NHRP entries before, and as you remember, it depends on the “hold-time” value set by the routers. Additionally, the systems may expire ISAKMP/IPsec connections due to IPsec timeouts. This is the crypto system status on the hub from the example with NHRP Phase 2 and process-switching:
I P s e cP h a s e1h a sb e e ne s t a b l i s h e dw i t hb o t hs p o k e s R a c k 1 R 1 # s h o wc r y p t oi s a k m ps a d s t s r c 1 5 0 . 1 . 1 . 1 1 5 0 . 1 . 2 . 2 1 5 0 . 1 . 1 . 1 1 5 0 . 1 . 3 . 3
http://blog.ine.com/2008/08/02/dmvpn-explained/

s t a t e Q M _ I D L E Q M _ I D L E

c o n n i ds l o ts t a t u s 1 0A C T I V E 3 0A C T I V E
26/46

3/19/2014

DMVPN Explained

IPsec Phase 2 SA entries for both protected connections to R2 and R3 follows. Note that SAs are for GRE traffic between the loopback.
R a c k 1 R 1 # s h o wc r y p t oi p s e cs a i n t e r f a c e :T u n n e l 0 C r y p t om a pt a g :T u n n e l 0 h e a d 0 ,l o c a la d d r1 5 0 . 1 . 1 . 1 p r o t e c t e dv r f :( n o n e ) l o c a l i d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 1 . 1 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) r e m o t ei d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 2 . 2 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) c u r r e n t _ p e e r1 5 0 . 1 . 2 . 2p o r t5 0 0 P E R M I T ,f l a g s = { o r i g i n _ i s _ a c l , } # p k t se n c a p s :2 3 0 ,# p k t se n c r y p t :2 3 0 ,# p k t sd i g e s t :2 3 0 # p k t sd e c a p s :2 2 7 ,# p k t sd e c r y p t :2 2 7 ,# p k t sv e r i f y :2 2 7 # p k t sc o m p r e s s e d :0 ,# p k t sd e c o m p r e s s e d :0 # p k t sn o tc o m p r e s s e d :0 ,# p k t sc o m p r .f a i l e d :0 # p k t sn o td e c o m p r e s s e d :0 ,# p k t sd e c o m p r e s sf a i l e d :0 # s e n de r r o r s1 2 ,# r e c ve r r o r s0 l o c a lc r y p t oe n d p t . :1 5 0 . 1 . 1 . 1 ,r e m o t ec r y p t oe n d p t . :1 5 0 . 1 . 2 . 2 p a t hm t u1 5 1 4 ,i pm t u1 5 1 4 ,i pm t ui d bL o o p b a c k 0 c u r r e n to u t b o u n ds p i :0 x 8 8 2 6 1 B A 3 ( 2 2 8 4 1 9 8 8 1 9 ) i n b o u n de s ps a s : s p i :0 x E 2 7 9 A 1 E E ( 3 7 9 9 6 2 2 1 2 6 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 1 ,f l o w _ i d :S W : 1 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 4 7 2 1 1 6 / 2 6 3 2 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E s p i :0 x B 4 F 6 A 9 E 5 ( 3 0 3 6 0 6 4 2 2 9 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 3 ,f l o w _ i d :S W : 3 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 9 6 1 7 6 / 2 6 3 0 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E s p i :0 x 1 4 9 2 E 4 D 0 ( 3 4 5 1 7 1 1 5 2 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 5 ,f l o w _ i d :S W : 5 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 2 5 2 6 4 / 2 6 3 0 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E i n b o u n da hs a s : i n b o u n dp c ps a s : o u t b o u n de s ps a s : s p i :0 x 8 1 9 4 9 8 7 4 ( 2 1 7 3 9 9 9 2 2 0 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 2 ,f l o w _ i d :S W : 2 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 4 7 2 1 1 6 / 2 6 2 6 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E s p i :0 x A A 5 D 2 1 A 7 ( 2 8 5 8 2 3 0 1 8 3 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,}
http://blog.ine.com/2008/08/02/dmvpn-explained/ 27/46

3/19/2014

DMVPN Explained

c o n ni d :2 0 0 4 ,f l o w _ i d :S W : 4 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 9 6 1 7 6 / 2 6 2 7 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E s p i :0 x 8 8 2 6 1 B A 3 ( 2 2 8 4 1 9 8 8 1 9 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 6 ,f l o w _ i d :S W : 6 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 2 5 2 6 5 / 2 6 2 7 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E o u t b o u n da hs a s : o u t b o u n dp c ps a s : p r o t e c t e dv r f :( n o n e ) l o c a l i d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 1 . 1 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) r e m o t ei d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 3 . 3 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) c u r r e n t _ p e e r1 5 0 . 1 . 3 . 3p o r t5 0 0 P E R M I T ,f l a g s = { o r i g i n _ i s _ a c l , } # p k t se n c a p s :2 2 5 ,# p k t se n c r y p t :2 2 5 ,# p k t sd i g e s t :2 2 5 # p k t sd e c a p s :2 2 6 ,# p k t sd e c r y p t :2 2 6 ,# p k t sv e r i f y :2 2 6 # p k t sc o m p r e s s e d :0 ,# p k t sd e c o m p r e s s e d :0 # p k t sn o tc o m p r e s s e d :0 ,# p k t sc o m p r .f a i l e d :0 # p k t sn o td e c o m p r e s s e d :0 ,# p k t sd e c o m p r e s sf a i l e d :0 # s e n de r r o r s1 7 ,# r e c ve r r o r s0 l o c a lc r y p t oe n d p t . :1 5 0 . 1 . 1 . 1 ,r e m o t ec r y p t oe n d p t . :1 5 0 . 1 . 3 . 3 p a t hm t u1 5 1 4 ,i pm t u1 5 1 4 ,i pm t ui d bL o o p b a c k 0 c u r r e n to u t b o u n ds p i :0 x B E B 1 D 9 C E ( 3 1 9 9 3 2 6 6 7 0 ) i n b o u n de s ps a s : s p i :0 x 1 0 B 4 4 B 3 1 ( 2 8 0 2 5 1 1 8 5 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 7 ,f l o w _ i d :S W : 7 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 4 3 6 4 2 2 / 2 6 2 7 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E i n b o u n da hs a s : i n b o u n dp c ps a s : o u t b o u n de s ps a s : s p i :0 x B E B 1 D 9 C E ( 3 1 9 9 3 2 6 6 7 0 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 8 ,f l o w _ i d :S W : 8 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 4 3 6 4 2 4 / 2 6 2 7 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E o u t b o u n da hs a s : o u t b o u n dp c ps a s :

Now let’s see how a spoke router establishes a spoke-to-spoke IPsec tunnel:

http://blog.ine.com/2008/08/02/dmvpn-explained/

28/46

3/19/2014

DMVPN Explained

N oN H R Pm a p p i n gf o rs p o k e ’ sn e t w o r kf i r s t R a c k 1 R 3 # s hi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 2 : 0 2 : 4 2 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 I S A K M Pn e g o t i a t e dj u s tw i t hR 1 R a c k 1 R 3 # s hc r y p t oi s a k m ps a d s t s r c 1 5 0 . 1 . 1 . 1 1 5 0 . 1 . 3 . 3

s t a t e Q M _ I D L E

c o n n i ds l o ts t a t u s 1 0A C T I V E

Generate traffic to network behind R2. Note that the first ping passes through, since it’s routed across the hub, but the second packet is sent directly to R2 and is missed, since IPsec Phase 2 has not yet been established
R a c k 1 R 3 # p i n g1 0 . 0 . 2 . 2 T y p ee s c a p es e q u e n c et oa b o r t . S e n d i n g5 ,1 0 0 b y t eI C M PE c h o st o1 0 . 0 . 2 . 2 ,t i m e o u ti s2s e c o n d s : ! . ! ! ! S u c c e s sr a t ei s8 0p e r c e n t( 4 / 5 ) ,r o u n d t r i pm i n / a v g / m a x=5 2 / 1 2 1 / 3 2 4m s N o t i c et h en e wN H R Pm a p p i n g s .N o t et h a tt h et u n n e lw i l le x p i r ei na b o u t3 m i n u t e s ,i fn on e wt r a f f i ci sg o i n gt ob eg e n e r a t e d R a c k 1 R 3 # s hi pn h r p 1 0 . 0 . 0 . 1 / 3 2v i a1 0 . 0 . 0 . 1 ,T u n n e l 0c r e a t e d0 2 : 0 5 : 3 8 ,n e v e re x p i r e T y p e :s t a t i c ,F l a g s :a u t h o r i t a t i v eu s e d N B M Aa d d r e s s :1 5 0 . 1 . 1 . 1 1 0 . 0 . 2 . 0 / 2 4v i a1 0 . 0 . 2 . 2 ,T u n n e l 0c r e a t e d0 0 : 0 2 : 4 4 ,e x p i r e0 0 : 0 3 : 1 5 T y p e :d y n a m i c ,F l a g s :r o u t e r N B M Aa d d r e s s :1 5 0 . 1 . 2 . 2

IOS create IPsec Phase 2 SAs for tunnels between R2-R3 and R1-R3. The tunnel between 2 and R3 is dynamic and is used to send only the data traffic.
R a c k 1 R 3 # s h o wc r y p t oi s a k m ps a d s t s r c 1 5 0 . 1 . 1 . 1 1 5 0 . 1 . 3 . 3 1 5 0 . 1 . 3 . 3 1 5 0 . 1 . 2 . 2 R a c k 1 R 3 # s h o wc r y p t oi p s e cs a i n t e r f a c e :T u n n e l 0 C r y p t om a pt a g :T u n n e l 0 h e a d 0 ,l o c a la d d r1 5 0 . 1 . 3 . 3 p r o t e c t e dv r f :( n o n e ) l o c a l i d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 3 . 3 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) r e m o t ei d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 1 . 1 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) c u r r e n t _ p e e r1 5 0 . 1 . 1 . 1p o r t5 0 0 P E R M I T ,f l a g s = { o r i g i n _ i s _ a c l , } # p k t se n c a p s :2 9 0 ,# p k t se n c r y p t :2 9 0 ,# p k t sd i g e s t :2 9 0 # p k t sd e c a p s :2 8 4 ,# p k t sd e c r y p t :2 8 4 ,# p k t sv e r i f y :2 8 4 # p k t sc o m p r e s s e d :0 ,# p k t sd e c o m p r e s s e d :0 # p k t sn o tc o m p r e s s e d :0 ,# p k t sc o m p r .f a i l e d :0 # p k t sn o td e c o m p r e s s e d :0 ,# p k t sd e c o m p r e s sf a i l e d :0 # s e n de r r o r s0 ,# r e c ve r r o r s0
http://blog.ine.com/2008/08/02/dmvpn-explained/ 29/46

s t a t e Q M _ I D L E Q M _ I D L E

c o n n i ds l o ts t a t u s 1 0A C T I V E 2 0A C T I V E

3/19/2014

DMVPN Explained

l o c a lc r y p t oe n d p t . :1 5 0 . 1 . 3 . 3 ,r e m o t ec r y p t oe n d p t . :1 5 0 . 1 . 1 . 1 p a t hm t u1 5 1 4 ,i pm t u1 5 1 4 ,i pm t ui d bL o o p b a c k 0 c u r r e n to u t b o u n ds p i :0 x 1 0 B 4 4 B 3 1 ( 2 8 0 2 5 1 1 8 5 ) i n b o u n de s ps a s : s p i :0 x B E B 1 D 9 C E ( 3 1 9 9 3 2 6 6 7 0 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 1 ,f l o w _ i d :S W : 1 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 2 6 8 5 6 / 2 3 8 3 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E i n b o u n da hs a s : i n b o u n dp c ps a s : o u t b o u n de s ps a s : s p i :0 x 1 0 B 4 4 B 3 1 ( 2 8 0 2 5 1 1 8 5 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 2 ,f l o w _ i d :S W : 2 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 5 2 6 8 5 3 / 2 3 8 1 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E o u t b o u n da hs a s : o u t b o u n dp c ps a s : p r o t e c t e dv r f :( n o n e ) l o c a l i d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 3 . 3 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) r e m o t ei d e n t( a d d r / m a s k / p r o t / p o r t ) :( 1 5 0 . 1 . 2 . 2 / 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 / 4 7 / 0 ) c u r r e n t _ p e e r1 5 0 . 1 . 2 . 2p o r t5 0 0 P E R M I T ,f l a g s = { o r i g i n _ i s _ a c l , } # p k t se n c a p s :3 ,# p k t se n c r y p t :3 ,# p k t sd i g e s t :3 # p k t sd e c a p s :4 ,# p k t sd e c r y p t :4 ,# p k t sv e r i f y :4 # p k t sc o m p r e s s e d :0 ,# p k t sd e c o m p r e s s e d :0 # p k t sn o tc o m p r e s s e d :0 ,# p k t sc o m p r .f a i l e d :0 # p k t sn o td e c o m p r e s s e d :0 ,# p k t sd e c o m p r e s sf a i l e d :0 # s e n de r r o r s0 ,# r e c ve r r o r s0 l o c a lc r y p t oe n d p t . :1 5 0 . 1 . 3 . 3 ,r e m o t ec r y p t oe n d p t . :1 5 0 . 1 . 2 . 2 p a t hm t u1 5 1 4 ,i pm t u1 5 1 4 ,i pm t ui d bL o o p b a c k 0 c u r r e n to u t b o u n ds p i :0 x 8 4 7 D 8 E E C ( 2 2 2 2 8 2 1 1 0 0 ) i n b o u n de s ps a s : s p i :0 x A 6 8 5 1 7 5 4 ( 2 7 9 3 7 4 0 1 1 6 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,} c o n ni d :2 0 0 4 ,f l o w _ i d :S W : 4 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 6 0 2 3 0 6 / 3 5 7 2 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E i n b o u n da hs a s : i n b o u n dp c ps a s : o u t b o u n de s ps a s : s p i :0 x 8 4 7 D 8 E E C ( 2 2 2 2 8 2 1 1 0 0 ) t r a n s f o r m :e s p 3 d e se s p m d 5 h m a c, i nu s es e t t i n g s= { T r a n s p o r t ,}
http://blog.ine.com/2008/08/02/dmvpn-explained/ 30/46

3/19/2014

DMVPN Explained

c o n ni d :2 0 0 3 ,f l o w _ i d :S W : 3 ,c r y p t om a p :T u n n e l 0 h e a d 0 s at i m i n g :r e m a i n i n gk e yl i f e t i m e( k / s e c ) :( 4 6 0 2 3 0 6 / 3 5 7 2 ) I Vs i z e :8b y t e s r e p l a yd e t e c t i o ns u p p o r t :Y S t a t u s :A C T I V E o u t b o u n da hs a s : o u t b o u n dp c ps a s :

Now you see how all the component of DMVPN work together. We have not covered some other major topics like NAT traversal with NHRP and DMVPN redundancy with multiple hubs. Those advanced topics probably require a separate post, since this one has grown too big already Tags: ccie, cef, dmvpn, dynamic, eigrp, ipsec, multipoint, NHRP, ospf Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics. Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

64 Responses to “DMVPN Explained”

1. DMVPN Explained · says: August 2, 2008 at 5:49 am [...] News » News News DMVPN Explained2008-08-02 08:49:46Have adjacencies with all spokes. Such limitation is that the limitation is [...] Reply 2. agalang says: August 2, 2008 at 7:27 am fantastic explanation..been waiting for this for a long time
http://blog.ine.com/2008/08/02/dmvpn-explained/ 31/46

3/19/2014

DMVPN Explained

Reply 3. annon says: August 2, 2008 at 7:57 am It was… brilliant!!! Reply 4. DMVPN Explained · says: August 2, 2008 at 9:21 am [...] & RAS Servers News » News News DMVPN Explained2008-08-02 12:21:49Endpoints endpoints need to exchange unicast packets, special “glue” is used [...] Reply 5. zeus says: August 2, 2008 at 1:24 pm Petr is freaking awesome!!!!! Brians how did u find this guy!!! Reply 6. ccieat21 says: August 2, 2008 at 8:45 pm Great Post .. looking forward for advanced DMVPN posts Reply 7. Vijay Tyagi says: August 2, 2008 at 8:53 pm You Rocks!!! Petr. I think IT industry will remember you forever for your great contributions. Regards Reply 8. joseph brunnerr says: August 3, 2008 at 3:02 pm I take issue with part of the above Petr! I quote: “Since all packets are routed across the hub, almost any dynamic routing protocol would help with attaining reachability. The hub just needs to advertise a default route to spokes, while spokes should advertise their subnets dynamically to the hub. Probably the best choice is to run EIGRP and summarize all subnets to 0.0.0.0/0 on the hub, effectively sending a default route to all spokes.” As dmvpn is commonly used in a hq/branch office scenario, typically the spokes have a default route towards their ISP; this is used to reach websites locally, and one or more hub public ip addresses… If
http://blog.ine.com/2008/08/02/dmvpn-explained/ 32/46

3/19/2014

DMVPN Explained

the spokes learn a default route via a dynamic routing protocol from the hub, they will not use it. They will most likely use the default static route towards the local isp next hop address/outgoing serial interface. Also if then they are not using the default route they will not learn any of the hub’s subnets, or the other spokes subnets for DMVPN phase 1 (no spoke to spoke routing) via the DMVPN. Could you please clarify this part in DMVPN Phase 1 regarding having the hub advertise a default route to the spokes… i have never done it or seen it done this way. thanks, Joe #19366 Reply 9. Brandon Carroll says: August 3, 2008 at 6:32 pm I Love it! Perfect timing too. I would however like the ability to grab a PDF of this Reply 10. Petr Lapukhov, CCIE #16379 says: August 3, 2008 at 8:35 pm To: Joseph Brunner Joe, naturally if you use a form of “split-tunneling” on spokes, you would not like to advertise default route fom the hub. Thanks for the point, I will add a few words commentions on that in the post. However, my idea is that with Phase 1, it does not matter whether you send detailed or summarized information from the hub – spoke to spoke tunnels are not used. Sending default route is just an extremal form of summarization, and you may resort to sending say 2-3 routes describing the corporate subnets. It’s the same idea as with ezVPN split-tunneling – you either tunnel everything or tunnel just specifics. Reply 11. Petr Lapukhov, CCIE #16379 says: August 3, 2008 at 8:37 pm To: Brandon Caroll Yeah, a few other people also asked for PDF version providing a link in the post. Reply 12. no ip split-horizon…. says: August 3, 2008 at 11:06 pm [...] If you’re new here, you may want to subscribe to my RSS feed. Thanks for visiting!I had to take 2 minutes and blog this. Last night I set up DMVPN. It all looked ok but I could not get the spoke to spoke connectivity. Then today I find Petr Lupakhovs – DMVPN Explained blog post on CCIE Blog at Internetwork expert. (You can find it here) [...]
http://blog.ine.com/2008/08/02/dmvpn-explained/ 33/46

I’m thinking on uploading the PDF paper and

3/19/2014

DMVPN Explained

Reply 13. JC says: August 7, 2008 at 7:25 am Outstanding and thorough explanation! I recently set up a fairly complex DMVPN solution and thought I understood the technology pretty well. I am humbled. It would be great if you could expand this to include Phase III and multiple hub redundancy. That way this could be the definitive guide to NHRP/DMVPN! Reply 14. MBR says: August 11, 2008 at 9:54 am This is great, Petr. This morning I went searching for dmvpn info. Your paper is by far the best that I found, in a class by itself. Reply 15. 11 August - CCIE Quickies « CCIE Pursuit Blog says: August 11, 2008 at 2:39 pm [...] appetite and you have a few free hours, you should surf over to Internetwork Expert Blog and read Petr’s magnum opus on the same topic. Possibly related posts: (automatically generated)Study StrategyIf I Knew You Were Comin’ [...] Reply 16. Review Notes: Cisco Lifecycle Services ARSFE (Design Phase) « CarlProject says: August 17, 2008 at 12:29 am [...] DMVPN design development (Here is a tutorial of DMVPN by Petr Lapukhov of Internetwork Expert) [...] Reply 17. Baby, You Can Route My World! » Blog Archive » Back In the Swing says: August 19, 2008 at 11:42 am [...] trying to learn everything I can about DMVPNs, IPSECs, GREs, etc. I’ve gone over an excellent DMVPN article by Petr Lapukhov of InternetworkExpert as well as Jeremy Stretch of PacketLife.net’s clear explanations. But [...] Reply 18. Cisco Guy says: September 12, 2008 at 12:34 am DMVPN is great for transferring multicast traffic securely. I have used this solution in a stock exchange scenario where brokers get real-time ticker updates for stocks, which is actually multicast traffic. GRE here with the added security of IPSEC is an excellent combination. Reply 19. Petr Lapukhov, CCIE #16379 says: September 12, 2008 at 12:37 am
34/46

http://blog.ine.com/2008/08/02/dmvpn-explained/

3/19/2014

DMVPN Explained

To: Cisco Guy Have you tried Cisco’s GET VPN technology for Secure Multicast in production? Reply 20. DMVPN Study « cciESolutions says: September 17, 2008 at 1:20 pm [...] DMVPN Explained [...] Reply 21. l0k1 says: September 17, 2008 at 5:27 pm hi my name is Daniel & I´m from Mexico, there´s an issue about my nhrp implementation, I revised the RFC to figured out what´s wrong whit this.. there are some things that tell me that my nhs is not responding my resolutions requests but this occurs only whit some spokes,,, is there any limit on the server cache or something like that?? this flags are saw on one of the spokes. 12.12.13.254/32, Tunnel12 created 00:00:51, expire 00:02:13 Type: incomplete, Flags: negative Cache hits: 2 Reply 22. Cisco Guy says: November 20, 2008 at 9:55 pm To: Petr Sorry for the late reply…no unfortunately I have not used GET VPN yet for secure multicast traffic.. It looks interesting technology though Reply 23. andri says: December 22, 2008 at 1:20 am first of all, this is a real great deal of explaination, i salute u . the problem is , i cant get my icmp packet be encrypted from spoke to spoke. I know something must have gone wrong and i am still trying to search the problem. I will be very please if you described the hardware configuration for this topology since i believe my problem is in the hardware. waiting for your sincere reply Reply 24. DMVPN Phase 3 - CCIE Blog says: December 23, 2008 at 6:25 am
http://blog.ine.com/2008/08/02/dmvpn-explained/ 35/46

3/19/2014

DMVPN Explained

[...] DMVPN Phase 3 By Petr Lapukhov, CCIE #16379 In this post we are going to speak mainly of NHRP. The other important part of DMVPN – IPsec – is relatively the same, and did not change with introduction of NHRP Phase 3. To begin with, let’s quickly recall the core features of NHRP Phase 1 & 2. For detailed overview, you may refer to DMVPN Explained [...] Reply 25. Dmvpn links « Reload In 5 says: December 29, 2008 at 7:00 am [...] dmvpn, ios Collection of interesting dmvpn articles and video links: – Internetworkexpert.com phase 1 & 2 phase [...] Reply 26. Hamood says: December 31, 2008 at 2:43 am Petr, Can you give an example for NHRP with OSPF and why we have to use the database filter-all out command. Most of the sample configurations I saw are using the EIGRP. Reply 27. James says: February 5, 2009 at 8:04 am Great post.I get help from this post.I really appreciate to author. Reply 28. ttongfly says: April 5, 2009 at 8:58 pm Thank you for post. I fixed problem on my LAB. Reply 29. Security « CCIE Study Notes says: May 12, 2009 at 1:03 am [...] explained here but i’m out of steam for security today Comments [...] Reply 30. ob says: August 1, 2009 at 8:27 am Great article! I have two questions though: 1) How do I get spoke-to-spoke multicasting to work. Even the simple “ping 224.0.0.1″ on spokeA will not get a reply from spokeB, only the HUB. 2) How do I set up redundant NHS?
http://blog.ine.com/2008/08/02/dmvpn-explained/ 36/46

3/19/2014

DMVPN Explained

Reply Petr Lapukhov, CCIE #16379 says: August 4, 2009 at 8:13 pm 1) You need to use PIM-NBMA mode on the hub tunnel interface to allow for neighbor tracking and splitting the NBMA interface into a group of P2P links. This of course only works with PIM sparse. 2) With Phase 2, you need to configure every spoke with two NHS addresses and configure both NHSes to point to each other. This will ensure proper NHS cache syncrhonization. 2) With Phase 3, everythin should be working automatically, even if you have multiple spokes registering to different hubs, the chain of redirects is based on the routing topology, not the NHS connections. Reply 31. Naru says: September 14, 2009 at 6:50 am Very nice explanation, keep the good work up! Reply 32. Sinisa says: September 22, 2009 at 3:05 pm This is a grat explanation of DMVPN, the best one I could find on the Internet. Question: I have DMVPN topology with two redundant NHSs (pointing each other) and several NHCs, and that topology works fine. Problem is when I shut NHS#1 (or it crashes) and bring it back, and then the same with NHS#2, my NHCs can’t see each other any more. They even can’t see NHSs, and NHSs can see only each other. I can only solve it by shut/no shut tunnel interfaces on NHCs. Is there a rule or a behaviour of NHRP that NHSs have to be configured first in network, then NHCs? I run multi area OSPF over multiple GRE tunnels, and it’s all protected with IPSec. I have removed IPSec protection and OSPF in observed mGRE tunnel to have a clear situation. Any help? Reply 33. Naru says: October 22, 2009 at 4:48 am I am currently using Orion SolarWinds NPM to monitor my nodes, though I needed to monitor the tunnels when they go up & down so I can send the report to my ISP, but I saw that even if the tunnel is not connected, it still shows as UP – UP, is there a way to change this behavior? For example, when you can’t reach that tunnel, the tunnel should go like UP – DOWN , or if there’s any other method to monitor those tunnels would be great. Thanks Reply 34. Sinisa says:
37/46

http://blog.ine.com/2008/08/02/dmvpn-explained/

3/19/2014

DMVPN Explained

December 9, 2009 at 3:03 am @Naru You can use ip sla traps and snmp. Reply 35. Zen says: December 28, 2009 at 6:08 am Hello, I implemented DMVPN a while ago, and used to work great. Recently I noticed memory & cpu usages going very high, and when I checked with show processes cpu , I saw that NHRP was using 40-60% of the CPU constantly. I ran show ip nhrp , and the results really frightened me, there are lots of unknown ip address in there , same is happening on my Hub and on Spokes. Here’s one of the many entries: 97.100.x.x/32 via 192.168.x.1 Tunnel0 created 00:00:03, expire 00:05:58 Type: dynamic, Flags: router There are many other different IP addresses that look like the one above, any idea whats going on? Reply 36. Ali says: January 20, 2010 at 2:44 am Can I implement a Laptop installed with Cisco VPN client as a DMVPN Spoke Site, LIke for eg. I have an employee working from a remote location and has internet connectivity and needs to access other spokes too , directly without the traffic being sent from the laptop to the hub and then to the other remote site, instead a dynamic tunnel needs to be created from the Laptop to the other spoke? Is it possible to implement DMVPN/NHRP on a Cisco VPN client? Reply 37. Zen says: February 22, 2010 at 3:01 am About my above post, i think it could help someone on the same foot. After implementing the following command I havent noticed anymore weird nhrp registers, and also we changed the address which crypto should allow to make a request for registers. crypto isakmp aggressive-mode disable crypto isakmp key 0 CISCO address [b]ActualIPAdress[/b] Reply 38. Periodic Failure » Single Spoke Dynamic Multipoint VPN (DMVPN) says:
http://blog.ine.com/2008/08/02/dmvpn-explained/ 38/46

3/19/2014

DMVPN Explained

April 3, 2010 at 8:05 pm [...] getting a fully working configuration, I stumbled across an excellent blog post by Petr Lapukhov DMVPN Explained it goes through the configuration stage by stage with great insight on how its all put together. I [...] Reply 39. Sleep-1 , Cisco-32423 « TacAck – My security journey! says: May 11, 2010 at 7:10 pm [...] , i want to do DMVPN today. There’s an awesome article on DMVPN written by Petr Lapukhov on blog.ine.com . I’m going to go through that as soon as i’m [...] Reply 40. Jan says: June 5, 2010 at 2:36 pm Good job Petr. Thanx for article. Can u add “sh ip route” (all routes) prints of NHRP Phase 2 devices? Reply 41. Roland says: June 27, 2010 at 9:06 am Should I expect DMVPN on R&S CCIE lab? Can’t find it in the blueprint. Reply Anthony Sequeira, #15626 says: June 28, 2010 at 5:41 am @Ronald DMVPN is tested heavily on the Security CCIE Track, but is no longer part of the Written or Lab materials for R&S Reply 42. EP says: July 16, 2010 at 9:17 pm to: Petr Lapukhov What a great article!!! Very well define… Sir, hope any new technologies would come from you…. all hard to learn from cisco books are well explained from you… very well instructor… Thank you so much… Damn!!! I’m reading all your articles… When I start reading it, I can’t free my sight not finishing it… Reply 43. tjames says:
39/46

http://blog.ine.com/2008/08/02/dmvpn-explained/

3/19/2014

DMVPN Explained

September 8, 2010 at 3:30 pm Guys i’ve been bashing my head around this problem for a few days please help ip nhrp network-id this is used to turn on nhrp on an interface and to provide the logical membership to a certain DMVPN cloud, otherwise stated each DMVPN cloud should have it’s unique network id What i did in my lab was to have each spoke and the hub in different DMVPN clouds meaning spoke one had network-id 1 , spoke 2 had network-id 2, hub had network-id 3 etc and it seemed to work just fine so i dont understand the use of “ip nhrp network-id” if with different network-ids it works Thanks Reply 44. tjames says: September 10, 2010 at 10:51 am Hi Petr Can you provide some insights into the above “dilema” ? Thanks a lot Reply 45. roger sambora says: October 21, 2010 at 6:50 am Petr: Excellent doc !! Better than any Cisco doc Would you be putting out something more including IPSec VTI too? BTW: not able to download the Phase 2 doc as Adobe? but Phase 3 docs downloads just fine. Thx !! Roger Reply 46. Mohinder Singh Rawat says: December 1, 2010 at 7:44 pm Hi Petr, Thanks a lot for your wonderful post. I was just checking your learning curve.. 4 CCIE in two years and pursuing Phd in Applied Mathematics..Awesome. Mahi Reply

http://blog.ine.com/2008/08/02/dmvpn-explained/

40/46

3/19/2014

DMVPN Explained

47.

Smail says: January 24, 2011 at 9:22 am Hi Petr, How the DMVPN is implemented when we have 2 data centers for redundancy. Both data centers are connected to remote locations via GRE tunnel. One data center is primary and other one is secondary and we would like to do the failover in case primary goes down. Reply

48.

Edgardo Scrimaglia says: May 31, 2011 at 8:59 pm Hello Petr, is DMVPN+multicast already suported over Cat6500 at the HUB? best regards Reply

49.

sanjay says: September 17, 2011 at 9:44 am Great… Thanks for the detail explanation with debugs…..:) Reply

50.

Rooein says: September 22, 2011 at 1:58 am Hi All, I have a question about DMVPN on transport mode in hub and spoke area, I wanna know, if i want to run DMVPN with transport mode, if i configure transport mode on hub,i should configure transport mode on all spoke? Thanks Reply

51.

emmak says: September 27, 2011 at 2:25 am great article! i tried this with the hub running bgp and it worked fine

Reply 52. Cisco – DMVPN Tutorial | x443 says: November 6, 2011 at 3:02 am [...] http://blog.ine.com/2008/08/02/dmvpn-explained/ [...] Reply
http://blog.ine.com/2008/08/02/dmvpn-explained/ 41/46

3/19/2014

DMVPN Explained

53.

See See Eye E says: November 21, 2011 at 2:04 pm I need to setup a VPN between 2 sites. One has live public address and other site is using just DSL connection with dynamic IP. Both sides Cisco routers. Pls advise, what type of VPN is required to establish connectivity assuming no security is required. Reply Mark Snow, CCIE #14073 says: November 22, 2011 at 7:32 am Best place for this question is probably over on our forum/mailing list at IEOC. That being said, GRE tunnels with NHRP (IPSec only being needed if security is of concern) will probably do you nicely. Basically DMVPN without the IPSec. Allows for NAT. Allows for DHCP addressing (on all but the hub). Gives you everything you asked for.

Reply 54. Cisco: DMVPN Resources | Joseph Drane Blog says: June 9, 2012 at 7:55 am [...] INE.com [...] Reply 55. Nikolay says: July 29, 2012 at 11:45 pm Hi! Is the DMVPN proprietry or open industry standard? Reply Brian McGahan, CCIE #8593 says: July 31, 2012 at 12:04 pm Cisco proprietary. Reply 56. Aleksandr says: March 30, 2013 at 1:25 am Hello. Thanks a lot for the article! Could you, please, clarify the situation regarding default routes? Consider the following situation: There are a central site (hub) and many branches (spokes). Public IP addresses are used as source and destination for tunnels — those are considered NBMA addresses. Each spoke uses different ISP.
http://blog.ine.com/2008/08/02/dmvpn-explained/ 42/46

3/19/2014

DMVPN Explained

Spokes may access the Intenet only through the hub (let’s say we don’t use proxy). So, each spoke router has to have two default routes: - first, to reach ISP using NBMA addresses (used only by router) - second, to reach Internet using private addresses (used by users) Please, tell what is the best solution for this situation. Thank you. Reply 57. swap says: May 7, 2013 at 1:39 pm This article says “(no-socket)” flag will trigger IPSec, this is not true. Instead the no-socket flag is used to specify not to trigger IPSec traffic, typically used for local & implicit NHRP mappings. In case there is a need for using such a NHRP mapping for traffic, it is changed from no-socket to “socket” and IPSec tunnel creation is triggered. Swap #19804 Reply 58. CCIExpert says: July 2, 2013 at 6:34 am Great topic Reply 59. mrosemtsc says: September 20, 2013 at 2:06 pm I have phase 2+eigrp running in a lab environment with two hubs, and three spokes. For some reason I cant get the traffic to go from spoke to spoke, but instead the traceroutes go through the hub(s) even through NHRP is supposed to resolve the next hop for the spoke. Have any of you run into this problem? Reply 60. DMVPN, introduction with example configurations | David's networking blog says: September 29, 2013 at 8:35 am [...] we get to some configuration, if you don’t know anything about DMVPN, check out these links: http://blog.ine.com/2008/08/02/dmvpn-explained/ http://blog.ine.com/2008/12/23/dmvpn-phase-3/ really good explanations of [...] Reply

Leave a Reply
http://blog.ine.com/2008/08/02/dmvpn-explained/ 43/46

3/19/2014

DMVPN Explained

Name (required) Mail (will not be published) (required)

Submit Comment

Search
Search Submit

Categories
Select Category

http://blog.ine.com/2008/08/02/dmvpn-explained/

44/46

3/19/2014

DMVPN Explained

CCIE Bloggers
Brian Dennis, CCIEx5 #2210 Routing & Switching Voice Security Service Provider ISP Dial Brian McGahan, CCIEx4 #8593, CCDE #2013::13 Design Data Center Routing & Switching Security Service Provider Mark Snow, CCIEx3 #14073
http://blog.ine.com/2008/08/02/dmvpn-explained/ 45/46

3/19/2014

DMVPN Explained

Data Center Voice Security Petr Lapukhov, CCIEx4 #16379, CCDE #2010::7 Design Routing & Switching Security Service Provider Voice

Popular Posts
CCIE Data Center ACE Rack Rentals CCIE Security v4 ATC Videos Now Available

twitter.com/inetraining Follow
© 2011 INE, Inc., All Rights Reserved

http://blog.ine.com/2008/08/02/dmvpn-explained/

46/46

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close