Hej!
När jag kopplar in min macbook air via nätverkskabel direkt in i fiberkonverterarens port så verkar mitt naturliga MTU vara MTU 1480. Ska det inte vara MTU 1500 som standard?
Är det något fel på mitt Telenor Villafiber?
Körde detta i terminal för att hitta MTU:
ping -g 1430 -G 1500 -h 1 -D 8.8.8.8
Jag har fler GPU än du och ser mig själv som GPU fattig ändå
Säkert har det göra med att du inte ser IP och ICMP header.
Testa:
ping -D -s 1472 8.8.8.8 (OK)
och
ping -D -s 1473 8.8.8.8 (om failar så har du 1500 men din Mac räknar inte övriga)
Annars om det inte funkar så ändrar du config och overridar:
sudo ifconfig en0 mtu 1500
Inget av dem två första kommandona funkade, fick inget svar.
sudo ifconfig en0 mtu 1500 <- denna behövs väl inte? Har väl redan 1500.
Jag har fler GPU än du och ser mig själv som GPU fattig ändå
Jag hade problem med att komma åt Apple Appstore på macbooken när jag var uppkopplad via VPN router som hade WireGuard klient igång.
Upptäckte sen med hjälp av VPN-leverantören att sänker man MTU till 1420 på VPN routerns WireGuard klient så fungerade det bra.
Förklaringen var att:
Mitt naturliga MTU var 1480. 1480-60 = 1420. Så vi ställde in 1420 på VPN routern.
WireGuard är känsligare än t.ex OpenVPN eller än att köra helt utan VPN.
Förstod efter det hur viktigt det är i nätverk att MTU är inställt rätt.
Olika operativsystem hanterar payload på ICMP olika. När du anger storleken på "size" i MacOS specifikt, så inkluderar kommandot inte IP headers, men verkar som att det inkluderar ICMP headers som en del av "sizen" (så bakom kulisserna i kommandot så tar den din angivna size -8 bytes för att inkludera ICMP headers).
Här har vi ett fint exempel att jämföra med Windows 11
I ditt exempel så får du igenom 1480, vilket då bekräftar att size-kommandot inte inkluderar de 20 bytes för IP Headers.
I Windows 11 så tar det stopp vid 1472, vilket verkar vara för att size-kommandot inte inkluderar varken 20 bytes IP Headers eller 8 bytes ICMP header.
I Windows 11 som exempel, så inkluderas inte ICMP headers i samma kommando, medan MacOS verkar göra det:
ping 1.1.1.1 -l 1472 -f
Pinging 1.1.1.1 with 1472 bytes of data:
Reply from 1.1.1.1: bytes=1472 time=1ms TTL=55
ping 1.1.1.1 -l 1473 -f
Pinging 1.1.1.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
MacOS: size 1480 (payload med ICMP header inkluderat, IP Headers exkluderat)
Windows 11: size 1472 (payload utan ICMP header eller IP Headers inkluderat)
Detta är även sant för olika tillverkare inom nätverksvärlden, Cisco, Juniper, Huawei, Nokia/Alcatel etc. som alla gör olika både i config och ping-kommandot vad som inkluderas eller inte Dessutom diffar det mellan samma tillverkare i olika mjukvaruversioner. Great fun.
Blandar vi in Wireguard i mixen så försvinner lite mer bytes för krypteringen. Tror det är 32 bytes för det, och sedan tunnlade TCP-paket så är vi nere på ~1400 bytes för data.
Typ såhär, utgår ifrån 1500 bytes:
-20 bytes för IPv4 headers = 1480
-8 bytes för WireGuard UDP = 1472
-32 bytes för WireGuard headers = 1440
-20 bytes för tunnlade IPv4 headers = 1420
-20 bytes för tunnlade TCP headers = 1400
= 1400 bytes för data
Därför kan det vara en god idé att konfigurera "max-segment-size" när man jobbar med tunnlar och krypterad trafik för att sköta fragmentering innan trafiken går in i tunneln.
Cisco t.ex.:
"When a host (usually a PC) initiates a TCP session with a server, it negotiates the IP segment size by using the MSS option field in the TCP SYN packet. The value of the MSS field is determined by the MTU configuration on the host. The default MSS value for a PC is 1500 bytes.
Use the ip tcp adjust-mss command in interface configuration mode to specify the MSS value on the intermediate router of the SYN packets to avoid truncation.
ip tcp adjust-mss 1400"
Copyright © 1999–2025 Geeks AB. Allt innehåll tillhör Geeks AB.
Citering är tillåten om källan anges.
