☰

traceroute: às vezes os roteadores não respondem e o usuário vê tempos limite

tag-icon • tag-icon linux timeout rate-limiting icmp traceroute
traceroute: às vezes os roteadores não respondem e o usuário vê tempos limite

Sou administrador de uma pequena rede e estou investigando um problema do qual meus usuários reclamam. A raiz de suas reclamações é traceroute: às vezes, os roteadores ao longo do caminho simplesmente não respondem às traceroutesondagens e os usuários veem tempos limite (que *substituem o RTT).

A rede consiste em alguns roteadores Linux conectados por Ethernet/sem fio. Roteadores Linux 99% ociosos, utilização do link 20 mbit/s, 2.000 pacotes/s. Sem fio é sólido como uma rocha. O PING para todos os roteadores ao longo do caminho é de 10 ms, com alguma variação, é claro. O Flood PING para qualquer um desses hosts é executado por minutos sem qualquer perda de pacotes (e quero dizer 0 pacotes perdidos). Baixando alguns arquivos enormes pela rede: média de 10,2 MB/s.

O exemplocorreto traceroutese parece com isso:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.919 ms  3.866 ms  4.117 ms
 2  10.41.13.1  4.149 ms  6.714 ms  6.707 ms
 3  10.41.1.11  8.475 ms  8.468 ms  8.705 ms
 4  10.0.0.2  8.697 ms  9.428 ms  9.707 ms

Oproblemático traceroutefica assim:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.190 ms  3.140 ms  3.128 ms
 2  10.41.13.1  3.119 ms  3.113 ms *
 3  10.41.1.11  3.697 ms *  3.683 ms
 4  10.0.0.2  4.531 ms  4.524 ms  5.171 ms
# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.471 ms  3.405 ms  3.388 ms
 2  10.41.13.1  3.372 ms  3.359 ms  3.350 ms
 3  10.41.1.11  5.039 ms * *
 4  10.0.0.2  5.105 ms  5.484 ms  5.473 ms

Investiguei um pouco tcpdumpe descobri que traceroutefunciona assim:

  1. Inicialmente envia um monte de solicitações ICMP com TTL de 1, 2, 3, 4, 5, 6. Cada TTL é enviado 3 vezes. São 18 pacotes :)
  2. Aguarda algum tempo por todas as respostas ( Time Exceeded).
  3. Quando todas as respostas retornarem, mostre os resultados.
  4. ..ou aguarde o tempo limite e mostre os resultados com respostas ausentes marcadas com asteriscos.

E a causa dos tempos limite é: os roteadores recebem todas as três solicitações respectivas, mas às vezes não respondem, não enviam ICMP Time Exceeded.

Suspeito que existam algumas configurações que definem esse comportamento no roteador. Nomeadamenteicmp_ratelimit,icmp_ratemask,icmp_msgs_per_seceicmp_msgs_burst. Tudo descrito de alguma formaem documentos do kernel.org. E aqui está o ponto em que falhei. Não vim com nenhum valor dessas variáveis ​​para fazer o traceroutetrabalho funcionar o tempo todo.

Tentei configurar isso em todos os roteadores:

  • icmp_ratelimitdefinido como 0(não limite nada)
  • icmp_msgs_per_secdefinido como 10000(deve ser alto o suficiente)
  • icmp_msgs_burstdefinido como 5000(alto o suficiente)

Não me ajudou, vejo o mesmo comportamento, tempos limites aleatórios. Não mexi com icmp_ratemask, porque não entendo completamente como excluir Time Exceededda limitação.

Então, finalmente, perguntas:

  1. Se você está familiarizado com esse tipo de tracerouteproblema, como o resolveu?
  2. Se você estiver familiarizado com as configurações do kernel mencionadas acima, quais são os valores "bons o suficiente"?
  3. Qual a forma correta de modificar icmp_ratemaskpara não limitar Time Exceededas mensagens para que traceroutefuncione sem falhas?
  4. E mais: há alguma violação de segurança ao alterar essas configurações (ou outras relacionadas)? Não quero sofrer DoS nem ser fonte de ataque DDoS para ninguém.

Responder1

Como parte das políticas do plano de controle em saltos, as sondagens ICMP são geralmente ignoradas. Eu sugeriria uma instância dedicada ao fumo prematuro se você quiser ter dados históricos mais completos, em termos de métricas e tendências.

informação relacionada