BFD — Fast Failure Detection và Rapid BGP Convergence
Tại Sao Quan Trọng Trong Production
Trong production hybrid connectivity, tốc độ failover sau khi link bị down là yếu tố quyết định SLA đạt được hay không. BGP hold timer mặc định là 180 giây — có nghĩa là trong trường hợp worst case, traffic có thể bị blackhole tới 3 phút trước khi BGP detect failure và failover sang đường backup.
Với HA VPN được thiết kế để đạt 99.9% uptime (tương đương ~8.7 giờ downtime/năm) hoặc Dedicated Interconnect 99.9%/99.99%, con số 180 giây hold timer là không chấp nhận được. BFD (Bidirectional Forwarding Detection) giải quyết điều này bằng cách cung cấp sub-5-second failure detection — song song với BGP, không phụ thuộc vào hold timer.
BFD không phải là "một tùy chọn nice-to-have" — nó là thành phần bắt buộc trong thiết kế hybrid connectivity production bất kỳ nơi nào failover speed quan trọng.
Internal Model — BFD Hoạt Động Như Thế Nào
Định Nghĩa Và Standards
BFD là một "forwarding path outage detection protocol" theo định nghĩa trong RFC 5880 (cho general BFD) và RFC 5881 (cho BFD over IPv4/IPv6 single-hop). Cloud Router implementation:
- Chạy trên UDP
- Sử dụng asynchronous mode (không phải demand mode)
- Gửi BFD control packets định kỳ theo timer
- Không hỗ trợ echo mode (echo mode gửi packets qua forwarding path và yêu cầu peer loop back — Cloud Router không implement điều này)
Cơ Chế Hoạt Động Cơ Bản
BFD là một hello protocol với độ dài cố định — mỗi bên gửi BFD control packets định kỳ qua forwarding path đến peer. Nếu một bên không nhận được packets trong một khoảng thời gian xác định (dựa trên timers và multiplier), nó coi forwarding path là bị lỗi và thông báo cho lớp trên (trong trường hợp này là BGP).
Cloud Router (GCP side) On-Prem Router
│ │
│──── BFD Control Packet ─────►│
│ │
│◄─── BFD Control Packet ──────│
│ │
│ [Định kỳ mỗi X ms] │
│ │
│ [Nếu không nhận được] │
│ [trong detection time] │
│ [→ Notify BGP: peer down] │Quan trọng: BFD packets đi qua cùng forwarding path với data traffic. Nếu forwarding path fail (VPN tunnel down, Interconnect physical link fail, intermediate device fail), BFD packets cũng bị ảnh hưởng, từ đó BFD phát hiện failure.
So sánh với BGP hold timer: BGP control traffic và BFD control traffic đều đi qua cùng path. Nhưng BFD có timers ngắn hơn nhiều, nên detect failure nhanh hơn.
Timer Configuration — Tính Toán Detection Time
Ba Tham Số BFD
Cloud Router hỗ trợ ba tham số cấu hình cho BFD:
1. Minimum Transmit Interval (ms)
- Default: 1000ms (1 giây)
- Range: 1000ms đến 30000ms (1 đến 30 giây)
- Ý nghĩa: Tần suất tối thiểu mà Cloud Router muốn gửi BFD packets đến peer
2. Minimum Receive Interval (ms)
- Default: 1000ms (1 giây)
- Range: 1000ms đến 30000ms
- Ý nghĩa: Tần suất tối thiểu mà Cloud Router muốn nhận BFD packets từ peer
3. Multiplier
- Default: 5
- Range: 5 đến 16
- Ý nghĩa: Số packets bị miss liên tiếp trước khi BFD coi session là failed
Negotiation Và Detection Time Formula
Hai BFD peers negotiate timers khi session được thiết lập. Giá trị lớn hơn được chọn:
Agreed Transmit Interval = max(
local Minimum Transmit Interval,
remote Minimum Receive Interval
)Detection Time = Agreed Transmit Interval × BFD Multiplier
Với default settings (cả hai bên):
Agreed Transmit Interval = max(1000ms, 1000ms) = 1000ms
Detection Time = 1000ms × 5 = 5000ms = 5 giâySo sánh:
- BGP hold timer default (Cloud Router): 60 giây
- BGP hold timer common default (on-prem): 90-180 giây
- BFD detection time default: 5 giây ← cải thiện 12x đến 36x
Ý Nghĩa Thực Tế Của Detection Time
Khi forwarding path bị fail, có hai scenario:
Scenario 1: Instant failure (link down ngay lập tức) Cloud Router nhận tín hiệu "link down" từ physical layer → BFD session bị tắt ngay → BGP được thông báo ngay. Không cần chờ detection time.
Scenario 2: Gradual failure (packet loss tăng dần) Không có tín hiệu "link down" ở physical layer (ví dụ: intermediate device bị lỗi nhưng physical link vẫn up). BFD phải chờ packet loss vượt ngưỡng. Detection time = thời gian từ khi packet loss bắt đầu đến khi Multiplier packets liên tiếp bị miss.
Với default settings, trong worst case: 5 BFD packets (mỗi 1 giây) bị miss → detection sau 5 giây từ khi packet loss đạt 100%.
Tại sao không giảm timers xuống thấp hơn?
Có lý do GCP đặt minimum là 1000ms:
- Packet loss tự nhiên: Trên shared infrastructure (internet, shared Interconnect), có thể có intermittent packet loss. BFD timer quá ngắn sẽ gây false positive — BFD declares failure khi forwarding path thực ra vẫn ok.
- Processing overhead: BFD packets phải được processed ở cả hai bên. Timer quá ngắn tạo overhead không cần thiết.
BFD Và BGP Integration
Cơ Chế Thông Báo
Khi BFD detect failure:
- BFD session chuyển từ UP sang DOWN
- BFD thông báo ngay cho BGP control plane: "BFD neighbor không còn reachable"
- BGP nhận thông báo và tear down BGP neighbor relationship (không chờ hold timer)
- BGP withdraw tất cả routes học từ peer đó
- Dynamic route control plane cập nhật: routes từ peer đó bị remove
- VPC network control plane propagate changes
- Andromeda cập nhật forwarding table
- Traffic failover sang đường backup (nếu có)
Tổng thời gian từ failure đến convergence (với BFD): ~5 giây detection + ~vài giây propagation = <10 giây tổng
Không có BFD: ~60-180 giây hold timer + propagation = ~1-3 phút
BFD Session Và BGP Session Là Độc Lập
BFD session được thiết lập riêng, độc lập với BGP session. BGP session có thể UP mà BFD session là DOWN (nếu BFD chỉ được cấu hình ở một bên). BGP session có thể DOWN mà forwarding path vẫn OK (ví dụ: software issue).
Implication: BFD failure không nhất thiết có nghĩa là BGP failure và ngược lại. Khi troubleshoot, cần kiểm tra cả hai:
- BGP session state
- BFD session state
- Forwarding path (can ping BGP peer IP?)
Graceful Restart Và BFD
Với graceful restart enabled, khi BGP speaker cần restart (ví dụ software upgrade), nó có thể gửi AdminDown BFD state để báo hiệu cho peer rằng đây là planned restart, không phải forwarding failure. Peer có thể giữ forwarding state trong khoảng thời gian graceful restart, tránh traffic disruption không cần thiết.
Dampening — Tránh Flap Storms
Vấn Đề BGP Flapping
Một link không ổn định (flapping — liên tục up/down) có thể gây ra:
- BFD liên tục notify BGP: "peer down" rồi lại "peer up"
- BGP liên tục withdraw và re-advertise routes
- VPC route table thay đổi liên tục
- Traffic disruption và oscillation
Nếu không có cơ chế dampening, một link flapping mỗi vài giây có thể tạo ra hàng trăm route changes mỗi phút — gây cascade effects lên toàn bộ routing table.
Cơ Chế Dampening Của Cloud Router
Cloud Router implement một penalty-based dampening system cho BFD:
Penalty accumulation:
- Penalty bắt đầu ở 0
- Mỗi khi BFD flap xảy ra, penalty nhân đôi (doubling)
- Lần flap đầu: penalty = 1
- Lần flap thứ hai: penalty = 2
- Lần flap thứ ba: penalty = 4
- ...
Suppression:
- Khi penalty vượt ngưỡng 4: BGP notifications bị suppress (BFD không notify BGP nữa dù link vẫn flapping)
- Nghĩa là route thay đổi ngừng xảy ra — route bị giữ ở trạng thái cuối cùng
Penalty decay:
- Penalty giảm một nửa mỗi 10 phút khi không có flap mới
- Khi penalty về 0, suppression bị gỡ bỏ
Suppression duration tối đa: 1 giờ
Ví dụ timeline:
T=0: Link flap 1 → penalty = 1 (dưới ngưỡng 4, BGP notify)
T=1: Link flap 2 → penalty = 2 (dưới ngưỡng, BGP notify)
T=2: Link flap 3 → penalty = 4 (đạt ngưỡng → suppress)
T=3 đến T=60: Link tiếp tục flap → penalty tăng nhưng đã suppress, BGP không notify
T=60 (1h later): Suppression tối đa hết → BGP có thể notify lại
Penalty decay: Mỗi 10 phút không có flap, penalty giảm một nửaHệ quả của dampening: Nếu link của bạn đang flapping và BFD đang suppress notifications, route sẽ ở trạng thái "stuck" không thay đổi. Traffic có thể đang đi một đường không tối ưu. Đây là trade-off có chủ đích: stability > optimality trong trường hợp link không ổn định.
Cấu Hình BFD Trong Cloud Router
Enable BFD
BFD phải được enable ở cả hai phía của connection — Cloud Router và on-prem router. Nếu chỉ một bên enable, BFD session không thể được thiết lập.
# Enable BFD trên BGP peer trong Cloud Router
gcloud compute routers update-bgp-peer ROUTER_NAME \
--peer-name=PEER_NAME \
--bfd-session-initialization-mode=ACTIVE \
--bfd-min-transmit-interval=1000 \
--bfd-min-receive-interval=1000 \
--bfd-multiplier=5 \
--region=REGIONSession initialization mode:
ACTIVE: Cloud Router chủ động mở BFD sessionPASSIVE: Cloud Router chờ peer mở sessionDISABLED: BFD bị tắt
Verify BFD Status
# Kiểm tra BFD session status
gcloud compute routers get-status ROUTER_NAME \
--region=REGION \
--format='json(result.bgpPeerStatus)'Output sẽ bao gồm BFD session state cho mỗi BGP peer.
Tuning BFD Timers — Khi Nào Cần
Tình huống cần tăng timers:
- Intermittent packet loss trên link: Nếu có occasional packet loss tự nhiên, default 5s detection time có thể trigger false positive. Tăng multiplier lên 8-10 để cần nhiều packets miss hơn.
- High-latency links: Nếu BFD packets mất >500ms để đến peer, receiver có thể nhận packets trễ so với timer expectation.
Tình huống cần giảm timers (không possible dưới 1000ms trên GCP):
- Nếu muốn detection <5s, giải pháp duy nhất là không thể trên Cloud Router vì minimum là 1000ms interval.
Failure Modes Khi BFD Không Hoạt Động Đúng
One-Sided BFD Configuration
Nếu chỉ Cloud Router được cấu hình BFD nhưng on-prem router thì không, BFD session không được thiết lập (BFD cần cả hai bên). Cloud Router sẽ fall back về BGP hold timer cho failure detection.
Cách kiểm tra: BFD session status sẽ không ở UP state dù BGP là ESTABLISHED.
BFD Và Network Middleboxes
Một số network middleboxes (firewalls, NAT devices) block hoặc modify UDP packets. BFD dùng UDP ports 3784 (control) và 3785 (echo, không dùng trên Cloud Router). Nếu middlebox giữa Cloud Router và on-prem block UDP 3784, BFD session không lên được.
Trong Dedicated Interconnect và HA VPN, BFD packets đi trực tiếp trong tunnel, không qua internet middleboxes — nên thường không có vấn đề này.
BFD False Positive Trong Peak Load
Trong một số trường hợp, khi on-prem router bị CPU overload nặng (ví dụ đang xử lý large BGP table update), nó có thể không xử lý BFD packets kịp thời, dẫn đến BFD timeout mà forwarding path thực ra vẫn OK. Kết quả: BGP session bị reset không cần thiết.
Giải pháp: Tăng BFD multiplier (ví dụ từ 5 lên 8) để cần nhiều consecutive misses hơn trước khi declare failure. Điều này tăng resilience với intermittent CPU issues.
So Sánh: Với Và Không Có BFD
| Metric | Không BFD | Với BFD (default) |
|---|---|---|
| Failure detection time (instant fail) | ~vài giây | ~vài giây |
| Failure detection time (no link-down signal) | 60-180s (hold timer) | ~5s |
| Convergence time (total) | 60-180s + propagation | ~10-15s |
| False positive risk | Thấp | Thấp (với proper timers) |
| Link flapping protection | Không có | Dampening system |
| Thêm overhead | Không | Minimal (1 packet/s) |
Kết luận: Overhead của BFD (1 control packet/giây mỗi session) là không đáng kể so với lợi ích về failover speed. BFD nên được enable trong mọi production hybrid connectivity deployment.