Table of Contents Link to heading
- The Problem That Sends Engineers to the Wrong Place
- EIGRP: Speed and Built-In Redundancy
- OSPF: Discipline, Maps, and Hierarchical Design
- BGP: Policy Over Speed
- Protocol Comparison: Choosing the Right Tool
- Traffic Flow: How a Packet Moves Across All Three Protocols
- Topology: Where Each Protocol Lives in an Enterprise Network
- Troubleshooting Checklist by Protocol
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
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.
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
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
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
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.
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