Networking Fundamentals — Module 17

Dynamic Routing Protocols

A deep-dive into how routers automatically discover, share, and optimize paths through networks — covering OSPF's link-state database, BGP's policy engine, EIGRP's DUAL algorithm, and IS-IS's TLV architecture at production scale.

30–40 min May 2026

// CHAPTER 01

The Routing Arms Race

// REAL-WORLD SCENARIOIt is 1969. ARPANET has four nodes. A human engineer maintains the routing tables. This works fine — there are exactly six possible paths in the entire network.

Fast-forward to 2024. The global internet has over 900,000 BGP prefixes. Tier-1 carriers run networks spanning dozens of countries with thousands of routers. Updating routes by hand is not just impractical — it is physically impossible at the timescales involved. A fiber cut in Tokyo triggers routing convergence across the entire planet within seconds. No human is fast enough. The network must route itself.

Dynamic routing protocols are the answer. They are distributed algorithms that give routers the ability to discover topology, compute optimal paths, and adapt to failures — automatically, continuously, and at global scale.

Dynamic routing protocols solve three fundamental problems: topology discovery (how does a router learn what the network looks like?), path computation (how does it decide which path is best?), and convergence (how does it react when the topology changes?).

Different protocols answer these questions with radically different architectural philosophies. OSPF builds a complete map of the network and runs Dijkstra. BGP is a policy machine that trades path vectors between autonomous systems. EIGRP keeps feasible backups cached for instant failover. IS-IS speaks in TLVs and runs inside the router's management plane. Understanding these differences is not academic — it determines how you design, troubleshoot, and scale every network you build.

🌐BGP Event Storms at Internet Scale

The BGP table at a major IXP contains over 900,000 prefixes, each with multiple paths. Every time a BGP update arrives, the router must re-run best-path selection for the affected prefix and potentially propagate changes to hundreds of peers. During a major route leak, this can generate millions of updates per second — a condition called a BGP event storm.

Classification by Algorithm

Routing protocols fall into three algorithmic families, each with distinct memory and convergence trade-offs:

Distance-vector protocols (RIP, EIGRP in the classical sense) implement a distributed form of Bellman-Ford. Each router knows only distances to destinations and the direction to send packets. Routers share their routing tables with neighbors. Simple to implement, but prone to count-to-infinity problems without additional mechanisms.

Link-state protocols (OSPF, IS-IS) flood topology information to every router in the area. Each router independently computes the SPF tree from the complete link-state database. Converges fast, eliminates routing loops by design, but requires more memory and CPU.

Path-vector protocols (BGP) advertise complete AS-path sequences, eliminating routing loops mathematically. Designed for inter-domain routing where policy controls trump performance. Slow to converge by design — stability is prioritized over speed.

// CHAPTER 02

OSPF — The Link-State Engine

// REAL-WORLD SCENARIOImagine you want to know the fastest route from New York to Los Angeles. One approach: ask your neighbor "how far is LA from you?" and add that to your distance. This is distance-vector — you rely on neighbors' reports and have no direct knowledge of the full map.

Another approach: collect a complete road atlas of the entire country, then compute the shortest path yourself. This is link-state — you flood every road segment in the atlas to every router, and each one independently solves the shortest-path problem with perfect information.

OSPF takes the second approach. Every router in an OSPF area has an identical copy of the link-state database (LSDB), and each independently runs Dijkstra's SPF algorithm. The result: perfectly loop-free routes computed from first principles.

OSPF (Open Shortest Path First) was standardized in RFC 2328 (OSPFv2 for IPv4) and RFC 5340 (OSPFv3 for IPv6). It uses the Dijkstra algorithm to compute a shortest-path tree (SPT) rooted at each router, with cost as the metric. The default cost formula is 10⁸ / bandwidth, meaning higher-bandwidth links have lower cost.

The OSPF LSDB and LSA Types

OSPF routers flood Link State Advertisements (LSAs) to build a shared topology database. Understanding LSA types is critical for designing OSPF in multi-area environments:

LSA Type 1 — Router LSA
  Originated by: every OSPF router
  Scope: single area
  Describes: all links and costs on the originating router

LSA Type 2 — Network LSA
  Originated by: the Designated Router (DR) on broadcast/NBMA segments
  Scope: single area
  Describes: all routers attached to the multi-access segment

LSA Type 3 — Summary LSA
  Originated by: Area Border Routers (ABRs)
  Scope: floods into other areas
  Describes: inter-area routes (distance to a prefix in another area)

LSA Type 4 — ASBR Summary LSA
  Originated by: ABRs
  Scope: all non-stub areas
  Describes: how to reach an ASBR (Autonomous System Boundary Router)

LSA Type 5 — AS External LSA
  Originated by: ASBRs
  Scope: all non-stub areas (entire OSPF domain)
  Describes: routes redistributed from outside OSPF

LSA Type 7 — NSSA External LSA
  Originated by: ASBRs inside a Not-So-Stubby Area
  Scope: NSSA only (converted to Type 5 by ABR at area boundary)

⚠ LSA Type 3 carries prefix/cost only — not the source area's topologyLSA Type 3 does NOT carry the actual topology of the source area — only the prefix and its cost as seen from the ABR. Routers in other areas cannot run SPF against the source area's topology; they treat inter-area routes as distance-vector information. This is a fundamental limitation of OSPF's area hierarchy.

DR and BDR Election on Broadcast Segments

On Ethernet segments, OSPF elects a Designated Router (DR) and Backup Designated Router (BDR) to reduce adjacency overhead. Without DR/BDR, n routers on one segment would form n(n-1)/2 adjacencies. With DR/BDR, every router forms a full adjacency only with the DR and BDR — reducing it to O(n) relationships.

DR election uses OSPF priority (0–255, default 1; 0 means ineligible), then Router-ID as a tiebreaker. The DR uses multicast address 224.0.0.6 (AllDRRouters) while non-DR routers use 224.0.0.5 (AllSPFRouters).

🗳️OSPF DR Election is Non-Preemptive

Once a DR is elected, it does NOT re-elect when a higher-priority router joins the segment. OSPF is non-preemptive for DR/BDR. A router with priority 255 joining an existing broadcast segment will become BDR (if the current BDR has lower priority), but will only become DR when the current DR fails. This prevents unnecessary reconvergence.

OSPF Area Design

Areas reduce SPF computation overhead and limit LSA flooding scope. All areas must connect to Area 0 (backbone), either directly or through a virtual link. The backbone area floods Type 3 summaries between non-backbone areas.

Special area types reduce routing table size by filtering external LSAs:

• Stub Area: blocks Type 5 LSAs. ABR injects a default route (Type 3). No external routes, but intra-area and inter-area routes still present.

• Totally Stubby Area (Cisco extension): blocks Type 3, 4, and 5 LSAs. Only intra-area routes + one default. Extreme simplification for spoke sites.

• Not-So-Stubby Area (NSSA): blocks Type 5 but allows redistribution via Type 7. Converted to Type 5 by the ABR at the boundary. Useful for branch sites with their own external connectivity.

# Verify OSPF LSDB
show ip ospf database                    # All LSAs summary
show ip ospf database router             # Type 1 LSAs
show ip ospf database network            # Type 2 LSAs
show ip ospf database summary            # Type 3 LSAs
show ip ospf database external           # Type 5 LSAs

# Check neighbor states
show ip ospf neighbor

# Verify SPF calculation
show ip ospf statistics                  # SPF run count and timing

# Area authentication
router ospf 1
  area 0 authentication message-digest   # MD5 auth for Area 0

// CHAPTER 03

The OSPF Neighbor State Machine

// REAL-WORLD SCENARIOTwo routers meet for the first time on an Ethernet segment. They don't immediately trust each other with their entire routing tables. Instead, they go through a careful eight-step handshake — each step building more trust and more information sharing than the last.

Think of it as two strangers becoming business partners. First you see them across the room (Init). Then you get a handshake and business card exchange (2-Way). Then you negotiate who speaks first (ExStart). Then you exchange company portfolios (Exchange). Then you call for missing details (Loading). Finally, you're fully synchronized and ready to work together (Full).

OSPF Neighbor State Machine

Show NBMA Attempt state

Down

▶

Init

▶

2-Way

▶

ExStart

▶

Exchange

▶

Full

DownHello

No hello packets received. The neighbor relationship has not started or has timed out (Dead Interval expired).

Trigger → Start: Hello sent

The most common production issue is routers stuck in EXSTART/EXCHANGE. This is almost always an MTU mismatch — one side has a 1500-byte interface, the other has jumbo frames (9000 bytes). DBD packets exceeding the MTU are silently dropped, and the state machine hangs. Fix: match MTU on both sides or use ip ospf mtu-ignore as a workaround.

Routers stuck at 2-WAY on a broadcast segment is expected behavior for non-DR/BDR routers — they form 2-Way with each other but Full adjacency only with DR and BDR. This is by design, not a fault.

! Troubleshoot stuck OSPF adjacency
debug ip ospf adj
debug ip ospf hello

! MTU mismatch fix
interface GigabitEthernet0/0
  ip ospf mtu-ignore          ! Workaround — better to fix MTU

! Authentication mismatch (key mismatch shows as stuck at EXSTART)
interface GigabitEthernet0/0
  ip ospf authentication message-digest
  ip ospf message-digest-key 1 md5 SecretKey123

⚠ Hello/Dead interval mismatch silently prevents OSPF adjacencyIf an OSPF neighbor relationship flaps between Down and Init repeatedly, check Hello/Dead interval mismatches. Default Hello is 10s (P2P/broadcast) or 30s (NBMA); Dead is 4× Hello. Mismatched intervals prevent adjacency from forming — OSPF will log "Mismatched hello parameters" and discard the Hello packet.

// CHAPTER 04

OSPF Convergence and SPF Scheduling

// REAL-WORLD SCENARIOA fiber cable is cut. The router on one end of the link detects the loss of carrier and immediately sends a Router LSA announcing the link is down. This LSA floods across the area within milliseconds. Every router in the area receives it, updates its LSDB, and schedules an SPF computation. But SPF is expensive — Dijkstra on a large LSDB can take tens of milliseconds. You can't run it for every single topology change in real time.

This is why OSPF uses SPF delay and throttling. The first SPF after an event runs almost immediately. If more changes arrive, subsequent SPF runs are delayed exponentially to prevent CPU saturation during network instability.

Modern OSPF implementations use SPF throttle timers with three values: initial delay, minimum hold, and maximum hold. RFC 3137 defines this as an exponential back-off. Cisco IOS defaults: timers throttle spf 50 200 5000 — meaning 50ms initial delay, doubling hold times up to 5000ms maximum.

Similarly, LSA generation is throttled with timers throttle lsa to prevent LSA storms from overwhelming OSPF flooding. The default in modern IOS: 50ms initial, 200ms minimum hold, 5000ms maximum.

Incremental SPF (iSPF)

Full SPF recomputes the entire shortest-path tree. Incremental SPF (iSPF) only recomputes the branches of the tree affected by the topology change, dramatically reducing CPU load in large networks. iSPF is triggered when only leaf nodes change (external routes, stub networks) and the tree structure itself is unchanged.

🔄OSPF's Constant LSA Heartbeat

OSPF LSAs have a MaxAge of 3600 seconds (one hour). Routers must refresh all self-originated LSAs before they hit MaxAge to prevent topology information from being flushed. In a 1000-router network, each router refreshes ~20 LSAs every hour — this generates a constant background flood of LSAs that never fully stops. It is the "heartbeat" of the OSPF domain.

Fast Hello and BFD

Default OSPF Hello is 10 seconds with a 40-second Dead interval. For fast convergence, options are:

• Fast Hello: sub-second Hello intervals (e.g., 1s/3s or 500ms). Works at the OSPF level but adds overhead and is limited by the OSPF process scheduler.

• BFD (Bidirectional Forwarding Detection): hardware-assisted failure detection operating independently of OSPF at 50–300ms intervals. BFD notifies OSPF immediately on link failure without waiting for Hello timeout. This is the production standard for sub-second convergence.

! Enable BFD for OSPF
router ospf 1
  bfd all-interfaces                       ! Enable BFD on all OSPF interfaces

interface GigabitEthernet0/1
  bfd interval 100 min_rx 100 multiplier 3 ! 300ms detection time

! Fast Hello (alternative — less preferred than BFD)
interface GigabitEthernet0/1
  ip ospf hello-interval 1
  ip ospf dead-interval 3

// CHAPTER 05

BGP — The Internet's Policy Engine

// REAL-WORLD SCENARIOOSPF is designed for a single organization's network — a place where everyone trusts everyone and the goal is purely performance. BGP is designed for the opposite: the global internet, where thousands of independent organizations connect and each has its own business policies about what traffic it carries, for whom, and at what cost.

When Comcast (AS 7922) and AT'T (AS 7018) connect at an Internet Exchange, they don't want AT'T running Dijkstra on Comcast's internal topology. They exchange only reachability information: "I can reach 192.0.2.0/24 via this path." Each side applies its own policies — which routes to accept, which to prefer, which to advertise to others.

BGP is not an optimization algorithm. It is a policy distribution mechanism dressed up as a routing protocol.

BGP (Border Gateway Protocol, RFC 4271) is the only EGP (Exterior Gateway Protocol) in production use on the internet. It operates between Autonomous Systems (ASes) — administratively distinct networks identified by 16-bit (original) or 32-bit (RFC 6793) AS numbers. IANA assigns public ASNs; private ASNs (64512–65534 for 16-bit, 4200000000–4294967294 for 32-bit) are used internally.

iBGP vs eBGP

BGP runs in two modes: eBGP (between different ASes) and iBGP (within the same AS). The differences are significant:

• eBGP: TTL=1 by default (direct connection required unless multihop configured). Routes received via eBGP are redistributed to iBGP peers and IGP.

• iBGP: TTL=255. iBGP does NOT re-advertise routes learned from one iBGP peer to other iBGP peers (the iBGP split-horizon rule). This prevents loops but requires full mesh or route reflectors.

• iBGP full mesh scales as O(n²) — 50 routers require 1225 sessions. Route Reflectors (RRs) break the full-mesh requirement by allowing a cluster of routers to share iBGP routes via a central reflector.

! Basic BGP configuration
router bgp 65001
  bgp router-id 10.0.0.1
  neighbor 203.0.113.1 remote-as 65002          ! eBGP peer (ISP)
  neighbor 203.0.113.1 description ISP-A
  neighbor 10.255.0.2 remote-as 65001            ! iBGP peer (internal)
  neighbor 10.255.0.2 update-source Loopback0
  !
  address-family ipv4 unicast
    network 192.0.2.0 mask 255.255.255.0         ! Advertise this prefix
    neighbor 203.0.113.1 activate
    neighbor 203.0.113.1 soft-reconfiguration inbound
    neighbor 10.255.0.2 activate
    neighbor 10.255.0.2 next-hop-self            ! Fix iBGP next-hop issue

! Route Reflector
router bgp 65001
  neighbor 10.255.0.3 remote-as 65001
  neighbor 10.255.0.3 route-reflector-client     ! This peer is an RR client

⚠ iBGP next-hop must be reachable via IGP — use next-hop-selfiBGP next-hop is not changed by default — the eBGP next-hop (an external IP) is advertised to iBGP peers as-is. If iBGP peers cannot reach that external IP via IGP, routes will be in the BGP table but marked as unreachable (no route to next-hop). Always configure next-hop-self on iBGP sessions unless you are running IGP redistribution of external prefixes.

// CHAPTER 06

BGP Path Attributes and Best-Path Selection

// REAL-WORLD SCENARIOTwo internet service providers both offer you a route to 8.8.8.0/24 (Google DNS). One is cheaper and domestic; the other is slower but redundant. Which should be the primary path? Which should be the backup? And what happens if you want to send some traffic via each?

BGP doesn't decide this for you — it gives you a rich toolkit of attributes and a deterministic selection algorithm. You express your business policy through those attributes, and BGP faithfully enforces it across every router in your AS. This is why BGP is a policy engine, not an optimizer.

BGP path attributes are classified by type: well-known mandatory (must be present in every update: ORIGIN, AS_PATH, NEXT_HOP), well-known discretionary (understood by all but optional: LOCAL_PREF, ATOMIC_AGGREGATE), optional transitive (may be forwarded even if not understood: COMMUNITY, AGGREGATOR), and optional non-transitive (not forwarded if not understood: MED, ORIGINATOR_ID).

BGP Best-Path Selection Wizard

Step through BGP's decision process to see which path wins and why.

Step 1: Weight (highest wins)

Cisco-proprietary, local router only. Not advertised to peers.

Peer	Weight	LOCAL_PREF	AS_PATH	Origin	MED	Type	Status
ISP-A (eBGP)	100	100	3	IGP	50	eBGP	BEST
ISP-B (eBGP)	0	150	2	IGP	100	eBGP	Eliminated
iBGP Peer	0	150	2	EGP	80	iBGP	Eliminated
iBGP RR	0	150	1	IGP	80	iBGP	Eliminated

BGP Communities

Communities are 32-bit tags (format AS:value) attached to routes for signaling policy. They are the BGP operator's primary tool for controlling what happens to routes as they traverse the network:

• NO_EXPORT (0xFFFFFF01): do not advertise beyond the local AS boundary.

• NO_ADVERTISE (0xFFFFFF02): do not advertise to any BGP peer.

• INTERNET (0x00000000): advertise to the entire internet (default behavior).

• Large communities (RFC 8092): three 32-bit values (Global Admin:Local Data 1:Local Data 2), enabling more precise signaling between operators.

! BGP community-based routing policy
route-map SET_COMMUNITY permit 10
  match ip address prefix-list CUSTOMER_ROUTES
  set community 65001:100                ! Tag customer routes

route-map PEER_EXPORT permit 10
  match community COMM_100
  set local-preference 200              ! Prefer routes with this community

! AS-path prepending for traffic engineering
route-map PREPEND_ASPATH permit 10
  set as-path prepend 65001 65001 65001  ! Prepend 3x to make path less preferred

! Verify BGP attributes
show bgp ipv4 unicast 192.0.2.0/24
show bgp ipv4 unicast neighbors 203.0.113.1 routes
show bgp ipv4 unicast regexp _65002_     ! Regex on AS-PATH

🕳️Remote Triggered Black Hole (RTBH) Filtering

BGP communities enable a practice called BLACKHOLE routing: a DDoS target announces its prefix with community 65535:666 (or operator-specific variants) to upstream providers, who then drop all traffic destined for that prefix at their edge — preventing DDoS traffic from ever reaching the victim's network. This is called Remote Triggered Black Hole (RTBH) filtering and is a standard DDoS mitigation technique used by virtually every major ISP.

// CHAPTER 07

EIGRP and the DUAL Algorithm

// REAL-WORLD SCENARIOMost routing protocols must recompute all paths when the topology changes. After a link failure, OSPF recomputes the entire SPF tree. RIP counts to infinity before finding an alternate route. Both approaches take time during which traffic is dropped.

Cisco's EIGRP (Enhanced Interior Gateway Routing Protocol) takes a fundamentally different approach. Before a failure occurs, it pre-computes backup paths that are guaranteed to be loop-free. When a failure hits, it activates the backup path immediately — no computation, no queries, no waiting. Sub-second failover without needing BFD.

The algorithm that makes this possible is DUAL: the Diffusing Update Algorithm, developed by J.J. Garcia-Luna-Aceves.

EIGRP uses composite metric based on bandwidth, delay, load, and reliability (the latter two disabled by default). The effective metric formula (simplified) is: metric = (K1 × bandwidth + K3 × delay) × 256 where bandwidth = 10⁷ / min_bandwidth_kbps and delay = sum_delay / 10 (in tens of microseconds).

Feasible Distance and Reported Distance

EIGRP tracks two distances for each route:

• Feasible Distance (FD): the best metric this router has ever computed to reach a destination. The FD of the current best path is stored in the topology table.

• Reported Distance (RD) (also called Advertised Distance): the metric that a neighbor reports for reaching the destination — i.e., the cost from that neighbor to the destination, not including the link to the neighbor.

The Feasibility Condition is the core of DUAL: a path is a loop-free backup (Feasible Successor) if and only if its RD is strictly less than the FD of the Successor. This condition mathematically guarantees that the backup router is not using our current router in its own path — no loops are possible.

EIGRP DUAL — Feasibility Condition Simulator

Drag the Successor FD slider to see which paths qualify as Feasible Successors. Feasibility Condition: RD of candidate < FD of Successor.

Successor Feasible Distance (FD): 150

120 (low cost)210 (high cost)

Path via R1 (Successor)

FD: 150 RD: 100Successor

This is the Successor — best path, FD = 150

Path via R2

FD: 180 RD: 120FS

RD 120 < FD 150 → Feasibility Condition met → Feasible Successor

Path via R3

FD: 200 RD: 160Neither

RD 160 ≥ FD 150 → Feasibility Condition FAILS → Not an FS

Path via R4

FD: 190 RD: 145FS

RD 145 < FD 150 → Feasibility Condition met → Feasible Successor

Why this matters: Feasible Successors provide loop-free backup paths that DUAL can activate instantly without querying the network — achieving sub-second failover. Routes that fail the feasibility condition require a full DUAL diffusing computation before they can be used.

EIGRP Active/Passive States

Each route in EIGRP is either Passive (stable, in the routing table) or Active (undergoing DUAL diffusing computation after losing all feasible successors). During Active state, the router sends queries to all neighbors. If a query goes unanswered for the Active Timer (default 3 minutes), the router logs a Stuck in Active (SIA) error and resets the neighbor relationship.

⚠ Stuck in Active (SIA) cascades when EIGRP queries propagate too farSIA (Stuck in Active) is one of the most disruptive EIGRP events. It occurs when a query propagates too far into the network — commonly caused by poor EIGRP summarization design. Large, flat EIGRP domains with no route summarization can have SIA propagate across hundreds of routers, causing massive session resets. Always summarize EIGRP routes at distribution/aggregation boundaries to limit query scope.

! EIGRP configuration
router eigrp 100
  network 10.0.0.0 0.255.255.255
  eigrp router-id 1.1.1.1
  no auto-summary                          ! Disable classful auto-summarization

! Manual summarization to limit SIA scope
interface GigabitEthernet0/1
  ip summary-address eigrp 100 10.1.0.0 255.255.0.0

! Verify EIGRP topology table
show ip eigrp topology                     ! All routes: successors and FSes
show ip eigrp topology all-links           ! Include non-feasible paths
show ip eigrp topology active              ! Only routes in Active state (SIA risk)

! Tune DUAL timers
router eigrp 100
  timers active-time 1                     ! Reduce SIA timer to 1 minute

// CHAPTER 08

IS-IS — The Service Provider Favorite

// REAL-WORLD SCENARIOIn the 1980s, when OSI protocols were competing with TCP/IP for internet adoption, ISO developed IS-IS (Intermediate System to Intermediate System) as a link-state protocol for OSI networks. TCP/IP won the war, but IS-IS survived in a curious way — it was retrofitted to carry IPv4 routes, and then IPv6. The result is a protocol that operates outside of IP entirely: IS-IS runs at Layer 2, using its own PDU types, and can carry any network layer payload. This independence from IP makes it almost impossible to accidentally break IS-IS by misconfiguring IP.

Tier-1 carriers and hyperscalers often prefer IS-IS over OSPF for this exact reason: it is immune to IP-layer misconfigurations, runs faster on large topologies due to its simpler flooding model, and supports multi-topology (MT) operation natively.

IS-IS uses TLV (Type-Length-Value) encoding for all information, making it naturally extensible. New TLVs can be added for new address families (IPv6 TLV 236, segment routing TLV 135, etc.) without breaking existing implementations. OSPF, by contrast, uses fixed-format LSA types that require protocol revisions for major extensions.

IS-IS Levels and Areas

IS-IS organizes topology into Level 1 (L1) and Level 2 (L2) hierarchies, analogous to OSPF areas but with different semantics:

• L1 routers: know only topology within their area. Route toward the nearest L1/L2 router for destinations outside the area (using the "attached" bit).

• L2 routers: form the backbone. Know all inter-area topology. Analogous to OSPF backbone.

• L1/L2 routers: border routers with both databases. Redistribute routes between L1 and L2 LSPs. Analogous to ABRs.

IS-IS addresses use NET (Network Entity Title) instead of router IDs: format XX.XXXX.XXXX.XXXX.XX (area.system-id.selector). The system-id is typically derived from the loopback IP.

! IS-IS configuration (IOS-XR style — common on SP gear)
router isis 1
  net 49.0001.0100.0000.0001.00       ! Area 49.0001, System-ID 0100.0000.0001
  is-type level-2-only               ! L2-only — backbone role
  address-family ipv4 unicast
    metric-style wide                 ! Wide metrics (32-bit, required for TE/SR)
  !
  interface GigabitEthernet0/0/0/0
    address-family ipv4 unicast
      metric 10
    circuit-type level-2-only

! IS-IS with Segment Routing (modern SP config)
router isis 1
  address-family ipv4 unicast
    segment-routing mpls              ! Enable SR-MPLS
  !
  interface Loopback0
    address-family ipv4 unicast
      prefix-sid index 1              ! Assign node SID

! Verify IS-IS
show isis neighbors
show isis database                    ! All LSPs in topology
show isis topology                    ! SPF computed paths

⚡Hyperscalers Run IS-IS, Not OSPF

Google, Facebook (Meta), Amazon, and most hyperscalers run IS-IS (not OSPF) as their internal IGP. IS-IS's TLV extensibility makes it easy to add Segment Routing, traffic engineering, and flexible algorithm extensions. Google's internal network runs IS-IS with a custom traffic engineering extension that rebalances traffic across their planet-scale data center interconnect every few seconds.

// CHAPTER 09

Redistribution — Connecting Different Routing Domains

// REAL-WORLD SCENARIOA company acquires a competitor. The acquirer runs OSPF. The acquired company runs EIGRP. Customers need to reach resources in both networks immediately. The network team has six months before the full migration is complete. The solution: route redistribution — importing routes from one protocol into another.

Redistribution is powerful and dangerous in equal measure. Done wrong, it creates feedback loops, black holes, and routing instability that can take days to diagnose. Done right, it enables seamless coexistence of multiple routing domains with surgical control over what information crosses each boundary.

Redistribution copies routes from one protocol's database into another. The receiving protocol treats redistributed routes as external (OSPF Type E2 by default, EIGRP external). Critically, redistributed routes carry the Administrative Distance (AD) of the receiving protocol for comparison with internal routes.

The Mutual Redistribution Problem

Bidirectional redistribution between two protocols creates feedback loops. Route A is learned by OSPF, redistributed into EIGRP, and then redistributed back into OSPF — now appearing as an OSPF external route with a higher AD than the original OSPF internal route. The same prefix is known via two different OSPF paths with different costs, potentially causing sub-optimal routing or oscillation.

Prevention mechanisms:

• Route tags: tag routes when redistributing into Protocol B. When redistributing back into Protocol A, filter routes with that tag. This prevents routes from bouncing back.

• Prefix-list filtering: explicitly enumerate which prefixes cross each boundary. More maintenance overhead but more precise.

• Administrative Distance manipulation: adjust AD of redistributed routes so internal routes always win over re-redistributed ones.

! Safe bidirectional redistribution with route tags
! -- On OSPF-to-EIGRP boundary router --
router eigrp 100
  redistribute ospf 1 metric 10000 100 255 1 1500 route-map OSPF_TO_EIGRP

route-map OSPF_TO_EIGRP permit 10
  match ip address prefix-list OSPF_PREFIXES
  set tag 100                              ! Tag OSPF->EIGRP routes

router ospf 1
  redistribute eigrp 100 subnets route-map EIGRP_TO_OSPF

route-map EIGRP_TO_OSPF deny 10
  match tag 100                            ! Block routes that came from OSPF
route-map EIGRP_TO_OSPF permit 20
  match ip address prefix-list EIGRP_NATIVE

⚠ OSPF E2 (default) ignores internal path cost — use E1 for multi-ASBR setupsOSPF E1 vs E2 metrics matter critically in redistribution. E2 (default) keeps the external metric constant regardless of internal path cost — a closer ASBR is not preferred over a farther one if the external cost is the same. E1 adds the internal path cost to the external metric. Use E1 when multiple ASBRs redistribute the same prefix to ensure traffic takes the shortest total path.

// CHAPTER 10

BGP Convergence and Route Dampening

// REAL-WORLD SCENARIOA router somewhere in AS 7018 has a flaky optical transceiver. Every 30 seconds, its BGP session to a peer drops and re-establishes. Each drop and re-establishment propagates an UPDATE and a WITHDRAW to that peer, who propagates it to their peers, who propagate it further. A single flapping prefix can generate millions of UPDATE messages that cascade across the global BGP table — a BGP event storm.

Route dampening is BGP's defense mechanism. Each time a prefix flaps, it accumulates a penalty. When the penalty exceeds a suppress-limit, the route is suppressed (hidden from the routing table). The penalty decays exponentially over time, and once it falls below the reuse threshold, the route is restored. Chronic flappers are suppressed for hours; occasional transients are tolerated.

BGP convergence is intentionally slow compared to IGPs. The MRAI (Minimum Route Advertisement Interval) timer (default 30s for eBGP, 5s for iBGP) delays advertisement of new best paths. This prevents rapid topology changes from being propagated globally before they stabilize. The tradeoff: even a simple link failure can take 30–90 seconds to fully converge across the internet.

BGP Timer Tuning

Production networks balance convergence speed against stability:

! Aggressive BGP timers for faster convergence
router bgp 65001
  neighbor 203.0.113.1 timers 10 30          ! Hello 10s, Hold 30s (default 60/180)
  neighbor 203.0.113.1 timers connect 5      ! Reconnect faster after session drop

! BGP route dampening
router bgp 65001
  bgp dampening 15 750 2000 60               ! Half-life 15min, reuse 750, suppress 2000, max-suppress 60min

! Graceful restart (preserve forwarding during BGP restart)
router bgp 65001
  bgp graceful-restart
  bgp graceful-restart restart-time 120
  bgp graceful-restart stalepath-time 360

! BFD for BGP — detect failure in milliseconds
router bgp 65001
  neighbor 203.0.113.1 fall-over bfd         ! BGP tears down session on BFD failure

🚨The 2010 Telefonica Route Leak

During the 2010 Telefonica route leak, approximately 40,000 routes were accidentally re-advertised with AS-path modifications, attracting traffic from multiple continents through a single PoP in Spain. BGP's path-vector mechanism meant the bad routes spread to hundreds of ASes within minutes before operators could apply filters. The incident highlighted how a single misconfigured router can briefly redirect global internet traffic.

// CHAPTER 11

Modern DC Routing — BGP in the Data Center

// REAL-WORLD SCENARIOHyperscale data centers have tens of thousands of servers, hundreds of top-of-rack switches, and dozens of spine switches — all requiring IP connectivity at sub-millisecond convergence with no single point of failure. Traditional IGPs like OSPF were designed for campus and WAN topologies, not the Clos fabric of a modern data center.

The answer that Facebook, Microsoft, and Google converged on independently: run eBGP — not OSPF — inside the data center. Each pod gets its own AS number. Spines have their own ASes. Leaves peer with spines via eBGP. This creates a hierarchy of autonomous systems where each layer can apply policy, filter routes, and fail independently.

It sounds bizarre to run an inter-AS protocol inside a single building. But BGP's properties — policy control, explicit AS-path, no SPF recomputation storms — make it ideal for the massive scale and operational discipline of hyperscale infrastructure.

The BGP Unnumbered RFC 5549 technique allows BGP sessions to form over IPv6 link-local addresses without requiring IP address assignment on every P2P link. Combined with RFC 7938 ("Use of BGP for Routing in Large-Scale Data Centers"), this is the architecture that powers AWS, Azure, and Google Cloud's internal fabric.

EVPN/VXLAN

Modern data center overlays use VXLAN (RFC 7348) to tunnel Layer 2 frames across a Layer 3 underlay fabric. The control plane for VXLAN is BGP EVPN (RFC 7432), which distributes MAC/IP binding information using BGP address family L2VPN EVPN.

BGP EVPN route types relevant to VXLAN:

• Type 2: MAC/IP Advertisement — maps MAC and IP to a VNI and VTEP IP.

• Type 3: Inclusive Multicast Ethernet Tag — advertises VTEP presence for BUM (Broadcast/Unknown/Multicast) traffic handling.

• Type 5: IP Prefix Route — for inter-VNI IP routing (symmetric IRB).

! BGP EVPN/VXLAN spine configuration (NX-OS)
feature bgp
feature vn-segment-vlan-based
feature nv overlay

vlan 10
  vn-segment 10010                            ! VXLAN VNI 10010

interface nve1
  no shutdown
  host-reachability protocol bgp
  source-interface loopback0
  member vni 10010 associate-vrf              ! L3 VNI for routing

router bgp 65100
  address-family l2vpn evpn
    advertise-pip                             ! Enable per-instance IP for anycast
  neighbor 10.255.0.1
    address-family l2vpn evpn
      send-community extended                 ! Required for EVPN extended communities

! Verify EVPN
show bgp l2vpn evpn summary
show bgp l2vpn evpn route-type 2 0           ! MAC/IP routes
show nve peers

// CHAPTER 12

Troubleshooting Dynamic Routing

// REAL-WORLD SCENARIOA network engineer gets paged at 2 AM. Customers cannot reach the company's web servers. Ping to the server IP fails from the outside. Ping from inside works fine. The firewall team says the rules are unchanged. The server team says the servers are up and responding locally.

The problem turns out to be a BGP route. The upstream ISP stopped advertising the company's prefix to the internet — the BGP session had gone down hours earlier due to a certificate expiry on MD5 authentication, and no one noticed. The route was simply absent from the global routing table.

Routing troubleshooting requires a systematic top-down approach: verify the prefix is in the routing table, verify the BGP/OSPF session is up, verify the route is being advertised, verify the route is being received by peers. Every step has a specific show command.

OSPF Troubleshooting Checklist

! 1. Verify adjacencies
show ip ospf neighbor

! 2. Check LSDB completeness (compare across routers)
show ip ospf database router | include Router ID
show ip ospf database | count Type-5

! 3. Verify route in routing table
show ip route ospf
show ip route 10.1.2.0

! 4. Check SPF scheduling
show ip ospf statistics        ! SPF run count -- excessive = instability

! 5. Verify area configuration consistency
show ip ospf              ! Check area IDs, types, stub flags

! 6. Debug with care (high CPU impact)
debug ip ospf events       ! neighbor state changes
debug ip ospf adj          ! adjacency formation details

BGP Troubleshooting Checklist

! 1. Session state
show bgp summary                           ! All neighbors, states, prefix counts
show bgp neighbors 203.0.113.1 | include BGP state

! 2. Prefix received from peer
show bgp ipv4 unicast neighbors 203.0.113.1 received-routes

! 3. Prefix in BGP table (after policy)
show bgp ipv4 unicast neighbors 203.0.113.1 routes

! 4. Why is a route not best?
show bgp ipv4 unicast 192.0.2.0/24        ! Shows all paths + best path markers

! 5. What is being advertised to a peer
show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes

! 6. Policy applied to a prefix
debug ip bgp 203.0.113.1 updates         ! Live update debug (careful on busy sessions)

A route appearing in received-routes but not in routes means a route-map or prefix-list is filtering it inbound. A route in routes but not in advertised-routes means an outbound policy is suppressing it or the route failed next-hop validation.

// CHAPTER 13

Common Misconceptions

✗ Common Mistake — OSPF always produces optimal pathsOSPF always produces optimal paths. OSPF uses the Dijkstra algorithm to compute the shortest path by metric, but the metric itself may not reflect actual bandwidth or latency. Default OSPF cost = 10⁸/bandwidth — a 100 Mbps link and a 1 Gbps link both get cost 1 using this formula (both below the reference bandwidth). Set auto-cost reference-bandwidth 100000 (100 Gbps) to ensure costs differentiate modern link speeds.

✗ Common Mistake — BGP slow convergence is a bug that can be fixedBGP slow convergence is a bug that can be fixed. BGP's slow convergence (30s MRAI timer) is intentional design, not a bug. It prevents global route oscillation by damping rapid changes before they propagate. While timers can be tuned for specific sessions (e.g., reducing to 1s for iBGP), aggressively reducing eBGP timers on full-table sessions can trigger CPU saturation during route flaps. The right tool for fast convergence is BFD + graceful restart, not aggressive BGP timers.

✗ Common Mistake — EIGRP's composite metric always picks the best pathEIGRP's composite metric always chooses the best path. EIGRP's composite metric weights bandwidth and delay by default (K1=1, K3=1, K2=K4=K5=0). Load and reliability are intentionally disabled because they fluctuate rapidly and cause route instability. The "best" path by EIGRP metric may differ from actual best path by latency. For latency-sensitive applications, use DSCP-based QoS policies rather than relying on EIGRP metric tuning.

✗ Common Mistake — IS-IS is only for service providersIS-IS is only for service providers. While IS-IS is dominant in SP networks, it is increasingly used in data center spine-leaf fabrics and enterprise networks that need SR-MPLS or Flexible Algorithm support. IS-IS's TLV extensibility makes adding new capabilities (SPRING, SRv6, flexible algorithms) much cleaner than OSPF opaque LSAs. The learning curve is steeper, but the operational benefits justify it at scale.

✗ Common Mistake — Route redistribution is safe if done carefullyRoute redistribution between protocols is safe if done carefully. Even "careful" redistribution introduces suboptimal routing, metric translation artifacts, and potential for routing feedback loops. The AD of redistributed routes (OSPF external = 110, EIGRP external = 170) means that if a loop forms, the re-redistributed route may win over the original. Redistribute only when necessary, use strict tagging and filtering, and monitor for route count anomalies after enabling redistribution.

✗ Common Mistake — OSPF Full adjacency guarantees the route is in the routing tableFull OSPF adjacency (state Full) means the route is in the routing table. A router can be Full with an OSPF neighbor yet the route can still be absent from the routing table. Causes: the route exists in the LSDB but SPF cannot find a valid path (discontiguous area, missing Type 4 LSA for ASBR, OSPF cost overflow), or the route is installed in the RIB but overridden by a higher-AD protocol for the same prefix. Always verify with show ip route, not just show ip ospf neighbor.

// CHAPTER 14

Depth Check

Beginner

What is the difference between distance-vector and link-state routing protocols?

Distance-vector protocols share only their routing table with neighbors (Bellman-Ford). Link-state protocols flood full topology information and each router independently computes paths (Dijkstra). OSPF and IS-IS are link-state; RIP is distance-vector; EIGRP uses DUAL which has characteristics of both.

Intermediate

Why does OSPF require all areas to connect to Area 0, and what is a virtual link?

OSPF Area 0 (backbone) is responsible for inter-area route distribution. Non-backbone areas must connect to it so that inter-area routes are distributed without loops. A virtual link creates a logical adjacency through a transit area when physical connectivity to Area 0 is unavailable — the virtual link traverses the transit area using unicast. It is a workaround, not a design choice — architectural redesign is always preferable.

Intermediate

Explain the iBGP split-horizon rule and why route reflectors solve it.

iBGP does not re-advertise routes learned from an iBGP peer to another iBGP peer — this prevents routing loops within an AS. But it requires full mesh (n² sessions) for all routers to see all routes. Route reflectors break this requirement: an RR re-advertises routes between its clients (adding ORIGINATOR_ID and CLUSTER_LIST attributes to detect loops). Multiple RRs can be deployed for redundancy, creating a hierarchical iBGP topology without full mesh.

Senior

What is the DUAL feasibility condition and why does it guarantee loop-free paths?

DUAL's feasibility condition states: a neighbor's path is a loop-free backup if its Reported Distance (RD) is strictly less than the local router's current Feasible Distance (FD). The reasoning: if a neighbor's cost to the destination is less than my own best-known cost, that neighbor cannot be using me in its path (if it were, its cost would be at least as large as mine). Therefore, routing traffic to that neighbor cannot create a loop. This is a mathematical invariant maintained by DUAL across the entire topology.

Senior

Why do hyperscale data centers use eBGP rather than OSPF as their internal IGP?

BGP's properties align better with hyperscale operational requirements: AS-path provides explicit loop detection without SPF storms, each pod's failure domain is isolated by AS boundaries, route policy can be applied at every tier independently, and BGP Unnumbered (RFC 5549) eliminates address management on P2P links. OSPF SPF reconvergence on a 10,000-router topology would be prohibitively slow; BGP's incremental path-vector updates scale far better at that size.

PhD

How does BGP Graceful Restart interact with route dampening, and what problems can arise?

BGP Graceful Restart (RFC 4724) allows a restarting BGP speaker to retain forwarding state while its control plane recovers. Peers mark routes as "stale" and continue forwarding without withdrawing them for up to the restart-time. The interaction with route dampening is subtle: if a prefix was partially suppressed (penalty above half-suppress) before the graceful restart, the stale routes may be re-advertised after restart with the same dampening penalty still applied. The routes would be immediately re-suppressed even though the peer is now stable — creating a period where the prefix is actively forwarded (stale state) but suppressed in BGP (not installed in RIB). This inconsistency persists until the suppress-limit decays below the reuse threshold. Production mitigation: configure separate dampening policies for iBGP (no dampening) and eBGP (conservative dampening), and set max-suppress-time lower than graceful-restart stalepath-time.

🎯 Key Takeaways

✓OSPF uses Dijkstra SPF on a synchronized LSDB — all routers in an area compute paths independently from identical topology data, eliminating routing loops by mathematical construction.
✓OSPF LSA types define flooding scope: Type 1/2 stay within an area, Type 3 summarizes across areas via ABRs, Type 5 floods the entire domain from ASBRs.
✓OSPF neighbors stuck in EXSTART/EXCHANGE almost always indicates MTU mismatch — fix MTU or use ip ospf mtu-ignore as a temporary workaround.
✓BGP is a policy engine, not an optimizer — it selects paths based on a deterministic attribute preference chain: Weight → LOCAL_PREF → AS_PATH length → Origin → MED → peer type.
✓EIGRP DUAL pre-computes loop-free backup paths (Feasible Successors) before failures occur. The feasibility condition (RD < FD) mathematically guarantees these backups are loop-free — enabling sub-second failover without querying the network.
✓IS-IS uses TLV encoding and operates at Layer 2, making it immune to IP misconfiguration and naturally extensible for Segment Routing, SRv6, and flexible algorithms.
✓Bidirectional route redistribution creates feedback loop risk. Mitigate with route tags: tag routes when crossing into Protocol B, filter tagged routes when crossing back into Protocol A.
✓BGP slow convergence (MRAI timer) is intentional — it prevents global route oscillation. Use BFD + graceful restart for fast failure detection, not aggressive BGP timer reduction.
✓Modern hyperscale data centers use eBGP (not OSPF) as their internal IGP with each pod assigned its own AS number, enabling policy-based routing and isolated failure domains per tier.
✓BGP EVPN/VXLAN distributes MAC/IP bindings via BGP address family L2VPN EVPN, enabling scalable Layer 2 overlays across Layer 3 fabrics — Type 2 for MAC/IP, Type 3 for BUM, Type 5 for IP prefixes.

Discussion

Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.

Continue with GitHub