Featured image

Table of Contents Link to heading

The Problem That Sends Engineers to the Wrong Place Link to heading

Every network engineer has sat in front of a black CLI screen asking the same question: “The cable is in. The IP is correct. So why won’t these two routers talk to each other?”

The answer is almost never the cable. It is almost never the IP address either. The answer lives in the routing protocol — specifically in a misunderstanding of what that protocol actually does and why it behaves the way it does under pressure.

Memorising CLI commands gets you through a lab exam. Understanding the character of each protocol — what it optimises for, where it breaks, and what it refuses to do — is what lets you troubleshoot a production network at 2 AM without guessing.

EIGRP, OSPF, and BGP are the three protocols that cover every routing scenario in enterprise and service provider networks. They are not interchangeable. Each was designed with a specific problem in mind, and understanding that design intent is the shortcut to intuitive troubleshooting.

EIGRP: Speed and Built-In Redundancy Link to heading

Info
EIGRP (Enhanced Interior Gateway Routing Protocol) is a Cisco-proprietary advanced distance-vector protocol. It converges faster than any other IGP and is the correct choice for all-Cisco environments where sub-second failover is a hard requirement.

The DUAL Algorithm: Always Knowing the Backup Route Link to heading

The defining feature of EIGRP is the DUAL algorithm (Diffusing Update Algorithm). While other protocols find the best path and stop, DUAL goes further: it simultaneously computes and stores a Feasible Successor — a pre-validated backup path that is guaranteed loop-free and can be activated instantly without any recalculation.

The analogy: you are driving home from the office when the main road suddenly jams. You do not pull over, open Google Maps, and wait for a route to be calculated. You already scouted the side street months ago — you turn immediately with zero hesitation. That is DUAL.

In network terms: when the primary path fails, EIGRP promotes the Feasible Successor to active in milliseconds. No query messages, no SPF run, no waiting. The network never noticed anything happened.

EIGRP Successor and Feasible Successor:

Router A ──────────────────── Router B   (Primary path, FD=100)
    │                              │
    └────── Router C ──────────────┘   (Feasible Successor, FD=150)

Primary link fails:
  → Router C promoted to Successor in <1 second
  → No SPF recalculation
  → No query flood

The Operational Catch: Query Propagation and EIGRP Stub Link to heading

EIGRP’s weakness mirrors its strength. When the primary path fails and there is no Feasible Successor available, EIGRP sends Query messages outward to all neighbours: “Do you have a route to this network?” Those neighbours query their neighbours, and the flood propagates until every router in the domain has been consulted — a condition called Stuck in Active (SIA) when responses are slow.

In a large, flat EIGRP domain, query propagation can temporarily freeze routing for affected prefixes across the entire network.

Warning
EIGRP Stub is not optional in large deployments — it is mandatory. Configure all branch and edge routers that are not transit paths as EIGRP Stubs. A Stub router advertises to its neighbours: “I am a dead end. Do not send me queries.” This contains the query scope to the distribution and core layers, preventing SIA storms from spreading.

Configuration Reference Link to heading

! Enable EIGRP
router eigrp 100
 network 10.0.0.0 0.255.255.255
 network 192.168.1.0 0.0.0.255
 no auto-summary

! Stub configuration — apply on all branch/edge routers
router eigrp 100
 eigrp stub connected summary

! Verify adjacency and topology table
show ip eigrp neighbors
show ip eigrp topology
show ip eigrp topology all-links     ! includes Feasible Successors

! Check Feasible Successor existence for a specific prefix
show ip eigrp topology 10.10.0.0/24
! State is Passive + FD value present = Feasible Successor exists
! State is Active = currently querying — potential SIA condition

OSPF: Discipline, Maps, and Hierarchical Design Link to heading

Info
OSPF (Open Shortest Path First) is an open-standard link-state IGP (RFC 2328). It runs on any vendor’s hardware, requires strict Area-based hierarchy, and scales to large multi-vendor enterprise networks. It is the IGP of choice for heterogeneous environments and organisations that cannot be locked into a single vendor.

How OSPF Thinks: A Map, Not a Rumour Link to heading

EIGRP passes route information between neighbours like a rumour: “Router B told me it can reach 10.0.0.0 in three hops.” OSPF does something fundamentally different. Every OSPF router builds a complete topological map (the LSDB — Link State Database) of every link in the area, then independently runs Dijkstra’s SPF algorithm on that map to compute its own shortest-path tree.

OSPF routers do not trust each other’s routing decisions. They verify every path themselves from first principles. This eliminates routing loops entirely — you cannot have a loop when every router derives its own paths from the same complete topology.

The trade-off is CPU and memory. A single large OSPF area with hundreds of routers triggers SPF recalculations on every router whenever any link changes. This is why OSPF mandates Area 0 (backbone) as the transit core, with all other areas connecting to it. A topology change in Area 1 only triggers SPF within Area 1 — the backbone is isolated from branch instability.

OSPF Area Hierarchy:

         ┌─────────────── Area 0 (Backbone) ───────────────┐
         │          Core Routers                           │
         │          Full LSDB of backbone only             │
         └─────┬──────────────┬────────────────┬───────────┘
               │              │                │
           ABR-1           ABR-2            ABR-3
            │                  │                │
        Area 1              Area 2           Area 3
    (Branch A)           (Branch B)       (Data Centre)
    Local LSDB           Local LSDB        Local LSDB
    SPF runs locally     SPF runs locally   SPF runs locally

Route Summarisation at the ABR: The Branch Manager Analogy Link to heading

Each branch area can contain hundreds of subnets. Without summarisation, every branch subnet propagates a separate LSA Type 3 into Area 0, inflating the backbone LSDB and slowing SPF on every core router.

Route summarisation at the ABR collapses all branch subnets into a single aggregate prefix before advertising into Area 0. The backbone sees one route per branch, regardless of how many subnets exist internally.

The analogy: a branch office has hundreds of departments each submitting individual expense reports to headquarters. Instead of flooding HQ with hundreds of line items every month, the branch director compiles everything into a single summary figure. HQ stays fast and clean; the detail remains available at the branch level when needed.

! Summarise Area 1 subnets at the ABR before entering Area 0
router ospf 1
 area 1 range 10.1.0.0 255.255.0.0
! All 10.1.x.x/y routes advertised as a single 10.1.0.0/16 into backbone
! Reduces backbone LSDB size and SPF computation time significantly

Configuration Reference Link to heading

! Enable OSPF
router ospf 1
 router-id 1.1.1.1                           ! always set explicitly
 network 10.0.0.0 0.255.255.255 area 0
 network 192.168.1.0 0.0.0.255 area 1
 passive-interface GigabitEthernet0/2        ! suppress hellos on LAN segments

! Verification
show ip ospf neighbor                        ! target state: FULL
show ip ospf database                        ! full LSDB
show ip ospf database summary                ! LSA count per area
show ip route ospf                           ! OSPF-learned routes

! DR/BDR election on multi-access segments
interface GigabitEthernet0/0
 ip ospf priority 100                        ! highest priority = DR

! Faster convergence with tuned timers
interface GigabitEthernet0/0
 ip ospf hello-interval 1
 ip ospf dead-interval 4
Tip
Set the OSPF Router ID explicitly with router-id before any adjacency comes up. If you rely on the highest active interface IP, the Router ID can change when an interface goes down — forcing a full LSDB flush and SPF recalculation across the entire area. A manually assigned or loopback-derived Router ID never changes regardless of interface state.

BGP: Policy Over Speed Link to heading

Info
BGP (Border Gateway Protocol) is the routing protocol of the internet — the only EGP in production use. It runs between autonomous systems, makes path decisions based on configurable policy and attributes rather than metrics, and is specifically designed for environments where business relationships, traffic costs, and contractual obligations determine routing.

Routing by Policy, Not Metric Link to heading

EIGRP and OSPF both optimise for the shortest or least-cost path. BGP explicitly does not. BGP selects paths based on attributes — AS_PATH length, Local Preference, MED, community tags, and more — and every one of these attributes is programmable through policy.

This means BGP can make routing decisions that no metric-based protocol can express. “Send critical database replication traffic over the expensive fibre link. Send employee web browsing over the cheap copper link. Regardless of which path is mathematically shorter.”

No EIGRP metric or OSPF cost value can capture that kind of business logic. BGP can.

Why BGP Convergence Is Deliberately Slow Link to heading

BGP convergence — propagating a routing change across the internet — is measured in minutes, not milliseconds. This is not a bug. It is intentional design.

If BGP reacted to every topology change with the urgency of EIGRP, a single fibre cut anywhere on the internet would cause millions of routers to simultaneously recalculate their routing tables. The compute load alone would bring the internet down faster than the original failure. BGP’s slow, incremental propagation distributes that processing load across time — each AS processes the change in turn rather than all at once.

The internet stays stable precisely because its routing protocol is conservative.

Note
This is also why BGP is the wrong protocol for intra-enterprise routing. Inside a campus or data centre where sub-second failover matters, use EIGRP or OSPF. BGP belongs at the WAN edge — at the boundary between your AS and the service provider.

Dual-ISP Traffic Engineering with BGP Link to heading

Company AS 65001 with two ISPs:

        ┌──────────────────────────────────┐
        │         Company Network          │
        │           AS 65001               │
        └──────┬──────────────┬────────────┘
               │ eBGP         │ eBGP
        ┌──────▼──────┐  ┌───▼────────────┐
        │  ISP-A      │  │   ISP-B        │
        │  Fibre      │  │   Copper       │
        │  Expensive  │  │   Cheap        │
        │  AS 65002   │  │   AS 65003     │
        └─────────────┘  └────────────────┘

BGP Policy:
  Database replication → LOCAL_PREF 200 via ISP-A (always preferred)
  Web browsing / YouTube → LOCAL_PREF 100 via ISP-B (cost-optimised)
  ISP-A failure → all traffic automatically shifts to ISP-B

Configuration Reference Link to heading

! eBGP sessions to both ISPs
router bgp 65001
 neighbor 203.0.113.1 remote-as 65002
 neighbor 203.0.113.1 description ISP-A-Fibre
 neighbor 198.51.100.1 remote-as 65003
 neighbor 198.51.100.1 description ISP-B-Copper

! Route-maps for traffic engineering
route-map PREFER-ISPA permit 10
 set local-preference 200

route-map PREFER-ISPB permit 10
 set local-preference 100

! Apply inbound policies
neighbor 203.0.113.1 route-map PREFER-ISPA in
neighbor 198.51.100.1 route-map PREFER-ISPB in

! Prefix filtering — never accept a default route unless explicitly intended
ip prefix-list BLOCK-DEFAULT seq 5 deny 0.0.0.0/0
ip prefix-list BLOCK-DEFAULT seq 10 permit 0.0.0.0/0 le 32
neighbor 203.0.113.1 prefix-list BLOCK-DEFAULT in

! Verification
show bgp summary
show bgp ipv4 unicast                        ! full BGP table
show bgp ipv4 unicast 0.0.0.0/0             ! path selection for default route
show ip route bgp                            ! BGP routes in the RIB

Protocol Comparison: Choosing the Right Tool Link to heading

Feature EIGRP OSPF BGP
Protocol type Advanced distance-vector Link-state Path-vector
Standard Cisco proprietary Open (RFC 2328) Open (RFC 4271)
Scope Intra-AS (IGP) Intra-AS (IGP) Inter-AS (EGP)
Convergence speed Sub-second (with FS) Seconds Minutes (by design)
Routing decision basis Composite metric (BW + delay) Cost (bandwidth) Policy + attributes
Multi-vendor support No — Cisco only Yes Yes
Scalability Medium High (with area design) Internet-scale
Key strength Instant failover via DUAL Loop-free topology map Fine-grained traffic policy
Key weakness Cisco lock-in, query storms Area discipline required Slow convergence, complexity
Best used for All-Cisco campus/branch Multi-vendor enterprise WAN edge, ISP peering

Traffic Flow: How a Packet Moves Across All Three Protocols Link to heading

Source: Branch office employee workstation
Destination: HQ database server

1. EIGRP domain (Branch):
   Workstation → Branch CE router
   EIGRP table: "10.0.0.0/8 via WAN uplink" (Successor, pre-computed)
   Packet forwarded toward WAN immediately

2. OSPF domain (Core backbone, Area 0):
   Packet enters the OSPF backbone
   Core router consults SPF-derived routing table
   Next-hop: HQ distribution router
   Forwarded across backbone via shortest path

3. OSPF domain (HQ, Area 1 or Data Centre area):
   ABR receives packet, routes into destination area
   OSPF delivers to HQ database server subnet
   Server receives packet

Failure scenario — WAN primary link drops:
   EIGRP (Branch): Feasible Successor promoted in <1 second
   OSPF (Core): SPF recalculates alternate path in seconds
   BGP (Edge): if ISP-A fails, shifts to ISP-B in 1–3 minutes
               (accelerated with BFD: convergence in seconds)

Topology: Where Each Protocol Lives in an Enterprise Network Link to heading

                     ┌────────────────────────────┐
                     │         INTERNET           │
                     └──────────────┬─────────────┘
                                    │ BGP eBGP
                       ┌────────────┴────────────┐
                       │  ISP-A       ISP-B      │
                       │  (Fibre)   (Copper)     │
                       └────────────┬────────────┘
                                    │ BGP eBGP / iBGP
                       ┌────────────▼────────────┐
                       │    Internet Edge         │
                       │  (Border/CE Router)      │
                       └────────────┬────────────┘
                                    │
                       ┌────────────▼────────────┐
                       │   OSPF Area 0           │  ← Multi-vendor
                       │   (Core / Backbone)     │    Open standard
                       └───────┬─────────┬───────┘    Loop-free map
                               │         │
                 ┌─────────────▼─┐   ┌───▼───────────────┐
                 │  ABR          │   │   ABR             │
                 └──────┬────────┘   └────────┬──────────┘
                        │                     │
            ┌───────────▼──────┐  ┌───────────▼──────────┐
            │  OSPF Area 1     │  │   OSPF Area 2        │
            │  (HQ Campus)     │  │   (Data Centre)      │
            └───────────────── ┘  └──────────────────────┘
                        │
            ┌───────────▼──────────────────────────┐
            │         EIGRP AS 100                 │  ← All-Cisco
            │      (Branch / WAN Edge)             │    Sub-second failover
            │  Branch-1  Branch-2  Branch-3        │    DUAL + FS
            └──────────────────────────────────────┘

Troubleshooting Checklist by Protocol Link to heading

The fastest first step for any routing problem:

show ip route <destination>
! D = EIGRP   → troubleshoot EIGRP
! O = OSPF    → troubleshoot OSPF
! B = BGP     → troubleshoot BGP
! Missing = route not in table → check protocol adjacency first

EIGRP adjacency not forming:

! AS number mismatch (most common)
show ip eigrp neighbors
! No output = no adjacency at all

! K-value mismatch (metric weights must be identical)
show ip protocols | include K values
! Default: K1=1 K2=0 K3=1 K4=0 K5=0

! Authentication failure
debug eigrp packets hello
! Look for "authentication failure" in output

! Network statement missing
show run | section router eigrp

OSPF adjacency stuck below FULL:

! Hello/Dead timer mismatch (adjacency stays at INIT)
show ip ospf interface GigabitEthernet0/0
! Both sides must match hello-interval and dead-interval

! Subnet mask mismatch (most common OSPF mistake)
show ip interface GigabitEthernet0/0 | include Internet address
! Both routers must be in the same subnet with the same mask

! MTU mismatch (adjacency reaches EXSTART then drops)
show ip ospf interface | include MTU
! Fix: ip ospf mtu-ignore on the interface

! Area mismatch
show ip ospf neighbor
! Check that neighbour area IDs match

BGP session not establishing:

! TCP 179 reachability
telnet 203.0.113.1 179
! Must connect — firewall blocking TCP 179 is the most common issue

! AS number mismatch
show bgp neighbors 203.0.113.1 | include remote AS
! Verify against what the ISP has configured on their side

! MD5 authentication mismatch
debug ip bgp 203.0.113.1 events
! Look for "MD5 digest error"

! eBGP not directly connected (multihop required)
neighbor 203.0.113.1 ebgp-multihop 2
neighbor 203.0.113.1 update-source Loopback0
Tip
Understanding the character of each protocol removes the mystery from network troubleshooting. EIGRP’s obsession with instant failover, OSPF’s insistence on building a complete map before making any decision, BGP’s deliberate slowness in service of global internet stability — these are not arbitrary design choices. They are the direct expression of what each protocol was built to solve. Know the design intent, and the CLI output stops being a wall of text and starts being a diagnostic story.