One of the required elements to get DMVPN working
is to have the correct commands in place,
whether we place those there manually
or whether we do it through network automation.
Either way is great, but the commands need to be there.
So in this video let's take a look at the configuration
we would place on the hub as well as the spokes.
[MUSIC PLAYING]
And as we do that, here's the reminder of our topology.
It has not changed since the last time we looked
at it in the previous video.
We have the internal networks at Site 1 as 172.16.1.0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have the internal networks at Site 1 as 172.16.1.0,
and then Site 2, Site 3, Site 4.
And then the reachable, the public,
sometimes referred to as the NBMA addresses,
are the 11, 22, 33 and 44.
And then the overlay network that we're
going to put on it, the GRE tunnels, that's
all going to be 10.
So there's a lot of commands that
are going to be implemented for a DMVPN solution.
This is Cisco's online doc.
Let me go ahead and just share with you
real quick exactly what we're looking at.
Probably any similar release would do.
So this is the "Dynamic Multipoint VPN Configuration
Guide Cisco IOS Release 15M&T." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Guide Cisco IOS Release 15M&T."
And they're all going to be pretty much the same,
just the framework of commands that we would do
for both the hub and the spoke.
And here is a good overview, and then down below
has some details.
Let me share with you a few of the highlights.
And a lot of these are going to be very familiar to you,
and there will be a few that will be new.
We'll take a look at all of them.
And let's start with this one.
OK.
Gets you into privileged mode.
We're good there.
And going down to config t, we're good with that, too.
Interface and the tunnel we want to go ahead and create.
So in our case, we're going to create Interface Tunnel 0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in our case, we're going to create Interface Tunnel 0,
but you can use any tunnel within the numbering
scheme allowed.
And the secret is we only need one tunnel interface
per router, whether it's the hub or whether it's the spokes,
because they're going to be multipoint GRE tunnels that can
support multipoint networks.
So if we have 1,400 peers, we don't
need to have 1,400 interfaces.
One tunnel interface.
So that's what that command is right there.
And then we're going to give that tunnel interface an IP
address.
So in our topology, we're going to do 10.0.0.x, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in our topology, we're going to do 10.0.0.x,
with x representing the router number.
So Router 1 will be 10.0.0.1, R2 will be 10.0.0.2,
and so forth on the tunnel interfaces.
And then we have an MTU that's being set.
The benefit of setting the MTU is
that we want to avoid getting a packet
so large that it has to be fragmented by the router
because we are going to be adding headers.
We're going to add a second IP header, a GRE header.
So by setting it to 1400, artificially lower
than what the default would be, we're
giving ourselves a little bit more room WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
giving ourselves a little bit more room
to add additional information and still not have to fragment.
In fact, that, along with-- let me go ahead and scroll down
to this.
It would be great if they were next to each other,
but that's OK.
That, along with this, would also be very helpful.
So this is the TCP MSS of 1360.
And, with the MTU of 14 that we set just previously,
1360 is the recommended for the TCP adjust-mss value
right here.
So 1400 for IP MTU, and 1360 regarding the TCP adjust-mss. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So 1400 for IP MTU, and 1360 regarding the TCP adjust-mss.
All right.
So continuing on, the Next Hop Resolution Protocol
is going to be used by spokes, for example, like R2.
If it sees, oh, the next hop to get to the 172.16.4.0 network,
the next hop is 10.0.0.4, but I don't
know what the real address is, the internet
address is for that.
So it's going to use NHRP.
But, at the same time, we don't want
everybody who's anybody to be able to use NHRP,
so we're going to set up some authentication.
Next, we have the IP NHRP map multicast dynamic.
This is on the hub.
And so that when clients like spokes-- like spokes R2, R3, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so that when clients like spokes-- like spokes R2, R3,
and R4--
when they connect up to R1, the hub, and they register,
this allows the hub to remember and allow those registrations.
So the hub knows, oh, R2 showed up.
And its GRE address is 10.0.0.2, and its real address
on the internet that people can send packets to to reach it
is 22.2.2.2.
This simply allows those registrations
to be dynamically learned at the hub.
We are also going to assign a network ID for the NHRP
that needs to be consistent on each of the routers, as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that needs to be consistent on each of the routers, as well.
We're going to specify for this tunnel interface the source.
In our case, it's going to be Gig0/0.
On all four routers it's Gig0/0 facing the internet.
So in our case, it would be Gig0/0,
or you could specify the IP address
for the source of the tunnel.
And again, for the destination, we
don't need to specify the destination
because they'll dynamically connect and register with us.
On each of the tunnel interfaces that
are participating on the routers in the DMVPN
we want to specify the same exact tunnel key. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we want to specify the same exact tunnel key.
And that is a number between 0 and it
looks like eleventy billion.
What is it?
No, 4 trillion something?
So, lots of range there, but that
needs to match, as well, to make it work.
This command here, tunnel mode gre multipoint,
simply allows us to have multipoint GRE
tunnels off of one logical tunnel interface.
So Tunnel 0 from R1 is going to have three tunnels
right away to 2, 3, and 4.
And R2 is going to have one tunnel initially to R1,
but more tunnels if it needs to generate traffic
that needs to go from R2 to R4 based on the routing tables. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that needs to go from R2 to R4 based on the routing tables.
So we need to specify tunnel mode gre multipoint
to make that possible.
And then we go ahead and apply the IPSec profile
on the tunnel interface.
This simply says, OK, any traffic in or out,
I'm going to go ahead and apply cryptography to it.
So, initially, what we're going to do
is we are going to not apply cryptography.
We're just going to do DMVPN without the IPSec.
And that way we can see the details,
and if we want to do protocol captures
we can see all the headers.
And then we can simply add the IPSec profile after the fact,
and then have our security and our DMVPN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then have our security and our DMVPN.
So it's a win-win.
But that's what this is doing right here.
And as we implement this, we're going
to overlay on top of the GRE network.
And also, for our internal networks at all the sites,
we're going to go ahead and implement
EIGRP as the routing protocol.
EIGRP makes its decisions about how good a path is
based on bandwidth and delay.
There is a part a little lower where it talks about delay,
and here it talks about bandwidth
for that tunnel interface.
You can tweak those values if you
need to make one path seem more preferred or less preferred
than another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
than another.
And as you scroll down, there's the adjust TCP for 1360--
again, 40 less than the IP MTU.
And then we have a hold time.
If use the default, that would probably work, as well.
The recommended range is between 300 and 600.
And then there's the delay, which
would be mostly important to a routing protocol that
looks at bandwidth and delay as part of its metric calculation,
like EIGRP does.
And here's the spoke configuration,
which is a little bit less.
So, for the spoke, we're going to have a few commands that
are similar and a few commands that
are unique just to the spokes, including telling WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are unique just to the spokes, including telling
the spokes, hey, when you get going and set up,
here's who you need to go register with,
which is going to be the IP address of R1.
This is the overview of the commands.
Let me walk you through the ones that
are a little bit different than the hub.
So enable, config t, interface tunnel,
whatever tunnel interface you want to use,
IP address we're going to use on the tunnel interface.
If it's R2, we're going to use .2.
If it's R3, we're going to use .3.
The 10 network is our GRE network.
The MTU of 1400, just like we did on the hub.
Specifying the NHRP authentication,
just like we did on the hub. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just like we did on the hub.
Now, this is different right here.
This is [INAUDIBLE] the spoke regarding the mapping,
or association between this address, which
is the GRE tunnel address that we
assigned to the hub and the reachable address.
So in our case, I'm going to cross that out because our case
it would be 11.1.1.1.
And up here, when it refers to the NBMA,
just think of that as the real reachable
IP address on the internet to reach that next-hop server
at 10.0.0.1.
So that's the mapping between those two.
Just remember it's the VPN first, and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just remember it's the VPN first, and then
the real physical address second, as far as the syntax.
And what this says to the spoke--
if you ever have broadcast or multicast traffic, like maybe
EIGRP updates or broadcasts and you need to send
them, who do you send them to?
And the answer is we're going to send them to--
and I'm going to put the physical address here.
And that is the hub at 11.1.1.1.
So ip nhrp map multicast, and we specify
the IP address of the hub.
Next, we're going to specify who the next-hop server is.
So if R2 or another spoke needs to figure out, oh, I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if R2 or another spoke needs to figure out, oh, I
need to figure out the real address behind 10.0.0.2,
or 10.0.0.3, or 10.0.0.4, it needs to know who to ask.
And so ip nhrp, Next Hop Resolution Protocol-- nhs,
Next Hop Server--
and then we put the GRE, the tunnel address of that server,
which, literally, in our case is going to be 10.0.0.1.
Now, behind the scenes, this client
also knows that the mapped address
to that, the real address, is 11.1.1.1
from our previous commands.
So what it'll do, it will send a packet to 10.0.0.1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what it'll do, it will send a packet to 10.0.0.1,
but it will then encapsulate that and then
also add the header of 11.1.1.1 before it ships it.
The internet will be routing based on this IP address
right here.
R1 will receive it, de-encapsulate it, and then
take a look at the request.
And then we have the network ID that we
had also on this server.
And then we're going to specify the tunnel source.
So on all of these branch routers,
the exit interface, or the egress interface
that connects to the internet, is going to be Gig0/0.
So we can specify the IP address.
Like on R2, it would be 22.2.2.2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Like on R2, it would be 22.2.2.2.
Or we can specify Gig0/0.
Either way is great.
And then we have the tunnel key, which,
again, is going to match on all the devices participating
in DMVPN.
And then we're going to specify it's a multipoint GRE
tunnel, which allows it to have multiple termination points
from one tunnel interface.
And then we have the rest of these commands,
which are very similar to what we had on the hub.
In fact, they're identical.
Including bandwidth and delay that we'd
use as part of tuning or tweaking
a routing protocol like EIGRP.
The adjust mss for TCP segment size to 1360, 40 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The adjust mss for TCP segment size to 1360, 40
below the IP MTU.
And the timer is similar as we had up on the hub.
So now that we've taken a look at all of those commands, what
I'd like to do is, instead of in this video applying them,
let's do this.
Let's cut it off right here for this video.
And in the next one, we'll start up in a lab.
I'll also supply some templates that we
can use so we don't have such a job of manually typing
all those commands in.
But we can still implement them and see the results
in a DMVPN solution.
So, having said that, we'll see you in the next video
to start with the hands-on lab portion
for implementing DMVPNs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for implementing DMVPNs.
I hope this has been informative for you.
And I'd like to thank you for viewing.