RIP Behavior - Discontigous Networks

In this post, we will discuss RIP protocol behavior for discontiguous networks.


Referring above algorithm, let's take an example of below topology and study the discontiguous network behavior in RIP.


Let's also assume we are running RIP version 1 in above topology. Below outputs/results will be seen.

1. R1 advertises Lo0 to R2. Because it is a host route, and we are using Cisco IOS in above topology, R1 advertises the subnet 172.16.0.1/32 to R2 because Lo0 and source interface F1/0 have a same major network (172.16.0.0) irrespective of the subnet mask configured (i.e. Lo0 has /32 and F1/0 has /30 subnet mask).

2. When R1 tries to advertise Lo1 which has the same major network as F1/0 but different subnet mask, R1 will drop network and will not advertise it.

3. R1 will successfully advertise Lo2 to R2 because Lo2 has the same major network and same subnet mask as F1/0.
4. While R1 will try to advertise Lo10 which has different major network compared to interface F1/0,  R1 will summarize 10.10.10.1/32 to its default Class A boundary and advertises the network 10.10.10.0 to R2.
5. The same behavior will be seen on R3 and while it will advertise it Lo10 to R2, it will also summarize this subnet to default Class A boundary and advertises the network 10.0.0.0/8.
6. R2 will receive the same network 10.0.0.0/8 from 2 routers(directions) with the same metric (hop count 1) and will install both routes in its routing table.

R2#  sh ip route 10.10.10.1
Routing entry for 10.0.0.0/8
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 172.16.23.2 on FastEthernet1/1, 00:00:13 ago
  Routing Descriptor Blocks:
  * 172.16.23.2, from 172.16.23.2, 00:00:13 ago, via FastEthernet1/1
      Route metric is 1, traffic share count is 1
    172.16.12.1, from 172.16.12.1, 00:00:16 ago, via FastEthernet1/0
      Route metric is 1, traffic share count is 1

7.  R1 cannot ping Lo10 or R3 and vice versa because R2 will not advertise the network 10.0.0.0/8 back to R1 and R3 which it has received from them only. Hence R1 and R3 cannot reach each other because of incomplete routing.

R1#sh ip route 10.10.10.3
% Subnet not in table

R3#sh ip route 10.10.10.1
% Subnet not in table

Solution :  

Let's enable RIPv2 on all routers and configure disable auto summarization on all.

R1(config)#
R1(config)#Router RIP
R1(config-router)#version 2
R1(config-router)#no auto-summary

Similarly, configure the same on R2 and R3. After the above configuration, the Discontiguous routing behavior will disappear and we will see complete routing end to end.

R1#sh ip route 10.10.10.3
Routing entry for 10.10.10.3/32
  Known via "rip", distance 120, metric 2
  Redistributing via rip
  Last update from 172.16.12.2 on FastEthernet1/0, 00:00:01 ago
  Routing Descriptor Blocks:
  * 172.16.12.2, from 172.16.12.2, 00:00:01 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1

R1#ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/60/68 ms

Similarly, R3 will be able to ping Lo10 (10.10.10.1/32) of R1.

Important note:  Besides RIP, IGP protocols like EIGRP (by default) follow the same behavior w.r.t discontiguous networks.  To disable this behavior, for example on EIGRP, disable auto summarization using "no auto-summary" command.