O que está acontecendo com esse estranho MTU?

Question

Eu tenho um microfone no nosso escritório comunicando-se com um servidor remoto através de uma VPN. Houve vários problemas que parecem estar ligados ao tamanho da MTU. Mike é um servidor RHEL 3 e o servidor cliente é o CentOS 5. Usei a ferramenta tracepath para tentar encontrar o MTU máximo e obtive esse resultado estranho

[root@mike root]# tracepath 192.168.1.4
 1:  mike (192.168.100.1)                                  0.170ms pmtu 552
 1:  mike (192.168.100.1)                                  0.011ms pmtu 552
 1:  mike (192.168.100.1)                                  0.010ms pmtu 552

snip - thousands of lines of the same output

 1:  mike (192.168.100.1)                                  0.025ms pmtu 552
 1:  192.168.100.252 (192.168.100.252)                        0.405ms
 2:  192.168.100.253 (192.168.100.253)                        0.876ms
 3:  192.168.1.4 (192.168.1.4)                         97.1000ms reached
     Resume: pmtu 552 hops 3 back 3

De outro servidor em nosso escritório para um cliente diferente, recebo um resultado muito mais razoável

[root@nora ~]# tracepath 192.168.2.1
 1:  nora (192.168.100.228)                                0.080ms pmtu 1500
 1:  192.168.100.253 (192.168.13.253)                      asymm  2   0.813ms
 2:  no reply
 3:  192.168.11.1 (192.168.11.1)                           73.210ms reached
     Resume: pmtu 1500 hops 3 back 3

Então, eu acho que é algo a ver com o microfone, em vez dos roteadores, firewalls ou VPN no meio. Alguma idéia?

Em resposta à resposta de Daniel Lawson abaixo, eis por que acredito que o problema é o microfone do servidor, pois a nora é capaz de obter a resposta correta

[root@nora ~]# tracepath 192.168.1.4
 1:  nora (192.168.100.228)                                0.101ms pmtu 1500
 1:  192.168.100.253 (192.168.100.253)                      asymm  2   0.863ms
 2:  no reply
 3:  192.168.1.4 (192.168.1.4)                        111.601ms reached
     Resume: pmtu 1500 hops 3 back 3

Em resposta ao comentário de Mike Pennington, os 192.168.100.252 e 192.168.100.253 são firewalls. O gateway padrão é 192.168.100.252, que então tem uma rota estática para que esses clientes enviem o tráfego para 192.168.100.253. Como eles estão na mesma rede, presumo que é por isso que a contagem de saltos não é incrementada.

    

Answer 1

Do que você disse, o caminho do servidor "mike" para um cliente é limitado a 552, e um caminho diferente, de "nora" para um cliente diferente, não é limitado.

Você não está comparando o mesmo caminho, então, a menos que haja mais informações, duvido que isso seja específico do servidor "mike". A PMTU é a MTU restrita ao longo do caminho, portanto, se isso fosse específico para o microfone, ela deveria acontecer com qualquer máquina que você traçasse.

Considerando que você está usando conexões VPN, não é surpresa que você esteja vendo uma PMTU restrita. Eu verificaria as configurações de MTU para a configuração da VPN para o primeiro cliente, e também tentaria verificar a MTU diretamente no ponto de extremidade da VPN do cliente (por exemplo, o endereço IP público que encerra a VPN). É provável que um ou outro tenha sua resposta.

    

Answer 2

É bastante comum em firewalls e VPNs de diferentes fornecedores. ponto de verificação para reduzir o MTU abaixo de 1500 para alguns tipos de tráfego.

    

Answer 3

Se você tem uma máquina Windows à mão, pode executar o mturoute no modo traceroute para determinar qual link / hop tem o MTU baixo.

link

    

Answer 4

Eu acho que o problema está relacionado ao zimbro não retornar um valor de MTU no pacote ICMP inacessível que faz parte do PMTUD. Eu já vi problema semelhante antes com zimbro