Saturday, February 22, 2020

DMVPN Phase 3 RIP Routing

In this lesson we’ll take a look how to configure RIP on a DMVPN phase 3 network. If you are unsure what the differences between the different DMVPN phases are then you might want to start with my introduction to DMVPN first.

We will use the DMVPN phase 3 basic configuration for this example. Here’s the topology we will use:
DMVPN Example Topology with hub, two spokes and loopback interfaces.
We have a hub router and two spoke routers. Here’s the DMVPN phase 3 configuration:
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)#ip nhrp redirect
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-if)#ip nhrp shortcut
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
Spoke2(config-if)#ip nhrp shortcut
Let’s make sure the hub 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:00:04     D
     1 192.168.123.3      172.16.123.3    UP 00:00:03     D
So far so good, can we ping the 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 = 7/8/10 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 = 7/7/8 ms
Our pings are working, time to configure RIP…

RIP

Unlike DMVPN phase 2, our spoke routers don’t need specific entries in their routing tables. The only thing they’ll need is a summary that covers the networks behind all spoke routers or a default route. I’ll configure the hub router so that it will only advertise a default route to the spoke routers:
Hub(config)#ip prefix-list DEFAULT_ROUTE permit 0.0.0.0/0

Hub(config)#router rip
Hub(config-router)#version 2
Hub(config-router)#no auto-summary 
Hub(config-router)#network 172.16.0.0
Hub(config-router)#default-information originate 
Hub(config-router)#distribute-list prefix DEFAULT_ROUTE out Tunnel 0
We will configure the spoke routers so that they advertise everything to the hub:
Spoke1(config)#router rip
Spoke1(config-router)#version 2
Spoke1(config-router)#no auto-summary 
Spoke1(config-router)#network 172.16.0.0
Spoke1(config-router)#network 2.0.0.0
Spoke2(config)#router rip
Spoke2(config-router)#version 2
Spoke2(config-router)#no auto-summary 
Spoke2(config-router)#network 172.16.0.0
Spoke2(config-router)#network 3.0.0.0
That should do it, let’s check the routing tables:
Hub#show ip route 

      2.0.0.0/32 is subnetted, 1 subnets
R        2.2.2.2 [120/1] via 172.16.123.2, 00:00:16, Tunnel0
      3.0.0.0/32 is subnetted, 1 subnets
R        3.3.3.3 [120/1] via 172.16.123.3, 00:00:24, Tunnel0
Spoke1#show ip route rip 

R*    0.0.0.0/0 [120/1] via 172.16.123.1, 00:00:28, Tunnel0
Spoke2#show ip route rip 

R*    0.0.0.0/0 [120/1] via 172.16.123.1, 00:00:02, Tunnel0
Our hub has learned the two networks on the loopback interfaces of our spoke routers. The spokes only have a default route.
In my example I am able to advertise a default route since the underlay network is directly connected. In a real world scenario, your spoke routers probably already use a default route towards the ISP. In that case, you should advertise a summary instead of a default route.
Before we test spoke-to-spoke connectivity, let me show you the NHRP cache on the two spoke routers:
Spoke1#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:22:10     S
Spoke2#show dmvpn | begin Peer
Type:Spoke, NHRP Peers:1, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 00:22:32     S
Right now the two spoke routers only have an entry for the hub router, this will change in a minute. Before I test connectivity between spoke1 and spoke2, let’s enable a debug:
Hub, Spoke1 & Spoke2#debug nhrp 
NHRP protocol debugging is on
Now let’s send a ping:
Spoke1#ping 3.3.3.3 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/10 ms
When both spoke routers don’t know about each others NBMA addresses then this will produce a lot of debug information. In the debug below I filtered some of the lines so that you only see how spoke1 learns the NBMA address of spoke2:
Hub#
NHRP: NHRP successfully resolved 172.16.123.2 to NBMA 192.168.123.2
NHRP: Attempting to Redirect, remote_nbma: 192.168.123.2
NHRP: inserting (192.168.123.2/3.3.3.3) in redirect table
NHRP: Pre-setting NBMA address in NHRP Traffic Indication to: 192.168.123.2
NHRP: Attempting to send packet via DEST 2.2.2.2
NHRP: Switching NHRP Packet using pre-set NBMA: 192.168.123.2
NHRP: Encapsulation succeeded.  Tunnel IP addr 192.168.123.2
NHRP: Send Traffic Indication via Tunnel0 vrf 0, packet size: 97
      src: 172.16.123.1, dst: 2.2.2.2
NHRP: 121 bytes out Tunnel0 
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 32
NHRP: netid_out 1, netid_in 1
NHRP: nhrp_cache_lookup_comp returned 0x0
NHRP: Attempting to forward to destination: 3.3.3.3
NHRP: Forwarding: NHRP SAS picked source: 172.16.123.1 for destination: 3.3.3.3
NHRP: Attempting to send packet via DEST 3.3.3.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: 3.3.3.3
NHRP: 129 bytes out Tunnel0
Above you can see that the receives the packet with destination 2.2.2.2 from spoke1. The hub will then send a NHRP traffic indication to the spoke1 router. This will trigger a NHRP resolution request on spoke1 which is received by the hub.
The resolution request is then forwarded by the hub to spoke2.
Here’s what it looks like on spoke1:
Spoke1#
NHRP: NHRP successfully resolved 172.16.123.1 to NBMA 192.168.123.1172.16.123.1 
NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97
NHRP: netid_in = 1, to_us = 0
NHRP: nhrp_rtlookup yielded Loopback0
NHRP: netid_out 0, netid_in 1
NHRP: Enqueued NHRP Resolution Request for destination: 3.3.3.3
NHRP: Checking for delayed event /3.3.3.3 on list (Tunnel0).
NHRP: No node found.
NHRP: Enqueued NHRP Resolution Request for destination: 3.3.3.3
NHRP: Checking for delayed event /3.3.3.3 on list (Tunnel0).
NHRP: No node found.
NHRP: Sending NHRP Resolution Request for dest: 3.3.3.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 /3.3.3.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: Successfully attached NHRP subblock for Tunnel Endpoints         (VPN: 172.16.123.3, NBMA: 192.168.123.3)172.16.123.3
Above you can see that spoke1 sends the packet to the hub router and then receives the traffic indication. Spoke1 will then create a NHRP resolution request which is sent to the hub router. A few microseconds later, it receives the resolution reply from spoke2 and it learns the NBMA address.
Here’s what it looks like on spoke2:
Spoke2#
NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105
NHRP: netid_in = 1, to_us = 0
NHRP: nhrp_rtlookup yielded interface Loopback0, prefixlen 32
NHRP: netid_out 0, netid_in 1
NHRP: We are egress router for target 3.3.3.3, recevied via Tunnel0
NHRP: Redist mask now 1
NHRP: Checking for delayed event 172.16.123.2/3.3.3.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 
Above you can see that spoke2 receives the NHRP resolution request from the hub router and processes it. It will then create a NHRP resolution reply and sends it to the spoke1 router.
Here’s what the NHRP traffic indication looks like in wireshark:
wireshark capture dmvpn nhrp traffic indication
Above you can see that the hub router sends the traffic indication to spoke1. It also includes the packet that “caused” the indication.
If you check the routing tables of the spoke routers then you will see something has changed:
Spoke1#show ip route nhrp | include 3.3.3.3
H        3.3.3.3 [250/255] via 172.16.123.3, 00:07:19, Tunnel0
Spoke2#show ip route nhrp | include 2.2.2.2
H        2.2.2.2 [250/255] via 172.16.123.2, 00:07:39, Tunnel0
The H is for NHRP which installed two new entries in our routing tables. The spoke routers now know how to reach each other directly. Note the next hop addresses, these have to be resolved using the NHRP cache:
Spoke1#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:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2 192.168.123.3      172.16.123.3    UP 00:06:16   DT1
                          172.16.123.3    UP 00:06:16   DT1
     1 192.168.123.1      172.16.123.1    UP 00:36:10     S
Spoke2#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:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2 192.168.123.2      172.16.123.2    UP 00:06:53   DT1
                          172.16.123.2    UP 00:06:53   DT1
     1 192.168.123.1      172.16.123.1    UP 00:37:00     S
The DT1 attribute means that it’s a dynamic entry and that a route has been installed.
Want to take a look at the wireshark capture yourself? Here’s the capture file:
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
 ip nhrp redirect
 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
 no cdp enable
!
router rip
 version 2
 network 172.16.0.0
 default-information originate
 distribute-list prefix DEFAULT_ROUTE out Tunnel0
 no auto-summary
!
ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
!
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
 ip nhrp shortcut
 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
 no cdp enable
!         
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
 ip nhrp shortcut
 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
 no cdp enable
!         
router rip
 version 2
 network 3.0.0.0
 network 172.16.0.0
 no auto-summary
!
end

Conclusion

You have now learned how to configure RIP on a DMVPN phase 3 network and how the behavior of NHRP changes with the traffic indication message. I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!

No comments:

Post a Comment