DMVPN without IPsec

Expand all



Contents
Last updated: June 11, 2014

You must load the initial configuration files for the section, DMVPN, which can be found in CCIE R&S v5 Topology Diagrams & Initial Configurations.

Task

  • Create a DMVPN network between R1 - R5 as follows:
    • R1 - R4 are the DMVPN spokes.
    • R5 is the DMVPN Hub, and the NHRP Next-Hop Server (NHS).
    • Create interface Tunnel0 as a multipoint GRE tunnel.
    • Source the tunnel from the routers' GigabitEthernet1.100 interface.
    • Use IP addressing in the format 155.1.0.Y/24, where Y is the router number.
    • Use an NHRP network ID of 1.
    • Use an NHRP authentication string of NHRPAUTH.
    • Use GRE tunnel key of 2.
    • Ensure that the spokes can send multicast traffic to the hub, and vice versa.
  • Configure IGP routing over the DMVPN tunnel as follows:
    • Enable RIPv2 on the DMVPN tunnel on R1 - R5.
    • All links should be passive interfaces except the DMVPN tunnel.
    • Advertise the routers' Loopback0 networks into RIP.
    • Configure R5 to advertise a default route via RIPv2 to the DMVPN spokes.
  • When complete, ensure that R1 - R5 can reach each other's Loopback0 networks over the DMVPN network.

Configuration

R1:
interface Tunnel0
 ip address 155.1.0.1 255.255.255.0
 ip nhrp authentication NHRPAUTH
 ip nhrp map 155.1.0.5 169.254.100.5
 ip nhrp map multicast 169.254.100.5
 ip nhrp network-id 1 
 ip nhrp nhs 155.1.0.5
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 2
 no shutdown
!
router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0
 passive-interface default
 no passive-interface Tunnel0


R2:
interface Tunnel0
 ip address 155.1.0.2 255.255.255.0
 ip nhrp authentication NHRPAUTH
 ip nhrp map 155.1.0.5 169.254.100.5
 ip nhrp map multicast 169.254.100.5
 ip nhrp network-id 1 
 ip nhrp nhs 155.1.0.5
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 2
 no shutdown
!
router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0
 passive-interface default
 no passive-interface Tunnel0


R3:
interface Tunnel0
 ip address 155.1.0.3 255.255.255.0
 ip nhrp authentication NHRPAUTH
 ip nhrp map 155.1.0.5 169.254.100.5
 ip nhrp map multicast 169.254.100.5
 ip nhrp network-id 1 
 ip nhrp nhs 155.1.0.5
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 2
 no shutdown
!
router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0
 passive-interface default
 no passive-interface Tunnel0


R4:
interface Tunnel0
 ip address 155.1.0.4 255.255.255.0
 ip nhrp authentication NHRPAUTH
 ip nhrp map 155.1.0.5 169.254.100.5
 ip nhrp map multicast 169.254.100.5
 ip nhrp network-id 1 
 ip nhrp nhs 155.1.0.5
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 2
 no shutdown
!
router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0
 passive-interface default
 no passive-interface Tunnel0


R5:
interface Tunnel0
 ip address 155.1.0.5 255.255.255.0
 ip nhrp authentication NHRPAUTH
 ip nhrp map multicast dynamic
 ip nhrp network-id 1 
 tunnel source GigabitEthernet1.100
 tunnel mode gre multipoint
 tunnel key 2
 no shutdown
!
router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0
 passive-interface default
 no passive-interface Tunnel0
 default-information originate 

Verification

Dynamic Multipoint VPN (DMVPN) is a multipoint GRE-based tunneling technology that behaves in many ways like a legacy Frame Relay or ATM hub-and-spoke network. DMVPN consists of one or more hub routers that are configured as Next-Hop Resolution Protocol (NHRP) Next-Hop Servers (NHS). Next-Hop Servers, or simply hubs, are used to create mappings between the public IP address used for the tunnel source, called the NBMA address, and the private IP address used inside of the tunnel, which is simply called the tunnel address. This NHRP mapping is loosely analogous to how Frame Relay and ATM maintained Layer 2 circuit to Layer 3 address mappings through protocols such as Inverse ARP.

The goal of the DMVPN network is to allow any-to-any communication over the private tunnel network, while at the same time not requiring that a full mesh of point-to-point tunnels be formed. Instead, tunnels can be formed on-demand based on the particular destination of traffic. This allows DMVPN designs to achieve very large scalability, because a full mesh of n*(n-1)/2 tunnels is not required.

From a configuration point of view, there are two roles in the DMVPN network, the hub(s) and the spoke(s). The hub and spokes must agree on certain parameters, such as NHRP authentication, GRE tunnel key number, and whether multicast will be supported. The spokes maintain a manual/static mapping of the hub’s tunnel address to NBMA address, while the hub dynamically learns about the spokes through NHRP messages. From a verification point of view, this should be one of the first steps in checking a DMVPN configuration, which is to ensure that the spokes have registered with the hub.

R5#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, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:4, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 169.254.100.1         155.1.0.1    UP 00:29:24     D
     1 169.254.100.2         155.1.0.2    UP 00:29:17     D
     1 169.254.100.3         155.1.0.3    UP 00:29:09     D
     1 169.254.100.4         155.1.0.4    UP 00:29:26     D
!
R5#show ip nhrp 
155.1.0.1/32 via 155.1.0.1
   Tunnel0 created 00:32:02, expire 01:27:57
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.254.100.1
155.1.0.2/32 via 155.1.0.2
   Tunnel0 created 00:31:55, expire 01:28:04
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.254.100.2 
155.1.0.3/32 via 155.1.0.3
   Tunnel0 created 00:31:47, expire 01:28:12
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.254.100.3
155.1.0.4/32 via 155.1.0.4
   Tunnel0 created 00:32:04, expire 01:27:55
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.254.100.4 

The spokes, however, should have this resolution configured statically. This is analogous to a legacy frame-relay map command.

R1#show run int tunnel0 | in map
 ip nhrp map 155.1.0.5 169.254.100.5
 ip nhrp map multicast 169.254.100.5
!
R1#show ip nhrp
155.1.0.5/32 via 155.1.0.5
   Tunnel0 created 00:36:11, never expire 
   Type: static, Flags: used 
   NBMA address: 169.254.100.5

From a data plane encapsulation point of view, R5 knows that the outer IPv4 address of the GRE tunnel going toward 155.1.0.1 should be 169.254.100.1, because this information is provided by NHRP. What this allows DMVPN configurations to do is to not have to manually specify the tunnel destination, which is why this design is termed a "Dynamic Multipoint" tunnel. At this point, the hub and spokes should have IPv4 reachability to each other, as the NHRP mappings have been successfully formed.

R5#ping 155.1.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/9/26 ms
!
R5#ping 155.1.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/21/87 ms
!
R5#ping 155.1.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/8 ms
!
R5#ping 155.1.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/13/26 ms

Note that although DMVPN is a multipoint tunnel, it is not a multicast tunnel. This means that the GRE source IP address and the GRE destination IP address are always unicast. Multicast is, however, supported inside of the tunnel, but essentially as a replicated unicast, similar to how multicast was supported over legacy Frame Relay or ATM PVCs. Multicast support is added to DMVPN by the spokes manually mapping multicast to the hub's NBMA address with the ip nhrp map multicast command, whereas the hub maps multicast as dynamic. This is analogous to the broadcast keyword at the end of a Frame Relay or ATM mapping statement.

The implication of how multicast support works over DMVPN can be seen from how routing protocols behave over DMVPN. Specifically, from an IGP routing point of view, the spokes only learn routes from the hub. This is because, like in Frame Relay or ATM hub-and-spoke networks, multicasts cannot be directly replicated between the spokes. In other words, if you were to enable EIGRP over DMVPN, the spokes would only become EIGRP adjacent with the hub, simply because the spokes do not see each other’s hello packets.

In this specific design, RIPv2 routing is used, with split-horizon enabled on the hub's tunnel interface (the default behavior). However, because the hub is advertising a default route to all the spokes, they do not need the specific routes about each other. This is one simple design technique that can help to scale DMVPN networks.

R1#show ip route rip
Codes: L - local, 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, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is 155.1.0.5 to network 0.0.0.0

R*    0.0.0.0/0 [120/1] via 155.1.0.5, 00:00:10, Tunnel0
      150.1.0.0/32 is subnetted, 2 subnets
R        150.1.5.5 [120/1] via 155.1.0.5, 00:00:10, Tunnel0
      155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R        155.1.5.0/24 [120/1] via 155.1.0.5, 00:00:10, Tunnel0
R        155.1.45.0/24 [120/1] via 155.1.0.5, 00:00:10, Tunnel0
R        155.1.58.0/24 [120/1] via 155.1.0.5, 00:00:10, Tunnel0
!
R5#show ip route rip
Codes: L - local, 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, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      150.1.0.0/32 is subnetted, 5 subnets
R        150.1.1.1 [120/1] via 155.1.0.1, 00:00:13, Tunnel0
R        150.1.2.2 [120/1] via 155.1.0.2, 00:00:03, Tunnel0
R        150.1.3.3 [120/1] via 155.1.0.3, 00:00:09, Tunnel0
R        150.1.4.4 [120/1] via 155.1.0.4, 00:00:21, Tunnel0
      155.1.0.0/16 is variably subnetted, 12 subnets, 2 masks
R        155.1.13.0/24 [120/1] via 155.1.0.3, 00:00:09, Tunnel0
                       [120/1] via 155.1.0.1, 00:00:13, Tunnel0
R        155.1.23.0/24 [120/1] via 155.1.0.3, 00:00:09, Tunnel0
                       [120/1] via 155.1.0.2, 00:00:03, Tunnel0
R        155.1.37.0/24 [120/1] via 155.1.0.3, 00:00:09, Tunnel0
R        155.1.146.0/24 [120/1] via 155.1.0.4, 00:00:21, Tunnel0
                        [120/1] via 155.1.0.1, 00:00:13, Tunnel0

From a traffic forwarding point of view, this network now behaves just like legacy Frame Relay hub-and-spoke, where traffic goes from spoke to hub to spoke.

R1#show ip cef 150.1.2.2
0.0.0.0/0
  nexthop 155.1.0.5 Tunnel0
!
R1#ping 150.1.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/14/45 ms
!
R1#traceroute 150.1.2.2
Type escape sequence to abort.
Tracing the route to 150.1.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.0.5 3 msec 6 msec 15 msec
  2 155.1.0.2 10 msec *  15 msec

This type of design is called "DMVPN Phase 1," because traffic cannot be directly exchanged between the spokes. Technically, "DMVPN Phase 1" uses point-to-point GRE tunnels on the spokes because there is no spoke-to-spoke dynamic tunnel negotiated, as we'll see in following labs. Depending on the traffic patterns of the network (for example, if there is a lot of spoke-to-spoke traffic), this design may not be desirable. In later tasks we will see how this problem is solved with both "DMVPN Phase 2" and "DMVPN Phase 3" configurations.

^ back to top