Ok, właśnie skończyłem rozwiązywanie problemu z ramkami typu jumbo między kilkoma Xserves, Netgear GSM7224 i Drobo B800i. Okazało się, że Xserves (Mac OS X 10.6.8 Server) i Drobo B800i akceptują MTU w bajtach, jak zwykle oczekiwano (1500-9000), ale wydaje się, że Netgear chciał go, włączając różne nagłówki / stopki Ethernet (zwiastuny) ) i ostatecznie skończyłem na Xserves & Drobo skonfigurowanym z MTU 9000 i portami Netgear ustawionymi na MTU 9216.
Użyłem następujących poleceń do testowania i weryfikacji MTU między dwoma Xservami w Netgear (Uwaga: są to polecenia Mac OS X, różnią się Windows i Linux):
ping -D -s <mtu> <ip_address>
traceroute -F <ip_address> <mtu>
Użycie formy zostało odnotowane na man
stronie jako „Określ liczbę bajtów danych, które mają zostać wysłane. Wartość domyślna to 56, co przekłada się na 64 bajty danych ICMP w połączeniu z 8 bajtami danych nagłówka ICMP”. Podczas testów stwierdziłem, że jest ping -D 1472 <ip_address>
to odpowiednik MTU 1500 ze względu na 8 bajtów danych nagłówka ICMP plus 20 bajtów nagłówków IP (zobacz to i to ). To wszystko ma sens.
Dlaczego jest to równoważne polecenie dla 9000 MTU ping -D -s 8164 <ip_address>
? Sprawdziłem, czy jest to limit, zanim pojawią się błędy „sendto: Wiadomość za długa”, ale także to, że 9000 MTU działa poprawnie, ponieważ traceroute -F <ip_address> 9000
działa i traceroute -F <ip_address> 9001
nie działa. Dlaczego więc 8164? Spodziewałbym się 8972 (MTU - 28 bajtów, tak jak dla 1500 MTU).
Ponadto, dlaczego 9216 MTU dla Netgear? Policzyłem 42 bajty dla nagłówków MAC i ethernetowych (włącznie z CRC), plus 20 dla nagłówków IP (które powinny zjeść w MTU).
Jestem naprawdę zardzewiały w tej matematyce i wiem, że po prostu czegoś brakuje.