Monday, December 7, 2015

Configuring DMVPN Phase 2 w/ EIGRP

In this blogtorial we will configure DMVPN Phase 2 and configure EIGRP over the DMVPN tunnel. Over the past few blogtorials we've been concentrating on how to configure DMVPN Phase 1 and routing protocols over DMVPN Phase 1. One of the key disadvantage of Phase 1 is that all spoke to spoke traffic must pass through the HUB which is a bit inefficient. DMVPN Phase 2 improves on DMVPN Phase 1 by allowing for on-demand dynamic spoke to spoke tunnels based on traffic patterns.

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  
 D    10.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
Many more articles to come so ....

Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.