Behavior of RIP version 1 in contiguous and discontiguous

networks

A question has been raised on CCNA Study Group at CLN1 about RIP version 1 (RIPv1, RIP-1)
behavior. In my view, the point of that discussion was about autosummarization behavior in
contiguous and discontiguous networks. I think that was a good discussion and I felt motivated to
write this document, that might be helpful for anyone who may be curious about it. And I'd just say
curious because for new CCENT/CCNA exams (V2.0) RIP-1 won't be needed anymore, so the kind
of details discussed here might probably not be of interest to you.
All the captures here was made using Putty and GNS3 running Cisco IOS. This was the
topology I used:

Figure 1 - Example topology used in our discussion

As RIP-1 doesn't provide any field to carry the subnet mask information in its updates, the only
possible routes exchanged would be the classful ones (like 10.0.0.0/8, 172.16.1.1/16, 200.1.1.0/24,
for example) since RIP-1 is a classful routing protocol. This fact would be reinforced by RIP feature
called autosummarization, which cannot be disabled in RIP-1 (you can even type in the command
"no auto-summary" into CLI but it will have no effect at all).
Surprisingly, there are some cases in which RIP-running routers would receive and accept
routes for a subnet (like 172.30.115.0/24) instead of summarizing it to the major classful network
(172.30.0.0/16). Regardless of a subnet or a classful network, all that information - the routes – are
supposed to be added to router's routing tables and for this task there are some rules going on the
devices that help them decide between route to a subnet and route to a major classful network. The
question is: where is this decision made - at the sending router, by sending a route in one of those
forms, or at the receiving router, by applying a mask it thinks to be appropriate for a route's network
address received in a RIP update?
I'll try to show in the captures that the answer is "both things happen", that is, the sending router
already sends the route for the subnet (like 172.30.115.0, without the subnet mask information) and
the receiving router uses some logic to apply a proper subnet mask to that subnet. It's worth
mentioning here that the route might even be dropped by either or both the sending and receiving
routers (see the first two links below for this).
You can read about this subject in great books like Cisco Press' OCG, but for the details
discussed here I'll rely most on these (external) links from Cisco's website2:
- Behavior of RIP and IGRP When Sending and Receiving Updates
- Why Doesn't RIP or IGRP Support Discontiguous Networks?;
- Why Don't RIPv1 and IGRP Support Variable-Length Subnet Mask? (read about this at the

1 Cisco Learning Network. See more at this URL https://learningnetwork.cisco.com

2 https://www.cisco.com/
 2

end of this text)

First, I'll put the resulting RIP updates (only for 1 hop-count routes) in the original scenario,
showing the routes advertised by each router and then I will follow this in the captures. Hope this
make it better to understand.
Work of R1:
- R1 advertises the subnet 172.30.0.0 to R2;
Work of R2:
- R2 advertises the subnet 10.0.0.0 to R1 and R3;
- R2 advertises the subnet 209.165.200.228 to R3;
- R2 advertises the subnet 209.165.200.232 to R1;
Work of R3:
- R3 advertises the subnet 172.30.0.0 to R2;
- R3 advertises the subnet 172.30.115.0 to R4;
- R3 advertises the subnet 209.165.200.0 to R4;
Note: The subnet 172.30.200.32 is not advertised. We'll get to it later when to see when this
subnet would be advertised.
Work of R4:
- Due to split horizon rules, R4 won't advertise any subnet in this topology.
In this discussion, we'll look at the captures of R3 and R4 because these two are the interesting
ones. For R1 and R2, except for the 209.165.200.228 and 209.165.200.232 subnets, all the other
subnets will be advertised as classful networks (172.30.0.0 and 10.0.0.0 – this one was not listed
above because it's a 2 hop-count route), which is the expected behavior of RIP-1 in discontiguous
networks.
So, the first thing we'll look at R3 is its routing table:

Figure 2 - R3's routing table showing VLSM subnets

 3

R3 has a loopback interface (L0) with the IP address 172.30.200.32/28. We will see this subnet
will not be advertised because of the rules of RIP-1.
We can confirm this by looking at R4's routing table:

Figure 3 - R4's routing table after network convergence

Two interesting things here are:

1- Subnet 172.30.200.32 is not in R4's routing table;
2- Subnet 172.30.115.0 was advertised as is and was installed in R4's routing table.
Item no. 2 is the clear example of RIP-1 behavior in contiguous networks. In this case, both R3
and R4 share the network 172.30.100.0/24. Here, two things are going on:
(a) R3 (sending router) is going to advertise the subnet 172.30.115.0. According to Cisco's
website, R3 knows that both this subnet and the subnet of the interface S0/1 (source of the update to
R4) share the same major network (172.30.0.0). Next, R3 confirms that subnet 172.30.115.0/24 also
shares the prefix of the subnet of interface S0/1 (172.30.100.0/24);
(b) R4 (receiving router) is going to receive a route to 172.30.115.0 on its interface S0/0, that
belongs to the subnet 172.30.100.0/24. R4 will then verify that this interface is in the same major
network of 172.30.115.0, so it will automatically apply the subnet mask of that interface (/24) to the
subnet address when adding it to the routing table (172.30.115.0/24 in 1 hop).
That's the answer to the question we made initially: two process take place, the first one at the
sending router and, if it actually advertises the route, the receiving router carries out the second
one, applying a proper mask to that subnet (route) so that it can add it to its routing table.
Item no. 1 is an example of another behavior of RIP-1 in contiguous networks. Again, R3
(sending router) is going to verify that both subnets (172.30.200.32 and 172.30.100.0) share the
same major network 172.30.0.0. However, this time subnet 172.30.200.32/28 is not going to pass
the check of subnet mask, because the interface S0/1 has a mask (prefix) of /24. Because of that, R3
drops this route and doesn't send it to R4.
If R3 sent an update to subnet 172.30.200.32, R4 would apply the mask /24 to it, but that would
be wrong since the subnet has a /28 prefix on R3.
This process is summarized in those two links previously cited at the beginning of this text. The
 4

result of this process can be seen in these two captures from R3 and R4 debugging:

Figure 4 - Debugging information on R3 showing missing update for subnet 172.30.200.32/28

Figure 5 - Debugging information on R4 showing it did not received subnet 172.30.200.32/28 from R3

Now, just to compare things, let's take a look at something slightly different on R3 that could
make it advertise a subnet 172.30.200.0 (we would change the subnet address for the sake of this
example).
If the subnet mask of L0 at R3 was changed from /28 into /24, then this subnet would be
processed as exactly the same as the subnet 172.30.115.0/24. The difference here would be that R4
would have a route to the subnet 172.30.200.0/24 instead of 172.30.200.32.
The next four pictures illustrate the result of this change, just for the sake of comparison.
 5

Figure 6 - R3's new routing table with new subnet 172.30.200.0/24

Figure 7 - Debugging information on R3 showing the new subnet being advertised to R4

 6

Figure 8 - Debugging information on R4 showing an advertisement for the new subnet 172.30.200.0/24

Figure 9 - R4's new routing table with new subnet 172.30.200.0/24 advertised by R3

Another change that could make the subnet 172.30.200.32 be sent to R4 would be to change
interfaces in the subnet 172.30.100.0 for both R3 (S0/1) and R4 (S0/0), from /24 to /28, so that they
could have the same mask as 172.30.200.32/28. However, the implication of this change is that
subnet 172.30.115.0/24 would stop being advertised, since its mask would be different from the
R3's S0/0 subnet mask (/28).
Finally, this discussion also slightly draws attention to another topic since we are talking about
different subnet masks: VLSM. That's why I put the third link from Cisco's website, for as we all
know, RIP-1 has also the limitation of not supporting VLSM.

Elias Meira dos Santos, Brazil, São Paulo, 2013