Contadores de solução de problemas de MTU do Cisco Nexus
Contents
Introduction
Este documento descreve a configuração de MTU diferente e também discute cenários que envolvem o comportamento com combinações e enchimento diferentes.
Background
A fragmentação ocorre no caminho L3 não em L2
O preenchimento é basicamente usado para garantir que o cabeçalho do pacote IP tenha um comprimento que seja um múltiplo de 32 bits
Pré-requisito
Informações sobre preenchimento
- O remetente[iniciador] executará o preenchimento, dispositivos intermitentes[trânsito] não executarão o preenchimento
- O preenchimento não deve ser modificado quando um pacote passa pelo switch cut-through
- O switch considerará o pacote como um quadro de baixo tamanho se o originador não for capaz de fazer o preenchimento
- A captura do Wireshark ocorrerá antes do preenchimento
- Basicamente, o switch adicionará bytes extras mesmo que o tamanho do pacote que está prestes a enviar para o fio seja menor que 64B
- Quando um quadro Ethernet marcado de 64 bytes 802.1q é recebido sobre uma porta de tronco em um L2/L3 e é roteado/encaminhado para uma porta de acesso não rotulada, a tag 802.1q é reduzida e o tamanho do quadro é reduzido em 4 bytes
- Durante o processo de desmarcação de um quadro, o quadro não atende mais ao MTU mínimo de 64 bytes, conforme especificado na especificação IEEE 802.1q, o switch deve colar o quadro de volta para 64 bytes
Fragmentação e incompatibilidade de MTU
- Se Path for L3, a fragmentação ocorrerá, o pacote não será descartado.
- Se Caminho for L2, nenhuma fragmentação ocorrerá, o pacote será totalmente descartado
- Inicie [ICMP] com pacote tamanho 1540B e tem L2 no caminho ainda assim, você não vê as quedas, onde o tamanho total se torna 1568 [1540+20+8]
- Inicie [ICMP com ]packet-size 1541B, o pacote total se torna 1569, e você verá as quedas e as quedas são vistas como contadores Giants
- Se a diferença de MTU após os contadores aumentar - Jumbo, Giants, Runt, etc. com base no cenário e na configuração.
Topologia
9K = MTU 9K [Jumbo]
1,5K = MTU 1,5K + configurado como L2
A topologia acima do laboratório foi dividida em vários cenários da seguinte forma:
Troubleshooting de MTU usando o teste de ping
Ping com tamanho de pacote 1500
Iniciado ping e bem-sucedido com qualquer queda de ping.
Mesmo que tenhamos L2, não vemos a queda como o tamanho do ping tomado é 1500 padrão.
N5K-1# ping 10.1.1.2 count 10
PING 10.1.1.2 (10.1.1.2): 56 data bytes
64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=3.228 ms
64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=4.832 ms
Ping com tamanho de pacote 5000
Ping iniciado com o pacote tamanho 5000 com contagem de pacotes 50 do N5k1 para o Nexus-Sw2 e descartado no L2 de trânsito
N5K-1# ping 10.1.1.2 packet-size 5000 count 50
PING 10.1.1.2 (10.1.1.2): 5000 data bytes
Request 0 timed out
Request 1 timed out
Pacote considerado como Jumbo na entrada do Nexus-sw1
Nexus-Sw1# sh interface ethernet 3/3 | i MTU|jumbo
MTU 9216 bytes, BW 10000000 Kbit, DLY 10 usec
50 jumbo packets 0 storm suppression packets >>>>>>> exact 50 jumbo packets are seeing in the RX counter.
Pacote considerado como Jumbo na saída do Nexus-sw1
Nexus-Sw1# sh interface ethernet 3/1 | i MTU|jumbo >>>>>>> Intertace connected towards to N7k2 with MTU 1500
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
50 jumbo packets >>>>>>> Exact 50 jumbo packets are egress in the TX.
Pacote descartado na entrada do Nexus-sw2
Nexus-Sw2# sh interface et3/1 | i MTU|giant >>>>>>> Interface connected towards Nexus-Sw1 with e3/1 MTU 1500
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
0 runts 50 giants 0 CRC/FCS 0 no buffer >>>>>>> Exact 50 input error and 50 Giants packets observed in the RX counter.
50 input error 0 short frame 0 overrun 0 underrun 0 ignored
Nexus-Sw2# sh interface et3/4 | i MTU|giant|error >>>>>>> Interface with MTU 1500
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
0 runts 0 giants 0 CRC/FCS 0 no buffer >>>>>>> No counter seen
0 output error 0 collision 0 deferred 0 late collision >>>>>>> No counter seen
Feedback