
Mục lục bài viết 10 phần
BGP Monitoring Protocol (BMP) đưa route view và trạng thái peer từ router tới hệ thống quan sát, nhưng một phiên TCP “up” chưa chứng minh dữ liệu đầy đủ. Test plan cần tạo route có kết quả biết trước, đối chiếu từng RIB, gây lỗi collector và đo độ trễ từ thay đổi BGP đến bằng chứng truy vấn được.
Bài viết giúp bạn
- Câu hỏi BMP cần trả lời
- Topology và điểm lấy bằng chứng
- Route view nào đang được xuất
Câu hỏi BMP cần trả lời
#RFC 7854 định nghĩa BMP như giao diện giám sát BGP, không phải giao thức định tuyến. Router gửi Initiation/Termination, Peer Up/Down, Route Monitoring, Statistics Report và có thể Route Mirroring qua TCP. Câu hỏi đúng không phải “có nhận được BMP không”, mà là collector có dựng lại đúng route view theo peer, address family và policy hay không.
Phạm vi nên ghi rõ: số peer, AFI/SAFI, số prefix, tốc độ update/withdraw, view cần quan sát và thời gian lưu giữ. Nếu mục tiêu là audit policy, chỉ Adj-RIB-In pre-policy là chưa đủ; nếu mục tiêu là xác nhận route đã chọn, cần Loc-RIB hoặc nguồn bằng chứng tương đương.
Topology và điểm lấy bằng chứng
#Topology tối thiểu gồm route generator, router under test, một collector BMP chính, một collector dự phòng nếu thiết kế production có HA, và hệ thống capture/clock chung. Route generator phát tập prefix có manifest: peer, NLRI, path attributes, thời điểm advertise/withdraw và kết quả policy mong đợi.
Đối chiếu ba lớp: BGP update do generator phát, RIB/FIB trên router và bản ghi mà collector cung cấp. Với production replay, hãy khử hoặc thay địa chỉ nhạy cảm nhưng giữ phân phối prefix length, AS_PATH, communities và burst pattern.

Route view nào đang được xuất
#RFC 7854 mô tả Adj-RIB-In; RFC 8671 bổ sung Adj-RIB-Out và RFC 9069 bổ sung Loc-RIB. Cần xác nhận implementation, phiên bản phần mềm và cờ per-peer thực tế, không suy từ tên trường trên UI. Pre-policy cho biết peer đã gửi gì; post-policy cho biết kết quả inbound policy; Adj-RIB-Out cho biết router quảng bá gì; Loc-RIB phản ánh kết quả lựa chọn route cục bộ.
Một route xuất hiện trong collector nhưng gắn sai peer distinguisher, Route Distinguisher hoặc view vẫn là lỗi dữ liệu. Test case phải dùng cùng một prefix với thuộc tính khác nhau từ nhiều peer để bắt lỗi gộp khóa hoặc nhầm pre/post-policy.
Biến số phải kiểm soát
#Giữ cố định software build, BMP view, transport address, collector parser, clock source, BGP timers và policy. Chạy riêng baseline steady-state, burst update, sustained churn, initial dump lớn và reconnect. Ghi cả compression, queue, batch và retention của pipeline sau collector vì chúng có thể tạo latency hoặc mất dữ liệu ngoài BMP.
Không dùng một traffic profile cho mọi kết luận. Số prefix và updates/s phải tăng theo bậc; attribute size, add-path, VPN route và IPv6 được tách thành dimension. CPU cao do route selection khác với CPU cao do BMP export, nên cần control run tắt BMP với cùng tải BGP.
KPI và bằng chứng đầu ra
#KPI chính là completeness theo manifest, event latency theo percentile, duplicate rate, attribute fidelity, thời gian initial dump, reconnect time và thời gian collector trở lại trạng thái truy vấn đầy đủ. Theo dõi thêm CPU, memory, control-plane queue và BGP convergence của router để phát hiện quan sát gây ảnh hưởng dịch vụ.
- KPI: Route completeness · Cách đo: So tập khóa peer/view/NLRI với manifest · Bằng chứng: Diff có timestamp · Ngưỡng pass/fail: Theo SLO đã duyệt
- KPI: Attribute fidelity · Cách đo: Hash trường chuẩn hóa · Bằng chứng: Mẫu raw BMP + parser output · Ngưỡng pass/fail: Không sai trường bắt buộc
- KPI: Event latency · Cách đo: t_queryable - t_inject · Bằng chứng: Clock log và event ID · Ngưỡng pass/fail: p95/p99 theo use case
- KPI: Recovery · Cách đo: Từ lỗi đến full reconciliation · Bằng chứng: Timeline + snapshot RIB · Ngưỡng pass/fail: Theo RTO giám sát
- KPI: Router impact · Cách đo: So control run bật/tắt BMP · Bằng chứng: CPU, memory, convergence · Ngưỡng pass/fail: Không vượt ngân sách
Ma trận test case và quyết định
#Pass không nên chỉ dựa trên trạng thái cuối giống nhau: nếu collector bỏ mất flap ngắn, forensic và alerting vẫn sai. Với use case realtime, cần kiểm tra khả năng thu sự kiện của đúng implementation và dùng nguồn BGP raw độc lập nếu cần lịch sử không bỏ sót; không mặc định Route Monitoring là event journal; với inventory, snapshot cuối có thể quan trọng hơn nhưng phải nói rõ.
- Tình huống: Initial dump · Fault/load: N peer × M prefix · Điều cần chứng minh: Có End-of-RIB và đủ view · Quyết định: Chấp nhận bootstrap
- Tình huống: Churn · Fault/load: Burst advertise/withdraw · Điều cần chứng minh: Không mất/sai thứ tự trạng thái cuối · Quyết định: Chấp nhận pipeline
- Tình huống: Collector chậm · Fault/load: Giới hạn read/CPU · Điều cần chứng minh: Router không ảnh hưởng BGP · Quyết định: Điều chỉnh backpressure
- Tình huống: TCP reset · Fault/load: Ngắt giữa initial dump · Điều cần chứng minh: Reconnect và reconcile đầy đủ · Quyết định: Chấp nhận recovery
- Tình huống: Hai collector · Fault/load: Lỗi một đích · Điều cần chứng minh: Đích còn lại giữ SLO · Quyết định: Chấp nhận HA
- Tình huống: Parser mismatch · Fault/load: Thuộc tính mới/unknown · Điều cần chứng minh: Không làm hỏng stream · Quyết định: Nâng parser hoặc cô lập
Test plan từng bước
#- Bước 1: Chốt version matrix của router, collector, parser và schema; đồng bộ clock.
- Bước 2: Tạo manifest route mẫu theo nhiều peer/view trước khi tăng scale; 1.000–10.000 route chỉ là mức khởi đầu minh họa, không phải benchmark hay yêu cầu RFC.
- Bước 3: Capture BMP raw, router RIB/FIB và output truy vấn collector trong cùng cửa sổ.
- Bước 4: Chạy baseline không churn; xác nhận Peer Up, initial dump, End-of-RIB và completeness.
- Bước 5: Phát advertise/withdraw có event ID, đo p50/p95/p99 latency và fidelity.
- Bước 6: Tăng route scale và update rate theo bậc, giữ mỗi plateau đủ lâu để quan sát queue.
- Bước 7: Gây TCP reset, collector restart, disk-full hoặc parser reject theo từng lỗi độc lập.
- Bước 8: Reconcile lại snapshot và lưu diff, resource graph, pcap cùng cấu hình.

Runbook lỗi collector và phục hồi
#Khi alarm mất BMP xuất hiện, trước hết phân biệt BGP peer down với TCP BMP down. Lưu connection state, buffer/drop counter, CPU và disk của collector; không restart đồng thời mọi thành phần. Sau reconnect, đợi initial dump hoàn tất rồi so snapshot với router, thay vì mặc định dữ liệu backlog đã đủ.
Checklist vận hành:
- Xác định exporter, collector, peer và view bị ảnh hưởng.
- Đóng dấu thời điểm lỗi từ ít nhất hai nguồn clock.
- Bảo toàn raw stream/log trước thao tác phục hồi.
- Kiểm tra End-of-RIB và số route sau reconnect.
- Reconcile route/attribute, không chỉ đếm tổng.
- Xác nhận alert và dashboard hết stale theo điều kiện rõ ràng.
Giới hạn kết luận
#BMP phản ánh dữ liệu mà implementation xuất, không tự chứng minh packet đã được forward đúng. Muốn kết luận service path, cần phép đo data plane. Kết quả ở một AFI/SAFI, một software build hoặc một collector parser không đại diện cho mọi view và phiên bản.
Trong phạm vi BMP và các extension được dẫn ở đây, TCP bảo đảm thứ tự byte khi phiên còn hoạt động, không bảo đảm collector đã lưu bền vững mọi sự kiện. Router có thể gộp cập nhật trung gian hoặc mất sự kiện khi phiên gián đoạn; initial dump sau reconnect khôi phục trạng thái hiện tại, không phải lịch sử đầy đủ. Reconciliation với manifest/RIB snapshot và kiểm tra raw-to-query là bắt buộc nếu dùng dữ liệu cho audit hoặc incident response.
Khái niệm cần nhớ
#- BMP: giao thức xuất thông tin giám sát BGP tới monitoring station.
- Adj-RIB-In: route nhận từ peer, có thể xét pre-policy hoặc post-policy.
- Adj-RIB-Out: route được chuẩn bị/quảng bá tới peer.
- Loc-RIB: route cục bộ sau quá trình lựa chọn.
- Initial dump: ảnh chụp route ban đầu sau khi phiên BMP thiết lập.
- Reconciliation: đối chiếu hai nguồn dữ liệu để phát hiện thiếu hoặc sai.
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.
