پیکربندی DMVPN
Let me explain this topology to you:
- R1,R2 and R3 are able to reach each other using their FastEthernet 0/0 interfaces. I used the 192.168.123.0 /24 subnet so that they can reach each other.
- R1 will be the hub router and R2/R3 will be the spoke routers.
- R2 and R3 will establish a tunnel to R1 as shown with the green dotted line.
- When R2 and R3 want to communicate with each other they will create a spoke-to-spoke tunnel as shown with the purple dotted line.
- We will use the 172.16.123.0 /24 subnet for the tunnel interfaces.
- Each router has a loopback interface with an IP address. The routers will reach each others loopback by going through the tunnel interface.
The configuration consists of a number of steps:
- Basic configuration of IP addresses.
- GRE Multipoint Tunnel configuration on all routers
- Encryption of tunnels using IPSEC.
- Routing configuration so the routers can reach each others loopback interfaces.
Let’s get started!
Basic configuration
First we’ll configure the IP addresses on all routers:
R1(config)#interface fa 0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.123.1 255.255.255.0
R1(config)#interface loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255R2(config)#interface fa 0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.123.2 255.255.255.0
R2(config)#interface loopback 0
R2(config-if)#ip address 2.2.2.2 255.255.255.255R3(config)#interface fa 0/0
R3(config-if)#no shutdown
R3(config-if)#ip address 192.168.123.3 255.255.255.0
R3(config)#interface loopback 0
R3(config-if)#ip address 3.3.3.3 255.255.255.255With the IP addresses configured we can continue by setting up the tunnels.
GRE Multipoint Configuration
First we will configure the hub router:
R1(config)#interface tunnel 0
R1(config-if)#ip address 172.16.123.1 255.255.255.0
R1(config-if)#tunnel mode gre multipoint
R1(config-if)#tunnel source fastEthernet 0/0
R1(config-if)#ip nhrp map multicast dynamic
R1(config-if)#ip nhrp network-id 1
R1(config-if)#ip nhrp authentication DMVPNWe will configure an IP address on the tunnel 0 interface and instead of specifying a destination IP address we will configure it as gre multipoint. If you want to use a routing protocol like RIP, OSPF or EIGRP you require the ip nhrp map multicast dynamic command to allow multicast traffic. For each DMVPN setup you require an unique network ID that you can configure with the ip nhrp network-id command. Last but not least, the ip nhrp authentication command enables a password for NHRP queries. I’ve set the password to ‘DMVPN’.
Now let’s configure our spoke routers, R2 and R3:
R2(config)#interface tunnel 0
R2(config-if)#ip address 172.16.123.2 255.255.255.0
R2(config-if)#tunnel mode gre multipoint
R2(config-if)#ip nhrp authentication DMVPN
R2(config-if)#ip nhrp map multicast dynamic
R2(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
R2(config-if)#ip nhrp map multicast 192.168.123.1
R2(config-if)#ip nhrp network-id 1
R2(config-if)#ip nhrp nhs 172.16.123.1
R2(config-if)#tunnel source fastEthernet 0/0Above you can see a number of commands that we didn’t configure on the hub router. We use the ip nhrp map command to map the IP address of the NHS (Next Hop Server) to the outside IP address. In this case 172.16.123.1 is the IP address on the tunnel interface of R1 and 192.168.123.1 is the outside IP address of R1. We also require the ip nhrp nhs command to set the IP address of the NHS.
The ip nhrp map multicast commands configures the spoke router to send multicast traffic only to the hub router, not to other spoke routers.
As the source of the tunnel I specified the FastEthernet 0/0 interface with the tunnel source command. It’s best to specify the interface as the source and not an IP address in case you are using dynamic IP address on the spoke router.
If everything went ok you should see a tunnel coming up on R2:
R2#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to upLet’s configure R3 which is pretty much the same as R2:
R3(config)#interface tunnel 0
R3(config-if)#ip address 172.16.123.3 255.255.255.0
R3(config-if)#tunnel mode gre multipoint
R3(config-if)#ip nhrp authentication DMVPN
R3(config-if)#ip nhrp map multicast dynamic
R3(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
R3(config-if)#ip nhrp map multicast 192.168.123.1
R3(config-if)#ip nhrp network-id 1
R3(config-if)#ip nhrp nhs 172.16.123.1
R3(config-if)#tunnel source fastEthernet 0/0The configuration is the same with the exception of the IP address on the tunnel interface. The tunnel should come up now:
R3#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to upRight now you should have a working multipoint GRE configuration so it’s wise to check this before you continue configuring IPSEC.
Verification of GRE Multipoint Configuration
First we will check the hub router:
R1#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.2 172.16.123.2 UP never D
1 192.168.123.3 172.16.123.3 UP never D Above you see that R1 is the hub router and that is has two peers. There’s a couple of interesting items that we can find here:
- Ent stands for the number of entries in the NHRP database for this spoke router. Normally you will only see 1 entry here.
- Peer NBMA Addr is the IP address on the outside interface of the spoke router, in our example 192.168.123.2 and 192.168.123.3.
- Peer Tunnel Add is the IP address on the tunnel interface of the spoke router.
- State shows if your tunnel is up or down.
- UpDn Tm is the up or down time of the current state (up or down). You will see the time here once we are using the tunnels.
- Attrb means attributes. You can see them at top of the show command. The D stands for dynamic which you will normally see for spoke routers.
Let’s use the same command on the spoke routers:
R2#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 00:43:44 S R3#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 00:46:58 S Right now the spoke routers only have a tunnel that connects to the hub router. Let’s try if we can ping from one router to another…
R2#ping 172.16.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 msR3#ping 172.16.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 msBoth spoke routers are able to reach the hub. Now let’s try to ping between the two spoke routers:
R2#ping 172.16.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 msThe ping is working and this is the interesting part of multipoint GRE. The spoke routers will dynamically create a tunnel between each other as you can see below:
R2#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 00:01:41 S
1 192.168.123.3 172.16.123.3 UP never DR3#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.123.1 172.16.123.1 UP 00:01:42 S
1 192.168.123.2 172.16.123.2 UP never D As you can see another tunnel has been established between R2 and R3. So far so good, multipoint GRE is working but everything is clear text at the moment. It’s time to configure IPSEC to encrypt the tunnels!
Configure IPSEC to encrypt mGRE Tunnels
I’m not going to cover the details of IPSEC, if you don’t know what all the commands are used for, look at the encrypted GRE tunnel with IPSEC article I wrote earlier.
R1,R2 & R3:
(config)#crypto isakmp policy 1
(config-isakmp)#encryption aes
(config-isakmp)#hash md5
(config-isakmp)#authentication pre-share
(config-isakmp)#group 2
(config-isakmp)#lifetime 86400
(config)#crypto isakmp key 0 NETWORKLESSONS address 0.0.0.0
(config)#crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
(config)#crypto ipsec profile MGRE
(ipsec-profile)#set security-association lifetime seconds 86400
(ipsec-profile)#set transform-set MYSET
(config)#interface tunnel 0
(config-if)#tunnel protection ipsec profile MGREWhen you configure the crypto isakmp key you should use IP address 0.0.0.0 if you are using dynamic IP addresses on spoke routers. 0.0.0.0 means it applies to any IP address. Let’s verify if our traffic is encrypted or not…
Verification of IPSEC encrypted tunnels
Just to be sure, do a shut/no shut on the tunnel interfaces after the configuration of IPSEC.
R1,R2 & R3:
(config)#interface tunnel 0
(config-if)#shutdown
(config-if)#no shutdownNext step is to check if IPSEC is active:
R1#show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.123.2 port 500
IKE SA: local 192.168.123.1/500 remote 192.168.123.2/500 Active
IPSEC FLOW: permit 47 host 192.168.123.1 host 192.168.123.2
Active SAs: 2, origin: crypto map
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 192.168.123.3 port 500
IKE SA: local 192.168.123.1/500 remote 192.168.123.3/500 Active
IPSEC FLOW: permit 47 host 192.168.123.1 host 192.168.123.3
Active SAs: 2, origin: crypto mapAs you can see IPSEC is active for both peers. Let’s send some pings to verify if traffic is encrypted or not:
R2#ping 172.16.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msR3#ping 172.16.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msLet’s see if packets are encrypted:
R1#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 192.168.123.1
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.123.2/255.255.255.255/47/0)
current_peer 192.168.123.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 26, #pkts decrypt: 26, #pkts verify: 26As you can see packets in the tunnel are encrypted. There is only one more item for us to configure and that is routing.
DMVPN routing configuration
Our tunnels are up and running and encrypted but the routers are unable to reach each others loopback interfaces because we didn’t configure any routing yet. There are two options:
- Static routing
- Dynamic routing
Static routing is easy, just make sure you use the IP address on the tunnel interfaces as the next hop IP address for your static routes. I’ll give you an example how to configure OSPF:
R1(config)#router ospf 1
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config-router)#network 172.16.123.0 0.0.0.255 area 0
R1(config)#interface tunnel 0
R1(config-if)#ip ospf network broadcastR2(config)#router ospf 1
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0
R2(config-router)#network 172.16.123.0 0.0.0.255 area 0
R2(config)#interface tunnel 0
R2(config-if)#ip ospf priority 0
R2(config-if)#ip ospf network broadcast R3(config)#router ospf 1
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0
R3(config-router)#network 172.16.123.0 0.0.0.255 area 0
R3(config)#interface tunnel 0
R3(config-if)#ip ospf priority 0
R3(config-if)#ip ospf network broadcast When configuring OSPF for DMVPN there are a number of things you have to consider:
- Earlier we used the ip nhrp map multicast command on the spoke routers which means that the spoke routers can only send OSPF hellos to the hub router. This means we’ll have an OSPF hub and spoke topology and the spoke routers should never become the DR or BDR.
- I’m using the OSPF broadcast network type so that the spoke routers will use each others IP addresses as the next hop IP address. If you have no idea what this means you should read my OSPF Next Hop IP Address with different network types article.
Let’s verify our work!
Verification of DMVPN Routing
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:00:33 172.16.123.2 Tunnel0
3.3.3.3 0 FULL/DROTHER 00:00:33 172.16.123.3 Tunnel0R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:00:31 172.16.123.1 Tunnel0R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:00:31 172.16.123.1 Tunnel0The spoke routers have formed an OSPF neighbor adjacency with the hub router. Let’s check the routing tables:
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/11112] via 172.16.123.1, 00:04:16, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11112] via 172.16.123.3, 00:04:16, Tunnel0R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/11112] via 172.16.123.1, 00:04:10, Tunnel0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11112] via 172.16.123.2, 00:04:09, Tunnel0R2 and R3 have learned about the other networks. Note that R2 and R3 are using each others IP address as the next hop for each others networks.
Let’s do a quick ping:
R2#ping 1.1.1.1 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msR2#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msR2 is able to reach the loopback interfaces of R1 and R3. Everything is looking good! I hope this article helps you to configure DMVPN.