In this video, we're going to kick it up
a notch by taking a look at the concept of VTI,
virtual tunnel interfaces, and why frankly they rock.
So, the concept of VTIs is to use a tunnel interface
and let's start there.
If we want to create a tunnel interface you go to a router
and say interface tunnel and then
you give it a number like 0 or 1 or 2 or 50 or 1,000.
And then as part of that tunnel configuration
you're going to specify the source of the tunnel.
So, in this case we could specify it's gig 0/1 or 15.
1.1.1, whatever your type address is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1.1.1, whatever your type address is
and we can specify the destination of R2,
which would be y-- and I'll put arrows there, bonk, bonk.
This is from R1's perspective and then
the default encapsulation is going to be GRE.
We don't have to specify that, the generic route
encapsulation, but here's the trick.
Instead of using generic root encapsulation what we can do
is we can say tunnel mode IPsec.
In the case of IPv4 we could say tunnel load IPsec for IPv4
and then we can specify the IPsec profile, the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then we can specify the IPsec profile, the tunnel
protection profile, that we want to use with it.
Also what we'd want to do is we want to go out and give it
an IP address.
So, let's imagine that between R1 and R2 we want to create
this logical tunnel and we'll call at 10.12.12.0/24 and maybe
we use 0.1 for R1 and 0.2 for R2.
And then once this is all up and running
we have this logical network between them.
See one of the problems with crypto maps
is that it was just R3 saying, oh traffic from 10.1.0
going to 10.2.0, go ahead and encapsulate it, ship it over, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to 10.2.0, go ahead and encapsulate it, ship it over,
and then R2 receives it and decrypts it and forwards it.
But there's-- you can't forward broadcasts or multicasts
and if there's broadcasts on this network we don't want
the router to take every single multicast and broadcast
and ship it over.
So, crypto maps don't allow that to happen.
However, if we have a tunnel interface--
because now we have a logical network here between R1
and R2--
if we have a multicast or a broadcast
and it needs to be sent out, this interface, the tunnel
interface, it can.
Now, one of the questions would be, why would
we ever want to send a broadcast or multicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we ever want to send a broadcast or multicast.
Maybe we want to use a routing protocol between those two
devices and that way if we have a logical network
with a Virtual Tunnel Interface we can actually have those guys
be [INAUDIBLE] or OSPF neighbors and they
can exchange routing information over the tunnel.
It's awesome.
So, that's the concept of a virtual tunnel interface
and this is an example of a static virtual tunnel interface
because we're specifying the source, the destination
of the tunnel, we're applying the IPsec profile,
and we're good to go.
Now, another option is this.
What if we have a Windows user that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What if we have a Windows user that
is a remote user that wants to build a remote access
VPN coming in using IPsec.
Well, to do that R1's not going to know where this guy is
coming from, I mean it could be anywhere
on the internet, any publicly routable address.
So, another option with VTIs is referred
to as a dynamic virtual tunnel interface
and to do that, we create a template.
And this template has information
such as the IPsec profile we want to use
and the fact that we're going to use IPsec.
And this tunnel template, called a virtual template
that we can set up, has the details for what profiles WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we can set up, has the details for what profiles
we want to use and for the IP address.
Because we might have dozens or hundreds
of actual virtual interfaces created
as a result of this template, we could use IPN numbers.
So, R1 could say, oh I've got loopback zero, go ahead and use
IP address unnumbered loopback 0.
And then all of the new virtual access interfaces
that are dynamically created on demand
would simply use that IP address associated with that loopback
that we specified in the template.
Now, the cool thing about creating a dynamic virtual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, the cool thing about creating a dynamic virtual
tunnel interface-- let me change that to an I there--
a dynamic virtual tunnel interface
is that we can create the template
and then we can have remote access users connect
and dynamically, based on that template,
create a new virtual access interface
for that VPN connection.
Or we could have other remote sites
like R6 and R6 could be configured in such a way
that it's coming in dynamically and when
it connects R1 can yet again--
based on who's connecting in and how they authenticate--
R1 could yet again use a virtual template WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R1 could yet again use a virtual template
to create a logical interface for that VPN coming in from R6.
So, now we've taken a look at how
we can use VTIs, virtual tunnel interfaces,
as part of our implementation of IPsec VPNs
and in the next video I'd like to share with you one
of the most creative methods of implementing VPNs
in a dynamic fashion and that is the idea of DMVPN
in the very next video.
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.