Senior 7 min · March 06, 2026
Routing Protocols

OSPF Metric Blind Spot — Why 10Gbps and 100Mbps Look Equal

Default OSPF cost=1 on both 10Gbps and transatlantic 100Mbps caused >200ms latency.

N
Naren Founder & Principal Engineer

20+ years shipping production systems from the metal up. Lessons pulled from things that broke in production.

Follow
Production
production tested
May 24, 2026
last updated
1,554
articles · all by Naren
 ● Production Incident 🔎 Debug Guide ⚙ Triage Commands
Quick Answer
  • RIP uses Bellman-Ford for distance vector routing with hop count metric
  • OSPF uses Dijkstra's SPF for link state routing with cost based on bandwidth
  • BGP is a path vector protocol that exchanges reachability and policy attributes
  • Convergence: RIP can take minutes (count-to-infinity), OSPF converges in under 10s
  • Production insight: metric misconfiguration causes silent suboptimal routing
✦ Definition~90s read
What is Routing Protocols?

Routing protocols are the distributed consensus engines that determine how packets traverse networks, from a small office LAN to the global internet. They solve the fundamental problem of dynamic path selection: when a link or router fails, the network must automatically recalculate viable routes without human intervention.

Imagine your city has thousands of roads and you need to drive a package from New York to Los Angeles.

Without them, every router would need static routes manually configured for every possible destination — an impossible task at internet scale. These protocols are essentially algorithms that allow routers to exchange reachability information and build a shared, consistent view of the network topology.

In the networking stack, routing protocols operate at the control plane, distinct from the data plane that actually forwards packets. They fall into two architectural camps: Interior Gateway Protocols (IGPs) like OSPF and RIP, which run within a single autonomous system (AS), and Exterior Gateway Protocols like BGP, which connect ASes.

The choice depends on scale and requirements — OSPF converges in seconds and handles hundreds of routers, while BGP handles hundreds of thousands of routes but prioritizes policy over raw speed. RIP, the oldest, is limited to 15 hops and is effectively obsolete outside of legacy or lab environments.

The critical blind spot this article addresses is OSPF's default metric behavior: it uses a reference bandwidth of 100 Mbps, meaning a 10 Gbps link and a 100 Mbps link both get a cost of 1. This breaks path selection on modern hardware, forcing engineers to manually adjust the reference bandwidth or use explicit cost overrides.

Understanding this quirk is essential for anyone designing or troubleshooting OSPF networks, as it directly impacts traffic engineering and convergence behavior in production environments.

Plain-English First

Imagine your city has thousands of roads and you need to drive a package from New York to Los Angeles. A routing protocol is like a GPS system that every intersection uses to talk to its neighbours — each junction shares what roads it knows about, how congested they are, and updates its map when a road closes. The 'protocol' is just the agreed language all those intersections use to gossip with each other so every driver always takes the best available path.

Every time you load a webpage, your request hops across dozens of routers spanning continents, undersea cables, and data-centres owned by completely different companies. None of those routers were pre-programmed with a static map of the entire internet — that would be impossible to maintain. Instead, they run routing protocols: living, breathing algorithms that continuously discover the network topology, elect the best paths, and heal themselves when links go dark. Understanding this machinery isn't academic; it's what separates an engineer who can debug a production outage from one who just restarts the router and hopes.

The core problem routing protocols solve is dynamic reachability at scale. A static route you add manually works fine for a lab with five subnets. It collapses the moment a link fails or a new site comes online, because nothing automatically redistributes that knowledge. Routing protocols replace human intervention with distributed consensus — every router converges on the same view of the network without a central coordinator, and they do it in seconds or milliseconds depending on the protocol.

By the end of this article you'll understand exactly how Bellman-Ford powers RIP and why it causes count-to-infinity, how Dijkstra's SPF algorithm inside OSPF builds a loop-free topology, why BGP is a policy engine masquerading as a routing protocol, and how to reason about convergence time and route selection in production networks. You'll also walk away with concrete Python simulations you can run locally to watch these algorithms think.

Why Routing Protocols Are the Internet's Distributed Consensus Engine

A routing protocol is a distributed algorithm that lets routers discover and maintain paths across a network without a central controller. The core mechanic: routers exchange reachability information (prefixes) and path cost metrics, then each independently runs a shortest-path computation (e.g., Dijkstra for OSPF, Bellman-Ford for RIP) to build its forwarding table. The result is a loop-free, converged topology that adapts when links fail or costs change.

Key properties that matter in practice: convergence time (how fast all routers agree after a change), metric type (hop count vs. bandwidth-delay composite), and scalability (link-state protocols like OSPF handle hundreds of routers; distance-vector like EIGRP scales differently). OSPF uses cost = reference bandwidth / interface bandwidth, defaulting to 100 Mbps reference — meaning any link faster than 100 Mbps gets cost 1, making 10 Gbps and 100 Mbps indistinguishable.

Use routing protocols in any multi-hop IP network where manual static routes are impractical — data centers, enterprise WANs, ISP backbones. They matter because they automate failover, load-balance across equal-cost paths, and enforce policy (e.g., BGP communities). Without them, a single link failure would require human intervention to re-route traffic.

OSPF Metric Blind Spot
Default OSPF cost calculation treats all links ≥100 Mbps as cost 1 — your 10 Gbps and 100 Mbps paths are equal unless you manually adjust the reference bandwidth.
Production Insight
Teams migrating from 1 Gbps to 10 Gbps core links often forget to set 'auto-cost reference-bandwidth 10000' in OSPF.
Traffic that should prefer the 10 Gbps path instead load-balances equally with 1 Gbps links, causing unexpected congestion and jitter on the slower path.
Always set the reference bandwidth to the fastest link in your network (e.g., 10000 for 10 Gbps) — never rely on defaults.
Key Takeaway
Routing protocols are distributed consensus engines — they converge on a shared view of the network topology.
Metric design matters: OSPF's default cost flattens all links ≥100 Mbps, so you must tune reference bandwidth for modern speeds.
Convergence time is the real operational metric — sub-second failover requires fast hello timers and incremental updates (OSPF LSA flooding).
OSPF Metric Blind Spot: 10Gbps vs 100Mbps THECODEFORGE.IO OSPF Metric Blind Spot: 10Gbps vs 100Mbps Why high-speed links appear equal to slower ones in OSPF cost OSPF Cost Formula Cost = reference bandwidth / interface bandwidth Default Reference Bandwidth 100 Mbps (classic default) 10Gbps Interface Cost 100 / 10000 = 1 (minimum cost) 100Mbps Interface Cost 100 / 100 = 1 (same cost) Equal Cost Paths Both links treated as equal cost Fix: Raise Reference Bandwidth Set to 10000 or higher for accuracy ⚠ Default reference bandwidth hides high-speed link advantage Always adjust 'auto-cost reference-bandwidth' to match your network THECODEFORGE.IO
thecodeforge.io
OSPF Metric Blind Spot: 10Gbps vs 100Mbps
Routing Protocols

Where Routing Protocols Fit in Networking

Every router maintains a routing table — the list of every destination network it knows about and how to reach it. But routers don't build that table by magic. They rely on routing protocols to dynamically discover paths, adapt to failures, and distribute reachability across an autonomous system or the entire internet.

The distinction between routing protocols and routed protocols is crucial for production thinking. Routed protocols like IP carry user data. Routing protocols like OSPF, BGP, and RIP carry routing information between routers. If the routing protocol goes down, the IP traffic doesn't necessarily stop — the routers still have stale routes until they time out. That stale state is a common root cause of traffic blackholes.

show-route.shBASH
1
2
3
4
5
6
7
8
# Show routing table on a Cisco router
show ip route

# Example output (abbreviated)
C   192.168.1.0/24 is directly connected, GigabitEthernet0/0
O   10.0.0.0/8 [110/2] via 192.168.1.1, 00:00:34, GigabitEthernet0/0
B   172.16.0.0/12 [20/0] via 10.0.0.1, 00:10:22, Serial0/0/0
R   192.168.2.0/24 [120/3] via 192.168.1.2, 00:00:12, GigabitEthernet0/1
Output
C = connected, O = OSPF, B = BGP, R = RIP
Routing Protocol vs Routing Table
The routing table is the final output; the routing protocol is the algorithm that builds it. If you change an OSPF cost, you don't touch the table directly — OSPF recalculates and updates it. That indirection is what makes dynamic routing powerful and dangerous in production.
Production Insight
When a routing protocol session dies, stale routes remain in the table until the hold-down timer expires.
During that window, traffic continues to be sent to a dead next-hop — a silent outage.
Rule: match the hold-down timer to your failure detection latency, or use BFD (Bidirectional Forwarding Detection) for sub-second convergence.
Key Takeaway
Routing protocols are the brain of the network.
Pick the protocol that matches your failure recovery needs, not just your feature checklist.
A misconfigured routing protocol is worse than no routing protocol — it can blackhole traffic silently.
Choosing Between RIP, OSPF, and BGP
IfSmall network (< 15 hops, no complex topology)
UseRIP may suffice for simplicity, but OSPF is preferred even in small networks for faster convergence.
IfEnterprise network with multiple paths and diverse link speeds
UseOSPF — provides fast convergence and metric based on bandwidth. Use multiple areas for scalability.
IfConnecting different autonomous systems (ISPs, multi-homed enterprise)
UseBGP — essential for inter-domain routing. You need policy control (local pref, AS_PATH manipulation).
IfLeaf-spine data center fabric (e.g., Clos topology)
UseUse OSPF or BGP underlay. BGP is common in modern DCs for its flexibility and ability to handle many paths.

RIP — Distance Vector Routing and Its Production Limits

RIP (Routing Information Protocol) is the simplest routing protocol. Every router sends its entire routing table to neighbours every 30 seconds. Each route carries a hop count — a metric that counts how many routers you must cross to reach the destination. The maximum is 15 hops; 16 means unreachable.

The algorithm behind RIP is Bellman-Ford — a distributed version where each router updates its table based on received advertisements. RIP converges slowly because of the count-to-infinity problem: when a link fails, the announcement takes time to propagate, and routers may temporarily believe a path exists through a router that just lost that route, incrementing the hop count each time. This slowly increases until it hits 16.

In production, RIP is almost never used today. The 15-hop limit is too restrictive for any network with more than a few routers. Convergence can take minutes — unacceptable for modern applications. However, RIP's simplicity makes it an excellent teaching tool. Understanding its flaws explains why OSPF and BGP exist.

bellman_ford_simulation.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# io.thecodeforge.routing.bellman_ford

import itertools

def rip_simulate(routers, initial_links, fail_link=None):
    """Simplified RIP-like Bellman-Ford simulation with count-to-infinity."""
    INF = 16
    # Initialize distances: self=0, direct neighbours=1, else INF
    dist = {r: {t: (1 if t in initial_links.get(r, []) else 0 if r == t else INF)
                for t in routers} for r in routers}
    
    for iteration in range(5):  # simulate 5 update cycles
        new_dist = {r: d.copy() for r, d in dist.items()}
        for r in routers:
            for neighbor in initial_links.get(r, []):
                if fail_link and (r, neighbor) in [fail_link, (fail_link[1], fail_link[0])]:
                    continue  # link is down
                for dest in routers:
                    via_neighbor = dist[neighbor][dest] + 1
                    if via_neighbor < new_dist[r][dest] and via_neighbor <= 15:
                        new_dist[r][dest] = via_neighbor
        dist = new_dist
        print(f"After iteration {iteration+1}: Router A to D = {dist['A']['D']}")
    return dist

# Test: 4 routers A-B-C-D
routers = ['A', 'B', 'C', 'D']
links = {'A': ['B'], 'B': ['A', 'C'], 'C': ['B', 'D'], 'D': ['C']}
print("Initial distances (A->D):")
result = rip_simulate(routers, links)
print("After iteration 5:", result['A']['D'])
Output
After iteration 1: A to D = 16 (unreachable)
After iteration 2: A to D = 3
After iteration 3: A to D = 3
After iteration 4: A to D = 3
After iteration 5: A to D = 3
(Converged. If link B-C fails, count-to-infinity begins.)
Mental Model: Bad News Travels Slowly
  • When a link fails, the router that discovers it sets the metric to 16 and announces it.
  • Neighbors may have a better path? No — they might have learned that route from the failed router, so they still think it's reachable.
  • The failed router hears the neighbor's advertisement and thinks there's a path through them, so it updates its own metric to (neighbor's metric + 1).
  • This cycle repeats, each time incrementing the metric, until it reaches 16 and is finally considered unreachable.
  • Protocols use split-horizon and route poisoning to mitigate this, but poison reverse only helps for directly connected routers.
Production Insight
If you ever encounter RIP in a legacy network, you'll see convergence taking 3-5 minutes on a simple link flap.
Engineers often 'fix' it by reducing timers — that only makes the update storm worse during convergence.
The real fix: replace RIP with OSPF or use administrative distance to prefer a static route for critical destinations.
Key Takeaway
RIP's count-to-infinity is the canonical example of a distributed algorithm's failure mode.
Larger networks require link-state protocols that build a consistent topology map.
If you see RIP in production, you're maintaining debt — plan a migration.

OSPF (Open Shortest Path First) is a link-state routing protocol. Instead of exchanging routing tables, OSPF routers flood Link State Advertisements (LSAs) to all routers in the same area. Every router builds an identical Link State Database (LSDB) of the entire network topology. Then each router runs Dijkstra's Shortest Path First (SPF) algorithm on this database to compute the shortest path tree to every destination.

OSPF uses a metric called cost, which defaults to reference_bandwidth / interface_bandwidth. This makes path selection sensitive to bandwidth — a 1Gbps link gets cost=1 (if reference is 100Gbps), a 100Mbps link gets cost=1 as well. That's why you must adjust the reference bandwidth to match your fastest links.

OSPF converges in seconds because each router independently calculates paths from the consistent LSDB — no hop-by-hop propagation delay. Link failures trigger immediate LSA floods, and the SPF tree is recalculated. However, SPF recalculations can be CPU-intensive in large topologies; OSPF mitigates this with areas (hierarchical design) and incremental SPF (iSPF).

dijkstra_ospf_simulation.pyPYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# io.thecodeforge.routing.ospf.dijkstra

import heapq

def dijkstra_spf(graph, start):
    """Standard Dijkstra's algorithm returns shortest distances from start."""
    distances = {node: float('inf') for node in graph}
    distances[start] = 0
    priority_queue = [(0, start)]
    visited = set()
    
    while priority_queue:
        current_dist, current_node = heapq.heappop(priority_queue)
        if current_node in visited:
            continue
        visited.add(current_node)
        for neighbor, cost in graph[current_node].items():
            new_dist = current_dist + cost
            if new_dist < distances[neighbor]:
                distances[neighbor] = new_dist
                heapq.heappush(priority_queue, (new_dist, neighbor))
    return distances

# Example topology: routers with OSPF costs
network_graph = {
    'Router1': {'Router2': 10, 'Router3': 5},
    'Router2': {'Router1': 10, 'Router4': 20},
    'Router3': {'Router1': 5, 'Router4': 15},
    'Router4': {'Router2': 20, 'Router3': 15}
}

spf_result = dijkstra_spf(network_graph, 'Router1')
print("Shortest path costs from Router1:")
for dest, cost in spf_result.items():
    print(f"  {dest}: cost = {cost}")
Output
Shortest path costs from Router1:
Router1: cost = 0
Router2: cost = 10
Router3: cost = 5
Router4: cost = 20 (via Router3: 5+15, not via Router2: 10+20=30)
Critical Production Warning: SPF Throttling
In a large OSPF domain (>500 routers), every link failure triggers full SPF recalculations. If you have a flapping link, routers can spend more time calculating SPF than forwarding traffic. Configure 'timers throttle spf' to dampen SPF runs: initial delay 50ms, incremental delay 200ms, maximum delay 5000ms. Also use stub areas or NSSA to reduce LSDB size.
Production Insight
A flapping Ethernet link in a large OSPF area can cause 100% CPU on all routers, turning a local issue into a network-wide meltdown.
Mitigation: set interface dampening, use LSA pacing timers, and monitor 'show process cpu' for OSPF processes.
Rule: never put more than 50 routers in a single OSPF area unless you have a dedicated network operations plan.
Key Takeaway
OSPF's fast convergence comes from two ideas: link-state flooding for consistent topology, and independent SPF calculation.
The cost is CPU bloat during topology changes — mitigate with area design and SPF throttling.
OSPF is the default enterprise IGP because it handles complex topologies well.

BGP — The Internet's Policy Engine

BGP (Border Gateway Protocol) is not a typical routing protocol. It doesn't find the shortest path based on bandwidth or hops. Instead, it exchanges reachability information and applies policy. BGP is a path vector protocol: each route advertisement carries the entire AS_PATH — the list of autonomous systems the route has traversed. This prevents loops (an AS will reject its own AS in the path).

BGP's primary metric is not latency or bandwidth but administrative policy. Network operators use BGP attributes like Local Preference (LOCAL_PREF), Multi-Exit Discriminator (MED), AS_PATH length, and community tags to influence inbound and outbound traffic. BGP decision process has 10+ tie-breaking steps, from highest LOCAL_PREF to lowest IGP metric to the router ID.

BGP convergence is complex — especially after a failure that creates a withdrawn route. The path exploration problem can cause significant delays (minutes) as BGP speakers try alternative paths before giving up. Techniques like BGP prefix independent convergence (PIC) and BGP add-path mitigate this.

bgp-path-selection.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Check BGP table entry for a prefix on a Cisco router
show ip bgp 192.0.2.0/24

# Sample output (abbreviated)
BGP routing table entry for 192.0.2.0/24, version 12345
Paths: (2 available, best #2)
  Path #1: (metric 100) via 203.0.113.1
    AS_PATH: 65001 65002 65003
    Local preference: 100
    MED: 50
  Path #2: (metric 10) via 198.51.100.1
    AS_PATH: 65001 65004 65003
    Local preference: 200
    MED: 20

# Best path is Path #2 due to higher local-preference.
Output
BGP selects Path #2 because Local Preference (200 > 100) is the first tie-breaker.
Mental Model: BGP as a Political System
  • A route is like a treaty: 'I will send traffic to network X through AS Y because we have a peering agreement.'
  • Local Preference is your internal policy: 'I prefer routes learned from my transit provider over my backup.'
  • AS_PATH is a trust measure: shorter path = less intermediation, but longer path may be more reliable.
  • MED is a suggestion: 'I'd prefer you enter my AS through this specific border router.'
  • Communities are tags that convey intent across administrative boundaries.
Production Insight
An accidental redistribution of a default route from one BGP speaker can cause a catastrophic routing blackhole.
This happened to a major cloud provider in 2020 when an internal route leaked to the internet, dropping traffic for hours.
BGP filtering with prefix-lists, AS_PATH filters, and RPKI validation are non-negotiable in production.
Key Takeaway
BGP is the glue of the internet, but it's fragile under misconfiguration.
Always filter inbound and outbound routes — assume your neighbour will make a mistake.
BGP convergence is a sliding scale: you trade control for speed.

Convergence and Performance: Engineering for Fast Recovery

Convergence is the time it takes for all routers to agree on a consistent view of the network after a change. The required convergence time depends on the application: voice traffic can tolerate sub-second outage, email can handle seconds, but financial trading systems require sub-50ms recovery.

RIP converges in tens of seconds to minutes due to hold-down timers and count-to-infinity. OSPF converges in 5-10 seconds with default timers; with BFD this drops to <1 second. BGP convergence is trickier: after a route withdrawal, BGP may explore alternative paths for up to minutes (path exploration).

Production tools to accelerate convergence
  • BFD (Bidirectional Forwarding Detection): sub-second link failure detection independent of routing protocol.
  • BGP PIC (Prefix Independent Convergence): pre-compute backup paths.
  • LFA (Loop-Free Alternate) in OSPF/IS-IS: install a backup next-hop to avoid waiting for SPF.
  • Graceful Restart: allows router to continue forwarding while restarting, if neighbor cooperates.

The trade-off: faster convergence often means more state, more CPU or memory. BFD adds packet overhead. LFA doubles the FIB table size. Choose based on your failure rate and tolerance.

measure-convergence.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Simplified convergence test using ping and cron
# Step 1: On a monitoring server, ping the far end IP continuously
ping -i 0.1 -c 500 far-end-router > /tmp/ping.log &

# Step 2: On the upstream router, shut down the primary link
conf t
interface GigabitEthernet0/0
shutdown

# Step 3: Check ping.log for the longest gap between responses
# Count lost packets, divide by 10 (ping interval 100ms) to estimate convergence time.

# For OSPF with default timers, expect around 5-10 seconds of loss.
# With BFD, loss should be under 1 second.

# Step 4: Restore the link, and repeat for BGP or RIP.
Output
Using default OSPF timers (dead interval 40s): ~30 seconds of packet loss.
With OSPF hello/dead tuned to 1s/4s: ~5 seconds.
With BFD: <1 second.
Production Tip: Test Convergence Before You Need It
Schedule regular convergence tests during maintenance windows. Fail a link, measure the outage with ping or synthetic traffic, and check if the actual convergence matches your design. You'll often discover that a timer mismatch or misconfigured interface dampening kills your SLA.
Production Insight
One large financial firm found that their OSPF convergence was 30 seconds instead of the expected 2 seconds.
Root cause: interface debounce timer was set to 2000ms on the ethernet port, delaying the link-down event before OSPF could even see it.
Rule: always check the physical layer failure detection before blaming the routing protocol.
Key Takeaway
Convergence time is a product of physical detection + protocol reaction + path calculation.
Engineers often look only at protocol timers and miss interface dampening or BFD integration.
Measure, don't assume — your SLA depends on the slowest component in the chain.

Routing Table Decoder: Protocol Codes You'll See in a Crash

When you type show ip route on a Cisco router after a BGP flap, the output isn't just noise. Each prefix has a letter code that tells you how it was learned. That code determines trust, path selection, and failover behavior. L means local — the router's own interface IP. C means directly connected — layer-2 adjacency. S is static, set by a human (or automation) with administrative distance of 1. O is OSPF, R is RIP, D is EIGRP, and B is BGP. Codes like IA (OSPF inter-area) or EX (EIGRP external) tell you the route was redistributed — a common source of suboptimal routing. Memorize these. When a route flips from O to E2 or B to D, you're watching a convergence event in real time. The code is your first diagnostic clue.

decode_routing_table.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// io.thecodeforge
# Simulate a routing table dump during a BGP maintenance window
cat << EOF
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 203.0.113.1 to network 0.0.0.0

O    10.10.0.0/16 [110/2] via 192.168.1.1, 00:12:34, GigabitEthernet0/0
B    172.16.0.0/16 [20/0] via 203.0.113.2, 00:05:22, GigabitEthernet0/1
S    10.0.0.0/8 [1/0] via 10.0.0.1
EOF
Output
(Shows simulated routing table with protocol codes)
Production Trap:
If you see a route coded as 'S' or 'B' flipping to 'D', someone likely redistributed a static into EIGRP without proper route filtering. Your traffic just took a detour through a data center you don't own.
Key Takeaway
The letter code in show ip route tells you the route's origin, trust level, and how it will behave during convergence — never ignore it.

Static vs. Dynamic vs. Default: When to Use Each at Scale

Static routing is for the paranoid. You hardcode every path. Zero overhead. Zero adaptability. At 10 routers, it's manageable. At 100, it's a career-limiting mistake. One typo and you blackhole traffic. Dynamic routing is the default for any network with redundancy. Protocols like OSPF and BGP auto-discover neighbors and converge around failures. The cost is CPU cycles and convergence time measured in seconds. Default routing is your escape hatch. It's the "I don't know where this packet is going, ship it to the gateway" rule. Production networks need all three. Use static for critical loopbacks and management interfaces. Use dynamic for internal transit links. Use a default route pointed at your WAN edge. Never default-route everything into a datacenter unless you enjoy congestion collapse.

RoutingDecision.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// io.thecodeforge
// Simulates routing decision logic based on type
public class RoutingDecision {
    private static final int STATIC_PREFERENCE = 1;
    private static final int DYNAMIC_PREFERENCE = 20;
    private static final int DEFAULT_PREFERENCE = 200;

    public static Route selectBestRoute(List<Route> routes, IpPrefix destination) {
        // Production note: prefer most specific prefix first, then lowest preference
        return routes.stream()
            .filter(r -> r.matches(destination))
            .min(Comparator.comparingInt(Route::getPreference)
                .thenComparing(Route::getPrefixLength)) // longest prefix match
            .orElse(null);
    }

    public static void main(String[] args) {
        List<Route> table = List.of(
            new Route("10.0.0.0/8", "203.0.113.1", STATIC_PREFERENCE),
            new Route("10.0.0.0/16", "192.168.1.1", DYNAMIC_PREFERENCE),
            new Route("0.0.0.0/0", "198.51.100.1", DEFAULT_PREFERENCE)
        );
        Route best = selectBestRoute(table, new IpPrefix("10.0.1.0/24"));
        System.out.println("Selected next hop: " + best.getNextHop());
    }
}

class Route {
    private final String prefix;
    private final String nextHop;
    private final int preference;
    // constructor, getters, matches() omitted for brevity
}
Output
Selected next hop: 192.168.1.1
Production Trap:
Default routes have an administrative distance of 200. If your dynamic protocol fails and the default kicks in, verify your monitoring alerts for 'default route active' — that's the last line of defense, not normal operation.
Key Takeaway
Static for critical, dynamic for scale, default for safety — but always check administrative distance to avoid route hijacking.
● Production incidentPOST-MORTEMseverity: high

OSPF Metric Misconfiguration Caused East-West Traffic to Traverse a Transatlantic Link

Symptom
Users in US-East reported slow responses when accessing US-West services. Network monitoring showed >200ms RTT for what should have been <20ms. Traffic on the US-to-Europe link jumped from 10% to 80% utilisation.
Assumption
The team assumed OSPF would automatically use the shortest path based on bandwidth. They had left the cost on all 10Gbps interfaces at the default (cost=1), thinking it was fine.
Root cause
OSPF cost is inversely proportional to bandwidth by default (cost = reference_bandwidth / interface_bandwidth). With reference_bandwidth=100Mbps, a 10Gbps link also gets cost=1, but so does a 100Mbps link across the Atlantic. Without manual cost tuning, OSPF cannot distinguish link quality — it just sees equal cost paths and load-balances, including the transatlantic one.
Fix
Set the reference bandwidth to a higher value (e.g., 10000 for 10Gbps) and manually assign costs proportional to latency or administratively preferred paths. On the transatlantic link, we set cost=100, and on the direct 10Gbps link cost=1. Then OSPF preferred the direct link exclusively.
Key lesson
  • Never assume default OSPF costs reflect real path quality.
  • Always tune the reference bandwidth to match your fastest links.
  • Use administrative distance or route-maps when simple cost isn't enough.
  • Monitor traffic flows after any routing configuration change — a silent diversion can be worse than a visible outage.
Production debug guideCommon production routing failures and the exact commands to diagnose them4 entries
Symptom · 01
Route flapping on OSPF — routes appear and disappear every few seconds
Fix
Check OSPF neighbor states with 'show ip ospf neighbor' — look for state transitions between FULL and DOWN. Examine interface errors ('show interface') for CRC or duplex mismatches. Fix physical layer first, then adjust OSPF timers.
Symptom · 02
BGP route not being learned even though neighbor is established
Fix
Check 'show ip bgp neighbors x.x.x.x advertised-routes' vs 'received-routes'. Verify inbound prefix-lists and AS_PATH filters. Use 'debug ip bgp updates' (carefully in production) to see what's being filtered.
Symptom · 03
RIP route goes up and down, or routing loop detected
Fix
Check 'show ip rip database' for active routes. Look for metric 16 (unreachable) entries that should not exist. Reduce timers? No — fix the underlying issue: disable split-horizon? Actually ensure all interfaces have split-horizon enabled. Use 'debug ip rip' to see triggered updates.
Symptom · 04
Traffic takes longer path despite a faster link being available
Fix
For OSPF: compare 'show ip ospf interface cost' across all links. For BGP: examine 'show ip bgp x.x.x.x' and look at the path's metric (MED), local preference, and AS_PATH length. The winning path may be a surprise due to tie-breakers.
★ Quick Debug: Routing Protocol IssuesImmediate actions for the three most common routing protocol emergencies
Network-wide connectivity loss after config change
Immediate action
Roll back the last configuration change using 'configure replace' or manually reload the saved config.
Commands
show running-config | section router ospf/rip/bgp — to see what was applied
show ip route — to check if default routes are missing
Fix now
If rollback not possible, add static default routes to re-establish connectivity, then debug the routing protocol.
Routing loop causing high CPU and packet drops+
Immediate action
Block the affected routes with a null0 static route to stop the loop. Then investigate the source.
Commands
show ip route x.x.x.x — check for multiple next hops pointing back to itself
traceroute x.x.x.x — see where TTL expires
Fix now
Add the blackhole route and correct the config that caused the loop (e.g., redistribute with wrong metric).
BGP session resetting repeatedly (flapping)+
Immediate action
Disable the session with 'neighbor shutdown' to stop the flapping, then check keepalive/hold timers and underlying connectivity.
Commands
show ip bgp neighbors x.x.x.x — look for state and last error
ping x.x.x.x source <loopback> — verify path MTU
Fix now
If MTU mismatch, configure 'ip tcp adjust-mss' on the interface. If timer mismatch, align both sides.
RIP vs OSPF vs BGP at a Glance
FeatureRIPOSPFBGP
TypeDistance VectorLink StatePath Vector
MetricHop Count (max 15)Cost (bandwidth-based)Policy (AS_PATH, Local Pref, MED)
AlgorithmBellman-FordDijkstra (SPF)Best Path Selection (10 steps)
ConvergenceMinutes (count-to-infinity)Seconds (SPF recalc)Seconds to minutes (path exploration)
ScalabilitySmall (<15 hops)Medium (areas for scale)Internet-scale (global tables)
Loop PreventionSplit horizon, poison reverseSPF guarantees loop-free treeAS_PATH loop detection
HierarchyFlat onlyAreas (backbone, normal, stub)ASes, confederations, reflectors
Use CaseLegacy/LabEnterprise IGPInter-AS / Internet
Production RiskSlow convergence, bandwidth wasteLSDB explosion, CPU spikesMisconfiguration leaks, convergence delay

Key takeaways

1
Routing protocols are the dynamic brain of the network; static routes are the skeleton.
2
RIP is obsolete for production—count-to-infinity kills convergence.
3
OSPF is fast and scalable with proper area design and SPF throttling.
4
BGP is a policy engine—filter everything and assume your neighbours will leak.
5
Convergence time depends on the weakest link
physical detection, protocol timers, and SPF/BGP processing.
6
Always validate your routing with packet-level traces and synthetic traffic injection.

Common mistakes to avoid

5 patterns
×

Assuming OSPF cost default works for all link speeds

Symptom
Traffic takes suboptimal path because multiple links have the same default cost (e.g., both 1Gbps and 100Mbps get cost=1 with reference bandwidth 100Mbps).
Fix
Set the reference bandwidth to the fastest link speed in your network (e.g., 'auto-cost reference-bandwidth 10000' on Cisco for 10Gbps). Manually assign costs on slower links to reflect latency or your traffic engineering.
×

Not filtering BGP routes inbound and outbound

Symptom
A mistaken route advertisement from your BGP peer leaks your private IP space to the internet, causing traffic blackholes or security exposure. Alternatively, your router learns too many routes and runs out of memory.
Fix
Always apply prefix lists inbound to accept only expected prefixes. Outbound, restrict to your own IP blocks. Use AS_PATH filters to prevent accepting routes from unknown ASes. Implement RPKI for validation.
×

Using RIP in production with default timers

Symptom
A link failure causes 3+ minutes of traffic loss due to count-to-infinity and hold-down timers. Reconvergence is unacceptable for any modern service.
Fix
If you must use RIP, tune timers aggressively (update 5, invalid 15, hold 30) and enable triggered updates. But better: migrate to OSPF or a dynamic routing protocol that converges in seconds.
×

Forgetting to configure OSPF network type on point-to-point links

Symptom
OSPF neighbors connect successfully but form DR/BDR elections unnecessarily, causing extra LSA flooding and suboptimal multicast traffic. On serial links, you may see 'OSPF: NBR state DOWN'.
Fix
Set the interface to point-to-point network type: 'ip ospf network point-to-point'. This eliminates DR election and speeds up convergence.
×

Mismatching BGP timers or update source interface

Symptom
BGP session flapping every few minutes with error 'Hold timer expired' or 'TCP connection lost'. The router uses the wrong source IP for TCP when the BGP session is between loopbacks.
Fix
Always use 'update-source loopback0' in BGP neighbor configuration to ensure the source IP is consistent. Ensure keepalive/hold timers match on both sides.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
Explain the difference between distance vector and link state routing pr...
Q02SENIOR
Describe the BGP best path selection process. How does LOCAL_PREF influe...
Q03SENIOR
How would you debug a routing loop in an OSPF environment?
Q01 of 03SENIOR

Explain the difference between distance vector and link state routing protocols. Give one advantage and one disadvantage of each.

ANSWER
Distance vector protocols (like RIP) share routing tables with neighbors. Each router knows only the distance to each destination via each neighbor. Advantages: simple configuration, low CPU/memory. Disadvantages: slow convergence (count-to-infinity), limited metric (hop count). Link-state protocols (like OSPF) flood link state advertisements so every router builds a complete topology map and runs SPF. Advantages: fast convergence, flexible metric. Disadvantages: higher CPU/memory requirements, complex to tune at scale. In production, most enterprises run OSPF for internal routing and BGP for internet edge.
FAQ · 4 QUESTIONS

Frequently Asked Questions

01
What is a routing protocol and why do I need one?
02
What is the difference between OSPF and BGP?
03
Can I use BGP inside my data centre instead of OSPF?
04
How do I choose a routing protocol for my network?
N
Naren Founder & Principal Engineer

20+ years shipping production systems from the metal up. Lessons pulled from things that broke in production.

Follow
Verified
production tested
May 24, 2026
last updated
1,554
articles · all by Naren
🔥

That's Computer Networks. Mark it forged?

7 min read · try the examples if you haven't

Previous
IP Addressing and Subnetting
9 / 22 · Computer Networks
Next
WebSockets Explained