A museums and culture department saw CPU spikes when a flapping WAN link churned OSPF. Which tuning goal should they pursue with SPF and LSA throttle timers?
Select an answer to reveal the explanation.
Short Explanation
Think of SPF like a smoke alarm that was going off every time a door slammed. Throttle timers add a short calm-down period so one WAN blip doesn’t keep the CPU rebuilding the whole map. You’re trading a little reconvergence speed for a lot of stability.
Full Explanation
SPF and LSA throttling introduce initial delay, hold, and maximum-wait intervals that pace Dijkstra runs and LSA flooding during instability. A museums and culture department seeing CPU spikes when a flapping WAN link churned OSPF should delay and pace SPF runs and LSA origination so brief flaps do not force constant full recalculation. That dampens CPU and control-plane load without abandoning OSPF on the civic WAN circuit.
Disabling SPF entirely and relying on static defaults until the WAN vendor replaces the circuit abandons dynamic routing as a tuning strategy and prolongs operational risk. Setting Hello interval to one second on every campus access switch to outrun flaps increases control-plane load and misses the throttling problem on the unstable link. Converting every OSPF area to totally stubby so external flaps never appear as LSAs may shrink some LSA types but does not replace throttle timers for damping flaps on the WAN itself.
Exam caveat: throttles slow reaction by design—balance damping against detection SLAs for critical services, and still pursue physical repair of the flapping circuit. Operational check: tune SPF and LSA throttle values consistently across routers, reproduce a brief flap, confirm CPU no longer pegs on continuous SPF, and verify convergence still meets the department’s recovery targets.