A municipal fiber consortium needs much faster detection of a dark-fiber failure between campuses than IGP hello timers alone provide. What is BFD’s primary role in that design?
Select an answer to reveal the explanation.
Short Explanation
BFD is the smoke alarm for the forwarding path—it notices the fiber went dark way faster than waiting for slow IGP hello timeouts.
Full Explanation
BFD’s primary role for the municipal fiber consortium is lightweight, rapid forwarding-path failure detection. Client protocols—OSPF, EIGRP, BGP, or static routes with tracking—register with BFD and tear down adjacency or next-hop dependency quickly when the dark-fiber path fails, far faster than relying on slow IGP hello/dead timers alone.
BFD does not replace OSPF and EIGRP entirely so hellos are no longer required; routing protocols still form adjacency, exchange topology, and compute paths—BFD accelerates failure signal. BFD does not encrypt IGP payloads against fiber taps; confidentiality needs crypto/MACsec/IPsec designs, not BFD. BFD does not summarize IPv6 and IPv4 tables into a single BFD RID for both VRFs; sessions are per-hop/per-protocol context, not a dual-stack table merge tool.
Exam caveat: BFD timers must be supported end-to-end on the fiber path and compatible with platform hardware offload expectations. Aggressive timers without hardware assist can spike CPU—size appropriately for campus dark fiber.
Operational check: enable BFD on the consortium links, confirm show bfd neighbors sessions are up, then break the fiber and measure how quickly OSPF/EIGRP/BGP react compared with hello-only baselines. Verify clients show BFD registration in protocol-specific neighbor details.