Dimensionar bien una red no consiste en mirar solo los megabits contratados. Hay que estimar cuántos dispositivos se conectan, qué aplicaciones usan, cuánto suben y descargan, y qué margen necesitas para picos, videollamadas o copias de seguridad. Saber calcular ancho de banda evita quedarte corto en hora punta y también pagar capacidad que nunca usas.
Lo esencial para dimensionar una red sin quedarte corto
- El ancho de banda es capacidad; el rendimiento real depende también de la latencia, el jitter y la congestión.
- La cuenta útil suma consumo simultáneo, no uso medio diario.
- Las videollamadas, las copias de seguridad y la voz sobre IP suelen revelar el cuello de botella antes que la navegación.
- Para tráfico con picos, el percentil 95 y el histórico de uso suelen ser más útiles que la media.
- Si el enlace es asimétrico, la subida puede agotarse antes que la bajada.
Qué estás dimensionando realmente
Yo suelo empezar separando tres ideas que se mezclan con facilidad: capacidad, rendimiento y latencia. El ancho de banda es la capacidad máxima que puede transportar la red en un momento dado; el rendimiento es lo que realmente pasa; y la latencia es el tiempo que tarda un paquete en llegar y volver. Cuando una conexión parece lenta, muchas veces el problema no es solo la capacidad, sino la suma de latencia, pérdida de paquetes y saturación puntual.Esta distinción importa porque una red puede tener un enlace “grande” y aun así ir mal si el tráfico es muy sensible al retardo, como ocurre con voz, videollamadas o aplicaciones en tiempo real. También importa en sentido inverso: un enlace modesto pero bien dimensionado y con poco tráfico concurrente puede funcionar mejor que uno más rápido, pero mal configurado o con demasiados picos. La conclusión práctica es sencilla: no dimensiono solo megabits, dimensiono comportamiento.
Con esa base clara, ya podemos mirar qué datos hacen falta antes de hacer una estimación seria.
Antes de calcular el ancho de banda que necesitas
La parte que más se subestima no es la fórmula, sino el inventario. Si no sabes quién usa la red, para qué y al mismo tiempo, cualquier cifra final será una apuesta. Yo intento reunir, como mínimo, estos datos:
| Dato | Qué debes mirar | Por qué cambia la cuenta |
|---|---|---|
| Usuarios simultáneos | Cuántas personas o dispositivos están activos a la vez | El consumo real se multiplica por concurrencia, no por número total de cuentas |
| Tipo de aplicación | Navegación, videollamadas, streaming, copias, VPN, cámaras | No consumen igual ni en la misma dirección |
| Subida y bajada | Qué parte del tráfico es de upload y cuál de download | La subida suele ser el cuello de botella en teletrabajo y backups |
| Horas punta | Cuándo se concentra el uso | La media diaria es engañosa si a las 10:00 todo el mundo se conecta a la vez |
| Overhead | VPN, cifrado, Wi-Fi, encapsulado y retransmisiones | Parte del enlace se pierde en cabeceras y eficiencia, no en carga útil |
Si además trabajas con enlaces compartidos o servicios críticos, añade una pregunta más: ¿qué pasa si hay un pico durante 10 minutos seguidos? Esa respuesta suele separar una red que “sale adelante” de una red que se cae por saturación. Con ese inventario ya puedes pasar a la parte numérica sin improvisar.
Fórmulas que sí sirven para estimar la capacidad
La fórmula más útil no es una sola, sino una combinación de tres piezas: consumo por servicio, número de flujos simultáneos y margen de seguridad. En forma simple, yo trabajo así:
Capacidad base = suma del consumo de cada servicio en uso simultáneo
Capacidad final = capacidad base × factor de overhead + margen
Como regla práctica, el overhead suele moverse entre un 15% y un 30% según haya VPN, Wi-Fi, cifrado y aplicaciones sensibles a paquetes pequeños. Para el margen, un 20% puede bastar en casa si el uso es estable; en entornos con trabajo intensivo, yo prefiero 25% o incluso 30%.
| Tipo de tráfico | Fórmula útil | Ejemplo rápido |
|---|---|---|
| Flujos continuos | Mbps por flujo × número de flujos | 4 videollamadas de 1,4 Mbps = 5,6 Mbps por sentido |
| Transferencias puntuales | Tamaño del archivo / tiempo disponible | 100 GB en 4 horas exige unos 55 Mbps sostenidos de subida |
| Tráfico por paquetes | Tamaño total del paquete × paquetes por segundo | La voz sobre IP no se mide solo por el códec |
| Consumo mixto | Suma de todos los servicios + overhead + margen | Es la fórmula que uso casi siempre en oficinas y hogares avanzados |
Un detalle útil: 1 MB/s equivale a 8 Mbps, así que conviene convertir siempre las cifras al mismo idioma antes de sumar. En una oficina pequeña, por ejemplo, una copia de seguridad de 100 GB en 4 horas ya consume alrededor de 55 Mbps de subida de media; si añades varias videollamadas y navegación normal, la cifra cómoda se acerca más a 80 o 100 Mbps sostenidos que a 50. Ese salto es justo el que mucha gente no ve hasta que la red empieza a ir al límite.
La cuenta cambia bastante cuando entran aplicaciones con patrones muy distintos, y ahí es donde conviene bajar al caso real.
Los escenarios que más cambian la cuenta
No todas las cargas pesan igual. Algunas apenas se notan en la media diaria, pero saturan la red cuando llegan en ráfagas; otras consumen poco, pero de forma continua. Cisco muestra en voz IP un buen ejemplo de esta trampa: el códec no basta por sí solo, porque el tamaño del paquete y los paquetes por segundo alteran el consumo real. En un escenario G.729, la llamada termina necesitando bastante más que los 8 Kbps nominales del códec cuando se suman cabeceras y encapsulado.
| Escenario | Qué domina | Rango orientativo | Qué suele fallar |
|---|---|---|---|
| Videollamadas 1:1 | Subida, bajada y estabilidad | ~54 kbps de audio o ~650 kbps de vídeo; en HD, alrededor de 1,4 Mbps | Jitter, pérdida de paquetes y Wi-Fi inestable |
| Copias en la nube | Subida sostenida | Depende del tamaño y del tiempo disponible | Saturar la línea durante horas |
| Cámaras IP y videovigilancia | Subida constante | Varía mucho según resolución y códec | Subestimar 24/7 y llenar el enlace con tráfico fijo |
| VoIP | Paquetes por segundo y overhead | Más alto de lo que sugiere el códec | Pensar que 8 Kbps siempre son 8 Kbps efectivos |
| Streaming y descargas | Bajada | Desde unos pocos Mbps hasta más de 20 Mbps por flujo | Olvidar que varios streams se suman muy rápido |
Mi lectura práctica es esta: si el problema es tiempo real, vigila la latencia y el jitter; si el problema es almacenamiento o backup, vigila la subida; si el problema es entretenimiento, vigila la bajada y la concurrencia. Esa clasificación te ahorra muchas estimaciones equivocadas y te lleva directamente al ajuste fino.
El margen que separa una red estable de una red frustrante
Cuando ya tienes una cifra base, no la cierro nunca sin margen. En una red doméstica sencilla suelo dejar un 15% o 20%; en teletrabajo serio o en una oficina pequeña, prefiero un 25% como mínimo; si hay backups, VPN o muchas videollamadas, me siento más cómodo con un 30% o incluso más. No es inflar por sistema: es absorber picos sin que la experiencia se vuelva irregular.
IBM suele recomendar mirar el percentil 95 para redes con picos ocasionales, porque representa mejor el comportamiento real que la media. A mí me parece una referencia útil cuando el tráfico tiene ráfagas cortas y quieres planificar sin sobrerreaccionar a un máximo aislado. Si un enlace está por encima del 80% de uso sostenido durante horas, yo ya empiezo a considerarlo frágil, aunque en las gráficas “todavía aguante”.
- Usa media solo como contexto, nunca como cifra de compra.
- Revisa el percentil 95 si el tráfico sube y baja con frecuencia.
- Separa subida y bajada; muchas redes fallan primero en upload.
- Reserva margen para el día malo, no para el día promedio.
- No olvides el hardware: router, firewall, AP y VPN también pueden limitar.
Con ese margen añadido, el cálculo deja de ser teórico y empieza a parecerse bastante a lo que la red va a soportar de verdad.
La cifra que yo usaría antes de ampliar o contratar un enlace
Si tuviera que quedarme con una sola regla de trabajo, sería esta: calcula el consumo simultáneo por servicio, añade el overhead real y después reserva un margen de seguridad de al menos un 20% o 25%. En redes con copias, videollamadas y varios usuarios, esa cifra suele ser la que evita el cuello de botella sin pagar de más.
También reviso siempre tres cosas que suelen quedar fuera de la primera estimación: si la subida soporta los picos, si el equipamiento de red puede procesar lo contratado y si la latencia mantiene una experiencia estable cuando todos se conectan a la vez. De poco sirve pagar más capacidad si el router o el punto de acceso se quedan cortos antes que la línea.
La forma más sensata de cerrar el cálculo, en mi experiencia, es empezar por el uso alto real, convertir todo a la misma unidad, añadir un margen conservador y validar durante unos días si el enlace se mantiene por debajo del 70% o 80% en hora punta. Si eso ocurre, la red suele tener espacio suficiente para crecer sin sorpresas.
