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: classful is separated by 192.168.1.x/30 in the middle/transit - this is important especially in this case that RIP is involved.

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 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 protocols containing the Automatic network summarization <u>is</u> in effect sentence.


When R1's Fa0/1 interface goes down, the default summary 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):


Type escape sequence to abort.
Tracing the route to

  1 72 msec 16 msec 0 msec
  2 16 msec 12 msec 8 msec
  3 16 msec 8 msec 12 msec
  4 8 msec 12 msec 8 msec
  5 20 msec 16 msec 20 msec
  6 32 msec 20 msec 20 msec
  7 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:


RIP performs auto-summarization on the classful network boundary every time the major/classful advertised network is different from the major network of the interface onto which the updates are sent !

In our quiz, because the transit links have addressing in major network, 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.

  • auto-summary is enabled by default
  • it does **not** install a Null0 for the auto-summaries that it generates
  • RIPv2 allows turning off the automatic summarization, but RIPv1 does not have this capability

How is the loop formed ?

As explained above, due to auto-summarization being enabled on R1, the major network summary 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 (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 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 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 from its routing table, but it still has another contributing route: the RIP received from R2 ==> it continues to generate the summary
  • since the summary is based on the RIP 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 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 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 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 !


Always disable auto-summarization when performing routing between discontiguous networks !
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router rip
R1(config-router)#no auto-summary

R3#clear ip route *
R#sh ip route rip is subnetted, 1 subnets
R [120/1] via, 00:00:15, Serial0/1 is subnetted, 3 subnets
R [120/1] via, 00:00:15, Serial0/1
                    [120/1] via, 00:00:19, Serial0/0

Type escape sequence to abort.
Tracing the route to

  1  *  *  *
  2  *  *  *

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 null 0


Type escape sequence to abort.
Tracing the route to

  1 40 msec 20 msec 4 msec
  2 !H  *  !H

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.