ISP Failover Misses the Five-Second SLA
Dell S5248F-ON switches at an enterprise edge run eBGP to two ISPs. ISP-A is AS 64500, ISP-B is AS 64501; the enterprise is AS 65010. Both sessions advertise a default route. A route-map sets local preference 200 for ISP-A and 100 for ISP-B. The design uses BGP hold 180 / keepalive 60 and no BFD. When the ISP-A circuit fails, the default route via ISP-B takes about 180 seconds to become active; the business SLA requires under 5 seconds. When ISP-A returns, the edge also sees brief asymmetric routing because the local-preference change is applied before the ISP-A session is fully stable. The edge does not run NAT; both ISPs provide public /30 links.
1. Why is the failover slow, and why is lowering the BGP hold timer to 5 seconds by itself a poor fix?
Read the worked answer
BGP detects a dead peer when the hold timer expires; with 180 seconds, a physical circuit failure is invisible until then. Lowering the hold timer to 5 seconds can work in a lab but is fragile: BGP keepalives are process-scheduled, a busy CPU or short microburst can cause a false reset, and both ends must agree. It also does not speed up the forwarding-path check if the link stays up at Layer 1/2 while the provider drops traffic. BFD is the right tool because it runs a lightweight, sub-second liveness check independent of BGP and can be tied to the neighbor with fall-over bfd. Keep BGP timers as a slower backup rather than the primary detector.
2. Design the detection and route-convergence changes, including commands and verification. Address the return-path asymmetry.
Read the worked answer
Enable BFD on each eBGP neighbor with a 300 ms transmit/receive interval and multiplier 3 (about 900 ms detection), then attach it to BGP. In OS10 the BFD session may be configured under the interface/session and enabled on the neighbor with bfd or fall-over bfd; confirm the exact platform syntax. Keep BGP hold/keepalive at 30/10 or 60/20 as backup. Ensure the ISP-B path is installed and that the local-preference route-map is only applied to stable sessions; use a route-map with a prefix-list for the default route and, if needed, maximum-prefix to avoid a partial-table trigger. Verify with show bfd neighbors, show bgp ipv4 unicast summary, show ip route 0.0.0.0, and a controlled link shutdown. For asymmetry, confirm ISP-B accepts the enterprise prefix and that the return path uses the same ISP; if both ISPs advertise the prefix, inbound traffic may return via ISP-A even while outbound uses ISP-B. Use AS-path prepending or MED on the backup path only after the failover policy is tested.
3. What would you monitor after the change to prove the SLA and catch a BFD false positive?
Read the worked answer
Monitor BFD session state, BGP neighbor uptime/flaps, and the default-route next-hop on both edge switches at sub-minute resolution. Track failover duration with a synthetic probe or syslog event correlation: link-down to BGP best-path change should be under 5 seconds, and the return path should not flap. A BFD false positive looks like a BFD down event with no corresponding interface or ISP alarm, followed by immediate recovery; correlate BFD with interface counters, CPU, and control-plane policing. If false positives appear, raise the multiplier before raising the interval, and make sure BFD packets are not competing with excessive CoPP or management traffic. Also alert on asymmetric routing indicators, such as outbound next-hop via ISP-B while inbound hits ISP-A.