skip to content

In a 200-site hub-and-spoke enterprise, how do EIGRP and OSPF differ in where routes can be summarised and how spoke routers are kept small?

level: seniorimportance: should knowfreq 18%

answer

  1. summary on which routers
  2. identical database inside an area
  3. queries towards the spokes
  4. stub router versus stub area
  5. discard route at the summariser

basics

~20 s

EIGRP can summarise on any interface, so hubs send spokes a summary or default and an implementation's stub feature stops hubs querying spokes; OSPF summarises only at area borders, so spokes need their own, ideally stub, areas.

solid answer

~50 s

In EIGRP the hubs can advertise a **summary or default on their spoke-facing interfaces** and each spoke can summarise its LANs towards the hubs; since a router that knows a prefix only through a summary replies to a query at once, summaries also **bound query scope**. The usual addition is the implementation's **stub routing** feature (not in RFC 7868), which tells hubs not to query spokes and stops spokes acting as transit. In OSPF, every router in an area holds an identical database, so summaries exist only at **area border routers** (area address ranges, RFC 2328 §3.5) and at the redistribution point for externals. Spokes therefore go into **non-backbone areas**, typically **stub areas** that replace AS-external-LSAs with a default (RFC 2328 §3.6), optionally with the ABR originating only a subset of summary-LSAs. One big spoke area would make every WAN flap trigger SPF on every spoke.

go deeper

for a junior

Recall that EIGRP can summarise on any interface while OSPF summarises at area border routers, and that both offer a way to give small sites only a default.

for a middle

Explain why OSPF cannot summarise inside an area, what a stub area removes, and how an EIGRP summary bounds the query scope.

for a senior

Design the 200-spoke network in both protocols, sizing areas or query boundaries, and anticipate the summary black hole when a dual-homed spoke loses one hub.

for a principal

Weigh EIGRP's low up-front design effort against OSPF's enforced hierarchy over the estate's lifetime, including addressing discipline and vendor mix at the spokes.

## The design problem Picture an enterprise with **two hub routers** at the data centres and **200 spoke sites**, each spoke with one or two small LANs and a WAN link to each hub. The spokes are modest routers. The design goals are: - each spoke holds as few routes as possible — ideally a default or a summary of the enterprise; - a flapping WAN link at one spoke does not cause work at the other 199; - a hub failure is handled quickly, without waiting on 200 routers. EIGRP and OSPF reach these goals in different places. ## EIGRP: summarise wherever it helps EIGRP has no areas, and any router may advertise a summary on **any interface**. 1. **Hubs towards spokes:** each hub advertises a default route or a summary of the enterprise space on its spoke-facing interfaces, so a spoke's table holds its own LANs plus one or two routes. 2. **Spokes towards hubs:** each spoke summarises its LANs, so a LAN change inside a site never reaches the hubs. (Working out the summary prefix itself is ordinary CIDR arithmetic.) 3. **Query boundaries:** RFC 7868 §3.1 notes that hiding reachability through aggregation or filtering controls how far a diffusing computation spreads. A router with no specific route for the lost destination, only a summary covering it, is not required to go active and can answer a query immediately. 4. **Stub routing:** the implementation's stub feature, which is **not part of RFC 7868**, lets a spoke announce itself as a stub. Hubs then do not send it queries, and the spoke does not advertise routes learned from one hub to the other, so it never becomes a transit path between hubs. Without step 4, a hub that loses a route with no feasible successor queries all 200 spokes, each of which may query the other hub, and one slow spoke can leave the route **stuck in active**. ## OSPF: summarise only where areas meet Every router in an OSPF area keeps an **identical link-state database**, so a router inside an area cannot advertise a summary in place of the detail. RFC 2328 provides two aggregation points: - **Area border routers (ABRs)** advertise configured **area address ranges** into other areas (§3.5). The range's cost is the maximum cost to any network inside it. - **Redistributed routes** can be aggregated where they enter OSPF, as an implementation feature; in a not-so-stubby area, RFC 3101 adds Type-7 address ranges at the NSSA border router. So the spoke design is an **area design**: 1. Put spokes in **non-backbone areas** with the hubs as ABRs. The backbone holds the hubs and data-centre links. 2. Make the spoke areas **stub areas** (RFC 2328 §3.6): AS-external-LSAs are not flooded into them, and the ABR advertises a **default summary-LSA** instead. 3. Optionally let the ABR originate **only a subset of summary-LSAs** into the stub area (RFC 2328 §12.4.3.1 permits this). Implementations call the extreme case, a default only, "totally stubby" — an implementation feature name, not an RFC term. 4. Size areas so that a WAN flap triggers SPF only among a few dozen spokes, not all 200. ## Side by side | Goal | EIGRP | OSPF | |---|---|---| | Small spoke tables | Summary or default on hub interfaces | Stub area with default; fewer summary-LSAs | | Spoke churn kept local | Spoke summarises its LANs | Area boundary at the hub ABR | | Hub failure handled quickly | Stub routing stops queries to spokes | Recompute bounded by area size | | Where summaries may sit | Any interface | ABRs, and where externals enter | | Up-front design needed | Low | Areas plus an addressing plan | ## Traps in both - **Black holes at the summariser.** OSPF ABRs install a **discard** entry for each active range (RFC 2328 §11.1), and EIGRP implementations install a similar null route for a summary. If a dual-homed spoke loses its link to one hub, that hub still advertises the summary and drops traffic for the spoke unless the hubs are connected and carry the specific route between them. - **Too many areas on one hub.** Each area makes the hub an ABR that runs SPF per area; dozens of areas concentrate load on two routers. - **Confusing the two "stubs".** An OSPF stub area is a database scope rule in the standard; EIGRP stub routing is a query and transit rule in one implementation.

  • A dual-homed spoke loses its WAN link to hub A; why might traffic from the data centre to that spoke be dropped?
    Both hubs advertise the same enterprise summary, so the data centre may still send traffic to hub A. Hub A no longer has the spoke's specific route, so its discard entry for the summary drops the packet. The fix is a link between the hubs carrying specifics, so hub A forwards to hub B.
  • Why not simply put all 200 spokes in OSPF's backbone area?
    Then every router holds every spoke's links in one identical database, and any WAN flap triggers SPF on the hubs and all 200 spokes. No ABR exists to summarise or to keep externals out, so the spokes carry the full table.

saying these in an interview costs you the question

  • An OSPF router inside an area can summarise its LANs towards its neighbours.
  • EIGRP stub routing is part of the EIGRP specification in RFC 7868.
  • An OSPF stub area and an EIGRP stub router do the same thing.
  • A plain OSPF stub area also removes every summary-LSA for other areas.
  • Summarising at the hubs can never black-hole traffic to a spoke.