Lesson Contents
In previous lessons I explained how DMVPN works and how to configure a basic DMVPN phase 2 network. In this lesson, we’ll take a look how to configure EIGRP on top of it. Here’s the topology we will use:
Above we have one hub router and two spoke routers. Each router has a loopback interface that we will advertise in EIGRP.
Configuration
Tunnel interfaces
Here’s the configuration of the tunnel interface of our hub:
Hub(config)#interface Tunnel0
Hub(config-if)#ip address 172.16.123.1 255.255.255.0
Hub(config-if)#ip nhrp authentication DMVPN
Hub(config-if)#ip nhrp map multicast dynamic
Hub(config-if)#ip nhrp network-id 1
Hub(config-if)#tunnel source GigabitEthernet0/1
Hub(config-if)#tunnel mode gre multipoint
Hub(config-if)#end
Here are our spoke routers:
Spoke1(config)#interface Tunnel0
Spoke1(config-if)#ip address 172.16.123.2 255.255.255.0
Spoke1(config-if)#ip nhrp authentication DMVPN
Spoke1(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke1(config-if)#ip nhrp map multicast 192.168.123.1
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp nhs 172.16.123.1
Spoke1(config-if)#tunnel source GigabitEthernet0/1
Spoke1(config-if)#tunnel mode gre multipoint
Spoke2(config)#interface Tunnel0
Spoke2(config-if)#ip address 172.16.123.3 255.255.255.0
Spoke2(config-if)#ip nhrp authentication DMVPN
Spoke2(config-if)#ip nhrp map 172.16.123.1 192.168.123.1
Spoke2(config-if)#ip nhrp map multicast 192.168.123.1
Spoke2(config-if)#ip nhrp network-id 1
Spoke2(config-if)#ip nhrp nhs 172.16.123.1
Spoke2(config-if)#tunnel source GigabitEthernet0/1
Spoke2(config-if)#tunnel mode gre multipoint
Let’s check if the hub router has two NHRP registrations:
Hub#show dmvpn
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: Tunnel0, IPv4 NHRP Details
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 00:09:48 D
1 192.168.123.3 172.16.123.3 UP 00:09:56 D
And do a quick ping to check if the tunnels are working:
Hub#ping 172.16.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/11 ms
Hub#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 = 6/7/10 ms
No issues there, time to configure EIGRP.
EIGRP
We’ll start with a basic configuration where we advertise all tunnel and loopback interfaces in EIGRP:
Hub(config)#router eigrp 123
Hub(config-router)#no auto-summary
Hub(config-router)#network 172.16.123.0 0.0.0.255
Hub(config-router)#network 1.1.1.1 0.0.0.0
Spoke1(config)#router eigrp 123
Spoke1(config-router)#no auto-summary
Spoke1(config-router)#network 172.16.123.0 0.0.0.255
Spoke1(config-router)#network 2.2.2.2 0.0.0.0
Spoke2(config)#router eigrp 123
Spoke2(config-router)#no auto-summary
Spoke2(config-router)#network 172.16.123.0 0.0.0.255
Spoke2(config-router)#network 3.3.3.3 0.0.0.0
Our hub should now have two EIGRP neighbors:
Hub#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(123)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.16.123.2 Tu0 11 00:00:12 1235 5000 0 3
0 172.16.123.3 Tu0 11 00:00:12 1003 5000 0 3
So far so good, what about the routing tables?
Hub#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/27008000] via 172.16.123.2, 00:00:42, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/27008000] via 172.16.123.3, 00:00:42, Tunnel0
Spoke1#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/27008000] via 172.16.123.1, 00:00:43, Tunnel0
Spoke2#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/27008000] via 172.16.123.1, 00:01:07, Tunnel0
The hub has learned the networks on the loopback interfaces of the spoke routers. The spokes learned the 1.1.1.0/24 network from the Hub but not each other’s networks. Like RIP, EIGRP is a distance vector routing protocol so split horizon is preventing the hub from advertising these networks. Let’s disable split horizon:
Hub(config)#interface Tunnel 0
Hub(config-if)#no ip split-horizon eigrp 123
Now let’s see what we have:
Spoke1#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/27008000] via 172.16.123.1, 00:02:19, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/28288000] via 172.16.123.1, 00:00:23, Tunnel0
Spoke2#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/27008000] via 172.16.123.1, 00:02:22, Tunnel0
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/28288000] via 172.16.123.1, 00:00:27, Tunnel0
The spokes now have learned each others network. There is one problem though…look at the next hop IP address (172.16.123.1). This is the IP address of the hub…when EIGRP advertises a network, it will set its own IP address as the next hop.
Here’s what that means:
Spoke1#traceroute 3.3.3.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 172.16.123.1 7 msec 8 msec 6 msec
2 172.16.123.3 8 msec 9 msec *
When spoke1 tries to reach spoke2, it will go through the hub. That’s not what we want so let’s tell EIGRP not to change the next hop IP address:
Rene,
What is the impact if the traffic go to the hub then to the other spoke ?
Ahmad,
The network will still function, but it will not be optimized. By having traffic go Spoke-Hub-Spoke instead of Spoke-Spoke, you could experience the following:
Great Answer . One thing I need to understand. With spoke to spoke traffic how would the physical path determined ? I believe if it wasn’t spoke to spoke ( spoke-hub-spoke) then the physical path must first hit the hub before reaching the other spoke. Can you clarify this ? Thank you.
Ahmad,
One of the key features (and limitations) of DMVPN Phase 2 is that each spoke can learn routes to every other spoke directly. It learns about these routes from the Hub, so it is ultimately up to the spoke to make its own determination via BGP or its own routing protocol, the best path to take to get to another spoke.
So think of it this way: In Phase 2, the Hub is still the “hub” for the control plane–all routes are learned through the hub. Spokes cannot exchange routes with each other directly. However, the Hub is no longer necessarily in the data p
... Continue reading in our forumWow. Clear. Thank you.