Kiểm thử IPv6 PMTUD: phát hiện MTU black hole trong tunnel và hybrid cloud

Path MTU là MTU nhỏ nhất trên toàn đường đi. Theo RFC 8201, IPv6 PMTUD dựa vào ICMPv6 Packet Too Big (PTB): router không chuyển tiếp được gói sẽ loại bỏ gói, gửi PTB kèm MTU của next hop, sau đó nguồn giảm kích thước packet. Nếu PTB không tới nguồn, kết nối có thể hoàn tất handshake nhưng treo khi gửi dữ liệu lớn.

Ping mặc định thường nhỏ hơn ngưỡng, vì vậy vẫn thành công. Kiểm thử phải dùng nhiều kích thước, transport và ứng dụng. Với IPv6, router trung gian không phân mảnh packet theo cách IPv4 thường được hiểu; nguồn phải thích nghi hoặc sử dụng cơ chế packetization phù hợp.

Topology cơ sở gồm client IPv6, router/firewall/tunnel gateway, một segment có MTU thấp hơn và server IPv6. Đặt packet capture ở phía client, trước và sau bottleneck, cùng counter/log tại thiết bị tạo PTB. Nếu kiểm tra hybrid cloud, ghi rõ overlay: IPsec, GRE, VXLAN, Geneve, SD-WAN hoặc cloud transit.

Tạo ba đường: baseline MTU đồng nhất; đường có bottleneck hợp lệ và PTB được chuyển; đường black hole chặn PTB. Nếu có ECMP, bảo đảm flow đi qua path xác định hoặc thu capture từng nhánh. Route change có thể thay PMTU giữa phiên nên phải là test case riêng.

Ghi MTU của từng interface, overhead của encapsulation theo cấu hình thực, route, ECMP hash, firewall policy, ICMPv6 policy, TCP MSS, offload NIC, kernel và application version. Capture tại host có offload có thể hiển thị packet lớn hơn frame trên dây; cần phân biệt artefact capture với packet thực.

Không suy ra overhead bằng tên tunnel. Xác nhận bằng packet capture và cấu hình vì tùy chọn header, encryption và encapsulation có thể thay đổi kích thước.

• Biến: Payload IPv6 · Mức thử: 1.200; 1.280; 1.400; 1.500+ octet · Mục đích: tìm ngưỡng
• Biến: PTB · Mức thử: cho phép; drop; rate-limit · Mục đích: tái tạo black hole
• Biến: Transport · Mức thử: ICMPv6; TCP; UDP/QUIC · Mục đích: so hành vi
• Biến: Tunnel · Mức thử: không tunnel; IPsec/VXLAN theo thực tế · Mục đích: đo overhead
• Biến: Route · Mức thử: ổn định; đổi path giữa phiên · Mục đích: kiểm tra cache PMTU
• Biến: ECMP · Mức thử: một flow; nhiều flow key · Mục đích: phát hiện path khác MTU
• Biến: Thời gian · Mức thử: cold cache; warm cache; sau timeout · Mục đích: kiểm tra PMTU state

KPI mạng gồm kích thước packet lớn nhất đi qua, số PTB, MTU được báo trong PTB, packet loss, retransmission, time-to-recovery và PMTU/MSS quan sát được. KPI ứng dụng gồm connect time, time-to-first-byte, transaction success, throughput, timeout và retry.

Evidence tối thiểu: pcap hai phía, counter ICMPv6/firewall, route và interface MTU, log tunnel, kết quả lệnh probe theo kích thước, TCP trace và application log. Gắn cùng test ID và clock. Một PTB xuất hiện trong capture trung gian nhưng không tới host là bằng chứng về policy hoặc đường trả về, không phải lỗi server.

Với UDP, không có cơ chế retransmission như TCP; ứng dụng phải có phản hồi/probe riêng. RFC 8899 mô tả PLPMTUD cho datagram transport, dùng probe và phản hồi tại packetization layer thay vì phụ thuộc hoàn toàn vào ICMP.

• Baseline: MTU đồng nhất, PTB cho phép, payload nhỏ/lớn.
• Bottleneck hợp lệ: giảm MTU một segment; xác nhận PTB và nguồn điều chỉnh.
• PTB black hole: drop PTB; đo timeout/retransmission và ứng dụng treo.
• PTB rate limit: burst nhiều flow; kiểm tra recovery không đồng đều.
• Tunnel overhead: thêm encapsulation; so PMTU trước/sau.
• ECMP không đồng nhất: hai path MTU khác nhau; nhiều flow key.
• Route change: chuyển sang path MTU thấp hơn khi phiên đang chạy.
• PLPMTUD: ứng dụng/transport hỗ trợ probe tại packetization layer.
• Recovery: mở lại PTB hoặc sửa MTU; xác nhận phiên mới và phiên cũ.

Không thử chặn ICMPv6 tùy tiện trên production. Tạo điều kiện black hole trong lab hoặc maintenance window, có rollback rõ ràng.

• Lập bảng MTU vật lý và logic trên toàn path.
• Tắt hoặc ghi rõ offload tại điểm capture; xác nhận frame trên dây.
• Chạy baseline với packet nhỏ, sau đó tăng kích thước có kiểm soát.
• Thu PTB và xác minh địa chỉ, MTU field, gói gây lỗi được trích dẫn.
• Bật rule drop/rate-limit PTB trong môi trường lab có phê duyệt.
• Chạy TCP transfer, HTTPS/gRPC hoặc ứng dụng thật với payload vượt ngưỡng.
• Lặp với tunnel, ECMP và route change; mỗi lần chỉ đổi một biến.
• Khôi phục policy; kiểm tra counter, cache và transaction trở lại baseline.
• Lưu pcap, cấu hình, log và bảng pass/fail cùng test ID.

Nếu PTB tới host và packet sau đó nhỏ đi, PMTUD đang phản ứng; vẫn cần kiểm tra MTU trong PTB có hợp lệ và throughput phục hồi. Nếu PTB xuất hiện ở router nhưng không ở host, kiểm tra ACL, firewall, reverse path và rate limit. Nếu không có PTB ở router, xác nhận bottleneck thực sự và counter egress.

Nếu TCP retransmit packet lớn lặp lại nhưng ACK cho packet nhỏ vẫn xuất hiện, black hole là nghi vấn mạnh. Nếu QUIC/UDP phục hồi qua probe nhỏ hơn, cần xác nhận implementation dùng PLPMTUD và thời gian tìm ngưỡng. Không gắn mọi timeout payload lớn cho MTU: server limit, WAF, proxy buffer và application timeout cũng có biểu hiện gần giống.

PMTU cache có thể làm test sau chịu ảnh hưởng test trước. Chạy cold-cache và warm-cache riêng; ghi thời điểm route thay đổi và thời điểm nguồn bắt đầu probe lại.

Biện pháp đúng ưu tiên duy trì ICMPv6 PTB cần thiết, thống nhất MTU qua tunnel và sửa cấu hình endpoint. MSS clamping có thể giúp một số TCP path nhưng không giải quyết UDP/QUIC và không thay thế PMTUD đúng. Giảm MTU toàn mạng có thể che lỗi nhưng làm tăng overhead; cần đánh giá trước khi áp dụng.

Sau sửa, regression phải phủ packet size quanh ngưỡng, nhiều transport, hai chiều, ECMP và route change. Theo dõi PTB rate và transaction timeout trong vận hành để phát hiện drift cấu hình.

Kết quả chỉ áp dụng cho path, MTU, tunnel, route, kernel và ứng dụng đã thử. ECMP có thể đưa flow khác sang path khác. Capture tại một điểm không chứng minh packet đi toàn tuyến. PMTUD thành công với TCP không tự chứng minh QUIC hoặc ứng dụng UDP hoạt động đúng.

Không công bố “MTU tối ưu” nếu chưa gắn topology và overhead. Mục tiêu là path thích nghi đúng và ứng dụng giữ SLO, không phải cố đạt một con số MTU chung.