27 votos

Buscando la causa de la retransmisión de TCP dentro de una LAN

Hola habitantes de Server Fault

Tengo un problema irritante con una LAN de aproximadamente 100 computadoras, 2 servidores de dominio Windows y 12 teléfonos VoIP. Desde su instalación hace aproximadamente un año, cada semana aproximadamente, notamos que un teléfono VoIP se reinicia a sí mismo, a veces en medio de una llamada. Simultáneamente, a menudo hay signos de pérdida temporal de conexión en las computadoras: congelamientos en el explorador al acceder a recursos compartidos de red, errores en nuestro software de administración debido a la pérdida de conexión al servidor de la base de datos.

He estado monitoreando con Wireshark la conexión entre la PBX VoIP y el resto de la red. Wireshark detecta un grupo de paquetes TCP retransmitidos en los momentos en que registramos reinicios de teléfonos. El registro de Wireshark muestra aproximadamente 2 grupos de retransmisiones al día que van desde 5 paquetes hasta cientos. Aquellos en cada grupo son principalmente entre la PBX y algún conjunto de los teléfonos VoIP, pero no siempre es el mismo conjunto. A menudo las retransmisiones al mismo tiempo son para teléfonos conectados al mismo switch, pero a veces las retransmisiones ocurren juntas para teléfonos en extremos opuestos de la red. Usualmente hay algunas retransmisiones coincidentes en el tráfico TCP en tránsito, por ejemplo, entre las máquinas cliente y los servidores de archivos.

Los picos en las retransmisiones y reinicios de teléfonos no se correlacionan bien con el momento en que la red está muy cargada. Parecen ocurrir ligeramente más durante el día, pero más por la noche, cuando el tráfico debería disminuir. Ocurren con bastante frecuencia tarde en la noche cuando la mayoría de las computadoras están apagadas y el tráfico debería ser el más bajo.

¿Tienes alguna idea que pueda ayudar a diagnosticar la causa de problemas como este? Una cosa que aún no he intentado, pero debería haberlo hecho, es actualizar el firmware de todos los switches.

1 votos

¿Qué modelo de switches? ¿Cómo se ven las estadísticas de procesador, memoria, etc.? ¿Estás en un único dominio de broadcast? ¿Qué tan cerca del rendimiento máximo estás viendo en la red?

0 votos

¿Qué protocolo de VoIP estás utilizando? ¿También estás utilizando UDP o TCP?

0 votos

Todos los switches son de 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 plus (3C16476CS). No creo que proporcionen estadísticas sobre procesador o memoria, pero me encantaría saber si es así. Sí, estamos en un solo dominio de difusión. No sé acerca del rendimiento, investigaré cómo medirlo.

19voto

Russ Wheeler Puntos 173

Las retransmisiones de TCP suelen deberse a la congestión de la red. Busque un gran número de paquetes de difusión en el momento en que ocurra el problema. Si el porcentaje de tráfico de difusión en su captura es superior a aproximadamente el 3% del tráfico total capturado, entonces definitivamente tiene congestión. Busque tanto en la capa física (ARP) como en la capa de red (resolución de nombres) las difusiones en la red. Si encuentra un alto volumen de tráfico de difusión, puede rastrearlo hasta la fuente desde los datos de captura.

10 votos

Además, las retransmisiones TCP no son la causa de tu problema, son un síntoma del problema.

0 votos

Debería haber mencionado que eché un vistazo a las transmisiones UDP y no se correlacionaban con las retransmisiones. Algunos de los eventos de retransmisión coinciden con picos en las transmisiones UDP, pero la mayoría no. He vuelto a mirar y encontré que las transmisiones UDP no exceden el 1.5% del tráfico (alrededor de 350 paquetes) en ningún segmento de tiempo de 10 minutos, y alcanzar ese nivel es raro. Sin embargo, no había mirado las transmisiones Ethernet. Estoy ejecutando un script ahora para filtrar todos mis registros de wireshark. ¿La regla del 3% de las transmisiones UDP y las transmisiones Ethernet es individualmente o combinada?

1 votos

El 3% no es realmente una regla general. Es lo que me han dicho y lo que he visto en mi propio entorno. He escuchado números que van desde el 10 hasta el 20%, pero he encontrado que una vez que excede el 3 al 5%, generalmente causa problemas. Necesitas analizar todo el tráfico de difusión: ethernet, de red y difusiones multicast, ya que todos pueden causar congestión. Básicamente, cualquier tráfico que se difunda a todos los puertos del switch es tráfico que necesita ser analizado y reducido o eliminado.

2voto

BillThor Puntos 15761

Recopilar estadísticas de tráfico para tus switches puede mostrar que existen períodos en los que estás funcionando al límite de su capacidad. Esto puede llevar a reintentos cuando las respuestas no llegan dentro del tiempo de espera inicial (generalmente 3 segundos). Esto aumenta momentáneamente la congestión hasta que entren en acción los mecanismos de mitigación de congestión.

Busca personas que estén utilizando medios de transmisión en continuo, ya que esto puede absorber el ancho de banda rápidamente.

Puede que puedas mitigar el problema para los teléfonos mediante la configuración del tráfico. Esto simplemente trasladará el problema a otros usuarios.

2voto

McJeff Puntos 1651

Parece que para mí se trata de un bucle de árbol de expansión o de una tormenta de difusión, especialmente si las retransmisiones y los problemas están localizados en el mismo switch (que difiere). Cuando sucede, ¿cuáles son los estados de puerto en su dispositivo L2? ¿Probablemente un switch defectuoso o malas prioridades de puente root? Problema interesante.

0 votos

Gracias por recordarme que investigue sobre árboles de expansión, sobre los cuales estoy vergonzosamente ignorante. Sin embargo, no creo que pueda ser un bucle de árbol de expansión, porque no tenemos ningún enlace redundante en nuestra red (posiblemente un problema en sí mismo). Con "estados de puerto en su dispositivo L2", ¿quieres decir qué puertos tienen habilitados los switches como resultado del algoritmo de árbol de expansión? No hemos configurado manualmente un puente root, ¿sería una buena idea hacerlo?

0 votos

Familiarizarse con STP es una buena idea, pero si estás seguro de que no tienes enlaces redundantes, entonces STP no será el problema.

0 votos

Sí, si no tienes enlaces redundantes, no sería un problema. Por estados de puerto, me refiero a cuáles están en reenvío/bloqueo/aprendizaje.

2voto

barak s. Puntos 11

Probablemente ya hayas resuelto esto dado que ha pasado tanto tiempo, pero básicamente necesitas habilitar "port fast" en los puertos que tienen puntos finales (teléfonos VoIP, estaciones de trabajo, servidores). Un teléfono puede enviar PDUs, por lo que si ese tipo reinicia provocará una convergencia de STP, lo que a su vez causará que se elimine la tabla FDB y que todos los dispositivos pasen por la divertida etapa de 4/5 pasos de STP. Al poner puertos con puntos finales en "port fast", se saltan la espera y pasan directamente al modo de reenvío.

1voto

Greg Askew Puntos 17236

Esperemos que tus teléfonos estén en un subred y VLAN diferente de las otras computadoras?

0 votos

No, están en la misma subred de IP, y estoy bastante seguro de que también en la misma VLAN. ¿Es esto un problema serio? Ciertamente parece que sería una buena idea. Puedo ver que separaría los dominios de difusión para los teléfonos y todo lo demás. ¿Tendría alguna otra ventaja?

0 votos

Sí, definitivamente colocaría los teléfonos en una VLAN dedicada.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X