Ir al contenido
Problemas y soluciones

Una sucursal va lenta y las demás no: cómo se aísla la causa

Tienes varias sedes con el mismo sistema, los mismos equipos y la misma forma de trabajar, y una de ellas se arrastra. Ese detalle es una ventaja enorme: cuando existe una sede sana, tienes un punto de comparación y el diagnóstico deja de ser adivinanza. Aquí está el orden para usarlo, qué medir en las dos a la misma hora, y cómo se comprueba cada hipótesis sin comprar nada por si acaso.

La sede sana es tu instrumento de medida

Cuando todo va lento, cualquier explicación parece razonable y se termina cambiando cosas al azar. Cuando una sola sede va lenta y las demás no, la mayoría de las hipótesis quedan descartadas antes de empezar: si el sistema central respondiera mal, respondería mal para todos; si el proveedor de la nube tuviera un problema, lo tendrían todos. Lo que queda tras esa criba es corto y concreto: el enlace de esa sede, el equipamiento de esa sede, el camino entre esa sede y el resto, o algo que solo ocurre ahí dentro. Cuatro familias. La única condición para que la comparación sirva es que las dos medidas se tomen igual: el mismo servicio, desde una computadora con cable, a la misma hora del día y con el mismo método. Comparar la sucursal a las once de la mañana con la central a las siete de la tarde no compara nada.

Diagnóstico comparado, paso a paso

Convierte «va lento» en un servicio y un número

Pregunta qué tarea concreta se hace pesada y cronométrala: abrir una factura en el sistema, guardar un archivo en la carpeta compartida, una videollamada que se corta. Cada una viaja por un camino distinto, y saber cuál duele te ahorra medir cosas que a nadie le importan. Anota cuánto tarda en la sucursal y cuánto en la sede sana.

Mide las dos sedes con el mismo método y a la misma hora

Desde una computadora conectada por cable en cada sede, toma la misma batería de medidas: tiempo de respuesta contra el sistema interno, caudal de subida y bajada, y pérdida de paquetes. Repite a media mañana y a media tarde. Si el problema solo aparece en franjas concretas, ya sabes que es carga y no avería.

Separa la salida a internet del tráfico entre sedes

Son dos caminos que la gente confunde todo el tiempo. Prueba un servicio público de internet y prueba un servicio que viva en la otra sede o en el centro de datos. Si internet vuela y el sistema interno se arrastra, el enlace de salida está bien y el problema está en el camino entre sedes o en el equipo que lo termina. Si ambos van mal, mira el enlace local primero.

Mide latencia, pérdida y fluctuación, no solo velocidad

Una prueba de velocidad puede dar bien mientras todo va mal. Lanza una medición sostenida contra el otro extremo durante varios minutos y observa el retardo típico, cuánto varía entre paquetes consecutivos y qué porcentaje se pierde. Las aplicaciones interactivas sufren por variación y pérdida mucho antes que por falta de caudal.

Comprueba si el enlace está lleno o si está roto

No es lo mismo. Un enlace saturado va bien de madrugada y mal a media mañana, y sus contadores de error están limpios. Un enlace degradado va mal siempre y acumula errores en el puerto. Mira el uso del enlace en promedios cortos y los contadores de error del puerto que lo termina; con eso separas las dos situaciones en cinco minutos.

Busca dentro de la sede lo que no debería estar ahí

Si el enlace no está lleno y el camino entre sedes está sano, la causa vive dentro. Sospechosos habituales: un lazo entre dos tomas que multiplica el tráfico, un puerto acumulando errores por un cable maltratado, un equipo enviando muchísimo tráfico él solo, o toda la sede saliendo por un único puerto lento hacia el rack.

La geometría del tráfico explica la mitad de los casos

En una empresa con varias sedes, un paquete puede tomar caminos muy distintos, y la lentitud suele estar en la elección del camino más que en la capacidad contratada.

  • Salida directa a internet desde la sucursal. El camino corto. Va tan bien como el enlace local.
  • Salida a internet a través de la sede central. El tráfico sube al túnel, sale por la central y vuelve. Duplica el recorrido y suma el retardo de dos enlaces. Es una decisión legítima por control y filtrado, pero pesa.
  • Acceso a un sistema que vive en la central. Depende por completo de la calidad del túnel, no del ancho de banda de internet.
  • Acceso a un servicio en la nube a través de la central. El peor de todos: sube, sale, llega y vuelve por el mismo camino.

Cuando una sucursal se queja de que la nube va lenta y las demás no, lo primero que hay que mirar no es el enlace: es por dónde sale. Basta un cambio hecho hace meses, o una ruta de respaldo que quedó activa tras una caída.

La comprobación es directa: consulta desde la sucursal cuál es tu dirección pública vista desde internet. Si coincide con la de la central, esa sede está saliendo por el camino largo.

Hipótesis, cómo se prueba cada una y qué se hace

  • Enlace lleno en horas pico: va bien temprano y mal a media mañana, sin errores en el puerto. Se resuelve con más capacidad o priorizando tráfico.
  • Enlace degradado: lento a cualquier hora y con errores creciendo en el puerto. Se escala al operador con fecha, hora y cifras.
  • Respaldo o sincronización de nube corriendo en horario laboral. Se reprograma fuera de horario o se limita su velocidad.
  • Salida a internet por la sede central sin necesidad. Se comprueba consultando la dirección pública desde la sucursal.
  • Túnel entre sedes mal dimensionado o con cifrado por encima de lo que el equipo procesa. Se compara el caudal dentro y fuera del túnel.
  • Resolución de nombres apuntando a un servidor de otra sede. Se resuelve con un servidor local o un reenviador cercano.
  • Ruta asimétrica: el tráfico va por un camino y vuelve por otro. Suele aparecer tras añadir un segundo enlace.
  • Lazo local entre dos tomas de pared: todos los puertos parpadean a la vez. Se corta y se activa la protección contra bucles.
  • Toda la sede saliendo por un puerto lento hacia el rack, o un equipo de seguridad pequeño para el caudal contratado.
  • Wifi saturado en esa sede concreta. Se prueba repitiendo la medida por cable: si por cable va bien, es cobertura.

Qué números separan un enlace sano de uno enfermo

Sin umbrales, «va lento» es una opinión. Estos son los que usamos al comparar dos sedes.

  • Retardo entre sedes dentro del país. Con fibra debe medirse en pocos milisegundos de ida y vuelta. Decenas de milisegundos entre dos puntos de la ciudad indican que el camino no es el que crees.
  • Variación del retardo. Para voz y video, por debajo de treinta milisegundos. Por encima, el audio se entrecorta aunque el promedio se vea bien.
  • Pérdida de paquetes. Por debajo del uno por ciento. Un dos o tres por ciento sostenido destroza lo interactivo y apenas se nota en una descarga grande.
  • Retardo total en una llamada. La referencia clásica es mantener el recorrido de un extremo al otro por debajo de ciento cincuenta milisegundos.
  • Uso del enlace. Por encima del setenta por ciento sostenido en promedios de cinco minutos, considéralo lleno: los picos instantáneos son bastante mayores.
  • Errores en el puerto. Un enlace sano no acumula errores de trama. Unos pocos por hora ya justifican revisar el cable o el transceptor.

Con estos seis números medidos en las dos sedes, la conversación con el operador cambia de tono: dejas de pedir que revisen y empiezas a mostrar un intervalo, un sentido y una cifra.

Cómo lo abordamos en una empresa con varias sedes

01

Línea base en todas las sedes

Antes de tocar nada se miden todas las sedes con el mismo método durante varios días. Sin línea base no hay forma de demostrar una mejora ni de detectar una recaída, y la mitad de las discusiones con el operador se ganan o se pierden en este punto.

02

Aislar por sustitución y por comparación

Se prueba la misma tarea desde otro puesto, por cable, en otro segmento y por otro camino de salida. Cada prueba elimina una familia de causas. El objetivo no es encontrar la culpa rápido, es reducir el problema a algo que se pueda cambiar y volver a medir.

03

Corregir lo que la medida señala, y solo eso

Si el enlace está lleno, se prioriza el tráfico que duele antes de ampliar capacidad. Si hay errores, se cambia el cable o el transceptor. Si el camino es el equivocado, se corrige la ruta. Comprar más capacidad para un problema de variación de retardo no arregla nada y cuesta todos los meses.

04

Dejar la sede vigilada

Un problema intermitente que nadie mide vuelve. Con monitoreo permanente de retardo, pérdida y uso por sede, la próxima vez el aviso llega antes que la queja. Eso es lo que hace [monitoreo de red y Network Guardian](/redes/monitoreo-de-red-y-network-guardian).

El tráfico invisible que llena el enlace de una sola sede

Muchas veces el enlace no es pequeño: es que alguien lo está usando para algo que nadie recuerda haber programado.

  • Respaldos en la nube corriendo de día. Un respaldo inicial de una sede completa satura la subida durante días. Se programan fuera de horario y se limita su velocidad.
  • Sincronización de carpetas en la nube. Una carpeta grande recién habilitada empieza a sincronizarse en todas las computadoras a la vez. Es la causa más frecuente de «se puso lento desde el lunes».
  • Actualizaciones del sistema operativo sin una caché local: cada computadora descarga lo mismo por su cuenta.
  • Un equipo con problemas enviando tráfico sin parar. Aparece de inmediato en la lista de mayores consumidores.

El orden correcto es medir quién consume antes de decidir. La lista de mayores consumidores de esa sede durante una hora pico responde la pregunta sin discusión. Y cuando el enlace es genuinamente pequeño, la conversación es de capacidad y de respaldo: lo tratamos en cuánto ancho de banda necesita mi empresa y en enlace de respaldo y failover.

Qué comprueba la sucursal y qué se decide en la central

Lo puede hacer alguien en la sucursal, hoy: cronometrar una tarea concreta y compararla con la otra sede, repetir la prueba por cable, medir a dos horas distintas, comprobar la dirección pública desde la que sale esa sede, y mirar si las luces del switch parpadean todas a la vez, que es la firma de un lazo local.

Se decide con visión de conjunto: cambiar el camino de salida a internet, redimensionar el túnel entre sedes, priorizar tráfico en el borde y negociar con el operador con datos en la mano.

Un aviso que ahorra dinero: antes de ampliar el enlace, demuestra que está lleno. Ampliar uno que no está saturado no cambia nada y el gasto se repite cada mes.

Sigue por aquí:

Preguntas frecuentes sobre una sede lenta

El operador dice que el enlace está bien. ¿Y ahora?

Probablemente tenga razón sobre su parte: mide su enlace hasta tu equipo de borde, y ese tramo puede estar perfecto mientras el problema vive dentro de tu red o entre tus sedes. Para avanzar, muéstrale medidas suyas: intervalo horario, sentido del tráfico, pérdida y retardo tomados desde el equipo que él entregó.

Mido la velocidad, sale bien, y la sede sigue arrastrándose.

Esa prueba mide caudal contra un servidor de internet cercano. Tu problema puede ser variación de retardo, pérdida de paquetes, o el camino hacia un sistema que no está en internet sino en otra sede. Mide retardo y pérdida sostenidos contra el destino real que te duele, no contra el servidor más cercano.

¿Cómo sé si el problema es el enlace o la red interna?

Repite la misma prueba desde dos puntos: uno conectado directamente al equipo de borde y otro en un puesto normal. Si en el borde va bien y en el puesto va mal, el problema es interno: cableado, switch, wifi o un equipo consumiendo. Si va mal en los dos, es el enlace o lo que hay más allá.

Todas las sedes usan lo mismo. ¿Puede ser el sistema central?

Si lo fuera, las otras sedes también lo sufrirían. Que solo una se queje es la mejor prueba de que el sistema está sano. Lo que sí puede pasar es que esa sede llegue por un camino distinto, con más saltos o por un túnel peor dimensionado.

Se puso lento desde el lunes y nadie tocó nada.

Alguien tocó algo, casi siempre sin saberlo. Los tres sospechosos habituales: una carpeta compartida grande que empezó a sincronizarse en todas las computadoras, un respaldo nuevo corriendo en horario laboral, o una actualización masiva descargándose puesto por puesto.

¿Sirve priorizar tráfico si el enlace está lleno?

Sirve para que lo importante siga funcionando mientras decides si amplías. Priorizar voz y el sistema de trabajo, dejando al final respaldos y descargas, cambia la percepción sin cambiar la capacidad. Lo que no hace es crear caudal.

Medimos las dos sedes antes de tocar nada

Con la línea base de la sede sana y la lenta, la causa aparece sola y el gasto se justifica con números.