Skip to content
Log in Sign up My account

1.3 Loop Prevention Mechanisms

Blueprint 1.3: Troubleshoot loop prevention mechanisms (filtering, tagging, split horizon, route poisoning)

  • Why routing loops form: distance vector rumours, redistribution feedback, inter-area leaks
  • Distance vector protections: maximum metric, split horizon, poison reverse, route poisoning, hold-down, triggered updates
  • EIGRP protections: DUAL feasibility condition, split horizon, maximum hop count, and when split horizon must be disabled (DMVPN hub)
  • OSPF and BGP built-in protections: area 0 rule, AS_PATH, iBGP split horizon, route reflector attributes
  • Policy protections at boundaries: route filtering and route tagging
  • Symptoms of a loop: TTL expired, a traceroute that repeats hops, a route that flaps or will not age out

How routing loops happen

A routing loop exists when routers forward a packet in a circle because each one believes the next one is closer to the destination. The packet circulates until its TTL reaches zero. Loops have three main causes on ENARSI:

Cause Where it happens Main protections
Stale distance vector information ("routing by rumour") RIP, and EIGRP without DUAL's checks Split horizon, poisoning, hold-down, maximum metric, feasibility condition
Redistribution feedback Two or more points of mutual redistribution Tags, prefix filtering, AD adjustment
Hierarchy violations OSPF inter-area, BGP between ASes and inside an AS Area 0 rule, AS_PATH check, iBGP split horizon, route reflector attributes

The data plane symptom is the same for all of them:

R1# traceroute 10.9.9.9 numeric
Type escape sequence to abort.
Tracing the route to 10.9.9.9
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 2 msec 1 msec 1 msec
  2 10.2.3.3 2 msec 2 msec 2 msec
  3 10.1.3.1 3 msec 2 msec 3 msec
  4 10.1.2.2 3 msec 3 msec 3 msec
  5 10.2.3.3 4 msec 3 msec 4 msec

Repeating hops in a traceroute mean a loop. So do & characters in IOS ping output (packet lifetime exceeded) and TTL expired in transit messages on hosts. Your next step is show ip route <prefix> on each repeated hop to find which router has the wrong next hop and which source gave it that route.

Distance vector protections

graph LR
  A["R1<br/>10.9.0.0/24 connected"] -- "update: 10.9.0.0 metric 1" --> B["R2"]
  B -. "split horizon: 10.9.0.0 is NOT sent back to R1" .- A
  A -- "link to 10.9.0.0 fails:<br/>poisoned update, metric 16" --> B
  B -- "poison reverse: 10.9.0.0 metric 16" --> A
Mechanism What it does RIP EIGRP
Maximum metric Caps how far a bad route can count 16 hops = unreachable Maximum hop count 100 by default (metric maximum-hops, up to 255)
Split horizon Never advertise a route out the interface it was learned on On by default On by default
Route poisoning Advertise a failed route as unreachable instead of just dropping it Metric 16 Unreachable signalled with infinite delay
Poison reverse Send the route back to the neighbor it came from, marked unreachable Used with poisoned routes Used selectively alongside split horizon
Hold-down Ignore worse news about a recently failed route for a time 180 s Not used; DUAL replaces it
Triggered updates Send changes immediately, not at the next periodic update Yes All EIGRP updates are triggered

RIP default timers are update 30 s, invalid 180 s, hold-down 180 s and flush 240 s. You can see them in show ip protocols:

R5# show ip protocols | section rip
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 11 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2

EIGRP: DUAL and the feasibility condition

EIGRP does not need hold-down timers because DUAL only accepts a backup path that is provably loop-free. A neighbor's path qualifies as a feasible successor only if its reported distance is lower than the current feasible distance (RD < FD). A neighbor that reports a distance equal to or higher than our own best might be routing through us, so EIGRP refuses to use it without first sending queries. The detail belongs to blueprint 1.9; for 1.3 you only need to know that the feasibility condition is EIGRP's loop prevention inside one AS, and that it says nothing about loops created by redistribution.

Split horizon and the hub-and-spoke problem

Split horizon assumes every router reachable through an interface can already hear the router that sent the route. On a point-to-point link or Ethernet that is true. On a multipoint interface where spokes cannot hear each other directly (DMVPN mGRE, or older Frame Relay multipoint), it is false: the hub learns spoke A's network on Tunnel0 and split horizon forbids it from sending that network back out Tunnel0 to spoke B.

graph TB
  H["Hub R1<br/>Tunnel0 172.16.0.1/24 mGRE"]
  S2["Spoke R2<br/>Lo10 10.2.10.0/24"]
  S3["Spoke R3<br/>Lo10 10.3.10.0/24"]
  S2 -- "EIGRP over Tunnel0" --- H
  S3 -- "EIGRP over Tunnel0" --- H
  H -. "split horizon blocks 10.2.10.0/24 back out Tunnel0" .-> S3
interface Tunnel0
 no ip split-horizon eigrp 100

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  af-interface Tunnel0
   no split-horizon

interface Tunnel0
 no ip split-horizon

Disabling split horizon is safe on a DMVPN hub because spokes are not transit for each other in the hub's view, and EIGRP's feasibility condition still protects the AS. Disable it only where needed, never globally out of habit.

Exam trap

The symptom of split horizon on a DMVPN hub is specific: every spoke has a route to the hub's networks, and the hub has routes to every spoke, but spokes have no routes to each other. If spokes are missing the hub's networks too, the fault is something else (adjacency, filtering, or multicast mapping for hellos).

Exam trap

In OSPF, split horizon does not exist. OSPF is link state and floods LSAs to every router in the area. A question offering no ip split-horizon as a fix for missing OSPF routes over DMVPN is a distractor; the usual OSPF faults there are network type mismatches and DR election on the hub.

OSPF

Inside one area every router runs SPF on an identical LSDB, so intra-area loops cannot form from stale routing information. Between areas OSPF behaves like a distance vector protocol and relies on hierarchy:

  • All inter-area traffic must pass through area 0. ABRs advertise Type 3 summaries from area 0 into non-backbone areas, and from non-backbone areas into area 0.
  • An ABR does not use Type 3 LSAs received over a non-backbone area to reach other areas. This is why a discontiguous area 0 or an area not touching area 0 needs a virtual link.
  • In MPLS L3VPN designs with OSPF as the PE-CE protocol, the DN bit and the domain tag prevent routes from looping back into the provider (blueprint 2.2).

BGP

Mechanism Rule Override
AS_PATH loop check A router discards any eBGP update whose AS_PATH contains its own AS neighbor x allowas-in (hub-and-spoke MPLS designs)
iBGP split horizon A route learned from an iBGP peer is not advertised to another iBGP peer Full mesh, route reflectors or confederations
ORIGINATOR_ID A route reflector client ignores a reflected route carrying its own router ID None needed
CLUSTER_LIST A route reflector ignores a route whose CLUSTER_LIST already contains its cluster ID None needed

Exam trap

A customer with two sites in the same private AS connected through one provider will not see each site's routes at the other. The AS_PATH check discards them because they carry the customer's own AS. The fix is allowas-in on the customer router or as-override on the provider PE, not a change to the IGP.

Policy protections: filtering and tagging

Built-in mechanisms only protect a single protocol. Once routes cross a protocol boundary through redistribution, the receiving protocol knows nothing about where the route really came from. You protect those boundaries yourself.

Filtering

Filter by prefix at the boundary so each domain only accepts routes that genuinely originate in the other domain. It is precise but requires maintenance: every new subnet means a prefix list change on every redistribution point.

ip prefix-list EIGRP-NATIVE seq 5 permit 10.20.0.0/16 le 24
!
route-map E2O permit 10
 match ip address prefix-list EIGRP-NATIVE
!
router ospf 1
 redistribute eigrp 100 subnets route-map E2O

Tagging

Tag routes as they cross the boundary and deny that tag when routes go the other way. It scales without prefix lists because the tag travels with the route.

route-map O2E deny 10
 match tag 90            ! came from EIGRP originally, do not send it back
route-map O2E permit 20
 set tag 110             ! mark OSPF-origin routes as they enter EIGRP
!
route-map E2O deny 10
 match tag 110           ! came from OSPF originally
route-map E2O permit 20
 set tag 90

Use the same tag values on every redistribution point so each router recognises routes tagged by the others. The redistribution page works through a full two-point example, including the AD half of the fix.

Prefix filtering Tagging
Matches on Network and length Origin label
Maintenance Update lists when subnets change None after setup
Fails when A new subnet is added and not listed A route is retagged or a tag is stripped (for example, redistributed through a third protocol that does not preserve it)
Best for Small, stable domains, or as an extra safety net Two or more mutual redistribution points

Null0 discard routes

Summarization creates its own loop risk. A router that advertises 10.1.0.0/22 but only has 10.1.0.0/24 and 10.1.1.0/24 would otherwise forward packets for 10.1.2.5 using its default route, which may point straight back at the router that sent them. The automatic discard route to Null0 (EIGRP summary with AD 5, OSPF summary, BGP aggregate) drops those packets instead. See summarization.

Troubleshooting checklist

  1. Confirm a loop exists: traceroute repeats hops, or TTL expired in transit.
  2. On each looping hop: show ip route <prefix>. Note "Known via", the AD, the tag and "from".
  3. If the source differs between hops (one says EIGRP, the next says OSPF), suspect redistribution feedback. Check route maps for tags and the ADs on the border routers.
  4. If a distance vector route will not go away after its origin is removed, look for feedback through another protocol, then look for disabled split horizon on a point-to-point design.
  5. In BGP, check show ip bgp <prefix> for AS_PATH and, for reflected routes, Originator and Cluster list.

Lab: split horizon on a DMVPN hub

Topology: three IOSv routers connected to one CML unmanaged switch for the underlay (192.0.2.0/24, documentation range). R1 is the hub, R2 and R3 are spokes on a phase 1 design. EIGRP AS 100 runs only over Tunnel0 and the loopbacks; never enable it on the underlay interface.

graph TB
  SW["Unmanaged switch<br/>192.0.2.0/24 underlay"]
  R1["R1 hub<br/>Gi0/0 192.0.2.1<br/>Tu0 172.16.0.1<br/>Lo10 10.1.10.1/24"] --- SW
  R2["R2 spoke<br/>Gi0/0 192.0.2.2<br/>Tu0 172.16.0.2<br/>Lo10 10.2.10.1/24"] --- SW
  R3["R3 spoke<br/>Gi0/0 192.0.2.3<br/>Tu0 172.16.0.3<br/>Lo10 10.3.10.1/24"] --- SW

Step 1. Baseline (this baseline already contains fault 1: split horizon is left at its default).

! R1 hub
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.0
interface Loopback10
 ip address 10.1.10.1 255.255.255.0
interface Tunnel0
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp map multicast dynamic
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
router eigrp 100
 eigrp router-id 10.255.255.1
 network 172.16.0.0 0.0.0.255
 network 10.1.10.0 0.0.0.255
!
! R2 spoke (R3 is identical with .3 and 10.3.10.1)
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.0
interface Loopback10
 ip address 10.2.10.1 255.255.255.0
interface Tunnel0
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp map 172.16.0.1 192.0.2.1
 ip nhrp nhs 172.16.0.1
 tunnel source GigabitEthernet0/0
 tunnel destination 192.0.2.1
router eigrp 100
 eigrp router-id 10.255.255.2
 network 172.16.0.0 0.0.0.255
 network 10.2.10.0 0.0.0.255

Step 2. Ticket. "Branch 2 users (behind R2) cannot reach Branch 3 (behind R3). Both branches can reach head office."

Step 3. Gather symptoms.

R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   172.16.0.3              Tu0                      13 00:04:51    9  1470  0  4
0   172.16.0.2              Tu0                      11 00:05:02   11  1470  0  4

R1# show ip route eigrp | include 10\.
D        10.2.10.0/24 [90/27008000] via 172.16.0.2, 00:05:02, Tunnel0
D        10.3.10.0/24 [90/27008000] via 172.16.0.3, 00:04:51, Tunnel0

R2# show ip route eigrp | include 10\.
D        10.1.10.0/24 [90/27008000] via 172.16.0.1, 00:05:02, Tunnel0

The hub knows both spokes. R2 knows the hub but not R3. That is the split horizon signature.

Step 4. Prove it.

R1# show ip eigrp interfaces detail Tunnel0 | include Split
  Split-horizon is enabled

Step 5. Fix and verify.

R1(config)# interface Tunnel0
R1(config-if)# no ip split-horizon eigrp 100

The adjacencies resynchronise. Then:

R2# show ip route eigrp | include 10\.
D        10.1.10.0/24 [90/27008000] via 172.16.0.1, 00:00:21, Tunnel0
D        10.3.10.0/24 [90/28288000] via 172.16.0.1, 00:00:21, Tunnel0

R2# ping 10.3.10.1 source Loopback10
!!!!!

The next hop is the hub, which is correct for phase 1. Exact metrics depend on the tunnel bandwidth and delay defaults of your image, so compare relative values rather than expecting identical numbers.

Step 6. Fault 2, route poisoning in action. Turn on debug ip routing on R2 (lab only), then shut Loopback10 on R3. Watch R2 delete 10.3.10.0/24 within a second or two, without waiting for a hold timer: R3 sends an update marking the route unreachable, the hub relays the withdrawal, and R2 removes it. Now inject a real fault on the hub:

R1(config)# router eigrp 100
R1(config-router)# distribute-list prefix ONLY-HUB out Tunnel0
R1(config)# ip prefix-list ONLY-HUB seq 5 permit 10.1.10.0/24

Bring R3's loopback back. R2 loses 10.3.10.0/24 again although split horizon is off. show ip protocols | section eigrp on R1 shows an outgoing filter on Tunnel0. Remove it, or change the prefix list to permit 10.0.0.0/8 le 24, and verify R2 relearns the route. Undo debug with undebug all.

Quick check

Spokes on a DMVPN running EIGRP see the hub's LAN but not each other's. The hub sees all spokes. What is the most likely cause?

Split horizon is enabled on the hub's mGRE tunnel interface. Disable it with no ip split-horizon eigrp <as> (classic) or no split-horizon under the af-interface (named mode).

What is the difference between route poisoning and poison reverse?

Route poisoning is the originating router advertising a failed route with an infinite metric so neighbors remove it quickly. Poison reverse is a neighbor sending a route back toward the router it learned it from, marked as unreachable, which overrides split horizon to make the "do not use me" message explicit.

Why does tagging prevent redistribution loops that the routing protocols themselves cannot see?

When a route is redistributed it becomes a new external route in the receiving protocol, with no memory of its origin. A tag set at redistribution travels with the route, so another boundary router can recognise it and refuse to redistribute it back into the domain it came from.

References