Here is our topology.
As always we will start with the interface configurations. Notice that in DMVPN Phase 2 the tunnel mode is set to gre multipoint on the spokes and hub vs 'tunnel mode gre' on spokes in Phase 1.
R1#sh run int gig1.151
Building configuration...
Current configuration : 126 bytes
!
interface GigabitEthernet1.151
description Internet_Facing
encapsulation dot1Q 151
ip address 1.1.1.1 255.255.255.0
end
!
R1#sh run int lo100
interface Loopback100
ip address 10.10.10.1 255.255.255.255
end
R2#sh run int gig1.151
Building configuration...
Current configuration : 126 bytes
!
interface GigabitEthernet1.151
description Internet_Facing
encapsulation dot1Q 151
ip address 1.1.1.2 255.255.255.0
end
!
R2#sh run int lo100
interface Loopback100
ip address 10.10.10.2 255.255.255.255
end
R3#sh run int gig1.151
Building configuration...
Current configuration : 126 bytes
!
interface GigabitEthernet1.151
description Internet_Facing
encapsulation dot1Q 151
ip address 1.1.1.3 255.255.255.0
end
!
R3#sh run int lo100
interface Loopback100
ip address 10.10.10.3 255.255.255.255
end
Ping and verify basic Layer 3 connectivity between the routers.
R2#ping 1.1.1.1
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/3/4 ms
R3#ping 1.1.1.1
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/3/4 ms
Next let's move onto configuring the DMVPN including NHRP parameters on all 3 routers. We will use the private subnet 192.168.1.0/24 for the DMVPN tunnel.
R1#sh run int tun0
Building configuration...
Current configuration : 263 bytes
!
interface Tunnel0
ip address 192.168.1.1 255.255.255.0
no ip redirects
!!--Set the MTU to account for the GRE / IPSEC overhead
ip mtu 1400
!!--Optional NHRP Authentication
ip nhrp authentication AUTH
ip nhrp map multicast dynamic
!!--NHRP network-id must match on all routers
ip nhrp network-id 1
ip tcp adjust-mss 1360
tunnel source GigabitEthernet1.151
tunnel mode gre multipoint
end
R2#sh run int tun0
Building configuration...
Current configuration : 291 bytes
!
interface Tunnel0
ip address 192.168.1.2 255.255.255.0
ip nhrp authentication AUTH
!!--Map the NHRP Next hop server to the NBMA address of the HUB
ip nhrp map 192.168.1.1 1.1.1.1
!!--Remember to do map multicast to HUB NBMA address (not the tunnel address) or else routing protocols will not work
ip nhrp map multicast 1.1.1.1
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source GigabitEthernet1.151
tunnel mode gre multipoint
end
R3#sh run int tun0
Building configuration...
Current configuration : 291 bytes
!
interface Tunnel0
ip address 192.168.1.3 255.255.255.0
ip nhrp authentication AUTH
ip mtu 1400
ip nhrp map 192.168.1.1 1.1.1.1
ip nhrp map multicast 1.1.1.1
!!-Make sure network-id matches on all the routers
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source GigabitEthernet1.151
tunnel mode gre multipoint
end
At this point we should full tunnel-to-tunnel-end connectivity.
R1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/6 ms
R1#ping 192.168.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms
R1#show ip nhrp dynamic
192.168.1.2/32 via 192.168.1.2
Tunnel0 created 00:12:18, expire 01:49:03
Type: dynamic, Flags: unique registered used nhop
NBMA address: 1.1.1.2
192.168.1.3/32 via 192.168.1.3
Tunnel0 created 00:09:29, expire 01:50:31
Type: dynamic, Flags: unique registered used nhop
NBMA address: 1.1.1.3
Unlike Phase 1 spoke-to-spoke dynamic tunnels can be created in Phase 2. However, the initial mapping of DMVPN addresses to NBMA addresses of the spokes must be done through the HUB.
R2#show ip nhrp bri
R2#show ip nhrp brief
Target Via NBMA Mode Intfc Claimed
155.1.0.5/32 155.1.0.5 169.254.100.5 static Tu0 < >
192.168.1.1/32 192.168.1.1 1.1.1.1 static Tu0 < >
Notice above that R2 only has 1 tunnel currently and that is to the HUB. Now let's do a traceroute from R2 to R3 and see what happens.
R2#traceroute 192.168.1.3
Type escape sequence to abort.
Tracing the route to 192.168.1.3
VRF info: (vrf in name/id, vrf out name/id)
1 *
192.168.1.3 3 msec *
Seems like it failed at first but then it went through.
As you can see from below consecutives traceroutes are going right through. This is because NHRP had to do the initial mapping of 192.168.1.3 -> R3 NBMA address which is 1.1.1.3.
R2#traceroute 192.168.1.3
Type escape sequence to abort.
Tracing the route to 192.168.1.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.3 2 msec * 2 msec
Also notice that there is a dynamically created tunnel between R2 and R3.
R2#sh ip nhr brief
Target Via NBMA Mode Intfc Claimed
192.168.1.1/32 192.168.1.1 1.1.1.1 static Tu0 < >
192.168.1.3/32 192.168.1.3 1.1.1.3 dynamic Tu0 < >
Dynamic tunnels have a 2 hour window before they are torn down.
R2#show ip nhrp tun0 det
192.168.1.1/32 via 192.168.1.1
Tunnel0 created 00:05:03, never expire
Type: static, Flags: used
NBMA address: 1.1.1.1
192.168.1.3/32 via 192.168.1.3
Tunnel0 created 00:02:51, expire 01:57:08
Type: dynamic, Flags: router nhop
NBMA address: 1.1.1.3
Let's take a look from the packet capture perspective.
- The first packet from R2 towards R3 generates the NHRP request from R2 which is sent to the NHS (Next Hop Server / R1 in this case) NBMA address.
- NHS then forwards the request to R3. R3 then responds back to the R2's NHRP's request with a NHRP reply which tells R2 the address to build the dynamic tunnel.
Now that we have DMVPN Phase 2 working, let's get EIGRP configured over the DMVPN tunnel and make sure that spoke-to-spoke tunnels are created dynamically.
R1# show run | sec eigrp
router eigrp 100
network 10.10.10.1 0.0.0.0
network 192.168.1.0
!!--Disable split horizon so the route advertisements from the spokes can be reflected to each other.
R1# sh run int tun0 | in split
interface Tunnel0
no ip split-horizon eigrp 100
R2# show run | sec eigrp
router eigrp 100
network 10.10.10.2 0.0.0.0
network 192.168.1.0
R3# show run | sec eigrp
router eigrp 100
network 10.10.10.3 0.0.0.0
network 192.168.1.0
Now let's do traceroute to see if dynamic spoke to spoke tunnels are created.
R2#traceroute 10.10.10.3
Type escape sequence to abort.
Tracing the route to 10.10.10.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.1 5 msec 4 msec 4 msec
2 192.168.1.3 4 msec * 4 msec
Looks like the traffic from R2 to R3 is still going through the HUB. Reason this is happening is because EIGRP is modifying the next hop ...
R2#show ip route eigrp 10.0.0.0/32 is subnetted, 3 subnets D 10.10.10.1 [90/27008000] via 192.168.1.1, 00:05:33, Tunnel0 D10.10.10.3 [90/28288000] via 192.168.1.1, 00:04:18, Tunnel0
To disable next-hop modifications in EIGRP on R1 ... "no ip next-hop-self eigrp 100"
R1#sh run int tun0
Building configuration...
Current configuration : 325 bytes
!
interface Tunnel0
no ip next-hop-self eigrp 100
Now when you take a look at the RIB on R2 ...
R2#show ip route eigrp
10.0.0.0/32 is subnetted, 3 subnets
D 10.10.10.1 [90/27008000] via 192.168.1.1, 00:01:12, Tunnel0
D 10.10.10.3 [90/28288000] via 192.168.1.3, 00:01:11, Tunnel0
Now the traffic is sent directly from R3 to R2.
R2#traceroute 10.10.10.3
Type escape sequence to abort.
Tracing the route to 10.10.10.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.3 4 msec * 3 msec
Although the traffic is sent directly between the spokes the EIGRP adjaceny is still formed just with the HUB.
R2#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.1 Tu0 12 00:04:14 24 1470 0 13
This is due to the fact that multicast / EIGRP hellos are exchanged only with the HUB.
To wrap it up ... key notes about DMVPN Phase 2 ...
- Tunnel mode gre multipoint on spokes
- Make sure to configure the routing protocol to 'leave the next hop unchanged'
- Route summarization at the HUB is not possible
- Remember that the dynamic tunnels are formed based on the next hop. If you summarized SPOKE subnets at the HUB then the next hop from the spoke's view would be HUB's DMVPN IP and in turn the other spokes will not be able to build a dynamic tunnel to the destination spoke. However, in DMVPN Phase 3 summarization by the HUB is possible because the dynamic tunnels are not formed based on the spoke's view of the next hop.
- Still requires the initial mapping of spoke tunnel address to NBMA address to go through the HUB
Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.
No comments:
Post a Comment