DMVPN Phase 2 RIP Routing

In the previous lesson about DMVPN I explained how to create a basic DMVPN phase 2 configuration, we’ll use this configuration and configure RIP on top of it. Here’s the topology we will use:

We have one hub router and two spoke routers, each router has a loopback interface which we will advertise in RIP.

Configuration

Tunnel Interfaces

Here’s the tunnel interface of the hub router:

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

And here are the 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 do a quick check to verify if the tunnels are working:

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

We see two NHRP registrations on the hub, let’s try a ping to the two spoke routers:

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

We have connectivity, now we can try RIP!

RIP

We’ll start with a basic configuration of RIP, we use version 2 and advertise all networks:

Hub(config)#router rip
Hub(config-router)#version 2
Hub(config-router)#network 1.0.0.0
Hub(config-router)#network 172.16.0.0
Hub(config-router)#no auto-summary

Spoke1(config)#router rip
Spoke1(config-router)#version 2
Spoke1(config-router)#network 2.0.0.0 
Spoke1(config-router)#network 172.16.0.0
Spoke1(config-router)#no auto-summary

Spoke2(config)#router rip
Spoke2(config-router)#version 2
Spoke2(config-router)#network 3.0.0.0
Spoke2(config-router)#network 172.16.0.0 
Spoke2(config-router)#no auto-summary 

Now let’s see what we find in our routing tables:

Hub#show ip route rip 

      2.0.0.0/32 is subnetted, 1 subnets
R        2.2.2.2 [120/1] via 172.16.123.2, 00:00:07, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
R        3.3.3.3 [120/1] via 172.16.123.3, 00:00:06, Tunnel0

The hub has two entries in its routing table, these are the loopback interfaces of the spoke routers. The next hop addresses are the IP addresses on the tunnel interfaces. When we want to resolve them, we’ll use the information from NHRP:

Hub#show dmvpn | begin Hub
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:29:29     D
     1 192.168.123.3      172.16.123.3    UP 00:07:24     D

What about the spoke routers? Let’s check their routing tables:

Spoke1#show ip route rip 

      1.0.0.0/32 is subnetted, 1 subnets
R        1.1.1.1 [120/1] via 172.16.123.1, 00:00:17, Tunnel0

Spoke2#show ip route rip 

      1.0.0.0/32 is subnetted, 1 subnets
R        1.1.1.1 [120/1] via 172.16.123.1, 00:00:08, Tunnel0

The spoke routers only have an entry for the loopback interface of the hub router. The problem here is that by default, split horizon is enabled. If we want direct spoke-to-spoke communication then our spoke routers need to learn each others networks. Let’s disable split horizon on the hub:

Hub(config)#interface Tunnel 0
Hub(config-if)#no ip split-horizon 

Let’s see if this made any difference:

Spoke1#show ip route rip 

      1.0.0.0/32 is subnetted, 1 subnets
R        1.1.1.1 [120/1] via 172.16.123.1, 00:00:10, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
R        3.3.3.3 [120/2] via 172.16.123.3, 00:00:10, Tunnel0

Spoke2#show ip route rip 

      1.0.0.0/32 is subnetted, 1 subnets
R        1.1.1.1 [120/1] via 172.16.123.1, 00:00:01, Tunnel0
      2.0.0.0/32 is subnetted, 1 subnets
R        2.2.2.2 [120/2] via 172.16.123.2, 00:00:01, Tunnel0

Great! The spoke routers learned each others loopback interfaces. Also take a good look at the next hop IP addresses, these are the tunnel addresses of the spoke routers. This should allow the spoke routers to reach each other directly without going through the hub.

Before we test this, let’s enable a debug on all routers so that you can see what is going on behind the scenes:

Hub, Spoke1 & Spoke2
#debug nhrp 
NHRP protocol debugging is on

Now let’s try a traceroute from spoke1 to spoke2:

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.3 6 msec 8 msec * 

As you can see above, our traffic goes from spoke1 to spoke2 directly! Our traffic doesn’t go through the hub router like in DMVPN phase 1.

In our example, both spoke routers don’t know each others NBMA address so they will start sending NHRP resolution requests to the hub router. In the debug below I will only show you the process of spoke1 trying to figure out the NBMA address of spoke2:

Hub#
NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.2
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 85
NHRP: netid_in = 1, to_us = 0
NHRP: nhrp_rtlookup yielded interface Tunnel0, prefixlen 24
NHRP: netid_out 1, netid_in 1
NHRP: nhrp_cache_lookup_comp returned 0x4B423138
NHRP: Forwarding request due to authoritative request.
NHRP: Attempting to forward to destination: 172.16.123.3
NHRP: Forwarding: NHRP SAS picked source: 172.16.123.1 for destination: 172.16.123.3
NHRP: Attempting to send packet via DEST 172.16.123.3
NHRP: NHRP successfully resolved 172.16.123.3 to NBMA 192.168.123.3
NHRP: Encapsulation succeeded.  Tunnel IP addr 192.168.123.3
NHRP: Forwarding Resolution Request via Tunnel0 vrf 0, packet size: 105
      src: 172.16.123.1, dst: 172.16.123.3
NHRP: 129 bytes out Tunnel0

Above you can see that the hub receives a NHRP resolution request from spoke1. It checks it’s cache to see if it knows how to reach spoke1 and it does find an entry because the spoke1 router has already registered himself. The hub router will then forward this resolution request to the spoke2 router.

Here’s what it looks like on spoke1:

Spoke1#
NHRP: NHRP could not map 172.16.123.3 to NBMA, cache entry not found
NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel0 netid-out 1
NHRP: Sending packet to NHS 172.16.123.1 on Tunnel0
NHRP: NHRP successfully resolved 172.16.123.1 to NBMA 192.168.123.1
NHRP: Checking for delayed event /172.16.123.3 on list (Tunnel0).
NHRP: No node found.
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.3, NBMA: 192.168.123.1)
NHRP: Successfully attached NHRP subblock for Tunnel Endpoints         (VPN: 172.16.123.3, NBMA: 192.168.123.1)
NHRP: Enqueued NHRP Resolution Request for destination: 172.16.123.3
NHRP: Checking for delayed event /172.16.123.3 on list (Tunnel0).
NHRP: No node found.
NHRP: Sending NHRP Resolution Request for dest: 172.16.123.3 to nexthop: 172.16.123.1 using our src: 172.16.123.2
NHRP: Attempting to send packet via DEST 172.16.123.1
NHRP: NHRP successfully resolved 172.16.123.1 to NBMA 192.168.123.1
NHRP: Encapsulation succeeded.  Tunnel IP addr 192.168.123.1
NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85
      src: 172.16.123.2, dst: 172.16.123.1
NHRP: 109 bytes out Tunnel0 
NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 133
NHRP: netid_in = 0, to_us = 1
NHRP: Checking for delayed event /172.16.123.3 on list (Tunnel0).
NHRP: No node found.
NHRP: No need to delay processing of resolution event nbma src:192.168.123.2 nbma dst:192.168.123.3
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.3, NBMA: 192.168.123.3)
NHRP: Cleanup up 0 stale cache entries
NHRP: Successfully attached NHRP subblock for Tunnel Endpoints         (VPN: 172.16.123.3, NBMA: 192.168.123.3)172.16.123.1

Above you can see that spoke1 checks its NHRP cache and doesn’t know the NBMA address for 172.16.123.3. It will then generate a NHRP resolution request and sends it to the hub router. It will then receive a NHRP resolution reply that carries the NBMA address of spoke2. Here’s what you will see on spoke2:

Spoke2#
NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.2
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105
NHRP: netid_in = 1, to_us = 1
NHRP: nhrp_rtlookup yielded interface Tunnel0, prefixlen 24
NHRP: request was to us, responding with ouraddress
NHRP: Checking for delayed event 172.16.123.2/172.16.123.3 on list (Tunnel0).
NHRP: No node found.
NHRP: No need to delay processing of resolution event nbma src:192.168.123.3 nbma dst:192.168.123.2
NHRP: Adding Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: NHRP subblock already exists for Tunnel Endpoints         (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Cache already has a subblock node attached for                       Tunnel Endpoints (VPN: 172.16.123.2, NBMA: 192.168.123.2)
NHRP: Attempting to send packet via DEST 172.16.123.2
NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.2
NHRP: Encapsulation succeeded.  Tunnel IP addr 192.168.123.2
NHRP: Send Resolution Reply via Tunnel0 vrf 0, packet size: 133
      src: 172.16.123.3, dst: 172.16.123.2
NHRP: 157 bytes out Tunnel0 
NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.2

Above you can see that spoke2 receives the NHRP resolution request that was forwarded from the hub to spoke2. It realizes that the request has one of its own addresses and decides to reply. It will create a NHRP resolution reply and forwards it to spoke1.

Here’s what the NHRP resolution request and reply look like in wireshark: