DMVPN Phase 1 RIP Routing

@Manhamane most labs are built using VIRL. Currently, the IOS version is 15.6.2.T

If you happen to be a GNS3 user, my favorite DMVPN image (which has everything you need) is c7200-adventerprisek9-mz.152-4.M6

@Dionisis Which output do you refer to?

Both RIP and EIGRP use the same next hop IP address in DMVPN phase 1?

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
Spoke1#show ip route eigrp 

      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/27008000] via 172.16.123.1, 00:01:27, Tunnel0

Rene

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
Spoke2#show ip route eigrp | include 2.2.2.2
D        2.2.2.2 [90/28288000] via 172.16.123.1, 00:00:41, Tunnel0

but i think the sentence below explains what it happens
EIGRP changes the next hop IP address when it advertises networks.

Hi Dionisis,

That’s right, EIGRP changes it.

Rene

Hi

please check the attached clip, here ‘no ip split-horison’ or jest ‘ip split-horison’.?

Hi Noorudheen,

I don’t see an attachment but the command is no ip split-horizon.

Rene

Hi Rene,
So we call DMVPN is Dynamic mGRE alternatively , rignt ??

One more confusion regarding the output …

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

when Spoke1 want to reach Spoke2(3.3.3.3) , what will be next hop in DMVPN Phase 1 ?? . Its showing 172.16.123.3 but all traffic will go through HUB, right ?Thanks

br//
zaman

Hi Zaman,

mGRE (multipoint GRE) is one piece of the DMVPN puzzle. You also need NHRP.

In DMVPN phase 1, all traffic will go through the hub yes, there is no direct spoke-to-spoke communication.

Rene

Hi,

In one of last capture images, the lesson says : “Above you can see the NBMA addresses”. That is said about loopback adresses 2.2.2.2 and 3.3.3.3 that are attached to Spoke-1 and Spoke-2 routers.

In the context of NHRP, could we say that NBMA does mean the same thing as the whole underlay network (including all “public” networks learned by the Spoke) ?

Hello Maodo

The NBMA in this particular example refers to the nature of the actual physical network, and the addressing of the physical interfaces connected to the medium. That is, the 192.168.123.X subnet. So if this is what you mean by the whole underlay network, then yes you are correct.

I hope this has been helpful!

Laz

I found the definition below of NMBA :

Multi-access means we have to select a DR and BDR.
Non-broadcast means that OSPF expects us to configure neighbors ourselves.

In the article :

According to that ; it seems that NBMA is that “kind-of Frame-Relay network” DMVPN builds on the underlay Network.

Hello Maodo.

Yes you are correct.

Laz

I realised at least on my lab that using the command “ip summary address rip 0.0.0.0 0.0.0.0” does not inject a default route on the spokes, you also have to include the command “default-information originate” under the “router rip” for this to take effect.

Hello Tariq

It seems that others are having similar issues with the ip summary address command when using the RIP protocol. Even so, the solution is not the default-information originate command.

These two commands do different things.

Default-information originate will advertise default route, while ip summary-address rip 0.0.0.0 0.0.0.0 will advertise only default route and will hide topology details. Remember that the ip summary-address command can use a more specific route, such as ip summary-address rip 10.2.0.0 255.255.0.0, it does not have to be 0.0.0.0 0.0.0.0.

Others have had similar problems, and when they change the routing protocol from RIP to EIGRP, it seems that the config works. My suspicion is that you may be using RIP v1 instead of v2. Can you verify that you are indeed using v2?

Then we can take a look at other issues that may be causing this.

I hope this has been helpful!

Laz

Hello Laz,

Thank you for the feedback, however I decided to simulate again with a vIOS and I received the summary-address as expected, so I guess the issue might be a bug on the initial IOS I was using which was the IOS 15.2 on a 7200.

regards,

Tariq

1 Like

Hello Tariq

Great, that’s for sharing that with us. It’s always valuable to hear the solutions to problems that were faced, that way we can all benefit from the experience.

Thanks again!

Laz

Hi Laz,

I am having doubt about TTL, as per 1,2,3 packet I am getting TTL= 255 at spoke 1 when it will send packet to hub TTL received by hub must be 254 and it will forward packet by changing TTL to 253 which will be received by spoke 2 and same in case of when spoke 2 tries to communicate to spoke 1 and in response TTL send by both spokes must be 253 not 255, Kindly suggest still confused in it .

Secondly I am unable to understand split horizon here, b/w two directly connected interface interface i can understand but here single tunnel at Hub connected to two spokes so not understandable, could you explore it how spilt horizon happening here?

Hello Pradyumna

When implementing dynamic spokes using DMVPN, whenever there is communication from spoke to spoke, the HUB does not decrement the TTL of the packets exchanged. This is because the traffic is hidden within the dynamic tunnel. The next-hop from the point of view of the packet inside the GRE tunnel is the other spoke, so no TTL decrement takes place.

The split horizon rule states that you cannot advertise a route out of the same interface that you have learned it from. As a result, if a packet comes into an interface, it should never be routed out of that same interface. But this is a problem for Phase 1 DMVPN with RIP, because that is exactly what has to happen. Packets going from Spoke1 to Spoke2 must enter the Gi0/1 interface on the HUB router, and exit it once again. Therefore split horizon must be disabled.

I hope this has been helpful!

Laz

Hi Laz,

Could you explain this packet capture in wireshark packet capture, actually I am unable to read this source to destination reachability through DMVPN where where we are using two ip header and one gre header but don’t know which header will remove at what point and how so please explain like packet flow?

One more thing what does it mean two time IPv4 upper and below and GRE in the middle, what is that mean? kindly help to read Wireshark.

  1. I think we can do communication b/w spokes by using static route or default route on hub as well as spokes, or using any routing protocol on hub but default route on spokes.
    can we do this?

Hello Pradyumna

The encapsulation is exactly the same as that found with normal GRE. Taking it step by step from the beginning:

  1. Spoke1 creates an ICMP message and encapsulates it into an IPv4 packet with a source and destination address of 2.2.2.2 and 3.3.3.3 respectively. These are the IP addresses of the source of the ICMP echo, and the destination host from which a reply is expected.
  2. This IPv4 packet is then encapsulated with a GRE header which simply tells the router that a tunnel is created and IP is the internal protocol used.
  3. This is then encapsulated into another IP packet this time using the source and destination addresses of 192.168.123.2 and 192.168.123.3 which are the public IP addresses. This header is used to get the packet from one router to the other.
  4. Once it arrives at the destination, the Spoke2 router recognizes that it is a GRE tunneled packet, removes the encapsulations until it gets to the internal IPv4 packet which routes it to its intended destination of 3.3.3.3.
  5. The ICMP message is then processed and an echo reply is returned using the same procedure in reverse.

More info on the encapsulation process can be found at this post and at this post as well.

This question has been answered at this post.

I hope this has been helpful!

Laz