Loading learning content...
Throughout the history of computer networking, three fundamental approaches to routing have emerged: distance vector, link state, and path vector. Each represents a different philosophy for solving the same core problem: how do routers discover paths to destinations and share that information to enable packet forwarding?
These paradigms aren't competing alternatives—they're complementary solutions optimized for different scenarios. Modern networks typically employ all three: distance vector for simplicity, link state for intra-domain efficiency, and path vector for inter-domain policy and scale.
This page provides a comprehensive comparison, analyzing the strengths, weaknesses, and appropriate applications of each paradigm. By understanding these tradeoffs, you'll be equipped to select and deploy the right routing approach for any network scenario.
By the end of this page, you will understand the fundamental differences between distance vector, link state, and path vector routing; the strengths and weaknesses of each paradigm; how to select the appropriate routing approach for different scenarios; why modern networks use multiple paradigms simultaneously; and the evolutionary trajectory of routing protocol development.
Before diving into detailed comparisons, let's establish a clear understanding of what each paradigm fundamentally does differently.
Distance Vector: "I know costs, not paths"
Distance vector routers share their distance (cost metric) to each destination. Routers advertise: "I can reach network X with cost Y." Neighbors add their own cost and propagate the information further.
Link State: "I know everything about the topology"
Link state routers share their local view of directly connected networks. Each router floods information about its links, enabling every router to build a complete topology map and independently calculate optimal paths.
Path Vector: "I know the complete path"
Path vector routers share the full sequence of autonomous systems (or domains) traversed to reach each destination. This enables loop prevention, policy decisions, and path-based filtering.
| Characteristic | Distance Vector | Link State | Path Vector |
|---|---|---|---|
| Information Type | Cost to destination | Local link topology | Full AS path + attributes |
| Topology Knowledge | None (just neighbors) | Complete (all routers) | AS-level (abstracted) |
| Algorithm | Bellman-Ford | Dijkstra (SPF) | Path selection hierarchy |
| Loop Prevention | Probabilistic (mitigations) | Guaranteed (consistent SPF) | Guaranteed (AS path check) |
| Policy Support | Minimal (metric only) | Limited (cost manipulation) | Extensive (attributes, communities) |
| Scalability | Limited | Moderate (within area) | Internet-scale |
| Convergence Speed | Slow | Fast | Deliberate (stability focus) |
The fundamental difference between routing paradigms lies in what information routers share. This choice cascades into every other characteristic—loop prevention, policy support, scalability, and convergence behavior.
Distance Vector Information:
Routers share routing table entries—what they believe about network reachability:
Distance Vector Advertisement:
Network Next Hop Metric
10.1.0.0 direct 0
10.2.0.0 Router B 3
10.3.0.0 Router B 5
10.4.0.0 Router C 2
This is economical but opaque. The receiver knows the advertiser can reach 10.3.0.0 with cost 5, but not how—the path is invisible.
Link State Information:
Routers share Link State Advertisements (LSAs) describing only their direct connections:
Link State Advertisement (Router A):
Router ID: 1.1.1.1
Links:
To: 2.2.2.2 (Router B) Cost: 10 Type: Point-to-Point
To: 10.1.0.0/24 Cost: 1 Type: Stub Network
To: 3.3.3.3 (Router C) Cost: 5 Type: Point-to-Point
Every router floods its LSA; every router builds the complete topology; every router runs SPF independently but arrives at consistent results.
Path Vector Information:
Routers share path + attributes—destinations with the complete AS sequence:
Path Vector Advertisement (BGP UPDATE):
NLRI: 192.0.2.0/24
AS_PATH: 65001 65010 65020
NEXT_HOP: 192.168.1.1
ORIGIN: IGP
LOCAL_PREF: 100
COMMUNITY: 65001:100 65001:200
This is more verbose than distance vector but provides crucial visibility. The receiver knows not just that the destination is reachable, but exactly which autonomous systems traffic will traverse.
Information Density Comparison:
| Paradigm | Information per Route | Overhead | Visibility |
|---|---|---|---|
| Distance Vector | ~8-12 bytes | Low | No path visibility |
| Link State | Entire LSA database | High initially, incremental updates | Complete topology |
| Path Vector | ~50-200 bytes per route | Moderate | Full AS path + attributes |
Path vector's verbosity is intentional. The additional bytes per route enable: loop prevention (AS path check), policy routing (path inspection), debugging (immediate path visibility), and trust boundaries (know whose networks you transit). At internet scale with ~1M prefixes, this is acceptable overhead for the capabilities gained.
Loop prevention is a critical differentiator between paradigms. The approach each takes determines reliability during network convergence and impacts network stability.
Distance Vector: Probabilistic Mitigation
Without path visibility, distance vector protocols cannot detect loops proactively. They rely on mitigations to reduce loop probability and duration:
These techniques reduce loop severity but don't eliminate loops. During convergence, loops can still form and persist until timers expire or metrics reach maximum.
Link State: Structural Guarantee
Link state protocols achieve loop-free routing through consistency. Since all routers have identical topology databases and run the same SPF algorithm:
Loops can only occur if the database is inconsistent (during brief flooding intervals). This is rare and quickly resolved.
Path Vector: Immediate Detection
Path vector provides the strongest loop prevention guarantee:
AS Path Check:
Incoming route: 10.0.0.0/8, AS_PATH: 65002 65003 65001 65004
Local ASN: 65001
Check: Is 65001 in the path?
Result: YES (position 3)
Action: REJECT immediately
No loop can form because the route is never installed.
This check is:
| Mechanism | Paradigm | Prevention Level | Impact on Convergence |
|---|---|---|---|
| Split Horizon | Distance Vector | Partial (2-node loops) | None |
| Poison Reverse | Distance Vector | Partial (2-node loops) | None |
| Hold-Down Timers | Distance Vector | Moderate | Significant slowdown |
| Max Hop Count | Distance Vector | Limit duration only | Network diameter limit |
| Consistent SPF | Link State | Guaranteed (if consistent) | Fast convergence |
| AS Path Check | Path Vector | Guaranteed (absolute) | No negative impact |
Routing loops don't just waste bandwidth—they cause packet loss, increase latency, and can trigger cascading failures. At internet scale, even probabilistic loop occurrence is unacceptable. This is why BGP (path vector) dominates inter-domain routing: the guarantee is essential, not optional.
How quickly a network adapts to topology changes—convergence—varies dramatically across paradigms. The design goals differ: IGPs optimize for speed within a single organization, while BGP prioritizes stability across the global internet.
Distance Vector Convergence:
RIP exemplifies distance vector convergence behavior:
RIP Timers (RFC 2453):
Update: 30 seconds (periodic full table)
Invalid: 180 seconds (route becomes invalid)
Flush: 240 seconds (route removed from table)
Hold-Down: 180 seconds (ignore updates for failed route)
Worst case: A route failure can take 4-8 minutes to fully converge due to count-to-infinity and hold-down timers.
EIGRP improves this with triggered updates and feasibility successors, achieving sub-second convergence in many cases. But it's still fundamentally limited by the distance vector lack of topology visibility.
Link State Convergence:
OSPF and IS-IS achieve rapid convergence:
OSPF Convergence Timeline:
0 ms: Link failure detected (BFD or interface)
10-50 ms: LSA generated with new topology
50-100 ms: LSA flooded throughout area
100-500 ms: All routers complete SPF calculation
500-1000 ms: Routing table updated, convergence complete
Total: Sub-second convergence is common
Link state's speed comes from:
Path Vector Convergence:
BGP deliberately converges slowly:
BGP Convergence Timeline:
0 s: Peer failure
30-90 s: Hold timer expires, session declared dead
0-30 s: If BFD enabled, sub-second detection
1-5 min: Withdrawal propagates globally
3-10 min: Alternative paths converge worldwide
Total: Minutes for global convergence (by design)
| Protocol Type | Failure Detection | Local Convergence | Network-Wide Convergence |
|---|---|---|---|
| RIP (Distance Vector) | 30-180 seconds | 30-180 seconds | Minutes to hours |
| EIGRP (Hybrid) | Sub-second possible | 1-5 seconds typical | Seconds to minutes |
| OSPF/IS-IS (Link State) | Sub-second with BFD | Sub-second | 1-5 seconds |
| BGP (Path Vector) | 30-90s or sub-second (BFD) | Seconds | Minutes (intentional) |
BGP's slow convergence isn't a flaw—it's deliberate. Rapid global reconvergence could cause route oscillation, overwhelming router CPUs and destabilizing the internet. Features like MRAI (Minimum Route Advertisement Interval), route flap damping, and conservative timers prioritize stability over speed. Fast local failover uses BFD; global convergence remains measured.
Scalability determines where each paradigm is applicable. A protocol that works beautifully for 50 routers may collapse at 500 or 5000.
Distance Vector Scalability:
Limiting Factors:
- Maximum hop count caps network diameter (RIP: 15 hops)
- Full table exchange every update interval
- Slow convergence worsens with size
- No hierarchical structure
Practical Limits:
RIP: ~15-30 routers, <100 networks
EIGRP: Hundreds of routers (with careful design)
Distance vector works well for small networks but lacks the structural features for large-scale deployment.
Link State Scalability:
Limiting Factors:
- Every router stores complete topology
- SPF computation is O(n log n) to O(n²)
- LSA flooding consumes bandwidth during churn
- Large LSDBs consume memory
Hierarchical Solution:
OSPF/IS-IS use areas to partition the network
- Area 0 (backbone): Connects all areas
- Stub areas: Receive default route, reduced LSAs
- NSSA areas: Allow limited redistribution
Practical Limits:
Per area: 50-200 routers recommended
Total network: Thousands of routers with proper area design
Path Vector Scalability:
BGP scales to the entire internet through abstraction:
Scaling Mechanisms:
1. AS-level abstraction
- Individual routers hidden behind ASN
- Internal topology changes don't trigger updates
2. Incremental updates
- Only changes propagate, not full tables
- Efficient TCP-based reliable delivery
3. Policy-based filtering
- Most networks don't need full global table
- Customers often receive default route only
4. Route aggregation
- /24s aggregate to /16s to /8s
- Reduces table size by orders of magnitude
Current Scale (2024):
- 70,000+ autonomous systems
- 950,000+ IPv4 prefixes
- 200,000+ IPv6 prefixes
- Millions of potential paths
| Paradigm | Limiting Factor | Practical Maximum | Scaling Technique |
|---|---|---|---|
| Distance Vector (RIP) | Hop count, convergence time | ~15-30 routers | None (protocol limitation) |
| Distance Vector (EIGRP) | Query scope, DUAL computation | ~500-1000 routers | Summarization, stub routing |
| Link State | LSDB size, SPF computation | ~200/area, thousands total | Area hierarchy, stub areas |
| Path Vector | Memory for RIB, update processing | Entire internet | AS abstraction, aggregation |
BGP's scalability comes from treating autonomous systems as atomic units. A single AS may contain thousands of internal routers, but BGP sees only one AS number. This abstraction reduces the global routing table from potentially billions of router-level paths to roughly 1 million AS-level paths—a crucial reduction that makes internet-scale routing feasible.
The ability to implement routing policies—business logic affecting path selection—varies dramatically across paradigms.
Distance Vector Policy:
Limited to metric manipulation:
Available Controls:
- Increase/decrease metric to influence path selection
- Filter routes on import/export (accept/deny)
- Distribute lists for prefix filtering
Limitations:
- Cannot see or filter based on actual path
- No mechanism to prefer/avoid specific transit networks
- Single metric provides limited expressiveness
Link State Policy:
More sophisticated but still limited:
Available Controls:
- Cost manipulation per interface
- Area-based policies (stub, NSSA, filtering)
- Route filtering at ABR/ASBR boundaries
- Summarization at area borders
Limitations:
- Within an area, all routers must agree
- No per-destination policy granularity
- Designed for single administrative domain
Path Vector Policy:
Extensive, multi-dimensional policy expression:
Available Controls:
- Path filtering (accept/reject based on AS path)
- Path manipulation (prepending, regex matching)
- Attribute modification (all BGP attributes)
- Community-based signaling (cross-AS policy)
- Local preference (intra-AS outbound preference)
- MED (inter-AS preference hints)
- Weight (per-router overrides)
- Per-neighbor policies (different policies per peer)
- Per-prefix policies (different treatment per destination)
Policy Examples:
- "Never send traffic through AS 65999" → AS path filter
- "Prefer customer over peer over transit" → Local preference
- "Suggest entry at Chicago, not Denver" → MED
- "Ask upstream to prepend when advertising to AS 65123" → Community
| Policy Type | Distance Vector | Link State | Path Vector |
|---|---|---|---|
| Path-based filtering | ❌ Not possible | ❌ Not possible | ✅ AS path regex |
| Transit preference | ❌ No visibility | ❌ No visibility | ✅ AS path analysis |
| Metric manipulation | ✅ Basic | ✅ Cost tuning | ✅ Multiple attributes |
| Cross-domain signaling | ❌ No mechanism | ❌ No mechanism | ✅ Communities |
| Inbound traffic engineering | ❌ Limited | ❌ Very limited | ✅ Prepending, selective ads |
| Business relationship encoding | ❌ No | ❌ No | ✅ Local pref, communities |
Path vector's path visibility wasn't created for loop prevention alone—it was designed to enable policy. The internet is composed of independent organizations with different (often competing) interests. Path vector allows each to make routing decisions aligned with their business objectives while still cooperating in global connectivity.
Understanding when to apply each paradigm is essential for network design. Modern networks typically use all three for different purposes.
Distance Vector Use Cases:
| Scenario | Why Distance Vector Works | Protocol Choice |
|---|---|---|
| Small office/branch | Simple, low resource | RIP (rare), EIGRP |
| Last-mile connectivity | Minimal configuration | RIP |
| Legacy compatibility | Interoperability | RIPv2 |
| EIGRP enterprise | Fast convergence, advanced features | EIGRP |
Link State Use Cases:
| Scenario | Why Link State Works | Protocol Choice |
|---|---|---|
| Enterprise campus | Fast convergence, hierarchy | OSPF |
| Service provider backbone | Multi-area scaling | IS-IS or OSPF |
| Data center | Deterministic paths | IS-IS (common) |
| MPLS infrastructure | Full topology needed | IS-IS + LDP |
Path Vector Use Cases:
| Scenario | Why Path Vector Works | Protocol Choice |
|---|---|---|
| Internet connectivity | Multi-AS, policy needed | eBGP |
| Enterprise multi-homing | Provider independence | eBGP |
| Large enterprise IGP | iBGP for prefix distribution | iBGP |
| MPLS VPN | MP-BGP for VPN routes | iBGP/eBGP |
| Content provider | Traffic engineering | eBGP with communities |
The Modern Hybrid Architecture:
Production networks combine paradigms:
┌─────────────────────────────────────────────────────────┐
│ Internet (eBGP) │
│ [Path Vector - BGP with peers] │
└─────────────────────────┬───────────────────────────────┘
│eBGP
┌─────────────────────────▼───────────────────────────────┐
│ Enterprise/ISP Network │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ iBGP Layer (internal distribution)│ │
│ │ [Route reflectors, iBGP mesh] │ │
│ └──────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────┐ │
│ │ IGP Layer (OSPF/IS-IS) │ │
│ │ [Fast convergence, reachability] │ │
│ └──────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────────────────┐ │
│ │ Access Layer (sometimes EIGRP) │ │
│ │ [Simple, branch connectivity] │ │
│ └──────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
| Criterion | Choose Distance Vector | Choose Link State | Choose Path Vector |
|---|---|---|---|
| Network size | Small (<50 routers) | Medium-Large (scalable) | Internet-scale |
| Administration | Single org, simple | Single org, complex | Multiple orgs |
| Policy needs | Minimal | Moderate | Extensive |
| Convergence priority | Acceptable latency | Fast convergence critical | Stability over speed |
| Resource constraints | Low CPU/memory | Moderate resources | Significant resources |
| Staff expertise | Basic networking | IGP expertise | BGP expertise |
In production networks, BGP depends on the IGP. iBGP next-hops must be reachable via OSPF/IS-IS. BGP provides external reachability; the IGP provides the internal paths to reach those next-hops. They're complementary layers, not alternatives.
The three routing paradigms—distance vector, link state, and path vector—represent different engineering tradeoffs optimized for different scenarios. Understanding these tradeoffs enables you to select appropriate protocols and understand why production networks use multiple paradigms together.
Key Concepts Mastered:
Module Complete:
You have now completed the Path Vector Routing module. You understand:
This knowledge forms the foundation for advanced BGP operations, inter-domain routing design, and understanding how the internet itself is structured and operated.
Congratulations! You have mastered path vector routing fundamentals, from the conceptual foundation of path information through practical BGP implementation to comparative analysis with other routing paradigms. You're now equipped to understand, troubleshoot, and design inter-domain routing solutions.