MTU-Nextel-Problema

Equipe Monitoramento -

Problema:

O MTU exigido pela empresa NEXTEL em suas interligações é de 1600 bytes. O alarme acontecerá quando o MTU da interface “bridge-nextel”  não estiver maior do que 1600.

É necessário conferir as interfaces do equipamento com problema e verificar qual não está com os valores corretos.

MTU = 1610 (Para que o MTU possar estar como 1610, é necessário que L2MTU seja maior do que 1610)

L2MTU = 1620 (Em interfaces wireless, o L2MTU padrão é 2290 e não é possível altera-lo)

 

O que significa MTU ?

A Maximum Transmission Unit (MTU – unidade máxima de transmissão) é um parâmetro que determina a maior datagrama que pode ser transmitida através de uma interface de IP, sem precisar ser dividida em unidades menores. A MTU deve ser maior do que o maior datagrama que você quiser transmitir, sem ser fragmentado. (Mais simplesmente, a MTU define o tamanho máximo (em bytes) do pacote que pode ser transmitido de uma vez só). 

Para a Ethernet, este valor deve ser de 1500 bytes. 
Para as conexões em PPPoE, 1492 
Para o RTC (velocidade baixa), 576 

Fragmentação de IP e Remontagem

O protocolo IP foi desenhado para ser usado em uma ampla variedade de links de transmissão. Embora o comprimento máximo de um datagrama IP seja 64K, a maioria dos links de transmissão reforça um limite máximo de comprimento de pacote, chamado MTU. O valor de MTU depende do tipo do link de transmissão. O desenho do IP acomoda diferenças de MTU, permitindo que os roteadores fragmentem datagramas IP conforme necessário. A estação de recebimento é responsável por remontar os fragmentos de volta no datagrama IP de tamanho original normal.

A Fragmentação de IP envolve a fragmentação de um datagrama em vários pedaços que podem ser remontados posteriormente. A fonte, o destino, a identificação, o comprimento total e os campos de compensação de fragmentação de IP, juntamente com os flags “more fragments” (mais fragmentos) e “don’t fragment” (não fragmentar) do cabeçalho IP, são utilizados para fragmentação e remontagem de IP. Para obter mais informações sobre os mecanismos de fragmentação e remontagem de IP, consulte RFC 791 leavingcisco.com.

A imagem a seguir mostra o layout de um cabeçalho IP.

pmtud_ipfrag_01.gif

A identificação é de 16 bits e é um valor atribuído pelo remetente de um datagrama IP para ajudar na remontagem de fragmentos de um datagrama.

O deslocamento do fragmento é de 13 bits e indica a posição à qual o fragmento pertence no datagrama IP original. Esse valor é um múltiplo de oito bytes.

No campo de flags do cabeçalho IP há três bits para flags de controle. É importante observar que o bit “don’t fragment” (DF) desempenha uma função central na PMTUD, pois determina se um pacote pode ou não ser fragmentado.

O bit 0 é reservado e está sempre definido como 0. O bit 1 é o bit DF (0 = “may fragment” (pode fragmentar) 1 = “don’t fragment”). O bit 2 é o bit MF (0 = “last fragment” (último fragmento) 1 = “more fragments”).

ValorBit 0 ReservadoBit 1 DFBit 2 MF
0 0 Pode ser fragmentado Último
1 0 Não pode ser fragmentado Mais

O gráfico a seguir mostra um exemplo de fragmentação. Se você adicionar todos os comprimentos dos fragmentos IP, o valor excederá o comprimento original do datagrama IP em 60. O fato de o comprimento geral ter aumentado em 60 se deve à criação de três cabeçalhos IP adicionais, um para cada fragmento após o primeiro fragmento.

O primeiro fragmento tem um deslocamento de 0, o comprimento desse fragmento é 1500; isso inclui 20 bytes do cabeçalho IP original ligeiramente modificado.

O segundo fragmento foi um deslocamento de 185 (185 x 8 = 1480), o que significa que a porção de dados desse fragmento começa com 1480 bytes no datagrama IP original. O comprimento desse fragmento é 1500; isso inclui o cabeçalho IP adicional criado para esse fragmento.

O terceiro fragmento tem um deslocamento de 370 (370 x 8 = 2960), o que significa que a parte de dados desse fragmento começa com 2960 bytes no datagrama IP original. O comprimento desse fragmento é 1500; isso inclui o cabeçalho IP adicional criado para esse fragmento.

O quarto fragmento tem uma compensação de 555 (555 x 8 = 4440), que significa que a parte de dados desse fragmento começa com 4440 bytes no datagrama IP original. O comprimento desse fragmento é de 700 bytes; isso inclui o cabeçalho IP adicional criado para esse fragmento.

Apenas quando o último fragmento é recebido, o tamanho do datagrama IP original pode ser determinado.

O deslocamento no último fragmento (555) fornece um deslocamento de dados de 4440 bytes para o datagrama IP original. Se, em seguida, adicionar os bytes de dados do último fragmento (680 = 700 – 20), você obterá 5120 bytes, o que representa a porção de dados do datagrama IP original. Portanto, adicionar 20 bytes a um cabeçalho IP, igualará o tamanho do datagrama IP original (4440 + 680 + 20 = 5140).

pmtud_ipfrag_02.gif

Problemas de Fragmentação de IP

Existem vários problemas que tornam a fragmentação de IP indesejável. Quando um datagrama IP é fragmentado, ocorre um pequeno aumento na sobrecarga de CPU e de memória. Isso continua verdadeiro para o remetente e para um roteador no caminho entre o remetente e o receptor. A criação de fragmentos envolve simplesmente a criação de cabeçalhos de fragmentos e a cópia do datagrama original nos fragmentos. Essa tarefa é eficaz porque todas as informações necessárias para a criação dos fragmentos são imediatamente disponibilizadas.

A fragmentação resulta em sobrecarga para o receptor na remontagem dos fragmentos, pois o receptor precisa alocar memória para os fragmentos chegando e mesclá-los de volta no datagrama, depois que todos os fragmentos são recebidos. A remontagem em um host não é considerada um problema, porque o host tem recursos de memória e tempo para executar essa tarefa.

A remontagem, no entanto, é muito ineficiente em um roteador cuja função principal é encaminhar pacotes o mais rápido possível. Os roteadores não são desenhados para manter pacotes; nem que seja por um curto período. Além disso, um roteador que realiza remontagem escolhe o maior buffer disponível (18K) para trabalhar, pois ele só tem como saber o tamanho do pacote IP original quando o fragmento é recebido.

Outro problema de fragmentação envolve o tratamento de fragmentos descartados. Se um fragmento de um datagrama IP for descartado, o datagrama IP original inteiro deverá ser reenviado, e também será fragmentado. Você verá um exemplo disso com o NFS (Network File System). O NFS, por padrão, tem um tamanho de bloco de leitura e de gravação de 8192; portanto, um datagrama de IP/UDP NFS será de aproximadamente 8500 bytes (incluindo cabeçalhos NFS, UDP e IP). Uma estação de envio conectada a uma Ethernet (MTU 1500) terá que fragmentar o datagrama de 8500 bytes em seis partes; cinco fragmentos de 1500 bytes e um fragmento de 1100 bytes. Se algum dos seis fragmentos for descartado em razão de um link congestionado, o datagrama original completo precisará ser retransmitido, o que significa que mais seis fragmentos terão que ser criados. Se esse link descartar um dos seis pacotes, é pouco provável que algum dado NFS possa ser transferido por esse link, pois pelo menos um fragmento IP seria descartado de cada datagrama IP original de 8500 bytes do NFS.

Os firewalls que filtram ou manipulam pacotes baseados em informações da Camada 4 (L4) até a Camada 7 (L7) no pacote podem ter problemas para processar fragmentos IP corretamente. Se os fragmentos IP estiverem danificados, o firewall poderá bloquear os fragmentos não iniciais porque eles não carregam as informações que correspondem ao filtro de pacote. Isso significaria que o datagrama IP original não poderia ser remontado pelo host de recebimento. Se o firewall estiver configurado para permitir que fragmentos não iniciais com informações insuficientes sejam compatíveis com o filtro, poderá ocorrer um ataque de fragmento não inicial pelo firewall. Além disso, alguns dispositivos de rede (como Content Switch Engines) direcionam pacotes baseados nas informações de L4 a L7 e, se um pacote abranger vários fragmentos, o dispositivo pode ter problemas reforçando as respectivas políticas .

Tem mais dúvidas? Envie uma solicitação

0 Comentários

Artigo fechado para comentários.
Desenvolvido por Zendesk