The first line shows the cpu utilization for the last five seconds, one minute and

five minutes. If CPU is not very busy you can proceed to step 2. Step 2 Disable the time stamp service (optionally) to obtain a better output, disable logging to the console and redirect the output to the RAM memory instead. R3#configure terminal R3(config)#no service timestamps R3(config)#no logging console R3(config)#logging buffered R3(config)#end Step 3 Enable appropriate 'debug' command (here: rip process is being debugged) R3#debug ip rip Step 4 Wait a period of time till output is sent to the RAM memory. Nothing will show on a screen as per step 2. Then disable debugging (here, the alias is used which disables debugging of all processes which is the fastest method). You can disable the specific one as well. In case of my debug this could be: ' undebug ip rip', or 'no debug ip rip'. R3#u all Step 5 Display the content of the debug from the memory buffer and copy it to a text editor for analysis. R3#show logging Step 6 Bring back the previous settings (logging to the console and time stamps). R3#configure terminal R3(config)#no logging buffered R3(config)#logging console R3(config)#service timestamps R3(config)#end For clarity's sake, I have broken the output of ' debug ip rip' into pieces so it is easier for us to analyze the information it provides. In practice, either you learn how to properly interpret the output the way it is presented to you by the system or you can rearrange the output in a text editor. The first debug output (pic. 8) illustrates what R3 is advertising out its Loopback1 interface. It's worth mentioning, that RIPv1 uses broadcast address (255.255.255.255) to announce networks/subnets as explained in lesson 35. RIPv2 will use the multicast address 224.0.0.9.

Pic. 8 - R3's Update out Loopback 1.

Next output (pic. 9) shows what R3 is announcing out its Loopback2 interface. Both loopback interfaces are enabled in RIP so, naturally, the updates are sent out these interfaces. Take a look at the output and analyse both (pic. 8 and pic. 9) comparing them with the topology diagram (pic. 1). Pic. 9 - R3's Update out Loopback 2.

Finally, what we have waited for is the answer to the question why R1 and R2 do not receive the subnets /28 from R3. Look at the below picture (pic. 10). Pic. 10 - R3's update out F1/0.

Suprisingly, R3 does NOT advertise ANYTHING out towards R1 and R2 (out F1/0 interface). We understand, that R3 will not advertise out F1/0 what has been learned on this interface (split-horizon). But why does it not advertise both subnets configured on the loopback interfaces (172.31.3.0/28 and 172.31.3.16/28)? The answer is the rules used in RIP in terms of sending and receiving updates. However, before I'll show you all the rules RIP uses, let's finish our diagnostics and look at what R3is receiving from one of its neighbors R2 (pic. 11). Notice, that the update R3 receives from R2 does NOT contain network mask, only metric (hop-count) like explained in the previous lesson. Pic. 11 - R2 Advertisement for R1 and R3.

RIPv1 Sending and Receiving Updates Rules Now, let me show you the update rules RIP uses which should clarify its behavior shown in this lesson. Pic. 12 - RIP Rules for Sending Updates.

Clearly, according to pic.12, R3 will not advertise /28 subnets since the egress interface (F1/0) DOES belong to the same major B network, but

the network mask on this interface is NOT the same as the subnets being advertised. Egress interface uses /24, whereas the subnet candidates for advertisement use /28. The only way to resolve this issue is to either re-address the subnets according to what is allowed in RIPv1 or use RIPv2 instead. As for the receiving updates in RIP protocol, the rules look as follows: Pic. 13 - RIP Rules for Receiving Updates.

Passive Interface in RIP Protocol You may have noticed that updates are sent out of all interfaces enabled for RIP. Otherwise routing would not work properly. But what if there is no router listening to these advertisements? A router can be connected to networks with no other routers in them. They must be advertised out other interfaces still. In such situation it is a waste of the bandwidth to send RIP advertisements every 30 seconds if no router listens to them. The solution is to use the 'passive-interface' command under the RIP process. When used with RIP protocol, the command will prevent a router from sending advertisements out the passive interface, but the subnet/network address of this interface is going to be included in the updates sent out other interfaces. Also, passive interface in RIP is capable of receiving updates and processing them. Be careful with making the interface 'passive' while using other routing protocol than RIP. The behavior of the same command will be different. In OSPF or EIGRP routing protocols, the ' passive-interface' command prevents these protocols from sending 'hello' packets which has serious implications. More on that in the upcoming posts. As an example, in order to stop sending advertisements out R3's loopback interfaces, the configuration will look like the one shown below: R3#configure terminal R3(config)#router rip R3(config-router)#passive-interface loopback1 R3(config-router)#passive-interface loopback2

This configuration optimizes RIP operation preventing it from sending its periodic advertisements out of both loopback interfaces. Of course, in large systems using RIP is not a common solution. Those who have no other choice, would definitely choose RIPv2 rather than RIPv1. And this is going to be the topic of my next post which finalizes the discussion of RIP fundamentals.

Post Questions and Answers

As per request (look at comments below), I decided to post the explanation for the two very interesting scenarios I received from some anonymous person (forgive me but I did not see your name in the post). First take a look at the picture below. Pic. 14 - RIPv1 Scenarios.

Example 1 Notice that in RIPv1 auto-summarization to the class boundary is always in effect. Also, notice that the update does NOT contain a network mask. R1 receives two RIPv1 updates: 10.0.0.0 from R2. 10.0.1.0 from R3.

The result is as per the rules explain above (pic. 13). R1 is going to have only one RIP prefix which is 10.0.1.0 in its routing table. This is because the rule for receiving update is asking the following question (pic. 13): Do any subnets of the same major class exist in the routing table? Yes! 10.0.1.0 subnet exists, that is why 10.0.0.0 which is less specific (major class) is IGNORED. Example 2

Notice that in RIPv1 auto-summarization to the class boundary is always in effect. Also, notice that the update does NOT contain a network mask.

R1 receives the SAME prefix on two different interfaces F1/0 (10.0.4.1) and S0/1 (10.0.3.1). If the metric is the same, R1 considers both paths: via F1/0 and S0/1 as equal cost paths and performs a load balance. I hope that clarifies these two corner case scenarios! Posted by Jarek Rek at 6:09 PM