Žilinská univerzita > Fakulta riadenia a informatiky > Katedra informačných sietí

Possible bugs/limitations encountered in Cisco's RIP implementation



  1. Default route origination not working reliably.
  2. Automatic summarization turned on causes major networks to be propagated throughout the RIP domain with a metric of 1.
  3. Using RIPv2 on NBMA hub-and-spoke topology causes the hub router to rewrite the next hop field in the RIPv2 update to the IP address of the spoke router advertising the originalupdate, thereby creating reachability issues
  4. When using IP Unnumbered with automatic summarization turned on, the RIP always performs summarization even if the advertised network is in the same major network as the unnumbered interface sourcing the update.
  5. Directly connected supernets can not be included into RIPv2 using the network command.
  6. Manual summarization can not be performed up to a supernet level, nor can multiple manual summaries within the same major network be configured on the same interface.
  7. RIP does not install a discard route when performing summarization.

Issue 1 – Default route origination not working reliably

After entering the command default-information originate in the router rip configuration mode, the router may not be originating the default route in its RIP updates. The workaround is to issue the command clear ip route * on the router afterwards (helps every time) or to reload the router completely. This behavior has been observed frequently but it occurs randomly and no verified sequence of steps is presently known to reproduce the problem with 100% certainty.

There is a noteworthy behavior of RIP that may be related to this issue.

The default-information originate command in the RIP configuration of a router should generate the default route regardlessly of whether that router has a default route in its routing table or not, according to the IOS documentation. However, if the default route is present in the routing table while the default-information originate command is configured, and the default route is then removed from the routing table, the router immediately advertises the default route in RIP as unreachable (with a metric of 16). In a few seconds, it readvertises the default route in RIP again as reachable with an usual metric of 1, even if the default route has not returned back to the routing table. This flapping of default route in RIP advertisements does not make sense as the presence of default route in the routing table should not have any influence on the default route advertisements in RIP updates at all. It appears to be related to the cause of the issue described above. I am suspecting some kind of race condition or deadlock to be  present in the code.

This issue has been observed on various IOSes starting from 12.1 up to 12.4.

Issue 2 – With automatic summarization turned on, the major networks may be propagated with metric of 1

Assume a network of three routers R1, R2, R3 interconnected in a row. The individual IP networks are as follows:

  • R1 local LAN network: 192.168.1.0/24
  • R1/R2 interconnection: 192.168.12.0/24
  • R2/R3 interconnection: 192.168.23.0/24

Assuming that either RIPv1 or RIPv2 with automatic summarization is configured on all routers, the R3 will contain the network 192.168.1.0/24 with the metric of 1 in its routing table. Using the debug ip rip and observing output on R2 and R3 it is confirmed that the R2 sends the route 192.168.1.0/24 with the metric of 1.

A probable cause of this problem is that with RIPv1 or RIPv2 with automatic summarization turned on, the router R2 re-summarizes the 192.168.1.0/24 network to the classful boundary when sending it out the interface to R3, despite the fact that the 192.168.1.0/24 is already summarized classfully. As the R2 is the originator of the new summary, it resets its metric back to 1.

The workaround is to use the RIPv2 with deactivated automatic summary.

This issue was reproducible on various IOS platforms and was last tested on version 12.4(12) advanced IP Services for 2691 series routers.

Issue 3 – RIPv2 creates reachability issues on NBMA hub-and-spoke networks

Assume a network of three routers R1, R2, R3 in a Frame Relay hub-and-spoke topology. R1 acts as a hub router, the R2 and R3 are spoke routers. The PVCs are between routers R1/R2 and R1/R3. The individual IP addresses are:

  • R1 Frame Relay interface: 192.168.123.1/24
  • R2 Frame Relay interface: 192.168.123.2/24
  • R3 Frame Relay interface: 192.168.123.3/24
  • R3 LAN interface: 192.168.3.1/24

Assuming that RIPv2 is configured on all routers and split horizon is turned off on R1's Frame Relay interface, the R2 will see the network 192.168.3.0/24 with the next-hop IP address 192.168.123.3 instead of 192.168.123.1. If the R2 does not contain a DLCI mapping between the IP address 192.168.123.3 and the PVC leading to the hub router, the network 192.168.3.0/24 will not be reachable from R2.

In my opinion, this behavior should be configurable by user since it is unsuitable for traditional hub-and-spoke deployments but it is necessary, for instance, in DMVPN. For comparison purposes, in EIGRP, the default behavior is to rewrite the next hop to the hub's IP address which is the preferred option, and since IOS 12.3, it can be turned off using the command no ip next-hop-self eigrp.

This issue is reproducible and was last tested on version 12.4(12) Advanced IP Services for 2691 series routers.

Issue 4 - RIP automatically summarizes advertised networks on unnumbered links even if the conditions for performing automatic summarization are not met

Assume two routers R1 and R2 interconnected with a serial link using IP Unnumbered. The individual IP addresses are:

  • R1 LAN interface: 10.0.1.1/24
  • R1 Serial interface: Unnumbered, using the LAN interface's IP
  • R2 LAN interface: 10.0.2.1/24
  • R2 Serial interface: Unnumbered, using the LAN interface's IP

Assuming that the RIPv1 is configured on both routers, each router advertises two networks in its update to the neighbor: the local LAN and the automatic summary 10.0.0.0, which should not have been advertised at all as the entire addressing is inside the major network 10.0.0.0/8. The routing table on R2, for instance, will contain networks 10.0.0.0/24 and 10.0.1.0/24 discovered by RIPv1. The issue with RIPv1 in this case is thus twofold: the automatic summary should not have been originated at all in the first place, and even if it was correct to originate it, then the individual component routes of that summary should not have been advertised.

Assuming that the RIPv2 with automatic summarization is configured on both routers, each router will advertise only the summarized network 10.0.0.0/8 to its neighbor. Again, the automatic summary should no have been originated at all.

The workaround is to turn off the automatic summarization.

This issue was reproducible on various IOS platforms and was last tested on 12.4(12) Advanced IP
Services for 2691 series routers.

Issue 5 - Network with netmask shorter that the natural (classful) mask can not be included into RIPv2 using the network command

Assuming that an interface on a router is configured with IP address 192.168.0.1/23, it is not possible to advertise this network in RIPv2 using the network command. The only way to advertise network with shorter-than-classful netmask is to perform redistribution. This limitation does not exist in any other classless routing protocol. 

Issue 6 - Manual summarization in RIPv2 can not be performed to a supernet level, nor can more summaries within the same major network be configured on the same interface

It is not possible in RIPv2 to configure manual summarization that uses shorter-than-classful mask in the summary route (supernetting). Also, it is not possible to configure two or more summaries that belong to the same major network on the same network interface. This limitation does not exist in any other classless routing protocol.

 

Issue 7 - RIPv2 does not install discard routes in the routing table when performing summarization

The RIPv2 does not install any discard route automatically in the routing table when performing automatic or manual summarization. In contrast, every other classless routing protocol makes use of the discard route. This limitation does not exist in any other classless routing protocol.

Considering issues 5, 6 and 7, the described limitations are not a property of the RIPv2 protocol itself, rather they are purely counterintuitive and unnecessary limitations of the IOS implementation. Considering the impresence of these limitations in every other classless routing protocol, it is hardly conceivable why the existing and working code was not reused to enhance the RIPv2 in these aspects as well.