NETWORK TESTING

Kiểm thử SRv6 policy failover: từ SID list đến packet loss

8/8/2026 · 16 phút

Hai SRv6 policy đưa lưu lượng qua các segment và chuyển đường khi link hoặc node lỗi
Mục lục bài viết 9 phần

SRv6 cho phép mã hóa đường đi và hành vi mạng trong Segment Routing Header, nhưng một policy được cài thành công chưa bảo đảm gói tin theo đúng segment list hoặc hội tụ không làm rơi dịch vụ. Bài này nối trạng thái control plane với capture, counter và KPI đầu-cuối.

ĐỌC NHANH

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

  • SRv6 policy cần chứng minh đ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

SRv6 policy cần chứng minh điều gì?

#

Ba lớp cần tách riêng: controller tính được policy, headend cài được segment list, và dataplane thực thi đúng hành vi tại từng SID. Trạng thái “up” ở controller chỉ là điều kiện cần. Sai locator, route recursion hoặc MTU có thể khiến traffic blackhole dù policy vẫn hiển thị hợp lệ.

Xác định trước câu hỏi: traffic có đi đúng constraint không; khi link/node/SID lỗi thì chuyển sang policy dự phòng trong bao lâu; dịch vụ có vượt loss hoặc latency budget không; và sau khi phục hồi có oscillation hay reordering kéo dài không.

02

Topology và điểm quan sát

#

Topology tối thiểu gồm source PE/headend, hai đường transit độc lập, endpoint PE và generator hai chiều. Tạo policy chính qua SID list A và policy dự phòng qua SID list B; nếu có controller/PCE, thu log quyết định nhưng vẫn phải capture ở ingress, một transit và egress.

Đồng bộ thời gian giữa generator, router và collector. Lưu FIB, SR policy, locator, SID table, interface counter và capture trước/sau sự kiện. Gắn flow ID hoặc sequence number để tính loss, duplicate và out-of-order thay vì suy từ throughput trung bình.

Topology kiểm thử SRv6 policy chính và dự phòng với điểm đo ingress, transit và egress
Topology kiểm thử SRv6 policy chính và dự phòng với điểm đo ingress, transit và egress
03

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

#

Khóa phiên bản NOS, SRH mode, encapsulation, locator length, SID flavor, routing underlay, MTU và ECMP. Ghi rõ endpoint behavior như End, End.X, End.DX6 hoặc hành vi khác; không dùng tên SID chung chung rồi suy diễn xử lý giống nhau.

Traffic profile phải gồm IPv6 packet size khác nhau, flow count, direction, rate và DSCP. Chạy cả dưới tải thấp và tải gần ngưỡng dự kiến. Một bài ping nhỏ không phát hiện SRH overhead, queue congestion hoặc reordering đa luồng.

04

KPI và bằng chứng đầu ra

#

Đo service interruption từ gói tốt cuối trước lỗi đến gói tốt đầu tiên trên đường hợp lệ; báo cả median và worst case qua nhiều lần. Kèm packet loss, duplicate, out-of-order, latency p95/p99, jitter, convergence control plane, route/SID churn và sai lệch giữa intended path với observed path.

  • KPI: Path compliance · Phép đo: SID list/capture tại transit · Bằng chứng: PCAP + FIB snapshot · Gợi ý pass/fail: Đúng policy đã khai báo
  • KPI: Interruption · Phép đo: Sequence/timestamp đầu-cuối · Bằng chứng: Raw flow record · Gợi ý pass/fail: Trong SLA đã duyệt
  • KPI: Packet loss · Phép đo: Tx/Rx theo sequence · Bằng chứng: Generator result · Gợi ý pass/fail: Không vượt loss budget
  • KPI: MTU behavior · Phép đo: Sweep frame size · Bằng chứng: PCAP/counter ICMPv6 · Gợi ý pass/fail: Không silent drop
  • KPI: Recovery stability · Phép đo: Lặp lỗi/phục hồi · Bằng chứng: Timeline + churn · Gợi ý pass/fail: Không flap kéo dài
05

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

#
  • Kịch bản: Link transit down · Fault injection: Tắt một link trong path A · Điểm cần chứng minh: Chuyển path B, loss có giới hạn
  • Kịch bản: Node transit mất · Fault injection: Cô lập node có SID · Điểm cần chứng minh: Không giữ stale path gây blackhole
  • Kịch bản: SID không reachable · Fault injection: Rút route locator · Điểm cần chứng minh: Policy invalid/fallback đúng thiết kế
  • Kịch bản: MTU thiếu headroom · Fault injection: Hạ MTU một đoạn · Điểm cần chứng minh: ICMPv6/PMTUD hoặc drop được phát hiện
  • Kịch bản: Controller mất · Fault injection: Ngắt controller · Điểm cần chứng minh: Dataplane giữ trạng thái theo thiết kế
  • Kịch bản: Phục hồi path · Fault injection: Bật lại thành phần · Điểm cần chứng minh: Không oscillation, duplicate kéo dài
06

Test plan theo từng pha

#

Pha baseline xác minh IGP/BGP, SID reachability, policy preference và traffic không lỗi. Pha functional dùng lưu lượng thấp để đối chiếu segment list quan sát được với thiết kế. Pha scale tăng flow/rate và số policy theo từng bước, luôn kiểm tra generator chưa chạm giới hạn.

Pha resiliency tiêm từng lỗi một, ghi timestamp T0 lỗi, T1 control plane nhận biết, T2 policy/FIB đổi, T3 traffic ổn định. Lặp tối thiểu nhiều lần cho mỗi hướng. Cuối cùng phục hồi và kiểm tra đường quay lại có theo thiết kế hay gây route churn.

Timeline đo hội tụ SRv6 từ lúc tiêm lỗi đến khi lưu lượng ổn định
Timeline đo hội tụ SRv6 từ lúc tiêm lỗi đến khi lưu lượng ổn định
07

Checklist nghiệm thu

#
  • Lưu topology, version, cấu hình locator/SID và policy.
  • Xác minh đồng bộ thời gian và sequence tracking.
  • Capture đủ ingress/transit/egress cho kịch bản đại diện.
  • Sweep packet size để kiểm tra SRH overhead và MTU.
  • Chạy lỗi link, node, SID reachability và controller riêng biệt.
  • Báo worst-case interruption, không chỉ throughput trung bình.
  • Kiểm tra rollback và trạng thái sau recovery.
08

Giới hạn của kết luận

#

Kết quả chỉ có giá trị cho NOS, phần cứng, SID behavior, underlay và traffic profile đã ghi. Không suy rộng từ một policy sang toàn mạng hoặc từ lab không tải sang production. Nếu dùng implementation extension, phải tách rõ chuẩn RFC với hành vi riêng của vendor.

09

Khái niệm cần nhớ

#
  • SID: Định danh segment kèm hành vi xử lý.
  • SRH: IPv6 Segment Routing Header chứa segment list và trường điều khiển.
  • Headend: Node áp policy SRv6 lên lưu lượng.
  • Locator: Prefix dùng định tuyến tới nhóm SID.
  • Endpoint behavior: Hành vi thực hiện khi gói đến SID.
  • Service interruption: Khoảng dịch vụ không giao nhận gói hợp lệ.
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