Problem: Sender Is Not Advertising IGRP Routes

Typically, an IP network running IGRP has routers that have a consistent view of the routing table. In other words, all routers have routing tables that contain reachability information for all the IP subnets of the network. This might differ when filtering of certain subnets is done at some routers and not at others. Ideally, all IGRP routers are aware of all routes of the complete network.

When the routing information differs from one router to the other, one of two possibilities could exist:

• Some router(s) is not advertising the IGRP routes.

• Some router(s) is not receiving the IGRP routes.

This section deals with a router not advertising IGRP routes.

Figure 5-16 provides a network scenario that will be used as the basis for troubleshooting a majority of the following causes of the "sender is not advertising IGRP routes" problem:

• network statement is missing or incorrect.

• The outgoing interface is down.

• distribute-list out is blocking the routes.

• The advertised network interface is down.

• The outgoing interface is defined as passive.

• Broadcast capability has been broken (encapsulation failure in Frame Relay).

• neighbor statement is misconfigured.

• The advertised subnet is VLSM.

• Split horizon is enabled.

Figure 5-16. Network Setup to Illustrate IGRP Routes Not Being Advertised

In Figure 5-16, Router 1 (the sender) is not advertising routes to Router 2. If a network statement is missing from Router 1's configurations, it will not advertise any IGRP routes.

Sender Is Not Advertising IGRP Routes ‚ Cause: Missing or Incorrect network Statement

One of the requirements for enabling IGRP on a router's interface is to mention the network statement under the router igrp command. The network statement decides which interface upon which IGRP should be enabled. If the network statement is misconfigured or is not configured, IGRP will not be enabled on that interface and IGRP routes will not be advertised out on that interface.

Figure 5-17 shows the flowchart to follow to fix this problem.

Figure 5-17. Problem-Resolution Flowchart

Debugs and Verification

Example 5-42 shows the current configuration for R1.

Example 5-42 Current Configuration for R1 in Figure 5-16

 R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router igrp 1    network 131.107.0.0   

Solution

The network statement is incorrectly configured under router igrp 1. Instead of 131.108.0.0, 131.107.0.0 is configured. This will not enable IGRP on the interface, and no updates will be sent.

Sometimes, a classless network statement is configured under router IGRP, assuming that it will cover all the networks ‚ for example:

  router igrp 1   network 131.0.0.0  

This network statement will not cover 131.0.0.0 ‚ 131.255.255.255 because 131.0.0.0 is a classless network and IGRP is a classful routing protocol. Similarly, if you have multiple Class C addresses, you cannot use one Class C address to cover all the Class C addresses that you own, such as 200.1.1.0 ‚ 200.1.4.0. This does not mean you can do this:

  router igrp 1   network 200.1.0.0  

This network statement is meaningless for IGRP because IGRP is a classful protocol. The correct way to advertise all four networks in IGRP is this:

  router igrp 1   network 200.1.1.0   network 200.1.2.0   network 200.1.3.0   network 200.1.4.0  

Example 5-43 shows the correct configuration for R1.

Example 5-43 R1 Configuration with the Correct network Statement

 R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router igrp 1   no network 131.107.0.0    network 131.108.0.0   

Example 5-44 shows the routing table entry of Router R2, with the learned IGRP route.

Example 5-44 R1 Routing Table Shows That Routes Were Properly Advertised by R2 After Correcting the Configuration

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Outgoing Interface Is Down

IGRP is the routing protocol that runs on Layer 3. IGRP cannot send updates across the interface if the outgoing interface is down. A variety of possible causes exists for the outgoing interface being down:

• Interface is up, line protocol is down.

• Interface is down, line protocol is down.

• Interface is administratively down, line protocol is down.

If the outgoing interface shows any of these symptoms, IGRP will not be capable of sending any updates across. The main thing to note here is that in all of these possibilities, the line protocol will always appear to be down. This is the most important information in determining the Layer 2 connectivity.

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

Figure 5-18. Problem-Resolution Flowchart

Debugs and Verification

Example 5-45 verifies that the interface Ethernet 0 is down.

Example 5-45 show interface Command Output Reveals That the Interface Is Down

 R1#  show interface ethernet 0  Ethernet0 is up,  line protocol is down  Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)   Internet address is 131.108.1.1/24 

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 might be as simple as loose cables or a bad cable; in which case, the cable must be replaced. Alter-natively, the problem could be as complex as bad hardware; in which case, the hardware must be replaced . Some of the tips on resolving the Layer 2 issue already were addressed in the "Troubleshooting IGRP Route Installation" section, where the cause is Layer 1/2 abeing down.

Example 5-46 shows the interface Ethernet 0 after fixing the Layer 2 problem.

Example 5-46 Verifying That the Layer 2 Problem Has Been Resolved

 R1#  show interface ethernet 0  Ethernet0 is up,  line protocol is up  Hardware is Lance, address is 0000.0c70.d31e (bia 0000.0c70.d31e)   Internet address is 131.108.1.1/24 

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

Example 5-47 Verifying That R2 Is Receiving the Routes After Fixing 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 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: distribute-list out Is Blocking the Route

distribute-list out is used to filter any routes that are going to be sent out on an interface. If a receiver is complaining about a missing route that should have been received, make sure that it is not being filtered through distribute-list out. If it is, the associated access list must be modified.

Figure 5-19 shows the flowchart to follow to fix this problem.

Figure 5-19. Problem-Resolution Flowchart

Debugs and Verification

Example 5-48 shows the configuration of Router R1. In this configuration, the access list does not permit the 131.108.0.0 network, so R1 will not advertise any 131.108 network, including 131.108.2.0/24.

Example 5-48 Access List Configuration on R1 Does Not Permit the 131.108.0.0 Network

 R1#  interface Loopback0   ip address 131.108.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    distribute-list 1 out     !     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 explicitly permitted in the access list. The access list configuration in Example 5-48 is permitting only 131.107.0.0 and is denying everything else because there is an implicit deny at the end of each access list. To fix this problem, add a permit statement allowing 131.108.0.0 in access-list 1.

Example 5-49 shows the new configuration change on Router R1.

Example 5-49 Access List Configuration on R1 to Permit the 131.108.0.0 Network

 R1#  interface Loopback0   ip address 131.108.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    distribute-list 1 out    !   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-50 shows the routing table entry of Router R2 after fixing the problem.

Example 5-50 R2 Routing Table Verifies That R2 Receives IGRP Routes After Fixing the Access List in R2

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Advertised Network Interface Is Down

A situation could arise in which the network that is being advertised is down and the connected route has been removed from the routing table. In this situation, IGRP will start advertising that network with an infinite metric and after the hold-down timer expires , it will no longer advertise this network. As soon as the advertised network comes up, IGRP will start advertising it again in its updates.

Figure 5-20 shows the flowchart to follow to fix this problem.

Figure 5-20. Problem-Resolution Flowchart

Debugs and Verification

Example 5-51 shows that the line protocol of the advertised network interface is down, indicating that something is wrong at Layer 2. For tips on fixing Layer 1/2, refer to the "Troubleshooting IGRP Route Installation" section.

Example 5-51 show interface Command Output Reveals That the Advertised Network Interface Is Down

 R1#  show interface Ethernet 1  Ethernet1 is up,  line protocol is down  Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)   Internet address is 131.108.2.1/24 

Solution

When the advertised network's interface goes down, IGRP will detect that because Layer 2 notifies the upper layer that the interface or the subnet is down. IGRP will no longer adver-tise that network in the IGRP updates. As Example 5-52 shows, Ethernet 1 is down, so IGRP no longer advertise 131.108.2.0/24 in its update.

To correct this problem, you must fix the Layer 1/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. Refer back to the "Troubleshooting IGRP Route Installation" section for tips on fixing Layer 1/2 issues.

Example 5-52 shows that the advertised network interface is up after fixing the Layer 2 problem.

Example 5-52 Verifying That the Advertised Network Interface Is Up

 Ethernet1 is up,  line protocol is up  Hardware is Lance, address is 0000.0c70.d51e (bia 0000.0c70.d51e)   Internet address is 131.108.2.1/24 

Example 5-53 shows that the route that was down is back in the routing table of R2.

Example 5-53 R2 Routing Table Verifies That R2 Starts Receiving IGRP Routes After Fixing the Layer 1/2 Issue

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Outgoing Interface Is Defined as Passive

When an interface is defined as passive under IGRP, IGRP will receive updates on that interface but will not send any updates. The passive-interface command is used to avoid sending unnecessary updates to a neighbor that does not need to receive any IGRP updates, such as a small route that is at the edge. A simple default gateway is enough information for that router to talk to the outside world. Be sure to use the passive-interface command where needed; otherwise , undesired results might occur.

Figure 5-21 shows the flowchart to follow to fix this problem.

Figure 5-21. Problem-Resolution Flowchart

Debugs and Verification

Example 5-54 shows the output of show ip protocols, which shows that the outgoing interface is defined as passive.

Example 5-54 Verifying That the Outgoing Interface Is Passive

 R1#  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  Passive Interface(s):   Ethernet0  Routing Information Sources:     Gateway         Distance      Last Update     131.108.1.2          100      00:00:09   Distance: (default is 100) 

Example 5-55 shows the configuration of Router R1, which shows that the outgoing interface is defined as passive.

Example 5-55 R1 Configuration Shows a Passive Interface

 R1#  router igrp 1   passive-interface Ethernet 0   network 131.108.0.0  

Solution

Example 5-54 and 5-55 confirm that the interface Ethernet 0 is defined as passive, so R1 is not sending any updates on Ethernet 0. Sometimes, it is desirable for some networks to be advertised out and others to be filtered. In this situation, you should not use passive interfaces ‚ distribute-list out is a better solution.

Assuming that passive-interface was configured by mistake, take this command out of the configuration to solve this problem.

Example 5-56 shows the new configuration to solve this problem.

Example 5-56 Removing the Passive Interface

 R1#  router igrp 1   network 131.108.0.0   no passive-interface Ethernet 0  

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

Example 5-57 R2's Routing Table Verifies That Removal of the Passive Interface Fixed Routes Advertisement Problem on R1

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Broken Broadcast Capability (Encapsulation Failure in Layer 2)

When IGRP is running in a Frame Relay environment, Layer 2 must support broadcast; otherwise, IGRP updates will not get across. When using static mapping, be sure to add the broadcast keyword at the end of a map statement. This problem also can be seen with X.25, ISDN, and other Layer 2 media. Whenever there is a static mapping, the broadcast keyword must be included in the configuration.

Figure 5-22 shows the network setup that is used to produce a broken broadcast capability in Frame Relay.

Figure 5-22. Network Setup Incompatible with Frame Relay Broadcasting Without broadcast Keyword in map Statement

Figure 5-22 shows that Router 1 and Router 2 are connected by Frame Relay. Router 1 is not advertising IGRP routes toward Router 2.

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

Figure 5-23. Problem-Resolution Flowchart

Debugs and Verification

Example 5-58 shows the configuration of Router R1. In this configuration, the frame-relay map statement does not include the broadcast keyword.

Example 5-58 R1 Configuration Lacks the broadcast Keyword

 R1#  interface Serial3   ip address 131.108.1.1 255.255.255.0   no ip directed-broadcast   encapsulation frame-relay   no keepalive    frame-relay map ip 131.108.1.2 16    !  

Example 5-59 shows output from the debug ip packet command, which includes the broadcast traffic source from R1. The debug shows that there are encapsulation failures.

Example 5-59 debug ip packet Command Output Indicates Encapsulation Failures

 R1#  show access-list 100  Extended IP access list 100     permit ip host 131.108.1.1 host 255.255.255.255 (8 matches) 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 (Serial3), len 88, sending broad/         multicast, proto=9 IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 88,  encapsulation failed,   proto=9  

Solution

To solve this problem, add the broadcast keyword in the frame-relay map statement.

Example 5-60 shows the new configuration of Router R1 with the correct frame-relay map statement.

Example 5-60 Configuring R1 with the frame-relay map Statement, Including the broadcast Keyword

  interface Serial3   ip address 131.108.1.1 255.255.255.0   no ip directed-broadcast   encapsulation frame-relay   no keepalive   frame-relay map ip 131.108.1.2 16  broadcast  !  

Example 5-61 shows the routing table entry of R2 with IGRP routes.

Example 5-61 R2 Routing Table Verifies That R2 Is Receiving IGRP Routes After Broadcasting Is Enabled on R2's frame-relay map Statement

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Misconfigured neighbor Statement

In a nonbroadcast environment, IGRP provides a unicast method of sending IGRP updates. To send unicast IGRP updates, you must configure the neighbor statement carefully . If the neighbor address is misconfigured in the neighbor statement, IGRP will not send the uni-cast update to the wrong neighbor or a nonexistent neighbor.

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

Figure 5-24. Problem-Resolution Flowchart

Debugs and Verification

Example 5-62 shows the IGRP configuration for Router R1. The configuration shows that the neighbor statement is configured wrong. Instead of 131.108.1.2, as shown in Figure 5-22, the neighbor statement points to 131.108.1.3, which does not exist.

Example 5-62 Misconfigured neighbor Statement Preventing Unicast IGRP Updates

 R1#  router igrp 1   network 131.108.0.0    neighbor 131.108.1.3   

Solution

In Example 5-62, IGRP is sending a unicast update to 131.108.1.3, a bogus neighbor that does not exist.

To resolve this problem, you must properly configure the neighbor statement.

Example 5-63 shows the correct configuration of Router R1.

Example 5-63 Configuring R1 with the Proper neighbor Statement

 R1#  router igrp 1   network 131.108.0.0    no neighbor 131.108.1.3     neighbor 131.108.1.2   

Example 5-64 shows the IGRP routes installed in R2's routing table.

Example 5-64 R2's Routing Table Verifies That the neighbor Statement Has Been Properly Configured on R1, so R2 Starts Receiving IGRP Routes

 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Advertised Subnet Is VLSM

IGRP is not designed to carry subnet mask information; therefore, any subnet that is using a different mask other than the interface that will be sourcing the IGRP update will not be advertised by IGRP, which actually performs a check before sending an update. This check makes sure that the subnet that will be advertised by IGRP has the same subnet mask as the interface that will be sourcing the IGRP update. If the mask is different, IGRP actually drops the update and will not advertise it. Therefore, in IGRP, the subnet mask should be consistent; otherwise, it can cause this problem. This is also explained in detail in Chapter 4.

Figure 5-25 shows a network setup that produces problems because of VLSM. The figure shows that Router 1 has a VLSM subnet that is 131.108.2.0/25. This subnet will not go across toward Router 2.

Figure 5-25. Network Setup Conducive to Advertised Subnet Problems Because of VLSM

Figure 5-26 shows the flowchart to follow to fix this problem.

Figure 5-26. Problem-Resolution Flowchart

Debugs and Verification

Example 5-65 shows that the loopback interface of R1 is configured for a /25 subnet mask and also shows that the interface that will be sourcing the IGRP update has a /24 mask.

Example 5-65 R1's Loopback Interface Configured with a Subnet Mask Incompatible with the Interface Sourcing the IGRP Update

 R1#  interface Loopback0    ip address 131.108.2.1 255.255.255.128    !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router igrp 1   network 131.108.0.0  

Solution

To solve the problem, you need to either change the subnet mask so that it matches the interface that will be sourcing the IGRP update or change the protocol to EIGRP that does support VLSM. Changing the protocol to EIGRP means that every router in the network must be changed to EIGRP, so this is a long- term solution.

Example 5-66 shows the configuration changes that correct the problem.

Example 5-66 Correcting the Mismatched Subnet Mask Problem

 R1#  interface Loopback0    ip address 131.108.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  

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

Example 5-67 R2's Routing Table Verifies That the Mismatched Subnet Mask Problem Has Been 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 

Sender Is Not Advertising IGRP Routes ‚ Cause: Split Horizon Is Enabled

Split horizon is a feature in IGRP that controls the routing loops. In some situations, it is necessary to enable split horizon to avoid loops ‚ for example, in a normal situation, an IGRP update is received on an interface and is not sent out on the same interface. In other situations, it must be disabled, such as in a hub-and-spoke Frame Relay situation when spokes have no circuit between them and they go through the hub router (see Figure 5-27).

Figure 5-27. Hub-and-Spoke Topology in Which Spokes Do Not Have Any Circuits Between Them

Another unique situation in this example is a router with an external route that has a next-hop address also known through the same interface where other IGRP routers are sitting (see Figure 5-28). When those external routes are redistributed into IGRP, the router does not advertise that route out the same interface because split horizon is enabled. Also, if a secondary address is configured under an interface, split horizon must be turned off on that interface; otherwise, that secondary address will not be advertised out that interface to other routers. In Figure 5-28, some secondary addresses are defined under R1's Ethernet. For this reason, you must configure no ip split-horizon under R1's Ethernet interface.

Figure 5-28. Network Setup Conducive to Route Advertisement Problems Because of Split Horizon

Figure 5-28 shows the network setup that produces problems when split horizon is enabled. Router 1 is not advertising all IGRP routes to Router 2.

Figure 5-29 shows the flowchart to follow to fix this problem.

Figure 5-29. Problem-Resolution Flowchart

Debugs and Verification

Example 5-68 shows the current configuration of R1. Note that 166.166.166.0/24 is known through 131.108.1.3. R2 also resides on this subnet, so R1 will not send out any update on this interface because of split horizon.

Example 5-68 R1 Configuration in Which a Static Route's Next-Hop Address Falls Under Its Connected Subnet Where RIP Is Enabled

 R1#  router igrp 1   redistribute static   network 131.108.0.0   !   ip route 155.155.0.0 255.255.0.0 Null0   ip route 166.166.166.0 255.255.255.0    131.108.1.3   

Example 5-69 shows that the route 166.166.166.0/24 is not in the routing table of Router R2.

Example 5-69 R2's Route Table Indicates That the 166.166.166.0/24 Route Is Missing

 R2#  show ip route igrp  I    155.155.0.0/16 [100/8496] via 131.108.1.1, 00:00:07, Ethernet0 

Example 5-70 shows the debug ip igrp transaction output on Router R1, which is advertising 155.155.0.0/16 but not 166.166.166.0/24. In R2's routing table, no route exists for 166.166.166.0/24.

Example 5-70 debug ip igrp transaction Command Output Shows That 166.166.166.0/24 Is Not Being Advertised

 R1#  debug ip igrp transaction  IGRP protocol debugging is on IGRP: sending update to 255.255.255.255 via Ethernet0 (131.108.1.1)       network 155.155.0.0, metric=501 

Solution

This problem happens because the next hop of 166.166.166.0/24 is 131.108.1.3. Under split horizon, IGRP will suppress this update on the interface where 166.166.166.0/24 is learned. Because of this, IGRP will not advertise 166.166.166/24 out the same interface where it is learned.

The solution lies in turning off split horizon on R1's Ethernet 0 interface.

Example 5-71 shows the corrected configuration on Router R1 to solve this problem.

Example 5-71 Disabling Split Horizon on R1 Ethernet 0 Interface

  interface Ethernet0   ip address 131.108.1.1 255.255.255.0    no ip split-horizon   

Example 5-72 shows that, after making the configuration changes, R2 is receiving 166.166.0.0/16 in the IGRP updates. Note that, because it is crossing the major network boundary, R1 will autosummarize it and send 166.166.0.0. This is why the routing table shows 166.166.0.0 instead of 166.166.166.0.

Example 5-72 R2's Routing Table Indicates That Disabling Split Horizon on R1 Has Enabled the Advertisement of 166.166.166.0/24

 R2#  show ip route igrp  I    155.155.0.0/16 [100/8496] via 131.108.1.1, 00:00:08, Ethernet0 I    166.166.0.0/16 [100/8496] via 131.108.1.1, 00:00:08, Ethernet0 

This problem also can occur when interfaces are configured with secondary IP addresses.

Example 5-73 shows the interface configuration with a secondary IP address.

Example 5-73 R1's Ethernet 0 Interface Configured with a Secondary IP Address

 R1#  interface Ethernet0   ip address 131.108.2.1 255.255.255.0 secondary   ip address 131.108.1.1 255.255.255.0  

If split horizon is enabled, this secondary address will not be advertised on Ethernet 0.

Similarly, imagine a situation in which there are three routers ‚ R1, R2, and R3 ‚ on the same Ethernet, as shown in Figure 5-30.

Figure 5-30. Network with Three Routers on the Same Ethernet Network

R1 and R3 are running OSPF. R1 and R2 are running IGRP. Now R3 advertises certain routes through OSPF to R1 that R1 has to redistribute into IGRP. R1 will not advertise those OSPF routes to R2 because of split horizon. Again, the solution is to disable split horizon.

Basically, these are the three main reasons for turning off the split horizon. Any other situation might create a routing loop if split horizon is turned off.