Understanding the Role of Split Horizon
Split horizon is the function of not advertising routes over an interface that the router is using to reach the route. The role of split horizon is to help avoid routing loops in a network. Split horizon prevents a router from advertising routes in its routing table that are known via a particular interface back out that same interface. This scenario explains how turning off split horizon can lead to routing loops.
Refer to Figure 2-6. RouterA would not advertise 168.71.8.0 to RouterC over serial 1 because RouterA learned about this subnet from RouterC over its serial 1 interface. However, RouterA does send and receive updates for 168.71.8.0 over serial 0 because RouterB is not the router that RouterA is using to access 168.71.8.0. RouterA's route to 168.71.8.0 is not known via this path.
Figure 2-6. A review of the basic network topology
Split horizon applies to connected routes as well. A connectedroute is a route to which the router has a direct physical attachment. In the previous example, RouterA has a connected route to 168.71.6.0 via interface serial 0. In other words, as far as RouterA is concerned, 168.71.6.0 is known via serial 0. RouterA does not advertise 168.71.6.0 out serial 0 if split horizon is enabled on serial 0.
RouterA's preferred route (the route it has stored) to network 168.71.8.0 is out serial 1. When RouterA is due to send an update to RouterC, it builds an update that contains all of the routes in its routing table except for the routes known via serial 1. In this case, it does not contain 168.71.9.0, 168.71.8.0, or 168.71.7.0. It does contain 168.71.5.0 and 168.71.6.0.
The following is an edited version of RouterA's routing table for reference:
RouterA#show ip route (edited for clarity)
C 168.71.9.0 is directly connected, Serial1
R 168.71.8.0 [120/1] via 168.71.9.2, 00:00:24, Serial1
R 168.71.7.0 [120/1] via 168.71.9.2, 00:00:24, Serial1
[120/1] via 168.71.6.2, 00:00:19, Serial0
C 168.71.6.0 is directly connected, Serial0
C 168.71.5.0 is directly connected, Ethernet0
You need to refer back to this text as this scenario progresses.
Routing Advertisements with Split Horizon Enabled
In the following output of the debug ip rip command on RouterA, you can see RouterA both receiving and advertising 168.71.8.0 out serial 0. You can also see that RouterA does not advertise 168.71.8.0 out serial 1 to RouterC. Notice also that RouterA does not advertise the connected routes out the interfaces they are connected to.
RouterA#debug ip rip Aug 2 23:02:03: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 2 23:02:03: 168.71.8.0 in 1 hops Aug 2 23:02:03: 168.71.7.0 in 1 hops Aug 2 23:02:05: RIP: received v1 update from 168.71.6.2 on Serial0 Aug 2 23:02:05: 168.71.8.0 in 2 hops Aug 2 23:02:05: 168.71.7.0 in 1 hops Aug 2 23:02:16: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 2 23:02:16: subnet 168.71.9.0, metric 1 Aug 2 23:02:16: subnet 168.71.8.0, metric 2 Aug 2 23:02:16: subnet 168.71.5.0, metric 1 Aug 2 23:02:16: default, metric 1 Aug 2 23:02:16: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1) Aug 2 23:02:16: subnet 168.71.6.0, metric 1 Aug 2 23:02:16: subnet 168.71.5.0, metric 1 Aug 2 23:02:16: default, metric 1 RouterA#
Split horizon is enabled by default in most instances. It is possible to tell whether split horizon is on or off by entering the show interfacecommand at a router prompt and examining the output.
RouterA#sh ip int s 1
Serial1 is up, line protocol is up
Internet address is 168.71.9.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is enabled
Multicast reserved groups joined: 224.0.0.9
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP multicast fast switching is enabled
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
Probe proxy name replies are disabled
Gateway Discovery is disabled
Policy routing is disabled
RouterA#
Routing Advertisements with Split Horizon Disabled
You want to disable split horizon when there is a need to send routing updates back out interfaces that they were learned over. The scenario on multipoint interfaces later in this chapter explains a circumstance you may want to disable split horizon for. It discusses how to disable split horizon, as well as the possible negative effects of doing so.
The following text shows how to disable split horizon and how to tell whether you have been successful [the no ip split-horizon command was also applied to Serial 1]:
RouterA#-config#interface serial 0 RouterA#-config-if#no ip split-horizon RouterA#-config-if#^Z RouterA#sh ip int s 0 Serial0 is up, line protocol is up Internet address is 168.71.6.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is enabled Multicast reserved groups joined: 224.0.0.9 Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Security level is default Split horizon is disabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP fast switching on the same interface is enabled IP multicast fast switching is enabled Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled Probe proxy name replies are disabled Gateway Discovery is disabled Policy routing is disabled RouterA#
The configuration for RouterA would appear as follows with split horizon disabled on both serial interfaces:
! interface ethernet0 ip address 168.71.5.1 255.255.255.0 ! interface serial0 ip address 168.71.6.1 255.255.255.0 bandwidth 128 no ip split-horizon ! interface serial1 ip address 168.71.9.1 255.255.255.0 bandwidth 128 no ip split-horizon ! router rip network 168.71.0.0 passive-interface Ethernet0 ! ip route 0.0.0.0 0.0.0.0 Ethernet0 !
In the following output of the debug ip ripcommand on RouterA, you can see RouterA advertising all of its routes out both serial interfaces because split horizon has been disabled:
RouterA#debug ip rip
Aug 2 23:54:47: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1)
Aug 2 23:54:47: subnet 168.71.9.0, metric 1
Aug 2 23:54:47: subnet 168.71.8.0, metric 2
Aug 2 23:54:47: subnet 168.71.7.0, metric 2
Aug 2 23:54:47: subnet 168.71.6.0, metric 1
Aug 2 23:54:47: subnet 168.71.5.0, metric 1
Aug 2 23:54:47: default, metric 1
Aug 2 23:54:47: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1)
Aug 2 23:54:47: subnet 168.71.9.0, metric 1
Aug 2 23:54:47: subnet 168.71.8.0, metric 2
Aug 2 23:54:47: subnet 168.71.7.0, metric 2
Aug 2 23:54:47: subnet 168.71.6.0, metric 1
Aug 2 23:54:47: subnet 168.71.5.0, metric 1
Aug 2 23:54:47: default, metric 1
RouterA#
This output showed that RouterA advertised every route it knew, including routes it is directly connected to back out the connected interface.
To understand this point further, take a look at the edited debug code that follows. It shows RouterA sending a route for 168.71.6.0 out serial 0 with split horizon disabled.
RouterA#debug ip rip Aug 2 23:54:47: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 2 23:54:47: subnet 168.71.9.0, metric 1 Aug 2 23:54:47: subnet 168.71.8.0, metric 2 Aug 2 23:54:47: subnet 168.71.7.0, metric 2 Aug 2 23:54:47: subnet 168.71.6.0, metric 1 Aug 2 23:54:47: subnet 168.71.5.0, metric 1 Aug 2 23:54:47: default, metric 1 RouterA#
The following code shows that with split horizon enabled, RouterA does not advertise 168.71.6.0 out serial 0:
RouterA#debug ip rip Aug 2 23:02:16: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 2 23:02:16: subnet 168.71.9.0, metric 1 Aug 2 23:02:16: subnet 168.71.8.0, metric 2 Aug 2 23:02:16: subnet 168.71.5.0, metric 1 Aug 2 23:02:16: default, metric 1 RouterA#
Routing Loops Caused by Disabling Split Horizon
In this scenario, the IP address is removed from Ethernet0 on RouterA (see Figure 2-7). The method for doing this follows. Removing the IP address makes RouterA think it has lost its route to 168.71.5.0. Because split horizon has been disabled on RouterA's serial interfaces, this results in a temporary routing loop between RouterA and RouterC while the routing tables in RouterA and RouterC reconverge.
Figure 2-7. The IP address on Ethernet0 in RouterA is removed
The following output of the debug ip rip and debug ip route commands on RouterA show RouterA's reaction to losing the IP address on Ethernet0.
The same debug messages are shown in each step. The messages appropriate to each section are in bold. Notice the progression as 168.71.5.0 is advertised back and forth between the routers until the metric is increased to 16.
Note
The debug ip routing command causes a router to create debug messages when significant changes, such as the loss of a route, occur in the routing table. The debugip ripcommand causes the router to create a message whenever a RIP event takes place—in this case, when a routing update is either sent or received using the RIP protocol.
Notice what happens when the IP address is removed from RouterA:
RouterA#debug ip rip RouterA#debug ip routing RouterA#-config#interface ethernet 0 RouterA#-config-if#no ip address RouterA#-config-if#^Z RouterA# Aug 3 01:14:01: RT: del 168.71.5.0/24 via 0.0.0.0, connected metric [0/0] Aug 3 01:14:01: RT: delete subnet route to 168.71.5.0/24 Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 2 hops Aug 3 01:14:02: RT: add 168.71.5.0/24 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: received v1 update from 168.71.6.2 on Serial0 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RT: delete route to 168.71.5.0 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RT: no routes to 168.71.5.0, entering holddown RouterA#
Notice that RouterA receives an update for 168.71.5.0 with a metric of 2 from RouterC and installs it. At this point, RouterC thinks that RouterA has a path to 168.71.5.0, and RouterA thinks that RouterC has a path to 168.68.5.0. In other words, a loop exists. If RouterA received a packet destined for subnet 168.71.5.0 during this time, RouterA would forward it to RouterC, and RouterC would send it right back to RouterA.
RouterA#debug ip routing RouterA#-config#interface ethernet 0 RouterA#-config-if#no ip address RouterA#-config-if#^Z RouterA# Aug 3 01:14:01: RT: del 168.71.5.0/24 via 0.0.0.0, connected metric [0/0] Aug 3 01:14:01: RT: delete subnet route to 168.71.5.0/24 Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 2 hops Aug 3 01:14:02: RT: add 168.71.5.0/24 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: received v1 update from 168.71.6.2 on Serial0 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RT: delete route to 168.71.5.0 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RT: no routes to 168.71.5.0, entering holddown RouterA#
In the following output, you can see that RouterA increases the metric to 3 and advertises the route back to RouterB and RouterC:
RouterA#debug ip routing RouterA#-config#interface ethernet 0 RouterA#-config-if#no ip address RouterA#-config-if#^Z RouterA#-config-if#^Z RouterA# Aug 3 01:14:01: RT: del 168.71.5.0/24 via 0.0.0.0, connected metric [0/0] Aug 3 01:14:01: RT: delete subnet route to 168.71.5.0/24 Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 2 hops Aug 3 01:14:02: RT: add 168.71.5.0/24 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: received v1 update from 168.71.6.2 on Serial0 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RT: delete route to 168.71.5.0 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RT: no routes to 168.71.5.0, entering holddown RouterA#
Notice in this final section that RouterB and RouterC send an advertisement for 168.71.5.0 back to RouterA with a metric of 16. This is in direct response to both RouterB and RouterC having noticed that RouterA increased the metric for 168.71.5.0 each time it advertised it. Receiving an advertisement from the same router with an increased metric usually means that the two routers are listening to each other's routes for the same network, thus creating a loop.
In order to stop this looping from going on until the increasing metric reaches the maximum amount—16 for RIP—the first router to notice the problem poisons the route to the other router by automatically marking the network as unreachable in its next update, which is called poi son reverse. Poison reverse is explained in more detail later in this chapter.
RouterA#debug ip routing RouterA#-config#interface ethernet 0 RouterA#-config-if#no ip address RouterA#-config-if#^Z RouterA#-config-if#^Z RouterA# Aug 3 01:14:01: RT: del 168.71.5.0/24 via 0.0.0.0, connected metric [0/0] Aug 3 01:14:01: RT: delete subnet route to 168.71.5.0/24 Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 2 hops Aug 3 01:14:02: RT: add 168.71.5.0/24 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: sending v1 update to 255.255.255.255 via Serial1 (168.71.9.1) Aug 3 01:14:02: subnet 168.71.5.0, metric 3 Aug 3 01:14:02: RIP: received v1 update from 168.71.6.2 on Serial0 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RIP: received v1 update from 168.71.9.2 on Serial1 Aug 3 01:14:02: 168.71.5.0 in 16 hops (inaccessible) Aug 3 01:14:02: RT: delete route to 168.71.5.0 via 168.71.9.2, rip metric [120/2] Aug 3 01:14:02: RT: no routes to 168.71.5.0, entering holddown RouterA#
RouterA's route to 168.71.5.0 has just entered holddown, as shown in the previous debug message. The events that occur in RouterA's routing table after the holddown timer expires will be the same as the events explained in the previous section on convergence.
Note
For brevity's sake, only RouterA's debug messages were provided in this section. RouterB and RouterC both went through a very similar scenario to that depicted for RouterA. They both lost their original routes to 168.71.5.0 and temporarily installed a loop, which eventually went into holddown, as did RouterA's route to 168.71.5.0.
Loss of a Connected Route Versus a Dynamic Route
Cisco routers react to losing a connected route differently than when they lose a dynamic route. Please refer to Figure 2-7 for the network topology used in this section.
In this scenario, split horizon has been disabled on all serial interfaces, and RouterA has had its IP address on Ethernet0 removed (see Figure 2-7). The debug messages shown here occur at the same time in both routers. Their clocks have been synchronized.
In the following debug messages from RouterA, you can see that RouterA immediately accepts RouterC's advertisement for 168.71.5.0 when it arrives. RouterC advertised 168.71.5.0 to RouterA because that split horizon has been disabled on RouterC's serial 1 interface.
RouterA#debug ip routing
Aug 5 23:11:04: RT: del 168.71.5.0/24 via 0.0.0.0, connected metric [0/0]
Aug 5 23:11:04: RT: delete subnet route to 168.71.5.0/24
Aug 5 23:11:15: RT: add 168.71.5.0/24 via 168.71.9.2, rip metric [120/2]
RouterA#
In the following debug from RouterC, you can see RouterC putting its route for 168.71.5.0 into holddown and waiting another 58 seconds before adding the new route:
RouterC# debug ip routing
Aug 5 23:47:40: RT: flushed route to 168.71.5.0 via 168.71.9.1 (Serial1)
Aug 5 23:47:40: RT: no routes to 168.71.5.0, entering holddown
Aug 5 23:48:38: RT: add 168.71.5.0 255.255.255.0 via 168.71.7.2, rip metric [120/2]
RouterC#
Note
The clocks in RouterA and RouterC are synchronized.
Split Horizon's Effect on Multipoint WAN Interfaces
Multipoint interfaces are physical interfaces that have the capability to reach multiple remote networks concurrently. Frame Relay and primary rate ISDN are two examples of interfaces with one physical connection. Through this connection, more than one remote network can be reached. The network diagram in Figure 2-8 has been changed to help explain how enabling split horizon causes problems on a Frame Relay network.
Notice that the serial interfaces on all three routers are now part of subnet 168.71.6.0. This is because Frame Relay is a layer two protocol. All devices connected to a common layer two network usually share the same network address space.
Figure 2-8. RouterA can reach both RouterB and RouterC via serial 0.
Note
Address space is another way of referring to the network portion of an IP address. In this case, RouterA, RouterB, and RouterC are using up host addresses .1, .2, and .3 of the possible 254 host addresses available in address space 168.71.6.0.
A partial configuration for RouterA showing the use of a multipoint Frame Relay interface follows:
!
interface serial0
encapsulation frame-relay
ip address 168.71.6.1 255.255.255.0
frame-relay map ip 168.71.6.2 100 broadcast
frame-relay map ip 168.71.9.2 101 broadcast
!
HINT
Remember that split horizon is off by default on multipoint interfaces for IP, which is why it doesn't appear in the previous configuration.
In the revised network diagram shown in Figure 2-8, RouterA is the only router with a complete routing table. RouterA has installed routes to subnets 168.71.7.0 and 168.71.8.0 that are known via serial 0. Due to split horizon, RouterA does not advertise either of these subnets back out serial 0. This prevents RouterB from learning about 168.71.8.0 and prevents RouterC from learning about 168.71.7.0. A facsimile of the actual routing tables for each router is included in Figure 2-8.
The debug ip rip messages from RouterA with split horizon enabled show why having split horizon enabled causes RouterB and RouterC to only have partial routing tables. Only subnet 168.71.5.0 is being advertised.
RouterA#debug ip rip
Aug 2 23:03:21: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1)
Aug 2 23:03:21: subnet 168.71.5.0, metric 1
RouterA#
The debug ip rip messages from RouterA with split horizon disabled show why having split horizon disabled allows RouterB and RouterC to obtain full routing tables.
RouterA#debug ip rip Aug 2 23:10:51: RIP: sending v1 update to 255.255.255.255 via Serial0 (168.71.6.1) Aug 2 23:10:51: subnet 168.71.9.0, metric 1 Aug 2 23:10:51: subnet 168.71.8.0, metric 2 Aug 2 23:10:51: subnet 168.71.7.0, metric 2 Aug 2 23:10:51: subnet 168.71.6.0, metric 1 Aug 2 23:10:51: subnet 168.71.5.0, metric 1 RouterA#
This example shows why Cisco defaults to disabling split horizon on Frame Relay interfaces. However, the section on disabling split horizon and routing loops has shown that disabling split horizon can cause problems. A more effective solution is to use subinterfaces, as explained in the next section.
Using Subinterfaces to Avoid Problems Caused by Split Horizon
The term subinterfaces refers to the process of creating logical interfaces on a physical interface. It is better to use subinterfaces with Frame Relay because each logical interface is treated just like a real physical interface by routing protocols (see Figure 2-9).
RouterA's partial configuration with Frame Relay and subinterfaces on serial 0 look like the following output:
!
interface serial0
encapsulation frame-relay
!
interface serial0.1 point-to-point
ip address 168.71.6.1 255.255.255.0
frame-relay map ip 168.71.6.2 100 broadcast
!
interface serial0.2 point-to-point
ip address 168.71.9.1 255.255.255.0
frame-relay map ip 168.71.9.2 101 broadcast
!
HINT
Remember that split horizon is on by default on point-to-point interfaces, which is why it doesn't appear in the configuration.
Figure 2-9. An example of using subinterfaces to ensure full IP connectivity
Using subinterfaces allows RouterB and RouterC to have full connectivity even though RouterA is running split horizon on subinterfaces 0.1 and 0.2.
The following debug ip ripmessages from RouterA show that RouterA will now send advertisements to RouterB and RouterC that allow them to create a complete routing table.
RouterA#debug ip rip
Aug 3 03:07:01: RIP: sending v1 update to 255.255.255.255 via Serial0.1 (168.71.6.1)
Aug 3 03:07:01: subnet 168.71.9.0, metric 1
Aug 3 03:07:01: subnet 168.71.8.0, metric 2
Aug 3 03:07:01: subnet 168.71.5.0, metric 1
Aug 3 03:07:01: RIP: sending v1 update to 255.255.255.255 via Serial0.2 (168.71.9.1)
Aug 3 03:07:01: subnet 168.71.7.0, metric 2
Aug 3 03:07:01: subnet 168.71.6.0, metric 1
Aug 3 03:07:01: subnet 168.71.5.0, metric 1
RouterA#