NETWORK EMULATION

Kiểm thử PMTUD và PLPMTUD: MTU blackhole, MSS và tunnel overhead

2/9/2026 · 16 phút

Luồng IPv4 và IPv6 đi qua tunnel có MTU thấp với ICMP Packet Too Big và probe PLPMTUD
Mục lục bài viết 10 phần

MTU blackhole thường chỉ lộ ra khi payload vượt một ngưỡng: kết nối mở được, ping nhỏ chạy, nhưng upload, TLS record hoặc gói trong tunnel bị treo. Nghiệm thu phải kiểm tra Path MTU Discovery (PMTUD), Packetization Layer PMTUD (PLPMTUD), ICMP Packet Too Big, TCP MSS và overhead theo topology thực.

ĐỌC NHANH

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

  • Bài toán PMTUD cần chứng minh
  • Topology và điều kiện đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Bài toán PMTUD cần chứng minh

#

RFC 1191 mô tả PMTUD cho IPv4 dựa trên cờ Don't Fragment và ICMP Destination Unreachable/Fragmentation Needed. RFC 8201 mô tả PMTUD cho IPv6, nơi router không phân mảnh transit packet và gửi ICMPv6 Packet Too Big (PTB). Lọc ICMP/PTB hoặc dịch MTU sai có thể tạo blackhole.

RFC 4821 và RFC 8899 mô tả PLPMTUD/DPLPMTUD: packetization layer chủ động probe và suy ra kích thước có thể dùng mà không phụ thuộc hoàn toàn vào ICMP. Support/hành vi phụ thuộc transport và implementation. TCP MSS chỉ giới hạn TCP segment payload được quảng bá, không giải quyết mọi UDP/QUIC/tunnel case.

02

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

#

Topology tối thiểu có client/server, router hoặc emulator đặt bottleneck MTU, firewall có thể allow/drop ICMP/PTB và tunnel endpoint tùy kịch bản. Tạo đường return khác đường forward để thử asymmetry. Capture hai phía bottleneck và endpoint; thu interface MTU, route/cache, ICMP counter, TCP state, retransmission và transaction log.

Chọn MTU rõ ràng, ví dụ access 1500 và đoạn/tunnel nhỏ hơn do overhead, nhưng không công bố con số kết quả nếu chưa đo đúng header stack. Tạo payload dưới, sát và trên ngưỡng; dùng application transfer/checksum, không chỉ ping. Đồng bộ clock và đặt marker cho policy/path/MTU change.

Minh họa: Topology kiểm thử PMTUD và MTU blackhole qua tunnel.
Minh họa: Topology kiểm thử PMTUD và MTU blackhole qua tunnel.
03

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

#

Ghi OS/kernel/transport version, IPv4/IPv6, interface/link MTU, route MTU, cached PMTU, DF behavior, ICMP policy/rate limit, TCP MSS, MSS clamping, offload và tunnel encapsulation. Với IPv6, ghi extension header trong scope; với QUIC/UDP, ghi library và DPLPMTUD support cụ thể.

Traffic profile gồm payload size sweep, frame/packet size, connection count, rate, burst, application protocol và direction. Header overhead cần tính theo stack thực: VLAN, PPPoE, GRE, IPsec, VXLAN hoặc cloud overlay. GRO/GSO/TSO có thể làm capture ở host khác wire image, nên điểm capture phải được ghi.

  • Path — Giá trị cần lưu: MTU từng hop, asymmetry, route; Sai lệch nếu bỏ sót: Không biết bottleneck thật
  • Control — Giá trị cần lưu: ICMP/PTB allow/drop/rate; Sai lệch nếu bỏ sót: Nhầm policy với endpoint lỗi
  • Endpoint — Giá trị cần lưu: cache, MSS, PLPMTUD support; Sai lệch nếu bỏ sót: Recovery khác theo stack
  • Tunnel — Giá trị cần lưu: header stack và overhead; Sai lệch nếu bỏ sót: Ước lượng payload sai
  • Traffic — Giá trị cần lưu: transport, payload, direction; Sai lệch nếu bỏ sót: Ping nhỏ che application stall
04

KPI và bằng chứng

#

KPI gồm discovery time, usable payload/packet size, transaction success, goodput, latency p95/p99, retransmission, probe count, blackhole duration và recovery sau path change. Đếm ICMP/PTB generated/received/accepted, nhưng không coi nhận PTB là pass nếu endpoint không điều chỉnh packetization.

Chuỗi bằng chứng cần nối oversized packet; PTB hoặc probe loss; endpoint PMTU/MSS state; packet size sau điều chỉnh; ACK/application completion. Với ICMP bị lọc, chứng minh PLPMTUD hoặc fallback phục hồi trong budget. Lưu pcap, route/cache, firewall log, emulator config và application hash/result theo run ID.

05

Ma trận quyết định

#
  • IPv4 DF, ICMP cho phép — Control signal: Frag Needed; Điều cần chứng minh: Giảm size và hoàn tất; Bằng chứng: ICMP + packet size
  • IPv4 ICMP bị lọc — Control signal: Không có; Điều cần chứng minh: PLPMTUD/fallback hoặc fail rõ; Bằng chứng: probe/retry + app
  • IPv6 PTB cho phép — Control signal: Packet Too Big; Điều cần chứng minh: Endpoint cập nhật PMTU; Bằng chứng: PTB + cache + traffic
  • PTB giả/không hợp lệ — Control signal: Có; Điều cần chứng minh: Validation, không hạ vô hạn; Bằng chứng: packet fields + state
  • TCP MSS clamp — Control signal: SYN option; Điều cần chứng minh: TCP đúng, không suy sang UDP; Bằng chứng: SYN + segment size
  • UDP/QUIC — Control signal: Probe tùy stack; Điều cần chứng minh: Không stall âm thầm; Bằng chứng: probe + transaction
  • Tunnel overhead đổi — Control signal: MTU giảm; Điều cần chứng minh: Tái discovery/recovery; Bằng chứng: encapsulated capture
  • Asymmetric path — Control signal: Signal theo return; Điều cần chứng minh: Hai hướng hoạt động đúng; Bằng chứng: capture hai hướng
06

Test plan MTU blackhole

#

Bắt đầu không tunnel, ICMP/PTB cho phép và sweep payload qua ngưỡng. Xác nhận control message chứa thông tin phù hợp, endpoint điều chỉnh packet size và transfer có checksum hoàn tất. Lặp cho IPv4/IPv6, TCP và transport ứng dụng nằm trong scope. Xóa/quan sát PMTU cache giữa lượt để tránh kết quả lượt trước che discovery.

Sau đó drop hoặc rate-limit ICMP/PTB có chủ đích, giữ mọi biến khác. Đo stall, retry, PLPMTUD probe và recovery. Bật tunnel từng lớp, tính overhead từ packet capture và lặp sweep. Với MSS clamping, kiểm tra SYN/SYN-ACK hai hướng, segment thực và ứng dụng; đừng dùng thành công TCP để kết luận UDP/QUIC pass.

Minh họa: Timeline PMTUD và PLPMTUD khi gặp MTU blackhole.
Minh họa: Timeline PMTUD và PLPMTUD khi gặp MTU blackhole.
07

Path change, recovery và scale

#

Giữa transfer, chuyển sang path có MTU thấp hơn hoặc thêm overhead tunnel; đo thời gian endpoint nhận biết và service restoration. Sau đó chuyển về path MTU lớn hơn để xem cache/probing có tăng size an toàn hay giữ mức thấp. Thử route flap và asymmetry để phát hiện state chỉ đúng một chiều.

Tăng connection/flow count và PTB rate để kiểm tra control-plane policing, firewall logging và endpoint CPU. ICMP rate limit cần bảo vệ hệ thống nhưng không được làm discovery thất bại ở tải hợp lệ. Thử PTB malformed/spoofed trong lab an toàn để xác minh validation theo stack, không suy diễn thành đánh giá bảo mật toàn diện.

08

Checklist nghiệm thu

#
  • Ghi MTU từng hop, route, tunnel header và hai chiều.
  • Ghi OS/kernel/library, PMTU cache và PLPMTUD support.
  • Baseline payload dưới/sát/trên ngưỡng bằng application transfer.
  • Capture trước/sau bottleneck và tại endpoint.
  • Thử IPv4 DF/ICMP Frag Needed và IPv6 PTB.
  • Thử ICMP allow, drop, rate-limit và signal sai.
  • Kiểm tra MSS trên SYN/SYN-ACK và segment thực.
  • Thử TCP cùng UDP/QUIC trong phạm vi support.
  • Gây path/tunnel overhead change giữa phiên.
  • Lưu pcap, cache/route, policy, checksum và verdict.
09

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

#

Kết quả phụ thuộc endpoint stack, transport, cache, firewall, tunnel và route đã đo. Ping với DF hữu ích để chẩn đoán nhưng không thay application traffic. MSS clamping có thể giảm một lớp triệu chứng TCP nhưng không thay thế quản lý MTU nhất quán.

Không công bố “Path MTU” nếu chỉ suy từ cấu hình interface hoặc một hướng. Offload và vị trí capture có thể làm packet trông lớn hơn wire packet. PLPMTUD support phải gắn với protocol/library/version; RFC tồn tại không đồng nghĩa mọi ứng dụng triển khai.

10

Khái niệm cần nhớ

#
  • Link MTU: Kích thước gói IP tối đa trên một link/interface theo cấu hình.
  • Path MTU: MTU nhỏ nhất trên đường đi liên quan.
  • PMTUD: Khám phá Path MTU dựa trên forwarding/control signals.
  • PLPMTUD/DPLPMTUD: Packetization layer dùng probe để tìm kích thước hoạt động.
  • ICMP Packet Too Big: Tín hiệu cho biết packet vượt MTU đường đi.
  • MSS: TCP Maximum Segment Size quảng bá khi bắt tay.
  • MTU blackhole: Gói lớn bị mất mà endpoint không điều chỉnh kịp/đú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ả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