Windows Updates y el tráfico en PYMEs

La empresita comenzó a crecer. Compraste una, dos, tres PCs y de golpe tenés 15 puestos de trabajo y el internet te está quedando chico.

Aumentás el ancho de banda y todo anda bien hasta que aparece una problema más común de lo que crees en redes chicas con equipos Windows:

Las descargas de Updates te saturan el ancho de banda!

Martes a la mañana, 15 máquinas bajando el acumulativo del mes al mismo tiempo, el ERP que no carga, la llamada de VoIP toda robotica y cortada y tu jefe preguntando «qué pasa con internet?». Te pasó?.

Esta semana me plantearon esto y saqué de la galera algo que vengo usando hace mucho tiempo en múltiples escenarios: QoS.

Te doy algunos tips en Mikrotik.

Escenario

Una PYME con un router Mikrotik (RouterOS 7) haciendo de gateway, una LAN con equipos Windows y un enlace de internet que se satura cada vez que Microsoft decide que es día de actualizar.

Identificamos el tráfico de Windows Update, lo marcamos y a una cola para que no se coma todo el enlace.

Paso 1: Identificando las URLs

Armamos una address-list con los dominios que usa Windows Update:

/ip firewall address-list
add address=download.windowsupdate.com list=WindowsUpdate_Servers
add address=update.microsoft.com list=WindowsUpdate_Servers
add address=delivery.mp.microsoft.com list=WindowsUpdate_Servers
add address=windowsupdate.microsoft.com list=WindowsUpdate_Servers
add address=windowsupdate.com list=WindowsUpdate_Servers
add address=download.microsoft.com list=WindowsUpdate_Servers
add address=wustat.windows.com list=WindowsUpdate_Servers
add address=ntservicepack.microsoft.com list=WindowsUpdate_Servers
add address=catalog.update.microsoft.com list=WindowsUpdate_Servers
add address=officecdn.microsoft.com list=WindowsUpdate_Servers
add address=tlu.dl.delivery.mp.microsoft.com list=WindowsUpdate_Servers

Ojo con esto: cuando cargás un FQDN en una address-list, Mikrotik lo resuelve con su propio DNS y va agregando las IPs dinámicamente respetando el TTL. Como Microsoft distribuye los updates por CDN, las IPs cambian todo el tiempo y no vas a atrapar el 100% del tráfico. Para una PYME alcanza y sobra, pero no es magia. Si querés afinar, usá el router como DNS de la LAN así lo que resuelve el cliente y lo que resuelve el router coincide.

Paso 2: Marcado de paquetes

Marcamos primero la conexión y después los paquetes de esa conexión. ¿Por qué en dos pasos? Porque marcar la conexión se evalúa una vez y después todos los paquetes (ida y vuelta) heredan la marca, lo cual es mucho más liviano para el CPU que evaluar la address-list en cada paquete.

/ip firewall mangle
add action=mark-connection chain=forward comment="Marca conexiones de Windows Update" dst-address-list=WindowsUpdate_Servers connection-mark=no-mark new-connection-mark=conn_updates passthrough=yes

add action=mark-packet chain=forward connection-mark=conn_updates new-packet-mark=packet_updates passthrough=no

Importante: si tenés FastTrack habilitado (viene en la config por defecto), las conexiones fasttrackeadas se saltean mangle y colas. O sea, configurás todo, no anda nada y te volvés loco. Excluí el tráfico marcado de la regla de fasttrack (o deshabilitala si el router está bien de recursos):

/ip firewall filter
set [find action=fasttrack-connection] connection-mark=!conn_updates

Paso 3: Creamos la cola simple

Acá armamos la cola y le aplicamos el limitador a los paquetes ya marcados.

/queue simple
add comment="Limita updates desde Microsoft para la red local" name=Limitador_Windows_Update target=192.168.88.0/24 max-limit=30M/30M packet-marks=packet_updates

Reemplazá 192.168.88.0/24 por tu LAN. El max-limit es subida/bajada desde el punto de vista del target. Listo, con esto los updates nunca van a pasar de 30 Mbps. Funciona, pero tiene un problema: si son las 3 de la mañana y el enlace está vacío, igual los updates van a 30M.

Desperdiciamos ancho de banda. Para hacerlo bien, hay que entender cómo funcionan las colas.

Cómo funciona: colas en Mikrotik

Todo el sistema de colas de RouterOS se apoya en HTB (Hierarchical Token Bucket). La idea: cada cola es un «balde» que se llena de tokens a cierta velocidad; para dejar pasar un paquete la cola tiene que tener tokens. Si no tiene, el paquete espera (o se descarta si el buffer se llena). Así se controla la velocidad. La documentación oficial está en Queues y HTB en el sitio de Mikrotik.

Simple Queue vs Queue Tree

• Simple Queues: se evalúan en orden, de arriba hacia abajo, y el paquete entra en la primera que matchea (por target, dst, packet-mark). Son fáciles, manejan subida y bajada en una sola regla, pero con muchas colas se vuelven pesadas para el CPU porque es una lista secuencial.
• Queue Tree: sólo trabaja con packet-marks (todo lo decide mangle), se cuelga de una interfaz o de global, y es unidireccional (una rama para bajada, otra para subida). Más laburo de configurar, pero es donde brilla la jerarquía y las prioridades.

Los parámetros que importan

• limit-at (CIR): la velocidad garantizada. Mientras la cola pida menos que esto, siempre la tiene.
• max-limit (MIR): el techo. Nunca pasa de acá, aunque el enlace esté vacío.
• priority (1 a 8, donde 1 es la más alta): acá está la trampa. La prioridad no significa «pasá primero siempre». Sólo decide quién se queda con el ancho de banda sobrante, una vez que todas las colas hijas recibieron su limit-at. Además sólo aplica en colas hoja (las que no tienen hijos).
• burst-limit / burst-threshold / burst-time: permiten superar el max-limit por un rato si la cola venía consumiendo poco. Útil para que la navegación «se sienta» rápida.
• queue (tipo de cola): define cómo se ordenan los paquetes dentro de la cola. pfifo/bfifo (fila de supermercado), sfq, pcq (reparte equitativamente entre IPs, ideal para que una sola PC no se lleve todo) y en RouterOS 7 también fq-codel y cake, que ayudan muchísimo contra el bufferbloat. (Si si, ya sé, es para un post aparte).

Regla de oro de HTB: la suma de los limit-at de los hijos no debería superar el max-limit del padre. Si no, estás garantizando ancho de banda que no tenés y la jerarquía se rompe.

Otra regla de oro: poné el max-limit del padre un 5-10% por debajo de lo que realmente te da el proveedor. El proveedor a veces no te entrega lo que dice, dejale un margen.

Haciéndolo bien: prioridades con Queue Tree

En vez de un techo fijo, le decimos al router: «los updates pueden usar todo lo que sobre, pero apenas alguien más necesite ancho de banda, se hacen a un lado». Suponiendo un enlace de 100M de bajada y la LAN en bridge:

/queue type
add kind=pcq name=pcq-bajada pcq-classifier=dst-address

/queue tree
add name=Bajada parent=bridge max-limit=92M
add name=Bajada_Resto parent=Bajada packet-mark=no-mark limit-at=80M max-limit=92M priority=4 queue=pcq-bajada
add name=Bajada_Updates parent=Bajada packet-mark=packet_updates limit-at=5M max-limit=92M priority=8 queue=pcq-bajada

¿Qué pasa acá? Los updates tienen garantizados 5M y el resto del tráfico 80M. Si nadie está usando internet, los updates pueden llegar a 92M (usan todo el sobrante). Pero apenas alguien empieza a navegar, el tráfico normal tiene prioridad 4 contra 8 de los updates, así que se queda con el excedente primero. Entonces… los updates vuelan de noche y se arrastran en horario pico, que es exactamente lo que queremos.

La cola cuelga de bridge (la interfaz LAN) porque la bajada sale del router hacia la LAN; las colas controlan tráfico de salida. Para la subida harías lo mismo colgando de la interfaz WAN, pero con updates el problema casi siempre es la bajada. Y si tenés VoIP, sumale otra hoja con priority=1 y un limit-at acorde a la cantidad de llamadas.

No mezcles: si usás Queue Tree con la misma marca, sacá la Simple Queue del paso 3, porque las simples se procesan antes y te van a pisar el comportamiento.

La otra alternativa: WSUS

Todo lo anterior es gestionar el síntoma. El problema de fondo es que cada PC baja el mismo update desde internet. Con 15 equipos bajás 15 veces el mismo acumulativo de varios cientos de MB. La solución clásica: WSUS (Windows Server Update Services). Un servidor en la LAN baja los updates una sola vez, vos aprobás cuáles se instalan y los clientes los toman de ahí a velocidad de LAN.

Y si hay algún equipo Windows dando vueltas por la oficina, puede cumplir el rol. Ahora, algunas aclaraciones:

• El rol de WSUS se instala en Windows Server (2016, 2019, 2022 o 2025). En Windows 10/11 sólo podés instalar la consola de administración, no el servidor. Así que ese «equipo que anda por ahí» tiene que tener un Windows Server licenciado.
• Microsoft anunció la deprecación de WSUS en septiembre de 2024. Ojo: deprecado no es discontinuado. Sigue incluido y soportado en Windows Server 2025 y sigue sincronizando updates, simplemente no le van a agregar funciones nuevas. Para una PYME sigue siendo perfectamente válido. Tenés más info acá Features removed or no longer developed in Windows Server.

Hardware recomendado

Según la documentación actual de Microsoft (Plan your WSUS deployment), los requisitos son:

• CPU: x64 de 1,4 GHz mínimo, 2 GHz o más recomendado.
• RAM: 2 GB adicionales a lo que ya pide el sistema operativo (la base de datos interna, WID, los necesita).
• Disco: 20 GB mínimo para los updates, 40 GB o más recomendado. Si vas a distribuir actualizaciones de versión de Windows 11 (UUP), sumá unos 10 GB por cada versión y arquitectura.
• Red: 100 Mbps mínimo, 1 Gbps recomendado.
• Base de datos: WID (Windows Internal Database) viene por defecto y para una PYME es más que suficiente. SQL Server sólo si vas a hacer balanceo de carga o ya tenés uno.
• Capacidad: un solo servidor WSUS puede atender hasta unos 30.000 clientes sincronizando cada 8 horas. Tus 15 PCs no le hacen ni cosquillas.

Para dimensionar según cantidad de equipos, la guía clásica de Microsoft (Determine WSUS Capacity Requirements, de la época de WSUS 3.0) proponía esta escala:

Esos números hoy quedaron cortos: los acumulativos de Windows 10/11 pesan muchísimo más que los updates de hace 15 años. Mi recomendación práctica para una PYME de hasta 100-200 equipos: cualquier máquina con un procesador de 4 núcleos, 8 GB de RAM (sumando lo que pide el propio Windows Server) y un SSD de 250 GB o más dedicado al contenido. Y la regla que más espacio te ahorra: aprobá sólo los productos, idiomas y clasificaciones que realmente usás y corré el asistente de limpieza del servidor seguido. Un WSUS que sincroniza «todo» se come un disco en semanas.

Después, por GPO (Configuración del equipo > Plantillas administrativas > Componentes de Windows > Windows Update) apuntás los clientes a http://servidor-wsus:8530 y listo.

¿Y si no tengo un Windows Server?

Plan C, gratis y sin servidor: Delivery Optimization. Es una función que ya viene en Windows 10/11 y permite que las PCs de la LAN compartan entre ellas los pedazos de updates que ya bajaron (tipo torrent). Por GPO configurás el modo de descarga en «LAN» (o «Group») y también podés limitar el ancho de banda que usa en primer y segundo plano. No es tan prolijo como WSUS, pero reduce bastante las descargas repetidas.

Conclusión

Lo ideal es combinar: WSUS (o Delivery Optimization) para no bajar 15 veces lo mismo, y QoS en el Mikrotik para que lo que sí se baje no le pise el pie al tráfico que importa. Y si te querés quedás con una sola cosa de este post:

La prioridad en las colas de Mikrotik reparte el sobrante, no el total. Entendido eso, el resto es jugar con los números.