If we have multiple sites around the world and they're all
connected to the internet-- some with DSL, some with cable,
some through service providers and what have you--
is it possible to have a secure and overlay network
between all those sites using the internet as a backbone?
The answer is yes, we can.
[MUSIC PLAYING]
And over the years, there have been several different attempts
and methods for using the internet
to connect various sites together.
So let me walk you through a really short history lesson
of some of those attempts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of some of those attempts.
So here, we have four routers representing four sites.
And they can be anywhere in the world.
They're all connected to the internet.
So R1 will be at site 1, R2, site 2, R3,
site 3, and R4, site 4.
And one of the attempts of using the internet securely
to connect these sites together was
to use site-to-site VPNs, which mean IPSec.
So the IPSec protocol suite has developed and grown over time.
It's really secure these days.
But you know what?
It's never been really easy to implement site-to-site tunnels WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's never been really easy to implement site-to-site tunnels
the way we used to.
For example, what we do is we go, OK, well,
what's your address here, R1?
11.1.1.1.
What's your reachable address on the internet, R2?
22.2.2.2.
And then we'd say, OK, great.
We're going to build an IPSec peering, or tunnel, an overlay
network, a tunnel, from R1 to R2, based on those addresses.
Then we'd use crypto ACLs.
We'd say, OK, we want to encrypt anything that's coming from
172.16.1-- that's our inside network here at this site-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
172.16.1-- that's our inside network here at this site--
going to 172.16.2.
That's their network.
And we'd build the crypto ACLs.
We'd configure them.
And then we would set up that tunnel, and away we go.
Now, that is a lot of work to do all that manually.
It really is.
There's a lot that can go wrong, especially if using IKE version
1, with IKE phase 1 and IKE phase 2, and the crypto
ISAKMP policies, and the IPSec policies,
and the transform sets.
It's a lot of work.
But we could.
And so we could set one up between site 1 and site 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we could set one up between site 1 and site 2.
Another one between site 1 and site 3.
Another one between site 1 and site 4.
And then, if R4 wanted to send traffic over to R2,
it could send it up this tunnel.
And R1 could get it and route it down here.
But-- oh my gosh.
I forgot to mention, once you have these multiple sites
involved, the crypto ACLs to identify what traffic should be
encrypted and what traffic shouldn't be encrypted,
that gets really, really difficult the more sites we
bring into the table, especially up here at the center point,
or the hub.
So site-to-site VPNs, they are a thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So site-to-site VPNs, they are a thing.
And they could work.
But they're not as effective because of the complications
that have to be put in place to make them work.
They are tricky.
All right.
So what's another option?
Another option would be we could create GRE tunnels.
So we could do this.
We could create logical GRE tunnels between R1 and R2.
So GRE is protocol 47.
And what we could do is simply say on R1,
we have tunnel interface 1 and tunnel interface 1 down here.
And we could still say from R1's perspective, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we could still say from R1's perspective,
the source of the tunnel is this IP address.
The destination is this.
And then vice versa.
R2 would say the source of the tunnel is this address.
The destination is here.
And then we could use an IPSec profile, which is a lot easier.
And with an IPSec profile, we just basically apply that
to the tunnel interface.
And then everything we're saying back and forth
gets encapsulated in GRE.
And then the IPSec profile on the tunnel interface
says, hey, anything in this GRE, let's encrypt it.
And that keeps us secure.
So that's easier to set up from a cryptography WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's easier to set up from a cryptography
perspective than the old way of doing
IPSec site-to-site tunnels.
But the other challenge here is that, well,
if you're going to do that, then you
have to do another tunnel here and another tunnel here.
And if you have traffic that R4 needs to send over to R2,
it's going to go up the tunnel.
And then R1 is going to route it down.
A little easier, because we're just
staying with tunnel interfaces.
Or if we have a lot of traffic that needs go from site 4
to site 2, we could build another tunnel here
between site 2 and R4 and between R3 and R4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between site 2 and R4 and between R3 and R4.
And at that point, it will be a full mesh of tunnels.
And that is a lot of overhead as well.
But it is possible.
So GRE tunnels.
And on each of the tunnels, one of the benefits
of doing the GRE method is that we have IP addressing
we can have on the tunnel.
So maybe for this tunnel on R1 end it's 10.0.0.1.
And down here on R2, it's 10.0.0.2.
So we can have these logical IP addresses
on the GRE tunnels in addition to work with.
Now, that is also a lot of work, all those GRE tunnels
manually configured.
So how about this?
I feel like a salesperson. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I feel like a salesperson.
But what if I told you--
So what if I told you we could configure this guy right here
with one tunnel interface--
let's call it tunnel 0, or tunnel 1, or tunnel 2--
and we simply configure it in such a way
that it's willing to dynamically learn
the other side of the tunnel?
And you might be thinking, well, just let anybody connect
and build the tunnel?
Well, we'd use some security.
We'll put some security on it as well.
So if R2 knows the right keys to use,
R2 can go ahead and register and build a tunnel. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R2 can go ahead and register and build a tunnel.
And maybe we'll use it as tunnel 0.
So they can build their tunnel dynamically to us.
And we would have that all set.
That saves a lot of time.
Because then we could deploy that all over the place.
We could do the same type of configuration on R3 and R4.
And they would dynamically register and build a tunnel
up to R1.
That's great.
So about 100 sites, almost the same identical
config on all those remote sites.
And when they turn on, they simply build their tunnel
and dynamically connect. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and dynamically connect.
And R2 now has all these tunnels.
And on this overlay network, these GRE tunnels,
we could have one logical IP address range, like 10.0.0.0
with a 24-bit mask.
And we could have R1 be dot 1.
We could have R2 be dot 2, and R3 be dot 3, and R4 be dot 4.
So they're on one logical network
with these dynamically generated tunnels.
And then also, we could throw in IPSec profiles on top of them.
So now we also have security and encryption on top of it.
And it gets better.
Not only could we have these devices dynamically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Not only could we have these devices dynamically
generate the tunnels so we don't have
to specify the endpoints for every single one,
but we can also, with dynamic multipoint VPNs,
which is what I'm describing here,
they could also dynamically build
tunnels between the spokes, between the remote sites.
So if R2 looks at its routing table and says,
oh, the next hop to get to the 172.16.4.0 network is 10.0.0.4,
it could use a protocol called NHRP, which is the Next Hop
Resolution Protocol.
And so we say, hey, I need to get to the 172.16.4 network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we say, hey, I need to get to the 172.16.4 network.
The next hop is 10.0.0.4.
I don't know the real address, the reachable address, of that.
This client, R2, can use NHRP, make a request saying, hey,
I need to find out what the real address is
for that next hop of 10.0.0.4.
It gets an answer.
We'll take a closer look at that detail process.
But it gets an answer, and then it
builds a tunnel dynamically between itself and R4
automatically.
It is one of the most amazing things
that we'll get to step through and actually lab up and verify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we'll get to step through and actually lab up and verify
as we proceed.
So that is the concept behind dynamic multipoint VPNs.
Here are the highlights.
The GRE tunnels don't have to all be statically configured.
They're going to be dynamically built.
We'll put IPSec profiles on top of those
for encryption protection.
And if one of the spoke sites, like the branch 2,
needs to forward packets over to R4, it can make a request,
find out what R4's publicly routable address is,
build a GRE tunnel on the fly, and forward directly
over to R4, and not have to route all the traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over to R4, and not have to route all the traffic
through the hub.
That's the beauty of DMVPN, Dynamic Multipoint VPN.
So in the next video, I'd like to just talk with you
about some of the techniques and methods that
are used to implement such a wonderful thing.
And we'll do that again in the next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.