Recentemente, tenho lidado com problemas de MTU . E tudo parece resultar do fato de que o adaptador ethernet em computadores mais novos possui um tamanho de quadro de 1504 bytes:
>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1504 1 3954161316 804790885 Local Area Connection
Agora, de acordo com uma pessoa aleatória no NetworkEngineering.stackexchange.com , qualquer pacote muito grande será descartado por qualquer NIC (placa de interface de rede) receptora, pois o pacote ethernet é muito grande:
... qualquer quadro com uma MTU maior que a especificação 802.3 de 1500
Um quadro maior que o máximo definido será descartado pela NIC - é um erro e o sistema operacional nunca saberá sobre isso. (um contador de quadros de grandes dimensões clicará, mas é tudo.)
O que causa problemas quando o computador tenta enviar pacotes para a máquina de gateway. Idealmente, eu estaria contando com a descoberta do Path MTU . Porém, como os pacotes Ethernet que estão sendo gerados são grandes demais para serem recebidos por qualquer outra máquina, não há oportunidade para que as mensagens de fragmentação muito grandes do Pacote IP sejam retornadas:
Não haverá "fragmentação". A camada 2 (Ethernet) não tem meios se indicar "fragmentação necessária". Isso é descoberto na Camada 3 (IP) pelos roteadores que enviam uma mensagem ICMP quando é necessário descartar o pacote porque não cabe na interface do próximo salto.
O que me leva à minha segunda pergunta primeiro:
- Por que existe uma especificação que cria intencionalmente quadros Ethernet inválidos? Qual é o comportamento pretendido aqui? Dado que outras placas de interface de rede não podem receber esses novos pacotes de tamanho padrão, o que eles esperavam que acontecesse.
Isso então me leva à minha primeira pergunta depois. E isso é algo que já foi perguntado antes - muito.
- A etiqueta QinQ de 4 bytes faz parte do cabeçalho do quadro ethernet ou parte da carga útil da ethernet? Se faz parte do cabeçalho, por que o corpo da carga aumentou em 4 bytes? Se faz parte da carga útil da Ethernet, por que a carga útil MTU aumenta em 4 bytes (quando sabemos que aumentá-la em 4 bytes faz com que seja um pacote inválido)?
A questão maior é ...
Se recuarmos por um momento, temos a pergunta maior:
O que devemos fazer?
Deve ter havido pessoas que projetaram esse padrão. O que eles esperavam que as pessoas fizessem com dispositivos que geram esses pacotes muito grandes ?
Estou realmente perguntando. Presumo que não fomos feitos para ir a todos os dispositivos de hardware e desfazer o aumento do MTU 1504 e revertê-lo para 1500:
netsh interface ipv4>set subinterface "Local Area Connection" mtu=1500 store=persistent
Ok.
isso seria (e está sendo) um pesadelo de configuração.
A ideia talvez seja desativar a marcação de VLAN? Além do pesadelo da configuração, ele simplesmente não funciona:
Etapa 1: desativar a marcação de VLAN
Etapa 2: observe que não funciona:
interface netsh ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
1504 1 238125 245855 Local Area Connection
Se a solução para isso é forçar manualmente todas as placas de rede para uma MTU de 1500, por que elas aumentaram até 1504 bytes e, em primeiro lugar, criaram pacotes inválidos?
Há uma peça do quebra-cabeça que estou perdendo.
Bônus Chatter
Without 802.1Q tagging Without 802.1Q tagging
+------------------------+ +------------------------+
|Destination MAC: 6 bytes| |Destination MAC: 6 bytes|
|Source MAC: 6 bytes | |Source MAC: 6 bytes |
|Ethertype: 2 bytes | |802.1Q tag: 4 bytes |
+------------------------+ |Ethertype: 2 bytes |
| | +------------------------+
| | | |
/ Payload: 1500 bytes / / Payload: 1500 bytes /
| | | |
| | | |
+------------------------+ | |
| Frame Check Sequence: | +------------------------+
| 4 bytes| | Frame Check Sequence: |
+------------------------+ | 4 bytes|
+------------------------+
Diagrama de rede
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | |
| | | | | |
| 192.168.1.98/24 |-----------+ +------------| 192.168.1.10/24 |
| MTU = 1504 bytes | | MTU = 1500 bytes |
+------------------+ +------------------+
Você também pode substituir qualquer configuração que desejar, gerando pacotes maiores que o máximo permitido de 1500bytes:
+------------------+ +----------------+ +------------------+
| Realtek PCIe GBe | | NetGear 10/100 | | Realtek 10/100 |
| (on-board) | | Switch | | (on-board) |
| | +----------------+ | |
| Windows 7 | ^ ^ | MTU = 1500 bytes |
| MTU = 16384bytes | | | | |
| |-----------+ +------------| |
+------------------+ +------------------+
Estou tentando encontrar um site que possa resolver meu problema técnico, conceitual, lógico, fundamental e teórico de como a Ethernet pode funcionar quando alguns dispositivos geram intencionalmente pacotes inválidos.
A preocupação surge quando tento enviar um pacote Ethernet inválido para outro dispositivo Ethernet:
computador gera pacote Ethernet
Source MAC: xx-xx-xx-xx-xx-xx Destination MAC: yy-yy-yy-yy-yy-yy Ethertype: 0x0800 Payload: ...1504 bytes... (or could be ...16384 bytes, anything larger than 1500...) CRC: 4 bytes
Este pacote é inválido porque é muito grande para ser recebido pelo dispositivo 802.3u de destino. Como o sistema operacional host do destino nunca vê o pacote e como a Ethernet não tem funcionalidade para relatar pacotes inválidos de volta ao remetente, o pacote "grande" é perdido.
Bônus Chatter
No link entre switches da Cisco e no formato de quadro IEEE 802.1Q :
Tamanho do quadro
A unidade de transmissão máxima padrão (MTU) de uma interface é de 1500 bytes. Com uma etiqueta VLAN externa conectada a um quadro Ethernet, o tamanho do pacote aumenta em 4 bytes. Portanto, é aconselhável que você aumente adequadamente o MTU de cada interface na rede do provedor. O MTU mínimo recomendado é 1504 bytes.
Enquanto isso:
O padrão Ethernet IEEE 802.3 exige apenas suporte para quadros MTU de 1500 bytes.