A kis MTU jó, mert kisebb sávszélességnél az egyes kapcsolatok adatcsomagjai gyorsabban váltakoznak, így pl. egy fájl áttöltés packetei közé hamarabb be tudnak iktatódni az sshd adatcsomagja. Ezért aztán a ppp MTU-ja általában 576 bite körül szokott lenni de ez nem szentirás. A nagyobb MTU akkor jó, ha valami spec dolgot csinálunk. Az IPSEC pl. mindent kódolva küld át a neten és a kódolás 64 byte hosszú adatblokkokkal dolgozik. Az 1460 viszont valószínüleg nem 64 többszöröse, így nem lenne jó pont ekkora adatblokkot használni. Így pl. a Freeswan nevű tcpip megvalósítás szeret 16000 byte méretű MTU-t állítani az interface-ére, aztán az adatcsomagokat majd ő letördeli.
Honnan tudja a másik fél, hogy mekkora adatot küldjön? Pl. UDP esetén nincs kapcoslatfelvétel, így nem tudja lekérdezni, hogy mekkora adatokat küldjön. Ezt úgy kompenzálják, hogy kitalálták a Reverse Path MTU Detectiont. Igazából csak annyiról van szó, hogy ha túl nagy adatot küld valaki, akkor a túl adatot fogadni nem képes állomás ELŐTT álló router visszaszól a feladónak egy ICMP adatcsomagban, hogy "Hé haver kisebb adatblokkokat küldjél, XXX byte méretűt!". Amennyiben tudja, a router ezután a nagy adatcsomagot felvágja kisebbekre és leadja a célállomásnak, de ha az adatcsomagban benne van a DF bit (dont fragment - ne tördeld), akkor nem tud mit tenni és kidobja.
Mikor van gond? Akkor, amikor egy állomás nem tudja megkapni az icmp adatcsomagokat melyek a
kisebb adatcsomag küldésre szólítanak fel, mert mondjuk az előtte levő router kidobja ezeket
a csomagokat. Ilyen pl. a www.slashdot.org weboldal. Ha ráadásul DF bites csomagokat küldenek,
akkor a túlméretes adatcsomagok nem tudnak átjönni a hálózaton.
Természetesen a kicsi adatcsomagok ilyenkor is átjönnek. Ezért aztán pl. levél érkezésekor a
hibajelenség az, hogy az egyik szerver felveszi saját szerverünkkel a kapcsolatot, megbeszéli
a feladót és a vevőt, ám az adatok vételekor rögtön megáll az adatáramlás, és hosszabb
idő után timeout-ol a két gép, megszakítja a kapcsolatot.
POP3 letöltés esetében a hibajelenség általában az, hogy a szervert eléri, kiírja, hogy 55
új üzenet érkezett, majd az első-második után megáll.
Weblap letöltés esetén a
hibajelenség az, hogy a weblap elkezd megjelenni (pl. háttér letörlődik), de nincs tovább.
Természetesen az említett hibák akkor is előjönnek, ha a saját MTU-nk túl nagy, ekkor
segíthet annak lecsökkentése. Ennek mószerei: Linux alatt ifconfig paranccsal, freeswan
esetében az overridemtu opcióval, windows alatt DHCP szerver paraméterrel vagy registry kulcs
átírással.
Mi lehet az oka annak, hogy kisebb MTU kell? PPP esetén a hálózat paramétere miatt, speciális
hálózatnál (token busz, token ring, fddi), a csatolókártya miatt, vagy pl. ADSL esetén
speciális MTU-t használnak (1492 byte), ennek okát pontosan nem tudom. Hasonlóan VLAN-t
tartalmazó hálózatoknál a 802.1q trönkölt VLAN 4 byte-ot ragaszthat az ethernet csomag
végére. Így elképzelhető, hogy túlméretes lesz az ethernet keret, de ez nem okoz hibát
minden hálózati csatoló és berendezés esetében, mert van ami erre már fel van készülve.
Mindenesetre VLAN esetén elképzelhető, hogy az 1496 byte méretű MTU segít.
Oké, az MTU itt jó, csakhogy az ICMP-t a vevő nem fogadja, hogyan tovább? Lényeges pontja a kapcoslatoknak, hogy általában TCP-re épülnek, ilyen pl. a web, a pop3 vagy az smtp (mail) átvitel. Ezek a TCP adatfolyamok viszont külön kapcsolatfelépítést használnak, melynek első csomagjai (ún. SYN csomagok) tartalmaznak egy MSS paramétert. Ez a TCP adatcsomagok "MAXIMUM SEGMENT SIZE" paramétere. A két berendezés tehát megbeszéli a kapcsolat elején azt, hogy egyáltalán mekkora TCP adatcsomagokkal kísérletezzenek, ami meghatározza az IP adatcsomag méretét, (MTU) és természetesen ennek illeszkedni kell az ethernet vagy más hordozóréteg méretéhez. Jó esetben természetesen semmi gond, ha a TCP-ben az MSS mondjuk 15000, hiszen az ICMP reverse path MTU detection üzenete után úgyis lejebb veszik a méretet a küldő felek. Rossz esetben viszont ez nem járható út, így ekkor a korrekt TCP kapcsolatokhoz fontos lehet a megfelelő MSS beállítás a TCP fejlécben.
Mekkorára állítja az operációs rendszer az MSS-t? Általában egyszerűen fogja az MTU-t és levon belőle 40-et és ezt írja az MSS-be, így jár el pl. a windows, linux is. Ha viszont van egy megosztott ADSL-ünk etherneten keresztül. akkor a belső hálózatunkon az MTU valószínüleg 1500 byte a hálózati kártyák miatt, az ADSL-en viszont 1492 byte. A belső gépekről indított kapcsolatok így 1500 byte alapján 1460 byte-os MSS-t állítanak be, ami meg tudja ölni a kapcsolatot. Mi a megoldás? Vegyük le minden megosztott gépen az MTU-t 1492-re, így azok is jó MSS-t fognak kiadni. Használjunk proxy szervert, mert ilyenkor a proxy szerver fog tcp kapcsolatot nyitni. és állítsuk be a proxy szervert úgy, hogy az megfelelő MTU-MSS-t produkáljon.
Nagyon hasznos még az alábbi megoldás, ha valaki linux 2.4-es kernellel osztja meg adsl
kapcsolatát:
iptables -t nat -A POSTROUTING -o ppp0 -p tcp --tcp-flags SYN,RST\
SYN -m tcpmss --mss 1453: -j TCPMSS --set-mss 1452 -v
Ez a szabály azt mondja meg, hogy minden adatcsomag, mely a ppp0-ra menne ki és SYN vagy SYN,RST
flagekkel rendelkezik (TCP beállító üzenet), és mss-e nagyobb egyenlő, mint 1253, az legyen
átírva úgy , hogy az mss 1452 byte legyen.
Természetesen a 1453 legyen MTU-40+1 míg a --set-mss MTU-40 méretű.
Ha valaki kombinálja
a dolgokat, nyugodtan rakhatja persze lejjebb is az mss-t , mondjuk 1250 bytenál nagyobb mss
kérése esetén 1249 byte-ra, így aztán még nagyobb lesz az esélye, hogy jól müködik
számítógépbe, bár minél kisebb az mss annál kisebb a hatásfok (több 40 byte-os fejléc
elküldése szükséges az adatok között).
Megjegyzés az iptables megoldáshoz: A netfilter/iptables (pl. http://freshmeat.net/redir/iptables/4545/url_homepage/
vagy
http://freshmeat.net/redir/iptables/4545/url_bz2/iptables-1.2.2.tar.bz2
)
csomagból szükséges betölteni az iptables ,
a nat és a tcpmss ill TCPMSS modulokat (nem pont ez a nevük). Emellett szükség van az iptables
parancsra is, így ha valaki kézzel fordítja a kernelét , az vagy töltsön le egy iptables
csomagot is (jelenleg pl. debian unstable vagy testing változatából, mert a potato-ban
nincsen), vagy fordítson kézzel egy iptables-t.
Tapasztalatom szerint azonban a debianba épített ip tables egy libraryt hiányol a tcpmss
állítási parancsnál, mert valamiért az nincs hozzáfordítva, ezért célszerűbb lefordítani
egy új iptables parancsot. Ha minden igaz elég a netfilter csomag kicsomagolása, és egy make
install, de ne feledkezzünk meg a régi iptables csomag leszedéséről, különben az új
(/usr/local/sbin/iptables) a régi iptables lib-jeit próbálja majd használni, és persze az
/etc/ld.so.config-ba is be kell írni az /usr/local/lib alkönyvtárat (és egy ldconfig-ot kell
futtatni utána)
Remélem segítettem megérteni a probléma alapját, ha igen, dobj ide egy köszönő üzenetet! Elég csak annyi, hogy kösz, megoldottad a gondomat...
További linkek:
RASPPPOE mtu leírásai -
Vagy itt is ua.
Egy angol leírás ugyanerről
Microsoft TCP registry
kulcsok
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\netTrans\000n
MaxMTU = 16-bit integer
Data Type: String )
win2k:
"MTU
Setting MTU overrides the default MTU for the network interface it is
added to. Note that if EnablePMTUDiscovery is set to 1, TCP will use the
smaller value of this local MTU and the "Discovered" MTU of the
underlying network connection. If you'd rather use only the MTU value
specified here, you'd have to disable PMTUDiscovery, which would prevent
your system from detecting the network MTU.
HKLM\SYSTEM\CurrentControlSet\Services
\Tcpip\Parameters\Interfaces\
MTU="1500" (DWORD, valid range is from 68 to
http://tweakhomepc.virtualave.net/download/mtuspeed308.exe
- lehet, hogy ezzel egyszerűbb a beállítgatás
Mirror (helyi)