101
0/228
Loading content...
Imagine packets bouncing endlessly between routers, never reaching their destination, consuming bandwidth and processing power until their TTL expires. This is a routing loop—one of the most dangerous failure modes in network routing.
Routing loops occur when routers have inconsistent views of the network, causing packets to be forwarded in circles. In early routing protocols, these loops were common during convergence, sometimes taking minutes to resolve while network performance degraded catastrophically.
Path vector routing solves this problem definitively. By including the complete AS path in every route advertisement, path vector protocols provide mathematically guaranteed loop prevention—not through timers, hop counts, or heuristics, but through a simple, elegant rule: if your own AS number appears in the path, the route is invalid.
By the end of this page, you will understand what causes routing loops, how distance vector protocols attempt to prevent them (and why those approaches are imperfect), how path vector's AS path check provides absolute loop prevention, and the implications of this guarantee for internet routing stability.
Before understanding how path vector routing prevents loops, we must first understand how loops form. A routing loop occurs when a packet enters a cycle of routers, each believing the next router is closer to the destination.
The Basic Mechanism:
Consider three routers A, B, and C attempting to reach network X:
Now suppose the link between C and X fails:
Why Loops Form:
Routing loops are fundamentally caused by stale information. The routing table entries are based on advertisements that were accurate when sent but became invalid due to topology changes. The problem compounds in distributed systems where:
During the window between a failure and complete convergence, routers have inconsistent views. This inconsistency creates the opportunity for loops.
Loop Characteristics:
| Aspect | Impact | Severity |
|---|---|---|
| Packet Loss | Packets loop until TTL expires | High |
| Bandwidth Waste | Looping packets consume capacity | Medium-High |
| CPU Overhead | Routers process same packets repeatedly | Medium |
| Latency | Legitimate traffic delayed by congestion | Medium |
| Cascading Failures | Loops can destabilize adjacent networks | High |
IP's Time-to-Live (TTL) field exists specifically to limit loop damage. Each router decrements TTL by 1; when it reaches 0, the packet is discarded. But this is a safety net, not a solution. Loops still cause congestion and packet loss until TTL expires—typically 30-64 hops of wasted forwarding.
Distance vector protocols like RIP employ several techniques to prevent and mitigate routing loops. While none of these techniques provides absolute prevention, understanding them illustrates why path vector's approach is superior.
1. Maximum Hop Count:
RIP defines a maximum hop count of 15; 16 means "unreachable." This prevents infinite counting but:
2. Split Horizon:
A router never advertises a route back to the interface from which it was learned. If B learned the route to X from C, B won't advertise that route back to C.
Without Split Horizon: With Split Horizon:
C→B: X via C (cost 1) C→B: X via C (cost 1)
B→C: X via C (cost 2) ✗ B→C: (no advertisement) ✓
This prevents simple two-router loops but fails for larger topologies.
3. Poison Reverse:
An enhancement to split horizon: instead of not advertising, the router advertises the route with infinite cost (poison) back to the source.
Poison Reverse:
C→B: X via C (cost 1)
B→C: X via C (cost ∞) ← Explicitly poisoned
This is more explicit than split horizon but has the same topology limitations.
4. Triggered Updates:
Rather than waiting for periodic updates (every 30 seconds in RIP), routers immediately send updates when routes change. This accelerates convergence but doesn't prevent loops—it just shortens the window.
5. Hold-Down Timers:
When a route is marked unreachable, the router ignores any new information about that route for a hold-down period (180 seconds in RIP). This prevents premature acceptance of stale routes but:
| Technique | How It Works | Limitation | Loop Prevention Level |
|---|---|---|---|
| Max Hop Count | Cost capped at 16 | Limits network size, loops persist until cap | Partial |
| Split Horizon | Don't advertise route to source | Fails in complex topologies | Partial |
| Poison Reverse | Advertise infinite cost to source | Same topology limitations | Partial |
| Triggered Updates | Immediate updates on changes | Faster but not preventive | Minimal |
| Hold-Down Timers | Ignore updates during hold-down | Very slow convergence | Moderate |
The classic example is the 'count-to-infinity' problem. When a destination becomes unreachable, routers slowly increment their cost metrics while learning 'better' routes from neighbors who haven't yet converged. The count continues until the maximum is reached. With RIP's 30-second update interval and maximum hop of 16, this can take up to 8 minutes—an eternity in network time.
Path vector routing eliminates routing loops through a fundamentally different approach: complete path visibility. Rather than inferring the path from cost metrics, path vector protocols include the entire AS path in every advertisement.
The Simple Rule:
If a router's own AS number appears anywhere in the AS path of an incoming route advertisement, that route is rejected.
This rule is elegant, absolute, and computationally trivial. Let's see why it works:
Proof by Contradiction:
Suppose a loop could form in a path vector network. For a packet to loop, it must return to an AS it has already traversed. But:
This is not a heuristic—it's a mathematical guarantee.
Immediate Detection:
Unlike distance vector's gradual count-to-infinity, path vector loop detection is instantaneous. The moment a route advertisement arrives, the receiving router checks for its own ASN:
Incoming: 192.0.2.0/24, AS_PATH: 65010 65020 65001 65030
AS 65001 check:
- Is 65001 in path? → YES (position 3)
- Action: REJECT immediately
- Reason: Loop detected
No timers. No counting. No propagation delay. The loop is prevented before it can form.
What This Means for Operations:
| Aspect | Distance Vector | Path Vector |
|---|---|---|
| Loop Detection | After loop forms | Before route accepted |
| Prevention Certainty | Probabilistic | Guaranteed |
| Convergence Impact | Slow (count-to-infinity) | Fast (immediate rejection) |
| Network Stability | Degrades during convergence | Stable throughout |
| Operator Intervention | Sometimes required | Rarely needed |
The internet contains 70,000+ autonomous systems with millions of routing paths. Any probabilistic loop prevention mechanism would inevitably fail at this scale. Path vector's guarantee is what makes global BGP routing feasible—operators can trust that route advertisements, however they arrive, will not create loops within the AS path check framework.
Understanding how BGP implementations perform the AS path loop check reveals the efficiency of this mechanism. The check is performed during UPDATE message processing, before any route is considered for selection.
The Checking Process:
Step 1: Parse AS_PATH Attribute The AS_PATH is parsed into segments (AS_SEQUENCE and AS_SET). Each segment is examined separately.
Step 2: Compare Against Local ASN For each ASN in the path (whether in AS_SEQUENCE or AS_SET), compare against the local BGP router's configured ASN.
Step 3: Take Action on Match If the local ASN is found:
1234567891011121314151617181920212223242526272829303132333435363738394041
def check_as_path_loop(update_message, local_asn): """ Check if the incoming BGP UPDATE would create a routing loop. Returns True if route should be rejected (loop detected). """ as_path = update_message.get_as_path() for segment in as_path.segments: if segment.type == AS_SEQUENCE: # Ordered sequence - check each ASN in order for asn in segment.asns: if asn == local_asn: log.info(f"Loop detected: local ASN {local_asn} in AS_SEQUENCE") return True # Reject route elif segment.type == AS_SET: # Unordered set - check if our ASN is a member if local_asn in segment.asns: log.info(f"Loop detected: local ASN {local_asn} in AS_SET") return True # Reject route return False # No loop, route can be processed def process_bgp_update(update, local_asn, rib): """ Main UPDATE processing with loop check as first step. """ # Step 1: Loop check (MUST be first) if check_as_path_loop(update, local_asn): stats.increment("updates_rejected_loop") return # Stop processing immediately # Step 2: Other validation (if loop check passed) if not validate_update(update): return # Step 3: Path selection best_path = select_best_path(update, rib) # Step 4: Install in RIB rib.install(best_path)Performance Characteristics:
The AS path loop check is highly efficient:
This efficiency is crucial because BGP routers in major networks may process thousands of route updates per second during convergence events. The loop check adds virtually no overhead.
Cannot Be Disabled:
A critical operational note: the AS path loop check is mandatory per RFC 4271 (the BGP specification). Unlike most BGP behaviors that can be tuned or disabled, no conforming implementation allows disabling this check. This is not a limitation—it's a feature. Loop prevention is too important to leave to operator discretion.
There is one scenario where operators intentionally allow their own ASN in paths: hub-and-spoke VPN topologies where the same AS is used at multiple sites. BGP implementations provide 'allowas-in' configuration that permits a limited number of occurrences of the local ASN. This is an explicit override with configurable limits, not a removal of loop protection.
While the AS path check provides definitive loop prevention for inter-AS (eBGP) routing, internal BGP (iBGP) presents a different challenge. iBGP does not modify the AS path, so the standard loop check cannot prevent internal loops.
The iBGP Problem:
Within an autonomous system, all BGP routers share the same ASN. When a router receives a route via iBGP:
Example Scenario:
AS 65001 Internal Topology:
R1 ──iBGP── R2
│ │
eBGP iBGP
│ │
R3 ──iBGP── R4
If R1 learns an external route and advertises to R2, R2 cannot advertise it to R4 via iBGP (split horizon). But what if there's a complex topology with multiple reflection layers?
Solution 1: Full Mesh iBGP:
The traditional iBGP solution is a full mesh—every iBGP router peers with every other iBGP router. This ensures:
Full Mesh Limitations:
Solution 2: Route Reflectors:
Route reflectors (RRs) break the split horizon rule in a controlled way:
Loop Prevention via CLUSTER_LIST:
- Each RR adds its CLUSTER_ID to the CLUSTER_LIST
- If a route arrives with local CLUSTER_ID in list → reject
- Same principle as AS path, but for internal clusters
| Mechanism | How It Prevents Loops | Scalability | Complexity |
|---|---|---|---|
| Split Horizon | Don't advertise iBGP-learned routes to iBGP peers | Poor (requires full mesh) | Low |
| Full Mesh | Direct peering eliminates forwarding decisions | O(n²) sessions | Moderate |
| Route Reflectors | CLUSTER_LIST check prevents RR loops | O(n) sessions | Moderate |
| ORIGINATOR_ID | Identifies original advertiser; reject if local | N/A (used with RR) | Low |
| Confederations | Sub-AS structure with inter-confederation eBGP | Moderate | High |
When route reflectors are used, the ORIGINATOR_ID attribute identifies the router that originally introduced the route to iBGP. If a router receives a route with its own router ID as the ORIGINATOR_ID, it rejects the route—preventing a different kind of loop where routes reflect back to their source.
Solution 3: Confederations:
BGP confederations divide a large AS into smaller "sub-ASNs" that use eBGP-like behavior internally:
Confederations provide:
Hierarchy of iBGP Loop Prevention:
1. Split Horizon (base rule)
↓ Still need reachability...
2. Full Mesh (simple but doesn't scale)
↓ Too many sessions...
3. Route Reflectors (most common)
↓ Very large networks...
4. Confederations (enterprise-scale)
While path vector routing provides robust loop prevention, several edge cases and misconfigurations can create problematic scenarios. Understanding these helps operators avoid pitfalls.
Misconfiguration: AllowAS-In Abuse:
The allowas-in feature exists for legitimate hub-and-spoke scenarios, but misconfiguration can create loops:
Router A (AS 65001) → Router B (AS 65001) → Router C (AS 65001)
↓
allowas-in 3
If allowas-in is set too high, routes can circulate through multiple sites with the same ASN before being rejected. Each pass through the topology adds latency and complexity.
Best Practice: Use allowas-in only where necessary, set the limit as low as possible (typically 1-2), and document the specific topology requirement.
AS_SET Aggregation Risks:
When routes are aggregated, the AS paths may be combined into an AS_SET:
Original routes:
192.0.2.0/25: AS_PATH 65001 65010
192.0.2.128/25: AS_PATH 65001 65020
Aggregated route:
192.0.2.0/24: AS_PATH 65001 {65010, 65020}
The AS_SET {65010, 65020} loses ordering information. Loop detection still works (if 65010 receives this route, it sees itself in the set), but:
Route Origin Validation (RPKI) Complements:
RPKI validates route origins but doesn't replace AS path loop prevention:
| Mechanism | What It Prevents | Limitation |
|---|---|---|
| AS Path Check | Routing loops | Doesn't verify BGP path authenticity |
| RPKI/ROA | Unauthorized origin announcements | Doesn't validate full path |
| BGPsec | Path manipulation attacks | Requires universal deployment |
These mechanisms are complementary—AS path loop prevention is necessary but not sufficient for complete routing security.
Private ASNs (64512-65534, 4200000000-4294967294) should never appear in routes advertised to the public internet. When they do (through misconfiguration), multiple networks may inadvertently share the same ASN, undermining loop prevention. Always configure 'remove-private-as' on eBGP sessions to public peers.
Forwarding Loops vs Routing Loops:
It's important to distinguish between two types of loops:
Routing Loops (Prevented by AS Path):
Forwarding Loops (Different Problem):
AS path loop prevention addresses routing loops definitively. Forwarding loops require separate mechanisms.
Having examined various loop prevention mechanisms, let's consolidate the comparison between distance vector, link state, and path vector approaches.
The Fundamental Tradeoff:
Each routing paradigm makes different tradeoffs between information sharing and computational complexity:
Link State Comparison:
Link state protocols (OSPF, IS-IS) achieve loop-free routing through a different mechanism: full topology knowledge. Every router computes identical shortest-path trees, ensuring consistent forwarding decisions.
| Aspect | Link State | Path Vector |
|---|---|---|
| Loop Prevention | Identical SPF results | AS path check |
| Scalability | Limited by topology size | Scales to internet level |
| Information Shared | Complete topology | AS path + attributes |
| Computation | Full SPF per router | Incremental path selection |
| Use Case | Intra-domain (IGP) | Inter-domain (EGP) |
| Trust Model | Within administrative domain | Across trust boundaries |
Link state and path vector serve different roles: link state for efficient routing within an organization, path vector for policy-rich routing between organizations.
Link state requires every router to know the complete topology—impractical for 950,000+ prefixes and millions of links. Path vector's abstraction (ASNs, not individual routers) is essential for scalability. Additionally, link state doesn't support the policy controls needed when traffic crosses organizational boundaries.
Loop prevention is fundamental to stable routing, and path vector's approach represents the gold standard for inter-domain environments. The simple rule—reject routes containing your own ASN—provides mathematical guarantees that probabilistic mechanisms cannot match.
Key Concepts Mastered:
What's Next:
Loop prevention is one application of path information's power. The next page explores policy routing—how operators use AS path visibility to implement sophisticated traffic engineering, prefer certain transit providers, avoid specific networks, and align routing decisions with business relationships.
You now understand how path vector routing achieves guaranteed loop prevention, why this is superior to distance vector approaches, and how the mechanism extends to iBGP scenarios. This foundation is essential for understanding BGP's role in maintaining internet stability.