DM-VPN stands for Dynamic Multipoint Virtual
Private Network, basically it’s describe a technology that uses
multipoint GRE tunnels (mGRE) along with IPSec in a hub and spoke topology on a
NBMA (Non-Broadcast Multiple Access) network.
The tunnels are created dynamically, between
the hub and spoke or spoke to spoke, without any specific configuration for
each node. This allows great flexibility and scalability for this kind of
solution without the complexity and overhead of full mesh GRE/IPSec tunnels.
This is the lab topology:
R1 is the hub while R2, R3 and R4 are the spokes. R5 is
acting as the public network.
Each spoke and the hub are holding 192.168.xx.0/24 segment
which represent the site local network.
So after configuring the IP addresses on the WAN (serial 1/0)
and LAN (Loopback1) interfaces and setting a default route on each router
toward R5 we can start configuring the DM-VPN.
Configuring DM-VPN network evolves in three steps:
1.
Configuring dynamic tunnels
2.
Setting up dynamic routing
protocol
3.
Configure IPSec protection
Configure
dynamic tunnels
Let’s start with the first step of configuring the tunnels
on the participating routers, I will start with R1 which in our case act as a
hub router:
|
interface Tunnel0
ip address 192.168.0.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip nhrp registration timeout 20
tunnel source 10.1.15.1
tunnel mode gre multipoint
end
|
The network segment between all DM-VPN routers will be
192.168.0.0/24 so the IP address of the tunnel on R1 is 192.168.0.1.
The NHRP (Next-Hop Resolution Protocol) is the key factor
for success which responsible for translate tunnel-to-physical interface
address between the participating routers. Whenever a spoke is looking for
route to specific network the NHRP protocol provide the answer.
NHRP multicast dynamic allow us, as the name apply, to use
multicast dynamically over this tunnel. This will be required later when we
will add the dynamic routing protocol which most of them using multicast to
establish adjacencies.
The NHRP network-id is used to distinguish between DM-VPN
networks (yes we can use more then 1 DM-VPN network on a single router for redundancy
purposes) and it must be the same on all routers to participate in the same
network.
Also note that the tunnel source is serial1/0 but there is
no tunnel destination, the tunnel mode is GRE but in multipoint way.
Now let’s look on a spoke router (R2) configuration:
|
interface Tunnel0
ip address 192.168.0.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.0.1 10.1.15.1
ip nhrp map multicast 10.1.15.1
ip nhrp network-id 1
ip nhrp nhs 192.168.0.1
ip nhrp registration timeout 20
tunnel source 10.1.25.2
tunnel mode gre multipoint
end
|
First the IP address of the tunnel is part of the DM-VPN
network segment.
Then the NHRP commands: In the spoke configuration we do
need to specific the hub location – NHRP map is correlating between the WAN IP
and the tunnel IP for the hub router, also the multicast mapping which points
toward the WAN interface and the NHS (Next-Hop Server) IP address.
In a DM-VPN network which based on NBMA, the hub doesn’t
know about the spokes but the spokes are configured to register at the hub and
after successful registration they learn about each other through the hub. That’s
the reason for the differences between the hub and the spoke configuration.
After finishing the first step we can verify the DM-VPN configuration
by issuing the following command:
|
R1#show dmvpn
Legend: Attrb --> S -
Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries
with same NBMA peer
NHS Status: E --> Expecting
Replies, R --> Responding
UpDn Time --> Up or Down Time for
a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP
Details
Type:Hub, NHRP Peers:3,
# Ent
Peer NBMA Addr Peer Tunnel Add State
UpDn Tm Attrb
----- --------------- --------------- -----
-------- -----
1
10.1.25.2 192.168.0.2 UP
2d15h D
1
10.1.35.3 192.168.0.3 UP
2d15h D
1
10.1.45.4 192.168.0.4 UP
2d14h D
|
Setting
dynamic routing protocol
The second step is to setup a dynamic routing protocol on
the network, in this case I will use EIGRP.
R1 (Hub) configuration:
|
router eigrp 1
network 192.168.0.1 0.0.0.0
network 192.168.11.1 0.0.0.0
no auto-summary
!
interface Tunnel0
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
end
|
I have configured EIGRP AS1 process and configured both LAN
and tunnel interface in the topology, also configured no next-hop-self and no
split-horizon to prevent connectivity issues because R1 is hub router which
learns and advertise network on the same interface.
R2 (Spoke) configuration:
|
router eigrp 1
network 192.168.0.1 0.0.0.0
network 192.168.21.1 0.0.0.0
no auto-summary
end
|
Pretty simple and the result:
|
R2#show ip route
Codes: C - connected, S -
static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF,
IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 -
OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF
external type 2
i - IS-IS, su - IS-IS summary, L1 -
IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate
default, U - per-user static route
o - ODR, P - periodic downloaded
static route
Gateway of last resort is
10.1.25.5 to network 0.0.0.0
D 192.168.31.0/24 [90/28288000] via
192.168.0.3, 00:02:34, Tunnel0
D 192.168.11.0/24 [90/27008000] via
192.168.0.1, 00:02:48, Tunnel0
D 192.168.41.0/24 [90/28288000] via
192.168.0.4, 00:02:25, Tunnel0
C 192.168.21.0/24 is directly connected,
Loopback1
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.25.0 is directly connected,
Serial1/0
C 192.168.0.0/24 is directly connected,
Tunnel0
S* 0.0.0.0/0 [1/0] via 10.1.25.5
|
Now before we proceed to the third step let’s look how does
traffic traverse between spoke to spoke and how does the spoke routers register
with the hub.
Let’s send ICMP from R2 LAN to R4 LAN:
|
R2#ping 192.168.41.1 source
lo1 repeat 50
|
So R2 is looking into the routing table:
|
R2#show ip route
Codes: C - connected, S -
static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O -
OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 -
OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF
external type 2
i - IS-IS, su - IS-IS summary, L1 -
IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate
default, U - per-user static route
o - ODR, P - periodic downloaded
static route
Gateway of last resort is
10.1.25.5 to network 0.0.0.0
D 192.168.31.0/24 [90/28288000] via
192.168.0.3, 02:13:54, Tunnel0
D 192.168.11.0/24 [90/27008000] via
192.168.0.1, 02:14:09, Tunnel0
D 192.168.41.0/24 [90/28288000] via
192.168.0.4, 02:13:45, Tunnel0
C 192.168.21.0/24 is directly connected,
Loopback1
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.25.0 is directly connected,
Serial1/0
C 192.168.0.0/24 is directly connected,
Tunnel0
S* 0.0.0.0/0 [1/0] via 10.1.25.5
|
In order to reach network 192.168.41.0/24 he need to go to
192.168.0.4 through tunnel 0 so now R2 is sending NHRP resolution request to the
R1, which is the NHS, for 192.168.0.4:
Note the request is for the tunnel IP address.
R1 is sending this request to R4:
R4 is sending replay to R1:
In the replay R4 includes the NBMA WAN IP address.
R1 is sending the replay to R2:
Another issue to look in is the NHRP registration message, following
our tunnel configuration I configured the spokes to send a message every 20
seconds.
Here is a registration message to the NHS:
which in turn will send registration
replay:
If the NHS doesn’t receive and NHRP registration from a
spoke router after 20 seconds he waits 3 retransmissions, which occur in 7
seconds, until he declares a down spoke which in this case will not receive NHRP
resolution requests anymore.
Some more
useful commands
Using show ip nhrp
brief we can see all dynamic and static tunnels:
|
R2#sh ip nhrp brief
Target Via NBMA Mode Intfc
Claimed
192.168.0.1/32 192.168.0.1 10.1.15.1 static Tu0
< >
192.168.0.2/32 192.168.0.2 10.1.25.2 dynamic Tu0
< >
192.168.0.3/32 192.168.0.3 10.1.35.3 dynamic Tu0
< >
192.168.0.4/32 192.168.0.4 10.1.45.4 dynamic Tu0
< >
|
And show ip nhrp details
we can see some more information:
|
R2#sh ip nhrp detail
192.168.0.1/32 via
192.168.0.1
Tunnel0 created 3d00h, never expire
Type: static, Flags: used
NBMA address: 10.1.15.1
192.168.0.2/32 via
192.168.0.2
Tunnel0 created 00:02:15, expire 01:57:50
Type: dynamic, Flags: router unique local
NBMA address: 10.1.25.2
(no-socket)
Requester: 192.168.0.3 Request ID: 6
Requester: 192.168.0.4 Request ID: 6
192.168.0.3/32 via
192.168.0.3
Tunnel0 created 00:02:16, expire 01:57:44
Type: dynamic, Flags: router
NBMA address: 10.1.35.3
192.168.0.4/32 via
192.168.0.4
Tunnel0 created 00:02:09, expire 01:57:50
Type: dynamic, Flags: router
NBMA address: 10.1.45.4
|
Show ip nhrp nhs detail
we see the configured NHS and the number of NHRP request and replay messages:
|
R2#show ip nhrp nhs detail
IPv4 Registration Timer: 20
seconds
Legend: E=Expecting replies,
R=Responding
Tunnel0:192.168.0.1 RE req-sent 11684 req-failed 0 repl-recv 11613 (00:00:14 ago)
|
And using clear ip
nhrp to reset NHRP cache and dynamic tunnels:
|
R2#clear ip nhrp
|
Configure
IPSec protection
The IPSec configuration is pretty straight forward:
|
crypto isakmp policy 10
encr aes 256
authentication pre-share
!
crypto isakmp key cisco123
address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set
MY_SET esp-aes 256 esp-sha-hmac
!
crypto ipsec profile DMVPN
set transform-set MY_SET
!
interface Tunnel0
tunnel protection ipsec profile DMVPN
end
|
Reference
Cisco document on NHRP protocol:
(Another) great article from Packet Life blog:
No comments:
Post a Comment