Problem: Sender Is Not Advertising RIP Routes

Typically, an IP network running RIP 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 in cases when filtering of certain subnets is done at some routers and not at others. Ideally, all RIP routers have routes of the complete network.

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

• Some routers are not advertising the RIP routes.

• Some routers are not receiving the RIP routes.

This section deals with problems in sending RIP routes.

Figure 3-21 provides a network scenario that will be used as the basis for troubleshooting a majority of following causes of the problem of the sender not advertising RIP routes:

• Missing or incorrect network statement

• Outgoing interface that is down

• distribute-list out blocking the routes

• Advertised network interface that is down

• Outgoing interface defined as passive

• Broken multicast capability (encapsulation failure in Frame Relay)

• Misconfigured neighbor statement

• Advertised subnet is VLSM

• Split horizon enabled

Figure 3-21. Network Setup in Which Router R1 Is Not Sending RIP Routes Toward R2

Figure 3-21 shows the network setup in which Router R1 is not sending RIP routes toward R2.

The sections that follow carefully dissect how to troubleshoot this problem based on specific causes.

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

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

Figure 3-22 shows the flowchart to follow to fix this problem.

Figure 3-22. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verifications

Example 3-64 shows the current configuration for R1.

Example 3-64 R1 Configuration Shows the Misconfigured 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 rip    network 131.107.0.0   

The network statement is incorrectly configured under router rip in Example 3-64. Instead of 131.108.0.0, 131.107.0.0 is configured. This will not enable RIP on the interface, and no updates will be sent.

Solution

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

  router rip   network 131.0.0.0  

The network statement will not cover 131.0.0.0 through 131.255.255.255 because 131.0.0.0 is a classless network and RIP is a classful protocol. Similarly, if you have multiple Class C addresses, you cannot use one network statement to cover all the addresses that you own. For example, suppose that you own 200.1.1.0 through 200.1.4.0. This doesn't mean that you can use the following command syntax:

  router rip   network 200.1.0.0  

The network statement here is meaningless for RIP-1 because RIP-1 is a classful protocol. The correct way to advertise all four networks in RIP is as follows :

  router rip   network 200.1.1.0   network 200.1.2.0   network 200.1.3.0   network 200.1.4.0  

Example 3-65 shows the corrected configuration for R1.

Example 3-65 Correcting the network Statement in the R1 Configuration

 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 rip    network 131.108.0.0   

Example 3-66 shows the routing table of Router R2, showing the learned RIP route.

Example 3-66 R2 Routing Table Shows That the RIP Routes Are Learned After Correcting the network Statement

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:11 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:11 ago, via Ethernet0     Route metric is 1, traffic share count is 1 

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

RIP is the routing protocol that runs on Layer 3. RIP cannot send updates across an inter-face if the outgoing interface is down. There can be a variety of possible causes 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, RIP will not be capable of sending any updates across the network. The main thing to note here is that, with any of these potential causes, the line protocol will always show down. This is the most important information to determine Layer 2 connectivity.

Figure 3-23 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-23. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-67 shows that the interface Ethernet 0 is down.

Example 3-67 Outgoing Interface Ethernet 0 of R1 Shows That the Line Protocol 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 

Example 3-68 shows the debug ip rip output. In this debug, R1 is not sending or receiving any RIP updates because Layer 2 is down.

In the debug, there are no outputs because of this problem .

Example 3-68 debug ip rip Output Reveals That Nothing Is Being Sent or Received on R1's Ethernet0 Interface

 R1#  debug ip rip  RIP protocol debugging is on R1# 

Solution

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

To correct this problem, Layer 2 or Layer 1 must be corrected. Sometimes, the problem could be as simple as loose cables or a bad cable that must be replaced, or it could be as complex as bad hardware, in which case hardware must be replaced .

Example 3-69 shows the interface Ethernet 0 after fixing the Layer 2 problem.

Example 3-69 R1's Outgoing Interface Ethernet0 Is Up After Fixing the Layer 2 Issue

 R1#  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 3-70 shows the routing table of R2.

Example 3-70 1's Ethernet0 Interface Is Up, So RIP Is Sending Updates and R2 Has RIP Routes in Its Routing Table

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

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

distribute-list out is used to filter any routes that will be sent out an interface. If a receiver is complaining about missing routes that should be received, make sure that the routes are not being filtered through distribute-list out. If this is the case, you must modify the access list.

Figure 3-24 shows the flowchart to follow to fix this problem.

Figure 3-24. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-71 shows the configuration of Router R1. In this configuration, access-list 1 does not explicitly permit the 131.108.0.0 network, so R1 will not be allowed to advertise any 131.108.X.X network, including 131.108.2.0/24.

Example 3-71 access-list 1 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 rip   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 are explicitly permitted in the access list. If not, they will be denied . In the configuration example in Example 3-72, the access list is permitting only 131.107.0.0. An implicit deny any at the end of each access list causes the 131.108.0.0 network to be denied. To fix this problem, permit 131.108.0.0 in access-list 1, as shown in Example 3-72.

Example 3-72 Reconfiguring access-list 1 to Permit Network 131.108.0.0

  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 rip   network 131.108.0.0    distribute-list 1 out    !    access-list 1 permit 131.108.0.0 0.0.255.255   

Example 3-73 shows the routing table of Router R2.

Example 3-73 R2 Routing Table Shows the Entry for the 131.108.2.0 Network After Permitting It in access-list 1

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

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

The network that is being advertised might be down, and the connected route has been removed from the routing table. In this situation, RIP will start advertising that network with an infinite metric of 16; after the hold-down timer has expired , it will no longer advertise this network. As soon as the advertised network comes up, RIP will start advertising it again in its updates.

Figure 3-25 shows the flowchart to follow to fix this problem.

Figure 3-25. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-74 shows that the line protocol of R1's Ethernet 1 interface is down, indicating that there is something wrong at Layer 2. This is the interface that is directly attached to the network that needs to be advertised. Therefore, that network cannot be advertised to neigh-boring routers.

Example 3-74 show interface Output Displays That the Line Protocol of the Advertised Network 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 

When the advertised network's interface goes down, RIP will detect the down condition. RIP will no longer advertise that network in the RIP update. In Example 3-74, interface Ethernet 1 is down, so RIP will no longer advertise 131.108.2.0/24 in its update.

Solution

You must correct this problem at Layer 2 or Layer 1. Sometimes, 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. After fixing the Layer 2 problem, reissue the show interface command to view the current status, to verify that it has changed state to up.

Example 3-75 shows that the advertised network interface line protocol is up.

Example 3-75 show interface Output Displays That the Line Protocol of Ethernet1 Is Up After Fixing the Layer 2 Issue

 R1#  show interface Ethernet 1  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 

When the interface is active again, RIP will begin to advertise that network in its periodic updates. Example 3-76 shows that the route that was down is back in the routing table of R2.

Example 3-76 show ip route Output Displays That R2's Routing Table Indicates the Network Again After the Layer 2 Issue Is Resolved

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

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

A situation might arise in which a router has a complete RIP routing table, but it is not ad-vertising to other routers running RIP. This occurs when not all routers in a RIP network have complete routing tables, resulting in lacking IP connectivity from one part of the net-work to the other. If the outgoing interface is defined as passive, it will not advertise any RIP updates on that interface.

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

Figure 3-26. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-77 shows the output of show ip protocols, which shows that the outgoing interface is defined as a passive interface.

Example 3-77 show ip protocols Output Reveals That the Outgoing Interface on R1 Is Passive

 R1#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 26 seconds   Invalid after 180 seconds, hold down 180, flushed after 240   Outgoing update filter list for all interfaces is   Incoming update filter list for all interfaces is   Redistributing: rip   Default version control: send version 1, receive any version     Interface        Send  Recv   Key-chain     Loopback0        1     1 2   Routing for Networks:     131.108.0.0  Passive Interface(s) Ethernet0  Routing Information Sources:     Gateway         Distance      Last Update     131.108.1.2          120      00:00:26   Distance: (default is 120) 

Example 3-78 shows the configuration of Router R1, which shows that the outgoing inter-face is defined as passive.

Example 3-78 Configuring the passive interface Command in RIP

  router rip   passive-interface Ethernet0   network 131.108.0.0  

Solution

When an interface is defined as a passive interface under RIP, RIP will receive updates on that interface but will not send any updates.

In Example 3-78, the interface Ethernet 0 is defined as passive, so R1 is not sending any updates on Ethernet 0. Sometimes, some networks should be advertised and others should be filtered. In this type of situation, passive interfaces should not be used. Distribute lists, used to selectively filter updates, are a better solution in that case.

Assume that passive-interface was configured by mistake. Take this command out of the configuration to solve this problem using the no form of the command.

Example 3-79 shows the new configuration to solve this problem.

Example 3-79 Correcting the passive-interface Problem

  router rip   network 131.108.0.0  

Example 3-80 shows the routing table of R2 after fixing the problem.

Example 3-80 R2 Routing Table After Removing the passive-interface Command

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Serial0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0       Route metric is 1, traffic share count is 1 

Sender Is Not Advertising RIP Routes ‚ Cause: Broken Multicast Capability (Frame Relay)

In some networking scenarios, router interfaces do not automatically propagate multicast and broadcast traffic unless configured to do so. This could be a major problem because RIP-1 updates are sent at a broadcast address and RIP-2 uses multicast to exchange routes. No routing information will propagate across the network unless broadcast and multicast features are enabled on such interfaces. Nonbroadcast multiaccess (NBMA) Frame Relay is a prime example of a networking environment in which interfaces exhibit this behavior.

Figure 3-27 shows a network setup that is deliberately configured with broken multicast to illustrate the example of how Frame Relay RIP updates will not go across R1.

Figure 3-27. NBMA Frame Relay Network Vulnerable to Broken Multicast Capability Problems

In Figure 3-27, Router 1 and Router 2 are connected through Frame Relay. Router 1 is not advertising RIP routes toward Router 2.

Figure 3-28 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-28. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-81 shows the configuration of Router R1. In this example, Frame Relay pro-vides the Layer 2 encapsulation. In this configuration, the frame-relay map statement doesn't have the keyword broadcast at the end. As a result, all broadcast/multicast traffic will be prohibited from crossing the NBMA network. The broadcast keyword tells the router to replicate the necessary broadcasts and send them across the specified circuits.

Example 3-81 R1's frame-relay map Statement Lacks the broadcast Keyword

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

Example 3-83 shows output from debug ip packet. This debug includes only the broadcast traffic source from R1. As shown in Example 3-82, R1 is configured with access-list 100.

R1 is configured with access-list 100, which permits all packets from source 131.108.1.1 destined to the broadcast address of 255.255.255.255. In Example 3-83, R1 runs debug ip

Example 3-82 Configuration in R1 of access-list 100 to Limit debug Output

 R1#:  access-list 100 permit ip host 131.108.1.1 host 255.255.255.255  

packet detail with access-list 100 to limit traffic destined to 255.255.255.255 with R1 as the source. The debug output in Example 3-83 shows that there are encapsulation failures, indicating that they cannot be placed in the appropriate Layer 2 frame.

Example 3-83 debug ip packet Output on R1 Reveals Encapsulation Failure for RIP Updates

 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 112, sending broad/         multicast UDP src=520, dst=520 IP: s=131.108.1.1 (local), d=255.255.255.255 (Serial3), len 112,  encapsulation   failed  UDP src=520, dst=520 

Solution

When RIP is running in a Frame Relay (NBMA) environment, Layer 2 must be configured to support broadcast traffic; otherwise , RIP updates will not get across. When static map-ping is used, make sure to add the broadcast keyword at the end of a frame-relay map statement.

Example 3-84 shows the new configuration of Router R1 with the corrected frame-relay map statement.

Example 3-84 Corrected Configuration to Enable Broadcast Traffic to Go Across an NBMA Environment

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

Example 3-85 shows the routing table of R2 with RIP routes.

Example 3-85 R2 Routing Table with RIP Routes After the Corrected frame-relay map Statement for Router R1

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Serial0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0       Route metric is 1, traffic share count is 1 

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

In a nonbroadcast environment, RIP utilizes a unicast method to send RIP updates. To send unicast RIP updates, neighbor statements must be configured carefully. If the neighbor address is configured incorrectly in the neighbor statement, RIP will not send the unicast update to the neighbor.

Figure 3-29 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-29. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-86 shows the RIP configuration in Router R1. The configuration shows that the neighbor statement is configured incorrectly. Instead of 131.108.1.2, it's pointing to 131.108.1.3, which doesn't exist.

Example 3-86 Router R1 RIP Configuration with Incorrectly Configured neighbor Statement

 router rip  network 131.108.0.0  neighbor 131.108.1.3  

Solution

In Example 3-86, RIP is sending a unicast update to a neighbor address of 131.108.1.3, which doesn't exist.

To solve the problem, the neighbor statement must be configured properly.

Example 3-87 shows the corrected configuration of Router R1.

Example 3-87 Router R1 Configuration with the Correct neighbor Statement

 R1#  router rip  network 131.108.0.0  neighbor 131.108.1.2  

Example3-88 shows the RIP routes installed in R2's routing table.

Example 3-88 R2 Routing Table Shows the RIP Entry After Correcting the RIP neighbor Statement

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Serial0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Serial0       Route metric is 1, traffic share count is 1 

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

In almost all IP networks, IP addresses are efficiently utilized by doing variable-length subnet masking (VLSM) of the original IP block. Because RIP-1 does not support VLSM routing, routing VLSM routes becomes a common issue with RIP running networks.

Figure 3-30 shows the network setup, which produces problems because of the existence of a VLSM. The figure shows that Router 1 has an interface whose mask is /25. Note that 131.108.0.0 is variably subnetted to two different masks, 131.108.1.0/24 and 131.108.2.0/25.

Figure 3-30. VLSM Network Example Producing Problems with RIP

RIP-1 cannot advertise the mask of a subnet, so it cannot support VLSM and cannot advertise /25 to an RIP interface whose mask is /24.

Figure 3-31 shows the flowchart to follow to correct this problem.

Figure 3-31. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-89 shows that a loopback interface on R1 is configured for a /25 (255.255.255.128) subnet mask; the interface that will be sourcing RIP update has a /24 (255.255.255.0) mask.

Example 3-89 Configuration to Show VLSM Subnets

 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 rip   network 131.108.0.0  

Solution

RIP-1 is not designed to carry subnet mask information. Therefore, any subnet that is using a different mask than the interface that will be sourcing the RIP update will not be adver-tised by RIP. RIP actually performs a check before sending an update, to make sure that the subnet that will be advertised by RIP has the same subnet mask as the interface that will be sourcing the RIP update. If the mask is different, RIP actually drops the update and will not advertise it.

To solve the problem, either change the subnet mask so that it matches the interface that will be sourcing the RIP update or change the protocol to RIP-2, which does support VLSM.

Example 3-90 shows the configuration changes that correct the problem.

Example 3-90 Configuring RIP to Advertise VLSM Routes

 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 rip    version 2    network 131.108.0.0  

Example 3-91 shows the routing table of Router R2 after correcting the problem.

Example 3-91 Router R2 Routing Table After Resolving the VLMS Support Problem

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/25  Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

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

Split horizon is a feature in RIP to control routing loops. In some situations, it is necessary to enable split horizon to avoid loops . For example, split horizon is necessary in a normal situation when a RIP update is received on an interface and is not sent out on the same interface. Split horizon must be disabled in other environments, such as a hub-and-spoke Frame Relay environment in which spokes have no circuit between them and they go through the hub router, as shown in Figure 3-32.

Figure 3-32. Hub-and-Spoke Frame Relay Network Requiring Disabling Split Horizon

Another unique situation worth mentioning is one in which a router has an external route that has a next-hop address also known through some interface where other RIP routers are sitting. When those external routes are redistributed into RIP, the router doesn't 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.

Figure 3-33 shows the network setup that produces problems when split horizon is enabled. Router 1 is not advertising all RIP routes to Router 3.

Figure 3-33. Split Horizon ‚ Enabled Network Vulnerable to RIP Problems

Figure 3-34 shows the flowchart to follow to fix this problem.

Figure 3-34. Flowchart to Solve Why the Sender Is Not Advertising RIP Routes

Debugs and Verification

Example 3-92 shows the current configuration of R1.

Example 3-92 166.166.166.0/24 Is Being Redistributed into RIP on R1

 R1#  router rip   redistribute static   network 131.108.0.0   !   ip route 155.155.0.0 255.255.0.0  10.10.10.4   ip route 166.166.166.0 255.255.255.0   131.108.1.3  

Example 3-93 shows that the route 166.166.166.0/24 is not in the routing table of Router R2; however, 155.155.155.0/24 does show up in the routing table.

Example 3-93 R2 Routing Table Does Not Show Route 166.166.166.0/24

 R2#  show ip route rip  R    155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:07, Ethernet0 

Example 3-94 shows the debug ip rip output on Router R1. R1 is advertising only 155.155.0.0/16, not 166.166.166.0/24. In R2's routing table, no route exists for 166.166.166.0/24.

Example 3-94 debug ip rip Output Displays 166.166.166.0 Is Not Being Advertised by R1

 R1#  debug ip rip  RIP protocol debugging is on RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.1) RIP: build update entries  network 155.155.0.0 metric 1 

Solution

This problem occurs because the next hop of 166.166.166.0/24 is 131.108.1.2. With split horizon, RIP will suppress this update from going out the same interface that 166.166.166.0/24 is learned. Notice that the route 155.155.155.0/24 was advertised by R1 because the next-hop address of that route was 10.10.10.4, which is a different interface on R1.

The solution lies in turning off split horizon on the Ethernet 0 interface of R1.

A similar situation would arise if 166.166.166.0/24 was defined as a secondary interface address on R1, which will not advertise this secondary interface address in its RIP update unless split horizon is turned off.

Example 3-95 shows the new configuration on Router R1 to solve this problem.

Example 3-95 Disabling Split-Horizon on R1's Ethernet 0 Interface

 R1#  interface Ethernet0   ip address 131.108.1.1 255.255.255.0    no ip split-horizon   

Example 3-96 shows that after making the configuration changes, R2 is receiving 166.166.166.0/24 in the RIP updates.

Example 3-96 R2 Routing Table After Split Horizon Has Been Disabled Confirms That RIP Updates Reflect the 166.166.166.0/24 Route

 R2#  show ip route rip  R    155.155.0.0/16 [120/1] via 131.108.1.1, 00:00:08, Ethernet0  R    166.166.0.0/16 [120/1] via 131.108.1.1, 00:00:08, Ethernet0  

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

Example 3-97 shows the interface configuration with secondary IP address.

Example 3-97 Interface Configuration with Secondary Addresses

 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 Ethernet0.

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

Figure 3-35. Another Split Horizon ‚ Enabled Network Vulnerable to RIP Problems

R1 and R3 are running OSPF. R1 and R2 are running RIP, as in the preceding example. Now, R3 advertises certain routes through OSPF to R1 that R1 must redistribute in RIP. R1 will not advertise those OSPF routes to R2 because of split horizon. The solution is again to disable split horizon.

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