PACKET FLOW

Kiểm thử BGP Monitoring Protocol: route view, collector loss và scale

13/9/2026 · 16 phút

Router BGP gửi BMP route monitoring tới hai collector và được đối chiếu với route generator
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.

ĐỌC NHANH

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
Tùy chỉnh đọc
01

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.

02

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.

Minh họa: Nguồn BGP độc lập, router và hai collector tạo các điểm đối chiếu route view; sơ đồ khái niệm, không phải topology sản phẩm.
Minh họa: Nguồn BGP độc lập, router và hai collector tạo các điểm đối chiếu route view; sơ đồ khái niệm, không phải topology sản phẩm.
03

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.

04

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.

05

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
06

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
07

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.
Minh họa: Gián đoạn collector, kết nối lại và đối chiếu trạng thái; không hàm ý BMP có thể phát lại toàn bộ sự kiện bị mất.
Minh họa: Gián đoạn collector, kết nối lại và đối chiếu trạng thái; không hàm ý BMP có thể phát lại toàn bộ sự kiện bị mất.
08

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.
09

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.

10

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.
THUẬT NGỮ NHANH

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.

Nguyên tắc biên tập

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.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật