DMVPN – Phase 3

Phase 3 requires mGRE tunnels similar to Phase 2, with tunnels on the hub and spokes of the DMVPN.
Adding an NHRP redirect allows the data plan of the spoke-to-spoke conversations to join the spokes directly without going through the hub.
- This eliminates the requirements to conduct IP CEF resolution.
Phase 3 allows the spokes to support NHRP resolution requests, meaning that the hub is NOT the only device that contains the NHRP database.

High-Level Operations

The spokes register their mappings with the hub.
- This allows the hub and spokes to discover and establish adjacencies dynamically.
- The routers can then exchange routing information.
- The hub is NOT obliged to preserve the information.
- Routes can be summarized, given that they are sent to the spokes.
- Default routes can be sent to the spokes, which improves network scalability.
The spokes receive routing information and fill their CEF tables.
- In this phase of DMVPN, CEF entries should NOT be invalid. They should be complete.
- They should point to the IP of the hub NBMA so that the first packets are CEF switched to the hub and the invalid CEF entries no longer trigger the NHRP resolution.
- The spoke-to-spoke communications are based on the packet NHRP Redirect messages.
mGRE tunnels are configured for NHRP redirect messages.
- This is the first major order for Phase 3, which operates similarly to ICMP redirect IP.
- Incoming IP packets via the mGRE tunnels, which will return on the same interface, send out a source Redirect NHRP message.
  - The message tells the source that the path is NOT optimal and it should find a better path via the NHRP Resolution.
The spokes receive the NHRP Redirect message > the router is an NHRP Request to the same destination IP, which is NOT the NHS (although the package always goes through there). The NHRP Request travels on ALL spokes until it finds the target. This is the normal operation of NHRP Request forwarding, which goes hop by hop.
The spoke (not the NHS) has the resolution. Based on the IP source present in the payload package. It will find the corresponding spoke in its routing table.
- It uses the source NBMA IP router and returns an NHRP reply directly ( without traversing the hub).
- The reply arrives on the source router, which learns the NBMA IP destination. Now, in addition to rewriting the NHRP table, the router rewrites the CEF entry.

The rewriting of the CEF is called NHRP SHORTCUT.
Instead of having a CEF adjacency that triggers the NHRP Request, the CEF entry is rewritten when the NHRP Response is received.
Traffic is switched at all times.
The NHRP responses update the table of the router CEF entries.

Summary

NHRP is needed for the spoke registration to the hub
NHRP is required for spoke-to-spoke resolution.
When traffic goes from a spoke to the hub, and the hub sees that the destination is reachable via another spoke, it sends an NHRP Redirect, which causes the spoke to install routes to each other.
A spoke-to-spoke tunnel is triggered by the hub via NHRP redirect.
NHRP Resolution is done per true destination and not per next hop, as in phase 2.
Unlike Phase 2, Phase 3’s behavior is less restrictive:
- Summarization is allowed on the hub.
- Default routing is allowed on the hub.
- Next-hop values on the spokes are always modified.

R5 Hub

R5(config-if)#do show run int t2023

interface Tunnel2023
 ip address 172.16.0.5 255.255.255.0
 no ip redirects
 ip nhrp network-id 555
 ip nhrp redirect
 tunnel source Ethernet0/0.100
 tunnel mode gre multipoint
 ip mtu 1476
 ip tcp adjust-mss 1436
end

R1 Spoke

interface Tunnel2023
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip mtu 1476
 ip nhrp map 172.16.0.5 169.1.100.5
 ip nhrp network-id 111
 ip nhrp nhs 172.16.0.5
 ip nhrp shortcut
 ip tcp adjust-mss 1436
 tunnel source 169.1.100.1
 tunnel mode gre multipoint
end

R2 Spoke

interface Tunnel2023
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip mtu 1476
 ip nhrp map 172.16.0.5 169.1.100.5
 ip nhrp network-id 222
 ip nhrp nhs 172.16.0.5
 ip nhrp shortcut
 ip tcp adjust-mss 1436
 tunnel source 169.1.100.2
 tunnel mode gre multipoint
end

R3 Spoke

interface Tunnel2023
 ip address 172.16.0.3 255.255.255.0
 no ip redirects
 ip mtu 1476
 ip nhrp map 172.16.0.5 169.1.100.5
 ip nhrp network-id 333
 ip nhrp nhs 172.16.0.5
 ip nhrp shortcut
 ip tcp adjust-mss 1436
 tunnel source 169.1.100.3
 tunnel mode gre multipoint
end

R4 Spoke

interface Tunnel2023
 ip address 172.16.0.4 255.255.255.0
 no ip redirects
 ip mtu 1476
 ip nhrp map 172.16.0.5 169.1.100.5
 ip nhrp network-id 444
 ip nhrp nhs 172.16.0.5
 ip nhrp shortcut
 ip tcp adjust-mss 1436
 tunnel source 169.1.100.4
 tunnel mode gre multipoint
end

Wireshark Verification

All 4 (Spoke) routers sent an NHRP Registration Request to R5 (Hub), who responded with Registration Reply success codes.

R5#show dmvp

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        T1 - Route Installed, T2 - Nexthop-override
        C - CTS Capable
        # 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: Tunnel2023, IPv4 NHRP Details 
Type:Hub, NHRP Peers:4, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 169.1.100.1          172.16.0.1    UP 00:09:28     D
     1 169.1.100.2          172.16.0.2    UP 00:08:00     D
     1 169.1.100.3          172.16.0.3    UP 00:06:22     D
     1 169.1.100.4          172.16.0.4    UP 00:03:27     D


R5#show ip nhrp

172.16.0.1/32 via 172.16.0.1
   Tunnel2023 created 00:09:34, expire 01:50:25
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.1.100.1 
172.16.0.2/32 via 172.16.0.2
   Tunnel2023 created 00:08:06, expire 01:51:53
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.1.100.2 
172.16.0.3/32 via 172.16.0.3
   Tunnel2023 created 00:06:28, expire 01:53:31
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.1.100.3 
172.16.0.4/32 via 172.16.0.4
   Tunnel2023 created 00:03:32, expire 01:56:27
   Type: dynamic, Flags: unique registered used nhop 
   NBMA address: 169.1.100.4 
R5#

Configure loop back on R1-R4

Configure EIGRP

Because EIGRP uses multicast to form adjacencies, multicast capabilities must be provided to all routers.

R5 Hub

The ip nhrp map multicast dynamic provides R5 with multicast capability.

R5(config)#int tunnel 2023

R5(config-if)#ip nhrp map multicast dynamic 

interface Tunnel2023
 ip address 172.16.0.5 255.255.255.0
 no ip redirects
 ip mtu 1476
 ip nhrp map multicast dynamic
 ip nhrp network-id 555
 ip nhrp redirect
 ip tcp adjust-mss 1436
 tunnel source Ethernet0/0.100
 tunnel mode gre multipoint
end

R5(config)#router eigrp 100

R5(config-router)#no auto-summary 
R5(config-router)#network 172.16.0.5 0.0.0.0

R1 - R4

ip nhrp map multicast 169.1.100.5

If adjacencies fail to form > bounce the tunnel interface on the spokes or us the “IP nhrp registration timeout 5″

R1
router eigrp 100
 network 1.1.1.1 0.0.0.0
 network 1.1.2.1 0.0.0.0
 network 172.16.0.1 0.0.0.0

R2
router eigrp 100
 network 2.1.1.2 0.0.0.0
 network 2.1.2.2 0.0.0.0
 network 172.16.0.2 0.0.0.0

R3
router eigrp 100
 network 3.1.1.3 0.0.0.0
 network 3.1.2.3 0.0.0.0
 network 172.16.0.3 0.0.0.0

R4

router eigrp 100
 network 4.1.1.4 0.0.0.0
 network 4.1.2.4 0.0.0.0
 network 172.16.0.4 0.0.0.0

R5 (Hub) will learn all of the EIGRP routes via its tunnel interface. R5 will not send updates on the same interface where it learned the routes due to split Horizon

Split horizon blocks route information from being advertised by a device out of any interface from which that information originated.

This behavior usually optimizes communications among multiple routing devices, particularly when links are broken. However, with nonbroadcast networks (such as Frame Relay and SMDS), situations can arise for which this behavior is less than ideal. In such situations and in networks that have EIGRP configured, you may want to disable split horizon.

R5#show ip interface tunnel 2023
Tunnel2023 is up, line protocol is up
  Internet address is 172.16.0.5/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1476 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled
  ICMP redirects are never sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  IP fast switching is enabled

Disable split horizon on the interface

R5(config-if)#no ip split-horizon eigrp 100 ?

The spokes should have the routes now.

End to end reachability obtained

R3>en
R3#
R3#tclsh
R3(tcl)#foreach VAR {
+>(tcl)#1.1.1.1
+>(tcl)#1.1.2.1
+>(tcl)#2.1.1.2
+>(tcl)#2.1.2.2
+>(tcl)#3.1.1.3
+>(tcl)#3.1.2.3
+>(tcl)#4.1.1.4
+>(tcl)#4.1.2.4
+>(tcl)#} { puts [exec "ping  $VAR"] }

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/4/9 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/8 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.1.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/4/7 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/6 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.2.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.1.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.1.2.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/8 ms

R3(tcl)#
R3(tcl)#tclquit
R3#
R3#