Perda de pacotes leves através do roteador

1

Recentemente, instalei uma linha de fibra em meu escritório e, com exceção de alguns problemas que estamos tendo, as coisas estão funcionando bem e a resposta da rede é realmente incrível.

O problema que estamos tendo é que, de vez em quando, meu roteador se desconecta e solta os pacotes. Não é a linha e não é o interruptor. É o próprio roteador, e eu troquei o hardware, e as duas peças fazem isso. O equipamento que estou usando é um Juniper Netscreen SSG5. Aqui estão os sintomas:

Eu faço pingflood para a interface "interna", com

 ping -f -c 10000 <internal-ip>

e eu recebo 10.000 respostas. Toda vez. Então, farei o mesmo, exceto para o endereço IP da interface externa (mas ainda no mesmo dispositivo). Ele cai em algum lugar entre 10 e 15 pacotes de 10.000. Eu fiz o mesmo teste em todos os outros gateways da empresa e nada mais mostra esse comportamento. Estou perplexo

Falei com o suporte da empresa de fibra e ambas as nossas interfaces estão codificadas para 100Mb com full duplex, se isso puder causar o problema. Aliás, quando pingando a interface externa de dentro do roteador, eu nunca perco um pacote, o que me faz pensar que não é a interface em si. E a interface local nunca perde um pacote, então não é o switch.

Eu honestamente não tenho certeza onde o problema poderia estar, exceto com o design do próprio hardware. Eu observei os gráficos e, mesmo durante a pingflood, não estou nem perto de maximizar a CPU ou a memória no roteador.

Alguma sugestão?

Editar

Para Tom: A fibra é 13Mb / s, mas quando eu faço ping na interface, ela não está cruzando a fibra. A LAN local está funcionando a 100Mb / s, e a interface interna responde a todos os pacotes. Eu terei que ver se posso pegar emprestado outro hardware, mas eu tenho alguns modelos antigos de Juniper (5GTs) em sites diferentes que não mostram os mesmos sintomas.

    
por Matt Simmons 20.01.2010 / 11:11

3 respostas

2

Tenha em mente dois pontos:

  1. O roteador provavelmente reduzirá o tráfego ICMP direcionado para ele, embora eu não esteja familiarizado com o SSG5 especificamente.
  2. Uma taxa de encaminhamento de 140MBit / seg pressupõe que o tráfego está passando pelo roteador; o tráfego endereçado para o roteador causará um impacto adicional no desempenho, já que todo pacote será passado para a pilha IP do próprio roteador e exigirá que um pacote de resposta seja gerado.

Alguns testes para testar:

  1. Experimente pingar da sua LAN através do roteador; talvez o fim remoto do link WAN? (Eu estou supondo que isso será algo com mais poder de processamento, se pertencer ao seu provedor de serviços).
  2. Execute o iperf entre um nó em seu escritório e algo externo na internet, para ter uma boa ideia sobre o que você está sendo moldado para.
por 20.01.2010 / 14:45
0

Apenas uma ideia. Mas qual é a velocidade da fibra? O backplane do roteador pode realmente mudar os pacotes a essa velocidade? Eu tive um problema semelhante com o preenchimento dos buffers de ethernet em um Cisco 857, maximizando as conexões nos switchports.

O SSG5 está executando a última versão do ScreenOS? Últimas atualizações de firmware?
A especificação afirma que pode mudar 140Mbit ou 30k Pacotes por segundo. Então pode não ser isso, mas talvez um roteador mais robusto poderia lidar com o tráfego?
Você poderia pegar emprestado um dispositivo maior de alguém? Talvez um Cisco 2811 ou um Juniper J2320?

    
por 20.01.2010 / 11:17
0

Tivemos problemas semelhantes quando nos mudamos para fibra / metro-ethernet (AT & T).

As interfaces do seu roteador mostram algum erro? Usamos a Cisco e veríamos CRC ou erros de entrada, dependendo da interface.

Finalmente, resolvemos o problema trocando diferentes métodos de negociação entre auto, 10 / half e full, e 100 / half e full, para cada um dos nossos locais, até auto ou 100 / full "preso". Você também pode querer para solicitar que seu provedor remova temporariamente o limite de 13 Mbps, para ver se há um problema com a limitação de largura de banda.

A AT & T culpou os switches que eles usavam (também a Cisco), mas não os trocava por modelos alternativos. Paramos de nos preocupar desde que parássemos de receber erros e 100 / full trabalhado (seja por codificação ou negociação automática).

Até hoje, ainda temos alguns escritórios automáticos e alguns 100 / full, só porque funcionou e não queremos quebrá-lo.

    
por 21.01.2010 / 01:34