Architecture and operating model
BFD tests the forwarding path between two routing engines with frequent control packets. When a BGP neighbor consumes BFD state, a path failure can be reported before the BGP hold timer expires. BFD does not calculate routes; it supplies a liveness signal. Its incremental value can be smaller on a direct link with reliable link-down signaling and larger across tunnels or intermediate carriers.
Detection time is approximately the negotiated receive interval multiplied by the detection multiplier. A 300 ms interval with multiplier 3 targets about 900 ms, but scheduling, control-plane load and jitter can extend it. Selecting 50 ms everywhere looks faster yet increases CPU, packet handling and false-down risk across hundreds of sessions. Calibrate timers against measured jitter and platform capacity.
Single-hop and multihop sessions differ in source address, TTL and return path. ACL and control-plane policing must admit BFD in both directions. Asymmetric routing can lose only one direction and still drop the session. Combining BFD with BGP graceful restart may create tension between fast failure signaling and retaining routes during a control-plane restart; validate the platform behavior.
Bring BFD Up independently before binding it to BGP. Observe negotiated transmit and receive intervals, multiplier, discriminators and loss on both sides. Enable BGP integration on one pilot neighbor. Measure actual convergence and false positives during a planned cut, a one-way filter and control-plane CPU pressure.
- 1BFD control packets
- 2Bidirectional path state
- 3BGP neighbor state
- 4Route selection and FIB update
Design parameters
- Detection objective
- Set a business-driven target in seconds and treat interval × multiplier as an initial estimate.
- Session scale
- Calculate neighbors × packets per second in both directions and compare with control-plane capacity.
- Jitter margin
- Measure P95 and P99 control-packet delay; do not set multiplier from best-case latency.
- Multihop path
- Validate source address, hop limit, ECMP and return route separately from single-hop sessions.
- Protocol interaction
- Exercise graceful restart, fast external fallover and damping in the failure matrix.
Worked example
With 80 BGP neighbors and a 300 ms transmit interval, each direction produces roughly 80/0.3 = 267 control packets per second. Test both directions and processing overhead. At 50 ms, the same set generates about 1,600 packets/s/direction, so acceptance must consider CPU and policing as well as outage goals.
For a primary tunnel at 300 ms × 3, the nominal target is 0.9 seconds. If BFD reports Down at 1.15 seconds and the backup BGP path forwards at 1.42 seconds, another 270 ms belongs to selection and FIB programming. Measure user loss through synthetic traffic, not only the BFD log.
Example commands: replace lab values and confirm permissions and software versions before use.
bfd
peer 192.0.2.2
transmit-interval 300
receive-interval 300
detect-multiplier 3
no shutdown
router bgp 64512
neighbor 192.0.2.2 remote-as 64513
neighbor 192.0.2.2 bfd
show bfd peers brief
show bgp summaryTroubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| BFD is Down while BGP TCP works | An ACL, policing rule or source mismatch may block only BFD packets. | Compare captures, counters and discriminators on both ends. |
| Sessions flap under load | Timers may be tighter than control-plane jitter allows. | Correlate CPU, scheduler delay, late BFD packets and multiplier events. |
| BFD drops but traffic moves late | BGP selection or FIB programming may lag after detection. | Join BFD Down, BGP withdrawal, RIB and FIB timestamps. |
Acceptance checks
- Verify BFD source and destination addresses on both peers.
- Confirm control packets in ACL and policing counters.
- Calculate packet rate and CPU budget for all sessions.
- Bring BFD Up before enabling BGP integration.
- Measure convergence during planned and one-way failures.
- Review false downs and re-establishment after load testing.
Related concepts
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Failover and failback
Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behavior and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Capacity and usable headroom
Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.