NETWORK TESTING

Kiểm thử BGP Graceful Restart và Route Reflector failover

6/8/2026 · 16 phút

Hai route reflector phục vụ nhiều BGP client trong bài kiểm thử graceful restart và failover
Mục lục bài viết 9 phần

BGP Graceful Restart có thể giữ route trong lúc control plane khởi động lại, nhưng stale route vẫn có thể blackhole traffic nếu forwarding state không còn đúng. Bài này đo riêng session recovery, route convergence và service interruption khi route reflector hoặc client lỗi.

ĐỌC NHANH

Bài viết giúp bạn

  • Graceful Restart giải quyết điều gì?
  • Topology và điểm quan sát
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Graceful Restart giải quyết điều gì?

#

RFC 4724 cho phép peer giữ route đã học trong một cửa sổ khi BGP speaker restart, dựa trên capability và giả định forwarding state được bảo toàn. Route được đánh dấu stale rồi được refresh hoặc loại bỏ sau End-of-RIB/timer. Cơ chế này giảm churn nhưng có thể kéo dài blackhole nếu giả định forwarding không đúng.

Route reflector giảm số phiên iBGP nhưng tạo điểm điều phối control plane. Hai RR không mặc nhiên tạo failover hoàn chỉnh: client policy, cluster ID, add-path, multipath, IGP reachability và next-hop resolution vẫn quyết định đường dữ liệu.

02

Topology và điểm quan sát

#

Topology gồm hai RR, ít nhất ba client, traffic generator ở hai prefix edge và collector BMP/telemetry nếu có. Mỗi client peering với cả hai RR. Một điểm capture/update log ở control plane và sequence traffic ở data plane giúp nối T0 gây lỗi đến T5 dịch vụ phục hồi.

Chạy baseline khi cả hai RR hoạt động; ghi số prefix, attribute mix, best-path distribution và route churn tự nhiên. Không thay IGP, policy hoặc timer giữa các lượt so sánh.

Topology kiểm thử hai route reflector và các điểm đo control/data plane
Topology kiểm thử hai route reflector và các điểm đo control/data plane
03

Biến số phải kiểm soát

#

Ghi NOS/version, GR capability, restart/stale timer, LLGR, BFD, hold/keepalive, route-refresh, add-path, multipath, cluster ID, next-hop-self và policy. Khóa prefix count, update rate, AS-path/community mix và traffic profile.

  • Biến: Prefix scale · Mức thử: nhỏ, mục tiêu, đỉnh · Rủi ro: CPU/RIB/FIB backlog
  • Biến: Restart type · Mức thử: process, supervisor, reboot · Rủi ro: Khác khả năng giữ FIB
  • Biến: RR failure · Mức thử: một RR, cả hai, path · Rủi ro: Control-plane isolation
  • Biến: Stale timer · Mức thử: theo cấu hình · Rủi ro: Blackhole kéo dài
  • Biến: BFD · Mức thử: bật/tắt · Rủi ro: Xung đột mục tiêu GR
  • Biến: Update burst · Mức thử: steady/burst · Rủi ro: Churn và queue
04

KPI và bằng chứng

#

KPI gồm session-down/up time, End-of-RIB time, route retention, stale-prefix duration, update/withdraw count, RIB-to-FIB delay, packet loss, reorder, latency và application interruption. Đo số route sai next-hop, không chỉ tổng route.

Bằng chứng gồm capability negotiation, BGP event/update, RIB/FIB snapshot, GR state, CPU/memory, sequence traffic và capture. Pass/fail phải nêu RR/client/version, lỗi được tiêm và SLO; “session Established trong 30 giây” không đủ nếu traffic mất lâu hơn.

05

Ma trận kịch bản quyết định

#
  • Sự kiện: Restart BGP process RR1 · Điều cần chứng minh: Client giữ/refresh route đúng · Dấu hiệu fail: Stale quá timer hoặc churn lớn
  • Sự kiện: Reboot RR1 · Điều cần chứng minh: RR2 duy trì control plane · Dấu hiệu fail: Traffic blackhole
  • Sự kiện: Mất path client–RR1 · Điều cần chứng minh: RR2 tiếp tục update · Dấu hiệu fail: Policy khác biệt gây route sai
  • Sự kiện: Client mất forwarding · Điều cần chứng minh: Peer loại stale đúng · Dấu hiệu fail: Route vẫn giữ và blackhole
  • Sự kiện: Cả hai RR restart lệch · Điều cần chứng minh: Không split view · Dấu hiệu fail: Prefix thiếu/loop
  • Sự kiện: Update burst khi recovery · Điều cần chứng minh: Queue thoát và hội tụ · Dấu hiệu fail: RIB/FIB backlog kéo dài
06

Test plan theo từng pha

#
  • Đồng bộ thời gian; lưu config, capability và baseline route.
  • Phát traffic có sequence qua các prefix đại diện.
  • Restart riêng BGP process trên RR1.
  • Lặp với supervisor/VM/container restart theo nền tảng.
  • Mất đường client–RR1 trong khi RR1 còn sống.
  • Gây lỗi forwarding ở client để thử stale-route risk.
  • Tăng prefix/update burst trong cửa sổ recovery.
  • Lặp với BFD bật/tắt và timer được phê duyệt.
  • Khôi phục; so RIB/FIB, best path và traffic.
  • Chạy ít nhất ba lần; xuất percentile và verdict.
Dòng thời gian BGP graceful restart, stale route và phục hồi dịch vụ
Dòng thời gian BGP graceful restart, stale route và phục hồi dịch vụ
07

Checklist nghiệm thu

#
  • Hai RR có policy/capability được đối chiếu.
  • Đã xác nhận GR negotiation hai chiều.
  • Stale timer phù hợp với failure model.
  • Đã thử lỗi không giữ được forwarding state.
  • RIB và FIB được quan sát riêng.
  • Update burst thử trong recovery.
  • BFD/IGP interaction đã ghi.
  • Packet loss đo đầu-cuối, không suy từ log.
  • RR recovery không tạo split view/loop.
  • Runbook có điều kiện vô hiệu GR nếu blackhole.
08

Giới hạn kết luận

#

GR behavior phụ thuộc implementation, AFI/SAFI, restart type và khả năng giữ FIB. Kết quả IPv4 unicast không tự áp dụng EVPN, VPNv4/v6 hoặc flowspec. RR failover không thay thế thiết kế IGP và next-hop redundancy.

Generator có thể đạt prefix scale nhưng không tái tạo attribute/update distribution production. Báo cáo phải giữ seed/profile để tái lập, tránh công bố “hitless” khi độ phân giải packet không đủ thấy micro-outage.

09

Khái niệm cần nhớ

#
  • Graceful Restart: Giữ route tạm thời trong lúc peer restart.
  • Stale route: Route được giữ nhưng chưa được refresh.
  • End-of-RIB: Marker kết thúc cập nhật ban đầu.
  • Route Reflector: Giảm full-mesh iBGP bằng phản xạ route.
  • RIB/FIB: Bảng định tuyến control plane và forwarding plane.
  • Control-plane churn: Khối lượng update/withdraw do biến động.
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ảo5 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