it-swarm-eu.dev

Come sapere quale MTU viene utilizzato in Windows XP

Sto soffrendo di un problema davvero strano in cui casualmente ottengo errori "La connessione al server è stata ripristinata" quando si tenta di accedere alle pagine Web (errore HTTP 12031 in base allo strumento di diagnostica della rete Windows) - questo accade indipendentemente dal fatto che la pagina web Sto cercando di accedere è su Internet esterno o anche se proviene da un'istanza Apache locale in esecuzione su localhost. Colpisce tutti i computer sulla nostra rete locale (Ethernet, non wireless), che utilizzano Windows XP.

Mi è stato suggerito che potrebbe avere a che fare con il MTU utilizzato sul traffico di rete. Se faccio il test ping per scoprire il pacchetto più grande che può passare attraverso non frammentato, posso eseguire il ping del localhost con un pacchetto di 1492 byte (+28 byte per un'intestazione?) e posso eseguire il ping del router con un pacchetto di 1462 byte (che è 1490 byte quando si include l'intestazione da 28 byte). Se provo a eseguire il ping di qualcosa all'esterno come Google, non riesco a ottenere nulla tramite più grande di 1430 (che è 1458 con l'intestazione).

Ho provato a seguire varie serie di istruzioni per aggiornare Windows XP Registry con questa impostazione MTU, aggiornando HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. Ho provato senza fine valori alternativi: il valore corretto più ovvio sembra essere il 1490, ma ho anche provato 1462, 1458, 1430, ecc. Ecc. Quando riavvio il computer per rendere effettive le modifiche, sembra funzionare per alcuni minuti (difficile da dire con certezza dato che è sempre casuale piuttosto che coerente) ma non dura mai a lungo.

Inizialmente, quando stavo tentando il valore 1430, dopo alcuni minuti di funzionamento, i risultati del test ping si sarebbero ridotti di 28 byte: improvvisamente avrei scoperto che potevo ottenere un pacchetto di 1402 byte solo su Google. Se avessi aggiornato l'impostazione del registro MTU su 1402, quando ho riavviato e aspettato alcuni minuti, sarebbe stato quindi 1374, quindi 1346, ecc. Ecc. Altri computer sulla rete non sono stati modificati (ancora al 1430) e rimuovendo l'impostazione MTU dal registro ripristinare le cose alla normalità (e ancora rotto).

La cosa che trovo più difficile nel diagnosticare tutto questo è che è molto difficile capire se sto persino giocando con le corrette impostazioni del registro. Quindi, è più semplice, la mia domanda sarebbe: Come posso sapere quale MTU sta configurando Windows sta cercando di usare?

Inoltre, se qualcuno ha qualche idea su come spiegare perché il MTU continua a scendere di 28, sarebbe utile anche (ad esempio, c'è un file di registro di Windows da qualche parte dove registrerà qualcosa nel punto in cui il valore cambia?)

Infine, se qualcuno può dirmi in modo definitivo come dire quale impostazione MTU dovrei provare a usare, sarebbe fantastico!

20
andygeers

Per Windows 7, Windows Vista e Windows XP, l'MTU per varie interfacce è disponibile da Windows stesso utilizzando netsh.

Windows 7, Windows Vista

Per mostrare corrente MTU su Windows 7 o Windows Vista, da un prompt dei comandi:

C:\Users\Ian>netsh interface ipv6 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1280                1   24321220    6455865  Local Area Connection
4294967295                1          0    1060111  Loopback Pseudo-Interface 1
      1280                5          0          0  isatap.newland.com
      1280                5          0          0  6TO4 Adapter

E per le interfacce IPv4:

C:\Users\Ian>netsh interface ipv4 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1500                1  146289608   29200474  Local Area Connection
4294967295                1          0      54933  Loopback Pseudo-Interface 1

Nota: In questo esempio la mia interfaccia di connessione alla rete locale IPv6 ha un MTU (1280) così basso perché sto usando un servizio tunnel per ottenere la connettività IPv6 .

Puoi anche cambiare il tuo MTU (Windows 7, Windows Vista). Da un comando elevato Prompt:

>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.

Testato con Windows 7 Service Pack 1

Windows XP

La sintassi netsh per Windows XP è leggermente diversa:

C:\Users\Ian>netsh interface ip show interface

Index:                                  1
User-friendly Name:                     Loopback
Type:                                   Loopback
MTU:                                    32767
Physical Address:                       

Index:                                  2
User-friendly Name:                     Local Area Connection
Type:                                   Etherenet
MTU:                                    1500
Physical Address:                       00-03-FF-D9-28-B7

Nota: Windows XP richiede che il servizio Routing e Accesso remoto sia avviato prima di poter visualizzare i dettagli su un'interfaccia (incluso MTU):

C:\Users\Ian>net start remoteaccesss

Windows XP non fornisce un modo per modificare l'impostazione MTU da netsh. Per quello puoi:

Testato con Windows XP Service Pack 3

Guarda anche


Breve discussione su cosa sia MTU, da cui provengono i 28 byte.

La tua scheda di rete (Ethernet) ha una dimensione massima del pacchetto di 1,500 bytes:

+---------+
| 1500    |
| byte    |
| payload |
|         |
|         |
|         |
+---------+

La porzione IP di TCP/IP richiede un'intestazione da 20 byte (12 byte di flag, 4 byte per l'indirizzo IP di origine, 4 byte per l'indirizzo IP di destinazione). Questo lascia meno spazio disponibile nel pacchetto:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |- IP header: 20 bytes
| 4 byte to address      | /
|------------------------|
| 1480 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

Ora un pacchetto ICMP (ping) ha un'intestazione di 8 byte (1 byte type, 1 byte code, 2 byte checksum, 4 byte di dati aggiuntivi):

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
| 1472 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

Ecco dove sono "28" mancanti - è la dimensione delle intestazioni necessarie per inviare un pacchetto ping.

Quando invii un pacchetto ping, puoi specificare quanti extra dati di payload desideri includere. In questo caso, se includi tutti i 1472 byte:

>ping -l 1472 obsidian

Quindi il pacchetto risultante ethernet sarà pieno per le branchie. Ogni ultimo byte del pacchetto da 1500 byte sarà riempito:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|. 1472 bytes of junk....|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Se provi a inviare un altro byte

>ping -l 1473 obsidian

la rete dovrà frammentare quel pacchetto da 1501 byte in più pacchetti:

Packet 1 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|..1472 bytes of payload.|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Packet 2 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|.                       |
| 1 byte of payload      |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

Questa frammentazione avverrà dietro le quinte, idealmente senza che tu lo sappia.

Ma puoi essere cattivo e dire alla rete che il pacchetto non può essere frammentato:

>ping -l 1473 -f obsidian

Il simbolo - f indica non frammentare . Ora quando provi a inviare un pacchetto che non si adatta alla rete ottieni l'errore:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

Il pacchetto deve essere frammentato, ma è stato impostato il flag Do not Fragment .

Se ovunque lungo la linea un frammento dovesse essere frammentato, la rete invia effettivamente un pacchetto ICMP che ti dice che è avvenuta una frammentazione. La tua macchina riceve questo pacchetto ICMP, viene detto qual è la dimensione più grande e si suppone che smetta di inviare pacchetti troppo grandi. Sfortunatamente la maggior parte dei firewall blocca questi pacchetti ICMP "Path MTU discovery", quindi la tua macchina non si rende mai conto che i pacchetti sono frammentati (o peggio: lasciati cadere perché non possono essere frammentati).

Questo è il motivo per cui il web server non funziona. È possibile ottenere le risposte iniziali piccole (<1280 byte), ma i pacchetti più grandi non riescono a passare. E i firewall del server Web non sono configurati correttamente, bloccando i pacchetti ICMP. Quindi il web server non si rende conto che non hai mai ricevuto il pacchetto.

La frammentazione dei pacchetti non è consentita in IPv6, tutti sono richiesti per consentire (correttamente) i pacchetti di rilevamento di ICMP mtu.

57
Ian Boyd

@ian Non sono così sicuro che netsh mostri effettivamente l'MTU attualmente usato. Sulla mia macchina Windows XP Pro SP3, ho eseguito netsh interface ip show interface e ho segnalato il valore MTU per l'interfaccia relativa come 1500. Ho quindi aggiunto le seguenti chiavi di registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
    value: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\MTU 
    value: various (e.g. 1200)

Microsoft dice che l'impostazione EnablePMTUDiscovery a 0 imposterà MTU a 576.

L'impostazione della voce di registro MTU imposta manualmente la MTU. Ho provato diversi valori per la voce MTU (riavvio ogni volta).

In entrambi i casi - aggiungendo la prima voce, poi la seconda voce - netsh riportava ancora la MTU come 1500. Test con ping confermato (o almeno suggerito) che il valore MTU configurato nel registro era in realtà utilizzato.

Inoltre, quando ho provato questo sul mio computer, il servizio Routing e Accesso remoto è stato disabilitato, quindi non è stato possibile avviarlo seguendo le tue istruzioni. L'ho abilitato andando in Pannello di controllo> Strumenti amministrativi> Gestione computer> Servizi e applicazioni> Servizi. Ho cambiato "Tipo di avvio" da Disabilitato a Manuale. Ho quindi avviato il servizio da quella finestra di dialogo.

Inoltre, non sono sicuro che KB283165 sia necessariamente le istruzioni corrette per la modifica del MTU. Queste istruzioni non sono rilevanti solo quando si esegue il client _ PPPoE di Windows? Se si connette a Internet tramite un router in cui il router è il client PPPoE (come nel mio caso), quelle istruzioni non sarebbero rilevanti, giusto?

Le istruzioni che ho seguito, che mi hanno portato a apportare le modifiche sopra riportate al registro, erano in KB900926: Impostazioni TCP/IP consigliate per WAN link con una dimensione MTU di meno di 576 (metodi 2 e 3).


Modifica per @ian

Sembra che tu abbia ragione. Configura per 1.200, ma netsh segnala 1500.

enter image description here

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

Quindi suppongo che la risposta alla domanda originale sia che su Windows XP devi usare trial-and-error con il flag Do not fragment per trovare il il più grande pacchetto che puoi inviare è Allora hai il tuo MTU.

8
JMM

Puoi trovare MTU usando il ping con approccio di prova ed errore:

ping <address> -f -l nnnn

Ping:

-f: specifica che i messaggi Echo Request vengono inviati con il flag Do not Fragment nell'intestazione IP impostato su 1. Il messaggio Echo Request non può essere frammentato dai router nel percorso verso la destinazione. Questo parametro è utile per la risoluzione dei problemi relativi ai problemi di Maximum Transmission Unit (PMTU).

-l Dimensione: specifica la lunghezza, in byte, del campo Dati nei messaggi di richiesta eco inviati. Il valore predefinito è 32. La dimensione massima è 65.527.

Otterrai "Il pacchetto deve essere frammentato ma DF imposta" i messaggi quando la lunghezza è troppo grande.

2
T. Kaltnekar

Microsoft KB314496: Le dimensioni MTU predefinite per diverse topologie di rete .
Non si dovrebbe provare a giocare con la configurazione MTU nelle normali configurazioni di rete.

Qui c'è un riferimento al codice VB .
C'è anche uno strumento chiamato DrTCP :

alt text


Nel registro,

  • Vai a HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • Apri l'adattatore che ti interessa
  • Copia la stringa ServiceName
  • Cerca quella stringa in HKLM\System; abbinerai una chiave NetCfgInstanceId
  • Un po 'sopra che sarà la chiave MaxFrameSize (la mia mostra 1514)

C'è anche un modo per cambiarlo con il comando netsh.

Inoltre, controlla la configurazione Percorso MTU Discovery .

1
nik

Vedi AdapterWatch :

AdapterWatch visualizza informazioni utili sugli adattatori di rete: indirizzi IP, indirizzo hardware, WINS server, server DNS, valore MTU, numero di byte ricevuti o inviati, la velocità di trasferimento corrente e altro. Inoltre, visualizza le statistiche generali TCP/IP/UDP/ICMP per il tuo computer locale.

1
harrymc