CCNP ENARSI (300-410) : DMVPN (DYNAMIC MULTIPOINT VPN)

1. DMVPN Fundamentals

In this section we will talk about theDMVPN Fundament's dynamic multipoint virtual private network. DMVPN is a Cisco solution that provides a scalable VPN architecture. DMVPN uses generic routing and encapsulation techniques like GRE for tunnelling next hop resolution protocol, NhRP for OnDemandforwarding and mapping information, and IPsec to provide a secure overlay network to address the deficiencies of site-to-site VPN tunnels while providing full mesh connectivity. DMVPN was released in three phases and each phase was built on the previous one with additional function skies.All three phases of DMVPN need only one tunnel interface on a router, and the DMVPN network size should accommodate all the endpoints associated with that tunnel network. DMVPN spokes can use DHCP or static addressing for the transport and overlay networks. They locate the other spoke IP addresses, protocols, and MDMA through NhRP, which we will introduce after fee slides. Let's check the DMVPM phase one first. DMVPN phase one was the first DMVPN implementation and provides a zero-touch deployment for VPN sites. VPN tunnels are created only between Spock and Hub sites. Traffic between spokes must traverse the hub to reach the other spock.

This is a legacy implementation of DMVPN. You can see in phase one we have DMVPNHub via DMVPN Spark One and the DMVPN Spark Two tunnels are just between the hub and the spoke. So if one spoke, let's say that if spark one wants to communicate with spark two, the traffic should go to Hub and then just forward it to spark two. When it comes to Dmvpm phase two, it provides additional capability from the Mvpm phase one and allows Spooktospoke communication on a dynamic basis by creating OnDemandVPN tunnels between the Spark devices. DMVPN phase two does not allow summarization. As a result, it also does not support sparked communication between different DMVPN networks. This is also a legacy implementation of DMVPN. So on DMVPN phase two, we again spoke to Hub tunnels. You can see here we can have this, but Spock tunnels are also in here. As a result, if Spark One wants to communicate with Spark Two, the traffic does not need to pass through the hub this time. So these guys can communicate with each other using the dynamically created Spock tunnel. When it comes to the mVPN phase three, this one refines Spark to Spock connectivity by enhancing theNhRP messaging and interacting with the routing table. With Dmvpm phase three, Duhab sends an NhRP redirect message to the Spark that originated the packet flow.

The NhRP redirect message provides the necessary information so that the originator can initiate a resolution of the destination network. In DMVPN phase three, NhRPinstals the paths in the routing table for the shortcut. It creates NhRP shortcuts, modifies the next destination for existing routes, or adds a more explicit route entry to the routing table. Because NhRP shortcuts add more explicit rods to the routing table, Mvpm phase three supports network summarisation at the hub while also providing optimal routing between spock routers. NhRP shortcuts allow a hierarchical tree topology so that the original hub is responsible for managing NhRP traffic and subnets within that region. But the spoke-to-spoke tunnel can be established outside the region. So the figure on the screen illustrates the differences in traffic patterns for all three DMVPN phases. All three modules support direct spot to hub communication, as shown by Rodger Van and rodgertwo.And the figure on the screen reflects the difference in traffic patterns between phase two and phase three of DMVPM with hierarchicaltopologies in this two-tier hierarchical design. Router two is the hub for the DMVPN tunnel, and router three is the hub for DMVPN tunnel 30. You can see here we have, I'm sorry, and that is the hub for DMVPN tunnel 20, and we have router three. And that is the hub for DMVPN tunnel 30. And here, connectivity between DMVPN tunnels 20 and 30 is established by DMVPN tunnel 10. Here you can see we have the DMVPN tunnel ten and connectivity is our best tunnel between these different tunnels. For phase two DMVPN tunnels, traffic from router five, as you can see here, must flow to the hub. Router two, okay, and it is sent to router three, in this direction, and it is just forwarded to router six. But for phase three DMVPN tunnels, a spark tospoke tunnel is established between Rodger five and Roddersix, as you can see here. And the two routers can communicate directly.

So, when it comes to the advantages of using theDMVPN, the first advantage is zero-touch provisioning. DMVPN hubs do not require additional configuration when additional sparks are added guys.So DMVPN sparks can use a templated tunnel configuration. The second benefit is the scalable deployment. minimum peering and permanent state Onspark routers allow for massive scale network scale is not limited by device. The other benefit is sparktoscop tunnels. Surely, Dmvpm provides full mesh connectivity while configuring only the initial spark to hub tunnel. Dynamic spoke to spark tunnels are created as needed and toned down when no longer needed. There is no packet loss while buildingdynamic on demand spoke to spock tunnels. After the initial spark to hub tunnels is established, the spoke maintains forwarding states only for sporks with which it is communicating guides.And the other advantage is flexible network topologies. DMVPN operation does not make any rigid assumptions about either the controlplane or data plane overlay topologies. The DMVPN control plane is used in a highly distributed and resilient model that allows massive scale and avoids a single point of failure or congestion. On the other hand, it is also used in a centralised model for a single point of control. And another advantage is multiprotocol and multicast support. DMVPN Guy supports IPV4, IPV6, and MPLS as the overlay or transport network protocol. And it also allows multicast traffic to flow on the other tunnel interface faces.

2. GRE –mGRE

In this section, we will talk about GRE and MGRE. A GRE tunnel provides connectivity to a wide variety of network layer protocols by encapsulating and forwarding those packets. An IP based network DMVPN guys usesmultipoint GRE MGRE encapsulation and supports dynamicrouting protocols which eliminates many of thesupport issues associated with other VPN technologies. GRE tunnels are classified as an overlay network because they are built on top of an existing transport network, also known as an underlay network. Additional header information is added to the packet when the router encapsulates the packet for the GRE tunnel. This new header information contains the remote endpoint IP address as the destination. The new IP headers allow the packets to be routed between the two tunnelendpoints without inspection of the packet payload.

After the packet reaches the remote endpoint, the GRE headers are removed and the original packet is forwarded out of the remote router. Let's now have a look at how we can configure the GRE. Here we have two routers, networker router one and networker router two. To configure the GRE tunnel, use the command isinterface tunnel and, for example, tunnel zero. Then we assign an IP address to our tunnel. For router one we are assigning ten, and for router two, the IP address is Since we are using 30 subnetmasks for Bob, since GRE is anencapsulating protocol, we adjust the maximum transfer unit MTU to maximum segment size MSS to 1360 bytes. Because most transport MTUs have an added overhead. Because of GRE, we must reduce the MTUto account for the extra overhead, a settingof common practise and will ensure unnecessary packetsfragmentation is kept to minimum guys. Then we also defining a tonne of source IP address inhere so that's the IP address of this interface and tunneldestination is the IP address of the remote routers gig zerozero interface as you can see in here and the sameMTU and MSS values are configured on the R two. And this time tunnel source is surely geek zeroagain of the router two and the destination isthis time the gig of router one. And then we are just making an OSPF configurationin here to advertise the 16 and the 1010networks and 17 and the 1010 networks. Let's go ahead with theNhRP next Hope Regulation protocol. NhRP Guys is defined in RFC 2332 as amethod to provide address resolution for hosts or networksfor MBMA networks such as frame relay and ATM.

Nhrpg Guides provides a method for devices tolearn the protocol and MDMA network, thereby allowingthem to directly communicate with each other. NhRP is a client server protocolthat allows devices to register themselvesover directly connected or disparate networks. NhRP Next hop servers guys, let's type in here. You can see them as NHSL as well. NHS are responsible for registering addresses or networks,maintaining an NhRP repository and replying to anyqueries received by the next Hop clients andyou can see them also. Like NHC. The NHC and NHS are transactional in nature. DMVPN uses multipoint GRE tunnels, which requires a method of mapping tunnel IP addresses to the transport IP addresses. NhRP provides the technology for mapping those IP addresses. The NHC, or nextHub clients, are statically configured with the IP address of the NHS, or theHubs, so that they can register their tunnel and MDMA IP address with the Hubs. When a spot to spoke tunnel is established,NhRP messages provide the necessary information for the Spocks to locate each other so that they can build a spark to spark DMVPN tunnel. The NhRP messages also allow aSpark to locate a remote network. So when it comes to the NhRP message types,guys, we have five different NhRP message types andthey are registration, Resolution, Redirect, Perch and the Error. Let's have a look of nowhowNhRP works with multiple GRE. Okay, on screen guys. We have two Spock routers and they sparked one and they spoke to us.

These guys are establishing a tunnel to the Hub router. As you can see here, Later, once we look at the configurations, you will see that the destination IP address of the Hubrouter will be statically configured on the Spock routers. The Hub router will dynamically accept spoke routers. The routers will use an NhRP registration request message to register their public IP addresses with the Hub. As you can see here, spark One is sending an establishing tunnel to the Hub. I'm using a public IP address. My public IP address is two twotwo. And Spoke is also sending an NhRP registration request message and sending the public IP here. As you can see on the second step, the Hub, which is our NhRP server, will create a mapping between the public IP addresses and the IP addresses of the tunnel interfaces. So here is the message of the Huband. He's saying, "Great, we have two sparks." OK, that means I received your registration request and I'm adding their public IPad dresses to my Nhrpcache and NhRP cache. You can see that one two is mapped to two two-two and one three is mapped to three threethree.And here is the other one two.Actually, this and this are the three. And after a few seconds, guys, spark 1 may want to send some packets to spark two. Then it needs to figure out the destination public IP address of the spoke to. So that means it will send an NhRPresolution request asking the Hub router what the public IP address of the spoke is.

So you can see, this is the NhRP resolution request. And he's saying, "I want to send something to speak to." Can you tell me what public IP address they use for their hub? Then Hub will use its NhRP cache to answer this query in the next step. As I told you, the Hub router will check its cache and find an entry forspoke to and send the NhRP Resolution replay. As you can see here, And we'll say that here you can reach them at three, three, three. And here is the entry that is in the cache thatHub router uses to reply to the spoke once request. And this is the NhRP Resolution reply packet. Now, guys, anymore? Spark One knows the destination public IP address of Spark Two and is able to tunnel something directly. This is great, right? We only require the Hub to figure out what the public IP address is and all traffic can be sent from Spark to Spark directly. And here it is, and from now on, if SparkOne wants to send some packets towards Spark Two,it will not go to the Hub anymore. And it will just go from this way to this way directly.

3. DMVPN CONFIGURATION

In our next section, we will have a look at how to configure a DMVPN. So this example on the screen shows the atopology used to explain DMVPN configuration and functions. We have router eleven, which is the TM VPN hub, and we have router 31 as the TM VPN spoke, and router 41, which is also the TM VPN spoke. All three routers use a static default route to the service provider router that provides connectivity for the MDMA networks in the 160 x 2160 00:16 network range. And also, AiGRP has been configured to operate on the DMVPN tunnel and to advertise the local lawnnetworks with care to prevent recursive routing.

But our main focus here, guys, is how we can configure the DMVPN hubs and what we need to do on the DMVPN spark side. So on the hub config, let's start with the hub config. So on router eleven we are defining a tunnel interface, an interface tunnel 100, and please check the tunnel name is set to the same for this box as well. And also, we're defining a bandwidth here with bandwidth and 4000. So defining a bandwidth value is actually optional for DMVPN configuration guys. Virtual interfaces do not have the concept of latency and need to have a reference bandwidth configured so that routingprotocols that use bandwidth for best bet calculation can make an intelligent decision. Bandwidth is also used for QRS configuration on the interface and bandwidth is defined with the interface parameter command with bandwidth. Here you can see that we are assigning an IP address to our tunnelinterface and this is 111.

Okay, this is going to be the tunnel interface configured for the hub. Then we are modifying the MTU. We have talked about this one while we were modifying the MTU and the MSS values in here. Then guys, we can define an NhRP network ID in here, which is set to 100 in this case. So, enabling NhRP and uniquely identifying the DMVPNtunnel for the virtual interface with the interface parameter command IP, NhRP, and networkid The NhRP network ID is locally significant and it is used to identify a DMVPN cloud on a router. Because multiple tunnel interfaces can belong to the same DMVPNcloud, it is recommended that the NhRP network ID match on all routers participating in the same DNVPN network. You can also see that here we have a command IP Guys, NhRP map multicast dynamic is optional, and please keep in mind that this configuration is for DMVPN phase One hub. OK guys, NhRP provides a mapping service from the protocol tunnel IP address to the NBMAtransport address for multi-guest packets too. In order to support multicast or routing protocols that use multicast, this must be enabled on all DMVPN hub routers with the tunnel command IPand HRP map multicast dynamic. Okay, then here we are defining tunnel source as tunnel source gigabit zero one. The tunnel source depends on the transport type guys.And the encapsulating interface can be a logical interface such as a loopback or a subinterface. Also, there guys, we are converting the tunnel to a GRE multipoint interface. So the command is tunnel mode, GRE multipoint, and here we have another optional parameter, which is the tunnel key. The Tunnel key is set to 100 here. So this key should match for both Hub and Spark routers to establish a tunnel between each other.Let us now discuss the Spock configuration. Guys, on the spot is similar to the configuration for a hub except that it does not use a multipoint GRE tunnel. Instead, the tunnel destination is specified. That is the first difference, and the second difference between the spokes is the NhRP mapping points to at least one active NHS, so we can check the spot configuration also here. So interface tunnel 100, that's the same withhub and we are setting the same bandwidth, so the IP address is surely changing. NTU is set to the same value, so these are almost the same. This is a similar thing, surely, and MTU and the MSS are also the same. Okay, the network ID is the same.

The tunnel source is the similar logic tunnel destination. We don't have this one on the Hub, right? And the tunnel key is also safe. The only difference that we can see between inHub and Spark is that we are defining a tunnel destination for the DMVPN Spark. This is the IP address of MDMA. I mean the transport IPof the hub, which is eleven. You can see it here. And also, we are using the command IP NHS, which is the hub and the 111, which is the IP address of the tunnel interface of the router eleven and MBMA eleven. The command finishes with the multicast option. Okay, this configuration is almost the same for the otherspoke also, but just some IP addresses are changing. So let's check how we can verify DMVPN phase one. So the command is "show DMVPN." That's the really basic command that we can use for both Spock and the Hubs. When we check the Showdown VPN output for router eleven, we see that we have two peers and these are our NhRP peers. Here are the peer MDMA addresses and here are the peer tunnel addresses. They are 31 and 41. As we configure and state is up for this DMVPN tunnel, the attribute is D, which means dynamic. When we check the output for this box, let's check for the other 31. When we typeshop DMVPN, it shows the type as spoke. Please look for the hub with the type Hub, as we currently only have one NhRP peer. Okay, and that is the hub, and here is the hub's peer MBMA address and peer tunnel address. Both are eleven for both, and we can see that state is upand attribute is S for distance, which is static. Okay, everything is looking great now. The output is looking correct.

This is how we configured theHubs and this box already. We can also check the Show of DMVPNdetail and this command provides the tunnel interface,tunnel roll, tunnel state, and the tunnel peer's uptime, so it's giving some more detail. Tunnel 100 is the interface, and it is on upstate. Here is the address for this one and some more detailed information as well. So to verify the DMVPN phase 1,we may also leave the NhRP cache. The information that NhRP provides is a vital component of the operation of DMVPN and every router maintains a cache of requests that it receives or is processing. The command show IP NhRP displays the local NhRP cache on the router. Router Eleven contains only dynamic registrations for Router 31 and Router 41. In the event that Router 31 and 41 cannot maintain connectivity to the RouterEleven transport IP address, eventually the tunnelmapping will be removed on Router Eleven. The NhRP message flags on Router Eleven indicate that Router 31 and Rather 41 have successfully registered with unique registration to Router Eleven and that traffic hasrecently been forwarded to both routers. So when we check Router Eleven, which is the HubShow IP NhRP, which is showing the NhRP cache, we can see the information for Rather 31 and Rather 41. And when we check the NhRP cache for the sparks, we will just see the information for the Hub router, which is Router Eleven. You can see it here. And please keep in mind that the type is dynamic for a hub and the type is static for the spokes again, so that is the verification. Also, So this screen is providing the output for the ShowIP and HRP brief comments. This time around, some information such as the used and next hope NhRP message flags are not shown with the brief keyword. So now let's check the routing table of the Hub. Okay, we configured the DMVPN phaseone and everything is looking fine. We verified the tunnel is up, but how the route table is looking. So on Router Eleven, which is the Hub, when you type the Show IP Route command, you can see that we have networks for 10330, which is the local area network segment of the 31, and ten four forty,which is the local area network segment of Router 41. And we can see that how we learned how this hublearned these routes is via the 131 and 141, which is the tunnel interface for the Rodger 31 and Rather 41. So, when it comes to the sparks routing table, and if we run the Show IP rod for both spokes, we can see that there is one 10 network for 31. 10 is the local network segment of Router Eleven.

So it is learned via the Router Eleven tunnel interface. And we also have ten four forty, which is the local area network segment of Rather 41, and this is also learned via the Hub tunnel interface. You can see here we are learning it also from 111 because this is the DMVPN phase one and there is no direct communication between the sparks. So if you were to check the trace route on thispark on Rather 31, trace route ten four, four one, and you can see that traffic is going to the Hubs tunnelinterface first, then it's just reaching the spark 41. So now let's check the configuration of DMVPN phase three. The phase three DMVPN guys configuration for the Hub router adds the interface parameter,the command IP and HRP redirect. As you can see here, This command checks the flow of packets on the tunnel interface and sends a redirect message to the source Spock router when it detects packets pinning out of the DMVPN cloud. Hair pinning is when traffic is received and sent out of an interface in the same cloud. For instance, packets coming in and going out of this same tunnel interface is a case of hairpening. And the phase three DMVPN configuration for spokerouters uses the multipoint GRE tunnel interface and uses the command and you can see the IP NhRP shortcut on the tunnel interface which enables the NhRP shortcut function. Please note that all three routers have tunnel mode. This time, the jerry multipoint, tunnel mode, jerry multipoint, and other configurations are identical to the DMVPN phase one.

So let's check what the traced route is looking like from the Rather 31, which is the spokes point of view. If we trace to one for Rather 31, we can see that first the packet is going through the hub and then reaching the spoke. So this is the initial packet flow afterspoke to Spock tunnel is established, which is the main advantage of the DMVPN phase three. If we trace route to the same IP address again, we will only see one hop, which is the 141 IP address of the router 41. After a spoke to Spock tunnel is established, we can verify DMVPN status again. So there are two new spoke-to-spoke tunnels guys in this output, and they are highlighted here. You can see these are the spoke tunnels and this with attribute DLX represents the local, which is a no-socket route, and the original tunnel to router eleven remains as the static one, as you can see here. So when we type the show of DMVPN details for Rather 31, we can see this output easily. So we can also check the NhRP cache again. The output on the screen displays the NhRP cache and notice that the NhRP mappings are router rip Nho and the NhRP cache, which is the next hop. And the flag rip indicates that therouter has found an identical route in the routing table that belongs to a different protocol. NhRP has overridden the other protocolsnexthop entry for the network. By installing a Next Hop shortcut in the routing table, the flag rip NHOP indicates that the routerhas an explicit method to reach the tunnel address via an MDMA address and has an associated router installed in the routing table.

Study with ExamSnap to prepare for Cisco CCNP Enterprise Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Cisco CCNP Enterprise Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Cisco CCNP Enterprise Practice Test Questions & Exam Dumps that are up-to-date.