Split-Horizon: Troubleshooting Common Issues

Understanding Split Horizon Failures in Production Networks

Split-horizon troubleshooting becomes critical when distance vector protocols fail to prevent routing loops despite proper configuration. While the concept appears straightforward, don't advertise routes back through the interface they were learned from; real-world implementations reveal subtle failure modes that can compromise network reliability.

The most common split-horizon issues manifest during network convergence events, NBMA (Non-Broadcast Multiple Access) topology changes, and routing redistribution scenarios. Understanding these failure patterns enables rapid diagnosis and resolution before loops destabilize your network.

Identifying Split Horizon Violations

Split horizon violations typically present as temporary or persistent routing loops, characterized by increasing hop counts and convergence delays. The key diagnostic indicators include:

• Routes with hop counts reaching infinity (16 for RIP, 255 for EIGRP)
• Identical prefixes advertised from multiple interfaces on the same router
• Convergence times exceeding expected protocol timers
• Asymmetric routing patterns during topology changes

Use debug ip rip or debug eigrp packets to observe route advertisements. Look for routes being advertised back through their learned interfaces—a clear split horizon violation.

Router# debug ip rip
RIP protocol debugging is on
*Mar  1 01:23:45.123: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (192.168.1.1)
*Mar  1 01:23:45.127: RIP: build update entries
*Mar  1 01:23:45.131:   10.1.1.0/24 via 0.0.0.0, metric 1, tag 0
*Mar  1 01:23:45.135: RIP: received v2 update from 192.168.1.2 on Serial0/0
*Mar  1 01:23:45.139:   10.1.1.0/24 via 0.0.0.0 in 1 hops (POISON REVERSE)

NBMA Network Split Horizon Problems

Frame Relay and similar NBMA technologies create the most complex split horizon scenarios. The physical topology (multiple sites connected through a single physical interface) conflicts with split horizon's interface-based logic.

In hub-and-spoke Frame Relay deployments, split horizon prevents the hub from advertising routes between spokes through the same physical interface, even though they represent different logical circuits. This breaks spoke-to-spoke reachability unless properly addressed.

Consider a typical scenario: three branch offices connected to a central hub via Frame Relay. The hub router learns routes from Branch A and needs to advertise them to Branch B, but split horizon blocks this advertisement because both branches connect through the same physical interface.

Router-Hub# show frame-relay map
Serial0/0 (up): ip 10.1.1.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 10.1.1.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active

The solution requires either disabling split horizon on the hub interface or implementing subinterfaces to create separate broadcast domains:

interface Serial0/0
 no ip split-horizon

Alternatively, use point-to-point subinterfaces to maintain split horizon benefits while enabling proper route propagation:

interface Serial0/0.102 point-to-point
 ip address 10.1.12.1 255.255.255.252
 frame-relay interface-dlci 102

interface Serial0/0.103 point-to-point
 ip address 10.1.13.1 255.255.255.252
 frame-relay interface-dlci 103

EIGRP Split Horizon Edge Cases

EIGRP's advanced distance vector behavior creates unique split horizon considerations. EIGRP maintains separate topology tables and can advertise feasible successors that meet specific loop-free criteria, which works within split horizon rules but may appear counterintuitive.

When unequal-cost load balancing is configured using the variance command (which allows EIGRP to load balance across unequal-cost paths), EIGRP may use multiple paths to the same destination. However, this doesn't violate split horizon—EIGRP still won't advertise a route back through the interface it was learned from.

For example, if Router A learns about network 192.168.10.0/24 through Serial0/0 with a metric of 2816, and through Serial0/1 with a metric of 5632, variance allows both paths to be used simultaneously. Some administrators mistakenly believe this violates split horizon, but EIGRP will never advertise this network back through Serial0/0 or Serial0/1.

Router# show ip eigrp topology 192.168.10.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(192.168.1.1) for 192.168.10.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2816
  Descriptor Blocks:
  192.168.1.2 (Serial0/0), from 192.168.1.2, Send flag is 0x0
      Composite metric is (2816/256), route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 192.168.2.1

Verify split horizon status with show ip eigrp interfaces detail:

Router# show ip eigrp interfaces detail Serial0/0
EIGRP-IPv4 Interfaces for AS(100)
                        Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface      Peers   Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0           1        0/0          0/0         1236       0/0           0           0
  Split-horizon is enabled
  Next xmit serial 
  Packetized sent/expedited: 23/0
  Hello interval is 60, Hold time is 180
  Authentication mode is not set

Redistribution-Induced Split Horizon Issues

Route redistribution between protocols can create split horizon violations that aren't immediately obvious. When redistributing between OSPF and EIGRP, routes learned from one protocol and redistributed into the other might be re-advertised back into the original protocol via different interfaces.

This scenario commonly occurs in enterprise networks with multiple routing domains. Consider a network where Router A redistributes OSPF routes into EIGRP, Router B learns these routes via EIGRP, and redistributes them back into OSPF, potentially creating a feedback loop.

The solution requires careful route filtering and administrative distance manipulation:

router eigrp 100
 redistribute ospf 1 metric 1544 20 255 1 1500 route-map FILTER-OSPF
 distance 90 0.0.0.0 255.255.255.255

route-map FILTER-OSPF deny 10
 match tag 110
route-map FILTER-OSPF permit 20
 set tag 100

router ospf 1
 redistribute eigrp 100 subnets route-map FILTER-EIGRP

route-map FILTER-EIGRP deny 10
 match tag 100
route-map FILTER-EIGRP permit 20
 set tag 110

Troubleshooting Methodology

Systematic split-horizon troubleshooting follows a structured approach. Begin by mapping the physical and logical topologies to identify potential points of violation. Document all redistribution points and NBMA segments where split horizon behavior differs from expectations.

Use show ip protocols to verify the split-horizon configuration across all routing processes:

Router# show ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 192.168.1.1
    Topology : 0 (base) 
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100

Trace route propagation using debug commands while monitoring routing table changes. Focus on interfaces where routes appear and disappear unexpectedly; these often indicate split horizon violations or configuration errors. Document the following for each suspected interface:

• Routes being received and their sources
• Routes being advertised and their destinations
• Split horizon status and any manual overrides
• NBMA configuration and logical circuit mappings

What's Next

With split horizon troubleshooting mastered, the next critical loop prevention mechanism to examine is poison reverse and its interaction with holddown timers. Understanding how these mechanisms work together provides complete control over distance vector protocol convergence behavior in complex topologies.

Tools and resources for this topic

• CCNP ENARSI 300-410 Official Cert Guide — The definitive ENARSI study resource by Raymond Lacoste. Covers advanced routing, services, and troubleshooting.