Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ping con pacchetti da 1100-1200...byte

1,461 views
Skip to first unread message

pierino

unread,
Jul 16, 2015, 12:01:00 PM7/16/15
to
Ciao,
Ho avuto un problema di connessione e mi hanno fatto fare un test
lanciando questi comandi :

ping xxx.xxx.xxx.xxx -f -l 1100

ping xxx.xxx.xxx.xxx -f -l 1200

ping xxx.xxx.xxx.xxx -f -l 1300

ping xxx.xxx.xxx.xxx -f -l 1400

Con il primo ed il secondo pacchetto rispondeva con il 1300 e 1400 no.

Cosa indicano questi valori in byte ? Che limite intendono ?

Grazie

ObiWan

unread,
Jul 16, 2015, 12:13:15 PM7/16/15
to
:: On Thu, 16 Jul 2015 18:00:59 +0200
:: (it.comp.reti.locali)
:: <mo8kd3$1sb$1...@dont-email.me>
:: pierino <pie...@pierino.it> wrote:

> Cosa indicano questi valori in byte ? Che limite intendono ?

https://it.wikipedia.org/wiki/Maximum_Transmission_Unit



ObiWan

unread,
Jul 16, 2015, 12:15:51 PM7/16/15
to
:: On Thu, 16 Jul 2015 18:13:14 +0200
:: (it.comp.reti.locali)
:: <20150716181...@eternal-september.org>
vedi anche

http://www.tp-link.us/FAQ-190.html



pierino

unread,
Jul 16, 2015, 12:19:34 PM7/16/15
to
...
>
> https://it.wikipedia.org/wiki/Maximum_Transmission_Unit

Grazie, molto esaustivo.

Visto che trattasi di un ponte radio in test pensi che sia colpa delle
apparecchiature utilizzate poco performanti ?

ObiWan

unread,
Jul 16, 2015, 12:20:49 PM7/16/15
to
:: On Thu, 16 Jul 2015 18:19:32 +0200
:: (it.comp.reti.locali)
:: <mo8lfs$63r$1...@dont-email.me>
vedi l'altro post o prova questo tool

http://www.elifulkerson.com/projects/mturoute.php


acc

unread,
Jul 16, 2015, 12:32:54 PM7/16/15
to
Il 16/07/2015 18.19, pierino ha scritto:

> Visto che trattasi di un ponte radio in test pensi che sia colpa delle
> apparecchiature utilizzate poco performanti ?

No, si tratta solo di un'impostazione che il provider sceglie in base
alle sue esigenze. Per te non fa praticamente differenza.

pierino

unread,
Jul 16, 2015, 12:52:57 PM7/16/15
to
...
>
> No, si tratta solo di un'impostazione che il provider sceglie in base alle
> sue esigenze. Per te non fa praticamente differenza.

In realta' e' un ponte radio punto-punto che collega 2 sedi, quali
potrebbero essere le esigenze dell' eventuale limitazione ? Non sarebbe
meglio che fosse abilitato di default per far passare il pacchetto
massimo ?

Grazie

acc

unread,
Jul 16, 2015, 3:24:49 PM7/16/15
to
Il 16/07/2015 18.52, pierino ha scritto:

> Non sarebbe
> meglio che fosse abilitato di default per far passare il pacchetto
> massimo ?

Un pacchetto piccolo comporta piu' frammentazioni, quindi un leggero
spreco di banda, ma puo' migliorare la stabilita' (meno errori) e
ridurre la latenza.

pierino

unread,
Jul 17, 2015, 5:21:08 AM7/17/15
to
..
>
> Un pacchetto piccolo comporta piu' frammentazioni, quindi un leggero spreco
> di banda, ma puo' migliorare la stabilita' (meno errori) e ridurre la
> latenza.

Scusa non ho capito: un pacchetto piccolo comporta piu' frammentazioni?
Non dovrebbe comportarne meno ?

Grazie

acc

unread,
Jul 17, 2015, 5:56:57 AM7/17/15
to
Il 17/07/2015 11.21, pierino ha scritto:

> Scusa non ho capito: un pacchetto piccolo comporta piu' frammentazioni?
> Non dovrebbe comportarne meno ?

Per pacchetto intendevo la dimensione dell'MTU, piu' e' piccola piu'
frammentazioni ci saranno. Ma e' un discorso che va preso con cautela,
cioe' non pensare al "caso peggiore" dove le differenze sono evidenti,
ma si verifica raramente, in realta' le differenze sono contenute.

pierino

unread,
Jul 19, 2015, 5:05:17 AM7/19/15
to
...
> Per pacchetto intendevo la dimensione dell'MTU, piu' e' piccola piu'
> frammentazioni ci saranno. Ma e' un discorso che va preso con cautela, cioe'
> non pensare al "caso peggiore" dove le differenze sono evidenti, ma si
> verifica raramente, in realta' le differenze sono contenute.

Ok, sto cercando di capire come si usa mtroute, ho trovato un articolo:

http://www.andreabeggi.net/2008/01/16/mtu-cose-e-come-funziona/

ma qui dice ( ambiente Linux ):

Controlliamo che un host esterno risponda al ping:
root@ginger:~# ping www.google.com -c3
PING www.l.google.com (216.239.59.147) 56(84) bytes of data.

pacchetto= 56 byte
IP Header ( intestazione ) = 20 byte
ICMP_REQUEST = 8 byte

Ma il mio comando ( ambiente Windows ):

C:\MTU>ping 192.168.XXX.XXX -c3

mi dice:

Fornire valore per l'opzione -c3.

Se provo senza :

C:\MTU>ping 192.168.XXX.XXX

Risponde:

Risposta da 192.168.XXX.XXX: byte=32 durata=29ms TTL=126

Quindi con un pacchetto da 32 byte.

Dove sbaglio ?

Grazie

pierino

unread,
Jul 19, 2015, 6:07:54 AM7/19/15
to
Sono adanto avanti con mturoute :

C:\MTU>mturoute 192.168.XX.29
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes is too big.
Path MTU: 1500 bytes.

Quanto sopra vuol dire che il pacchetto da 1472 bytes + 20 di Ip Header
+ 8 di ICMP_REQUEST = 1500 bytes e' passato e, quindi, sono al massimo
( 1500 byte ) di trasferimento ? )

Se provo con -t x vedere ogni hop :

C:\MTU>mturoute -t 192.168.XX.29
mturoute to 192.168.XX.29, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
1 +- host: 192.168.XX.247 max: 1500 bytes
2 -...- host: 82.XXX.XX.174 not responding
3 +- host: 192.168.XX.29 max: 1500 bytes

C:\MTU>

L' hos 192.168.XX.247 e' il mio firewall.

cosa vuol dire? Il pacchetto passa ma l' IP Pubblico che sto
raggiungendo non risponde ? Non risponde per qualche tipo di settaggio
ma permette il transito dei 1500 bytes ?

Cosa significa: Maximum payload is 10000 bytes ?

Provo permettendo la frammentazione ( parametro -f ):

C:\MTU>mturoute -t -f 192.168.XX.29
mturoute to 192.168.XX.29, 30 hops max, variable sized packets
* ICMP Fragmentation is permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
1 ++++++++++-+-+- host: 192.168.XX.247 max: 10000 bytes
2 ...-.- host: 82.XXX.XX.174 not responding
3 +- host: 192.168.XX.29 max: 10000 bytes

C:\MTU>

L' unica differenza che vedo con la frammentazione permessa :

1 +- host: 192.168.XX.247 max: 1500 bytes

e

1 ++++++++++-+-+- host: 192.168.XX.247 max: 10000 bytes

Ci sono dei + e- aggiuntivi

Cosa significa ?

Poi, al termine: max: 10000 bytes al posto di max: 1500 bytes

significa che il pacchetto inviato e' superiore ai 1500 byte e, quindi,
deve essere frammentato ?

Grazie

acc

unread,
Jul 19, 2015, 9:33:32 AM7/19/15
to
Il 19/07/2015 12.07, pierino ha scritto:
> Sono adanto avanti con mturoute :
>
> C:\MTU>mturoute 192.168.XX.29
> * ICMP Fragmentation is not permitted. *
> * Speed optimization is enabled. *
> * Maximum payload is 10000 bytes. *
> + ICMP payload of 1472 bytes succeeded.
> - ICMP payload of 1473 bytes is too big.
> Path MTU: 1500 bytes.
>
> Quanto sopra vuol dire che il pacchetto da 1472 bytes + 20 di Ip Header
> + 8 di ICMP_REQUEST = 1500 bytes e' passato e, quindi, sono al massimo (
> 1500 byte ) di trasferimento ? )

penso di si, non conosco mtroute ma credo sia un test analogo

> Se provo con -t x vedere ogni hop :
>
> C:\MTU>mturoute -t 192.168.XX.29
> mturoute to 192.168.XX.29, 30 hops max, variable sized packets
> * ICMP Fragmentation is not permitted. *
> * Speed optimization is enabled. *
> * Maximum payload is 10000 bytes. *
> 1 +- host: 192.168.XX.247 max: 1500 bytes
> 2 -...- host: 82.XXX.XX.174 not responding
> 3 +- host: 192.168.XX.29 max: 1500 bytes
>
> C:\MTU>
>
> L' hos 192.168.XX.247 e' il mio firewall.
>
> cosa vuol dire? Il pacchetto passa ma l' IP Pubblico che sto
> raggiungendo non risponde ? Non risponde per qualche tipo di settaggio
> ma permette il transito dei 1500 bytes ?

Forse il frame passa solo fino ad un certo punto, ma a te questo non
dovrebbe interessare perche' che tu puoi controllarne solo la dimensione
della *tua* tratta, delle altre dovresti fregartene, tanto non ci puoi
fare nulla.

> significa che il pacchetto inviato e' superiore ai 1500 byte e, quindi,
> deve essere frammentato ?

La frammentazione c'e' sempre e comporta un *leggerissimo* (quasi
insignificante) calo di prestazioni. In ogni caso questa e' la
normalita'. Non ho capito cosa ti preoccupa.
Allargare l'MTU serve solo ad ottimizzare i grossi trasferimenti
nell'ambito della propria LAN, ma per avere dei risultati rilevanti
dovresti almeno triplicarlo. Nelle comunicazioni remote invece, qualche
byte in piu' o in meno non fa differenza.

pierino

unread,
Jul 19, 2015, 11:58:18 AM7/19/15
to
..
>> Se provo con -t x vedere ogni hop :
>>
>> C:\MTU>mturoute -t 192.168.XX.29
>> mturoute to 192.168.XX.29, 30 hops max, variable sized packets
>> * ICMP Fragmentation is not permitted. *
>> * Speed optimization is enabled. *
>> * Maximum payload is 10000 bytes. *
>> 1 +- host: 192.168.XX.247 max: 1500 bytes
>> 2 -...- host: 82.XXX.XX.174 not responding
>> 3 +- host: 192.168.XX.29 max: 1500 bytes
>>
>> C:\MTU>
>>
>> L' hos 192.168.XX.247 e' il mio firewall.
>>
>> cosa vuol dire? Il pacchetto passa ma l' IP Pubblico che sto
>> raggiungendo non risponde ? Non risponde per qualche tipo di settaggio
>> ma permette il transito dei 1500 bytes ?
>
> Forse il frame passa solo fino ad un certo punto, ma a te questo non dovrebbe
> interessare perche' che tu puoi controllarne solo la dimensione della *tua*
> tratta, delle altre dovresti fregartene, tanto non ci puoi fare nulla.
>

Hum, non ho capito, come passa il frame fino ad un certo punto? Il mio
pc remoto 192.168.XX.29 lo raggiunge, giusto?
Quello che non capisco e' la riga :

host: 82.XXX.XX.174 not responding

Che rigarda l' IP pubblico dell' host remoto

Cosa vuol dire, arriva, passa ma l' apparato non risponde perche'
disabilitato ai ping ? Infatti, se provo a pingarlo mi ritorna:

Richiesta scaduta.

E' un ponte radio punto-punto, sto guardando la mia tratta...

>> significa che il pacchetto inviato e' superiore ai 1500 byte e, quindi,
>> deve essere frammentato ?
>
> La frammentazione c'e' sempre e comporta un *leggerissimo* (quasi
> insignificante) calo di prestazioni. In ogni caso questa e' la normalita'.
> Non ho capito cosa ti preoccupa.

Mi preoccupa il fatto che spesso non riesco a collegarmi in Terminal
Server ( Desktop Remoto ) all' host 192.168.XX.29.
Mi dicono che e' colpa dell' MTU.
Infatti, dai test che ho fatto, se l' MTU scende sotto i 1200 byte il
remoto pinga ma non riesco a collegarmi in Termina Server.

> Allargare l'MTU serve solo ad ottimizzare i grossi trasferimenti nell'ambito
> della propria LAN, ma per avere dei risultati rilevanti dovresti almeno
> triplicarlo. Nelle comunicazioni remote invece, qualche byte in piu' o in
> meno non fa differenza.

Anche qui non ho capito, la la MTU non vuol dire: Max Transfer Unit e
non ha un valore massimo di 1.500 byte per reti ethernet ?

Cmq quello che vorrei e' riuscire a tracciare il percorso del mio
pacchetto e capire *dove* non transita un determinato valore di MTU in
modo da capire quale sia l' apparato che limita il mio collegamento

Dove sbaglio ?

Grazie

acc

unread,
Jul 19, 2015, 1:24:47 PM7/19/15
to
Il 19/07/2015 17.58, pierino ha scritto:

> Hum, non ho capito, come passa il frame fino ad un certo punto? Il mio
> pc remoto 192.168.XX.29 lo raggiunge, giusto?
> Quello che non capisco e' la riga :
>
> host: 82.XXX.XX.174 not responding
>
> Che rigarda l' IP pubblico dell' host remoto
>
> Cosa vuol dire, arriva, passa ma l' apparato non risponde perche'
> disabilitato ai ping ? Infatti, se provo a pingarlo mi ritorna:
>
> Richiesta scaduta.

Quello che tu stai effettuando e' un test che serve a scoprire la
dimensione massima della MTU di una tratta.
Il test utilizza un flag che impedisce la frammentazione del pacchetto,
in pratica se il pacchetto non e' abbastanza piccolo non verra'
trasmesso, ovviamente in questo caso non avrai alcuna risposta.

Ma tutto questo riguarda soltanto il test, invece nel normale utilizzo
il flag che evita la frammentazione e' disabilitato, i pacchetti
verranno sempre spediti (se sono troppo lunghi verranno frammentati) e
avrai le risposte.

> Mi preoccupa il fatto che spesso non riesco a collegarmi in Terminal
> Server ( Desktop Remoto ) all' host 192.168.XX.29.
> Mi dicono che e' colpa dell' MTU.

Non credo, se hai l'MTU impostato male al massimo avrai un degrado delle
prestazioni, ma deve funzionare.
Piuttosto controlla l'indirizzo, non conosco la tua rete ma
192.168.qualcosa e' un indirizzo locale.

> Anche qui non ho capito, la la MTU non vuol dire: Max Transfer Unit e
> non ha un valore massimo di 1.500 byte per reti ethernet ?

Vuol solo dire che tutto quello che stai trasmettendo verra' diviso in
pacchetti di 1500 byte al massimo, se ad esempio stai inviando un file
di 10kb (10240 byte), verra' diviso in 7 pacchetti, di cui 6 di 1500
byte e uno di quel che rimane (1240 byte).
Se invece imposti l'MTU a 1200, i pacchetti saranno di piu' (9 in
totale) e dato che ogni pacchetto ha un header ci sara' un po' piu' di
overhead, cioe' la trasmissione durera' un po' (molto poco) di piu'.

> Cmq quello che vorrei e' riuscire a tracciare il percorso del mio
> pacchetto e capire *dove* non transita un determinato valore di MTU in
> modo da capire quale sia l' apparato che limita il mio collegamento
>
> Dove sbaglio ?

Di solito su usa regolare il valore dell'MTU in base al tipo di
connessione, in modo da ottimizzare il collegamento col proprio
provider, ma tieni ben presente che si tratta solo di un'ottimizzazione,
non e' indispensabile per il funzionamento.
A quello che avviene da li' in poi non dovresti far caso, puo' darsi che
ci siano tratte con MTU piu' piccola o piu' grande, non importa.

pierino

unread,
Jul 19, 2015, 1:36:00 PM7/19/15
to
..
>
> Quello che tu stai effettuando e' un test che serve a scoprire la dimensione
> massima della MTU di una tratta.
> Il test utilizza un flag che impedisce la frammentazione del pacchetto, in
> pratica se il pacchetto non e' abbastanza piccolo non verra' trasmesso,
> ovviamente in questo caso non avrai alcuna risposta.

Ok, bene, quindi :

C:\MTU>mturoute 192.168.XX.29
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
+ ICMP payload of 1472 bytes succeeded.
- ICMP payload of 1473 bytes is too big.
Path MTU: 1500 bytes.

Quanto sopra vuol dire che il pacchetto da 1472 bytes + 20 di Ip Header
+ 8 di ICMP_REQUEST = 1500 bytes e' passato e, quindi, sono al massimo
( 1500 byte di trasferimento )
...

>
> Non credo, se hai l'MTU impostato male al massimo avrai un degrado delle
> prestazioni, ma deve funzionare.

E invece... e' proprio il MTU, quando e' buono tutto funziona
regolarmente, quando e' basso, a volte meno di 1000, il Terminal Server
non va..

> Piuttosto controlla l'indirizzo, non conosco la tua rete ma 192.168.qualcosa
> e' un indirizzo locale.
>

Si ma ci sono dei router in mezzo, come ti dicevo e' un ponte radio
punto-punto, esce in internet su un IP Pubblico ed arriva dall' altra
parte sempre su un IP pubblico, poi il router lo porta sulla lan
remota..

>> Anche qui non ho capito, la la MTU non vuol dire: Max Transfer Unit e
>> non ha un valore massimo di 1.500 byte per reti ethernet ?
>
> Vuol solo dire che tutto quello che stai trasmettendo verra' diviso in
> pacchetti di 1500 byte al massimo, se ad esempio stai inviando un file di
> 10kb (10240 byte), verra' diviso in 7 pacchetti, di cui 6 di 1500 byte e uno
> di quel che rimane (1240 byte).
> Se invece imposti l'MTU a 1200, i pacchetti saranno di piu' (9 in totale) e
> dato che ogni pacchetto ha un header ci sara' un po' piu' di overhead, cioe'
> la trasmissione durera' un po' (molto poco) di piu'.

Ok, benissimo, quindi 1500 byte e' il valore masimo del pacchetto che
puo' trasportare ethernet.
>
>> Cmq quello che vorrei e' riuscire a tracciare il percorso del mio
>> pacchetto e capire *dove* non transita un determinato valore di MTU in
>> modo da capire quale sia l' apparato che limita il mio collegamento
>>
>> Dove sbaglio ?
>
> Di solito su usa regolare il valore dell'MTU in base al tipo di connessione,
> in modo da ottimizzare il collegamento col proprio provider, ma tieni ben
> presente che si tratta solo di un'ottimizzazione, non e' indispensabile per
> il funzionamento.
> A quello che avviene da li' in poi non dovresti far caso, puo' darsi che ci
> siano tratte con MTU piu' piccola o piu' grande, non importa.

Eh, ma come ti dicevo, importa a me in quanto trattasi di un
collegamento punto-punto e devo capire quali sono le apparecchiature
che mi impediscono il regolare funzionamento..

Cmq grazie 1000 sei molto chiaro e competente nelle risposte, sto
iniziando a capire qualcosa.. :-)

acc

unread,
Jul 19, 2015, 2:11:27 PM7/19/15
to
Il 19/07/2015 19.35, pierino ha scritto:

> Eh, ma come ti dicevo, importa a me in quanto trattasi di un
> collegamento punto-punto e devo capire quali sono le apparecchiature che
> mi impediscono il regolare funzionamento..

Non avevo capito che la tratta era tua, ma in questo caso non ti
dovrebbe essere difficile controllare quali sono le impostazioni nei
vari punti.

pierino

unread,
Jul 20, 2015, 10:43:58 AM7/20/15
to
acc ha spiegato il 19/07/2015 :
Bu no, se provo a testare gli hop ( parametro -t ) mi ritorna questo :

C:\MTU>mturoute -t 192.168.XX.29
mturoute to 192.168.XX.29, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
1 +- host: 192.168.XX.247 max: 1500 bytes
2 -...- host: 82.XXX.XX.174 not responding
3 +- host: 192.168.XX.29 max: 1500 bytes

C:\MTU>

Vedo solo che arriva al mio firewall:

1 +- host: 192.168.XX.247 max: 1500 bytes

poi all' Ip pubblico remoto :

2 -...- host: 82.XXX.XX.174 not responding

che non risponde,

e poi al mio host:

3 +- host: 192.168.XX.29 max: 1500 bytes

In pratica il transito attraverso le apparecchiature costituenti il
ponte radio ed i router necessari non lo vedo.

Forse con qualche altro strumento ?

Grazie

ObiWan

unread,
Jul 20, 2015, 10:51:01 AM7/20/15
to
:: On Mon, 20 Jul 2015 16:43:56 +0200
:: (it.comp.reti.locali)
:: <moj1cj$v4n$1...@dont-email.me>
:: pierino <pie...@pierino.it> wrote:

>
> 2 -...- host: 82.XXX.XX.174 not responding

ti basterebbe abilitare il "ping" (ICMP) verso quell'host; quello che
non mi torna è il fatto che, avendo un ponte radio tra due reti private
(192.168...), per raggiungere i due estremi del ponte tu passi da un IP
pubblico; se non ho capito male come è la config, la cosa non ha molto
senso, anzi, potrebbe proprio essere un errore, specie se i due estremi
del bridge wireless sono sotto il tuo diretto controllo.



pierino

unread,
Jul 20, 2015, 11:09:27 AM7/20/15
to
Sembra che ObiWan abbia detto :
Hum, si, in effetti hai ragione, ho fatto confusione io il fatto e' che
e' stato realizzato un ponte radio con backup su ADSL, quindi se
funziona il ponte radio :
hostA <--> FirewallA <--> PonteradioAntennaA <--> PonteRadioAntennaB
<-->FirewallB<-->hostB

Se funziona il backup:

hostA <--> FirewallA <--> routerAdslA <--> Internet <--> RouterAdslB
<-> FirewallB <--> hostB

Quindi se mturoute mi risponde:

C:\MTU>mturoute -t 192.168.XX.29
mturoute to 192.168.XX.29, 30 hops max, variable sized packets
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
1 +- host: 192.168.XX.247 max: 1500 bytes
2 -...- host: 82.XXX.XX.174 not responding
3 +- host: 192.168.XX.29 max: 1500 bytes

C:\MTU>

Vuol dire che transita attraverso un Ip pubblico :

2 -...- host: 82.XXX.XX.174 not responding

E che, quindi, sto utilizzando l' adsl di backup e non il ponte radio ?

Grazie
0 new messages