NETWORK EMULATION

Kiểm thử GRE tunnel: overhead, MTU, fragment, keepalive và failover

18/9/2026 · 15 phút

Minh họa: Kết nối mạng qua đường hầm GRE. Ảnh AI, không phải kết quả đo.
Mục lục bài viết 9 phần

GRE đóng gói payload mạng vào một delivery protocol nhưng không tự mã hóa hay bảo đảm sống còn. Tunnel có thể “up” trong khi payload lớn blackhole, keepalive bỏ sót failure một chiều hoặc route tiếp tục đẩy traffic vào đường hỏng. Bài đo phải nhìn cả overlay, underlay và giao dịch ứng dụng.

ĐỌC NHANH

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

  • Câu hỏi kỹ thuật cần trả lời
  • Topology và điều kiện đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Câu hỏi kỹ thuật cần trả lời

#

GRE định nghĩa cơ chế encapsulation; availability và bảo mật đến từ các lớp xung quanh. Test plan cần xác nhận loại payload, outer IP version, checksum/key/sequence option nếu dùng, routing overlay/underlay, tunnel source/destination và cơ chế phát hiện lỗi. Trạng thái interface up không chứng minh remote endpoint nhận được payload.

Cần trả lời underlay giảm MTU ra sao, ai fragment hoặc gửi ICMP, TCP MSS được điều chỉnh ở đâu, failure một chiều được phát hiện bằng gì và route overlay rút trong bao lâu. Nếu GRE chạy qua IPsec, cloud gateway hoặc ECMP, phải tính toàn bộ overhead và state/failure domain bổ sung.

02

Topology và điều kiện đo

#

Topology gồm generator hai phía, hai GRE endpoint, underlay router, network impairment emulator và capture ở inner lẫn outer interface. Dùng nhiều đường underlay nếu production có ECMP/HA. Thêm ứng dụng TCP/UDP dài hạn và short-flow để nhìn khác biệt giữa forwarding ổn định với reconvergence.

Khóa endpoint model/software, outer/inner addressing, GRE options, MTU, routing protocol/static route, keepalive/BFD nếu có, IPsec stack, QoS, ECMP hash và firewall. Đồng bộ thời gian; chạy baseline không tunnel và GRE không impairment trước khi thêm loss, latency, jitter, reordering hoặc MTU restriction.

Minh họa: Phân biệt mạng bên trong và đường truyền bên ngoài GRE. Ảnh AI, không phải kết quả đo.
Minh họa: Phân biệt mạng bên trong và đường truyền bên ngoài GRE. Ảnh AI, không phải kết quả đo.
03

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

#

Traffic profile gồm 64-byte, IMIX, near-MTU, jumbo, TCP/UDP/ICMP, IPv4/IPv6 payload, unicast/multicast nếu cần, flow ngắn/dài và DSCP khác nhau. Quét payload quanh ngưỡng MTU theo từng byte để bắt boundary. Ghi DF behavior, ICMP filtering, MSS clamp, NIC offload và fragment reassembly timeout.

Impairment gồm one-way/two-way loss, latency, jitter, reordering, duplication, bandwidth cap, path MTU giảm, ICMP blackhole và route flap. Failure gồm link down, remote endpoint process restart, tunnel source mất, một ECMP path hỏng và asymmetric return. Thay từng biến để tránh nhầm lỗi MTU với loss ngẫu nhiên.

Với outer IPv6, router trung gian không phân mảnh; hành vi của tunnel endpoint là nguồn outer packet cần được kiểm riêng cùng PMTUD. Keepalive thường dùng trao đổi khứ hồi và phụ thuộc implementation; thử chặn từng chiều để xác định tín hiệu phát hiện thực tế, không mặc định mỗi probe đo một chiều.

04

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

#

KPI steady state gồm offered load, throughput/goodput, packet loss, latency p50/p95/p99, jitter, out-of-order, fragment/reassembly và CPU. KPI recovery gồm detection time, route withdrawal, traffic restoration, loss window và session survival. Đo cả inner goodput và outer wire rate để thấy overhead thực.

Không dùng throughput outer làm goodput ứng dụng. Nếu packet được fragment rồi truyền thành công, vẫn phải báo fragment cost, CPU và loss sensitivity; “không mất gói” không đồng nghĩa thiết kế MTU tốt.

  • KPI: Encapsulation correctness · Cách đo: Inner/outer header mapping · Bằng chứng: Capture hai miền
  • KPI: MTU ceiling · Cách đo: Payload lớn nhất không lỗi · Bằng chứng: Sweep + ICMP/counter
  • KPI: Overhead · Cách đo: Outer bytes trừ inner bytes · Bằng chứng: Interface/generator stats
  • KPI: Failure detection · Cách đo: Fault đến state/route đổi · Bằng chứng: Log + timestamp
  • KPI: Service restoration · Cách đo: Fault đến transaction ổn định · Bằng chứng: Flow log + loss window
  • KPI: Reordering · Cách đo: Sequence đảo trong flow · Bằng chứng: Generator/PCAP
  • KPI: Session survival · Cách đo: Flow dài không reset ngoài SLO · Bằng chứng: Client/server log
05

Ma trận quyết định và failure mode

#

Keepalive chỉ có giá trị khi topology và chiều đo đại diện failure cần phát hiện. Một probe theo chiều A→B không chắc phát hiện B→A hỏng; route tracking cũng có thể theo dõi next-hop nhưng không kiểm tra service đích.

  • Kịch bản: Payload dưới MTU · Kỳ vọng: Forward đúng · Dấu hiệu fail: Loss/header sai
  • Kịch bản: Payload sát/vượt MTU · Kỳ vọng: Fragment hoặc ICMP đúng policy · Dấu hiệu fail: Silent blackhole
  • Kịch bản: ICMP bị chặn · Kỳ vọng: PLPMTUD/MSS hoặc fail rõ · Dấu hiệu fail: TCP treo dài
  • Kịch bản: Loss một chiều · Kỳ vọng: Detection theo thiết kế · Dấu hiệu fail: Tunnel vẫn hút traffic
  • Kịch bản: Remote restart · Kỳ vọng: State/route phục hồi trong SLO · Dấu hiệu fail: Stale route
  • Kịch bản: ECMP path hỏng · Kỳ vọng: Flow remap có giới hạn · Dấu hiệu fail: Polarization/loss kéo dài
  • Kịch bản: Reordering · Kỳ vọng: App chịu trong profile · Dấu hiệu fail: TCP collapse/UDP sequence lỗi
  • Kịch bản: GRE qua IPsec · Kỳ vọng: Overhead và state đúng · Dấu hiệu fail: Double-fragment/MTU sai
06

Test plan theo từng pha

#

Pha A xác nhận underlay reachability và native baseline. Pha B bật GRE, kiểm inner/outer mapping, DSCP/TTL và route. Pha C quét packet size quanh MTU, DF và ICMP; lặp với TCP/UDP và offload tắt/bật có ghi nhận. Pha D tăng flow/PPS/throughput để tìm bottleneck.

Pha E áp latency, jitter, loss và reordering theo từng mức; đo ứng dụng. Pha F ngắt một chiều, link, route, tunnel source, endpoint process và ECMP member. Pha G quan sát keepalive/BFD/route tracking, recovery và session state. Pha H thêm IPsec hoặc stack production đầy đủ, chạy regression và rollback.

Minh họa: Theo dõi lỗi đường truyền và phục hồi dịch vụ. Ảnh AI, không phải kết quả đo.
Minh họa: Theo dõi lỗi đường truyền và phục hồi dịch vụ. Ảnh AI, không phải kết quả đo.
07

Checklist nghiệm thu và runbook

#
  • Ghi đầy đủ inner/outer protocol, GRE option và security layer.
  • Tính overhead theo đúng stack, không dùng con số mặc định chung.
  • Chạy native baseline và GRE baseline cùng traffic profile.
  • Sweep payload quanh MTU; kiểm DF, ICMP và fragment.
  • Kiểm TCP MSS, UDP lớn và ứng dụng thực tế.
  • Đo inner goodput, outer wire rate, loss và CPU.
  • Chèn one-way failure, remote restart và route flap.
  • Kiểm keepalive/BFD/route tracking theo từng chiều.
  • Thử ECMP, asymmetry, loss, reordering và bandwidth cap.
  • Lưu capture inner/outer, config, counter, log và timeline.
08

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

#

GRE không cung cấp mã hóa, xác thực hay bảo vệ tính toàn vẹn bằng mật mã; checksum tùy chọn chỉ hỗ trợ phát hiện lỗi; nếu yêu cầu bảo mật, cần lớp bổ sung và test plan riêng. Hành vi keepalive, key/sequence option, offload, PMTUD và HA phụ thuộc triển khai. Không suy hitless failover từ một loại session hoặc một hướng traffic.

Kết quả lab chỉ đúng cho stack encapsulation, MTU, path, software và impairment profile đã chạy. Public cloud hoặc carrier underlay có thể hạn chế fragment/ICMP và thay đổi đường; cần đo end-to-end tại môi trường mục tiêu.

09

Khái niệm cần nhớ

#
  • GRE: Generic Routing Encapsulation cho payload mạng qua delivery protocol.
  • Inner/outer header: header payload và header vận chuyển sau encapsulation.
  • Tunnel overhead: byte bổ sung làm giảm payload MTU/goodput.
  • PMTUD: phát hiện MTU nhỏ nhất trên đường.
  • MSS clamping: điều chỉnh TCP MSS để tránh segment quá lớn.
  • One-way failure: lỗi chỉ ở một chiều truyền.
  • Reassembly: ghép các fragment tại đích phù hợp.
  • Service restoration: thời gian dịch vụ thực sự trở lại, không chỉ tunnel up.
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