[NOTE: Click the “DOWNLOAD” button to the right to download the config files for this lab]
Transcript: Welcome to the CCDA lab where we’ll be considering DMVPN as a case study. We’ll see how DMVPN allows for zero-touch hub deployment and also how dynamic tunnels are built between spoke sites.
So we have simple lab set up here. We have three routers. This guy is acting as a hub, and then we have two spokes. This is actually just a switch, and I changed the symbol to look like a cloud because in DMVPN we actually are going to be connected usually to an ISP cloud, could be an internet cloud, or something. So I just changed this to look like a cloud. Right.
So let’s look at the configuration. This lab don’t focus on configuration, so it’s already configured, so I’m just going to run through the configuration.
So basically, for DMVPN you can configure your ISKMP policies, you configure your key. In this case we’re using a wildcard key of zero dot zero, so you can match anybody. This is not as secure, but imagine if you have 500 host, the old style of configuring all the keys one by one. That’s why on the hub you usually use a something like a wildcard ISKMP key.
Now you have your transform set here, and then we match it in a profile. Now this is the tunnel, this is where a lot of things are done. So look at the IP address we are using for your tunnel, right? And then look at some … Now some of the things that are important here are the IP NHRP map multicast dynamic, the network-ID, and a couple EIGRP commands. Since we’re using EIGRP to tunnel source, notice that the tunnel mode is GRE multipoint, and then we’re adding IPSEC on top of that. That’s really about it.
Now for your EIGRP, notice that we are matching the tunnel interface and not the physical interface. That’s very important because you are running EIGRP over the tunnel. So it’s secure over the tunnel. Now remember DMVPN can actually carry multicast traffic so that’s why we can actually run EIGRP over the tunnel. So that’s about it here.
And if I come here, the configuration is similar, so show run. Show irun. Show run. Similar configuration, like I said. We configure our policy key, configure our transform set. Now in the tunnel, in the tunnel configuration, it’s slightly different. Here you’re creating a map between the physical NHS, that’s the server, or the hub. So the tunnel IP address of the hub and the physical IP address of the hub, right? And then you create some other, you match another multicast, then you specify the server. Right. So that then. Good.
So if I were to check show IP route, I would see that 1.1, this is coming from the hub, and 3.3 is coming from the other spoke. A couple of things I’m going to do here [SYSY 00:03:06] is in IPSEC so I can check the IPSEC SA. So right now, you noticed that there’s only one IPSEC SA and it’s with the hub, right? So this is the IP address of the hub, right? I’m sorry, I mean ISKMP SA, right, so that’s ISKMP. Now let’s check the IPSEC SA, and then you also notice it’s only with the hub also, that’s this, and then some packets have been encapsulated and decapsulated so as [inaudible 00:03:34] those are like control packets, like EIGRP, and stuff like that, right?
So one other thing, if I were to check IP, show IP NHRP, I can see that we’ve created a static mapping. We created a static mapping to the hub. On the hub, let’s check this. On the hub IP NHRP, you see that those are dynamic because it’s like the spoke went to find the hub. So that’s why we say on the hub it’s like zero-touch configuration. Once you’ve configured the hub once, then you don’t need to touch it again.
So let’s go back to the spoke. And one thing I can do … Let’s ping 1.1.1, right, which is the hub. Now if I were to check my IPSEC SA, so right now it’s on 76, right? So let’s use a repeat of, say 10, and if we check it again, as you can see, it’s been encapsulated and decapsulated. So that’s one way you know whether things are actually going through your tunnel. It’s very important to check that things have been encapsulated and decapsulated over the tunnel. Right.
Now what if we want this spoke to ping a host on this guy to reach a host on this guy? Right.
With DMVPN we can actually find dynamic spoke-to-spoke tunnels, right. So, let’s say we want to ping 3.3.3. So right now, let’s look at what this is saying. This is saying about 96 and 94, okay. So if I ping 3.3.3, let’s say I repeat it for 15, right. So if I check that IPSEC SA again, I can see that this has gone to 105. But one thing that you notice is that it has also created another IPSEC SA. So it has created another one with this spoke, too, right? And as you can see, the packets have been encapsulated over that dynamic spoke-to-spoke tunnel. We have 10. So it means that about three or four packets were encapsulated over the hub, that’s over the tunnel between the hub, and then the hub said, “Oh, no, you can actually create dynamic spoke-to-spoke tunnels,” and then all the packets were encapsulated over the dynamic spoke-to-spoke tunnels.
CCNA Quad Instant Pricing – Intense
So the way that we know it’s going over the dynamic spoke-to-spoke tunnels, let’s ping again. Right now it’s on 10 and 11. So if I use another 15, this should go 25 and 26. So let’s see. All right, so there we go. We have a 25 and 26. Good.
Now if I were to check our show crypto ISKMP SA, let’s check the ISKMP SAs. So you notice it has created an ISKMP SA with this spoke too, and if I were to check the show IP NHRP, I can now see another a dynamic NHRP entry on this guy. So basically this is how we have our spoke-to-spoke tunnel, right?
So DMVPN is actually really cool because on the hub you don’t really need to do anything. If I add another spoke I don’t need to do anything. On the hub, I just need to configure the spoke, and you can use a template for the spoke, and then everything is very easy. And then you can have dynamic spoke-to-spoke tunnels between your different spokes. So everything doesn’t have flow through the hub. So that’s really cool.