It's time-- it's time for some hands-on with DMVPN.
[MUSIC PLAYING]
So we are going to use this topology
and here's what I've done in the labs
to make this more of a learning exercise
and not just a "type 2000 commands" exercise.
I've got in the lab two sets of scripts.
I've got one which does DMVPN with no IPSec.
So that way, we get all the bells and whistles
and features of DMVPN but we can also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and features of DMVPN but we can also
take a look with packet decodes if we need to
and take a look at what's going on.
And then I have a second version that includes the IPSec.
So, as a reminder of the network topology,
everything in red here are the internal networks from
the customer's perspective at headquarters-- the hub site--
and sites 2, 3, and 4.
Here we have the internet-reachable networks.
And for the GRE tunnels, we're going
to use the 10 network with .1, .2, .3, and .4, respectively.
There's also a couple additional commands
that we are going to need to use in this topology to make it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we are going to need to use in this topology to make it
work, so let's do a quick review of those,
and then we'll implement them and we'll see it work.
All right, I love me some DMVPN.
So let me go ahead and minimize PuTTY.
This is on DCNUG, our management computer.
And here I have the scripts for DMVPN no IPSec.
And I'd like to open those up.
All right, so let me bring those two up.
There we go.
So let me point out these commands
will identify what might be slightly new,
so config t, interface Tunnel0, bandwidth is fine. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so config t, interface Tunnel0, bandwidth is fine.
IP address on R1 will be 1.
MTU, the authentication for NHRP is that.
The nhrp map multicast dynamic means
that R2 and R3 and R4 when they register
can dynamically register with the hub and it'll accept it.
We have a network-id, a hold time.
Oh, these are really important.
So let's talk about split-horizon for a moment.
The network-- the overlay network that we're
laying on top of the infrastructure-- behind it
we have the internet and everybody's connections to it,
but the overlay network is going to be our DMVPN GRE tunnels, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but the overlay network is going to be our DMVPN GRE tunnels,
and they are going to look like this.
And it is the 10 network.
So 10.1 here, .2, .3, .4.
Now, this is going to be a multipoint interface by default
from R1 because he's got three tunnels coming into that one
GRE interface, and that's OK because it says right here GRE
multipoint-- he can support it.
But from a routing perspective-- so this is a 172.16.2 network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But from a routing perspective-- so this is a 172.16.2 network
right here, and when that network is advertised via EIGRP
and received on this interface, there's
a little thing called split horizon which says,
hey, dear router, if you're running a distance-vector type
routing protocol-- which EIGRP certainly is, it's advanced
and a hybrid, kind of, but it isn't just
a distance-vector routing protocol.
When it learns about the 10.16.2 network on this interface--
tunnel zero--
it says, well, I learned about it on this interface.
I shouldn't advertise the same network on that same interface.
That's split-horizon.
So that's what I'm doing right here,
is I'm disabling split-horizon because I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is I'm disabling split-horizon because I
want R1, when it learns about this network on this tunnel
interface, I want him to advertise it
here and here to all of his other buddies
that are off of that same multipoint GRE tunnel
interface.
OK, so that's the split-horizon piece.
The next-hop-self-- I'm turning that off, as well,
because if R2 advertises a route for 172.16.2,
and he advertises up to R1 and it has the next hop of .2,
if R1 advertises it down to R4, it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if R1 advertises it down to R4, it's
going to have the next hop of .1.
R1's going to say, hey, I'm the next hop.
What we want to have happen, if you're using phase 2
or higher-- we'll take a closer look at that, as well,
as we proceed through these videos--
if we want R4 to ever create a tunnel--
I'll go back to blue--
over to R2, R4 needs to see, oh, in its routing table 172.16.2,
the next hop is .2 and that causes
R4 to do the query to find out what the reachable address is
for R2 so we can build the tunnel over to R2.
So if R4 simply thought that this was reachable via .1-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if R4 simply thought that this was reachable via .1--
10.0.0.1-- it would never have a desire or need or even
knowledge of building its own tunnel over to R2.
And that's why I'm doing this command right here, no
ip next-hop-self eigrp 1.
It basically says to R1, hey, when
you learn this route 172.216.2 and the next hop
is .2, just when you're advertising off
that same interface, leave that next hop of 10.0.0.2,
and that way R4 will see the next hop in the routing table
of 10.0.0.2.
All right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right.
So that's new information.
I want to make sure I was clear on that.
And tunnel source is Gig 0/0, that's
the internet-facing interfaces on all of our devices.
And tunnel key-- OK, here for our routing protocols,
what I'm doing is I'm including the GRE
network, which is the 10 networks, and also
the local networks.
So I've got-- let me put black here, actually,
let me color it red, so--
actually, let me get an eraser out.
Tools! WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Tools!
All right, so here we go.
So 172.16.2.0 is here.
172.16.3.0 is here.
Wow, look at that.
I didn't even ask for that.
And then off of R4 is 172.16.4.0 and up here off R1
it's 172.16.1.0.
All right, so I'm basically including the local networks
and the GRE network as part of my routing protocol,
so all that will be communicated. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so all that will be communicated.
And I think, also on these routers,
I also have in a separate config the loopback interfaces
of 1.1.1.1 and 2.2.2.2 and 3.3.3.3,
and so forth, also included inside
of the EIGRP routing process.
All right, so that's the configuration for the hub.
I've got the configuration for the spokes.
We've been through those in the previous video.
Oh, also one thing--
this is interesting-- when we apply these scripts,
I'm going to go ahead and have us exit out of privileged mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to go ahead and have us exit out of privileged mode.
It'll exit us off the console on these devices
and require you to log back in as Bob.
You know, labs are interesting.
So anyway, long story short, if I go into EIGRP configuration
mode, or if we do, for whatever reason,
when we exit all the way out back to privileged remote,
we lose all of our rights.
There's no permissions.
We can't do anything.
So if you find yourself in that situation,
just go ahead and type in exit and then log back in as Bob
and it'll be right back to where this lab initially started.
Just a little side note. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just a little side note.
All right, let's do this.
I'm going to grab the config here, just copy it, highlight
it, right-click, Copy.
Make sure we're on R1, the hub, paste, and exit.
And then I'll press Enter and just log in as Bob.
All right, so that is done.
So show interface tunnel 0.
There is tunnel 0, and he's pretty lonely right now.
(SINGING) I'm so lonely--
show ip nhrp-- because I know nothing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
show ip nhrp-- because I know nothing.
Nobody's checked in yet.
Nobody's registered with me.
I'm just one end of a tunnel waiting for dynamic spokes
to chime in.
So let's go to the spokes.
And here is the first spoke, which is R2.
So we took a look at these commands and the details
for those commands, right-click, Copy, and let's go to R2.
The hardest part is don't put it back on R1, put it on R2.
So right-click and then we'll go back in as Bob. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So right-click and then we'll go back in as Bob.
And there's our tunnel.
It came up.
And there's our adjacency over the tunnel, our EIGRP
adjacency.
And if we do this, show ip nhrp, and that's the server
that we just built the tunnel to.
So this says, basically, this address, 10.0.0.1,
is available at the reachable address
on the internet of 11.1.1.1.
And if we go to R1, and do that same command, show ip nhrp,
now R1 knows about R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now R1 knows about R2.
It knows about the tunnel address of 10.0.0.2
and how to reach it at 22.2.2.2.
That's because R2 just registered a few moments ago.
All right, and if we look at the routing table,
this will be fun, show IP route for eigrp learned routes,
we have two routes.
We know how to get to the 2.2.2 network
and we also need know how to get to the 172.16.2 network,
both of which are owned by R2.
So if we send traffic to either of those addresses or IP
addresses in those networks, what would happen
is the packet would be logically created WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is the packet would be logically created
in the mind of the router.
It would then add a GRE header.
It would then add the outer IP addresses.
The source would be from R1's perspective,
it would be 11.1.1.1.1 and the destination
would be 22.2.2.2.2, shipped over the tunnel.
R2 would receive that, de-encapsulate it,
and then forward it on to the destination
it was intended to go to.
All right, let's continue on and bring in the other spokes.
So bring in R3.
So there's R3's config. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's R3's config.
We'll do the copy and go to R3 and paste that in and log back
in as Bob.
And now we just show ip nhrp and we'll just show ip route
for eigrp learned routes.
We're learning more routes, so we now
have knowledge of the 2.2.2.2 network
and the next hop is 10.0.0.2 and that's
because R1 is playing that game where he's not swapping out
the next hop as he re-advertises that route
out the same interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
out the same interface.
And if we go to R1 and do a show ip nhrp,
it now knows about those two people
R2 and R3 that just registered.
And let's do R4.
And we'll go to our text file.
Here's R4.
We'll get the whole thing, Copy, paste,
and we'll log back in as Bob.
So now here's what we have.
We've got R1, which is the hub.
He knows about the three spokes that have registered. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
He knows about the three spokes that have registered.
He's got three logical tunnels off that tunnel0 interface.
And if we do a show ip route--
[LAUGHING] and it says I don't know what that is.
Let's do show ip eigrp interfaces--
there we go-- and show ip eigrp--
this will tell a good story--
neighbors.
Look at that.
So we have three neighbors off of our one logical tunnel
interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
interface.
And if you do a show ip route for eigrp, there we go.
We've got routes that are learned
from R2's side of the house, R3's side of the house,
and R4's side of the house.
And here's an example of EIGRP messages that are being sent.
So the source-- this is R1, at 10.0.0.1,
sent to the multicast address of 224.0.0.10,
but check this out-- so here's the Ethernet information.
There's the IP header that the internet
is using, sourcing it from 11.1.1.1 going to 22.2.2.2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is using, sourcing it from 11.1.1.1 going to 22.2.2.2.
And then we have the GRE and then the header right
after that, which is the actual destination.
So what happens is this packet is multicast from R1.
It says, oh, I need to send this,
and it takes that multicast with the source and destination,
it wraps it up in GRE, and then it puts the appropriate IP
header for the routable addresses for itself
as the source, the IP address for R2 as the destination,
and it ships it.
The internet delivers that based on that header,
then R2 de-encapsulates and actually processes
the hello for the EIGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the hello for the EIGRP.
And the fun continues.
Here's an EIGRP hello from R2 to R1, so it's a multicast
but it was taken, wrapped up, encapsulated,
and then the GRE header and then the IP header for transit,
which has a source of 22.2.2.2, R2's reachable address,
destination 11.1.1.1, R1's reachable address,
shipped, so all the internet sees is the outside IP header
and then R1 receives it, de-encapsulates it,
says, oh, EIGRP hello message.
Fantastic, I'll process that.
So let me show you something else truly amazing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let me show you something else truly amazing.
Let's imagine that we're at R2.
We're at R2.
If we do a show ip route, let's just
do it for EIGRP learned routes.
And what's about to happen is so amazing.
If we do a show ip nhrp, here's what R2 is saying.
It says I'm on the 10 network--
my address is 10.0.0.2, but I know about 10.0.0.1
and what the reachable address is I
need to send to reach that 10.0.0.1,
but I don't know anything else about R3 or R4, says R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but I don't know anything else about R3 or R4, says R2.
So we look at the output for show ip
route for EIGRP learned route.
What would happen if we had to send a packet to 172.16.4--
we have a host, PC4, it's literally at 172.16.4.10.
The next hop is 10.0.0.4 and R2 does not know--
I repeat does not know--
how to reach 10.0.0.4 because it doesn't have a mapping.
So here's what's going to happen.
If it gets traffic destined for this network
and it sees this as the next hop, NHRP kicks in. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it sees this as the next hop, NHRP kicks in.
And what's going to happen is this router is
going to make a request and send it to the hub--
the next hop server-- and say, hey,
I need to know what the IP address is,
the reachable IP address, the NBMA address
associated with 10.0.0.4 because I'd like to build a tunnel
and send traffic his way.
So I'm going to draw this out to talk about it for a moment.
So here's R1, there's R2, and there's R4.
So here's what's about to happen-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here's what's about to happen--
R2, when it needs to send a packet--
we're going to send a packet to 172.16.4.10--
it's going to go ahead and immediately make a request,
and that request says, hey Mr. Next hop server,
I need to know what the NBMA or the real reachable address
is for 10.0.0.4.
So R2 sends that request.
Now R1-- does he know the real address behind 10.0.0.4?
He does.
He does because R4 registered with him.
However, I like this attitude.
R1 says, instead of me just answering you directly, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R1 says, instead of me just answering you directly,
I'm going to go ahead and pass on your request to R4
and then that request is going to have
the information about the reachable address for R2
and, R4, please tell R2 what your address is.
So that request goes up to the hub.
The hub sends that same request down to R4
and then R4 responds directly to the publicly reachable address
of R2 saying, hey, here's the information you asked for.
It's a miracle.
I mean, it really is amazing.
At that point, R2 now knows what the address is
and they'll build a tunnel and subsequent packets that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and they'll build a tunnel and subsequent packets that
need to be routed between each other with them
as their next hops are going to be sent over that GRE tunnel.
And if we're using IPsec, it would also
be protected if we had the IPsec profile applied.
That's how it works.
Now, also, this is also quite interesting.
When R2, if he's trying to ping the 172.16.4.10, which
is a PC hanging off down here, it'll make that request,
but what it also does it will send the initial packet also up
to that NHS server.
And so what happens is this server says, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so what happens is this server says,
OK, I got a couple of things going on.
I'm getting this request, which I'm sending down to R4,
and I'm also getting this data packet, this transit packet,
that needs to be shipped down to that network.
And it will actually route it on behalf of the network down
to R4 while these guys figure out their shizzle
and get that tunnel going directly between them.
So what we should see if we do a ping to that address or even
a trace, we should see the first packet or the first hop
in that packet--
we should see the first hop go through R1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we should see the first hop go through R1,
like 10.0.0.1 as the first hop and then go down to R4.
And then after the GRE tunnel's built between these two,
then we can see them go directly back and forth
between each other without having to go through the hub.
So that's the magic in the background.
The best way to demonstrate that is--
we could do a couple of things.
Let's do the simplest, the cleanest one first.
Let's do a trace to--
and also what we could do is we could
go to PC2, which is hanging off of R2,
and just ping R4's PC4's address, that would also do it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and just ping R4's PC4's address, that would also do it.
PC4 is 172.16.4.10.
Or we could do it from the router--
totally your choice, either way works great.
So we'll go to R2 and we'll do a trace to 172.16.4.10
and I'm also going to source it from my local network.
So I'm going to do a source and that's going to be Gig 1/0--
that's my 172.16.2 network that R2 is connected to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's my 172.16.2 network that R2 is connected to.
You don't have to do that, but I just want to see if we trace it
or whatever, I want to see the IP addresses involved.
OK, so what happened there was it
went through R1 as the first hop.
Oh look, at this--
[LAUGHING]---- we caught it, two packets in.
I love this.
So what this is showing us here is that for our traceroute,
it uses three packets with a TTL of one,
then three more with a TTL of two,
and so forth to get the path to the network fed back to us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and so forth to get the path to the network fed back to us.
So this shows us that the first two at 120 milliseconds and 72
milliseconds went through 10.0.0.1--
that's the hub.
And this last one here, the third, went directly to R4.
So that's pretty darn quick.
So the request learned before the resolution happened
and the initial packets were routed through the hub,
and then the third packet of that trace
actually went directly across.
So you might say, Keith, is that really would happened? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So you might say, Keith, is that really would happened?
And we should verify that.
Let's do a show ip nhrp, and look at this, we now know--
we didn't a moment ago, but now we do--
we know how to reach 10.0.0.4, that's
the next hop from the routing table for 172.16.4
and we know his reachable global address on the internet,
sometimes called the NBMA address.
Oh, it says right there, NBMA address.
And let's do this--
let's do another trace to that same address.
You'll notice it's not going through R1 at all, not even WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
You'll notice it's not going through R1 at all, not even
the first hop because we have a GRE
tunnel built between those two.
So if we were to do it again, let's go to R3.
In fact, let's go from PC2 to PC3.
PC2 is off of R2, PC3 is off of R3.
So PC3's address is this bad boy right here.
And we'll go ahead and on PC2 we'll just maybe do a ping.
Or we can do a trace.
So on this little virtual machine, if you trace, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So on this little virtual machine, if you trace,
it uses UDP by default, I believe.
You can do a capital P and then 1 and that uses ICMP.
It's a little bit cleaner.
All right, so there's our trace.
So from the PC it went to R2, which is this guy,
and then the next hop was R1, and then the final hop was R3--
or the host on R3.
So if we had the up arrow key again, look at this magic.
No hop through 10.0.0.1 at all--
that's because it built a tunnel. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's because it built a tunnel.
So if we go back to R2 and do show ip nhrp again,
now it knows about all three of them.
It knows about R1.
It knows about R3.
It knows about R4, along with their reachable global net
addresses.
Oh my gosh, it's so much fun.
In preparation for this, here's what I also did.
I'll share this with you real quick and then we'll close off
and we'll go to the next video, where we
can add IPSec on top of this.
Let me bring this up real quick.
OK, this is R2 making its resolution requests. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
OK, this is R2 making its resolution requests.
So R2 asking about 10.0.0.4-- how do I get there?
So R2 makes this NHRP request, and then this
is showing R1 sending that request down to R4--
I did two separate protocol captures at the same time--
and then this is R4 replying directly back to R2.
And I thought, is that really happening?
And it sure enough is.
So this is referred to as DMVPN phase 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is referred to as DMVPN phase 2.
And we'll take a look at phase 3 and what that means
in a separate video coming up, but it's wonderful.
It works and allows dynamic tunnels
to be built initially between lots and lots of spokes
with the headquarter site and if the traffic patterns demand,
they can build dynamic tunnels from spoke to spoke and forward
traffic directly that way.
It's a wonderful thing.
All right, so without further ado, in the next video, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so without further ado, in the next video,
we'll take a look at implementing DMVPNs again,
but this time we'll add on top of it
IPSec, which makes them protected and encrypted
so that anybody along the internet who might look
at our packets is going to see the source and destination
public addresses.
They'll see it's using ESP for encryption
as part of its cryptography, but they won't
be able to see the payload.
They won't know if it's a ping or if it's
a data file or anything else because of the encryption.
So I'll see you in that lab in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I'd like to thank you for viewing.