
Mục lục bài viết 9 phần
Ngày đăng · 16 phút đọc BFD có thể báo lỗi đường truyền nhanh, nhưng người dùng chỉ thấy dịch vụ phục hồi sau khi routing protocol xử lý sự kiện, RIB/FIB cập nhật, ECMP rehash và luồng dữ liệu ổn định. Vì vậy không nên lấy thời gian BFD Down làm số liệu hội tụ end-to-end.
Bài viết giúp bạn
- Câu hỏi kiểm thử cần trả lời
- Topology và timeline đo
- Timer và biến số phải kiểm soát
Câu hỏi kiểm thử cần trả lời
#RFC 5880 định nghĩa BFD để phát hiện lỗi trên đường hai chiều giữa các forwarding engine. Câu hỏi của lab là BFD phát hiện đúng loại lỗi nào, upper-layer protocol phản ứng ra sao và traffic mất bao nhiêu gói. BFD không thay routing protocol và không tự lập trình đường dự phòng.
Phạm vi phải ghi single-hop/multihop, IPv4/IPv6, asynchronous/echo nếu có, protocol gắn với BFD và HA/ECMP behavior. Không dùng timer cấu hình như kết quả đo.
Một tiêu chí tốt phải trả lời được ba lớp. Lớp protocol xác nhận phiên BFD chuyển trạng thái đúng. Lớp forwarding chứng minh route dự phòng thực sự được cài vào FIB. Lớp dịch vụ đo tác động mà endpoint nhìn thấy. Nếu chỉ một lớp đạt, verdict không nên ghi “hội tụ đạt SLA”.
Topology và timeline đo
#Dùng hai path giữa source–destination, traffic generator có sequence number, router DUT, điểm capture và đồng hồ đồng bộ. Chèn failure tại link trực tiếp, transit node hoặc forwarding path để phân biệt physical-down với black hole.
Timeline: T0 lỗi được kích hoạt; T1 BFD Down; T2 routing adjacency/path đổi; T3 FIB hoàn tất; T4 gói đầu tiên nhận lại; T5 KPI ổn định. Service interruption là T0–T4/T5, không phải chỉ T0–T1.
Trigger phải có timestamp độc lập: tắt cổng bằng relay, drop có kiểm soát trên emulator hoặc chặn forwarding nhưng giữ carrier. Mỗi cách tạo lỗi trả lời một câu hỏi khác nhau. Việc shutdown interface thường kích hoạt tín hiệu vật lý trực tiếp, do đó không đại diện cho lỗi transit im lặng. Với multihop BFD, cần đặt capture ở cả hai đầu và xác nhận đường đi của control packet có trùng với data path cần bảo vệ hay không.

Timer và biến số phải kiểm soát
#Ghi Desired Min TX, Required Min RX, Detect Mult, negotiated interval, authentication, echo và hardware offload. Timer quá thấp ở hàng nghìn session có thể tăng CPU hoặc false down khi control plane bận.
Khóa routing timers/policy, BGP PIC/FRR, ECMP, traffic rate, flow entropy, MTU, QoS và background control-plane load. Với asymmetric path, kiểm tra hai hướng riêng.
Negotiated interval là giá trị vận hành cần lưu, vì hai peer có thể quảng bá timer khác nhau. Với echo mode, ghi rõ thiết bị nào loop packet và forwarding path được sử dụng. Với authentication, theo dõi cả chi phí xử lý và hành vi khi key sai hoặc đổi key. Không thay timer trong lúc chạy rồi gộp dữ liệu vào cùng một baseline.
KPI và bằng chứng
#KPI gồm BFD detection time, notification-to-route time, RIB-to-FIB time, total interruption, packet loss, duplicate, reorder, latency transient và số session false flap. Theo dõi CPU/memory, BFD packets và routing updates.
Bằng chứng tối thiểu: packet capture BFD và data, event log có timestamp, RIB/FIB snapshot, traffic result và cấu hình timer. Nếu timestamp từ nhiều máy, ghi sai số clock.
Nên báo cáo percentile cho thời gian gián đoạn qua nhiều lần lặp, thay vì chỉ lấy lần nhanh nhất. Packet loss cần quy đổi cả theo số gói và thời gian ở offered load đã biết. Một khoảng mất 1.000 gói ở 10 Mpps khác hoàn toàn 1.000 gói ở 10 kpps; raw counter đơn lẻ không đủ để so sánh hai cấu hình.
Ma trận lỗi
#- Sự kiện: Physical link down · BFD kỳ vọng: Down nhanh · Dịch vụ kỳ vọng: Chuyển path, loss dưới ngưỡng
- Sự kiện: Transit black hole · BFD kỳ vọng: Phụ thuộc đường BFD · Dịch vụ kỳ vọng: Phát hiện nếu BFD đi đúng forwarding path
- Sự kiện: Lỗi một chiều · BFD kỳ vọng: Một/both end Down · Dịch vụ kỳ vọng: Không giữ path không dùng được
- Sự kiện: Peer process restart · BFD kỳ vọng: Session transition rõ · Dịch vụ kỳ vọng: Route phục hồi ổn định
- Sự kiện: Microburst loss · BFD kỳ vọng: Không false flap ngoài ngưỡng · Dịch vụ kỳ vọng: Không chuyển đường quá mức
- Sự kiện: Path flapping · BFD kỳ vọng: Hold/protection đúng thiết kế · Dịch vụ kỳ vọng: Không routing churn kéo dài
- Sự kiện: Backup path congestion · BFD kỳ vọng: BFD vẫn Up · Dịch vụ kỳ vọng: KPI báo degraded, không gọi là BFD failure
Test plan chức năng và hiệu năng
#Baseline phiên Up và traffic ổn định. Gây từng lỗi, giữ đủ lâu, phục hồi rồi lặp ít nhất ba lần. Tăng dần loss burst để tìm false-positive boundary; không thay timer và loss cùng lúc.
Thử flow mới và flow hiện hữu, nhiều packet size và flow entropy. Khi path primary trở lại, đo failback/rehash. Nếu total offered load vượt capacity backup, tách congestion loss khỏi convergence loss.
Chạy hai profile: constant-rate để dễ dựng timeline và mixed IMIX/application-like để quan sát tác động thực tế. Với ECMP, số flow phải đủ lớn để thấy phân bố nhưng cũng cần một nhóm pinned flow để nhận diện per-flow black hole. Pass/fail nên nêu riêng detection, route/FIB và service recovery; không lấy trung bình che mất một lần hội tụ bất thường.
Scale, flapping và bảo vệ control plane
#Tăng số BFD session theo bước ở steady state và khi nhiều session đồng thời Down/Up. Theo dõi CPU, scheduling jitter, packet drop và thời gian xử lý event. Scale test cần chạy đủ lâu để phát hiện drift.
Thử control-plane policing và congestion hợp lệ để bảo đảm BFD không bị drop do chính policy bảo vệ. Authentication/TTL validation cần kiểm tra theo profile và phiên bản, nhưng không phát flood ngoài lab.

Runbook thực hành
#- Chốt BFD mode, protocol và negotiated timer.
- Đồng bộ clock, lưu baseline RIB/FIB.
- Phát traffic có sequence number hai chiều.
- Thử link down, black hole, lỗi một chiều và restart.
- Đo T0–T5, loss/reorder/duplicate.
- Thử microburst và flapping.
- Tăng session scale/background load.
- Kiểm tra backup capacity/failback.
- Lưu pcap, log, config và verdict.
Giới hạn kết luận
#Kết quả phụ thuộc hardware offload, NOS, routing feature, timer và scale. BFD Up chỉ chứng minh path được phiên BFD quan sát, không chứng minh application SLA. BFD Down nhanh không bảo đảm FIB hoặc dịch vụ phục hồi nhanh.
Không so sánh thiết bị nếu failure trigger, session scale, traffic và timestamp method khác nhau.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
