How OSPF Shortest Path First Works: Networking Explained

1. Introduction and Core Concepts

Open Shortest Path First (OSPF) is a link-state routing protocol that powers the interior of most large enterprise networks, data centers, and Internet Service Provider backbones. At its heart lies the Shortest Path First (SPF) algorithm, more formally known as Dijkstra's algorithm, which allows every router in an OSPF domain to independently compute the loop-free shortest path to every other network destination. Unlike distance-vector protocols that rely on rumors from neighbors, OSPF gives each router a complete, synchronized map of the network topology.

The term ospf shortest path first refers to both the protocol itself and the computational process it uses to build its routing table. OSPF was developed by the Internet Engineering Task Force (IETF) as an open standard (RFC 2328 for OSPFv2 and RFC 5340 for OSPFv3) to overcome the limitations of the older Routing Information Protocol (RIP), such as its 15-hop limit, slow convergence, and inability to handle Variable Length Subnet Masking (VLSM). By using link-state technology, OSPF provides fast convergence, scalability through hierarchical area design, and support for equal-cost multipath routing.

Why does this matter? In modern networks where milliseconds of downtime can cost thousands of dollars, routers must react to link failures and topology changes in seconds, not minutes. OSPF achieves this by flooding Link-State Advertisements (LSAs) throughout an area, ensuring all routers share an identical Link-State Database (LSDB). Each router then runs the SPF algorithm locally on this database to construct a Shortest Path Tree (SPT) with itself as the root. This distributed yet deterministic approach eliminates routing loops and enables intelligent traffic engineering based on configurable link costs, rather than just hop count.

Key Terminology

To understand OSPF SPF, you must know its core components. A Link is the interface on a router, and its State describes the link's status and cost. The Link-State Database (LSDB) is the collection of all LSAs received from every router in the area — essentially the complete network map. The Link-State Advertisement (LSA) is the packet that describes a router's local links, neighbors, and costs. Finally, the Shortest Path Tree (SPT) is the result of the SPF calculation: a tree data structure representing the lowest-cost paths from the calculating router to all destinations.

OSPF's cost metric is a critical concept. By default on Cisco routers, cost is calculated as Reference Bandwidth / Interface Bandwidth, with a default reference of 100 Mbps. This means a 10 Gbps link has a cost of 1, a 1 Gbps link has a cost of 1, and a 100 Mbps link has a cost of 1 as well (unless the reference bandwidth is tuned). Administrators can manually set costs to engineer traffic flows, making SPF decisions deterministic and controllable.

2. How It Works

OSPF operation can be broken down into five distinct phases: neighbor discovery, database synchronization, LSA flooding, SPF computation, and routing table installation. The process begins when routers discover each other by exchanging OSPF Hello packets on multicast address 224.0.0.5. Hellos contain the router ID, area ID, hello/dead intervals, and neighbor list. If parameters match, routers transition through states from Down to Init to 2-Way, and on broadcast networks, they elect a Designated Router (DR) and Backup Designated Router (BDR) to reduce adjacency overhead.

Once a neighbor relationship progresses to ExStart, Exchange, Loading, and finally Full, the routers synchronize their LSDBs by exchanging Database Description (DBD) packets, Link-State Requests (LSRs), and Link-State Updates (LSUs). At the end of this process, all routers within the same area possess an identical LSDB. This synchronization is fundamental — if databases diverge, SPF calculations will produce inconsistent routing tables and potential loops. OSPF uses reliable flooding with explicit acknowledgments (LSAcks) to guarantee delivery.

With a synchronized LSDB, each router independently runs Dijkstra's algorithm. The algorithm works by maintaining two sets of nodes: those with a finalized shortest path and those still tentative. It starts at the root (itself) with a distance of 0 and all other nodes at infinity. It iteratively selects the tentative node with the smallest distance, finalizes it, and relaxes all of its neighbors — meaning if a path through the finalized node to a neighbor is cheaper than the currently known path, it updates the neighbor's distance and predecessor. This greedy approach works because OSPF link costs are always non-negative.

The SPF Calculation Process

Conceptually, you can visualize the SPF calculation as building a tree outward from the root. The router places itself at the root of the tree. It then examines all links described in its own Router LSA and adds the directly connected neighbors with their costs. The neighbor with the lowest total cost is added to the tree first. The process repeats, always expanding the frontier by the lowest cumulative cost path, until all destinations in the area are added. The resulting tree provides the shortest path to every subnet, and the router installs the next-hop information for each destination into its Routing Information Base (RIB).

OSPF is hierarchical. A large autonomous system is divided into areas, with Area 0 (the backbone) at the center. SPF is run independently within each area. Area Border Routers (ABRs) summarize inter-area routes and inject them as Summary LSAs (Type 3) into other areas, while Autonomous System Boundary Routers (ASBRs) inject external routes (Type 5 LSAs). This hierarchy limits the scope of LSA flooding and SPF computation, which is crucial for scalability. A link flap in one area does not force routers in another area to rerun full SPF.

3. Implementation

While production OSPF is implemented in router operating systems like Cisco IOS, Juniper Junos, and open-source daemons like FRRouting, its core SPF logic is pure Dijkstra's algorithm. Understanding the implementation clarifies how routers achieve sub-second convergence. The following Python examples model the LSDB as an adjacency list and implement SPF with a priority queue, which is how modern OSPF implementations achieve optimal performance.

# Implementation 1: Core Dijkstra SPF Algorithm as used by OSPF
import heapq
from collections import defaultdict

def ospf_spf_calculation(lsdb, source_router):
    """
    Simulates OSPF SPF calculation using Dijkstra's algorithm.
    lsdb: dict {router_id: [(neighbor_id, cost), ...]}
    source_router: Router ID of the calculating router (root of SPT)
    Returns: distances and predecessors for shortest path tree
    """
    # Initialize distances to infinity for all routers
    distances = {router: float('inf') for router in lsdb}
    predecessors = {router: None for router in lsdb}
    distances[source_router] = 0
    
    # Priority queue: (cumulative_cost, router_id)
    # This is the key optimization for OSPF SPF (heap-based)
    pq = [(0, source_router)]
    visited = set()
    
    while pq:
        current_cost, current_router = heapq.heappop(pq)
        
        # Skip if we have already finalized this node
        if current_router in visited:
            continue
        visited.add(current_router)
        
        # Relax all neighbors (examine LSAs for current router)
        for neighbor, link_cost in lsdb[current_router]:
            if neighbor in visited:
                continue
            
            new_cost = current_cost + link_cost
            
            # If found a shorter path, update distance and predecessor
            if new_cost < distances[neighbor]:
                distances[neighbor] = new_cost
                predecessors[neighbor] = current_router
                heapq.heappush(pq, (new_cost, neighbor))
    
    return distances, predecessors

# Example LSDB for a small OSPF area
lsdb_example = {
    'R1': [('R2', 10), ('R3', 5)],
    'R2': [('R1', 10), ('R3', 2), ('R4', 1)],
    'R3': [('R1', 5), ('R2', 2), ('R4', 9)],
    'R4': [('R2', 1), ('R3', 9)]
}
dist, prev = ospf_spf_calculation(lsdb_example, 'R1')
print(f"Shortest costs from R1: {dist}")
# Output: {'R1': 0, 'R2': 7, 'R3': 5, 'R4': 8}

# Implementation 2: OSPF LSDB and LSA Flooding Simulation
class RouterLSA:
    """Represents OSPF Type 1 Router LSA"""
    def __init__(self, router_id, links):
        self.router_id = router_id
        self.links = links  # List of (neighbor_id, cost, network)
        self.sequence_number = 1

class OSPFDatabase:
    """Simulates the Link-State Database (LSDB)"""
    def __init__(self):
        self.lsdb = {}  # router_id -> RouterLSA
    
    def add_lsa(self, lsa):
        """Add or update LSA if sequence number is newer"""
        existing = self.lsdb.get(lsa.router_id)
        if existing is None or lsa.sequence_number > existing.sequence_number:
            self.lsdb[lsa.router_id] = lsa
            return True  # Flood further
        return False
    
    def to_adjacency_list(self):
        """Convert LSDB to graph for SPF calculation"""
        graph = defaultdict(list)
        for router_id, lsa in self.lsdb.items():
            for neighbor, cost, _ in lsa.links:
                graph[router_id].append((neighbor, cost))
        return graph
    
    def flood_lsa(self, new_lsa, source_router):
        """Simulate reliable flooding to all routers"""
        print(f"Flooding LSA from {new_lsa.router_id} originated at {source_router}")
        self.add_lsa(new_lsa)

# Build LSDB
db = OSPFDatabase()
db.add_lsa(RouterLSA('R1', [('R2', 10, '10.0.12.0/30'), ('R3', 5, '10.0.13.0/30')]))
db.add_lsa(RouterLSA('R2', [('R1', 10, '10.0.12.0/30'), ('R4', 1, '10.0.24.0/30')]))
db.add_lsa(RouterLSA('R3', [('R1', 5, '10.0.13.0/30'), ('R4', 2, '10.0.34.0/30')]))
db.add_lsa(RouterLSA('R4', [('R2', 1, '10.0.24.0/30'), ('R3', 2, '10.0.34.0/30')]))

adj = db.to_adjacency_list()
print(f"Adjacency List for SPF: {dict(adj)}")

# Implementation 3: Building the OSPF Routing Table from SPT
def build_routing_table(lsdb, source, predecessors, distances, loopback_networks):
    """
    Reconstructs next-hop routing table from SPF predecessors.
    loopback_networks: dict {router_id: network_prefix}
    """
    routing_table = {}
    
    for destination in lsdb:
        if destination == source:
            continue
        
        # Walk back from destination to source to find next-hop
        next_hop = destination
        current = destination
        
        # Trace predecessor chain until we find direct neighbor of source
        while predecessors[current] is not None and predecessors[current] != source:
            current = predecessors[current]
        
        if predecessors[current] == source:
            next_hop = current
        elif current == source:
            next_hop = destination
        
        # Handle ECMP (Equal-Cost Multi-Path) detection
        cost = distances[destination]
        network = loopback_networks.get(destination, f"Net-{destination}")
        routing_table[network] = {
            'next_hop': next_hop,
            'cost': cost,
            'predecessor_chain': predecessors
        }
    
    return routing_table

# Reuse SPF results from Implementation 1
loopbacks = {'R1': '1.1.1.1/32', 'R2': '2.2.2.2/32', 'R3': '3.3.3.3/32', 'R4': '4.4.4.4/32'}
distances, preds = ospf_spf_calculation(lsdb_example, 'R1')
rib = build_routing_table(lsdb_example, 'R1', preds, distances, loopbacks)

for prefix, entry in rib.items():
    print(f"{prefix} -> next-hop {entry['next_hop']}, cost {entry['cost']}")

# Implementation 4: Incremental SPF and ECMP Handling
def ospf_spf_with_ecmp(lsdb, source):
    """
    OSPF with Equal-Cost Multi-Path support.
    Real OSPF installs multiple next-hops if costs are equal.
    """
    distances = {r: float('inf') for r in lsdb}
    # Store ALL predecessors for ECMP
    ecmp_predecessors = {r: [] for r in lsdb}
    distances[source] = 0
    pq = [(0, source)]
    visited = set()
    
    while pq:
        cost, node = heapq.heappop(pq)
        if node in visited:
            continue
        visited.add(node)
        
        for neighbor, w in lsdb[node]:
            new_cost = cost + w
            if new_cost < distances[neighbor]:
                distances[neighbor] = new_cost
                ecmp_predecessors[neighbor] = [node]
                heapq.heappush(pq, (new_cost, neighbor))
            elif new_cost == distances[neighbor]:
                # Equal cost path found - add to ECMP set
                ecmp_predecessors[neighbor].append(node)
    
    return distances, ecmp_predecessors

# Example where ECMP occurs: R1 to R4 has two equal costs
ecmp_lsdb = {
    'R1': [('R2', 5), ('R3', 5)],
    'R2': [('R1', 5), ('R4', 5)],
    'R3': [('R1', 5), ('R4', 5)],
    'R4': [('R2', 5), ('R3', 5)]
}
d, ecmp = ospf_spf_with_ecmp(ecmp_lsdb, 'R1')
print(f"Distances: {d}")
print(f"ECMP predecessors for R4: {ecmp['R4']}")  # Should be ['R2', 'R3']
print(f"R1 can load-balance to R4 via both R2 and R3 with cost {d['R4']}")

4. Step-by-Step Example

Let's walk through a concrete SPF calculation for a four-router OSPF area. Consider routers R1, R2, R3, and R4 interconnected as follows: R1 connects to R2 with cost 10 and to R3 with cost 5. R2 connects to R3 with cost 2 and to R4 with cost 1. R3 connects to R4 with cost 9. We will calculate the Shortest Path Tree from R1's perspective. This topology is intentionally asymmetric to show how OSPF avoids the trap of simply choosing the direct link.

Initialization: R1 sets its own distance to 0 and all others to infinity. The candidate list (priority queue) contains only R1(0). The visited set is empty. The LSDB already contains all Router LSAs, so R1 knows the full graph. This mirrors the state immediately after LSDB synchronization but before any SPF run.

Iteration 1: Extract the minimum node from the candidate list: R1(0). Mark R1 as visited. Relax its neighbors: R2 via cost 10 gives distance 10, predecessor R1. R3 via cost 5 gives distance 5, predecessor R1. Candidate list now contains R3(5), R2(10). The algorithm correctly prefers the lower-cost path to R3 even though R2 is directly connected.

Iteration 2: Extract R3(5) — the smallest tentative distance. Mark R3 visited. Examine R3's neighbors: R2 via R3 costs 5 + 2 = 7, which is better than the current 10, so update R2's distance to 7 and predecessor to R3. R4 via R3 costs 5 + 9 = 14, so set R4 distance to 14, predecessor R3. Candidate list now: R2(7), R4(14). Note how the path to R2 improved by going through R3.

Iteration 3: Extract R2(7). Mark R2 visited. Relax R2's neighbors: R4 via R2 costs 7 + 1 = 8, which is better than 14, so update R4 to 8, predecessor R2. Candidate list: R4(8). R1 and R3 are already visited and ignored.

Iteration 4: Extract R4(8). Mark visited. No unvisited neighbors remain. Algorithm terminates. Final distances from R1: R1=0, R3=5, R2=7 (via R3), R4=8 (via R3->R2). The routing table on R1 will show: to reach R2's loopback, next-hop is R3; to reach R4, next-hop is also R3. This demonstrates that the shortest path is not always the most intuitive direct link, and OSPF's SPF calculation guarantees the mathematically optimal result.

Visualizing the Shortest Path Tree

The resulting SPT rooted at R1 looks like: R1 is the root, with a single child R3 (cost 5). R3 has child R2 (cost 2, cumulative 7). R2 has child R4 (cost 1, cumulative 8). This forms a chain R1—R3—R2—R4. If R1 needs to send a packet to R4's network 4.4.4.4/32, it will forward to R3, which forwards to R2, which delivers to R4. Each router independently computes its own tree; R4's tree would be completely different, rooted at R4, ensuring loop-free forwarding.

5. Complexity Analysis

The efficiency of OSPF's SPF calculation directly impacts network convergence time. When a link fails, every router in the area must rerun SPF before it can update its forwarding table. Therefore, understanding the time and space complexity of Dijkstra's algorithm as applied to OSPF is critical for network design, especially in large areas with hundreds of routers.

The classic Dijkstra implementation using an array to find the minimum distance node runs in O(V²) time, where V is the number of routers (vertices) and E is the number of links (edges). This is acceptable for very small areas but scales poorly. Modern OSPF implementations use a binary heap (priority queue) to achieve O((V + E) log V) time. With a Fibonacci heap, the theoretical bound improves to O(E + V log V), though binary heaps are more common in practice due to lower constant factors and simpler implementation.

Space complexity is dominated by the LSDB storage and the auxiliary data structures for SPF. Storing the LSDB requires O(V + E) space for the adjacency list. The distance, predecessor, and priority queue structures each require O(V) additional space. In hierarchical OSPF, V and E refer only to the routers and links within a single area, not the entire autonomous system, which is why proper area design is the primary tool for controlling SPF complexity.

In practice, the worst-case full SPF is rarely triggered. OSPF implementations use optimizations like Incremental SPF (iSPF), which only recalculates the affected portion of the tree when a single link changes, and Partial Route Calculation (PRC) for changes to leaf networks. These can reduce computation from O((V+E) log V) to nearly O(log V) for minor topology changes, allowing networks with 500+ routers per area to converge in under 200 milliseconds.

6. Variations and Optimizations

Standard OSPF SPF has been enhanced with numerous optimizations to meet the demands of modern high-speed networks. The most significant is Incremental SPF (iSPF), described in RFC 2328 optimizations and widely implemented by Cisco and Juniper. Instead of rebuilding the entire SPT from scratch when an LSA changes, iSPF identifies the subtree affected by the change and only recalculates that portion. If a leaf network flaps, iSPF may not need to run Dijkstra at all.

SPF Throttling is another critical optimization. Without throttling, a flapping link could cause routers to run SPF continuously, spiking CPU to 100%. Modern implementations use exponential backoff: the first SPF runs immediately, the next is delayed by 50ms, then 100ms, 200ms, up to a maximum hold time (often 5-10 seconds). This dampens instability while still allowing fast convergence for isolated failures. Related is LSA throttling, which rate-limits the generation of LSAs themselves.

Fast Reroute (FRR) technologies like Loop-Free Alternate (LFA) and Remote LFA pre-compute backup paths before a failure occurs. OSPF calculates not only the primary shortest path but also a loop-free backup next-hop for each destination. When a link fails, the router can switch to the backup in under 50ms without waiting for LSA flooding and SPF reconvergence, meeting carrier-grade requirements.

OSPF Variants

Several OSPF variants adapt SPF for different environments. OSPFv3 (RFC 5340) supports IPv6 and runs SPF on the same topology but advertises prefixes separately. OSPF Multi-Area Adjacency and OSPF Sham Links extend SPF across MPLS VPNs. Data center fabrics often use OSPF with enhancements like OSPF-TE (Traffic Engineering) where link costs are dynamically adjusted based on bandwidth utilization, and SPF is run more frequently with tuned reference bandwidths (e.g., 100 Gbps).

Another optimization is SPF Prefix Prioritization. Not all prefixes are equal — loopbacks and BGP next-hops are more critical than edge subnets. High-priority prefixes are calculated first and installed in the forwarding plane ahead of low-priority ones, reducing the time critical traffic is blackholed after a failure.

7. Real-World Applications

OSPF Shortest Path First is not an academic exercise; it is the workhorse of interior routing globally. Understanding where it is deployed illustrates why its design choices matter.

Enterprise Campus and WAN Networks: A typical Fortune 500 company with dozens of offices uses OSPF as its Interior Gateway Protocol (IGP). Each campus building or geographic region is an OSPF area, with Area 0 interconnecting data centers. When a fiber cut occurs between buildings, OSPF SPF recalculates and reroutes voice and data traffic within seconds, maintaining connectivity for thousands of employees without manual intervention. The ability to set link costs allows network architects to prefer high-capacity fiber over slower backup links.

Internet Service Provider (ISP) Backbones: Tier-1 and Tier-2 ISPs run OSPF or IS-IS (a similar link-state protocol) in their core. An ISP PoP (Point of Presence) in each city is an area, and the backbone interconnects them. OSPF's fast convergence and ECMP support are vital here — ISPs use ECMP to load-balance traffic across multiple equal-cost fiber paths, maximizing utilization of expensive long-haul links. A single SPF calculation may determine the path for millions of customer flows.

Data Center Fabrics: Modern leaf-spine data center architectures heavily use OSPF as an underlay protocol. Each rack's Top-of-Rack (ToR) switch runs OSPF to advertise its subnets. With hundreds of switches and thousands of links, SPF must be highly optimized. Data centers often tune OSPF to use unnumbered interfaces and BFD (Bidirectional Forwarding Detection) for sub-second failure detection, triggering SPF in milliseconds to reroute east-west traffic between servers.

Beyond traditional networking, the SPF algorithm itself is reused in many software systems. Web servers use similar shortest-path logic for CDN request routing, databases use it for query plan optimization, and network management platforms simulate OSPF SPF offline to predict the impact of planned maintenance before it happens.

8. Comparison with Alternatives

OSPF is not the only routing protocol available. Network architects choose between several Interior Gateway Protocols (IGPs) based on scalability, vendor support, and operational complexity. The primary alternatives are RIP, Enhanced Interior Gateway Routing Protocol (EIGRP), and Intermediate System-to-Intermediate System (IS-IS).

RIP is a distance-vector protocol that uses hop count as its metric and the Bellman-Ford algorithm. It is simple but severely limited — maximum 15 hops, slow convergence (minutes), and periodic full-table updates every 30 seconds. EIGRP is Cisco's advanced distance-vector protocol using the Diffusing Update Algorithm (DUAL). It offers fast convergence and unequal-cost load balancing but is historically Cisco-proprietary, limiting multi-vendor deployments. IS-IS is another link-state protocol very similar to OSPF, also using Dijkstra, but it operates at Layer 2 and uses TLV encoding, making it more extensible and popular in very large ISP cores.

For most enterprise networks, OSPF is the default choice due to its open standard, mature implementations, and excellent tooling. IS-IS is preferred by large ISPs because it is less tied to IP and handles large topologies slightly more efficiently. EIGRP remains in Cisco-heavy environments, while RIP is now largely relegated to legacy or very small networks and lab environments.

9. Common Mistakes and Best Practices

Deploying OSPF incorrectly can lead to suboptimal routing, slow convergence, or even network outages. One of the most common mistakes is failing to tune reference bandwidth. With the default 100 Mbps reference, any link faster than 100 Mbps (1 Gbps, 10 Gbps, 100 Gbps) all have cost 1, making SPF unable to distinguish between them. Best practice is to set reference bandwidth to at least 100 Gbps (100000 Mbps) on all routers in the domain so costs properly reflect modern link speeds.

Another frequent pitfall is poor area design. Placing too many routers in a single area (e.g., > 300) causes the LSDB to grow large, SPF runs to be CPU-intensive, and a single flapping link to affect everyone. Conversely, creating too many small areas increases ABR overhead and summarization complexity. Best practice is to keep areas under 200 routers, use contiguous Area 0, and summarize aggressively at ABRs to reduce LSA flooding scope. Virtual links to fix discontiguous Area 0 should be avoided — they add complexity and fragility.

Inconsistent hello/dead timers or MTU mismatches cause adjacencies to fail to form or to flap. OSPF requires hello and dead intervals to match between neighbors, and on broadcast networks, MTU must match for DBD exchange. Always explicitly configure timers if changing from defaults and ensure interface MTUs are consistent. Using passive interfaces on user-facing ports is also critical — without it, OSPF will send Hellos to end hosts, wasting bandwidth and exposing the routing domain to spoofing.

Best Practices Checklist

• Set Router IDs deterministically: Manually configure loopback-based router IDs (e.g., 1.1.1.1) rather than relying on highest interface IP, ensuring stability after interface changes.
• Use point-to-point network types: On data center and WAN links, configure ip ospf network point-to-point to avoid DR/BDR election overhead and speed up convergence.
• Enable BFD: Pair OSPF with Bidirectional Forwarding Detection for sub-second failure detection instead of relying on 40-second dead timers.
• Filter and summarize: Use area range and summary-address commands to reduce LSDB size and limit SPF impact. Filter Type 3 LSAs where appropriate.
• Monitor SPF runs: Track show ip ospf statistics and CPU usage. Frequent SPF runs (> 10 per minute) indicate a flapping link that needs dampening.
• Secure OSPF: Enable MD5 or IPsec authentication to prevent rogue routers from injecting false LSAs and hijacking traffic.

Finally, never forget that OSPF cost is directional. While most implementations use symmetric costs, it is possible to configure different costs in each direction, which can lead to asymmetric routing. Always verify costs in both directions during troubleshooting with show ip ospf interface and show ip ospf database.

10. Interview Questions

OSPF SPF is a staple of networking interviews for roles ranging from Network Engineer to Solutions Architect. Interviewers test both theoretical understanding of Dijkstra and practical OSPF troubleshooting. Here are common questions with concise, interview-ready answers.

Q1: Why does OSPF use Dijkstra's algorithm and not Bellman-Ford? What constraint does this impose?

OSPF uses Dijkstra because it is a link-state protocol where each router has a complete, synchronized map (LSDB) of the area. Dijkstra is more efficient than Bellman-Ford when the full topology is known — O((V+E) log V) with a heap versus O(V*E) for Bellman-Ford — and it guarantees loop-free shortest paths in a single run. The constraint is that Dijkstra requires all link costs to be non-negative. OSPF enforces this by defining cost as a positive integer (1-65535). If negative costs were allowed, Dijkstra would fail, and Bellman-Ford would be needed to handle them, but OSPF's cost model makes this unnecessary.

Q2: What happens step-by-step when a link fails in an OSPF area?

First, the routers directly attached to the failed link detect the failure via interface down or BFD. They generate new Router LSAs reflecting the topology change with an incremented sequence number and flood them reliably throughout the area using LSUs and LSAcks. Every router in the area receives the updated LSA, updates its LSDB, and schedules an SPF run (subject to SPF throttling). Each router then runs Dijkstra on the new LSDB, rebuilds its SPT, and updates its RIB and FIB. Convergence time is the sum of failure detection + flooding delay + SPF computation + RIB/FIB installation, typically 200ms to a few seconds when tuned.

Q3: How does OSPF prevent routing loops if every router calculates independently?

Loops are prevented because all routers in an area share an identical LSDB at the moment of calculation. Since Dijkstra is deterministic, if all routers start from the same map, they will compute consistent, loop-free paths — even though each computes a different tree rooted at itself. Loops could only occur transiently during convergence when LSDBs are temporarily inconsistent, which is why fast flooding and SPF throttling are critical. Hierarchical area design also prevents inter-area loops by requiring all inter-area traffic to transit Area 0 and by using distance-vector-like behavior for summary LSAs between areas.

Q4: What is the difference between Intra-area, Inter-area, and External routes in OSPF, and how does SPF handle them?

Intra-area routes (O) are destinations within the same area — SPF calculates these directly from Type 1 and Type 2 LSAs by building the SPT. Inter-area routes (O IA) are destinations in another area, advertised by ABRs via Type 3 Summary LSAs; the router calculates the cost as SPF cost to the ABR plus the advertised cost from the ABR. External routes (O E1/E2) are redistributed from other protocols via Type 5 LSAs from ASBRs; E1 cost includes internal OSPF cost to the ASBR plus external cost, while E2 cost is just the external cost. SPF is only run fully for intra-area; inter-area and external use partial calculations.

Q5: How would you design OSPF costs to achieve traffic engineering for two equal paths?

To load-balance, ensure both paths have identical cumulative cost so OSPF installs both as ECMP — for example, set each link's cost so Path A (R1-R2-R4) and Path B (R1-R3-R4) both sum to 20. OSPF will then install two next-hops and the router will hash flows across them. To prefer one path, make its cumulative cost lower — e.g., set Path A to 10 and Path B to 20, so SPF will choose Path A as primary. For more granular control, use OSPF-TE or MPLS-TE, but simple cost tuning covers 90% of enterprise traffic engineering needs. Always verify with traceroute and show ip route.