Como encontro um roteador mal configurado ou diagnostico tempos limite de solicitação intermitentes?

Question

Sou um programador de analistas na minha organização e estou encontrando algum tipo de problema de tempo limite intermitente ao usar solicitações de CVS e HTTP em nossa rede.

Após o tempo limite, a solicitação é concluída, mas leva pouco mais de 60 segundos, e é por isso que estou achando que é algum tipo de problema de failover por tempo limite.

Eu gostaria de tentar descobrir como encontrar, se possível, qual é o problema, suponho que há uma má rota sendo feita em algum lugar ou que há algo errado com um dos servidores DNS. A equipe de infra-estrutura me disse que não há nenhum problema com a rede, o que, pessoalmente, estou pensando, é uma desculpa.

Eu tenho acesso root a duas máquinas Linux (RHEL 5.4).

Por favor, desculpe-me se essa tarefa for óbvia, já que eu sou um desenvolvedor de software e não um engenheiro de rede.

UPDATE

Eu pensei que poderia mencionar que esse problema ocorre entre os clientes e o servidor CVS e os clientes que usam VPN e o servidor HTTP. Nossos clientes VPN não resolvem de maneira inversa e pedimos aos engenheiros de rede que recomendem isso, mas eles não veem isso como sendo um problema.

    

Answer 1

Muitas vezes os lugares estragam seus registros reversos. Você pode dizer que você errou registros reversos, porque se você executar algo como netstat -a e leva muito tempo para executar e você recebe um monte de endereços IP no rfc1918 espaço de endereçamento. Não ter registros reversos neste espaço, por si só, não é realmente um problema, mas é um problema se o seu pessoal DNS encaminhar suas solicitações de DNS para os provedores ou para um servidor DNS quebrado.

Uma maneira rápida de verificar se é um problema de DNS é fazer logon no sistema e procurar um IP de alguém conectado ao sistema (observe o netstat -a e procure por conexões estabelecidas) e, em seguida, execute

nslookup a.b.c.d (or whatever the IP of that host is)

se você tiver um sistema mais antigo, talvez seja necessário digitar

nslookup d.c.b.a.in-addr.arpa.

Em ambos os casos, o resultado pode ser algo como "não é possível encontrar esse endereço", mas a resposta precisa voltar rapidamente . Os tempos limite de DNS podem ser da ordem de segundos, e se você tiver 3 servidores DNS no seu resolv.conf, seu servidor tentará cada um deles antes que desista. Isso pode facilmente resultar em uma quantidade realmente irritante de tempo.

Uma maneira rápida de ilustrar o problema para seu chefe é executar netstat -an e, em seguida, executar netstat -a e, em seguida, dizer "se nosso DNS estivesse funcionando corretamente, ambos seriam executados quase exatamente na mesma quantidade de tempo.

Se for um problema de registro inverso, você provavelmente poderá "corrigir" o problema desativando as pesquisas inversas em seus aplicativos. Nesta situação, pode ser mais fácil do que envolver outro grupo.

Há também a possibilidade remota de haver uma incompatibilidade de duplex entre seus servidores e seus switches. Isso pode ser testado olhando para a saída de (windows) netstat -e ou (unix) netstat -i. Você está procurando por "erros" ou "colisões". Se você vir "colisões", seu final está mal configurado; é half duplex e deve ser full duplex. Se você vir "erros", a extremidade do comutador é half duplex e você é full duplex. Ambos os contadores devem ser zero, ou pelo menos pequenos e não aumentar. Esses problemas podem ser muito difíceis de rastrear porque o link funcionará muito bem se for descarregado e ficar totalmente desfeito quando houver muito tráfego.

    

Answer 2

Se a solicitação for concluída, não será um problema de tempo limite. Se fosse um problema de tempo limite, a solicitação nunca seria concluída, daí o nome "tempo limite". Você quer dizer que alguns pedidos terminam e alguns são completos depois de um longo período de tempo, porque isso faz mais sentido do que o que você declarou no seu post.

No que diz respeito a rastrear o problema, há muitas áreas para analisar. Aqui estão algumas sugestões para você começar:

Execute um tracert de uma máquina cliente para o servidor em questão. Conte quantos saltos ele atravessa. Cada hop é um roteador de algum tipo. Se o tracert for diretamente de sua máquina cliente para o servidor, não haverá roteadores no caminho.

Execute um caminho de uma máquina cliente para o servidor em questão e procure por latência e perda de pacotes entre os dois.

Instale um sniffer de pacotes no servidor e inicie uma captura. Envie uma solicitação do cliente e observe a saída do pacote sniffer no servidor. Se você vir um atraso significativo entre a solicitação e a resposta na saída do sniffer, será um problema no servidor. Se não houver atraso significativo, é um problema de rede.