A routing loop is a forwarding cycle, not merely a long or inefficient path
Routers normally make hop-by-hop forwarding decisions that move an IP packet toward its destination. A loop exists when those decisions form a cycle: one router forwards toward another, and a later router sends the same destination back into the earlier part of the path. The packet consumes resources without making progress.
This definition matters because high latency, packet loss, or a strange traceroute can occur without a loop. The strongest diagnosis combines a repeating path pattern with contradictory route decisions.
A repeated sequence of routers is more informative than one repeated address
1 10.10.1.1 2 10.20.0.1 3 10.30.0.1 4 10.20.0.1 5 10.30.0.1 6 10.20.0.1 7 10.30.0.1
The repeating 10.20.0.1 → 10.30.0.1 sequence is a strong clue that probes are cycling between the same Layer 3 forwarding points. One duplicated address would be weaker evidence because traceroute output can be affected by load balancing, response behavior, or how devices generate ICMP replies.
The next step is not “restart routing.” Inspect the selected route for the affected destination on the routers appearing in the cycle.
TTL limits the damage by forcing looping IP packets to expire
Each IPv4 router decrements the packet's Time To Live value. IPv6 uses Hop Limit for the same essential purpose. When the value reaches zero, the router discards the packet and may return ICMP Time Exceeded.
This prevents one looping packet from circulating forever. It also explains why a user may see timeouts while traceroute continues to reveal intermediate routers: each probe is intentionally sent with a different TTL so the path can be exposed hop by hop.
Router A and Router B explicitly send the same prefix back to each other
Affected destination: 10.50.8.25 Router A selected route: 10.50.8.0/24 via 192.0.2.2 → Router B Router B selected route: 10.50.8.0/24 via 192.0.2.1 → Router A
This is direct forwarding-plane contradiction. A sends the affected /24 to B, and B sends that same /24 back to A. Traceroute should be expected to alternate between those Layer 3 hops until TTL expires.
The smallest justified correction is the route or routing state that created the contradictory next-hop choices. Changing an unrelated metric elsewhere adds noise rather than information.
Compare the route each router actually selects for the affected destination
It is not enough to compare “a route to the network.” Routers use longest-prefix matching. A /24 can override a /16 summary, and either can override a default route. Therefore, the relevant question is: which prefix wins for this exact destination, and where does that selected entry forward next?
| Router | Candidate routes | Selected for 10.50.8.25 | Why |
|---|---|---|---|
| A | 10.50.0.0/16 via B; 0.0.0.0/0 via ISP | 10.50.0.0/16 via B | /16 is more specific than default |
| B | 10.50.8.0/24 via A; 10.50.0.0/16 via C | 10.50.8.0/24 via A | /24 is most specific |
Swipe horizontally to see the full table.
The apparent contradiction can therefore come from different route sources and different prefix lengths, not only identical static routes.
Two defaults can create a loop for destinations neither router knows specifically
Imagine Router A uses Router B as its default next hop, while Router B uses Router A as its default. A destination with no more-specific route will bounce between them. Known internal prefixes may still work normally, which can make the failure look selective.
This is why testing only one reachable network can miss the issue. Compare the failing destination against working prefixes and inspect the route that wins in each case.
Known internal networks work, but an unknown destination loops through reciprocal defaults
Router A has connected routes for local networks and a default route to B. Router B has other connected networks and a default route back to A. A client reaches known internal prefixes correctly, but traffic to an unknown external destination alternates A → B → A → B.
The failure is not “all routing is broken.” It is specifically the fallback path for unmatched destinations. The discriminating evidence is the default route on each router plus the traceroute cycle for a destination lacking a more-specific route.
A broad summary can attract traffic that another router sends back for a more specific destination
Summarization reduces route-table size, but a summary can also hide missing reachability. Suppose one router advertises 10.50.0.0/16 toward a neighbor while lacking a valid path to 10.50.8.0/24. If its fallback sends 10.50.8.0/24 back toward the neighbor, traffic can loop.
The key is to compare the summary with the more-specific route actually selected at each hop. The summary itself is not “bad”; the problem is the inconsistent forwarding chain it creates for the affected destination.
Temporary routing loops can appear while routers update after a topology change
Dynamic routing protocols do not always update every router at the exact same instant. After a failure or metric change, one router can temporarily act on newer information while another still uses older state. That inconsistency can create a transient loop.
The diagnostic distinction is duration and recovery. A loop that disappears as the routing domain converges may be transient. A loop that persists long after the network should have stabilized points toward configuration, redistribution, summarization, default-route, or protocol/design problems.
A topology failure produces a brief loop that disappears after convergence
A link fails between two routing domains. For several seconds, traceroute alternates between two routers, then the repeated pattern disappears and traffic takes a new stable path. Route logs show updates propagating during the same interval.
That evidence supports a transient convergence loop rather than a persistent static misconfiguration. The next question is whether the convergence behavior is acceptable for the design or whether protocol tuning/resiliency needs review. The absence of a continuing loop after stable routes are installed is important evidence.
Asterisks, path changes, and one repeated hop are not automatically routing loops
Missing replies
Devices may filter or rate-limit TTL-expired responses while still forwarding traffic.
Load balancing
Multiple paths can appear without any forwarding cycle.
Weak evidence
A single repeated address is weaker than a consistent repeating sequence.
Not specific
Congestion and long paths can raise delay without looping.
Not specific
Drops have many causes; TTL expiration must be tied to path evidence.
Needs context
Traceroute intentionally generates TTL expiration; the repeating path is what makes a loop suspicious.
A routing loop and a switching loop can both waste bandwidth, but their mechanisms are different
| Feature | Routing loop | Layer 2 switching loop |
|---|---|---|
| Layer | Layer 3 | Layer 2 |
| Data unit | IP packet | Ethernet frame |
| Lifetime limiter | TTL/Hop Limit | No equivalent IP TTL in the frame-switching process |
| Typical artifact | Repeated router sequence in traceroute | Broadcast amplification, MAC flapping, high switching load |
| Primary evidence | Route-table next-hop contradictions | Switching topology/MAC/STP evidence |
Swipe horizontally to see the full table.
Use Network Loop Broadcast Storm for the Layer 2 version.
Looping traffic can consume bandwidth and router resources without delivering useful work
Every cycle uses link capacity and forwarding resources. A small number of packets may simply expire with little visible network impact. Heavy looping traffic can contribute to congestion, higher latency, and drops on the links participating in the loop.
Performance degradation is therefore a consequence, not the defining proof. The routing loop itself is demonstrated by the forwarding cycle.
High latency and packet loss occur, but traceroute never repeats a cycle
A path shows high RTT and intermittent loss during peak use. Traceroute reaches the destination through a stable sequence of routers with no repeated cycle. Interface utilization rises sharply during the same period.
This is a counterexample: the user symptoms overlap with what a routing loop can cause, but the path evidence does not support looping. Congestion is a stronger branch because performance degradation correlates with load while the route chain still progresses normally.
Some symptoms support a routing loop far more strongly than others
| Observation | Diagnostic strength | What it means | Next evidence |
|---|---|---|---|
| High latency | Weak | Path is slow | Traceroute and utilization |
| Packet loss | Weak | Packets are not all delivered | TTL/path/drop evidence |
| Repeated traceroute sequence | Strong | Probes appear to revisit same Layer 3 cycle | Route tables on repeated routers |
| A→B and B→A exact-prefix routes | Very strong | Forwarding contradiction directly forms loop | Identify route source/configuration |
| ICMP Time Exceeded from loop routers | Supporting | TTL expires while cycling | Correlate with repeating path |
Swipe horizontally to see the full table.
Destination → repeating path → exact-prefix routes → route source → correction → verification
- Identify the exact failing destination or prefix.
- Capture traceroute and look for a repeating router sequence, not merely asterisks.
- List the routers participating in the suspected cycle.
- On each router, inspect the selected route for the exact affected destination.
- Record next hop, outgoing interface, prefix length, and route source.
- Check defaults, summaries, redistribution, stale routes, and dynamic-protocol state as applicable.
- Correct the route state that creates the cycle.
- Rerun traceroute and confirm the path progresses toward the destination.
- Test a neighboring prefix so valid reachability was not removed broadly.
For broader route interpretation, use Routing in AP Networking.
The route source often explains why the contradiction exists
A static route may point to an outdated next hop. A default route may be reciprocal. A summary may attract traffic without a valid more-specific path. Redistribution may reintroduce a route into the protocol it originated from. A dynamic route may be temporarily stale during convergence.
The corrective action should match the mechanism. Removing random routes until the loop disappears can also remove legitimate reachability. First identify which selected entry causes the circular forwarding decision and why that entry exists.
A fixed traceroute is necessary, but routing-table evidence should also show the cycle is gone
After the change, rerun the same traceroute to the same destination and confirm the repeated sequence disappears. Then inspect the previously looping routers and verify their selected routes now move traffic toward the destination instead of back toward one another.
Finally, test the original destination and at least one related or neighboring prefix. This catches repairs that stop the loop simply by deleting reachability too broadly.
A routing protocol can appear healthy while the installed forwarding decision is still wrong
Routing protocols exchange reachability information, but packets are forwarded according to the route that is actually selected and installed for the destination. That distinction matters during loop diagnosis. A neighbor relationship being “up” does not prove the chosen next hop is correct, and a routing table that contains several possible paths does not tell you which one wins until prefix length, administrative preference, metric, and platform rules are considered.
For the affected destination, compare the selected forwarding entry on each router in the repeated traceroute sequence. If the control-plane view and forwarding behavior disagree, investigate which route is installed, whether stale state remains, and whether policy or redistribution changes the effective path. The packet follows the forwarding decision, not the administrator's intended topology diagram.
A routing loop can involve more than two routers
The easiest example is A → B → A, but real loops can involve three or more forwarding points. A traceroute such as R2 → R5 → R7 → R2 → R5 → R7 shows a three-router cycle. The diagnostic method is unchanged: write the repeating sequence, inspect the selected route for the exact destination on each participant, and identify the next-hop relationship that closes the cycle.
Do not stop after finding the first suspicious router. A loop is a chain of decisions, so the useful artifact is the entire cycle. This prevents a partial fix that moves the loop rather than eliminating it.
A routing loop may affect one prefix while nearby destinations continue to work
Because routers select routes by prefix, a loop can be narrowly scoped. Traffic to 10.50.8.0/24 may cycle while 10.50.9.0/24 follows a correct, more-specific path. A broad “the network is down” description can therefore hide the evidence needed to find the faulty route.
Compare one failing destination with a nearby working destination and record which route wins for each on the suspected routers. That differential comparison can expose a bad static route, summary interaction, or redistributed prefix much faster than testing random hosts.
24 routing-loop evidence flashcards
Practice traceroute patterns, TTL, exact-prefix route analysis, defaults, summaries, convergence, Layer 2 versus Layer 3 distinctions, counterexamples, and verification.
Build the answer as path observation → route contradiction → mechanism → correction → verification
Observation: traceroute alternates between Router A and Router B until TTL expires. Route evidence: A sends 10.50.8.0/24 to B, while B sends the same /24 back to A. Mechanism: each router's selected next hop re-enters the same forwarding cycle. Correction: fix the route source creating one side of the contradiction. Verification: rerun traceroute, confirm the repeated sequence is gone, verify both routing tables progress toward the destination, and test a neighboring prefix to confirm valid reachability remains.
Connect routing loops to route analysis, CLI evidence, troubleshooting, and Layer 2 loop diagnosis
Use Routing in AP Networking for forwarding logic, Network CLI Output Practice for route/traceroute artifacts, AP Networking Troubleshooting Guide for evidence-first diagnosis, and Network Loop Broadcast Storm to compare Layer 2 loop behavior.