Dynamic multipoint VPNs are indeed very amazing.
In this video, I'd like to take a look at why they're amazing,
what they do for us, and introduce you
to a few components in the mix that make it all possible.
So let's use this network.
And let's imagine that this represents
three different sites.
Maybe this is the headquarter site up here.
And this is site 2.
And over here we have site 3.
And we need some basic connectivity.
So let's also imagine each of these three routers
has some connectivity to a network.
It could be the internet.
It could be a private network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It could be a private network.
It could be MPLS, what have you.
But they've all got connectivity.
And they've got these reachable addresses.
So R1 is 15.1.1.1.
R2 is this guy.
And R3 is this guy.
And from a color-coding perspective,
I color-coded these IP addresses in yellow, the publicly
reachable IP addresses.
In DMVPN speak sometimes they refer
to those publicly reachable addresses as the NBMA,
as a Non-Broadcast Multi-Access Address.
So whenever you see this keyword,
just think about the reachable address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just think about the reachable address
that each router can use to reach the other devices.
Now, as the name implies, we are going to build some tunnels.
And they are going to be GRE-based.
And we're going to have some tunnels that look like this.
And the tunnels also are going to have a network address
space.
And so the network address space we're going to use is this guy
right here, 172.16.123.R, where R represents the router number.
So R1 would end in .1.
R2 would end in .2.
R3 would end in .3.
And the cool thing is that instead of using a separate GRE
tunnel interface, one from R1, another one from R1 to R3, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tunnel interface, one from R1, another one from R1 to R3,
we're going to use a special type of GRE called
an mGRE, a multipoint GRE interface,
so that R1 can have one tunnel interface here,
and then it can have multiple connections off of that.
We're going to use that same treatment down here
at site 2 and site 3 as well.
So whenever I refer to the tunnel IP addresses,
I'm talking about the tunnel IP addresses
on the tunnel interfaces.
Now, here's the kicker.
Let's say we have a user like Bob, who's over here at site 2.
He's on the 10.2 network.
And he wants to send traffic over to a resource over here
at site 3 on the 10.3 network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at site 3 on the 10.3 network.
I'll put a server there.
That traffic might have to go up to the hub, the R1, who
would then have to route it.
However, if we trained R2 that the next hop to get to the 10.3
network was 172.16.123.3.
And if you're thinking, "Hey, that seems familiar,"
that's the tunnel IP network address space.
If R2 believed that was the next hop,
that would trigger R2 to go ahead and forward
the traffic directly to R3.
Now, the problem is how does R2 know
what R3's public address is, the reachable address, the NBMA WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what R3's public address is, the reachable address, the NBMA
address.
The answer is we are going to use yet
another protocol for that.
And that protocol is called NHRP, the Next Hop Resolution
Protocol.
So by using GRE, multipoint GRE tunnels, and next hop
resolution protocols, we can have a situation
where R2, if it needs to send traffic
from itself over to 10.3, it can not only learn about that
and learn about the next hop via NHRP.
But also, if there's no tunnel in place, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But also, if there's no tunnel in place,
it can dynamically negotiate a tunnel between R2 and R3,
build that tunnel, and then start
routing the traffic directly from itself over to R3
over an IPsec tunnel.
And that way the traffic no longer has to go over the hub.
So here's the big picture.
If we have a hub or two that we configure,
we have spokes dynamically check in with those hubs,
and then dynamically build tunnels with each other,
spoke to spoke to spoke.
If we need to, they can send traffic directly,
all without having to manually configure
those specific IPsec tunnels between all the spokes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
those specific IPsec tunnels between all the spokes.
It's amazing.
So here is what we get to do.
We're going to think this topology with these three sites
and we'll walk through the configuration step by step.
And as we go, we'll verify that each piece works
until we have a fully functional IPsec-protected DMVPN network.
So I'll see you in the next video.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.