- 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#