CCNP Enterprise: Single-Area OSPF Across a Carrier L2 Handoff

Single-Area OSPF Across a Carrier L2 Handoff

Northwind Health runs two campuses joined by a carrier-provided 1 Gbps Layer 2 handoff plus a 300 Mbps internet circuit at each site. Cleveland has 1,800 users and 42 access stacks; Akron has 600 users and 14. Both sites sit in a single OSPF area 0 that spans the carrier handoff, with the Cleveland core acting as the only ABR, the ASBR, and the default gateway for 96 VLANs. When the Akron core reloaded last month, 14,000 LSAs reflooded both sites and the Cleveland core hit 92% CPU for nine minutes; a call center dropped 400 calls. Interface counters show no errors. The team has no BGP experience, change control takes two weeks, and the CIO wants one protocol, fewer moving parts, plus a design that survives any single node or link failure at either site.

1. The team proposes splitting OSPF into area 0 at Cleveland and area 1 at Akron, with the Akron core pair as ABRs. Will that fix the CPU spike and the flooding event? What would you investigate and change first?

Read the worked answer

The area split does not obviously fix this, and the LSA count is the tell.

Sanity check the number: 56 access stacks and 96 VLANs should produce a few hundred internal LSAs, not 14,000. A count that large almost always means redistribution - typically redistribute connected and redistribute static - turning every connected subnet into a type-5 external that is flooded to every router in every area.

Therefore:

Measure before designing. show ip ospf database counted by LSA type, and show ip ospf statistics for SPF run time on the Cleveland core. If type-5 dominates, an area split leaves the problem intact: externals flood into area 0 and are re-originated as type-3/type-5 into area 1. You would do the work and still have the outage.
Fix the origination, not the topology. Replace redistribute connected with passive-interface plus network statements so internal subnets become type-1/2 inside the area. Redistribute only genuine externals (the ISP default), and consider making Akron a not-so-stubby area so external flooding stops at the ABR.
Then consider the area split, whose real value here is bounding SPF to Akron's topology and letting the ABR summarize Akron's 96 VLANs into two or three summary ranges.

Judgement: the CI0 asked for fewer moving parts. Splitting areas adds two ABRs, summarization and an inter-area traffic path - justified only after the LSA count is normalized. The area split alone is cosmetic.

2. Design the Cleveland–Akron interconnect and the Akron default gateway. State the failure behaviour and tell them whether sub-200 ms voice convergence is achievable.

Read the worked answer

Terminate the carrier handoff as routed, not switched.

Ask the carrier for a routed /31 (or /30) handoff at each end. An L2 handoff gives you STP blocking half the capacity, no ECMP, one broadcast domain across 60 km, and a carrier maintenance action that can blackhole traffic with no interface event on your side.
Run OSPF point-to-point over the /31 with BFD. Detection 150 ms x 3 = 450 ms, plus SPF and FIB install, lands around 600–700 ms for data. For sub-200 ms voice, use BFD 50 ms x 3 = 150 ms with fast hellos; verify the platform can install the FIB that fast before promising it.
Put the default gateway for Akron's VLANs at Akron: an HSRP pair of local L3 switches, with the SVIs there and OSPF to Cleveland. Do not backhaul Akron's first hop to Cleveland - that puts the carrier in the voice path on every call and turns a WAN blip into a total outage at Akron.
Summarize Akron's VLANs into two or three ranges at the ABR so Cleveland's LSDB does not grow with Akron access changes.

Failure behaviour to document: link loss triggers BFD then OSPF reconvergence; HSRP stays local so the voice gateway never moves; a single Akron distribution switch failure leaves the surviving switch as active gateway with sub-second failover. A Cleveland core failure removes the inter-site path but Akron keeps local routing and its local internet circuit.

3. The CIO asks why not just run BGP everywhere, since that is what the consultants recommended. Give the criteria and a recommendation.

Read the worked answer

Criteria that justify BGP as the interior protocol here:

More than two or three sites, or a credible plan to get there within 18 months (mergers, SD-WAN, M&A).
Multi-homing to two or more providers, where you need per-prefix policy and AS-path control rather than two floating statics.
Address-family separation (a guest or OT/medical-device space with different policy).
A requirement to carry routes over a provider MPLS or SD-WAN overlay where you do not control the underlay.

Criteria that argue against it now: two sites, one carrier, one internet circuit each, a team with no BGP experience, and a two-week change window. BGP's convergence and troubleshooting cost is real, and a badly filtered eBGP session is a worse outage than an LSA flood.

Recommendation: OSPF inside, BGP only at the internet edge if and when they add a second provider. If the CIO expects to reach four-plus sites within a year, start now - the migration cost rises steeply once 96 VLANs are live and the change window is two weeks. In that case, fund training before the first session is configured, and set an explicit, measured exit criterion (e.g. the team can explain and predict reconvergence for a link failure unaided).

4. During the review someone proposes also redistributing the ISP default into OSPF at both sites with equal cost. What goes wrong and how would you control it?

Read the worked answer

What goes wrong: with the default originated at both sites at equal cost, every router picks its nearest exit. That is fine on a healthy day and asymmetric the moment the inter-site link degrades - some traffic egresses at Akron with a return path through Cleveland, and stateful devices on the path start dropping. Worse, the two ASBRs can flap the default between them during a partial failure, which reconverges every router in the domain.

Controls, in order of preference:

Originate the default at one site with a clearly better metric, and keep the second as a backup default with a worse metric - deterministic egress, predictable asymmetric behaviour.
If both must be active, ensure the topology is symmetric (routed /31 plus BFD) so the return path follows the same decision.
Never let a redistributed static flap the domain: originate the default with a static route tied to an IP SLA object, and add a route-map so the default is withdrawn cleanly rather than re-originated every poll.

The judgement point is that equal-cost defaults are a routing decision with a stateful-firewall consequence; the failure mode shows up as intermittent application timeouts, not as a routing alarm.