A school district wants faster failure detection on Metro Ethernet links between OSPF routers. How should they compare sub-second OSPF hellos with BFD?
Select an answer to reveal the explanation.
Short Explanation
Fast hellos are like checking your mailbox every half-second—OSPF itself does all the knocking. BFD is a dedicated doorbell that can wake OSPF without flooding the protocol with tiny hellos. Same goal, less OSPF busywork with BFD.
Full Explanation
Aggressive OSPF Hello/Dead timers can shorten detection but increase protocol control-plane load and remain OSPF-specific. BFD offers a separate, lightweight failure-detection service that OSPF (and other clients) can register with, often preferred for sub-second detection on Metro links. A parks or clinic edge choosing between fast hellos and BFD should remember: BFD provides lightweight, protocol-independent detection that can signal OSPF, while aggressive hellos increase OSPF control-plane chatter.
Fast hellos do not always beat BFD, and claiming BFD cannot be fast misstates modern timer capabilities. Default Dead timers are not mandatory under any circumstance when detection SLAs require faster failure handling—but the preferred tool is often BFD rather than extreme hello rates. Fast hellos do not reduce control-plane load compared with a dedicated BFD session.
Exam caveat: BFD and hello tuning can coexist poorly if misunderstood—pick a primary detection strategy and align both ends. Operational check: enable BFD with OSPF as client on the Metro link, verify sessions, compare CPU and failover time against an aggressive-hello-only trial, and standardize on BFD for civic Metro-E handoffs where supported.