This article discusses the solutions for quiz 15.
Have a look at the quiz to understand the problem
Who said the dinosaurs are dead ? No, no... they are still among us in the form of RIP, Frame Relay and few others.
This is not a new episode from Discovery Channel, but just another topic that Cisco (still) keeps inside the curriculum for the CCIE exam.
There were people asking me WHY do I talk about RIP ?
Let me ask you something back: imagine you go for the CCIE lab and you need to configure RIP or EIGRP and after reading the entire content of the exam you realize that they don't say anything about the default auto-summarization - so, what do you do? do you disable it or not ?
My point here: you need to be ready for anything and a proper preparation for CCIE exam needs to cover RIP and other topics that are considered "dinosaurs" in today's network world.
Quiz Review
The quiz is about a simple RIP network that worked for some time until the interface connected to users on 1st floor (Fa0/1 on R1) goes down which causes an impact on the entire network. The first problem visible here is the use of discontinuous networks: 172.16.0.0/16 is separated by 192.168.1.x/30 in the middle/transit
I intentionally did not show any configuration in the quiz (it would have been too obvious), but only the output of the routing table.
A closer look at the quiz reveals a classful 172.16.0.0/16 route that exists only on R2 and not on R1. This discrepancy between R1 and R2 should be the starting point for explaining the problem.
Also, the hint section shows the output of show ip protocolsAutomatic network summarization <u>is</u> in effect
When R1's Fa0/1 interface goes down, the default summary 172.16.0.0/16 will loop between R1, R2 and R3 and any traffic for it (different than the connected networks) will loop at layer 3 until TTL expires, burdening the network (details to follow below):
R3#traceroute 172.16.1.1 Type escape sequence to abort. Tracing the route to 172.16.1.1 1 192.168.1.2 72 msec 16 msec 0 msec 2 192.168.1.10 16 msec 12 msec 8 msec 3 192.168.1.5 16 msec 8 msec 12 msec 4 192.168.1.2 8 msec 12 msec 8 msec 5 192.168.1.10 20 msec 16 msec 20 msec 6 192.168.1.5 32 msec 20 msec 20 msec 7 192.168.1.2 20 msec 20 msec 20 msec... and so on...
... read further to understand why it happens like that ...
RIP Automatic Summarization
To understand how the loop is formed, we need to know/remember:
In our quiz, because the transit links have addressing in major network 192.168.1.0/24, it means that R1 will always generate summaries for 172.16.x.x when sent out over these transit links.
This behavior applies to all distance vector protocols: RIP, IGRP, EIGRP. When using EIGRP and RIPv2, you can disable this automatic summarization.
|
NOTES
|
|
How is the loop formed ?
As explained above, due to auto-summarization being enabled on R1, the major network summary 172.16.0.0/16 will loop between R1, R2 and R3. Let's see, step by step, how this happens:
Note: the above diagram shows only the status of summary 172.16.0.0/16 (the other RIP routes are omitted)
Stage 1: Initial (apparently working) status
Due to mistakenly auto-summarization being enabled on R1, this router generates the summary 172.16.0.0/16 and advertises it to both R2 and R3.
The condition to generate the auto-summary is the existence of contributing prefixes, which is satisfied: R1 has a connected 172.16.1.0/24 route. RIP does not uses the behavior of installing Null0 for the summaries they generate !
Stage 2 (for the next 180 sec): R1's Fa0/1 interface goes down
R1's Fa0/1 interface goes down and for the following occurs on R1:
- R1 drops the connected 172.16.1.0/24 from its routing table, but it still has another contributing route: the RIP 172.16.2.0/24 received from R2 ==> it continues to generate the summary 172.16.0.0/16
- since the summary is based on the RIP 172.16.2.0/24 received from R2 and due to split-horizon rules, R1 will stop advertising the summary towards R2
- since the summary is based on the RIP 172.16.2.0/24 received from R2, R1 will advertise the summary with an increased metric towards R3
- R3 will see two equal cost (metric=2) routes for the summary (the new one from R1 and the old one from R2)
- R2 will not see the summary from R1 and it needs to wait 180 seconds before invalidating it
Stage 3 (for the next 60 sec): R2 is holding down the summary
R2 does not receive the summary from R1 for 180 seconds so it will flush it and poison it (advertise it with unreachable metric of 16). The following happens:
- R2 marks the 172.16.0.0/16 summary as down in its routing table and for the next 60 sec does not accept worse metric updates for it
- R3 sees the poisoned summary from R2 and it drops this path from its routing table - R3 will only keep the summary via R1
Stage 4 (next update <30 sec): Flushing expires on R2
The flushing (holding down the summary) expires after a total of 240 sec, so now R2 can happily accept the summary with a worse metric (metric = 3) received from R3 and it sends it further to R1, thus creating the loop in control plane:
- R2 accepts the worse metric (metric=3) via R3 (as opposed to the old metric of 1 from R1)
- R1 will receive (for the first time) this summary with a metric of 4, from R1
- R1 also receives the child subnet 172.16.2.0/24 from R1 so it will continue to generate the summary towards R3
Solutions to Solve the Routing Loop
1. Correct the mistake
The problem is caused by a mistake in configuration on R1: auto-summary is enabled !
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router rip R1(config-router)#no auto-summary R1(config-router)#end R1# ---------------------------------------------- R3#clear ip route * R#sh ip route rip 172.16.0.0/24 is subnetted, 1 subnets R 172.16.2.0 [120/1] via 192.168.1.6, 00:00:15, Serial0/1 192.168.1.0/30 is subnetted, 3 subnets R 192.168.1.8 [120/1] via 192.168.1.6, 00:00:15, Serial0/1 [120/1] via 192.168.1.2, 00:00:19, Serial0/0 R3# R3#traceroute 172.16.1.1 Type escape sequence to abort. Tracing the route to 172.16.1.1 1 * * * 2 * * * ... R3#
2. Manually generate a Null0 for the summary
DISCLAIMER: I would not consider this a solution, but it can solve the problem since the Null0 route will break the routing loop!
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip route 172.16.0.0 255.255.0.0 null 0 R1(config)#end ---------------------------------------------- R3#traceroute 172.16.1.1 Type escape sequence to abort. Tracing the route to 172.16.1.1 1 192.168.1.2 40 msec 20 msec 4 msec 2 192.168.1.2 !H * !H R3#
Juniper Approach
The above problems with the auto-summaries under RIP can not occur on Juniper devices because of different approach used by JunOS: all advertisements are based on routing policies used to import or export routes.
JunOS does not have commands/keywords such as auto-summary, ip summary-address, default-originate or similar that do "magic" things in the background.
Unlike Cisco, Juniper would never advertise a summary unless you manually export it under the RIP protocol and such summary exists in the routing table.
The detailed configuration of this quiz on Juniper devices and more information can be found here.
Thank you for your comments and interest in the quiz!
Subscribe to this blog to get other more interesting quizzes and detailed solutions.
Costi is a network and security engineer with over 10 years of experience in multi-vendor environments. He holds a CCIE Routing and Switching certification and is currently pursuing same expert-level certifications in other areas. He believes that the best way to learn and understand networking topics is to challenge yourself to fix different problems, production-wise or lab-type exams. He also enjoys teaching networking and security technologies, whevever there is an opportunity for it.
Comments
comments powered by Disqus