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.
Respostas:
Respondendo a preocupações individuais no post ...
Em relação à descoberta do Path MTU
Com base no seu diagrama, concordo que o PMTUD não pode funcionar entre dois PCs diferentes no mesmo segmento da LAN; Os PCs não geram mensagens de erro ICMP exigidas pelo PMTUD .
Jumbo frames
Alguns fornecedores (como a Cisco) têm modelos de switch que suportam cargas de Ethernet maiores que 1500 bytes. Oficialmente, o IEEE não endossa essa configuração , mas o setor precisa validar criteriosamente o MTU original de 1500 bytes. Tenho redes LAN / backup de armazenamento que aproveitam o jumbo frame por um bom motivo; no entanto, assegurei-me de que todas as MTUs correspondessem à mesma vlan ao implantar jumbo-frames.
MTUs incompatíveis em um domínio de broadcast
A conclusão é que você nunca deve ter MTUs Ethernet incompatíveis dentro do mesmo domínio de transmissão Ethernet; se o fizer, é um erro ou erro de configuração. Independentemente de bug ou erro, você precisa resolver esses problemas, às vezes manualmente.
Toda essa discussão leva à próxima pergunta ...
Não sei se concordo ... Não vejo como a série IEEE 802.3 ou RFC 894 cria quadros inválidos. Implementações de host ou configurações incorretas de host criam quadros inválidos. Para entender se sua implementação está seguindo as especificações, precisamos de muito mais evidências ...
Este diagrama é pelo menos uma evidência prima facie de que suas MTUs são incompatíveis dentro de um domínio de broadcast ...
Como uma implementação compatível com 802.3 responde a incompatibilidades de MTU?
MTU 1504 e MTU 1500 dentro do mesmo domínio de broadcast é simplesmente uma configuração incorreta; nunca se espera que funcione mais do que máscaras de rede IP incompatíveis ou sub-redes IP incompatíveis podem funcionar. Sua empresa terá que se ajustar e corrigir a causa raiz das incompatibilidades da MTU ... neste momento, é difícil dizer se a causa raiz é erro do usuário, erro de implementação ou alguma combinação das opções acima.
Se as máquinas Windows afetadas estiverem efetuando login com êxito em um domínio do Active Directory, é possível escrever scripts de logon do Windows para corrigir automaticamente problemas de MTU com base em alguns testes bem construídos nos scripts de logon de domínio (supondo que o controlador de domínio não faça parte da MTU problemas).
Se as máquinas não estiverem efetuando login em um domínio, o trabalho manual é outra opção.
Outras possibilidades de conter os danos
Use um switch layer3 Nota 1 para criar uma vlan personalizada para qualquer coisa que tenha MTUs quebradas e defina a MTU Ethernet do switch layer3 para corresponder às máquinas quebradas; isso depende do PMTUD para resolver problemas de MTU na camada IP. Switches Layer3 geram os erros ICMP exigidos pelo PMTUD .
Esta opção funciona melhor se você puder endereçar novamente as máquinas quebradas com DHCP; e você pode identificar as máquinas quebradas pelo endereço mac.
Difícil dizer neste momento
802.1ad vs 802.1q
Até agora não vi evidências de que você esteja usando o QinQ ; pelas evidências limitadas que vi até agora, você está usando o encapsulamento 802.1q simples , que deve funcionar corretamente no Windows, supondo que o driver da NIC suporte o encapsulamento 802.1q .
Notas finais :
Nota 1 Qualquer switch da camada 3 deve funcionar ... Cisco, Juniper e Brocades podem executar esse tipo de função.
fonte
Eu posso tentar responder sua pergunta conceitual.
Não consigo encontrar uma cotação real, mas parece bastante claro que .1ad e .1q nunca foram planejados para serem processados por PCs ou outros hosts finais. Eles são (geralmente) processados apenas por equipamentos de infraestrutura. Não sei o que estava na mente dos designers, mas é difícil imaginar pacotes QinQ indo para um PC em um cenário da vida real. Interfaces Ethernet em equipamentos de infraestrutura (rotas, comutadores, etc.), podem lidar com pacotes maiores.
Portanto, os pacotes são inválidos apenas para PCs, o que, em teoria, nunca os deveria ver.
fonte