Routing Loop¶
A destination-specific cycle in installed router next hops that permits a packet to revisit a router instead of reaching its destination.
Core Idea¶
A routing loop exists when the installed forwarding choices for one destination or prefix send a packet through a directed cycle of routers. A router's chosen next hop points to another router whose choice eventually points back to one already visited, rather than onward to the destination. The operational consequence is that a packet following those choices can revisit a router. An observed packet trace is useful evidence, but the loop can be identified from the forwarding state before any particular packet is captured.[1][2]
The cycle is specific to the destination and moment examined. Its identity does not require one routing protocol, one initiating link failure, a fixed duration, or repeated circulation until the packet disappears. A time-to-live or hop-limit expiry can stop a packet without changing the installed next hops that caused the loop.[3]
Structural Signature¶
One destination or prefix → installed next-hop choices → cyclic closure → possible packet revisit.
- Destination or prefix. Hold the target fixed. A router can choose different next hops for different targets; combining them into one drawing can create a cycle that no packet actually follows.
- Installed next-hop choices. Inspect the forwarding decisions in effect at the relevant time. Physical adjacency or an advertised route alone does not establish that a packet will use that link.[3]
- Cyclic closure. Trace the successor choices. A sequence such as A→B→C→A closes for the same destination; a path that exits toward the destination does not.
- Possible packet revisit. The closed choices give a packet for that destination a route back to a router it already passed. Packet lifetime and other forwarding behavior may bound an individual traversal, but do not remove the state relation.[1][2]
Stale information, asynchronous updates, split horizon, local convergence delay, and count-to-infinity behavior may matter in particular protocols. They are causes, limits, or responses, not additional roles required in every loop.
What It Is Not¶
- Not a physical ring. Cables can form a ring while the installed route for the target follows an acyclic path.
- Not every delivery failure. A packet dropped along an acyclic path did not revisit a router by virtue of a forwarding cycle.
- Not a cycle assembled across different destinations. A→B for one prefix and B→A for another do not establish a two-router loop for either packet.
- Not merely a control-plane advertisement. The claim concerns the forwarding choices that are installed and applied to traffic, although advertisements may help explain how they arose.[3]
- Not a Layer-2 broadcast condition. Such a condition does not, by itself, establish installed router next-hop choices that close for one IP destination.
Scope of Application¶
The identity applies to destination-based packet forwarding in different routing settings. RFC 2453 presents a possible three-router RIP route cycle; RFC 8333 presents a conditional two-router loop during link-state interior-gateway-protocol convergence. They use different route-computation and update mechanisms, yet both can leave installed next-hop choices closing for one target.[1][2]
A microloop is a transient routing-loop subtype associated with inconsistent forwarding information while a network converges. It does not define the whole category: cyclic forwarding can also persist until configuration or routing state changes. The distinction between transient and persistent concerns duration and cause, not whether the per-destination cycle exists.[3]
Clarity¶
To diagnose a suspected loop, specify the destination, the time, and each router's actually installed next hop. Then trace the successor relation. This separates three evidence surfaces: a protocol's advertised or computed route, the forwarding entries in effect, and packets observed on the wire. A source may show a possible configuration without reporting a field incident or trace.[1][2][3]
The S/B case in RFC 8333 makes the timing explicit. Following failure of the direct S–D link in its worked topology, S may install B as its new next hop for D before B replaces its old next hop S. During that interval, a packet for D can bounce between S and B. Reverse the update order or change one of the entries, and that particular conditional cycle is absent.[2]
Manages Complexity¶
Real routing failures involve link metrics, advertisements, forwarding tables, timers, and packet behavior. The loop abstraction first reduces them to a target-specific successor relation. That compact view answers the recognition question: does following installed choices return to a router already in the path? The protocol details then return when explaining how the cycle formed and what could resolve it.[1][2]
This separation prevents a familiar symptom from standing in for a cause. Packet loss may accompany a loop, but also many acyclic faults. A hop-limit expiry limits a single packet but leaves the route state untouched. Count-to-infinity belongs to the RIP-style case; it is not an explanation for every link-state microloop.[1][3]
Abstract Reasoning¶
For a fixed destination D, let each participating router's forwarding entry identify its next router at one time. Starting at A, repeatedly follow the installed next hop. If the sequence reaches D or exits the examined set without repetition, that sequence does not demonstrate a loop. If it revisits A or another earlier router before reaching D, the repeated segment is a directed forwarding cycle. This reasoning uses the router decisions, not the shape of the physical network.[1][2]
Apply the counterfactual to RFC 8333's worked state: new S→B paired with old B→S closes the two-router relation for D. If B has already changed its entry away from S, that closure vanishes. The test identifies a conditional state, not a claim that every failure of an S–D link produces a loop or that a specified delay fixes all convergence failures.[2]
Knowledge Transfer¶
The same destination-specific closure test works for the RIP example and the link-state example. What transfers is the role map: fixed target, installed successors, closed path, and possible packet return. What does not transfer automatically is the explanation. RIP's split-horizon and metric behavior and the link-state example's ordering of forwarding updates address different route dynamics.[1][2]
The abstract notion of a directed cycle is broader still. A dependency cycle in a project or a graph-theory self-edge can be cyclic without routers, destination-specific forwarding, or packets. Those cases share closure, not the full identity of a routing loop.
Examples¶
Possible three-router RIP cycle¶
RFC 2453 describes a possible route pattern for one destination: A routes through B, B through C, and C through A. The destination is held fixed; A→B, B→C, and C→A are the next-hop choices; those choices close; and a packet using them can return to A. The RFC uses the pattern to explain why split horizon alone does not solve every multi-router loop. It does not report a captured packet trace or a measured outage in this passage.[1]
Conditional link-state microloop¶
In RFC 8333's Figure 1, the direct S–D link fails. If S updates its forwarding choice for D to B before B changes its old choice of S, the installed pair is S→B→S. The destination is D; the two entries are the next-hop choices; they close; and packets for D can revisit S while the mismatch persists. This is a conditional worked topology, not a claim that the order occurred in a measured production network.[2]
Near miss: ring topology with an acyclic route¶
Suppose physical links connect A–B–C–A, but for destination D the installed choices are A→B→C→D; C does not use its physical link to A for that target. Physical connectivity closes, yet the forwarding path does not. Changing C's next hop for the same D to A would create the missing cyclic closure. This constructed comparison isolates the role of installed forwarding state; it is not a third reported RFC incident.
Structural Tensions¶
The cited cases establish a harmful forwarding configuration, not a universal trade-off constitutive of every loop. Protocol designers may trade convergence speed against local loop-prevention measures in a particular setting, but that design question does not define the loop itself. The stable diagnostic is whether the installed next-hop choices close for a destination at the time under examination.[2][3]
Structural–Framed Character¶
The pattern is predominantly structural within network forwarding: once destination and installed entries are fixed, cyclic closure and possible packet revisit are inspectable relations. The term loop carries mild negative weight because it blocks intended delivery, but the finding does not depend on an evaluator's taste. RFCs describe examples and remedies; their institutional status does not make a cycle exist. Networks are human-designed systems, while the next-hop relation and packet return follow operational rules rather than a social judgment.[1][2]
The vocabulary of directed cycles travels widely, but destination, router, forwarding entry, and packet do not travel literally to every cyclic system. An analyst recognizes a loop by tracing the installed choices; calling an unrelated repetitive process a “routing loop” imports a metaphor. Its character: a structural failure relation whose exact carrier and consequence keep it domain-specific.
Structural Core vs. Domain Accent¶
Its portable core is directed closure: following successors can return to an earlier point. Generic Cycle names a wider structural idea, but shared closure alone does not import every feature of that concept. The domain differentia is a fixed destination, operational next-hop state, and packet-forwarding meaning. Remove those and one may still have a cycle, but no longer a routing loop.
A more general “failure to make progress because of cyclic choices” could be investigated across domains if independent cases preserved the same functional roles. The two RFC cases establish transfer across routing protocols, not a new cross-domain Prime.
Instantiates / Related Primes¶
This entry presupposes Relation.
The prerequisite Relation is the binary association between routers established by installed next-hop entries for one destination at one time. Its composition makes the return path test possible. That association can be acyclic; the routing loop is the failure configuration in which it closes, not a kind of Relation. Cycle shares directed closure, but its full live signature makes broader loop-invariant and sign-or-gain commitments that the cited routing cases do not establish. Routing concerns the selection and maintenance of paths rather than the cyclic forwarding state itself. Link-state Routing supplies the method in the second example, while the RIP example shows that method is not required.[1][2]
Packet Switching supplies a broader traffic setting, yet packet switching alone does not make next-hop choices close. Broadcast Storm names a different traffic phenomenon; its name alone does not establish the destination-specific IP forwarding relation here. These neighbors help locate the failure without replacing its four-role test.
Relationships to Other Abstractions¶
Current abstraction Routing Loop Domain-specific
Parents (1) — more general patterns this builds on
-
Routing Loop presupposes Relation Prime
A routing loop presupposes a destination-specific installed next-hop relation whose composition closes back to a router.Fixing destination and time gives router relata, binary next-hop membership determined by installed forwarding entries, and relation composition that tests successive hops. Without that association there are no specified successor choices to close; the relation can exist with acyclic choices. A routing loop is a failure configuration of the relation, not a kind of Relation or a constituent inside every relation.
Hierarchy path (1) — routes to 1 parentless root
- Routing Loop → Relation
Neighborhood in Abstraction Space¶
Routing Loop sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Administrative Distance — 0.76
- In-Place Adjacent-Block Rotation — 0.76
- A-star algorithm — 0.76
- Floyd's Cycle-Finding Algorithm — 0.76
- Hop-by-hop transport — 0.75
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
A graph-theory self-loop is an edge from a node to itself, while the cited routing cycles involve distinct routers; generic Cycle is broader than network forwarding. A physical network ring is also broader than the selected route through it. A packet's TTL or hop-limit exhaustion is a possible effect that ends the packet's travel, not a repair of the forwarding entries. Split horizon, triggered updates, or local convergence delays address scoped cases; none belongs in the definition of every routing loop.[1][2][3]
References¶
[1] Gary Malkin, RFC 2453, “RIP Version 2” (1998), especially §3.4.4. Official Standards Track RFC; its three-router loop is a possible route pattern, not an observed incident. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l
[2] Stéphane Litkowski, Bruno Decraene, Clarence Filsfils, and Pierre Francois, “Micro-loop Prevention by Introducing a Local Convergence Delay,” RFC 8333 (2018), especially §1 Figure 1 and §6. https://www.rfc-editor.org/rfc/rfc8333.html. Official RFC; the S/B loop is conditional on forwarding update order. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n
[3] Mike Shand and Stewart Bryant, “A Framework for Loop-Free Convergence,” RFC 5715 (2010), especially §2. https://www.rfc-editor.org/rfc/rfc5715.html. Official Informational RFC; its discussion of transient microloops does not make every routing loop transient. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h