Pérdida de paquetes de luz a través del enrutador

Pérdida de paquetes de luz a través del enrutador

Recientemente instalé una línea de fibra en mi oficina y, con la excepción de un pequeño problema que estamos teniendo, todo está funcionando bien y la respuesta de la red es realmente sorprendente.

El problema que tenemos es que de vez en cuando mi enrutador falla y suelta paquetes. No es la línea ni el interruptor. Es el enrutador en sí, cambié el hardware y ambas piezas lo hacen. El equipo que estoy usando es un Juniper Netscreen SSG5. Aquí están los síntomas:

Hago un pingflood a la interfaz "interna", con

 ping -f -c 10000 <internal-ip>

y obtengo 10.000 respuestas. Cada vez. Luego, haré lo mismo, excepto con la dirección IP de la interfaz externa (pero aún en el mismo dispositivo). Cae entre 10 y 15 paquetes de 10.000. Hice la misma prueba en todas las demás puertas de enlace de la empresa y nada más muestra este comportamiento. Estoy perplejo.

Hablé con el soporte de la compañía de fibra y nuestras dos interfaces están codificadas a 100 Mb con dúplex completo, si eso pudiera causar el problema. Por cierto, cuando hago ping a la interfaz exterior desde el interior del enrutador, nunca pierdo un paquete, lo que me hace pensar que no es la interfaz en sí. Y la interfaz local nunca pierde un paquete, por lo que no es el conmutador.

Honestamente, no estoy seguro de dónde podría radicar el problema, excepto en el diseño del hardware en sí. He observado los gráficos e incluso durante la inundación, no estoy ni cerca de maximizar la CPU o la memoria en el enrutador.

¿Alguna sugerencia?

Editar

Para Tom: La fibra es de 13 Mb/s, pero cuando hago ping a la interfaz, no cruza a la fibra. La LAN local funciona a 100 Mb/s y la interfaz interna responde a cada paquete. Tendré que ver si puedo tomar prestada otra pieza de hardware, pero tengo algunos modelos antiguos de Junipers (5GT) en diferentes sitios que no muestran los mismos síntomas.

Respuesta1

Tenga en cuenta dos puntos:

  1. Es probable que el enrutador acelere el tráfico ICMP dirigido a él, aunque no estoy familiarizado específicamente con el SSG5.
  2. Una velocidad de reenvío de 140 MBit/seg supone que el tráfico vaa través deel enrutador; tráfico dirigidoael enrutador causará un impacto adicional en el rendimiento, ya que cada paquete se pasará a la propia pila de IP del enrutador y requerirá que se genere un paquete de respuesta.

Un par de pruebas para probar:

  1. Intente hacer pingflooding desde su LANa través deel enrutador; ¿Quizás el extremo remoto del enlace WAN? (Supongo que será algo con más poder de procesamiento, si es propiedad de su proveedor de servicios).
  2. Correriperfentre un nodo en su oficina y algo externo en Internet, para tener una buena idea de en qué se le está formando.

Respuesta2

Sólo una idea... ¿Pero cuál es la velocidad de la fibra? ¿Puede la placa posterior del enrutador transferir paquetes a esa velocidad? Tuve un problema similar al llenar los buffers de Ethernet en un Cisco 857 maximizando las conexiones en los puertos del switch.

¿El SSG5 ejecuta la última versión de ScreenOS? ¿Últimas actualizaciones de firmware?
La especificación afirma que puede transferir 140 Mbit o 30 k paquetes por segundo. Puede que no sea así, pero ¿quizás un enrutador más robusto podría hacer frente al tráfico?
¿Podrías pedirle prestado a alguien un dispositivo más grande? ¿Quizás un Cisco 2811 o un Juniper J2320?

Respuesta3

Tuvimos problemas similares cuando cambiamos a fibra/metro Ethernet (AT&T).

¿Las interfaces de su enrutador muestran algún error? Usamos Cisco y veríamos CRC o errores de entrada, según la interfaz.

Finalmente lo resolvimos intercambiando diferentes métodos de negociación entre automático, 10/medio y completo, y 100/medio y completo, para cada una de nuestras ubicaciones, hasta que el modo automático o 100/completo se “atascó”. También puedes pedirle a tu proveedor que elimine temporalmente el límite de 13 Mbps para ver si hay un problema con la limitación de ancho de banda.

AT&T echó la culpa a los conmutadores que utilizaban (también a Cisco), pero no los cambiaría por modelos alternativos. Dejamos de preocuparnos siempre que dejáramos de recibir errores y funcionara al 100/completo (ya sea mediante codificación rígida o negociación automática).

Hasta el día de hoy, todavía tenemos algunas oficinas automáticas y algunas 100/completas, simplemente porque funcionó y no queremos estropearlo.

información relacionada