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

25

Hola habitantes de la falla del servidor

Tengo un problema irritante con una LAN de aproximadamente 100 computadoras, 2 servidores de dominio de Windows y 12 teléfonos VoIP. Desde su instalación hace aproximadamente un año, cada semana más o menos, notamos que un teléfono VoIP se reinicia, ocasionalmente en medio de una llamada. Simultáneamente, a menudo hay signos de pérdida temporal de conexión en las computadoras: congelaciones 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 haciendo un monitoreo de Wireshark en la conexión entre la PBX VoIP y el resto de la red. Wireshark recoge un grupo de paquetes TCP retransmitidos en los momentos en que grabamos los reinicios del teléfono. El registro de Wireshark muestra alrededor de 2 grupos de retransmisiones al día que van desde 5 paquetes hasta cientos. Los que están en cada grupo se encuentran principalmente entre la central y algunos conjuntos de teléfonos VoIP, pero no siempre son el mismo conjunto. A menudo, las retransmisiones al mismo tiempo son a teléfonos conectados al mismo conmutador, pero a veces las retransmisiones ocurren juntas a teléfonos en extremos opuestos de la red. Por lo general, hay algunas retransmisiones coincidentes al pasar el tráfico TCP, por ejemplo, entre las máquinas cliente y los servidores de archivos.

Los picos en las retransmisiones y los reinicios del teléfono no se correlacionan bien con cuando la red está muy cargada. Parecen ocurrir un poco más durante el día, pero más en la noche, cuando el tráfico debería estar disminuyendo. Ocurren razonablemente a menudo a altas horas de la noche cuando la mayoría de las computadoras están apagadas y el tráfico debe ser más bajo.

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

networking tcp voip

— Surrealista
fuente

1

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

— Zypher

¿Qué protocolo de VoIP estás usando? Además, ¿usa UDP o TCP?

— Chris S

Todos los conmutadores son 3Com: Línea base 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 el procesador o la memoria, pero me complacería saber lo contrario. Sí, estamos en un dominio de difusión. No sé sobre el rendimiento, buscaré medirlo.

— Surrealista

17

Las retransmisiones de TCP generalmente se deben a la congestión de la red. Busque una gran cantidad de paquetes de difusión en el momento en que se produce el problema. Si el porcentaje de tráfico de difusión en su captura supera el 3% del tráfico total capturado, entonces definitivamente tiene congestión. Busque transmisiones de capa física (ARP) y de capa de red (resolución de nombre) en la red. Si encuentra un gran volumen de tráfico de difusión, puede rastrearlo a la fuente desde los datos de captura.

— joeqwerty
fuente

99

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

— joeqwerty

Debería haber mencionado que eché un vistazo a las transmisiones UDP y no se correlacionaron con las retransmisiones. Algunos de los eventos de retransmisión coinciden con picos en las transmisiones UDP, pero la mayoría no. He tenido otra mirada y descubrí que las transmisiones UDP no exceden el 1.5% del tráfico (alrededor de 350 paquetes) en cualquier segmento de tiempo de 10 minutos, y alcanzar ese nivel es raro. Sin embargo, no había mirado las transmisiones de Ethernet. Estoy ejecutando un script ahora para filtrar todos mis registros de Wirehark. ¿Es la regla general del 3% para las transmisiones UDP y las transmisiones Ethernet de forma individual o combinada?

— Surrealista

1

El 3% no es realmente una regla de oro. Es lo que me han dicho y lo que he visto en mi propio entorno. He escuchado números que van del 10 al 20%, pero descubrí que una vez que supera el 3 al 5%, generalmente causa problemas. Debe observar todo el tráfico de transmisión: Ethernet, red y transmisiones de multidifusión, ya que todas pueden causar congestión. Básicamente, cualquier tráfico que se transmite a todos los puertos del conmutador es tráfico que debe analizarse y reducirse o eliminarse.

— joeqwerty

Todavía no tengo un gráfico bonito para verificar una buena correlación durante un largo período, pero las transmisiones de Ethernet parecen bastante prometedoras. Un registro donde hubo retransmisión tenía poco más del 3% de transmisiones, otro alrededor del 6%. Al menos he encontrado un problema: un servidor antiguo está emitiendo un flujo constante de paquetes ARP gratuitos.

— Surrealista

1

Encontré las entradas ARP excesivas usando el filtro Wireshark de arp- y solo para ver las transmisiones, usando un filtro deeth.addr==ff:ff:ff:ff:ff:ff

— mlhDev

2

La recopilación de estadísticas de tráfico para sus conmutadores puede mostrar que tiene períodos en los que está funcionando a su capacidad o cerca de ella. Esto puede conducir a reintentos cuando las respuestas no regresan dentro del tiempo de espera inicial (a menudo 3 segundos). Esto aumenta la congestión momentáneamente hasta que se activan los mecanismos de mitigación de la congestión.

Busque personas que utilicen medios de transmisión, ya que pueden absorber el ancho de banda rápidamente.

Es posible que pueda mitigar el problema de los teléfonos mediante la configuración del tráfico. Esto solo moverá el problema a otros usuarios.

— BillThor
fuente

2

Suena como un bucle de árbol de expansión o una tormenta de transmisión para mí, especialmente si las retransmisiones y los problemas están localizados en el mismo interruptor (que difiere). Cuando sucede, ¿cuáles son los estados del puerto en su dispositivo L2? ¿Probablemente un mal cambio o malas prioridades del puente raíz? Interesante problema

— McJeff
fuente

Gracias por incitarme a leer sobre árboles que se extienden, sobre los cuales soy vergonzosamente ignorante. Sin embargo, no creo que pueda ser un bucle de árbol de expansión, porque no tenemos enlaces redundantes en nuestra red (posiblemente un problema en sí mismo). Por "estados de puerto en su dispositivo L2", ¿estoy en lo cierto, quiere decir qué puertos han habilitado los conmutadores como resultado del algoritmo de árbol de expansión? No hemos configurado manualmente un puente raíz, ¿sería una buena idea hacerlo?

— Surrealista

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

— joeqwerty

Sí, si no tienes enlaces redundantes, no sería un problema. Por estados de puerto, sí, me refiero a cuáles son de avance / bloqueo / aprendizaje.

— McJeff

2

Probablemente haya resuelto esto ya que ha pasado tanto tiempo, pero esencialmente necesita habilitar el "puerto rápido" en los puertos que tienen puntos finales (teléfonos voip, estaciones de trabajo, servidores). Un teléfono puede enviar PDU, por lo que si ese tipo se reinicia, provocará una convergencia de STP, lo que provocará que la tabla FDB se vacíe y que todos los dispositivos pasen por la diversión STP de 4/5 pasos. Al poner los puertos con punto final en "puerto rápido", se saltan la espera y pasan directamente al modo de reenvío.

— barak s.
fuente

1

¿Esperamos que sus teléfonos estén en una subred y VLAN diferentes de las otras computadoras?

— Greg Askew
fuente

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

— Surrealista

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

— Greg Askew

1

También podría ser un equipo defectuoso, como un interruptor defectuoso. ¿Las retransmisiones se correlacionan con teléfonos / computadoras en un conmutador en particular o parte de la red?

Solo para extender un poco mi respuesta. No todos los interruptores se crean de la misma manera, incluso si tienen las mismas especificaciones. Algunos pueden hacer frente a una carga mucho mayor que otros porque tienen procesadores más rápidos en su interior. Puede ser que sus interruptores no estén a la altura.

Comenzaría por poner algunos de sus teléfonos VOIP más problemáticos en su propio interruptor físico y ver si los reinicios continúan. Si desaparece, entonces estás en el camino para resolverlo muy pronto.

— Mate
fuente

Desearía que lo hicieran. Parece haber más problemas con los dispositivos conectados a dos conmutadores, que se encuentran en los extremos opuestos de la red. Sin embargo, también hay importantes retransmisiones a teléfonos en otras partes de la red.

— Surrealista