Saturday, February 22, 2020

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:
DMVPN Example Topology with hub, two spokes and loopback interfaces.
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:
DMVPN Phase 2 resolution request spoke to hub
Above we see that the NHRP resolution request is generated by spoke1, sourced from 192.168.123.2 and destined for 192.168.123.1 (the hub). In the NHRP mandatory part we can see that the source NBMA address is 192.168.123.2 (spoke1) using tunnel address 172.16.123.2. It’s looking for the NBMA address of 172.16.123.3.
When the hub receives this packet, it will forward it to the spoke2 router:
dmvpn phase 2 resolution request hub forwards
Above we see that the hub forwards the NHRP resolution request from the spoke1 router to spoke2. Here’s what spoke2 will do with it:
DMVPN phase 2 resolution spoke2 answers spoke1
Above you can see that spoke2 will generate the NHRP resolution reply and sends it to spoke1.
When spoke1 receives this, it will install the NBMA address of spoke2 in its NHRP cache. We can verify this on the spoke routers:
Spoke1#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:12:18     S
     1 192.168.123.3      172.16.123.3    UP 00:04:37     D
Spoke2#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:12:31     S
     1 192.168.123.2      172.16.123.2    UP 00:04:45     D
Above we can see that the spoke routers have installed an entry for each others NBMA address. The “D” attribute indicates that this entry was dynamically learned.
Want to take a look at the wireshark captures yourself? You can find them here:
hostname Hub
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.1 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 no ip split-horizon
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
!
interface GigabitEthernet0/1
 ip address 192.168.123.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router rip
 version 2
 network 1.0.0.0
 network 172.16.0.0
 no auto-summary
!
end
hostname Spoke1
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.2 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.123.1 192.168.123.1
 ip nhrp map multicast 192.168.123.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.123.1
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
!
interface GigabitEthernet0/1
 ip address 192.168.123.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router rip
 version 2
 network 2.0.0.0
 network 172.16.0.0
 no auto-summary
!
end
hostname Spoke2
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Tunnel0
 ip address 172.16.123.3 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map 172.16.123.1 192.168.123.1
 ip nhrp map multicast 192.168.123.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.123.1
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
!
interface GigabitEthernet0/1
 ip address 192.168.123.3 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router rip
 version 2
 network 3.0.0.0
 network 172.16.0.0
 no auto-summary
!
end



Conclusion

You have now seen how to configure RIP on a DMVPN phase two network and how the NHRP resolution works. RIP is an old routing protocol but it works very well for DMVPN. It doesn’t change the next hop which allows the spoke routers to see the correct next hop addresses. The only thing you need to keep in mind is to disable split horizon.
If you have any questions, feel free to leave a comment!

No comments:

Post a Comment