tcptraceroute: Hop não responde

Question

AFAIK tcptraceroute é a melhor ferramenta para verificar se um firewall está bloqueando a conexão tcp a um serviço. (Se você conhece uma ferramenta melhor, por favor deixe um comentário)

Alguns saltos não respondem. Veja * * *

remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
 1  * * *
 2  172.18.56.12  0.407 ms  0.222 ms  0.230 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  10.102.1.1  32.017 ms  31.728 ms  31.486 ms
 8  * * *
 9  10.101.7.124 [open]  31.728 ms  32.391 ms  33.549 ms

Existe um termo para o comportamento desses saltos?

Como chamar isso, se o salto não responder e eu ver * * * na saída?

(Infelizmente eu não tenho 300 reputações e não posso criar a nova tag "tcptraceroute")

Antecedentes: gostaria de dizer às pessoas como são responsáveis pela rede, que devem usar roteadores que fazem o NOW-I-AM-MISSING-THE-MAGIC-TERM.

    

Answer 1

Não há realmente uma palavra exata para isso, mas para ajudá-lo com seu diálogo com aqueles que gerenciam essa rede, você pode olhar para o CoPP (Control Plane Policing)

É interessante notar que o dispositivo pode não estar definido para negar esses pacotes, pode ser apenas limitá-los. Portanto, se você quiser respostas, pode pedir que excluam determinados IPs do limite de taxa ou aumentem o limite para tudo se isso for desejado.

Vou avisá-lo que você pode ter dificuldade em fazer com que a equipe da rede faça essas alterações, pois elas estão lá para proteger o dispositivo contra ataques DoS ou sobrecarga de uso normal no plano de controle.

De documentos da Cisco , abaixo estão alguns dos efeitos que podem ser vistos se o plano de controle estiver sobrecarregado:

• Qualidade de serviço reduzida (como voz, vídeo ou dados críticos tráfego de aplicativos)
• Processador de rota alta ou utilização de CPU do processador de comutador
• Rota de rota devido à perda de atualizações de protocolo de roteamento ou keepalives
• Topologia de camada 2 instável
• Sessões interativas lentas ou sem resposta com o CLI
• Esgotamento de recursos do processador, como memória e buffers
• Quedas indiscriminadas de pacotes de entrada

Answer 2

Como já foi dito nos comentários, não há uma resposta real para isso (então eu me sinto um pouco bobo por digitar isso, mas seria muito longo para um comentário). O que você está vendo é apenas tcptraceroute dizendo que não obteve uma resposta do salto. Não há termo para isso, é apenas a maneira como o traceroute foi projetado. Quando o salto não responde ao pedido ICMP, você obtém uma resposta * , significando que nada foi retornado, portanto, uma resposta na forma de um tempo de resposta ping não pôde ser determinada.

Então, para chegar ao seu plano de fundo:

I would like to tell the people how are responsible for the network, that they should use routers which do NOW-I-AM-MISSING-THE-MAGIC-TERM.

Diga-lhes que eles devem ter seus roteadores bloqueando as solicitações do ICMP e pronto, eles entenderão o que você quer dizer com apenas algumas palavras. Também porque não é tanto um recurso, mas uma configuração. Então você não "usa roteadores que bloqueiam pedidos ICMP", você os instrui a fazer isso (pode ser a configuração padrão, mas é uma configuração, no entanto). As pessoas responsáveis pela rede devem saber disso.