Hello Maodo.
Yes you are correct.
Laz
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
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.
Hello Pradyumna
The encapsulation is exactly the same as that found with normal GRE. Taking it step by step from the beginning:
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
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.
I hope this has been helpful!
Laz
When I add ip summary-address rip 0.0.0.0 0.0.0.0
on the Hub. I lose all rip learned routes on the spokes. This is with Split-horizon enable or disabled.
I am using EVE-NG vIOS 15.6
Hello Levi
You should have split horizon enabled when you issue this command. In the lesson, this is stated, but the configuration made seems to be incorrect. I will let Rene know to make the necessary modifications.
In any case, when you apply the changes, it may take RIP several minutes before recovering, so you may need to wait or you can reset the RIP process in order to see the results. In any case, Iāve tested it out in the lab once again and I see that I get the same result as the lesson.
If you are still getting different results, try using some debug commands to see if the RIP advertisements are indeed being sent between the routers.
I hope this has been helpful!
Laz
In the lesson it states āIn a real world scenario, you are probably already using a default route for your Internet connection. In this case, you should use a summary that matches the networks behind your spoke routers instead of a default route.ā How would you do that specifically?
Hello Scott
Letās say we have a single Hub that uses a default route to connect to the Internet. Letās assume that we have three spokes, and behind each spoke we have the following subnets:
We want to create a summary route that includes all of these networks. In the lesson, Rene used a default route like so:
Hub(config-if)#ip summary-address rip 0.0.0.0 0.0.0.0
But this wonāt work since our default route is used to connect to the Internet. We need a summary route that will include all of the subnets of the spoke routers. We can do the following:
Hub(config-if)#ip summary-address rip 192.168.4.0 255.255.252.0
This network and subnet mask combination includes all the subnets on all spokes. For more information on creating summary routes, take a look at this lesson:
I hope this has been helpful!
Laz