Why Doesn't RIP or IGRP Support Discontiguous Networks?

Introduction

A discontiguous network comprises a major net that separates another major net. In Figure 1, a subnet of network 172.20.0.0 separates network 172.16.0.0. 172.16.0.0 is a discontiguous network. This document describes why RIPv1 and IGRP do not support discontiguous networks and explains how you can work around this issue.

Figure 1 – Discontiguous Network

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• How to Configure RIPv1 and IGRP

• Concepts that underlie IP Addresses and Subnets

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

RIP and IGRP are classful protocols. Whenever RIP advertises a network across a different major net boundary, RIP summarizes the advertised network at the major net boundary. In Figure 1, when Router 1 sends an update that contains 172.16.5.0 to Router 2 across 172.20.88.0, the router converts 172.16.5.0/24 into 172.16.0.0/16. This process is called auto-summarization.

When Router 1 Sends Updates to Router 2

Use the topology in Figure 1 to identify what questions you need answer when Router 1 prepares to send an update to Router 2. Refer to Behavior of RIP and IGRP When Sending and Receiving Updates for more detailed information about this decision-making. Remember that the advertisement of network 131.108.5.0/24 is of interest here. Here is the question you need to answer:

• Is 172.16.5.0/24 part of the same major network as 172.20.88.0/24, which is the network assigned to the interface that sources the update?

  • No: Router 1 summarizes 172.16.5.0/24 and advertises the route 172.16.0.0/16. The summarization is done to the major classful boundary. In this case, the address is a class B address, and so, the summary is 16 bits.

  • Yes: Although this is not the case in the example, if the answer to the question is yes, Router 1 would not summarize the network and would advertise the network with subnet information intact.

Use the debug ip rip command on Router 1 to see the update that Router 1 sends:

RIP: sending v1 update to 255.255.255.255 via Serial3/0 (172.20.88.2)
RIP: build update entries
  network 172.16.0.0 metric 1

Router 2 Receives Updates from Router 1

When Router 2 prepares to receive and update from Router 1, you need to identify the questions that need to be answered. Again, remember that the reception of network 172.16.5.0/24 is of interest here. However, remember that when Router 1 sent the update the network was summarized to 172.16.0.0/16. Here is the question you need to answer:

• Is the network that receives updates (172.16.0.0/16) part of the same major network of 172.20.88.0, which is the address assigned to the interface that received the update?

  • No: Do any subnets of this major network already exist in the routing table known from interfaces other than that which received the update?

  • Yes: Ignore the update.

Again, use the debug ip rip command on Router 2 to see the updates that came in from Router 1:

RIP: received v1 update from 172.20.88.2 on Serial2/0
     172.16.0.0 in 1 hops

However, the routing table of Router 2 indicates that the update was ignored. The only entry for any subnetwork or network on 172.16.0.0 is the one directly connected to Ethernet0. The output of the show ip route command on Router 2 shows:

172.20.0.0/24 is subnetted, 1 subnets
C       172.20.88.0 is directly connected, Serial2/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.2.0 is directly connected, Ethernet0/0

The behavior of RIPv1 and IGRP is such that when Router 1 and Router 2 exchange updates, both Router 1 and Router 2 do not learn about the attached subnetworks of 172.16.5.0/24 and 172.16.2.0/24. As a result, devices on these two subnetworks are unable to communicate with each other.

Solution

In some situations, discontiguous networks are unavoidable. In these situations Cisco recommends that you do not use RIPv1 or IGRP. Routing protocols like EIGRP or OSPF are better suited for this situation.

Establish Connectivity

In the event that you use RIPv1 or IGRP with discontiguous networks, you must use static routes to establish connectivity between the discontiguous subnetworks. In this example these static routes establish this connectivity:

For Router 1:

ip route 172.16.2.0 255.255.255.0 172.20.88.1

For Router 2:

ip route 172.16.5.0 255.255.255.0 172.20.88.2

Related Information

• IP Routed Protocols Support Page
• IP Routing Support Page
• IGRP Support Page
• RIP Support Page
• Technical Support & Documentation - Cisco Systems