|
0:00:14
|
In our next section we are going to talk about the Dynamic Multipoint VPN feature or DMVPN
|
|
0:00:21
|
that is a variation of running ipsec over GRE tunnels
|
|
0:00:25
|
this is going to result in us having a
|
|
0:00:26
|
full mesh of LAN-to-LAN IPSec over GRE
|
|
0:00:32
|
Now the overall idea of DMVPN or Dynamic Multipoint VPN
|
|
0:00:37
|
is that we want to establish a on demand full mesh of IPSec tunnels
|
|
0:00:42
|
without having to manually define through crypto maps or through crypto vti interface
|
|
0:00:47
|
who are all the crypto peers
|
|
0:00:49
|
and what are the access list or proxy acls
|
|
0:00:52
|
that define what traffic is going to go over the tunnel
|
|
0:00:55
|
versus our normal clear text traffic that is not inside the tunnel
|
|
0:01:00
|
in order to do this, there is going to be three portions of configuration logic that are tied together
|
|
0:01:05
|
the first of which is a Multipoint GRE tunnel or a MGRE tunnel
|
|
0:01:10
|
where we would specify, what the
|
|
0:01:12
|
tunnel source is, but now what the tunnel destination is
|
|
0:01:18
|
so essentially we are going to have one single tunnel interface that can have multiple destination at the same time
|
|
0:01:24
|
the second protocol is the Next Hop Resolution Protocol or NHRP
|
|
0:01:29
|
which is going to be used to determine on the spokes
|
|
0:01:33
|
where the other devices on the network are located
|
|
0:01:36
|
based on essentially a mapping table
|
|
0:01:40
|
similar to how an address resolution protocol or ARP cache would work
|
|
0:01:44
|
or a frame relay mapping table
|
|
0:01:46
|
where the hub of the network
|
|
0:01:48
|
is going to be maintaining this table
|
|
0:01:53
|
that maps the spokes
|
|
0:01:55
|
NBMA addresses to their
|
|
0:01:57
|
tunnel addresses or their VPN addresses
|
|
0:02:00
|
then the last portion we have
|
|
0:02:02
|
is the crypto ipsec profile
|
|
0:02:04
|
which we saw previously, when we were dealing with static
|
|
0:02:07
|
virtual tunnel interfaces or the VTIs
|
|
0:02:11
|
which is used to encrypt traffic that is routed out a particular interface
|
|
0:02:18
|
Now the overall design goal of this configuration
|
|
0:02:20
|
is that we are going to reduce the need for a full mesh of static tunnel configuration
|
|
0:02:25
|
which from a scalability point of view is an issue
|
|
0:02:28
|
because we have n time (n-1) over 2
|
|
0:02:31
|
where n is the number of nodes in the network
|
|
0:02:34
|
thats the amount of static tunnels that we have to configure
|
|
0:02:38
|
So for example on a network with 1000 devices that we want a full mesh of tunnels
|
|
0:02:42
|
on each of those devices we will have to configure 999 tunnel interfaces
|
|
0:02:47
|
with 999
|
|
0:02:49
|
crypto maps or crypto profiles
|
|
0:02:52
|
So its going to be very difficult to manage this type of design
|
|
0:02:56
|
Now with Dynamic Multipoint VPN
|
|
0:02:57
|
or DMVPN
|
|
0:02:59
|
we are going to have just one single Multipoint GRE Interface
|
|
0:03:03
|
that is used for all of the connections
|
|
0:03:06
|
and the key is that the tunnels are going to be
|
|
0:03:07
|
created on demand
|
|
0:03:09
|
based on traffic that is routed between the spokes
|
|
0:03:13
|
so at even given time, if we would have that network of a 1000 devices
|
|
0:03:17
|
doesn't necessarily means that we have a 1000 tunnels
|
|
0:03:20
|
or more specifically 999 tunnels on each device
|
|
0:03:24
|
in order to send the traffic to all devices at the same time
|
|
0:03:28
|
instead its going to be based on the actual destination of the traffic
|
|
0:03:32
|
that the spokes are sending
|
|
0:03:35
|
and based on
|
|
0:03:36
|
essentially dial on demand type logic
|
|
0:03:38
|
the tunnel is not going to be setup until we actually have traffic to route out the interface
|
|
0:03:45
|
Now the way that DMVPN works is based on two main components
|
|
0:03:50
|
the DMVPN hub which is also known as the Next Hop Resolution Protocol Server or the NHRP Server
|
|
0:03:57
|
and the DMVPN spokes which are the DMVPN clients
|
|
0:04:04
|
Now to start the spokes or the clients of the network
|
|
0:04:07
|
are going to register with the DMVPN hub or the NHRP server
|
|
0:04:13
|
by manually specifying what the hub's address is
|
|
0:04:17
|
So on the all the spokes configuration, everyone is going to know what the public address of the hub
|
|
0:04:22
|
and the what is the tunnel address of the hub
|
|
0:04:25
|
with the public address is going to be what the tunnel source is
|
|
0:04:28
|
and the, the VPN address is going to be whats actually assigned
|
|
0:04:33
|
on the GRE tunnel interface
|
|
0:04:36
|
Now the hub, since the spokes are registering with it
|
|
0:04:39
|
the Dynamically going to learn what is the VPN address and what is the NBMA address of the spokes
|
|
0:04:47
|
where the VPN address again, thats the one that is actually assigned on the tunnel
|
|
0:04:51
|
the NBMA address is the tunnel source
|
|
0:04:54
|
that would be the publicly routable address
|
|
0:04:58
|
once we have the mappings from the spokes to the hub
|
|
0:05:01
|
then the spokes are going to establish a GRE tunnel
|
|
0:05:04
|
and this is going to be used to exchange our IGP routing control information or control plane
|
|
0:05:10
|
which typically uses EIGRP
|
|
0:05:13
|
but could use other protocols like OSPF or RIP or BGP
|
|
0:05:18
|
by, you see in vast majority of examples
|
|
0:05:20
|
due to some limitations, we will talk about from a routing logic point of view
|
|
0:05:25
|
most of the time you see DMVPN configured with EIGRP
|
|
0:05:31
|
Now once the spokes have the tunnels set up to the hub
|
|
0:05:35
|
if the spokes want to send traffic to each other
|
|
0:05:38
|
the first thing they need to do is to learn routes about each other
|
|
0:05:42
|
and this is going to happen dynamically via an IGP
|
|
0:05:45
|
that is learned via the tunnel interface, that we have to the hub
|
|
0:05:50
|
Now the key about the routing logic here is that when the first spoke
|
|
0:05:55
|
learns routes about another one
|
|
0:05:57
|
the next hop values for those routes
|
|
0:06:00
|
needs to be the second spokes' VPN IP address
|
|
0:06:06
|
So if we were to visualize this
|
|
0:06:09
|
in a topology, we have the hub of the DMVPN network
|
|
0:06:13
|
and the goal of this is that we have spoke 1
|
|
0:06:18
|
that is trying to reach some segment that is on spoke 2, lets say we have network A
|
|
0:06:23
|
and B, we are trying to exchange packets between them
|
|
0:06:26
|
Now the transport of the network in between doesn't really matter
|
|
0:06:30
|
we can have any type of ip transport
|
|
0:06:33
|
could be over the internet, could be over private MPLS VPN
|
|
0:06:37
|
as long we have ip reachability between all the devices, really thats all that we care about
|
|
0:06:43
|
Now the first thing thats going to happen again is that the spokes are going to register with the hub
|
|
0:06:48
|
to create a GRE tunnel
|
|
0:06:52
|
over this GRE tunnel, this is where we are exchanging out routing information
|
|
0:06:57
|
So lets say that we are running EIGRP
|
|
0:07:00
|
the routes from the first spoke are going to go out up the tunnel to the hub
|
|
0:07:04
|
hub is going to then advertise them down to second spoke
|
|
0:07:08
|
and vice versa
|
|
0:07:10
|
So eventually spoke 1 knows about the route to B, and spoke 2 knows about the route to A
|
|
0:07:17
|
Now when these updates are exchanged
|
|
0:07:20
|
when spoke 1 is advertising its route A out the interface
|
|
0:07:24
|
the next hop value that the hub receives
|
|
0:07:27
|
is going to be whatever address is assigned on the tunnel interface of spoke 1
|
|
0:07:33
|
So lets say that this address is
|
|
0:07:35
|
S1 for spoke 1
|
|
0:07:38
|
when the hub continues to advertise this route down to the other spoke
|
|
0:07:43
|
if the next hop value is maintained
|
|
0:07:47
|
and spoke 2 says that A is reachable via
|
|
0:07:51
|
spoke 1's address
|
|
0:07:54
|
it now knows that it needs to create an on demand tunnel between the two of them
|
|
0:08:01
|
and the way that this is going to occur
|
|
0:08:03
|
is by the spokes asking
|
|
0:08:05
|
the DMVPN hub or the Next Hop Resolution Server
|
|
0:08:10
|
what is the real address or what is the NBMA address
|
|
0:08:14
|
that actually corresponds to that next hop value
|
|
0:08:18
|
that it learned via the routing protocol
|
|
0:08:21
|
and this is what our NHRP is designed to do
|
|
0:08:24
|
where essentially creating a mapping between the VPN addresses
|
|
0:08:28
|
and the tunnel source addresses, which are the NBMA addresses
|
|
0:08:33
|
So the spokes are going to send the NHRP request to the Hub
|
|
0:08:38
|
the Hub is then going to tell them
|
|
0:08:40
|
that this address on the tunnel, this spoke1 address
|
|
0:08:43
|
is actually related to this public address, we will say that this is the P1
|
|
0:08:49
|
and over here we have P2 and then S2
|
|
0:08:53
|
where the hub knows that the tunnel
|
|
0:08:56
|
address
|
|
0:08:59
|
of S1 and the tunnel address of S2
|
|
0:09:04
|
actually mapped to the NBMA addresses that are the public address of 1 and public address of 2
|
|
0:09:11
|
so once the spokes realize this, they know that when traffic is routed between A and B
|
|
0:09:16
|
we can form a GRE tunnel directly between each other
|
|
0:09:20
|
and the traffic can then bypass the hub
|
|
0:09:24
|
So the final result of this which is really the key of the design
|
|
0:09:28
|
is that ones the spoke to spoke tunnel is formed
|
|
0:09:30
|
the hub is only used for the control plane information
|
|
0:09:35
|
we don't need the actual data packets to forward to the hub
|
|
0:09:38
|
which is one of the limitation of traditional hub and spoke design
|
|
0:09:42
|
whether this would be hub and spoke NBMA like
|
|
0:09:45
|
frame realy or atm
|
|
0:09:46
|
or whether we are doing just static GRE tunnels
|
|
0:09:50
|
we could have a case where I have a tunnel from spoke1 up to the hub
|
|
0:09:54
|
then a tunnel from spoke2 up to the hub
|
|
0:09:57
|
and the actual traffic routes up to the hub and back down
|
|
0:10:00
|
but then the problem is thats not necessarily the shortest path between all of the spokes
|
|
0:10:05
|
and the hub will then have to have lots of bandwidth and lots of
|
|
0:10:08
|
forwarding capabilities in order to maintain a very large network like this
|
|
0:10:14
|
So the key point of DMVPN is that the hub is mainly there just for maintaining the control plane
|
|
0:10:19
|
doesn't actually have to receive
|
|
0:10:21
|
the data packets that are going between the spokes
|
|
0:10:27
|
Now with DMVPN
|
|
0:10:29
|
were typically assuming that we are also going to be running ipsec at the same time
|
|
0:10:34
|
but multipoint GRE and the Next Hop Resolution Protocol
|
|
0:10:38
|
these are used just to maintain a tunnel establishment
|
|
0:10:42
|
they are technically unrelated to any of the encryption
|
|
0:10:46
|
So you could design without having to run ipsec on top of it
|
|
0:10:50
|
which is going to obviously save you some additional encapsulation overhead
|
|
0:10:54
|
but most of the time DMVPN does
|
|
0:10:56
|
imply they are also going to be running ipsec
|
|
0:11:00
|
Now when we are trying to do ipsec lan to lan between a multiple site at the same time
|
|
0:11:06
|
the previous cases that we looked at
|
|
0:11:08
|
were using either crypto maps or static
|
|
0:11:11
|
VTI or the Virtual Tunnel Interfaces
|
|
0:11:15
|
where the issues with these configurations
|
|
0:11:17
|
are that we still have to manually define the peer addresses
|
|
0:11:21
|
and the proxy identities or the proxy acls
|
|
0:11:25
|
where for a crypto map based lan to lan tunnel
|
|
0:11:29
|
we need to know the who what and the how
|
|
0:11:33
|
the who again is going to define
|
|
0:11:34
|
where is the tunnel going to, so who is the end point of the tunnel
|
|
0:11:38
|
the what controls
|
|
0:11:40
|
what traffic actually goes in the tunnel which is the
|
|
0:11:42
|
proxy acl or the proxy identity
|
|
0:11:45
|
and then the how is going to be
|
|
0:11:46
|
to find by the transform set
|
|
0:11:50
|
So again we would have a network of a 1000 nodes in DMVPN
|
|
0:11:55
|
the problem with using cyrpto maps
|
|
0:11:57
|
is that we would have to have
|
|
0:11:59
|
essentially 999 entries in the map
|
|
0:12:04
|
that is saying set this peer and then call this particular proxy access list
|
|
0:12:08
|
So its going to really defeat the purpose of scale ability of DMVPN, to begin with
|
|
0:12:14
|
So the solution of this, similar to what we saw in the VTIs before the virtual tunnel interfaces
|
|
0:12:19
|
is that we are going to be using ipsec crypto profiles
|
|
0:12:24
|
where the crypto profile is essentially a stripped down version of a crypto map
|
|
0:12:29
|
and the profile says that for the interface that the profile is assigned to
|
|
0:12:34
|
which in the case of DMVPN is our tunnel interface
|
|
0:12:38
|
for whatever traffic is routed out that link
|
|
0:12:41
|
its going to inherit, what are the phase II
|
|
0:12:44
|
parameters are inside the profile
|
|
0:12:46
|
which essentially is going to be the ipsec transform set
|
|
0:12:50
|
which would define are we doing ESP with
|
|
0:12:53
|
single DES, 3DES, AES
|
|
0:12:55
|
Are we doing SHA or MD5
|
|
0:12:58
|
because the
|
|
0:12:59
|
the peer address and the proxy acl
|
|
0:13:02
|
were assuming that these are inherited
|
|
0:13:05
|
from the NHRP resolution
|
|
0:13:08
|
and from the IGP routing control plane, thats already running on the tunnel
|
|
0:13:14
|
So the configurations of the profile is very straight forward
|
|
0:13:16
|
we essentially need to define just what is the transform set that is going to be used by the profile
|
|
0:13:21
|
and then profiles apply to the tunnel interface
|
|
0:13:27
|
Now this still means though, we have to have our normal
|
|
0:13:29
|
phase I negotiation
|
|
0:13:31
|
so typically in a DMVPN design in order to maintain the scalability
|
|
0:13:36
|
we would be using pre shared keys with a wild card key
|
|
0:13:41
|
or ideally using certificates
|
|
0:13:44
|
which is going to give us a dynamic and scalable way
|
|
0:13:48
|
for the end points in order to authenticate each other
|
|
0:13:52
|
Now in my particular example here we are going to look at
|
|
0:13:55
|
we are going to be using wild card pre shared keys
|
|
0:13:58
|
but the problem is from a large scale deployment point of view, this is not very secure
|
|
0:14:02
|
because if one device is compromised and the key is learned
|
|
0:14:06
|
then it means that the entire
|
|
0:14:08
|
DMVPN network is compromised
|
|
0:14:11
|
Now for the DMVPN configuration we are going to start with some of our common
|
|
0:14:15
|
parameters that we saw in other ipsec configurations
|
|
0:14:18
|
where first and foremost we are obviously going to start with the
|
|
0:14:21
|
phase I ISAKMP parameters
|
|
0:14:24
|
So we will define our policy that says whats the authentication
|
|
0:14:27
|
whats the hashing algorithm, what is the encryption
|
|
0:14:30
|
what is the Diffy Halman group
|
|
0:14:32
|
possibly what is the isakmp security association life time
|
|
0:14:36
|
and then if we are doing pre shared keys
|
|
0:14:40
|
as I mentioned we would typically use a wild card for this
|
|
0:14:43
|
or if we are using certificate authority
|
|
0:14:45
|
we need to make sure that all of the end points are trusting the same
|
|
0:14:48
|
CA server
|
|
0:14:51
|
then we would define what are our
|
|
0:14:53
|
phase II parameters, this is what the ipsec
|
|
0:14:56
|
transform set defines
|
|
0:14:57
|
along with the ipsec profile
|
|
0:15:00
|
where inside of the ipsec profile, this is where we are
|
|
0:15:03
|
calling the transform set
|
|
0:15:05
|
then the profile is going to be bound to the interface
|
|
0:15:11
|
from the actual tunnel interface configuration
|
|
0:15:15
|
we will see that there is essentially three sets of configuration that we need to maintain
|
|
0:15:20
|
the configuration that is shared between the hub and the spokes
|
|
0:15:25
|
the configuration that specific just to the spokes
|
|
0:15:28
|
then the configuration that is specific just to the hub
|
|
0:15:32
|
Now the tunnel itself
|
|
0:15:34
|
is going to have a fairly
|
|
0:15:36
|
similar configuration between all of the devices
|
|
0:15:39
|
where first and fore most, this is going to be running as a multipoint GRE tunnel
|
|
0:15:45
|
now the difference between a multipoint GRE tunnel and a normal point to point tunnel
|
|
0:15:49
|
which is the default tunnel mode
|
|
0:15:51
|
is that we will specify what is the tunnel source
|
|
0:15:55
|
but we will not specify the tunnel destination
|
|
0:15:59
|
the tunnel destination is going be implied based on the next hop resolution protocol
|
|
0:16:04
|
and based on the next hop values that we are learning based on our IGP
|
|
0:16:11
|
then just like any other tunnel configuration we would also need an ip address
|
|
0:16:16
|
and we will specify the tunnel key
|
|
0:16:19
|
which is essentially a field inside the GRE header
|
|
0:16:23
|
that the router is going to use to associate with that particular tunnel interface
|
|
0:16:28
|
because since we are not specifying a destination
|
|
0:16:31
|
the router doesn't necessarily know
|
|
0:16:33
|
is the incoming GRE packets is supposed to go to that tunnel interface
|
|
0:16:37
|
or is it supposed to go to a different interface
|
|
0:16:41
|
So by specifying the tunnel key, we are still able to associate, which particular packets actually go to that
|
|
0:16:45
|
interface versus another one
|
|
0:16:51
|
then likewise for the shared next hop resolution protocol parameters
|
|
0:16:56
|
we have the nhrp network id and the nhrp network authentication
|
|
0:17:00
|
these are essentially just needed in case is where we would
|
|
0:17:02
|
have potentially multiple tunnel interfaces
|
|
0:17:06
|
and as packets are received in
|
|
0:17:08
|
we need to make sure that the NHRP request
|
|
0:17:11
|
is associated with the correct tunnel interface
|
|
0:17:15
|
so essentially everyone in the same DMVPN network
|
|
0:17:19
|
is going to agree on the tunnel key
|
|
0:17:22
|
the nhrp network ip
|
|
0:17:24
|
and then typically the nhrp authentication
|
|
0:17:27
|
you could leave the third step out but
|
|
0:17:29
|
really there is no reason to run this without
|
|
0:17:32
|
the authentication as an extra
|
|
0:17:34
|
protection against a misconfiguration
|
|
0:17:36
|
or an extra protection against some sort of
|
|
0:17:39
|
malicious attack on the network
|
|
0:17:41
|
next we have a configuration that is specific to the spokes
|
|
0:17:45
|
where the spoke is going to be specifying
|
|
0:17:47
|
what is the hubs
|
|
0:17:49
|
source address
|
|
0:17:51
|
which is the public address
|
|
0:17:52
|
that we are going to be routing over the transit network
|
|
0:17:55
|
and then what is the tunnel ip address of the hub
|
|
0:17:59
|
so this is similar in logic to a static frame relay mapping
|
|
0:18:03
|
or a static arp entry for ethernet
|
|
0:18:06
|
where we are saying the inside address
|
|
0:18:09
|
or the VPN address, thats the tunnel ip
|
|
0:18:12
|
then the public address or the nbma that is the tunnel source
|
|
0:18:17
|
will specify the next hop server
|
|
0:18:22
|
which is going to be again the tunnels address
|
|
0:18:25
|
not the public address
|
|
0:18:27
|
then if we were to run any type of multicast over the tunnel
|
|
0:18:31
|
like multicast ospf or multicast eigrp
|
|
0:18:35
|
the ip nhrp map multicast command
|
|
0:18:38
|
says that when a multicast packet goes out that interface
|
|
0:18:41
|
we are going to encapsulate it inside of GRE
|
|
0:18:44
|
and the destination of the packets is going to change
|
|
0:18:47
|
to the public address of the hub
|
|
0:18:51
|
so on DMVPN the spokes cannot directly exchange multicast routing between each other
|
|
0:18:56
|
we will look at a different solution later
|
|
0:18:59
|
which is know as the GETVPN the Grouping Encrypted Transport
|
|
0:19:03
|
which is designed to
|
|
0:19:04
|
basically provide secure multicast
|
|
0:19:07
|
transit over the net
|
|
0:19:11
|
Now the for the additional hub parameters
|
|
0:19:14
|
the only other thing that we need to add here as well
|
|
0:19:16
|
is the ip nhrp map
|
|
0:19:18
|
multicast dynamic
|
|
0:19:20
|
which is saying that
|
|
0:19:21
|
when someone registers to me with NHRP
|
|
0:19:24
|
I am going to create a dynamic mapping
|
|
0:19:27
|
that if a multicast packet needs to be sent out the tunnel
|
|
0:19:31
|
I am going to do a replicated unicast
|
|
0:19:34
|
or a pseudo broadcast
|
|
0:19:36
|
similar to how we would do it on a frame relay
|
|
0:19:39
|
hub and spoke network or an atm hub and spoke network
|
|
0:19:42
|
where we are making multiple copies
|
|
0:19:44
|
of the single multicast
|
|
0:19:46
|
we are making multiple copies based on who are the devices that register to me through NHRP
|
|
0:19:53
|
So in our previous case, where we had
|
|
0:19:55
|
the hub talking to two different spokes
|
|
0:19:58
|
if the hub is trying to send the
|
|
0:20:00
|
EIGRP hello
|
|
0:20:02
|
or EIGRP update out both of these interfaces
|
|
0:20:05
|
we know that we need to send it two separate times, one to spoke1 and one to spoke2
|
|
0:20:11
|
So based on the registration
|
|
0:20:13
|
thats what this command is doing, or saying whoover dynamically registers to us
|
|
0:20:16
|
we are going to put a multicast mapping to them
|
|
0:20:19
|
and again thats needed for our multicast IGP
|
|
0:20:24
|
then lastly we are going apply the crypto profile to the interface which is the tunnel protection command
|
|
0:20:29
|
and the configure whatever other IGP options that we need
|
|
0:20:36
|
Now as you could see there is a lot of overall configurations to get this
|
|
0:20:41
|
basic functionality to work for DMVPN
|
|
0:20:43
|
so this most likely would be one of those configs where you would want to reference the documentation for
|
|
0:20:48
|
just to make sure that you are not leaving an individual step out
|
|
0:20:52
|
Now documentation wise
|
|
0:20:54
|
if we were to go to our IOS documentation
|
|
0:20:57
|
which is we know is under products
|
|
0:21:00
|
then IOS
|
|
0:21:02
|
regular IOS
|
|
0:21:04
|
12.4
|
|
0:21:06
|
12.4T
|
|
0:21:08
|
configuration guides
|
|
0:21:10
|
then just like our other ipsec configs, this is going to be under secure connectivity
|
|
0:21:16
|
then under here this is under dynamic multipoint VPN
|
|
0:21:21
|
so just this first documented VPN
|
|
0:21:25
|
Now just like the other documents, it would be a good idea to spend some time to read through this
|
|
0:21:29
|
specially to look at some of the caveats of what you can or cannot do with the feature
|
|
0:21:35
|
there is also different limitations based on the specific IOS version that you are running
|
|
0:21:40
|
but mainly what I want to show you here is just towards the end
|
|
0:21:43
|
they configuration examples
|
|
0:21:46
|
that show both the hubs configuration
|
|
0:21:49
|
and the spokes configuration
|
|
0:21:54
|
so I am going to take the hubs configuration
|
|
0:21:58
|
and we will put this into notepad
|
|
0:22:00
|
we will say that this is the hub
|
|
0:22:04
|
then side by side we are going to look at the spokes configuration
|
|
0:22:09
|
to see mainly the difference between the two of them
|
|
0:22:13
|
so just like lot of these other complex ipsec configurations
|
|
0:22:16
|
you can essentially just take there example
|
|
0:22:19
|
and then change it around to meet your specfic needs
|
|
0:22:24
|
So the hub is on the left there and the spokes are on the right
|
|
0:22:29
|
now in our particular topology
|
|
0:22:32
|
the way that we are going to set this up
|
|
0:22:34
|
is that router5 is going to be configured as the hub
|
|
0:22:38
|
of DMVPN, which also means that it is the NHRP
|
|
0:22:42
|
server
|
|
0:22:45
|
and the spokes or the NHRP clients are going to be router3
|
|
0:22:51
|
and router1
|
|
0:22:55
|
Now once the network is completely setup
|
|
0:22:57
|
ideally what we should be able to do is on router1
|
|
0:23:00
|
1 is to send traffic to the 10 network
|
|
0:23:04
|
this is going to go over the GRE tunnel that we have to the hub
|
|
0:23:08
|
but when router1 sourced from this 192 network
|
|
0:23:12
|
but when router1 wants to send traffic to the 172 network behind router3
|
|
0:23:16
|
this is going to go to directly to router3 over a new tunnel
|
|
0:23:21
|
as opposed to having to go up to the hub
|
|
0:23:25
|
and then turn around and then come right back
|
|
0:23:32
|
now you could also see in the topology that there are some additional devices that are doing filtering
|
|
0:23:37
|
where if router5 is going to be the hub
|
|
0:23:39
|
we need to go through the ASA
|
|
0:23:42
|
then likewise, when we are testing, if we are testing
|
|
0:23:44
|
from switch2 or we are testing from switch1
|
|
0:23:47
|
we have to go through ASA1
|
|
0:23:49
|
to simplify this design
|
|
0:23:52
|
what I am going to do is just on the outside interfaces of both of the firewalls
|
|
0:23:56
|
just simple allow all ip traffic inbound
|
|
0:24:00
|
once we actually have the basic tunnel working
|
|
0:24:03
|
then we will look at the specific protocols that we will need to permit
|
|
0:24:07
|
if we were to go through a very
|
|
0:24:09
|
straight firewall filtering policy
|
|
0:24:12
|
but for this case if we just go to
|
|
0:24:15
|
to ASA1 and ASA2
|
|
0:24:18
|
I am simply going to say access list outside in
|
|
0:24:22
|
permit ip any any
|
|
0:24:24
|
and access group
|
|
0:24:27
|
outside in
|
|
0:24:28
|
in interface outside
|
|
0:24:37
|
Now just like for any configuration that you may not be very familiar with
|
|
0:24:41
|
you want to make sure that you don't over complicate
|
|
0:24:44
|
the overall design
|
|
0:24:47
|
with additional filtering or additional protocols that are unrelated to this
|
|
0:24:51
|
so again once we get the DMVPN working then we will come back and look at
|
|
0:24:54
|
what are the potential filtering
|
|
0:24:56
|
problems we can run into with the ASA or with like
|
|
0:25:00
|
Zone Based Policy Firewall or the CBAC
|
|
0:25:05
|
So on switch1 here, this is going to be under its multiple contexts
|
|
0:25:09
|
and lets say we are going to be testing this from switch2
|
|
0:25:12
|
So we will change to context switch2
|
|
0:25:16
|
then basically at the same configs, so access list outside in permits ip any any
|
|
0:25:22
|
and access group outside in is then
|
|
0:25:24
|
applied in on the outside interface
|
|
0:25:29
|
Now the other goal of this design, for DMVPN
|
|
0:25:33
|
is not on ly to create the full mesh of the tunnels
|
|
0:25:37
|
but the routing is then going to be taking care of the dynamic
|
|
0:25:41
|
where with our previous lan to lan tunnels we may have had to do static routing
|
|
0:25:45
|
in order to accomplish this
|
|
0:25:47
|
So what we are going to be doing in this design
|
|
0:25:50
|
is on the segment between router5 and 6
|
|
0:25:53
|
we are running EIGRP
|
|
0:25:56
|
process 999
|
|
0:25:58
|
the same thing between 3 and 4
|
|
0:26:03
|
it had to be 999, and then router1
|
|
0:26:07
|
is going to be running it for these 192 networks, that is behind the ASA
|
|
0:26:12
|
So once the final configuration is complete, we should see that router1 takes its updates and sends them to the hub
|
|
0:26:20
|
the hub is then going to take these updates, send them back down to the other spokes
|
|
0:26:26
|
router3 is then going to know to get to the 192.168 network
|
|
0:26:31
|
I would need to go to router1
|
|
0:26:33
|
with the traffic actually starts to flow between them
|
|
0:26:36
|
if router4 pings switch2
|
|
0:26:38
|
we should see a new tunnel
|
|
0:26:41
|
is established, both an ipsec and a GRE tunnel
|
|
0:26:44
|
and the traffic is directly routed to, between these spokes, without having to go up to the hub first
|
|
0:26:52
|
Now when you are testing this configuration, if we were to router4, in to a traceroute
|
|
0:26:57
|
if in the traceroute from 4 to switch 2
|
|
0:27:01
|
we see one of the ip addresses of the hub
|
|
0:27:05
|
it means that there is something wrong in your routing logic
|
|
0:27:09
|
or there is something wrong in your
|
|
0:27:11
|
DMVPN phase II versus phase III configuration
|
|
0:27:17
|
and we will come back a little bit later and talk about what are the differences
|
|
0:27:20
|
in the designs of DMVPN phase I , II and III
|
|
0:27:23
|
it has to do with an optimization of the routing protocols
|
|
0:27:27
|
and then how that is going to effect, how the traffic is actually routed out the tunnel
|
|
0:27:33
|
So next lets take a look at that syntax example that we saw from the documentation
|
|
0:27:37
|
and again we are going to be looking at this side by side, where the hub in this case is going to be router5
|
|
0:27:43
|
and then spokes, these are going to be router1 and router3
|
|
0:27:49
|
Now the first thing we are starting with is the crypto isakmp policy
|
|
0:27:54
|
where just like any other ipsec tunnel, we need to make sure that everyone agrees on the phase I policy
|
|
0:28:00
|
which mean sthe authentication
|
|
0:28:03
|
the hashing, I will say md5
|
|
0:28:05
|
the encryption, I will say 3DES, and then I will say group num
|
|
0:28:11
|
Now I want to make sure, I manually defined this on all of the devices
|
|
0:28:15
|
because again different versions of IOS has different defaults
|
|
0:28:19
|
for the default crypto policy
|
|
0:28:28
|
So even if this may not show up in the configuration
|
|
0:28:31
|
I want to ensure that I am going to enter all of these option
|
|
0:28:35
|
then we have the phase I authentication
|
|
0:28:39
|
Notice that in this example
|
|
0:28:41
|
the address that they are using is all
|
|
0:28:43
|
is all zeros
|
|
0:28:46
|
and this is what the wild card pre shared key is
|
|
0:28:49
|
we are essentially saying that, for anyone
|
|
0:28:52
|
who comes in, I don't care who their, IKE identifier is
|
|
0:28:55
|
they could be matched against these key cisco 47
|
|
0:28:59
|
I must say a more specific one in the configuration
|
|
0:29:03
|
So everyone needs to agree on this, I will say for simplicity, this is going to be the password cisco
|
|
0:29:09
|
I could be more specific and match all of the
|
|
0:29:13
|
devices, so from router5 I could put keys that match router1 and 3
|
|
0:29:17
|
from 1 and 3 I could match
|
|
0:29:18
|
now put keys that match
|
|
0:29:20
|
from 1 to 3 adn 5, and from 3 to 1 and 5
|
|
0:29:24
|
but again the idea behind this is that if its going to be scalable from management point of view 2
|
|
0:29:29
|
we wouldn't have to want to maintain
|
|
0:29:31
|
manual authentication keys anywhere
|
|
0:29:34
|
really the combination of the security and the scalability
|
|
0:29:37
|
would be, if you are using Certificate Authority for your RSA signature
|
|
0:29:44
|
we then next have our transform set, this is going to be our phase II parameters
|
|
0:29:48
|
they are saying transform set 2 is using DES and MD5, which is fine
|
|
0:29:53
|
but what are the key differences here
|
|
0:29:56
|
from this configuration for DMVPN
|
|
0:29:59
|
versus our other tunnels
|
|
0:30:01
|
is that the ipsec mode
|
|
0:30:03
|
is transport
|
|
0:30:05
|
as opposed to tunnel
|
|
0:30:09
|
and the reason that this is the case is similar to the overhead
|
|
0:30:13
|
discussion that we have before when we were comparing the GRE tunnels with IPSec
|
|
0:30:17
|
versus the VTIs, the Virtual Tunnel Interfaces
|
|
0:30:21
|
and the additional overhead of having the GRE header
|
|
0:30:24
|
in addition to the ESP header
|
|
0:30:28
|
So with DMVPN since we already have GRE which is adding the IP header
|
|
0:30:33
|
of the source and the destination of the spoke and a hub or the spoke to spoke
|
|
0:30:37
|
ESP is used just to encrypt that payload
|
|
0:30:40
|
Not to add an additional header on
|
|
0:30:44
|
Now you technically could run DMVPN in tunnel mode
|
|
0:30:48
|
but its just going to add additional overhead
|
|
0:30:50
|
and its essentially going to be a waste of bandwidth and a waste of
|
|
0:30:53
|
processing to have to de encapsulate multiple levels of headers
|
|
0:31:00
|
next we have the ipsec profile
|
|
0:31:02
|
which is then calling the transform set
|
|
0:31:06
|
same on the, the hub and the spoke
|
|
0:31:08
|
So we could see, upto this point the basic ipsec configuration is essentially going to be the same one
|
|
0:31:14
|
the differences really are going to come in once we get to the tunnel configuration
|
|
0:31:18
|
and look at the NHRP
|
|
0:31:20
|
configuration on the hub versus the spoke
|
|
0:31:25
|
Now in this example there is some un needed commands they have here
|
|
0:31:29
|
along with some comments
|
|
0:31:30
|
like the bank and the tunnel, technically we could leave that off it
|
|
0:31:33
|
just going to effect our routing
|
|
0:31:36
|
our routing protocol, cost calculation
|
|
0:31:39
|
we also have the ip mtu
|
|
0:31:42
|
and the
|
|
0:31:44
|
ip tcp adjust mss command
|
|
0:31:47
|
these are related to actual payload size
|
|
0:31:50
|
that we can put inside of tunnel
|
|
0:31:52
|
because we are adding multiple levels of encapsulation
|
|
0:31:55
|
typically you would want this on
|
|
0:31:57
|
because its going cost the router to do the fragmentation
|
|
0:32:01
|
versus to have
|
|
0:32:02
|
multiple
|
|
0:32:04
|
inefficient packets that are
|
|
0:32:06
|
fragmented by ESP
|
|
0:32:08
|
and then reassembled on the other side
|
|
0:32:10
|
but we technically could remove this
|
|
0:32:13
|
so I am going to remove the
|
|
0:32:15
|
the mtu on both sides
|
|
0:32:18
|
then we have the authentication
|
|
0:32:20
|
this basically is just going to prevent a misconfiguration of one side versus the other
|
|
0:32:26
|
So this , the password is donttel
|
|
0:32:29
|
we then have the mapping for multicast
|
|
0:32:32
|
where notice here the mapping on the spoke side, on the right
|
|
0:32:37
|
is using two different addresses,
|
|
0:32:39
|
it says 10.0.0.1
|
|
0:32:43
|
and 172.17.0.1
|
|
0:32:48
|
where this second address, this is the public address
|
|
0:32:52
|
the 10.0.0.1, this is the tunnel address
|
|
0:32:56
|
Now in our particular design
|
|
0:32:58
|
the tunnel is being sourced from router
|
|
0:33:05
|
the tunnel is being sourced from router5, who is the hub
|
|
0:33:08
|
and we are going to be using its outside interface fastethernet0/1
|
|
0:33:12
|
So the source of the tunnel
|
|
0:33:14
|
on router5 is going to be
|
|
0:33:16
|
this network, it is 10.0.125.5
|
|
0:33:21
|
this is what the other device is then
|
|
0:33:23
|
are going to point at
|
|
0:33:25
|
as the mapping
|
|
0:33:28
|
and as the next hop server
|
|
0:33:31
|
So this address here 172.17.0.1
|
|
0:33:36
|
this is what I am going to replace with
|
|
0:33:39
|
So 172.
|
|
0:33:41
|
172.17.0.1
|
|
0:33:46
|
This is replaced with 10.0.125.5
|
|
0:33:51
|
So this is the essentially the public address of router5
|
|
0:33:57
|
then we have the tunnel address
|
|
0:34:01
|
we will say the tunnel address of router5
|
|
0:34:04
|
is going to be
|
|
0:34:07
|
we will replace 10.0.0.1
|
|
0:34:09
|
we will see the tunnel is going to be 10.255.255.5
|
|
0:34:15
|
.5 for router
|
|
0:34:19
|
so on this side on the hub
|
|
0:34:22
|
10.255.255.5
|
|
0:34:25
|
on the spokes, we will the first ones is going to be the router1, this will be 10.255.255.1
|
|
0:34:32
|
on router3 essentially the only thing thats going to change in the configuration
|
|
0:34:36
|
is just we are using a .3 there instead of .1
|
|
0:34:40
|
So we have the mapping from the
|
|
0:34:43
|
the next hop servers' address
|
|
0:34:45
|
we are doing the multicast mapping
|
|
0:34:48
|
we then have the NHRP network ip
|
|
0:34:52
|
which is used again in the
|
|
0:34:54
|
basically the payload of the NHRP packet
|
|
0:34:56
|
to make sure we talking about the same tunnel interface
|
|
0:35:01
|
the spokes are then saying that router5 is the next hop server
|
|
0:35:06
|
and the vast mojority of the rest of the config, we can
|
|
0:35:11
|
we can remove here
|
|
0:35:13
|
here we have the tunnel source
|
|
0:35:16
|
the tunnel mode and the tunnel key
|
|
0:35:19
|
and then the ipsec config
|
|
0:35:23
|
so you could see, a lot of this is, is kind of redundant, or just extra commentary that they have on the configuration
|
|
0:35:32
|
but when we compare the full thing of the hub on the left
|
|
0:35:35
|
to the spokes on the right
|
|
0:35:37
|
really the only thing the way I think on the spokes is the NHRP mapping
|
|
0:35:42
|
and then the next hop server
|
|
0:35:45
|
we could technically remove the whole time, this is just an optimization of the timers
|
|
0:35:50
|
then we have the tunnel source
|
|
0:35:53
|
on the spokes, router3 and router1, I will say that this their loopback zero interface
|
|
0:35:58
|
on router5
|
|
0:36:00
|
this is going to be fastethernet0/1
|
|
0:36:04
|
which is that outside interface here, fastethernet0/1
|
|
0:36:10
|
So we are assuming that before we can actually establish the tunnel
|
|
0:36:14
|
that everyone has basic ip reachablity from this interface
|
|
0:36:17
|
to whatever this interface on the other side
|
|
0:36:20
|
these are the ones that would be the publicly routable ones over the network
|
|
0:36:24
|
I like if you are running DMVPN over the internet
|
|
0:36:26
|
you need to make sure that these addresses are public addresses
|
|
0:36:31
|
then pretty much the rest of the configuration, we can remove
|
|
0:36:35
|
thats just a normal interface and routing configuration
|
|
0:36:39
|
thats not directly related to the
|
|
0:36:41
|
to the DMVPN
|
|
0:36:48
|
So lets now try this on the hub, on router5
|
|
0:36:59
|
there syntax looks good
|
|
0:37:02
|
lets also look at the debug crypto
|
|
0:37:05
|
ISAKMP this is going to show us our phase I negotiation
|
|
0:37:10
|
then we have
|
|
0:37:12
|
this configuration for router1
|
|
0:37:24
|
if we look at router5, we should now see the tunnel start to negotiate
|
|
0:37:29
|
so based on the phase I parameters that we defined
|
|
0:37:31
|
that wild card key for the authentication
|
|
0:37:35
|
then the transform set for the ipsec
|
|
0:37:42
|
it says that the tunnel is running in transport mode
|
|
0:37:46
|
wher again really this is the key point
|
|
0:37:48
|
that the previous lan to lan examples we saw were in running in tunnel mode
|
|
0:37:53
|
we already have their additional layer of the GRE encapsulation
|
|
0:37:57
|
we don't need a new header that is
|
|
0:37:59
|
provided by ESP
|
|
0:38:01
|
so ESP is just encrypting the GRE payload
|
|
0:38:04
|
not adding an additional ip header
|
|
0:38:07
|
if we now look at the show crypto
|
|
0:38:11
|
show crypto isakmp sa
|
|
0:38:14
|
we should that there is a tunnel established from router1 to router5
|
|
0:38:20
|
on both side, show crypto isakmp sa
|
|
0:38:24
|
if we look at the show ip router
|
|
0:38:27
|
router1 should have the tunnel interface
|
|
0:38:32
|
10.255.255.0
|
|
0:38:35
|
if we look at the debug
|
|
0:38:37
|
ip nhrp rp or debug nhrp
|
|
0:38:45
|
on 1 and 5, lets undebug the phase I negotiation
|
|
0:38:50
|
So debug nhrp
|
|
0:38:51
|
you will also see that these debugs specific for DMVPN
|
|
0:38:56
|
where the DMVPN debugs, these are
|
|
0:38:59
|
kind of a combination of
|
|
0:39:01
|
the ipsec
|
|
0:39:03
|
and the nhrp
|
|
0:39:05
|
you could get these individually if you were to say debug
|
|
0:39:08
|
crypto ipsec or crypto isakmp
|
|
0:39:11
|
or debug nhrp
|
|
0:39:14
|
but here lets say debug dmvpn all nhrp
|
|
0:39:22
|
on 1, 3 and 5
|
|
0:39:26
|
so next lets take at same configuration we had on router1
|
|
0:39:30
|
the only thing thats changing to move this over to router3 is just to change of that single address over the tunnel
|
|
0:39:35
|
everything else is going to stay the same
|
|
0:39:45
|
We should now see that the tunnel establishes to the hub
|
|
0:39:51
|
and if we look inside payload of the nhrp request
|
|
0:39:56
|
basically what are they doing
|
|
0:39:57
|
is creating this mapping between the publicly routable address
|
|
0:40:03
|
and the tunnel address
|
|
0:40:07
|
if we look at the show ip nhrp
|
|
0:40:10
|
or show nhrp
|
|
0:40:11
|
show nhrp
|
|
0:40:13
|
say show ip show nhrp
|
|
0:40:16
|
so the debugs are debug nhrp but the show commands are show ip
|
|
0:40:19
|
nhrp, show I want to show the ip nhrp
|
|
0:40:27
|
dynamic
|
|
0:40:32
|
or lets just say show ip nhrp
|
|
0:40:34
|
okay, this one
|
|
0:40:36
|
we can see is a static mapping
|
|
0:40:39
|
and again you can think it is kind of a like to show frame relay map output
|
|
0:40:42
|
where it saying tha this
|
|
0:40:45
|
nbma address
|
|
0:40:47
|
which is the public address is mapping to this
|
|
0:40:50
|
tunnel address
|
|
0:40:52
|
and we knew about this from the next hop server which is server5
|
|
0:40:57
|
this is now a static mapping because all of the spokes have to manually specify this
|
|
0:41:01
|
so they know who is the hub to begin with
|
|
0:41:05
|
Now when we do the spoke to spoke communication and look at the show ip nhrp
|
|
0:41:09
|
we should see that there is a dynamic mapping
|
|
0:41:12
|
that router3
|
|
0:41:14
|
knows that the address of 1
|
|
0:41:17
|
which on router1, this address is
|
|
0:41:19
|
200.0.0.1
|
|
0:41:22
|
/32 thats its loopback
|
|
0:41:25
|
its going to say this address here
|
|
0:41:27
|
maps to the nbma address which is 10.255.255.1
|
|
0:41:36
|
then likewise router1 is going to say
|
|
0:41:38
|
that router3's address, which is 200.0.0.3
|
|
0:41:43
|
is going to map to the tunnel address that is
|
|
0:41:45
|
10.255.255.3
|
|
0:41:52
|
so next lets look at whats going on in the routing
|
|
0:41:56
|
we have EIGRP 999 enabled on their inside interfaces
|
|
0:42:01
|
if we show ip EIGRP neighbours
|
|
0:42:04
|
because your router3 has an adjacency with router4
|
|
0:42:08
|
if we look at the show ip route EIGRP
|
|
0:42:11
|
we see that router3 is learning one of the LAN segments on router4
|
|
0:42:16
|
if we look at show ip eigrp interfaces
|
|
0:42:19
|
we have eigrp enabled on the lan but not on the tunnel
|
|
0:42:23
|
so the next thing I need to do, if we show run section router eigrp
|
|
0:42:28
|
is that essentially all of these devices under the IGP
|
|
0:42:32
|
configuration
|
|
0:42:34
|
will say network 10.255.255.0
|
|
0:42:38
|
0.0.0.255
|
|
0:42:49
|
So these two commands I need to add on the hub and on the spoke
|
|
0:42:54
|
Now ideally what we should see
|
|
0:42:57
|
is that the spokes are going to form an adjacency with the hub
|
|
0:43:02
|
but the spokes are not going to form an adjacency directly with each other
|
|
0:43:10
|
if we look at the results of debug outputs
|
|
0:43:13
|
we see the nhrp request they are saying that this is the tunnel address
|
|
0:43:18
|
we are trying to resolve that to the public address, or the nbma address
|
|
0:43:23
|
if we look at the
|
|
0:43:25
|
show ip route eigrp
|
|
0:43:28
|
we could see now that we are learning routes in the tunnel
|
|
0:43:32
|
where mainly I am concerned about this
|
|
0:43:37
|
10.0.6 or 10.0.56
|
|
0:43:40
|
these are the networks that router5
|
|
0:43:43
|
is learning from router6
|
|
0:43:47
|
so ideally what we want to see
|
|
0:43:49
|
is that once the traffic actually starts to transit
|
|
0:43:52
|
if switch2 is trying to get to router6
|
|
0:43:56
|
its going to go to the ASA, its going to go to 1
|
|
0:43:59
|
then one is going to send to send it over the tunnel to 5
|
|
0:44:04
|
but if switch2 is trying to get to router4
|
|
0:44:07
|
when the traffic gets to 1, a new tunnel should be formed
|
|
0:44:11
|
and then this should route this direction
|
|
0:44:16
|
so lets now look at the routing table of all of these device
|
|
0:44:22
|
I want to see the show ip route eigrp
|
|
0:44:26
|
router1 is learning routes from 5
|
|
0:44:31
|
3 is learning routes from 5
|
|
0:44:36
|
on 5
|
|
0:44:38
|
we are learning routes from both
|
|
0:44:40
|
3 and from 1
|
|
0:44:44
|
but the spokes are not exchanging their updates yet
|
|
0:44:49
|
Now since we are running eigrp, this is just like any other type of hub and spoke topology
|
|
0:44:54
|
when the hub was router5
|
|
0:44:56
|
receives the update in on the tunnel interface
|
|
0:45:00
|
it normally is not going to send it back out that same interface due to split horizon
|
|
0:45:05
|
so if eigrp is used for the DMVPN configuration on the hub
|
|
0:45:10
|
we need to make sure that
|
|
0:45:12
|
split horizon is disabled for eigrp
|
|
0:45:16
|
we will say on tunnel 0
|
|
0:45:18
|
no ip split horizon eigrp 999
|
|
0:45:23
|
ip we now look back at the spokes on 1 and 3
|
|
0:45:27
|
and show ip route eigrp
|
|
0:45:30
|
we should now see that we are learning about the other spokes networks
|
|
0:45:36
|
so router1 knows how to reach router4
|
|
0:45:40
|
on router3, if we show ip route eigrp
|
|
0:45:44
|
router3 knows how to reach
|
|
0:45:45
|
switch1 and switch2 thats 192.168 networks
|
|
0:45:50
|
if we were to now do a traceroute
|
|
0:45:52
|
lets say that we go to router4
|
|
0:45:55
|
and we are going to trace how do we get to 6
|
|
0:45:58
|
and how do we get to switch2
|
|
0:46:03
|
what should ideally happened is that the traffic going to 6 should go over the tunnel to router5
|
|
0:46:09
|
but the traffic going to switch2 is going to go over the tunnel directly to 1
|
|
0:46:16
|
So on router4 lets say how to get to 10.0.6.6
|
|
0:46:24
|
which is what we want, its going over the tunnel thats
|
|
0:46:26
|
towards router5
|
|
0:46:28
|
if we trace
|
|
0:46:31
|
192.168.118.8
|
|
0:46:38
|
notice here that the traffic is going to 5
|
|
0:46:40
|
before it goes to 1
|
|
0:46:47
|
so technically the tunnel is working
|
|
0:46:51
|
and the routing is working
|
|
0:46:52
|
but now the hub of the DMVPN
|
|
0:46:54
|
is not only used for the control plane
|
|
0:46:57
|
but its also being used for the data plane forwarding
|
|
0:47:00
|
which is really not what we want
|
|
0:47:02
|
what we should see here instead is that
|
|
0:47:04
|
router5 is not listed as a next hop here
|
|
0:47:08
|
because we want 3 to establish the tunnel directly to 1
|
|
0:47:13
|
and the design issue that is related to this
|
|
0:47:15
|
is the particular routing protocol that we are using
|
|
0:47:18
|
and what is the next hop value
|
|
0:47:21
|
for the spoke to spoke routes
|
|
0:47:26
|
in a correct design we should see that router3
|
|
0:47:29
|
sees the next hop of router1
|
|
0:47:32
|
for these routes, not from the hub itself
|
|
0:47:37
|
and the reason that this is not happening right now
|
|
0:47:40
|
is that with eigrp
|
|
0:47:43
|
when the spokes receives a route in from
|
|
0:47:46
|
or excuse me, the hub, when the hub receives a routing for the spoke
|
|
0:47:48
|
which in this case is router5
|
|
0:47:51
|
so the update goes from
|
|
0:47:53
|
1 to 5
|
|
0:47:55
|
5 sends it to 3
|
|
0:47:58
|
when this happens 5 is going to set the next hop to its
|
|
0:48:01
|
own tunnel interface to .5 address
|
|
0:48:06
|
what we want what we want to occur instead is that this update is passed through
|
|
0:48:10
|
without the next hop being modified
|
|
0:48:14
|
which is one of the commands they have in the example here
|
|
0:48:17
|
on the tunnel interface of 5
|
|
0:48:20
|
we would just need to say no ip next hop self
|
|
0:48:23
|
for eigrp as 999
|
|
0:48:30
|
if we now look at router3 and check back routing table
|
|
0:48:34
|
we will see now the next hop is changed to be router1's next hop
|
|
0:48:38
|
not to be 5
|
|
0:48:44
|
in the case that we would use ospf
|
|
0:48:46
|
as the igps opposed to eigrp
|
|
0:48:49
|
the next hop values are going to be related to what is the
|
|
0:48:51
|
ospf network type
|
|
0:48:54
|
so this means that with ospf over
|
|
0:48:57
|
DMVPN
|
|
0:48:58
|
we would need to be running network type broadcast
|
|
0:49:01
|
or non broadcast
|
|
0:49:03
|
and also specify that the hub with the DMVPN
|
|
0:49:06
|
is also the designated router for OSPF
|
|
0:49:11
|
now this could be considered to design limitation
|
|
0:49:14
|
for OSPF over DMVPN
|
|
0:49:16
|
because we have to maintain the
|
|
0:49:18
|
the designated router election or if were to run
|
|
0:49:21
|
not broadcast, we would have to maintain the neighbour statements
|
|
0:49:25
|
if we were to use network type point to multipoint or point to point
|
|
0:49:30
|
the next hop values, not going to be the value that we need
|
|
0:49:34
|
Now if we look at the change of this, if we go to router4 and do the trace
|
|
0:49:43
|
we see for the first couple of packets, these are going to router5
|
|
0:49:48
|
but then we should see a new tunnel is formed
|
|
0:49:51
|
directly from 1 to 3
|
|
0:49:55
|
if we look at the show ip nhrp
|
|
0:49:59
|
I know see a dynamic mapping
|
|
0:50:02
|
for router1's address, it says, it corresponds to this public address
|
|
0:50:08
|
and if we look at the
|
|
0:50:10
|
the show crypto isakmp sa
|
|
0:50:13
|
notice that now we have a tunnel directly between 1 and 3
|
|
0:50:19
|
so from here on now, when we go to send traffic
|
|
0:50:23
|
we see that it does not use router5
|
|
0:50:28
|
its going to skip the hub and go directly between
|
|
0:50:31
|
the spokes, so directly between router1 and 3
|
|
0:50:35
|
so reviewing our verification again here for the DMVPN
|
|
0:50:38
|
one of the first things that we will want to look at is
|
|
0:50:41
|
is the nhrp resolution or the next hop resolution protocol properly working
|
|
0:50:46
|
and we could see that this by looking at the show ip nhrp
|
|
0:50:50
|
ideally on the hub
|
|
0:50:52
|
we should see all of the spokes have dynamically registered
|
|
0:50:55
|
on the spokes we see that we have the static mapping for the hub
|
|
0:50:59
|
and they wants the tunnels are actually up spoke to spoke
|
|
0:51:01
|
we are going to dynamic resolution between them
|
|
0:51:05
|
if we have any problems with the ipsec configuration, this is going to be our normal phase I and phase II verification
|
|
0:51:11
|
by looking at the show crypto isakmp sa or the show crypto ipsec sa
|
|
0:51:16
|
or the debug crypto isakmp or the debug crypto ipsec
|
|
0:51:19
|
thats going to show us any issues on our phase I or phase II negotiation
|
|
0:51:24
|
Now additionally they are DMVPN specific commands
|
|
0:51:28
|
that we saw which are basically an immigration
|
|
0:51:31
|
of the ipsec and isakmp
|
|
0:51:32
|
plus the nhrp together
|
|
0:51:35
|
which would be under either show DMVPN
|
|
0:51:37
|
or debug DMVPN
|
|
0:51:42
|
Now the other design issue that goes along
|
|
0:51:45
|
with this configuration for DMVPN
|
|
0:51:47
|
is what I mentioned briefly before
|
|
0:51:49
|
the difference between phase I
|
|
0:51:51
|
phase II and phase III
|
|
0:51:53
|
DMVPN or NHRP designs
|
|
0:51:57
|
Now with the phase I configuration
|
|
0:52:00
|
this is where when we have
|
|
0:52:02
|
the hub of the network
|
|
0:52:05
|
that is establishing the
|
|
0:52:07
|
on demand tunnels to the spokes
|
|
0:52:10
|
so we have spoke1 and we have spoke2
|
|
0:52:14
|
then for any traffic between them, if we have traffic
|
|
0:52:16
|
its going from segment A to segment B
|
|
0:52:19
|
spoke1 is simply going to route the packet
|
|
0:52:21
|
up the tunnel to the hub
|
|
0:52:23
|
then hub is going to route it back down
|
|
0:52:26
|
So its just like doing normal static
|
|
0:52:28
|
hub and spoke
|
|
0:52:29
|
ipsec vpns
|
|
0:52:31
|
but the difference is that the configuration
|
|
0:52:33
|
of the spokes, we don't necessarily need to
|
|
0:52:35
|
specify all of the
|
|
0:52:37
|
the
|
|
0:52:38
|
the proxy acls
|
|
0:52:40
|
because we are using the crypto profiles on the interface
|
|
0:52:44
|
Now the phase II DMVPN
|
|
0:52:46
|
or NHRP phase II
|
|
0:52:49
|
is when we can allow
|
|
0:52:50
|
the spokes to dynamically discover each other
|
|
0:52:53
|
and then configure the on demand tunnel
|
|
0:52:56
|
and this is what we have configured up to this point
|
|
0:53:00
|
now phase II is considered
|
|
0:53:02
|
more of like a legacy configuration or kind of obsolete because we will see there is a new enhancement
|
|
0:53:08
|
with phase III, thats going to solve some of the design problem
|
|
0:53:11
|
but with our current operation of phase II
|
|
0:53:15
|
when the spokes send a packet
|
|
0:53:17
|
to the VPN IP address
|
|
0:53:20
|
so any thing that we are learning dynamically over the tunnel
|
|
0:53:22
|
this is what is going to trigger the nhrp request
|
|
0:53:26
|
So the spoke is sending the request to the server
|
|
0:53:28
|
this is trying to do a binding for the
|
|
0:53:31
|
nbma ip, which is public ip
|
|
0:53:34
|
to the vpn address, which is the one that is the tunnel
|
|
0:53:37
|
which is actually assigned on the tunnel
|
|
0:53:40
|
then the server is going to reply
|
|
0:53:42
|
with the nbma mapping
|
|
0:53:44
|
this is what is allowing the spoke to form
|
|
0:53:46
|
the dynamic tunnels, to dynamically discover each others addresses
|
|
0:53:51
|
Now the limitation of this is we saw
|
|
0:53:53
|
is that from a routing protocol point of view
|
|
0:53:56
|
the next hop value has to be preserved
|
|
0:53:59
|
as the updates are passed between
|
|
0:54:02
|
the spoke to the hub and then from the hub back down to the other spoke
|
|
0:54:07
|
this means with eigrp we had to use that ip next hop self
|
|
0:54:11
|
eigrp command, or excuse me, no ip next hop self
|
|
0:54:14
|
eigrp on the hub
|
|
0:54:15
|
to preserve the next hop values
|
|
0:54:17
|
and if we were to run ospf
|
|
0:54:19
|
it means that we would have to run in network
|
|
0:54:21
|
type broadcast or non broadcast
|
|
0:54:23
|
which brings along other design issues
|
|
0:54:26
|
like the unicasting of updates
|
|
0:54:28
|
and the designated router and backup designated router election
|
|
0:54:33
|
they would also be an issue with any type of summarization
|
|
0:54:36
|
or default routing
|
|
0:54:38
|
because if the next hop values
|
|
0:54:39
|
pointing at the hub
|
|
0:54:41
|
as opposed to the other spokes
|
|
0:54:43
|
then we are not going to able to establish those
|
|
0:54:44
|
on demand spoke to spoke tunnels
|
|
0:54:50
|
so the design fix for this is now what is known as the nhrp
|
|
0:54:53
|
phase III or the DMVPN phase III
|
|
0:54:56
|
where we still have the same procedure for the
|
|
0:54:58
|
spokes are registering
|
|
0:54:59
|
with the next hop resolution protocol server
|
|
0:55:01
|
which is the DMVPN hub
|
|
0:55:04
|
but the key difference now is that the
|
|
0:55:05
|
spoke is no longer going to send an nhrp query
|
|
0:55:10
|
or a nhrp request
|
|
0:55:11
|
when we are sending traffic
|
|
0:55:12
|
to the VPN ip addresses
|
|
0:55:15
|
so the hub is basically only used
|
|
0:55:17
|
for the IGP control information
|
|
0:55:20
|
we are going to learn routes from them
|
|
0:55:22
|
then based on whatever those routing destination are, we are going to send packets up to the hub
|
|
0:55:27
|
Now when the hub receives these
|
|
0:55:29
|
the hub is going to know what is the
|
|
0:55:31
|
final destination spoke
|
|
0:55:34
|
So for example in this
|
|
0:55:35
|
topology with the two spokes and hub
|
|
0:55:38
|
packets are going from A to B
|
|
0:55:41
|
spoke1 is going to send the packet up to the hub
|
|
0:55:43
|
the hub knows that the real destination is on spoke2
|
|
0:55:46
|
so the packet is going to be sent down
|
|
0:55:50
|
the change now though
|
|
0:55:51
|
is that once this packet is redirected
|
|
0:55:54
|
its coming in the tunnel and then its forwarding back up the same tunnel interface
|
|
0:55:58
|
we are going to generate an nhrp redirect message back to the source
|
|
0:56:03
|
telling them that I am not actually not the destination for this
|
|
0:56:07
|
but it will forward the packet down to the final destination
|
|
0:56:11
|
so its similar to an ICMP redirect
|
|
0:56:14
|
but this is specifically to trigger
|
|
0:56:16
|
a change
|
|
0:56:17
|
in the nbma ip address to the VPN ip
|
|
0:56:21
|
ip address mapping on the spokes
|
|
0:56:24
|
Now once the spoke receives this nhrp redirect
|
|
0:56:29
|
its going to send an nhrp query
|
|
0:56:32
|
towards the final destination
|
|
0:56:35
|
the query is going to go
|
|
0:56:36
|
up to the hub and then its going to flow down
|
|
0:56:38
|
to the other spoke
|
|
0:56:39
|
to whatever the final spoke destination is
|
|
0:56:42
|
but now the difference is that the destinations
|
|
0:56:44
|
spoke is the one who actually directly
|
|
0:56:47
|
responds to the request
|
|
0:56:50
|
so in this case where the packet is going from A to B
|
|
0:56:54
|
the packet actually gets there
|
|
0:56:56
|
but then the hub is going to reply back with the redirect
|
|
0:57:01
|
so the redirect gets to spoke1
|
|
0:57:03
|
spoke1 is then going to trigger based on this
|
|
0:57:06
|
the nhrp request
|
|
0:57:10
|
when the hub gets this it doesn't reply to it itself
|
|
0:57:13
|
it forwards it down to the final destination
|
|
0:57:17
|
then spoke2 is going to send the response
|
|
0:57:20
|
to spoke1
|
|
0:57:22
|
in order for them to establish the end to end tunnel
|
|
0:57:27
|
Now from our point of view, when we actually look at the end result
|
|
0:57:30
|
we are still going to have spoke to spoke tunnel
|
|
0:57:33
|
but the difference is that its an
|
|
0:57:35
|
optimizaton of how much control plane information
|
|
0:57:38
|
that the hub has to maintain
|
|
0:57:41
|
So essentially when the response is sent
|
|
0:57:44
|
the response from this spoke is going to contain their mapping, so the VPN address to the nbma address
|
|
0:57:50
|
and the originating
|
|
0:57:52
|
spoke of the packets, in this case which was spoke1 on the left
|
|
0:57:56
|
they are going to update their sef table
|
|
0:57:58
|
with new next hop value
|
|
0:58:00
|
that says, well thats not really reachable by the hub
|
|
0:58:03
|
its actually reachable via this other spoke
|
|
0:58:06
|
and this is what the call the sef shortcut or the nhrp shortcut
|
|
0:58:11
|
So the change in this design
|
|
0:58:13
|
is that the DMVPN hub is still used for the control plane of routing
|
|
0:58:18
|
but its not used for the nhrp
|
|
0:58:20
|
requests and responses
|
|
0:58:22
|
its used to figure out dynamically who are the spokes
|
|
0:58:25
|
and what are the IGP routes
|
|
0:58:28
|
then spokes are going to communicate
|
|
0:58:30
|
between themselves using nhrp
|
|
0:58:32
|
based on the fact that the hub is generating that redirect message back on to them
|
|
0:58:38
|
and then they are going to use those shortcut updates the
|
|
0:58:40
|
nhrp shortcut or the sef shortcut
|
|
0:58:43
|
in order to actually update whats going on
|
|
0:58:46
|
in their forwarding information base or the sef table
|
|
0:58:50
|
Now the advantage of using this DMVPN phase III
|
|
0:58:54
|
is that it allows it to do summarization
|
|
0:58:57
|
or it allows us to do next hop modification
|
|
0:59:00
|
which means that we would be able to on the hub
|
|
0:59:05
|
basically just advertise a default route
|
|
0:59:09
|
So I could send 0.0.0.0/0 down to all of the spokes
|
|
0:59:13
|
but then the spokes which still be able to establish the on demand tunnels
|
|
0:59:21
|
based on the redirect messages that the hub is generating
|
|
0:59:25
|
Now as for the next hop modification
|
|
0:59:28
|
this would mean that with OSPF we do not have the limitation
|
|
0:59:32
|
of having to run network type non broadcast or broadcast
|
|
0:59:37
|
So we could run as network type point to multipoint
|
|
0:59:40
|
which is designed for these type of partially meshed networks
|
|
0:59:42
|
and we are not going to have any
|
|
0:59:44
|
we are not going to have any issues with next hop values
|
|
0:59:47
|
Now from a scale ability point of view
|
|
0:59:50
|
this is really where the advantage comes in
|
|
0:59:52
|
that you can
|
|
0:59:53
|
have multiple levels of hierarchy
|
|
0:59:56
|
for the DMVPN in phase III
|
|
0:59:59
|
and if you do want more information about that
|
|
1:00:03
|
there is design document
|
|
1:00:08
|
that is migrating
|
|
1:00:09
|
from dynamic multipoint vpn phase II to phase III
|
|
1:00:12
|
on cisco's website
|
|
1:00:14
|
so it talks about the specific
|
|
1:00:17
|
variation of what happens when
|
|
1:00:19
|
you are running phase II
|
|
1:00:21
|
versus what happens when you are running phase III
|
|
1:00:24
|
and the key is that with this DMVPN a lot of the designs and that being very very large scale
|
|
1:00:29
|
where you may have
|
|
1:00:31
|
10,000, 20,000 sites
|
|
1:00:34
|
that are running inside of the same DMVPN network
|
|
1:00:40
|
Now configuration wise, there is basically only
|
|
1:00:43
|
two minute changes that we need to make
|
|
1:00:45
|
in order to implement this DMVPN
|
|
1:00:48
|
and if we take a look at the command line, I have this configured now
|
|
1:00:52
|
between the three devices that we are using for the DMVPN
|
|
1:00:56
|
which is specifically in this case is router5 as the hub
|
|
1:01:00
|
then router3 and router1 as the spokes
|
|
1:01:05
|
Now on router1 and 3 which are the spokes
|
|
1:01:09
|
if we look at the tunnel interface
|
|
1:01:12
|
there is one additional command which is the
|
|
1:01:16
|
ip nhrp shorcut
|
|
1:01:21
|
the ip nhrp, actually two commands on the
|
|
1:01:24
|
spokes, ip nhrp shortcut and ip nhrp redirect
|
|
1:01:29
|
then on the hub which is router5
|
|
1:01:32
|
it has the
|
|
1:01:34
|
ip nhrp redirect
|
|
1:01:38
|
so router5, who is the hub is
|
|
1:01:39
|
going to be in charge of sending the redirect messages
|
|
1:01:42
|
then router1 and router3 are listening for them
|
|
1:01:45
|
this shortcut command this tells them to update the sef entry
|
|
1:01:49
|
once the redirection actually occurs
|
|
1:01:51
|
you could technically put
|
|
1:01:53
|
both of these commands on
|
|
1:01:54
|
everyone and its not going to hurt
|
|
1:01:56
|
you end up in the same result
|
|
1:01:58
|
but technically the hub doesn't need the
|
|
1:02:01
|
shortcut command and only needs the redirect command
|
|
1:02:05
|
now the other change that I have made here is that I have removed the
|
|
1:02:08
|
no ip next hop sef eigrpp command on the hub
|
|
1:02:14
|
and the end result of this, if we were to go to router3
|
|
1:02:17
|
which is one of the spokes
|
|
1:02:19
|
and look at the show ip route eigrp
|
|
1:02:22
|
we see that we have the same routing information as before
|
|
1:02:26
|
where we are learning about router1's
|
|
1:02:28
|
routes to the 192 network
|
|
1:02:31
|
but notic that the next hop value is now router5, which is the hub
|
|
1:02:36
|
this is similar to our very first configuration which is essentially the
|
|
1:02:40
|
phase I DMVPN
|
|
1:02:43
|
where the traffic pattern
|
|
1:02:45
|
from 1 to 3
|
|
1:02:47
|
in phase I would be that the packets actually routed to 5 first
|
|
1:02:51
|
then 5 routes them back down
|
|
1:02:55
|
in the phase II
|
|
1:02:56
|
DMVPN, the first packets were routed up to 5
|
|
1:03:00
|
then the subsequent ones went directly between 1 and 3
|
|
1:03:04
|
based on the new on demand tunnel
|
|
1:03:07
|
where in phase III
|
|
1:03:10
|
we should see the same result that the packets are going to route directly between 1 and 3
|
|
1:03:15
|
but the next hop value is not then
|
|
1:03:19
|
maintained
|
|
1:03:21
|
so router5 is updating the next hop value to itself
|
|
1:03:24
|
but on router3, if we look at the show
|
|
1:03:26
|
crypto isakmp
|
|
1:03:29
|
show crypto isakmp sa
|
|
1:03:32
|
we see right now there is only one tunnel from 3
|
|
1:03:36
|
this is the tunnel from 3 to 5
|
|
1:03:40
|
likewise on router1, we should see the same thing, we should see a tunnel just from 1 to 5
|
|
1:03:46
|
if we show crypto
|
|
1:03:49
|
isakmp sa
|
|
1:03:52
|
we have the tunnel just up to the hub
|
|
1:03:55
|
once we actually go to send the traffic
|
|
1:03:58
|
from router4, if we were to ping
|
|
1:04:00
|
192.168.118.8
|
|
1:04:05
|
which is switch2
|
|
1:04:09
|
if we look at router3 and look at the show crypto isakmp sa
|
|
1:04:13
|
and the same thing on router1
|
|
1:04:17
|
notice that now we have the new tunnels
|
|
1:04:19
|
we have the direct tunnels between 1 and 3
|
|
1:04:23
|
and if router4 were to traceroute, if we trace to
|
|
1:04:27
|
192.168.118.8
|
|
1:04:31
|
even though that the next hop value
|
|
1:04:34
|
on router3 has not
|
|
1:04:35
|
then changed or it has been changed
|
|
1:04:38
|
has been changed to router5
|
|
1:04:40
|
but even though thats the case
|
|
1:04:42
|
the actual data plane traffic is not needed to use router5 in the transit
|
