DMVPN relies on next technologies
- Multipoint GRE (mGRE)
- Next-Hop Resolution Protocol (NHRP)
- Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
- Dynamic IPsec encryption
- Cisco Express Forwarding (CEF)
- Multipoint GRE (mGRE)
Classic GRE tunnel is point-to-point, but mGRE generalizes this idea by allowing a tunnel to have “multiple” destinations. mGRE is similar to any NBMA technology such as Frame-Relay or ATM.
The mappings between tunnel IP address and real IP address is done using NHRP.
- Next-Hop Resolution Protocol (NHRP)
With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop (NHRP provides an ARP-like solution for NBMA netwroks).
For NHRP to work you need one or more entities that are capable of answering NHRP Resolution Requests. These entities are next-hop servers (NHS). Every other node will register their tunnel-to-NBMA address mapping with the server and query the server when they need to resolve
peer’s tunnel address. The use of NHRP allows dynamic discovery of new endpoints added
to the DMVPN network and thus frees the administrator from the need of extra
provisioning.
- Dynamic Routing Protocol
DMVPN design recommends the use of a dynamic routing protocol to propagate routes from the headend to the branch offices.
The benefits provided by a dynamic routing protocol are:
- Network topology information
- Topology change notification
- Remote peer status
EIGRP is recommended as the dynamic routing protocol because of its conservation of router CPU cycles and network bandwidth, as well as its quick convergence times. EIGRP also provides a range of options for address summarization and default route propagation.
RIP, OSPF and BGP can also be used as routing protocols for DMVPN
- Dynamic IPsec encryption
Traffic is encrypted when it is forwarded from or to the tunnel interface
- Cisco Express Forwarding (CEF)
tunnel IP address. For a prefix dynamic learned across the DMVPN cloud, CEF will only attempt to resolve the next-hop IP address.
In order to permit direct routing between spokes, all prefixes should be learned by spokes with the next-
hop IP addresses pointing to the route origin.
- In order to accomplish this when dynamic routing protocol is EIGRP use command
no ip next-hop-self eigrp [AS_Number]
- In order to accomplish this when dynamic routing protocol is OSPF use command
ip ospf network-type broadcast
DMVPN Topologies
- Dual hub-dual DMVPN cloud
- Dual hub-single DMVPN cloud
Wherever dual hub is mentioned it means two or more hubs. In these topologies at least two hubs are recommended for redundancy.
A DMVPN cloud topology can support either a hub-and-spoke or spoke-to-spoke deployment model.In a hub-and-spoke deployment model, each headend uses an mGRE interface and each branch uses a p2pGRE or mGRE interface. In a spoke-to-spoke deployment model, both the headend and the branch must use mGRE interfaces.
- Dual DMVPN Cloud Topology
- Single DMVPN Cloud Topology
In general the single DMVPN cloud topology is best when dynamic spoke-spoke tunnels are required, because spoke-spoke tunnels can only be built within a DMVPN cloud not between DMVPN clouds. The dual DMVPN cloud topology is often easier for hub-and-spoke only networks, in this case it can be easier to configure the routing protocol to prefer one DMVPN cloud (hub) over the other since the routing protocol receives routing information from the hubs on different tunnel interfaces.
Scenario A - Single Cloud Single Hub, hub-and-spoke DMVPN
- In a hub-and-spoke model tunnels are continuously up.
- When a spoke wants to transmit a packet to another spoke, traffic will be routed trough hub router.
- Tunnel created on the spoke to the hub will be a point-to-point tunnel.
- ISAKMP and IPsec config
Same config on all devices (hub and spokes)
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac
crypto ipsec profile DMVPN
set transform-set 3DES
- Tunnel configuration - hub
interface Tunnel100
ip address 10.1.1.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source Loopback100
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
- Tunnel configuration - spoke
- spoke1
interface Tunnel100
ip address 10.1.1.2 255.255.255.0
ip nhrp map 10.1.1.1 1.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
tunnel source Loopback100
tunnel destination 1.1.1.1
tunnel protection ipsec profile DMVPN
- spoke2
interface Tunnel100
ip address 10.1.1.3 255.255.255.0
ip nhrp map 10.1.1.1 1.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
tunnel source Loopback100
tunnel destination 1.1.1.1
tunnel protection ipsec profile DMVPN
- EIGRP configuration
- hub
router eigrp 100Because of EIGRP split-horizon filters updates received by hub from spoke1 and spoke2 are never sent back on the Tunnel 100 interface. If communication between spoke1 and spoke2 is required you need to disable split-horizon on hub device.
network 10.1.1.0 0.0.0.255
network 192.168.1.0
no auto-summary
interface Tunnel100
no ip split-horizon eigrp 100
Verification:
hub#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1001 1.1.1.1 2.2.2.2 ACTIVE 3des md5 psk 2 23:48:31
Engine-id:Conn-id = SW:1
1002 1.1.1.1 3.3.3.3 ACTIVE 3des md5 psk 2 23:48:45
Engine-id:Conn-id = SW:2
hub#show crypto ipsec sa detail
interface: Tunnel100
Crypto map tag: Tunnel100-head-0, local addr 1.1.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 152, #pkts encrypt: 152, #pkts digest: 152
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2
path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
current outbound spi: 0x4DAA0FBB(1302990779)
protected vrf: (none)
local ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/47/0)
current_peer 3.3.3.3 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 150, #pkts encrypt: 150, #pkts digest: 150
#pkts decaps: 143, #pkts decrypt: 143, #pkts verify: 143
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 1.1.1.1, remote crypto endpt.: 3.3.3.3
path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
current outbound spi: 0x62CB1B9B(1657478043)
hub#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.1.3 Tu100 10 00:11:05 681 5000 0 7
0 10.1.1.2 Tu100 12 00:11:06 36 5000 0 7
spoke1#show ip route eigrp
D 192.168.1.0/24 [90/297372416] via 10.1.1.1, 00:10:33, Tunnel100
D 192.168.3.0/24 [90/310172416] via 10.1.1.1, 00:09:37, Tunnel100
spoke1#traceroute 192.168.3.1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
1 10.1.1.1 40 msec 8 msec 8 msec
2 10.1.1.3 16 msec * 16 msec
- Unlike hub-and-spoke model, when one spoke wants to communicate to another spoke it doesn't do so via the hub.
- When a spoke wants to transmit a packet to another spoke, it uses NHRP to dynamically determine the required destination address of the target spoke.
- The hub router acts as the NHRP server and handles this request for the source spoke, but there ends it's role in this particular transaction
- The two spokes dynamically create an IPsec tunnel between them (via the single mGRE interface) and data can be directly transferred.
- This dynamic spoke-to-spoke tunnel will be automatically torn down after a (configurable) period of inactivity
- The spokes can no longer be a point-to-point tunnel. Like the hub they will need to be able to dynamically accept incoming SA requests. Tunnels in a spoke-to-spoke setup are multipoint (mGRE) tunnels.
- The spokes still learn all routing updates via the hub. Neighborships are still formed only between the hub and the spoke. The hub must be configured so that it doesn't set itself as the next hop for all routes that it advertises
- ISAKMP and IPsec config
Same config on all devices (hub and spokes)
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key CISCO address 0.0.0.0 0.0.0.0
crypto ipsec transform-set 3DES esp-3des esp-md5-hmac
crypto ipsec profile DMVPN
set transform-set 3DES
- Tunnel configuration - hub
interface Tunnel100
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
no ip split-horizon eigrp 100
tunnel source Loopback100
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
- Tunnel configuration - spoke
- spoke1
interface Tunnel100
ip address 10.1.1.2 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp map 10.1.1.1 1.1.1.1
ip nhrp map multicast 1.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
tunnel source Loopback100
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
- spoke2
interface Tunnel100Without "ip nhrp map multicast 1.1.1.1" command, EIGRP protocol will not exchange any multicast packets between hub and spokes.
ip address 10.1.1.3 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp map 10.1.1.1 1.1.1.1
ip nhrp map multicast 1.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.1.1.1
tunnel source Loopback100
tunnel mode gre multipoint
tunnel protection ipsec profile DMVPN
- EIGRP configuration
- hub
router eigrp 100
network 10.1.1.0 0.0.0.255
network 192.168.1.0
no auto-summary
Because of EIGRP split-horizon filters updates received by hub from spoke1 and spoke2 are never sent back on the Tunnel 100 interface.
in this model design traffic from spoke1 to spoke2 should not pass trough hub device. In order to accomplish this next EIGRP configuration is needed:
interface Tunnel100
no ip next-hop-self eigrp 100
no ip split-horizon eigrp 100
Verification
spoke1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1003 2.2.2.2 1.1.1.1 ACTIVE 3des md5 psk 2 23:37:29
Engine-id:Conn-id = SW:3
1004 2.2.2.2 3.3.3.3 ACTIVE 3des md5 psk 2 23:45:08
Engine-id:Conn-id = SW:4
spoke1#show crypto ipsec sa detail
interface: Tunnel100
Crypto map tag: Tunnel100-head-0, local addr 2.2.2.2
protected vrf: (none)
local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/47/0)
current_peer 1.1.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 333, #pkts encrypt: 333, #pkts digest: 333
#pkts decaps: 339, #pkts decrypt: 339, #pkts verify: 339
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 1, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 2.2.2.2, remote crypto endpt.: 1.1.1.1
path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
current outbound spi: 0xE6C15153(3871428947)
protected vrf: (none)
local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/47/0)
current_peer 3.3.3.3 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 7, #pkts encrypt: 7, #pkts digest: 7
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 2.2.2.2, remote crypto endpt.: 3.3.3.3
path mtu 1514, ip mtu 1514, ip mtu idb Loopback100
current outbound spi: 0xF31F30FC(4078907644)
hub#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.1.3 Tu100 13 00:16:59 43 5000 0 21
0 10.1.1.2 Tu100 11 00:16:59 848 5000 0 23
spoke1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.1.1 Tu100 11 00:16:53 119 5000 0 24
spoke1#show ip route eigrp
D 192.168.1.0/24 [90/297372416] via 10.1.1.1, 00:17:30, Tunnel100
D 192.168.3.0/24 [90/310172416] via 10.1.1.3, 00:17:30, Tunnel100
spoke1#traceroute 192.168.3.1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
1 10.1.1.3 40 msec * 4 msec
No comments:
Post a Comment