Newsgroup: it.comp.reti.ip-admin
Titolo: Re: MTU

 e perche' la connessione al mailserver non funziona con mtu 1500?
Perché uno dei router lungo il percorso è configurato male.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 grazie
i motivi possono essere davvero molteplici.
l'MTU, *banalizzando*, è la dimensione massima di un pacchetto prima che 
esso venga frammentato.
poniamo il caso, però, che:
- le tue macchine stiano inviando dei pacchetti conformi che, durante il 
tragitto, subiscono un piccolo gonfiamento che porta il pacchetto in 
overhead ad un totale di 1550 (stai, ad esempio, attraversando una VPN 
che inserisce delle informazioni aggiuntive nell'header, o un IDS troppo 
invadente scrive delle informazioni, etc. etc.)
OPPURE
- tu esci con 1500 esatti ma un router sul percorso è configurato in 
modo tale da frammentare a 1496 o a 1450 etc.
in questi casi il pacchetto viene ulteriormente frammentato, alcune 
riframmentazioni causano:
- rallentamenti estremi (non riesci a lavorare ma solo saltuariamente 
cade una sessione, non viene identificato immediatamente come "problema" 
perchè, nonostante sia particolarmente lento, sembra "funzionare" anche 
se molto male)
- inutilizzo di alcune applicazioni (il protocollo VNC, ad esempio, 
diventa non utilizzabile)
morale della favola: di già alla tua macchina di uscire con 1400 e vivi 
felice.
perdonate le banalizzazioni, c'è da parlare per giorni sull'argomento, 
ma ho volontariamente semplificato ai minimi termini!! non mi massacrate! :)

 ma ho volontariamente semplificato ai minimi termini!! non mi massacrate!
Semplificare va bene, ma hai detto cose non corrette e non hai detto qual è 
la vera origine del problema.
L'MTU è la dimensione massima dei pacchetti inviabili da un'interfaccia IP. 
Pacchetti più grossi andrebbero frammentati dal router ma è ormai prassi 
consolidata quella di gestire la dimensione dei pacchetti tra gli host.
Internet è fatta da una moltitudine di tecnologie ognuna delle quali ha 
interfacce con MTU diversa.
Ethernet, da standard, ha una MTU di 1500 ottetti e siccome grossi pezzi di 
Internet sono fatti con Ethernet l'MTU di 1500 è un numero che si ripete 
spesso.
Possono esistere lungo il percorso interfacce che, per fari motivi, hanno un 
MTU minore di 1500 ottetti.
Supponi ora di aprire una connessione TCP e di voler mandare uno stream con 
molti dati.
Il TCP preparerà un pacchetto della dimensione della MTU dell'interfaccia da 
cui vuoi trasmetterlo. Essendo probabilmente ethernet lo preparerà da 1500 
ottetti e lo invierà.
Il pacchetto farà il suo bel percorso fino ad arrivare al router che ha 
un'interfaccia, mettiamo da 1480 ottetti.
Essendo di norma pacchetti TCP non frammentabili il router non potrà mandare 
il pacchetto e dovrà scartarlo.
Scartandolo manda indietro un ICMP "Fragmentation needed and DF set" e in 
questo pacchetto scriverà qual è la dimensione dell'MTU dell'interfaccia che 
ha causato lo scarto.
Il mittente riceve questo ICMP e si accorge del collo di bottiglia, da quel 
momento inizierà a trasmettere pacchetti TCP da 1480.
La cosa ovviamente si ripete se più avanti c'è un'ulteriore strozzatura.
Questo meccanismo si chiama PMTUD (Path-MTU-Discovery).
Quello che talvolta succede è che amministratori di rete troppo zelanti e 
ignoranti filtrano tutti gli ICMP inbound o outbound per salcazzo quale 
motivo e così si perdono i messaggi di errore "Fragmentation needed".
Ecco che il TCP continuerà imperterrito a trasmettere e ritrasmettere 
pacchetti da 1500 e il ricevente non ne vedrà manco uno.
Il problema si manifesta in maniera subdola perché fintanto che i pacchetti 
scambiati sono < 1480 tutto funziona alla grande.
Se sono richieste HTTP per pagine piccole funzionano bene, se sono dei check 
mail con casella vuota, pure. Appena c'è da scaricare qualcosa di più grosso 
SBAM, si blocca fino al timeout.
Quindi il nostro "Sanchioni" devi capire perché ALLA macchina di posta che 
lui contatta non arrivano questi ICMP. Di solito è colpa di chi la gestisce, 
ma talvolta è più subdolo.
Ridurre il proprio MTU può essere un palliativo temporaneo ma se il 
MECCANISMO non funziona il problema c'è e si farà vedere di nuovo.
Ciao,
-- 
  Daniele Orlandi					つづく

 motivo e così si perdono i messaggi di errore "Fragmentation needed".
touchè.

 MTU minore di 1500 ottetti.
Q-in-Q.... m'ha fatto bestemmiare per alcune ore...


 Q-in-Q.... m'ha fatto bestemmiare per alcune ore...
MPLS anyone? :^/
O anche dei semplici tunnel...
-- 
  Daniele Orlandi					つづく


spesso però non puoi fare altrimenti perchè il problema non deriva dai 
tuoi sistemi gestibili, ma da qualcosa che gerarchicamente sta oltre la 
tua rete.
certo, è una soluzione non molto serena, parziale, ciò che vuoi, ma è 
una soluzione.
ciao!

 una soluzione.
Quel che giustamente dice Daniele è che non è una soluzione ma un workaround.
La soluzione è chiedere a chi ti gestisce i sistemi di configurarli
correttamente.



ma certo, ed io sono daccordissimo con daniele che, tra l'altro, stimo 
profondamente.
solo che a volte ciò non è semplicemente possibile (per mille motivi). e 
bisogna ricorrere a soluzioni di indubbio cattivo gusto, ma che almeno 
ci mettono una pezza :)
ciao!

 tuoi sistemi gestibili
Chiaro che se non hai controllo sul sistema remoto ridurre va bene come 
workaround temporaneo, ma perché devi essere tu a inficiare le prestazioni 
della tua rete per fare un favore a qualcuno che non sa come configurare i 
propri sistemi?


 ridotta a 1500.
Dimensione di un Jumbo Frame! ricordo bene?

 Dimensione di un Jumbo Frame! ricordo bene?
AFAIR, si.
Mi domando che caspita ci si faccia con i jumbo frames
a casa....

 ha scritto
nel messaggio news:1286900635.1874.34.camel@ale-netbook

Una volta che hai tutto il ferro che serve per gestirli, perché non 
abilitarli?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 


Per esempio trasferire i files da e per la NAS in modo ottimale.


 Per esempio trasferire i files da e per la NAS in modo ottimale.
Boh, io non ne ho mai sentito la mancanza.
Ma ammetto di trasferire pochi file di grosse dimensioni....

 Dimensione di un Jumbo Frame! ricordo bene?
Tecnicamente Jumbo è tutto quello che è superiore ai 1518 stabiliti 
dall'IEEE 802. Se sono pochi ottetti in più si parla di baby jumbo.
9000 è una convenzione che è uscita dalle raccomandazioni di Internet2 ma 
non è stato mai standardizzato.
Ci sono apparati che supportano 1526, altri 7200, altri 9000, altri di più, 


Gandalf Corvotempesta wrote:

ValeRyo e The_ZiPMan hanno indovinato entrambi i motivi:
1- NAS 
2- "perché no?" :)
Il vantaggio col NAS e SAN non è trascurabile, certo non in ambiente 
casalingo, ma in altri casi significa:
- ridurre i PPS che passano per lo switch
- ridurre gli IRQ e il processing su entrambi i sistemi
- diminure l'overhead
- Nel caso particolare delle SAN significa poter traportare un intero blocco 
in un pacchetto senza dover frammentare.


 casalingo, ma in altri casi significa:
Concordo, ma te stavi parlando di ambiente casalingo, ecco il perchè
mi son meravigliato. Io personalmente a casa non ne ho mai sentito
il bisogno, tutto qui.
Per quel che devo fare vivo bene con il mio switch netgear
da 30 euro. (che non supporta i jumbo, ovviamente)

 primi 9k di una connessione non rompe un p0' le balle? 
L'overhead è solo l'intestazione Ethernet+IP+TCP (ed eventualmente il trailer)


 1- NAS -> casa
aaaah, maledetti pornazzi da 2Gb!! sono sempre un casino da trasferire 
da proprio pc al nas!!
ahahah
LOL :)

 da proprio pc al nas!!
E pensa ai porno rippati dai BD! (esistono i BD porno?)


 E pensa ai porno rippati dai BD! (esistono i BD porno?)
Esistono?!?!?!?! Sono stati il motivo principale della vittoria di BD
rispetto a DVD-HD.


 rispetto a DVD-HD.
Non ne avevo idea... anzi, ricordavo una mezza affermazione di Sony
"never porn on blu-ray".


 primi 9k di una connessione non rompe un p0' le balle?
Il sistema operativo si tiene una routing cache nella quale si ricorda per 
ogni destinazione l'MTU del percorso per un lungo tempo, quindi l'overhead è 
solo per il primo pacchetto verso una destinazione.
Comunque l'obiezione è sensata, colgo l'occasione per fare un paio di conti.
Linux tiene traccia del tipo ICMP ma non del codice, comunque dopo 4 giorni 
di uptime di 61 milioni di pacchetti ricevuti ho 60000 ICMP tipo 3 
(Destination Unreachable), anche facendo finta che siano tutti Fragmentation 
Received sono comunque uno su mille, direi che è un problema minore.
Soprattutto quando il NAS ha mandato i suoi bei 2.5 Gpkt :)



naaa, da sempre il porno ha portato innovazione. persino il VHS ï¿œ stato 
fatto appositamente per l'industria del porno e poi esportato (come 
supporto tecnologico) a tutti gli altri film!
:)

 (come supporto tecnologico) a tutti gli altri film!
Trovato:
  Sony Corp. said it will not work with the adult film industry to help put 
their movies on its Blu-ray Disc format, although it will not try to stop 
them completely.
  The company will not allow its disc replicating subsidiary, Sony DADC, to 
handle adult film titles, it said this week.
http://www.lifespy.com/2007/has-sony-killed-blu-ray-with-no-porn-policy/


 Non concordo oppure non capisco come funzioni il TCP.
Misunderstanding mio. Io parlavo dell'overhead generico che si risparmia
usando Jumbo frame.


 
http://www.xbiznewswire.com/view.php?id=125714
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 
Avevo letto che a breve alcuni benemeriti avrebbero fatto il primo bd 3d 
porno.
Certo che avere un simil rocco che gira nudo per la casa � inquietante


 ha scritto nel
messaggio news:i9rlgd$13v7$
2...@newsreader1.mclink.it
 > 
http://www.xbiznewswire.com/view.php?id=125714
Vabb�, ognuno si diverte come pu� :-)
