¿Por qué CLOS? El problema con las redes de tres niveles
La arquitectura de red tradicional de tres niveles (Core → Agregación → Acceso) nos sirvió bien durante décadas. Pero cuando el tráfico este-oeste explotó — impulsado por la virtualización, contenedorización y aplicaciones distribuidas — sus limitaciones se volvieron críticas:
- Sobresubscripción en agregación — el tráfico entre switches de acceso debe atravesar la capa de agregación
- Spanning Tree Protocol (STP) bloquea rutas redundantes, desperdiciando ancho de banda
- Escalar requiere reemplazo total — switches core más grandes, módulos linecard más costosos
- Latencia impredecible — diferentes rutas tienen diferentes conteos de saltos
La arquitectura CLOS (Leaf-Spine) elimina estos problemas por diseño.
Fundamentos de la arquitectura CLOS
En una topología Leaf-Spine:
- Cada switch leaf se conecta a cada switch spine — sin rutas bloqueadas
- Máximo dos saltos entre dos servidores cualesquiera — latencia predecible
- Agregar capacidad significa agregar switches spine — escalado horizontal
- ECMP (Equal-Cost Multi-Path) distribuye el tráfico a través de todas las rutas disponibles
Dimensionando su fabric CLOS
Las matemáticas son directas:
- Switches leaf: número de puertos uplink a spines = número de switches spine
- Switches spine: número de puertos downlink = número máximo de switches leaf
- Puertos de servidor por leaf: puertos restantes después de uplinks spine
Ejemplo: Un switch leaf con 48 x 10G downlinks y 6 x 40G uplinks se conecta a 6 switches spine, soportando hasta 48 servidores por leaf. Con 6 switches spine de 48 puertos cada uno, puede tener hasta 48 switches leaf — eso son 2,304 conexiones de servidor.
Principios de diseño de despliegues reales
Habiendo diseñado redes CLOS para entornos bancarios, estos son los principios que sigo:
1. Simule antes de desplegar
Use EVE-NG o GNS3 para construir una simulación completa de su fabric. Pruebe:
- Tiempos de convergencia BGP/OSPF
- Comportamiento de failover cuando un spine cae
- Distribución de tráfico bajo carga
- Plantillas de configuración en todos los switches
2. Elija su protocolo de enrutamiento
eBGP es el estándar moderno para fabrics CLOS:
- Cada switch obtiene su propio ASN
- Modelo de peering simple — leaf establece peering con todos los spines
- Dominios de fallo bien entendidos
- Usado por hyperscalers (Facebook, Microsoft, LinkedIn)
OSPF funciona para fabrics más pequeños:
- Configuración inicial más simple
- Convergencia más rápida en redes pequeñas
- Considere OSPF unnumbered para reducir la complejidad del direccionamiento IP
3. Estandarice todo
Cada switch leaf debe tener una plantilla de configuración idéntica. Cada switch spine debe ser idéntico. El poder de CLOS es su uniformidad. Use herramientas de gestión de configuración desde el primer día.
4. Planifique para el día 2
- Monitorización: utilización por puerto, estado de sesión BGP, distribución hash ECMP
- Automatización: zero-touch provisioning para nuevos switches
- Documentación: diagramas de topología actualizados automáticamente desde el estado de red
Estrategia de migración
Migrar de tres niveles a CLOS sin tiempo de inactividad requiere planificación cuidadosa:
- Despliegue la capa spine junto a los switches core existentes
- Migre los switches de acceso al rol leaf un rack a la vez
- Desplace el tráfico gradualmente usando métricas de enrutamiento
- Decomisione el core antiguo solo después de la validación completa
Este enfoque permite ejecutar ambas arquitecturas en paralelo durante el período de transición.
Puntos clave
CLOS no es solo para hyperscalers. Cualquier organización con 50+ servidores, tráfico este-oeste significativo o planes de crecimiento se beneficiará de la arquitectura Leaf-Spine. La complejidad inicial en la configuración de enrutamiento se compensa con la simplicidad operativa y el rendimiento predecible.
¿El paso más importante? Comience con la simulación. EVE-NG le da un entorno libre de riesgos para validar su diseño antes de tirar un solo cable.