Primeiro, talvez seja melhor explicar o que é a Ethernet Jumbo Frame. A Ethernet é uma tecnologia de rede de camada 2 e sua Unidade de dados de protocolo (PDU) é um quadro. Para referência, um L3PDU (camada IP) é um pacote e um L4PDU (tcp / udp) é um segmento.
Um quadro Ethernet (existem vários tipos de Ethernet, mas podemos generalizar aqui) consiste em um cabeçalho (contendo, entre outras coisas, um MAC de origem, um MAC de destino, um tag de VLAN 802.1q, etc.) os dados, ou paylod, de o quadro e uma soma de verificação CRC usada para validar a transmissão bem-sucedida do quadro.
A ethernet original especificou um tamanho de quadro (o valor dos dados em todo o quadro, incluindo o cabeçalho e a soma de verificação) como 1500 bytes (ou possivelmente 1518, é necessário pesquisar). Esse número atingiu um equilíbrio entre a quantidade de dados a serem enviados de uma só vez e a probabilidade de a transmissão falhar ou colidir e ter que ser retransmitida. Com o advento de LANs rápidas e full duplex, as pessoas perceberam que o desempenho poderia ser melhorado aumentando o tamanho do quadro Ethernet. O tamanho tradicional dos quadros jumbo é de 9000 bytes por quadro, embora isso seja principalmente uma convenção.
Em uma LAN sólida (full-duplex) (ou VLAN) na qual todos os elementos esperam receber ethernet de quadro jumbo, ele realmente melhora o desempenho. O problema com esse cenário é se você introduzir um elemento de rede ou dispositivo final que não o espera. Na melhor das hipóteses, isso resultará em uma degradação do desempenho, pois os pacotes são perdidos porque os dispositivos receptores esperam apenas 1518 bytes em um quadro.
Agora, para suas perguntas específicas:
Qual seria a melhor maneira de implementar o Jumbo Frames em uma rede?
Esta é uma pergunta subjetiva. No meu local de trabalho, optamos por implementá-lo apenas onde sabíamos que tínhamos todas as variáveis sob controle e sabíamos que isso ajudaria. Para fazer isso, nós o implementamos em uma vlan "privada" especial que somente dispositivos específicos podiam acessar por meio de suas segundas NICs. Especificamente, colocamos a segunda NIC de nossos servidores de arquivos e servidores de aplicativos nessa nova VLAN e, em seguida, alteramos todas as referências ao esquema de IP usado nessa VLAN. Isso nos permite segmentar de maneira restrita (ninguém conectará uma máquina de desktop a essa VLAN) a área específica que sabemos que mais se beneficiaria (os links de dados de maior utilização em nossa infraestrutura). Isso maximiza o ganho e minimiza o risco.
Mais especificamente, no lado da rede (usando IOS), construímos VLANs dedicadas aos dispositivos de quadro jumbo e adicionamos "mtu 9000" à sua definição de vlan. Todas as interfaces do switch que usariam essa rede foram colocadas nessa vlan usando algo como "switchport access vlan 11". Nas máquinas Linux (que têm eth0 conectado à rede padrão e eth1 conectado à rede jumbo frame), adicionamos "MTU = 9000" a / etc / sysconfig / network-scripts / ifcfg-eth1. Como nunca roteamos esses pacotes (é impossível que qualquer coisa que não esteja diretamente conectada à VLAN do jumbo-frame fale com uma NIC na VLAN do jumbo-frame), nunca tivemos que nos preocupar com a configuração do roteador.
Pelo que sei, para que funcione corretamente, todos os equipamentos de rede da rede devem suportar Jumbo Frames. Isso é verdade?
Sim, praticamente. Todos os "clientes" da rede (com o que eu quero dizer servidores / desktops / IPKVMs / monitores ambientais IP etc.) também devem falar isso ou, como mencionado acima, você terá muitas máquinas semi-alcançáveis (elas executarão ping e qualquer L3 ou L4PDU com menos de 1500 bytes serão bem-sucedidos, o que significa que, por exemplo, seu servidor de email fará ping e você poderá entregar manualmente o que provavelmente será uma pequena mensagem de teste. mail (aquele com o anexo do Excel que é enviado com tamanho de quadro> 1500 bytes), ele misteriosamente falhará).
Se eu tiver equipamentos específicos (por exemplo, impressora de rede) que não puderem ser atualizados para a Ethernet GB, isso me impedirá de ativar os Jumbo Frames?
Se for esse o caso, aqui está o que eu faria (assumindo o equipamento de rede que pode lidar com isso):
- construa duas VLANs, uma com jumbo-frame e outra sem
- atribua todos os seus dispositivos de rede a uma vlan ou a outra
- no roteador e nos switches, implemente a jumbo frame vlan e altere o tamanho do quadro em qualquer cliente de rede.
Isso significa que você não terá mais uma topologia L2 plana na sua rede. Por exemplo, se do servidor habilitado para jumbo-frame que você deseja imprimir na impressora que não seja jumbo-frame, os pacotes precisarão ser roteados (viaje pelo roteador, os quadros reescritos em um tamanho mais convencional e depois enviados para o impressora na outra VLAN). Isso significa que a comunicação entre as máquinas de quadro jumbo e não-jumbo-frame será um pouco pior do que era antes, mas as taxas de transferência de dados entre todos os dispositivos na VLAN do jumbro-frame serão melhores. É realmente apenas um julgamento.
Quais são algumas das vantagens de ativar os Jumbo Frames?
Esperemos que coberto acima. Boa sorte!
Você pode encontrar o post de Jeff Atwood no Jumbo Frames informativo.
Destaques do post:
fonte
Você pode usar o ping.exe para verificar o tamanho máximo dos pacotes e compará-lo com as configurações dos Jumbo Frames.
Ajuste o tamanho do pacote usado por -l, e use -f para definir o sinalizador DO_ NOT_FRAGMENT. Quando você atinge o tamanho máximo de pacote, recebe a mensagem "O pacote precisa ser fragmentado, mas o DF está definido".
Isso fornecerá uma indicação se o Jumbo Frames funcionar ou não.
fonte
Sim, tudo deve suportar Jumbo Frames - trate-o como alternar entre token ring e ethernet. A única diferença é que alguns dispositivos ainda parecem funcionar por um curto período de tempo ou intermitentemente - isso também pode ser uma grande dor de cabeça se você não acompanhar quais dispositivos reconfigurou em uma rede grande (ou seja, duas semanas depois, você recebe uma problema de algum usuário com uma impressora recheada na parte traseira do cubículo que "agora" parou de funcionar). O mesmo se aplica a qualquer material novo - você precisará configurar um procedimento para reconfigurar todos os novos dispositivos e computadores com jumbo-frames, para evitar chamadas de suporte quando eles não funcionarem além da inicialização inicial.
fonte
No Linux, achei que funcionava o seguinte: Se você estiver usando vlans com tags, defina o mtu para o dispositivo base (por exemplo, eth1) para o tamanho do quadro jumbo. Todas as vlans que suportam jumbo-frames obtêm o mesmo mtu, as vlans que não ficam com o original, na maioria das vezes 1500.
Na verdade, as vlans que possuem jumbo falantes e comutação ativadas poderão enviar para a interface vlan local, mesmo que o mtu nessa vlan seja menor que o da interface base.
Também no linux, o comando para testar é: ping -s 4096 -M do
-s é o tamanho, -M diz "não fragmentar". Se você exceder o mtu local, você receberá um erro. Se você exceder o mtu remoto, não receberá nada de volta.
fonte