Reti locali
 

Ping con pacchetti da 1100-1200...byte
1 | 2 |

pierino 16 Lug 2015 18:00
Ciao,
Ho avuto un problema di connessione e mi hanno fatto fare un test
lanciando questi comandi :

ping ******* ******* ******* ******* -f -l 1100

ping ******* ******* ******* ******* -f -l 1200

ping ******* ******* ******* ******* -f -l 1300

ping ******* ******* ******* ******* -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 16 Lug 2015 18:13
:: On Thu, 16 Jul 2015 18:00:59 +0200
:: (it.comp.reti.locali)
:: <mo8kd3$1sb$1@dont-email.me>
:: pierino <pierino@pierino.it> wrote:

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

https://it.wikipedia.org/wiki/Maximum_Transmission_Unit
ObiWan 16 Lug 2015 18:15
:: On Thu, 16 Jul 2015 18:13:14 +0200
:: (it.comp.reti.locali)
:: <20150716181314.000070a1@eternal-september.org>
:: ObiWan <obiwan@mvps.org> wrote:

> :: On Thu, 16 Jul 2015 18:00:59 +0200
> :: (it.comp.reti.locali)
> :: <mo8kd3$1sb$1@dont-email.me>
> :: pierino <pierino@pierino.it> wrote:
>
>> Cosa indicano questi valori in byte ? Che limite intendono ?
>
> https://it.wikipedia.org/wiki/Maximum_Transmission_Unit

vedi anche

http://www.tp-link.us/FAQ-190.html
pierino 16 Lug 2015 18:19
...
>
> https://it.wikipedia.org/wiki/Maximum_Transmission_Unit

Grazie, molto esaustivo.

Visto che trattasi di un ponte ra***** in test pensi che sia colpa delle
apparecchiature utilizzate poco performanti ?
ObiWan 16 Lug 2015 18:20
:: On Thu, 16 Jul 2015 18:19:32 +0200
:: (it.comp.reti.locali)
:: <mo8lfs$63r$1@dont-email.me>
:: pierino <pierino@pierino.it> wrote:

> ...
>>
>> https://it.wikipedia.org/wiki/Maximum_Transmission_Unit
>
> Grazie, molto esaustivo.
>
> Visto che trattasi di un ponte ra***** in test pensi che sia colpa
> delle apparecchiature utilizzate poco performanti ?

vedi l'altro post o prova questo tool

http://www.elifulkerson.com/projects/mturoute.php
acc 16 Lug 2015 18:32
Il 16/07/2015 18.19, pierino ha scritto:

> Visto che trattasi di un ponte ra***** 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 16 Lug 2015 18:52
...
>
> 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 ra***** 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 16 Lug 2015 21:24
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 17 Lug 2015 11:21
..
>
> 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 17 Lug 2015 11:56
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 19 Lug 2015 11:05
...
> 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 ******* ******* -c3

mi dice:

Fornire valore per l'opzione -c3.

Se provo senza :

C:\MTU>ping 192.168 ******* *******
Risponde:

Risposta da 192.168 ******* ******* byte=32 durata=29ms TTL=126

Quindi con un pacchetto da 32 byte.

Dove sbaglio ?

Grazie
pierino 19 Lug 2015 12:07
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 ******* 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 ******* 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 19 Lug 2015 15:33
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 *****ogo

> 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 ******* 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 19 Lug 2015 17:58
..
>> 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 ******* 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 ******* 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 ra***** 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 19 Lug 2015 19:25
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 ******* 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 *******
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 19 Lug 2015 19:35
..
>
> 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 ra*****
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 ******* 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 19 Lug 2015 20:11
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 20 Lug 2015 16:43
acc ha spiegato il 19/07/2015 :
> 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.

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 ******* 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 ******* 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 ra***** ed i router necessari non lo vedo.

Forse con qualche altro strumento ?

Grazie
ObiWan 20 Lug 2015 16:51
:: On Mon, 20 Jul 2015 16:43:56 +0200
:: (it.comp.reti.locali)
:: <moj1cj$v4n$1@dont-email.me>
:: pierino <pierino@pierino.it> wrote:

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

ti basterebbe abilitare il "ping" (ICMP) verso quell'host; quello che
non mi torna è il fatto che, avendo un ponte ra***** 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 20 Lug 2015 17:09
Sembra che ObiWan abbia detto :
>>> On Mon, 20 Jul 2015 16:43:56 +0200
>>> (it.comp.reti.locali)
>>> <moj1cj$v4n$1@dont-email.me>
>>> pierino <pierino@pierino.it> wrote:
>
>>
>> 2 -...- host: 82 ******* XX.174 not responding
>
> ti basterebbe abilitare il "ping" (ICMP) verso quell'host; quello che
> non mi torna è il fatto che, avendo un ponte ra***** 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.

Hum, si, in effetti hai ragione, ho fatto confusione io il fatto e' che
e' stato realizzato un ponte ra***** con backup su ADSL, quindi se
funziona il ponte ra***** :
hostA <--> FirewallA <--> Pontera*****AntennaA <--> PonteRa*****AntennaB
<-->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 ******* 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 ******* XX.174 not responding

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

Grazie
ObiWan 20 Lug 2015 17:14
:: On Mon, 20 Jul 2015 17:09:26 +0200
:: (it.comp.reti.locali)
:: <moj2sc$63d$1@dont-email.me>
:: pierino <pierino@pierino.it> wrote:

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

mi sa di si :P
pierino 20 Lug 2015 17:24
Il 20/07/2015, ObiWan ha detto :
>>> On Mon, 20 Jul 2015 17:09:26 +0200
>>> (it.comp.reti.locali)
>>> <moj2sc$63d$1@dont-email.me>
>>> pierino <pierino@pierino.it> wrote:
>
>> E che, quindi, sto utilizzando l' adsl di backup e non il ponte
>> ra***** ?
>
> mi sa di si :P

Hum, eppure il firewall dice di no, verifico...

grazie 1000 !!
ObiWan 20 Lug 2015 17:57
:: On Mon, 20 Jul 2015 17:24:16 +0200
:: (it.comp.reti.locali)
:: <moj3o7$a48$1@dont-email.me>
:: pierino <pierino@pierino.it> wrote:

> Il 20/07/2015, ObiWan ha detto :
>>>> On Mon, 20 Jul 2015 17:09:26 +0200
>>>> (it.comp.reti.locali)
>>>> <moj2sc$63d$1@dont-email.me>
>>>> pierino <pierino@pierino.it> wrote:
>>
>>> E che, quindi, sto utilizzando l' adsl di backup e non il ponte
>>> ra***** ?
>>
>> mi sa di si :P

> Hum, eppure il firewall dice di no, verifico...

beh, fai presto a verificare, stacca la ADSL e controlla se il link
funziona :D
pierino 21 Lug 2015 17:50
..
>
> beh, fai presto a verificare, stacca la ADSL e controlla se il link
> funziona :D

Aggiornamento: Sembra che funzioni il ponte ra***** ma, per qualche
motivo recondito, il firewall di destino coinvolga anche l' interfaccia
ADSL.
Mah, non esiste uno strumento che permette di verificare il limite
dell' MTU su *ogni* apparato su cui transita ?

Ade esempio su ognuno di questi apparati ?

hostA <--> FirewallA <--> Pontera*****AntennaA <--> PonteRa*****AntennaB
<-->FirewallB<-->hostB

Attualmente *misuro* gli host e basta..

Grazie
Mirko Borsari 21 Lug 2015 18:13
Il Tue, 21 Jul 2015 17:50:07 +0200, pierino ha scritto:


> Aggiornamento: Sembra che funzioni il ponte ra***** ma, per qualche
> motivo recondito, il firewall di destino coinvolga anche l' interfaccia
> ADSL.

bhe, questo va messo a posto... ti stai concentrando sull'mtu ma
magari il problema è proprio la configurazione di questo firewall...

> Mah, non esiste uno strumento che permette di verificare il limite
> dell' MTU su *ogni* apparato su cui transita ?

ma se tutti gli apparati sono sotto il tuo controllo non puoi
verificarne la configurazione e modificarla se serve?



--
MirkoB. news@bsi-net.it
Motoretta BMW R1200R Lightgrey

L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente
pierino 21 Lug 2015 18:57
Sembra che Mirko Borsari abbia detto :
> Il Tue, 21 Jul 2015 17:50:07 +0200, pierino ha scritto:
>
>
>> Aggiornamento: Sembra che funzioni il ponte ra***** ma, per qualche
>> motivo recondito, il firewall di destino coinvolga anche l' interfaccia
>> ADSL.
>
> bhe, questo va messo a posto... ti stai concentrando sull'mtu ma
> magari il problema è proprio la configurazione di questo firewall...
>
>> Mah, non esiste uno strumento che permette di verificare il limite
>> dell' MTU su *ogni* apparato su cui transita ?
>
> ma se tutti gli apparati sono sotto il tuo controllo non puoi
> verificarne la configurazione e modificarla se serve?

No, purtroppo e' un ponte ra***** esistente e non realizzato da me, sto
cercando di capire per, eventualmente, fare le domande giuste..

Grazie
Mirko Borsari 22 Lug 2015 09:04
Il Tue, 21 Jul 2015 18:57:12 +0200, pierino ha scritto:


>> ma se tutti gli apparati sono sotto il tuo controllo non puoi
>> verificarne la configurazione e modificarla se serve?
>
> No, purtroppo e' un ponte ra***** esistente e non realizzato da me, sto
> cercando di capire per, eventualmente, fare le domande giuste..

vabbè, ma è tutta roba che puoi controllare... non stiamo parlando di
un router telecom nel mix...
se vuoi sapere come sono configurati gli MTU, basterà chiederlo a chi
mette mano agli apparati (e potrei aspettarmi che siano ai valori di
default)...




--
MirkoB. news@bsi-net.it
Motoretta BMW R1200R Lightgrey

L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente
pierino 22 Lug 2015 19:46
...
>
> vabbè, ma è tutta roba che puoi controllare... non stiamo parlando di
> un router telecom nel mix...
> se vuoi sapere come sono configurati gli MTU, basterà chiederlo a chi
> mette mano agli apparati (e potrei aspettarmi che siano ai valori di
> default)...

Il problema e' che chi ha fatto il ponte non e' attualmente reperibile,
quindi non ho accesso agli apparati del ponte ra*****.
Volevo cercare di capire in modo autonomo il motivo x il quale, in
certi momenti, il valore di MTU che *passa* scende sotto i 1000 byte ed
impedisce il collegamento in Terminal Server.

Posso misurare il valore max dell' MTU degli host, controllare quello
dei firewall e mi sembra tutto ok, quindi dovrebbero essere gli apparti
del ponte, ma non so quali..

Credevo esistesse uno strumento software che *****izza *ogni* apparati
su cui transita e, quindi, risesca ad individuare su quale apparato non
passa..

grazie
Mirko Borsari 22 Lug 2015 20:07
Il Wed, 22 Jul 2015 19:46:17 +0200, pierino ha scritto:


> Il problema e' che chi ha fatto il ponte non e' attualmente reperibile,
> quindi non ho accesso agli apparati del ponte ra*****.
> Volevo cercare di capire in modo autonomo il motivo x il quale, in
> certi momenti, il valore di MTU che *passa* scende sotto i 1000 byte ed
> impedisce il collegamento in Terminal Server.

perdonami, ma a me sembra più problematica la cosa che hai spiegato
qualche post fa riguardo al firewall che pare faccia un po' di
confusione con le interfacce...

> Posso misurare il valore max dell' MTU degli host, controllare quello
> dei firewall e mi sembra tutto ok, quindi dovrebbero essere gli apparti
> del ponte, ma non so quali..
>
> Credevo esistesse uno strumento software che *****izza *ogni* apparati
> su cui transita e, quindi, risesca ad individuare su quale apparato non
> passa..

come è già stato detto i dati passano sempre... vengono solo divisi in
pezzi più grandi o più piccoli in base allo spazio che c'è.
con il comando ping che hai postato all'inizio riesci a capire
variando il valore di MTU quale sia il più alto possibile che passa
senza frammentazione.

ti incollo un esempio che ho fatto adesso pingando un host attraverso
una VPN, prima con frammentazione disabilitata e poi abilitata, come
vedi normalmente i dati passano, quindi mi sembra strano che il
problema sia questo (anche se ovviamente non lo escludo al 100%)

C:\Users\mirko.BSI>ping 192.168.56.19 -f -l 1500

Esecuzione di Ping 192.168.56.19 con 1500 byte di dati:
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.

Statistiche Ping per 192.168.56.19:
Pacchetti: Trasmessi = 4, Ricevuti = 0,
Persi = 4 (100% persi),

C:\Users\mirko.BSI>ping 192.168.56.19 -l 1500

Esecuzione di Ping 192.168.56.19 con 1500 byte di dati:
Risposta da 192.168.56.19: byte=1500 durata=95ms TTL=125
Risposta da 192.168.56.19: byte=1500 durata=117ms TTL=125
Risposta da 192.168.56.19: byte=1500 durata=110ms TTL=125
Risposta da 192.168.56.19: byte=1500 durata=107ms TTL=125

Statistiche Ping per 192.168.56.19:
Pacchetti: Trasmessi = 4, Ricevuti = 4,
Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 95ms, Massimo = 117ms, Me***** = 107ms




--
MirkoB. news@bsi-net.it
Motoretta BMW R1200R Lightgrey

L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente
pierino 23 Lug 2015 09:28
..
>
> perdonami, ma a me sembra più problematica la cosa che hai spiegato
> qualche post fa riguardo al firewall che pare faccia un po' di
> confusione con le interfacce...

Bu, si, fa un po' di confusione ma l' MTU la posso controllare
..

>> Credevo esistesse uno strumento software che *****izza *ogni* apparati
>> su cui transita e, quindi, risesca ad individuare su quale apparato non
>> passa..
>
> come è già stato detto i dati passano sempre... vengono solo divisi in
> pezzi più grandi o più piccoli in base allo spazio che c'è.
> con il comando ping che hai postato all'inizio riesci a capire
> variando il valore di MTU quale sia il più alto possibile che passa
> senza frammentazione.

OK
>
> ti incollo un esempio che ho fatto adesso pingando un host attraverso
> una VPN, prima con frammentazione disabilitata e poi abilitata, come
> vedi normalmente i dati passano, quindi mi sembra strano che il
> problema sia questo (anche se ovviamente non lo escludo al 100%)
>
...

Ok i dati passano, ma non basta, probabilmente per certe appilcazioni
devono essere anche di una certa dimensione, a me se la mtu va sotto i
1000 il Terminal Server Windows non funziona...
acc 23 Lug 2015 09:40
Il 23/07/2015 9.28, pierino ha scritto:

> Ok i dati passano, ma non basta, probabilmente per certe appilcazioni
> devono essere anche di una certa dimensione, a me se la mtu va sotto i
> 1000 il Terminal Server Windows non funziona...

Per le connessioni remote, di default Windows pone l'MTU a 576, se
ricordo bene, gia' questo dovrebbe suggerirti che il problema non
dovrebbe essere li'.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Reti locali | Tutti i gruppi | it.comp.reti.locali | Notizie e discussioni reti locali | Reti locali Mobile | Servizio di consultazione news.