Problema

En muchos homelabs la tendencia natural es añadir más nodos, discos y servicios sin replantear la arquitectura de red. El resultado típico es una red fragmentada donde:

  • Las VLANs se crean de forma ad‑hoc y los switches aplican reglas implícitas que el administrador no ve.
  • El firewall de capa 3 introduce reglas automáticas que generan “cajas negras” y hacen que el tráfico legítimo se pierda o se ralentice.
  • El ancho de banda de la WAN (por ejemplo 100 Mbps) se convierte en cuello de botella cuando los discos mecánicos intentan servir datos a alta velocidad.
  • La mezcla de diferentes sistemas de almacenamiento (TrueNAS, NAS viejo, discos SATA) sin una política de cache o tiering genera latencias inesperadas.

El síntoma más frecuente es una degradación progresiva del rendimiento y fallos intermitentes en servicios críticos (VMs, contenedores, backups) que aparecen cuando la red ya está saturada o cuando una regla de firewall oculta bloquea una ruta necesaria.

Causa

1. Segmentación de red sin planificación

Crear VLANs por nombre (VLAN10‑Management, VLAN20‑IoT, etc.) sin definir rutas estáticas ni políticas de aislamiento lleva a que el tráfico de gestión compita con el de datos. Los switches de capa 2 pueden reenviar broadcast a todas las VLANs si no se configuran correctamente los “tagged/untagged ports”.

2. Reglas de firewall implícitas

Muchos dispositivos (por ejemplo Unifi) añaden reglas “helper” o NAT dinámico que el administrador no ve en la UI. Cuando se migra a un router dedicado (MikroTik, pfSense) sin limpiar esas reglas, el tráfico que antes funcionaba queda atrapado en una cadena de “forward” que nunca se evalúa.

3. Desbalance entre capacidad de red y velocidad de discos

Los discos SAS de 7200 RPM entregan ~150 MB/s en lectura secuencial, pero una WAN de 100 Mbps solo permite 12 MB/s. Si la arquitectura depende de replicación remota o backups a través de la WAN, el disco se queda esperando, lo que se traduce en I/O elevado y latencia en la capa de aplicación.

4. Falta de cache o tiering

Al mezclar SSDs de alta velocidad con HDDs sin una capa de cache (L2ARC, ZIL) los workloads de escritura intensiva (descargas, transcodificación) terminan bloqueados en los discos lentos. El resultado es un “bottleneck” que se manifiesta como “high I/O wait” en las VMs.

Solución

1. Rediseñar la segmentación de VLAN

  1. Define un plano de direccionamiento IP por VLAN (por ejemplo 10.0.10.0/24 para Management, 10.0.20.0/24 para IoT).
  2. Asigna puertos de uplink como trunk en todos los switches y marca explícitamente las VLANs que deben pasar.
  3. Desactiva el flooding de broadcast en puertos que no forman parte de la VLAN correspondiente (storm-control broadcast level 10).
  4. Crea rutas estáticas en el router para cada subred, evitando el uso de protocolos dinámicos que puedan generar rutas inesperadas.

2. Implementar un firewall transparente y auditable

  1. Usa un router dedicado (MikroTik, pfSense) en modo bridge si deseas mantener la topología existente sin NAT.
  2. Desactiva todas las reglas automáticas y parte de cero.
  3. Crea una política mínima:
    • Permitir tráfico de gestión (SSH, HTTPS) solo desde la VLAN de Management.
    • Permitir tráfico de datos entre VLAN de Trusted LAN y Storage VLAN.
    • Bloquear todo lo demás y registrar los drops (log-prefix="DROP").
  4. Habilita el logging y exporta los logs a un syslog central para auditoría.

3. Balancear la capacidad de red y almacenamiento

  1. Introduce una capa de cache SSD frente a los discos SAS usando ZFS L2ARC y ZIL (o equivalente en TrueNAS).
  2. Configura un “burst” de 10 GbE entre los nodos de almacenamiento y el resto del clúster; mantén la WAN solo para backups externos.
  3. Planifica la replicación: usa rsync o ZFS send/receive con compresión y limitación de ancho de banda (--bwlimit=10M) para no saturar la WAN.

4. Automatizar la validación de la topología

  1. Desarrolla scripts de verificación que consulten la tabla de rutas (ip route show) y comparen contra un archivo de referencia.
  2. Integra pruebas de conectividad (ping, traceroute) entre VLANs críticas después de cada cambio de configuración.
  3. Utiliza herramientas de monitoreo (LibreNMS, Grafana) para visualizar el tráfico por VLAN y detectar picos anómalos.

Ejemplo de regla de firewall mínima en MikroTik

/ip firewall filter
add chain=forward src-address=10.0.10.0/24 dst-address=10.0.40.0/24 action=accept comment="Management → Trusted LAN"
add chain=forward src-address=10.0.40.0/24 dst-address=10.0.30.0/24 action=accept comment="Trusted LAN → Storage"
add chain=forward action=drop log=yes log-prefix="DROP"

Cuándo aplicar esta solución

Aplica cuando:

  • Tienes al menos dos VLANs y notas tráfico inesperado o caídas intermitentes.
  • El firewall actual muestra reglas que no reconoces o que cambian automáticamente.
  • Los backups o replicaciones a la nube tardan mucho más de lo esperado.
  • Los contenedores/VMs presentan alto I/O wait sin causa aparente.

No aplica si:

  • Tu red es monolítica (una sola subred) y no planeas escalar.
  • Usas exclusivamente dispositivos de consumo sin capacidad de VLAN o firewall avanzado.
  • El cuello de botella está en la CPU/GPU y no en la red o el storage.

Código

# Verificar puertos trunk en un switch Cisco (ejemplo)
show interface trunk

# Exportar tabla de rutas del router MikroTik a JSON para auditoría
/ip route export file=routes.json

Verificación

  1. Ping entre VLANs: ping -c 5 10.0.40.10 desde una máquina en Management.
  2. Revisar logs de firewall: busca entradas con log-prefix="DROP" para confirmar que solo se bloquea tráfico no deseado.
  3. Monitorear throughput en la interfaz 10 GbE con iperf3 -c <peer>; debería superar los 9 Gbps.
  4. Comprobar hit rate de cache en ZFS (zpool status -v) y asegurarse de que L2ARC está activo.

Notas adicionales

  • Cuando uses VLANs en switches de nivel 2, siempre configura PVID (Port VLAN ID) para los puertos de acceso; de lo contrario, los frames sin tag pueden terminar en la VLAN equivocada.
  • En entornos mixtos (TrueNAS + Proxmox) es recomendable usar iSCSI para los discos de VM y reservar los discos locales para datos de alta disponibilidad.
  • Si la WAN es inevitablemente lenta, considera deduplicación y compresión antes de enviar datos; ZFS send con -c o rsync --compress pueden reducir el tráfico en un 30‑50 %.
  • Mantén una copia de seguridad de la configuración del router (/export) antes de aplicar cambios masivos; restaurar es mucho más rápido que reconstruir reglas desde cero.