Problem: IGRP Routes Not in the Routing Table

For a router to send the packets to a particular destination, the router must have a routing entry for that destination subnet in the routing table. If there are no entries in the routing table, the packet will be dropped.

Example 5-1 shows that the routing table entry of R2 does not produce any IGRP routes for a particular destination of 131.108.2.0.

Example 5-1 R2 Routing Table Shows No IGRP Route for 131.108.2.0

 R2#  show ip route 131.108.2.0   % Subnet not in table  R2# 

The most common possible causes of this problem are as follows :

• network statement is missing or incorrect.

• Layer 2 is down.

• The distribute list is blocking the route.

• The access list is blocking the IGRP source address.

• The access list is blocking the IGRP broadcast.

• This is a discontiguous network.

• The source is invalid.

• A Layer 2 problem (switch, Frame Relay, or other Layer 2 medium) has occurred.

• A sender AS mismatch has occurred.

• A sender's problem has occurred (discussed in the "Troubleshooting IGRP Routes Advertisement" section).

Figure 5-1 shows the setup in which Router 1 and Router 2 are running IGRP in between.

Figure 5-1. Example Topology for the "IGRP Routes Not in the Routing Table" Problem

IGRP Routes Not in the Routing Table ‚ Cause: Missing or Incorrect network Statement

Several reasons exist for IGRP routes not being in the routing table. The one discussed here is a missing or incorrect network statement in the router's configuration. Other causes are mentioned at the beginning of this section. Just glancing through the flowchart might tell you the cause that fits your problem the most.

In the case of a wrong or missing network statement, IGRP will not be capable of receiving any updates on a particular interface. Recall from Chapter 3 that a network statement has two purposes:

• To enable IGRP on the interface for sending and receiving IGRP routes

• To advertise that network in IGRP updates

Figure 5-2 shows the flowchart to follow to solve this problem.

Figure 5-2. Problem-Resolution Flowchart

Debugs and Verification

Example 5-2 shows the configuration for Router R2. Please note that the loopback interface is used in this example and many other examples throughout this chapter. If the loopback interface is replaced with any other interface, it will not change the meaning. You should treat the loopback as any interface that is up and functional and that has a valid IP address.

Example 5-2 R2 Configuration

  interface Loopback0   ip address 131.108.3.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router IGRP 1    network 131.107.0.0   

The network 131.108.0.0 statement is missing from R2's configuration.

Example 5-3 shows the output of the show ip protocols command, which indicates that the routing information source also is not displaying 131.108.1.1 as a gateway. A gateway is a next -hop address from which routing updates are received. If there is no entry under the gateway, either nothing is being received or nothing is being installed from that neighbor.

Example 5-3 show ip protocols Command Output on R2

 R2#  show ip protocol  Routing Protocol is "IGRP 1"   Sending updates every 30 seconds, next due in 82 seconds   Invalid after 270 seconds, hold down 280, flushed after 630   Outgoing update filter list for all interfaces is   Incoming update filter list for all interfaces is   Default networks flagged in outgoing updates   Default networks accepted from incoming updates   IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0   IGRP maximum hopcount 100   IGRP maximum metric variance 1   Redistributing: igrp 1   Routing for Networks:     131.107.0.0   Routing Information Sources:     Gateway         Distance      Last Update   Distance: (default is 100) 

Example 5-4 shows the debug ip packet 100 detail output. In this debug, R2 is receiving the IGRP packets but is ignoring them because IGRP is not enabled on E0 interface. Note that protocol 9 is reserved for IGRP. This is because no network statement for 131.108.0.0 exists under router igrp 1.

Example 5-4 debug ip packet 100 detail Command Output on R2

 R2#  debug ip packet 100 detail   IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 32, rcvd 2, proto=9  R2#  show debug  Generic IP:   IP packet debugging is on (detailed) for access list 100 IP routing:   IGRP protocol debugging is on   IGRP event debugging is on R2#  show access-list 100  Extended IP access list 100     permit ip any host 255.255.255.255 (3 matches) 

Solution

When configured, the network statement does two things:

• Enables IGRP on the interface to send and receive IGRP updates

• Advertises that network in IGRP update packets

Because the network statement is missing on Router 2, the router ignores IGRP updates arriving on the Ethernet0 interface, as seen in the debug output. This problem also can happen if you incorrectly configure the network statement. For example, instead of con-figuring 209.1.1.0, you configure 209.1.0.0 assuming that 0 will cover anything in the third octet. IGRP is a classful protocol and assumes that the network statements are classful as well. If a classless statement is configured instead, IGRP will not function properly.

To correct this problem, you must add a properly configured network statement in the configuration.

Example 5-5 shows the new configuration for Router R2 that solves this problem.

Example 5-5 Adding a network Statement to R2 to Populate the Routing Table with IGRP Routes

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1   no network 131.107.0.0    network 131.108.0.0   

Example 5-6 shows the output of show ip protocols on R2, which displays the gateway information after inserting the proper network statement.

Example 5-6 show ip protocols Command Output on R2 After Corrected network Statement

 R2#  show ip protocols  Routing Protocol is "IGRP 1"   Sending updates every 30 seconds, next due in 82 seconds   Invalid after 270 seconds, hold down 280, flushed after 630   Outgoing update filter list for all interfaces is   Incoming update filter list for all interfaces is   Default networks flagged in outgoing updates   Default networks accepted from incoming updates   IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0   IGRP maximum hopcount 100   IGRP maximum metric variance 1   Redistributing: igrp 1   Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update  131.108.1.1          100      00:00:09  Distance: (default is 100) 

Example 5-7 shows the output of show ip route, which shows that Router R2 is learning the IGRP route after the configuration change.

Example 5-7 show ip route Command Output Confirms That R2 Is Learning the IGRP Route

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Layer 1/2 Is Down

One of the causes for routes not being installed in the routing table is that Layer 1 or Layer 2 is down. If this is the case, it is not a RIP problem. Layer 1 or 2 could be down for several reasons. The following is the list of most common thing to check if an interface or line protocol is down:

• Unplugged cable

• Loose cable

• Bad cable

• Bad transceiver

• Bad port

• Bad interface card

• Layer 2 problem at the telco in case of a WAN link

• Missing clock statement in case of back-to-back serial connection

Figure 5-3 shows the flowchart to follow to solve this problem.

Figure 5-3. Problem Resolution Flowchart

Debugs and Verification

The output in Example 5-8 indicates that the Ethernet interface's line protocol is down, which is a sign that there is something wrong at Layer 2.

Example 5-8 show interfaces Command Output Reveals That the Line Protocol Is Down

 R2#  show interfaces ethernet 0  Ethernet0 is up,  line protocol is down  Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)   Internet address is 131.108.1.2/24 

Example 5-9 shows the output of debug ip igrp events and debug ip igrp transaction. The output shows that R2 is not sending or receiving any IGRP updates because Layer 2 is down.

Example 5-9 debug ip igrp events and debug ip igrp transaction Command Output Reveals That R2 Is Not Sending or Receiving IGRP Updates

 R2#  debug ip igrp events  IGRP event debugging is on R2#  debug ip igrp transaction  IGRP protocol debugging is on R2#  show debug  IP routing:   IGRP protocol debugging is on   IGRP event debugging is on 

Solution

IGRP runs above Layer 2. IGRP cannot send or receive any routes if Layer 2 is down.

To correct this problem, you must fix the Layer 2 problem. The problem could be as simple as loose cables, or it could be as complex as bad hardware, in which case the hardware must be replaced.

Example 5-10 shows the output of show interfaces ethernet 0 after fixing the Layer 2 problem.

Example 5-10 show interfaces ethernet 0 Command Output After Restoring Layer 2 Connectivity

 R2#  show interfaces ethernet 0  Ethernet0 is up,  line protocol is up  Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)   Internet address is 131.108.1.2/24 

Example 5-11 shows the output of show ip protocols, which also shows that the problem is fixed.

Example 5-11 show ip protocols Command Output Verifies That the Gateway Is Restored After Fixing Layer 2 Connectivity

 R2#  show ip protocols  Routing Protocol is "IGRP 1"   Sending updates every 30 seconds, next due in 82 seconds   Invalid after 270 seconds, hold down 280, flushed after 630   Outgoing update filter list for all interfaces is   Incoming update filter list for all interfaces is   Default networks flagged in outgoing updates   Default networks accepted from incoming updates   IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0   IGRP maximum hopcount 100   IGRP maximum metric variance 1   Redistributing: igrp 1   Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update  131.108.1.1          100      00:00:09  Distance: (default is 100) 

Example 5-12 shows the output of show ip route, which shows that the IGRP route is being learned.

Example 5-12 show ip route Command Output Verifies That the IGRP Route Is Being Learned

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: distribute-list in Is Blocking the Route

A distribute list is a filtering mechanism for routing updates. A distribute list calls an access list and checks which networks are supposed to be permitted. If the access list does not contain any network, it will be automatically denied . A distribute list can be applied on incoming routing updates or outgoing routing updates.

In this example, distribute-list in is configured, but because the access list does not contain the permit statement for 131.108.0.0, R2 is not installing this route in the routing table.

Figure 5-4 shows the flowchart to follow to solve this problem.

Figure 5-4. Problem-Resolution Flowchart

Debugs and Verification

Example 5-13 shows the current configuration of Router R2. In the access list configuration, the network 131.108.0.0 is not explicitly permitted (and, therefore, is denied), so the router is not installing any subnets of the 131.108.0.0 network.

Example 5-13 R2 Access List Configuration Does Not Permit Routes from the 131.108.0.0 Network

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1   network 131.108.0.0    distribute-list 1 in    !    access-list 1 permit 131.107.0.0 0.0.255.255   

Solution

When using a distribute list, you should always double-check your access list to make sure that the networks that are supposed to be permitted actually are permitted in the access list definition. In Example 5-13, the access list is permitting only routes from 131.107.0.0. All other routes are denied by the implicit deny at the end of each access list. To fix this prob-lem, explicitly permit 131.108.0.0 in access-list 1.

Example 5-14 shows the new configuration of Router R2 with the correct access list.

Example 5-14 Reconfiguring access-list 1 to Permit Routes from Network 131.108.0.0

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1   network 131.108.0.0    distribute-list 1 in    !   no access-list 1 permit 131.107.0.0 0.0.255.255    access-list 1 permit 131.108.0.0 0.0.255.255   

Example 5-5 shows that Router R2 is learning IGRP routes after the configuration change.

Example 5-15 show ip route Command Output Reveals That the Change to access-list 1 Was Successful

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24  Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks: 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Access List Blocking IGRP Source Address

Access lists are used to filter the traffic based on the source address. Extended access lists are used to filter the traffic based on source or destination address. These access lists can be applied on the interface with the interface-level command ip access- group { access-list number } { in out } to filter the incoming and outgoing traffic.

When the access list is applied in an IGRP environment, always make sure that it does not block the source address of the IGRP update. In this example, R2 is not installing IGRP routes in the routing table because access-list 1 is not permitting the source address of IGRP updates from R1.

Figure 5-5 shows the flowchart to follow to solve this problem.

Figure 5-5. Problem-Resolution Flowchart

Debugs and Verification

Example 5-16 shows the current configuration of Router R2. The source address of 131.108.1.1 is not being permitted in the access list. Because the only permit statement in the access list is 131.107.0.0, the source address of RIP, 131.108.0.0, will be implicitly denied.

Example 5-16 Current Configuration of Router R2

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 1 in    !   router igrp 1   network 131.108.0.0   !    access-list 1 permit 131.107.0.0 0.0.255.255   

Example 5-17 shows the output of debug ip igrp events and debug ip igrp transaction. In this debug, IGRP is only sending the updates and is not receiving anything because the source address, 131.108.1.1, is not permitted in the input access list of R2. This is also shown in the debug ip packet 100 detail output, where access-list 100 specifically looks at the source address of 131.108.1.1

Example 5-17 debug Command Output Showing That IGRP Updates Are Sent and Not Received

 R2#  debug ip packet 100 detail  IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 46,  access denied  , proto=9 R2# R2#  show debug  Generic IP:   IP packet debugging is on (detailed) for access list 100 IP routing:   IGRP protocol debugging is on   IGRP event debugging is on IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.2)       subnet 131.108.3.0, metric=501 IGRP: Update contains 1 interior, 0 system, and 0 exterior routes. IGRP: Total routes in update: 1  R2#    show access-list 100    Extended IP access list 100   permit ip host 131.108.1.1 host 255.255.255.255  R2# 

Solution

The standard access list specifies the source address. In this case, the source address is 131.108.1.1. This source address is not permitted in the standard access list, so IGRP routes will not get installed in the routing table of R2. To solve this problem, permit the source address in access-list 1.

Example 5-18 shows the necessary configuration changes to fix this problem.

Example 5-18 Fixing the Access List to Permit the IGRP Update Source Address

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   ip access-group 1 in   !   router igrp 1    network 131.108.0.0    !   no access-list 1 permit 131.107.0.0 0.0.255.255    access-list 1 permit 131.108.1.1   

Example 5-19 shows the configurations in case of an extended access list.

This problem also can happen when using extended access lists and when the IGRP source address is not permitted in the access list. This solution also can be used in case of extended access list. The idea here is to permit the source address of the IGRP update.

Example 5-19 Fixing the Extended Access List to Permit the IGRP Update Source Address

  access-list 100 permit ip 131.107.0.0 0.0.255.255 any   access-list 100 permit ip host 131.108.1.1 any  

After changing the access list, standard or extended, and permitting the source address of the neighbor that is sending the IGRP routing updates, R2 will start accepting and installing the IGRP updates.

Example 5-20 shows the routing table entry of Router R2, which shows that it is learning IGRP routes after the configuration change of the access list.

Example 5-20 R2's Routing Table Verifies That R2 Receives IGRP Routes After Fixing the Access Lists

  R2#    show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Access List Blocking IGRP Broadcast

Access lists are used for the filtering purpose. When used on the inbound interface, always make sure that it is not blocking IGRP broadcast, which is used for IGRP routing updates. If this broadcast address is not permitted in the access list that is applied on the interface inbound, IGRP will not install any routes in the routing table learned on that interface.

Figure 5-6 shows the flowchart to follow to solve this problem.

Figure 5-6. Problem-Resolution Flowchart

Debugs and Verification

Example 5-21 shows the current configuration of R2. In this configuration, the IGRP des-tination address of 255.255.255.255 is not being permitted; as a result, no IGRP routes are being installed in R2. The access-group 100 in command is configured under the Ethernet 0 interface of R2. This filter actually is calling access-list 100. If you look at access-list 100, it is actually denying the incoming broadcast access on Ethernet 0 inter- face because there is an implicit deny at the end of each access list. This blocks the IGRP updates, and R2 will not install any IGRP routes.

Example 5-21 R2's Configuration Does Not Permit the IGRP Broadcast Address of 255.255.255.255

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 100 in    !   router igrp 1   network 131.108.0.0   !    access-list 100 permit ip 131.107.0.0 0.0.255.255 any     access-list 100 permit ip host 131.108.1.1 host 131.108.1.2   

Solution

IGRP broadcasts its routing updates on 255.255.255.255. This address must be permitted in the input access list of the receiving router.

Example 5-22 shows the new configuration for Router R2.

Example 5-22 Reconfiguring Router R2 to Permit the IGRP Broadcast Address

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 1 in    !   router igrp 1   network 131.108.0.0   !   access-list 100 permit ip 131.107.0.0 0.0.255.255 any   access-list 100 permit ip host 131.108.1.1 host 131.108.1.2    access-list 100 permit ip host 131.108.1.1 host 255.255.255.255   

Example 5-23 shows the routing table entry of R2 after correcting the problem.

Example 5-23 R2's Routing Table Shows That the IGRP Broadcast Address Is Now Permitted

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24  Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Discontiguous Network

The definition of a discontiguous network is one in which two subnets belonging to the same major network are separated by a network or a subnetwork belonging to another major network. Chapter 4, "Understanding Interior Gateway Routing Protocol (IGRP)," provides a detailed description of why discontiguous networks are not supported in IGRP.

Figure 5-7 shows an example of a discontiguous network in which 137.99.0.0 is a major network. The subnets of this major network are separated by another major network, 131.108.0.0. This situation produces a discontiguous network problem.

Figure 5-7. Sample Discontiguous Network

Figure 5-8 shows the flowchart to follow to solve this problem.

Figure 5-8. Problem-Resolution Flowchart

Debugs and Verification

Example 5-24 shows the configuration of Routers R1 and R2. IGRP is enabled on the Ethernet interfaces of R1 and R2 with the correct network statements.

Example 5-24 R1 and R2 Configurations Indicate That IGRP Is Enabled on the Ethernet Interfaces

 R2#  interface Loopback0   ip address 137.99.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1    network 131.108.0.0     network 137.99.0.0    !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 137.99.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router igrp 1    network 131.108.0.0     network 137.99.0.0    !  

Example 5-25 shows the debug ip igrp transaction output for Routers R1 and R2. Both debugs show that the network 137.99.0.0 is being sent across.

Example 5-25 debug ip igrp transaction Command Output for R1 and R2 Indicates That Updates for Network 137.99.0.0 Are Being Sent

 R2#  debug ip igrp transaction  IGRP protocol debugging is on R2# IGRP: sending update to 255.255.255.255 via Loopback0 (137.99.3.2)       network 131.108.0.0, metric=8476  IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.2)   network 137.99.0.0, metric=501   IGRP: received update from 131.108.1.1 on Ethernet0   network 137.99.0.0, metric 8976 (neighbor 501)  R2# _____________________________________________________________________________________ R1#  debug ip igrp transaction  IGRP protocol debugging is on R1# IGRP: sending update to 255.255.255.255 via Loopback0 (137.99.2.1)       network 131.108.0.0, metric=8476  IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.1)   network 137.99.0.0, metric=501  R1#  IGRP: received update from 131.108.1.2 on Ethernet0   network 137.99.0.0, metric 8976 (neighbor 501)  R1# 

Solution

IGRP is not installing the route 137.99.0.0 in the routing table because IGRP does not support discontiguous networks. As discussed in Chapter 4, there are several solutions to this problem. The quick solution is to configure a static route to the more specific subnets of 137.99.0.0 on each router. This provides each router the routes about the specific subnets of a discontiguous majornet. Other solutions are as follows:

• Change the address on the link between R1 and R2 to be a part of 137.99.0.0. In other words, assign another subnet on this link, which is a part of 137.99.0.0.

• If the address cannot be changed, run a GRE tunnel between R1 and R2, and put a separate subnet address with the same mask on the tunnel interface, as demonstrated:

• Replace IGRP with any other IP routing protocol that supports discontiguous networks ‚ for example OSPF, ISIS, EIGRP, RIP-2, and so on.

 R1#  interface tunnel 0   ip address 137.99.1.1 255.255.255.0   tunnel source Ethernet 0   tunnel destination 131.108.1.2  _____________________________________________________________________________________ R2#  interface tunnel 0   ip address 137.99.1.2 255.255.255.0   tunnel source Ethernet 0   tunnel destination 131.108.1.1  

Discontiguous subnets are discouraged and should be avoided even if a protocol supports it. They destroy the summarization capabilities.

Example 5-26 shows the configuration change that is required for both Routers R1 and R2 to fix the problem. In the configurations, a static route has been added for the discontiguous subnets.

Example 5-26 Adding a Static Route as a Solution for Discontiguous Subnets

 R1#  interface Loopback0   ip address 137.99.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router igrp 1   network 131.108.0.0   network 137.99.0.0   !    ip route 137.99.3.0 255.255.255.0 131.108.1.2   _____________________________________________________________________________________ R2#  interface Loopback0   ip address 137.99.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1   network 131.108.0.0   network 137.99.0.0   !    ip route 137.99.2.0 255.255.255.0 131.108.1.1   

Example 5-27 shows the routing table entry of R2 after fixing this problem.

Example 5-27 Verifying That the IGRP Routing Update Problem Caused by Discontiguous Networks Has Been Resolved

  R2#  show ip route 137.99.2.0    Routing entry for 137.99.2.0/24  Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Invalid Source

When RIP tells the routing table to install the route, it performs a source validity check. This check makes sure that the source where the update is coming from is also on the same subnet of the local receiving interface. If the source is not on the same subnet as the local interface, RIP ignores the update and will not install routes in the routing table coming from this source address.

Figure 5-9 shows the network diagram for the invalid source problem.

Figure 5-9. Network with an Invalid Source

As Figure 5-9 illustrates, Router 1's Serial0 interface is unnumbered to Loopback0. Router 2's serial interface is numbered. When Router 2 receives an IGRP update from Router 1, it complains about the source validity.

Figure 5-10 shows the flowchart to follow to solve this problem.

Figure 5-10. Problem-Resolution Flowchart

Debugs and Verification

Example 5-28 shows the configuration of both Routers R2 and R1, where R1's Serial0 interface is unnumbered to Loopback0 and R2's Serial0 interface is numbered.

Example 5-28 R1/R2 Configuration with Mismatched Numbered/Unnumbered Serial Interfaces

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0    ip address 131.108.1.2 255.255.255.0    !   router igrp 1   network 131.108.0.0   !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Serial0    ip unnumbered Loopback0    !   router igrp 1   network 131.108.0.0   !  

Example 5-29 shows the debug ip igrp transaction output, which reveals that R2 is ignoring IGRP updates from R1 because of the source validity check failure.

Example 5-29 debug ip igrp transaction Command Output Reveals That R2 Is Ignoring IGRP Update from R1

 R2#  debug ip igrp transaction  IGRP protocol debugging is on  IGRP: received update from invalid source 131.108.2.1 on Serial0  R2# 

Solution

When IGRP tells the routing table to install the route, it performs a source validity check. If the source is not on the same subnet on which it received the update, it ignores the update. In cases when one side is numbered and the other side is unnumbered, this check must be turned off. This is usually the case in dial backup situations in which remote routers dial into an access router. The access router's dialup interface is unnumbered, and all remote routers get an IP address assigned on their dialup interfaces.

Example 5-30 shows the new configuration change on Router R2 to fix this problem.

Example 5-30 Disabling the Source Validity Check on R2

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0   ip address 131.108.1.2 255.255.255.0   !   router igrp 1    no validate-update-source    network 131.108.0.0   !  

Example 5-31 shows that after changing the configurations of R2, the route gets installed in the routing table.

Example 5-31 show ip route Command Output Verifies That R2 Is Now Receiving the IGRP Update from R1's Unnumbered Interface

  R2#  show ip route 131.108.2.0    Routing entry for 131.108.2.0/24  Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Serial0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Layer 2 Problem (Switch, Frame Relay, Other Layer 2 Media)

Sometimes, broadcast capability is broken at Layer 2, which further affects Layer 3 broadcast, and IGRP fails to work properly. The Layer 3 broadcast is further converted into a Layer 2 broadcast. If Layer 2 has problems in handling Layer 2 broadcasts, the IGRP updates will not be propagated across. The debug shows that the broadcast is being originated at one end but is not getting across.

Figure 5-11 shows the network diagram for a Frame Relay problem while running IGRP.

Figure 5-11. Two Routers Running IGRP in a Frame Relay Network

In Figure 5-11, Router 1 and Router 2 are connected by Frame Relay. (Although, this could be any Layer 2 medium ‚ X.25, Ethernet, FDDI, and so forth.)

Figure 5-12 shows the flowchart to follow to solve this problem.

Figure 5-12. Problem-Resolution Flowchart

Debugs and Verification

Example 5-32 shows the output of debug ip packet detail 100, which verifies that R1 is sending and receiving IGRP updates without any problem. On R2, updates are being sent but are not received. This means that the IGRP update is being lost at Layer 2.

Example 5-32 debug ip packet detail 100 Command Output Shows That R1 Is Successfully Sending IGRP Updates

 R1#  show access-list 100  access-list 100 permit ip any host 255.255.255.255 R1#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R1#  IP: s=131.108.1.1 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9   IP: s=131.108.1.2 (Ethernet), d=255.255.255.255, len 46, rcvd 2, proto=9  _____________________________________________________________________________________ R2#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R2#  IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9   IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9  

Solution

IGRP sends updates on a broadcast address of 255.255.255.255. If this address gets blocked at Layer 2, IGRP will not function properly. The root of the Layer 2 problem could result from a simple Ethernet switch, Frame Relay cloud, bridging cloud, and so on. Fixing the Layer 2 problem is beyond the scope of this book. We will leave this up to you, but here are some tips:

• In cases of Frame Relay

  - Check for the broadcast keyword missing in the frame-relay map statement.

  - Call your telco and make sure that it is propagating broadcast traffic across.

• In cases of a bridging cloud

  - Make sure that any bridge in the middle is not dropping the broadcast packets.

  - If the middle medium is Token Ring to Ethernet, make sure that the translational bridging is working properly.

Example 5-33 shows that after fixing the Layer 2 problem, IGRP routes get installed in the routing table.

Example 5-33 Verifying IGRP Routes Show Up in the Routing Table After Resolving the Layer 2 Problem

  R2#  show ip route 131.108.2.0    Routing entry for 131.108.2.0/24  Known via "igrp 1", distance 100, metric 8976   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0 

IGRP Routes Not in the Routing Table ‚ Cause: Sender's AS Mismatch

IGRP updates carry the AS number. When a receiver receives an IGRP update and the AS number of the sender does not match with its own AS number, IGRP ignores that update. As a result, no IGRP routes are installed in the routing table. Multiple IGRP processes can be run under different AS numbers . These processes are independent of each other.

Figure 5-13 shows the flowchart to follow to solve this problem.

Figure 5-13. Problem-Resolution Flowchart

Debugs and Verification

Example 5-34 shows the configuration of both R1 and R2. R1 is running IGRP AS 1, and R2 is running IGRP AS 2.

Example 5-34 R1 and R2 Configurations Show That They Are in Different Autonomous Systems

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0   ip address 131.108.1.2 255.255.255.0   !    router igrp 2    network 131.108.0.0   !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Serial0   ip address 131.108.1.1 255.255.255.0   !    router igrp 1    network 131.108.0.0   !  

Example 5-35 shows the output of debug ip igrp transaction and debug ip packet 100 detail on R1 and R2. Both routers are sending the IGRP update, but the update never reaches the other side. Both routers show that the IGRP packets are being received, but IGRP is ignoring these updates because of the AS number mismatch. Unfortunately, the debug does not show the mismatch message; however, it does show that IGRP is not displaying the update received message in the debugs.

Example 5-35 debug ip igrp transaction Command Output on R1 and R2 Reveals the Status of IGRP Updates

 R1#  show debug  Generic IP:   IP packet debugging is on (detailed) IP routing:  IGRP protocol debugging is on   IGRP event debugging is on  R1# R1#  show access-list 100  access-list 100 permit ip any host 255.255.255.255 R1#  debug ip packet 100 detail   IP packet debugging is on (detailed) for access list 100  R1# R1#  debug ip igrp transaction  IGRP protocol debugging is on IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.1)       subnet 131.108.3.0, metric=501 IP: s=131.108.1.2 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9 _____________________________________________________________________________________ R2#  debug ip packet 100 detail   IP packet debugging is on (detailed) for access list 100  R2# R2#  debug ip igrp transaction  IGRP protocol debugging is on IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.2)       subnet 131.108.2.0, metric=501 IP: s=131.108.1.1 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9 

Solution

In this example, the sender is sending AS 1 in the update. When R2 receives it, it ignores this update because R2 is running IGRP under AS 2.

To fix this problem, change the IGRP configurations so that R1 and R2 both agree on one AS number.

Example 5-36 shows the new configuration on R2 that fixes this problem.

Example 5-36 Configuring R2 to Have the Same AS Number as R1

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0   ip address 131.108.1.2 255.255.255.0   !    no router igrp 2     !     router igrp 1    network 131.108.0.0   !  

Example 5-37 shows that after fixing the AS problem, IGRP routes get installed in the routing table.

Example 5-37 show ip route Command Output Reveals That the AS Problem Preventing IGRP Route Installation Is Resolved

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "igrp 1", distance 100, metric 8976  Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 131.108.1.1 on Serial0, 00:00:12 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0       Route metric is 8976, traffic share count is 1       Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 0