Configuración de Infraestructura de Red
Budget: $750 – $1,500 USD
Requerimiento de Técnico capacitado para configurar el equipamiento de red de acuerdo al detalle que figura a continuación:
Propuesta Técnica Completa – Laboratorio de Informática (VERSIÓN CORREGIDA)
1. Situación Actual
1.1 Infraestructura de Servidores
Dos servidores, clones y poseen:
• CPU: Intel Xeon E3-1225 (4c/4t – 3.2 GHz, sin hyper-threading)
• RAM: 32 GB
• Almacenamiento: SSD SATA (suficiente para la carga actual)
• Sistema Operativo: Windows Server 2016
• Rol: Host de sesiones para terminales NComputing (vSpace)
• Carga actual:
o 17/18 L300 NComputing por servidor (35 totales)
o Uso: navegación, multimedia, multitarea ligera/media
________________________________________
1.2 Redes
• Switch central con conexión directa a:
o Servidor 1 y 2
o L300
o AP UniFi
• Control: UniFi Controller
• Router disponible: MikroTik RB3011
• Topología actual: Switch → Módem ISP (router del ISP actuando como principal)
Problemas actuales:
• Conflictos de IP
• Pérdida de conectividad cuando la Wi-Fi masiva entra en carga
• Red plana sin segmentación
• Múltiples DHCP activos (Windows Server + módem ISP + AP UniFi)
• Broadcast storms y ARP saturado cuando hay 100+ clientes Wi-Fi
Diagnóstico General:
El problema no es hardware, sino diseño de red deficiente.
________________________________________
2. Diagnóstico Técnico
2.1 Servidores insuficientes para 35 L300 (se analiza su actualización / reemplazo en una tercera etapa)
• El Xeon E3-1225 tiene baja capacidad por hilo.
• Con 17 L300 por servidor está en el límite.
• No hay 30% de holgura.
• La ausencia de hyper-threading reduce aún más el rendimiento por sesión.
________________________________________
2.2 El problema de red NO es falta de equipos
Causas técnicas:
1. Múltiples DHCP simultáneos
→ superposición de rangos + duplicación de IP + ARP conflicts.
2. Una sola red para todo
→ 35 L300 + Wi-Fi masiva comparten broadcast domain.
→ Los 130 clientes Wi-Fi generan picos de ARP y DHCP que rompen al laboratorio.
3. El módem ISP no debe ser el router principal
→ carece de: VLAN, firewall granular, logs, limitación de broadcast, control DHCP.
Correc ción incorporada:
La raíz del problema es segmentación nula + gestión DHCP incorrecta.
________________________________________
3. Diseño Técnico Propuesto
3.1 Nuevo diseño de red
Topología recomendada:
Módem ISP (en modo bridge)
↓
MikroTik RB3011 ← Router principal, DHCP centralizado
↓
Switch central VLAN-aware
├── Servidor 1 (VLAN 10)
├── Servidor 2 (VLAN 10)
├── L300 (VLAN 20)
└── AP UniFi (VLAN 30/40)
Corrección incorporada:
Se agrega requerimiento de que el switch soporte VLAN 802.1Q (si no, debe ser reemplazado).
________________________________________
3.2 VLANs
• VLAN 10 – Servidores
• VLAN 20 – Laboratorio (L300)
• VLAN 30 – Wi-Fi Staff
• VLAN 40 – Wi-Fi Alumnos (masiva)
• VLAN 50 – Administración
Corrección incorporada:
Separación estricta entre Wi-Fi masiva y L300 para evitar interferencias.
________________________________________
3.3 DHCP centralizado (OBLIGATORIO)
El único DHCP activo debe ser el MikroTik.
• Rango por VLAN
• Lease-time corto en VLAN 40
• ARP=reply-only en VLAN 20/40
• DHCP snooping en el switch (si es compatible)
________________________________________
3.4 Access Points UniFi
• Cada SSID asignado a su VLAN
• Multicast/broadcast limitados
• L2 isolation para VLAN 40 (alumnos)
• Opción de portal o RADIUS (opcional)
________________________________________
3.5 Ajustes en servidores
• IP fija en VLAN 10
• Hardening básico: SMB, RDP, ACLs
• Mantener SSD, pero evaluar NVMe si se reemplaza hardware
• Verificar si vCAST está habilitado en vSpace para offload multimedia
________________________________________
4. Situación Futura Recomendada
4.1 Si se mantienen los L300
Con los servidores actuales (E3-1225):
• Máximo seguro: 12–15 L300 por servidor
• A 17 por servidor está SIN margen.
Si se requiere 30% de holgura:
• CPU moderna: Xeon E-2288G / E-2388G / Ryzen 5700G/7700
• RAM: 64 GB por servidor
• Disco: NVMe 1 TB (IOPS muy superiores al SSD SATA)
• NIC: 1GbE dual o ideal 10GbE hacia el switch
Corrección incorporada:
Se aclara que el bottleneck no es solo la CPU, sino también la latencia del SSD SATA, que escala mal con 30+ sesiones.
4.2 Si se reemplaza una cantidad de L300 por PC/Laptop
Escenario en Evaluacion
________________________________________
Conclusión
Los 4 problemas críticos que causan inestabilidad son:
1. Múltiples DHCP activos
2. Red completamente plana sin VLANs
3. Router del ISP actuando como router principal
4. Wi-Fi masiva compartiendo broadcast con los L300
Con el diseño propuesto:
• Eliminás las duplicaciones de IP
• Aislás tráfico crítico
• Bajás el ruido de ARP en el dominio de los L300
• Garantizás estabilidad para las 35 estaciones
• Podés escalar (más L300 o PCs) sin romper la red
Propuesta Técnica Completa – Laboratorio de Informática (VERSIÓN CORREGIDA)
1. Situación Actual
1.1 Infraestructura de Servidores
Dos servidores, clones y poseen:
• CPU: Intel Xeon E3-1225 (4c/4t – 3.2 GHz, sin hyper-threading)
• RAM: 32 GB
• Almacenamiento: SSD SATA (suficiente para la carga actual)
• Sistema Operativo: Windows Server 2016
• Rol: Host de sesiones para terminales NComputing (vSpace)
• Carga actual:
o 17/18 L300 NComputing por servidor (35 totales)
o Uso: navegación, multimedia, multitarea ligera/media
________________________________________
1.2 Redes
• Switch central con conexión directa a:
o Servidor 1 y 2
o L300
o AP UniFi
• Control: UniFi Controller
• Router disponible: MikroTik RB3011
• Topología actual: Switch → Módem ISP (router del ISP actuando como principal)
Problemas actuales:
• Conflictos de IP
• Pérdida de conectividad cuando la Wi-Fi masiva entra en carga
• Red plana sin segmentación
• Múltiples DHCP activos (Windows Server + módem ISP + AP UniFi)
• Broadcast storms y ARP saturado cuando hay 100+ clientes Wi-Fi
Diagnóstico General:
El problema no es hardware, sino diseño de red deficiente.
________________________________________
2. Diagnóstico Técnico
2.1 Servidores insuficientes para 35 L300 (se analiza su actualización / reemplazo en una tercera etapa)
• El Xeon E3-1225 tiene baja capacidad por hilo.
• Con 17 L300 por servidor está en el límite.
• No hay 30% de holgura.
• La ausencia de hyper-threading reduce aún más el rendimiento por sesión.
________________________________________
2.2 El problema de red NO es falta de equipos
Causas técnicas:
1. Múltiples DHCP simultáneos
→ superposición de rangos + duplicación de IP + ARP conflicts.
2. Una sola red para todo
→ 35 L300 + Wi-Fi masiva comparten broadcast domain.
→ Los 130 clientes Wi-Fi generan picos de ARP y DHCP que rompen al laboratorio.
3. El módem ISP no debe ser el router principal
→ carece de: VLAN, firewall granular, logs, limitación de broadcast, control DHCP.
Correc ción incorporada:
La raíz del problema es segmentación nula + gestión DHCP incorrecta.
________________________________________
3. Diseño Técnico Propuesto
3.1 Nuevo diseño de red
Topología recomendada:
Módem ISP (en modo bridge)
↓
MikroTik RB3011 ← Router principal, DHCP centralizado
↓
Switch central VLAN-aware
├── Servidor 1 (VLAN 10)
├── Servidor 2 (VLAN 10)
├── L300 (VLAN 20)
└── AP UniFi (VLAN 30/40)
Corrección incorporada:
Se agrega requerimiento de que el switch soporte VLAN 802.1Q (si no, debe ser reemplazado).
________________________________________
3.2 VLANs
• VLAN 10 – Servidores
• VLAN 20 – Laboratorio (L300)
• VLAN 30 – Wi-Fi Staff
• VLAN 40 – Wi-Fi Alumnos (masiva)
• VLAN 50 – Administración
Corrección incorporada:
Separación estricta entre Wi-Fi masiva y L300 para evitar interferencias.
________________________________________
3.3 DHCP centralizado (OBLIGATORIO)
El único DHCP activo debe ser el MikroTik.
• Rango por VLAN
• Lease-time corto en VLAN 40
• ARP=reply-only en VLAN 20/40
• DHCP snooping en el switch (si es compatible)
________________________________________
3.4 Access Points UniFi
• Cada SSID asignado a su VLAN
• Multicast/broadcast limitados
• L2 isolation para VLAN 40 (alumnos)
• Opción de portal o RADIUS (opcional)
________________________________________
3.5 Ajustes en servidores
• IP fija en VLAN 10
• Hardening básico: SMB, RDP, ACLs
• Mantener SSD, pero evaluar NVMe si se reemplaza hardware
• Verificar si vCAST está habilitado en vSpace para offload multimedia
________________________________________
4. Situación Futura Recomendada
4.1 Si se mantienen los L300
Con los servidores actuales (E3-1225):
• Máximo seguro: 12–15 L300 por servidor
• A 17 por servidor está SIN margen.
Si se requiere 30% de holgura:
• CPU moderna: Xeon E-2288G / E-2388G / Ryzen 5700G/7700
• RAM: 64 GB por servidor
• Disco: NVMe 1 TB (IOPS muy superiores al SSD SATA)
• NIC: 1GbE dual o ideal 10GbE hacia el switch
Corrección incorporada:
Se aclara que el bottleneck no es solo la CPU, sino también la latencia del SSD SATA, que escala mal con 30+ sesiones.
4.2 Si se reemplaza una cantidad de L300 por PC/Laptop
Escenario en Evaluacion
________________________________________
Conclusión
Los 4 problemas críticos que causan inestabilidad son:
1. Múltiples DHCP activos
2. Red completamente plana sin VLANs
3. Router del ISP actuando como router principal
4. Wi-Fi masiva compartiendo broadcast con los L300
Con el diseño propuesto:
• Eliminás las duplicaciones de IP
• Aislás tráfico crítico
• Bajás el ruido de ARP en el dominio de los L300
• Garantizás estabilidad para las 35 estaciones
• Podés escalar (más L300 o PCs) sin romper la red