In this post I'm going to reinforce all the theory discussed in the two previous posts. But I would like to make it more practical this time. This should help you understand RIPv1 better and hone your skills regarding its implementation. RIPv1 is a good prelude to learning RIPv2 as well since the verification commands are identical for both versions of the protocol. I will finish this lesson off by showing you one quick optimization technique used often with both versions of RIP.
Our topology diagram remains the same.
Pic. 1 - Topology Diagram.
Icons designed by: Andrzej Szoblik - http://www.newo.pl
In my previous post I enabled RIP protocol on all the routers and interfaces in the topology presented. Now is the time to verify its operation.
The first RIP verification command I'd like to introduce is the powerful: 'show ip protocols'. It provides information about which dynamic routing protocols are enabled on a router, if any, also displaying specific information about them (here's RIPv1 information).
Pic. 2 - The 'show ip protocols' output on R1.
Get familiar with the output and pay a special attention to the highlighted pieces of information. The output shows us the following (pic.2):
- Outgoing/incoming filter list - currently, there are no filters applied to updates being sent or received (more on ACLs which are used to do filtering in the upcoming posts).
- Sending updates - RIP is advertising its routing table every 30 seconds and the next update is going to be sent in 16 seconds.
- Invalid after - The routing entry is invalidated (can no longer be used) if it is not refreshed by neighbor(s) in 180 seconds.
- hold down - If the router receives a 'route-poison' message from the neighbor(s), it still does not trust it entirely for another 180 seconds (it is possibly down). After that period of time it invalidates the prefix. Meanwhile, the router keeps sending packets to the destination marked as possibly down like everything is 'a-ok'.
- flushed after - The routing entry is removed from the routing table after 240 seconds if not refreshed by the neighbor(s).
- Default version control - the router is advertising version 1 updates, but able to accept updates from both RIPv1 and RIPv2 enabled routers.
- Automatic Summarization - Automatic summarization is enabled (more on this in 'RIP rules' section later in the post).
- Maximum paths - currently the router can use up to 4 equal cost path (metric identical) to a given destination (configurable: up to 16 in most IOS versions as of writing this post).
- Routing for networks - the router has interfaces in 172.31.0.0 class B networks.
- Routing Information Sources - neighboring router's addresses which the router heard from. The time shows when was the last time R1 received the advertisement from its neighbors (e.g. neighbor 172.31.15.5 sent its update to R1 8 seconds ago). This timer should never show you more than 30 seconds under normal circumstances. If the last update from a neighbor arrived longer than 30 seconds ago, it means that the either the neighbor stopped sending its updates or they do not get through.
As you recall, the 'network' statement we used to enable RIP on the interfaces takes a classful IP address as its argument (like explained in the previous post). There is no other additional keyword available for RIP (others protocols use wildcard mask to accomplish this). In case your router has multiple interfaces configured as subnets of the same major network, they all are going to participate in the RIP domain.
For instance, if on R1 I wanted to enable RIP protocol on S0/2 interface only, with my addressing scheme it is not possible. All interfaces are subnets of the same class B major network (172.31.0.0) and will be automatically encompassed in RIP process. If you try to outsmart it and use the following classless statement, it will be accepted by IOS syntax rules but the resulting configuration is going to look like shown in pic. 3 anyway.
Configuration attempting to enable RIP on S0/2 only:
R1(config)#router rip
R1(config)#network 172.31.14.0
Resulting is the following running configuration:
Pic. 3 - RIP's classless statement result.
Of course, it is possible to filter out what is going to be advertised or which updates are going to be accepted by the RIP process. This however is beyond the scope of this lesson as you do not know necessary tools to accomplish that yet.
Another command that you may find useful if you want to see what is currently in the RIP database is the following:
Pic. 4 - RIP Database.
The best entries in the RIP database (normal route selection process applies) are going to populate the routing table. You already know the command 'show ip route' which displays the full routing table including connected and static routes as well. But you can also try to display RIP routing entries only rather than the whole routing table. Here's your command:
Pic. 5 - RIP Routing Table.
The routing table contains two class C network addresses advertised by R4 and R5 respectively:
Also, it tells us that the R1 has seven subnets of 172.31.0.0 class B network. Hang on a second! We can only see three of them listed in pic. 5:
- 172.31.25.0
- 172.31.24.0
- 172.31.2.0
Where are the remaining four subnets?
Take a closer look at pic. 4 which shows the whole RIP database. Can you see the missing four subnets now? In case you can't spot them in pic. 4 look at the following one (pic. 6) which shows all seven of them. For clarity, I have removed class C networks and highlighted the subnets in question.
Pic. 6 - R1's RIP Subnets.
There are seven subnets of 172.31.0.0 class B network indeed! The RIP database shows them all, but the ones that are directly connected subnets, are not making their way to the routing table. Do you still remember why?
The reason is, of course, related to the route selection process already explained in the previous posts. The router knows them as directly connected subnets with the administrative distance of 1,and the same entries are now in the RIP database (as the 'network' statement encompasses them). Recall that RIP's administrative distance value is: 120. The directly connected networks are always the most preferred ones. That is why, we see them as connected rather than RIP generated entries.
Notice the two entries in the routing table: 172.31.24.0 and 172.31.25.0. They both have two equal cost paths (the same metric) which is correct according to our topology. In that case traffic-sharing (load balancing) is going to occur when packets are sent to these destinations.
However, R1 has not learned 172.31.3.0/28 and 172.31.3.16/28 subnets that should be advertised byR3.
What is the explanation to this?
Let's do some diagnostics on R3 in order to find out what is going on. I'm going to start by checking that RIPv1 has been enabled properly on R3. I want to make sure that the loopback1, loopback2, and F1/0 interfaces participate in the RIP domain (the 'network' statement encompasses them). Here is the result of the test.
Pic. 7 - R3's RIP Information.
It seems that configuration is correct! So, let's take a closer look at what R3 is advertising to their neighbors. In order to see that, we must use 'debug ip rip' command.
WARNING!
Extreme care must be taken when using any debug commands on the production equipment. After the diagnostics have been completed, the debug command(s) must be turned off immediately.
All 'debug' commands are VERY dangerous if used on the production routers. They have enormous impact on the CPU and can potentially crash the device. They are typically used as the commands of the last resort during troubleshooting of a given technology when problem cannot be resolved without data they provide. So we tend to use them only in situations when we cannot do any more damage than there has already been done :-).
However, in the lab it is recommended to learn what information can be obtained using 'debug' commands. They help us gain a deeper understanding of a given technology and may be very helpful in troubleshooting.
Since I use the lab equipment (dynamips/dynagen emulator to be accurate), I can safely enable the following debug command to trace the RIP process without any damage to my gear. In practice, it is best if you redirect the output of the debug commands to RAM memory and then copy its content to a text editor for analysis. Here's how you can do this:
Step 1
Make sure that CPU is not heavily utilized first. Enabling 'debug' commands can create high CPU utilization on the production equipment.
R3#show processes cpu
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!
