Contornando os problemas ‘Path MTU Discovery’ com ajustes por rota MTU

15.6. Contornando os problemas ‘Path MTU Discovery’ com ajustes por rota MTU

Para envio pesado de dados, a Internet geralmente funciona melhor quando usando pacotes grandes. Cada pacote implica em uma decisão de roteamento, quando enviando um arquivo de 1 megabyte; isso tanto pode significar em torno de 700 pacotes quando usando pacotes que são tão longo quanto possível, quanto 4000 se usando o menor padrão possível.

Contudo, nem todas as partes da Internet suportam 1460 bytes completos de payload por pacote. Portanto, é necessário tentar e descobrir o maior pacote que se ‘ajustaria’, a fim de otimizar uma conexão.

Esse processo é chamado ‘Path MTU Discovery’, onde MTU significa ‘Maximum Transfer Unit’, ou seja, Unidade de Transferência Máxima.

Quando um roteador encontra um pacote que é demasiado grande demais em um pedaço, E está sinalizado com o bit “Don´t Fragment” – Não Fragmentar, ele retorna uma mensagem ICMP indicando que foi forçado a descartar um pacote por causa disso. O host que envia reage sobre essa sinalização enviando pacotes menores, e por interação ele pode descobrir o tamanho de pacote ótimo para uma conexão para determinado caminho.

Isso usava para funcionar bem até a Internet ser descoberta pelos hooligans que faz a melhor deles para romper as comunicações. Isso levou os administradores ao seu tempo a tanto bloquear como shapear tráfego ICMP em uma tentativa equivocada para melhorar a segurança ou a robustez dos seus serviços Internet.

O que acontece agora é que o ‘Path MTU Discovery’ está funcionando menos e menos bem e falha em certas rotas, o que conduz a sessões TCP/IP bizarras que morrem após um tempo.

Eu não tenho qualquer evidência disso, apesar de dois sites que eu usei para testar esse problema com dois Alteon Acedirectors antes dos sistemas serem afetados – talvez alguém mais conhecedor possa fornecer pistas a respeito de como isso acontece.

15.6.1. Solução

Quando você encontrar sites que sofrem desse problema, pode desabilitar o ‘Path MTU discovery’ configurando-o manualmente. Koos van den Hout, ligeiramente editou, escreve:

O problema seguinte: Eu definir o mtu/mru da minha linha contratada rodando o ppp a 296 porque ele é somente 33k6 e eu não consigo influenciar o enfileiramento no outro site. A 296, a resposta a um pressionamento de tecla está dentro de um quadro de tempo razoável.

E no meu lado, Eu tenho um masq-router rodando o Linux (claro!).

Recentemente, Eu dividir o ‘server’ e o ‘router’ e assim muitas aplicações estão rodando em uma máquina diferente daquela sobre a qual estava ocorrendo o roteamento.

Eu tive então problemas para entrar no IRC. Grande pânico! Alguns digging descobriram que Eu estava conectado ao IRC, mesmo assim Eu era mostrado como ‘conectado’ no IRC, não recebia a motd do IRC. Eu verifiquei o que poderia ser o problema e observei que Eu já tinha tido alguns problemas anteriores para alcançar certos websites relacionados ao MTU, já que Eu não tinha problemas para alcançá-los quando o MTU era 1500, o problema era exibido justamente quando o MTU era definido como 296. Como os servidores IRC bloqueia quase todo tipo de tráfego não necessário para suas operações imediatas, eles também bloqueia o ICMP.

Eu tratei de convencer os operadores de um webserver que esse era a causa de um problema, porém os operadores do servidor IRC não se preocuparam resolver isso.

Assim, Eu tive de assegurar que o tráfego mascarado sainte partisse com o MTU mais baixo a partir do link externo. Mas Eu desejava que o tráfego Ethernet local tivesse o MTU normal (para o tráfego de aplicações como o NFS).

Solução:

ip route add default via 10.0.0.1 mtu 296
(10.0.0.1 é o endereço do gateway padrão, o endereço interno do roteador que faz masquerade)

Em geral, é possível sobrescrever o ‘PMTU discovery’ configurando rotas especificas. Por exemplo, se somente certa sub-rede está dando problemas, isso deve ajudar:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

15.7. Contornando os problemas ‘Path MTU Discovery’ com MSS Clamping (para ADSL, cable, usuários PPPoE & PPtP)

Como explicado acima, o ‘Path MTU Discovery’ não funciona ou talvez não mais funcione. Se você souber de um salto em algum ponto de sua rede que possui um MTU limitado (<1500), você não deve confiar que o ‘PMTU Discovery’ possa descobrir isso.

Além do MTU, existe ainda um outro caminho para definir o tamanho máximo de pacote (MPU), o assim chamado Tamanho Máximo de Segmento. Isso é um campo na parte de opções TCP de um pacote SYN.

Os Kernels Linux recentes, e alguns drivers PPPoE (notadamente, aquele excelente Pingüim barulhento), caracteriza a possibilidade de ‘grampear o MSS’.

A coisa boa sobre isso é que definindo o valor MSS, você está dizendo ao lado remoto de maneira inequívoca ‘para tentar de fato enviar-me pacotes maiores do que esse valor’. Nenhum tráfego ICMP é preciso para conseguir fazer isso funcionar.

A coisa ruim é que isso provoca um seccionamento óbvio – ele quebra ‘fim a fim’ modificando pacotes. Dito isso, nós usamos isso dica em muitos lugares e funciona charmosamente.

A fim de fazer isso funcionar você precisa pelo menos do iptables-1.2.1a e do Linux 2.4.3 ou superior. A linha de comando básica é:


# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu

Isso calcula o MSS apropriado para o seu link. Se você estiver sentindo com coragem, ou acha que você conhece melhor, você pode também fazer algo igual a isso:


# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

Isso define o MSS que permite passar pacotes SYN com 128. Use isso se você tiver VoIP com pacotes diminutos, e pacotes http enormes que possa estar causando picotagem em suas ligações de voz.

15.8. O Mais Moderno Condicionador de Tráfego...

Autores Originais dos textos:

Bert Hubert (Netherlabs BV)
bert.hubert@netherlabs.nl

Thomas Graf (Autor de Seção)
tgraf@suug.ch

Gregory Maxwell (Autor de Seção)
greg@linuxpower.cx

Remco van Mook (Autor de Seção)
remco@virtu.nl

Martijn van Oosterhout (Autor de Seção)
kleptog@cupid.suninternet.com

Paul B Schroeder (Autor de Seção)
paulsch@us.ibm.com

Jasper Spaans (Autor de Seção)
jasper@spaans.ds9a.nl

Pedro Larroy (Autor de Seção)
piotr@member.fsf.org