MTU – Gera lentidão, será?

Olá Pessoal,

  Nós já havíamos comentado sobre o pacote jumbro frame em um post anterior e como existem conceitos e configurações relacionados a este tópico, resolvi trazer um laboratório prático para demonstrar o funcionamento desse famoso MTU.

  Segue abaixo a topologia executada no GNS3. Neste laboratório estou utilizando o Cisco 2691 em conjunto com o IOS: c2691-advsecurityk9-mz.124-15.T14.bin. Para a conectividade serial o hardware adicionado foi a WIC-2T. Os arquivos do GNS3 podem ser obtidos na nossa seção arquivos.

  Nesse laboratório iremos mostrar como a mudança de um parâmetro, em algum ponto da rede, ou seja, na conexão entre a origem e o destino podem afetar a transmissão de pacotes através da Internet ou dentro de sua rede interna.

  Neste exemplo iremos fazer a alteração em um parâmetro, entre a conectividade Ethernet do PE1 com o roteador de BackBone. Lembrando-se, que quando esses parâmetros são alterados  na rede para habilitar um pacote jumbro frame, por exemplo, todo o caminho que irá encaminhar esse pacote deve aceitar a mesma definição para o MTU.

  Para efetuar o teste de conectividade entre os dois pontos, foi executado um ping da máquina ( 192.168.3.10 ) e do roteador CE1 para o roteador CE2 ( loopback – 192.168.5.1). Nesse teste a única forma de fazer com que o pacote, não seja fragmentado, seria através de um parâmetro que chamamos de DF-BIT. Esse parâmetro podemos habilitar normalmente através da CLI do roteador, ou através do DOS de seu computador.

  No primeiro teste foi executado o ping através desse comando:

CE1#ping 192.168.5.1 size 1401 df-bit

Type escape sequence to abort.
Sending 5, 1401-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

  Logo abaixo vocês podem observar o status capturado no WireShark, para qual apresenta o “request” do ping, com a flag “df” habilitada. 

  Devido ao tamanho do pacote ser maior que o permitido pelo MTU, recebemos uma mensagem de “unreachable”, ou seja, o pacote não foi transmitido devido a flag DF-BIT habilitada.

  Nesse outro teste envio um pacote de 1500bytes, sem nenhuma marcação do df-bit.

CE1#ping 192.168.5.1 size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 212/345/412 ms

  Nesse teste é colocado 1400bytes, porém com o parâmetro df-bit habilitado.

  Para um teste final, fizemos um ping com pacote de 8192bytes, liberando a fragmentação entre a origem e destino. 

  Essa configuração executada na interface Ethernet foi colocada como teste.

interface FastEthernet0/0
ip address 10.10.1.5 255.255.255.252
ip mtu 1400
duplex auto
speed auto

  Desta forma, podemos demonstrar que temos influências no meio de transmissão, quando trabalhamos com um pacote Ethernet e  com isso podemos responder a pergunta colocada no título de nosso post.

  Espero que vocês tenham gostado e aguardo comentários 🙂 . Se vocês acharem melhor, eu posso fazer uma vídeo aula para demonstrar todos os testes online. Fico no aguardo.

Abs,
Rodrigo

0
0

Link permanente para este artigo: https://ciscoredes.com.br/2012/02/27/mtu-gera-lentidao/

2 comentários

    • Plínio Monteiro em 14 de março de 2012 às 14:19
    • Responder

    Excelente post.

    Em alguns casos, precisamos mesmo alterar o MTU.

    0

    0
  1. Exatamente @Plínio. Dependendo da situação que enfrentamos com a operadora ou até mesmo de algum equipamento interno.

    0

    0

Deixe um comentário

Seu e-mail não será publicado.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Translate