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
2 comentários
Excelente post.
Em alguns casos, precisamos mesmo alterar o MTU.
Exatamente @Plínio. Dependendo da situação que enfrentamos com a operadora ou até mesmo de algum equipamento interno.