Kiểm thử BGP Graceful Restart và LLGR: giữ forwarding nhưng không giữ route sai

RFC 4724 mô tả cơ chế để BGP speaker báo khả năng Graceful Restart và để peer hỗ trợ giữ route trong một khoảng thời gian. RFC 9494 mở rộng bằng LLGR cho một số trường hợp cần thời gian khôi phục dài hơn. Hai cơ chế không tự chứng minh data plane còn chuyển tiếp đúng: peer có thể giữ route trong RIB trong khi next hop hoặc FIB không còn hợp lệ.

Phép thử cần trả lời ba câu hỏi: phiên BGP có thương lượng capability đúng không; forwarding có liên tục trong từng kiểu restart không; và route lỗi có bị rút hoặc hạ ưu tiên đủ nhanh khi topology thay đổi. Cần tách planned restart, process crash, route-engine switchover, line-card failure và mất nguồn vì không phải lỗi nào cũng thỏa điều kiện GR.

Topology tối thiểu gồm hai router biên, hai upstream/route-generator, một prefix nguồn và một prefix đích có đường dự phòng. Traffic generator phát nhiều flow liên tục qua DUT; observation point thu BGP update, RIB/FIB, next-hop resolution và packet ở cả ingress lẫn egress. Với chassis hai route processor, thêm tín hiệu active/standby và trạng thái line card.

Đồng bộ clock cho generator, router và collector. Lấy baseline khi không có lỗi: negotiated capabilities, route count, best path, ECMP membership, packet loss, latency và path. Sau đó chỉ thay đổi một fault tại mỗi case.

Khóa implementation, phiên bản, AFI/SAFI, iBGP/eBGP, policy, BFD, IGP, ECMP, next-hop tracking, restart time, stale-path time và LLGR_STALE community. Ghi rõ router đóng vai restarting speaker hay helper; capability có thể khác theo address family hoặc peer.

Traffic profile cần giữ ổn định packet size, flow count, rate, entropy và ứng dụng mô phỏng. Quét lần lượt process restart, route-processor switchover, peer reset, mất link, mất next hop, thay đổi origin và withdrawal trong cửa sổ stale. Nếu BFD đang bật, phải xác định nó làm session rơi và ảnh hưởng GR ra sao theo implementation.

KPI control plane gồm session downtime, End-of-RIB timing, số route được đánh stale, thời gian RIB hội tụ và thời gian FIB cập nhật. KPI dịch vụ gồm packet loss, outage duration, throughput, latency/jitter, flow reset và path correctness. Với route bị thay đổi trong lúc restart, stale exposure time là KPI bắt buộc.

Bộ bằng chứng tối thiểu: capability dump, BGP updates, RIB/FIB snapshot trước–trong–sau lỗi, route policy, event log, packet capture, generator result theo thời gian và cấu hình timer. Chỉ dựa vào ping có thể bỏ sót microburst loss, ECMP member sai hoặc flow cũ còn sống trong khi flow mới thất bại.

Ngưỡng không nên chỉ ghi “không mất gói”. Hãy đặt packet-loss budget, thời gian gián đoạn tối đa và stale exposure riêng cho từng dịch vụ; đồng thời quy định không chấp nhận loop hoặc giao traffic sang đường đã bị thu hồi.

• Tình huống: Planned control-plane restart · Kỳ vọng: Forwarding liên tục theo SLO · Bằng chứng chính: traffic timeline + FIB · Dấu hiệu fail: outage vượt ngưỡng
• Tình huống: Peer làm helper, topology không đổi · Kỳ vọng: Route stale được giữ rồi refresh · Bằng chứng chính: update + RIB flags · Dấu hiệu fail: route bị rút sớm hoặc giữ quá lâu
• Tình huống: Prefix bị rút trong cửa sổ restart · Kỳ vọng: Không tiếp tục gửi vào đường chết · Bằng chứng chính: egress PCAP + FIB · Dấu hiệu fail: blackhole do stale route
• Tình huống: Next hop mất khả năng reach · Kỳ vọng: Chuyển sang path hợp lệ · Bằng chứng chính: next-hop/FIB timeline · Dấu hiệu fail: RIB đúng nhưng FIB sai
• Tình huống: Capability mismatch · Kỳ vọng: Fallback an toàn · Bằng chứng chính: OPEN message + logs · Dấu hiệu fail: giả định GR nhưng peer không hỗ trợ
• Tình huống: LLGR hết timer · Kỳ vọng: Route còn stale bị loại · Bằng chứng chính: route timeline · Dấu hiệu fail: stale tồn tại ngoài timer

Đầu tiên xác minh BGP OPEN capability và timer thực tế. Gây planned restart trên speaker, quan sát helper đánh dấu route, FIB tiếp tục chuyển tiếp và End-of-RIB kết thúc giai đoạn khôi phục. Lặp lại với process crash và route-engine switchover để xác định trường hợp nào không giữ forwarding.

• Lưu baseline capability, RIB, FIB và traffic.
• Chạy restart trên từng peer, từng AFI/SAFI.
• Đo session down/up, End-of-RIB và service outage.
• So sánh flow đang tồn tại với flow khởi tạo mới.
• Xác nhận route không bị nhân đôi hoặc sai attribute sau recovery.
• Lặp lại khi helper bị quá tải control plane.

Trong lúc speaker đang restart, rút prefix từ nguồn thật hoặc làm next hop mất reachability. Kỳ vọng phụ thuộc policy và khả năng phát hiện của hệ thống, nhưng báo cáo phải chứng minh traffic không bị giữ trên đường chết vượt ngưỡng. Với multipath, kiểm từng member; aggregate throughput có thể che một nhánh blackhole.

Nếu dùng LLGR, kiểm tra LLGR_STALE community: route mang community này phải được xử lý là least preferred, thấp hơn mọi route không thuộc nhóm least preferred, không chỉ giảm LOCAL_PREF một mức tùy ý. Kiểm tra thêm NO_LLGR: route mang community này không được giữ sang giai đoạn LLGR. Thử một route thay thế có local preference khác, route leak mô phỏng trong lab và hết timer. Không dùng traffic hoặc route ngoài phạm vi được phép.

Tăng route count, peer count và update rate theo bậc; giữ traffic application song song để phát hiện CPU hoặc programming queue kéo dài hội tụ. Báo cáo percentile thay vì chỉ trung bình, nhất là thời gian FIB và packet-loss burst.

Triển khai canary trên một cặp peer, giám sát capability mismatch, stale count và outage. Chuẩn bị rollback timer/policy, OOB access và điều kiện tắt GR nếu stale route gây blackhole. Regression bắt buộc sau đổi NOS, route policy, BFD, IGP hoặc phần cứng forwarding.

Kết quả chỉ đúng cho topology, peer implementation, phiên bản, AFI/SAFI, timer, policy, route scale và fault model đã thử. GR không thay thế fast reroute, thiết kế đa đường hay kiểm chứng data plane.

Không suy “zero packet loss” nếu độ phân giải đo thấp hơn outage. LLGR kéo dài thời gian khôi phục nhưng cũng kéo dài rủi ro stale; quyết định bật phải dựa trên failure model và SLO cụ thể.

• Restarting speaker: BGP node có control plane khởi động lại.
• Helper: peer giữ route của restarting speaker trong thời gian cho phép.
• End-of-RIB: marker cho biết hoàn tất gửi routing information ban đầu.
• Stale route: route được giữ tạm nhưng chưa được speaker xác nhận lại.
• LLGR: cơ chế giữ route lâu hơn GR thông thường theo RFC 9494.
• RIB/FIB: bảng quyết định tuyến và bảng forwarding thực tế.
• Stale exposure: thời gian traffic có thể còn đi theo route cũ.