DMVPN Phase 1 RIP Routing

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

1 Like

I configured both commands and I can see Default Route learnt by Spokes but the Default Route is flapping almost every 30 seconds on Spokes. Infact, all the RIP Routes on all Routers including Hub are flapping. Not sure if there is some misconfiguration or if its a Bug.

I am using GNS3 Dynamips- Router 7200 version 15.4

Below is my config:

HUB

Hub#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES NVRAM  administratively down down
GigabitEthernet0/0         192.168.123.1   YES NVRAM  up                    up
GigabitEthernet1/0         unassigned      YES NVRAM  administratively down down
GigabitEthernet2/0         unassigned      YES NVRAM  administratively down down
Loopback0                  1.1.1.1         YES NVRAM  up                    up
Tunnel0                    172.16.123.1    YES NVRAM  up                    up
Hub#
Hub#sh run int tunne0
Building configuration...

Current configuration : 266 bytes
!
interface Tunnel0
 ip address 172.16.123.1 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip summary-address rip 0.0.0.0 0.0.0.0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
end

Hub#sh run | s rip
 ip summary-address rip 0.0.0.0 0.0.0.0
router rip
 version 2
 network 1.0.0.0
 network 172.16.0.0
 default-information originate
 no auto-summary
Hub#

Spoke1

Spoke1#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES NVRAM  administratively down down
GigabitEthernet0/0         192.168.123.2   YES NVRAM  up                    up
GigabitEthernet1/0         unassigned      YES NVRAM  administratively down down
GigabitEthernet2/0         unassigned      YES NVRAM  administratively down down
Loopback0                  2.2.2.2         YES NVRAM  up                    up
Tunnel0                    172.16.123.2    YES NVRAM  up                    up
Spoke1#
Spoke1#sh run in
Spoke1#sh run interface tunn
Spoke1#sh run interface tunnel 0
Building configuration...

Current configuration : 287 bytes
!
interface Tunnel0
 ip address 172.16.123.2 255.255.255.0
 ip nhrp authentication cisco
 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/0
 tunnel destination 192.168.123.1
end

Spoke1#
Spoke1#sh run | s rip
router rip
 version 2
 network 2.0.0.0
 network 172.16.0.0
 no auto-summary
Spoke1#
Spoke1#sh ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 172.16.123.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/2] via 172.16.123.1, 00:00:01, Tunnel0
Spoke1#
Spoke1#
Spoke1#
Spoke1#sh ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 172.16.123.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/2] via 172.16.123.1, 00:00:09, Tunnel0
Spoke1#sh ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 172.16.123.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/2] via 172.16.123.1, 00:00:25, Tunnel0
Spoke1#sh ip route rip
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 172.16.123.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/2] via 172.16.123.1, 00:00:05, Tunnel0
Spoke1#

Spoke2

Spoke2#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                unassigned      YES NVRAM  administratively down down
GigabitEthernet0/0         192.168.123.3   YES NVRAM  up                    up
GigabitEthernet1/0         unassigned      YES NVRAM  administratively down down
GigabitEthernet2/0         unassigned      YES NVRAM  administratively down down
Loopback0                  3.3.3.3         YES NVRAM  up                    up
Tunnel0                    172.16.123.3    YES NVRAM  up                    up
Spoke2#
Spoke2#
Spoke2#sh run in
Spoke2#sh run interface tunn
Spoke2#sh run interface tunnel 0
Building configuration...

Current configuration : 287 bytes
!
interface Tunnel0
 ip address 172.16.123.3 255.255.255.0
 ip nhrp authentication cisco
 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/0
 tunnel destination 192.168.123.1
end

Spoke2#sh run | s rip
router rip
 version 2
 network 3.0.0.0
 network 172.16.0.0
 no auto-summary
Spoke2#

Hello Rahul

I’m looking over your configs and at first glance I don’t see a problem. Indeed on Spoke1 you ran the show ip route rip command four times, and every time I see the same default route. Unless I’m missing something, and if I am please feel free to point it out, I don’t see any evidence of route flapping. Can you be more specific in describing the problem you are facing?

Thanks!

Laz

aah, I think I know what is going on Laz.

So if you see the sh ip route rip output that I pasted above. The default route is getting refreshed every 30 seconds on the Spoke. That’s what I mean by Route flap and that is what I am trying to show by entering the same command 4 times. And I think this behavior is expected from RIP as RIP sends full routing update every 30 seconds.

Please correct me if I am wrong Laz. Haven’t touched RIP since long time and wanted to do this RIP Lab for the sake of completeness of the course.

Thanks again for your help!

Hello Rahul

Ah, I see what you mean. This is expected behaviour as you have correctly stated. That timer indicates the amount of time that has gone by since the last update for this particular entry. In other words, it shows how old the information is. Every 30 seconds, RIP does indeed send a new update, so this timer, under normal circumstances, should be reset to zero every 30 seconds. More about this process can be found at the following lesson:

Now a note on terminology. The term flapping is used when something continuously changes (due to a malfunction or due to a bad config). A flapping route is when routing information continues to change in such a way that the next-hop IP continuously changes again and again over time. A flapping interface is one that continuously comes up and goes down over and over again. A flapping interface can cause a flapping route, but a flapping route can also be caused by continuously conflicting routing protocol information. The GRE Tunnel Recursive routing error is a classic case of a flapping route.

Another feature that helps to alleviate flapping in BGP can be found in the following lesson as well.

I may have gone overkill in explaining on this post, but I just wanted to be thorough. :sunglasses:

I hope this has been helpful!

Laz