Get Full Access to our 662 Cisco Lessons Now Start $1 Trial
You are here: Home » Cisco » CCIE Routing & Switching

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.

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



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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
Give Membership a try - it's just $1 ►

501 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , , ,

Forum Replies

  1. Rene,

    When would we choose to use Phase 1, 2, or 3, and why? I understand the differences between the three, but do we gain any benefit from implementing one or the other that is noticeable to end users?

    It seems to me that perhaps allowing spoke routers to talk to each other may decrease latency in the real world, as they would not have to hop through the hub router, but other than that I’m not sure.

    Thanks,

    Patrick

  2. Hi Patrick,

    The different versions are like an evolution of DMVPN. We don’t really use phase 1 anymore unless you have a really good reason why you want to force all traffic through the hub (security perhaps?). Otherwise, it’s more effective to allow spoke-to-spoke traffic.

    Both phase 2 and 3 allow spoke-to-spoke traffic, the advantage of phase 3 is that we use the “shortcuts” so you don’t need specific entries anymore in the routing tables of the spoke routers. I can’t think of any advantages right now that phase 2 has over phase 3 so if you implement this, yo

    ... Continue reading in our forum

  3. Hello Heng

    This is a very good question. Looking at the process in more detail, when using Phase 3.

    Initially, (and that is the key word) all spoke to spoke packets are switched across the hub. In order for a spoke to learn about the true NBMA IP address of another spoke, the NHRP redirect message is used.

    So when a hub receives an IP packet inbound on its interface and switches it out of the same interface, it sends a special NHRP redirect message to the source indicating that this is a suboptimal path. It should look for a better way using NHRP resolution.

    ... Continue reading in our forum

  4. Hello Lagapides
    Thank you so much for your time. I got it now .
    Sovandara

  5. Thanks Laz - I’ve only ever known ethernet in my time as a network engineer so to imagine that something else can exist in it’s place at layer 2 is a strange concept for me! :open_mouth:

    I’ve since heard that home power line network can actually be used to shuttle ethernet frames around too… absolute madness! :wink:

40 more replies! Ask a question or join the discussion by visiting our Community Forum

We use cookies to give you the best personal experience on our website. By using our website, you agree to our use of cookies Read more.