Las redes de data center se dividen en dos funciones distintas: LAN Ethernet, que transporta aplicaciones, usuarios y tráfico IP, y SAN Fibre Channel, que transporta bloques de almacenamiento con requisitos rigurosos de pérdida, latencia y ordenamiento. Esta guía recorre la arquitectura spine-leaf, los enfoques Cisco ACI y Juniper EVPN-VXLAN para la LAN, el Fibre Channel con Cisco MDS y Brocade para la SAN, y cómo dimensionar, proteger y operar ambos.
Sobre este material: las capacidades citadas varían según modelo, versión de software, licencia, óptica, distancia y configuración. Valide siempre las matrices de compatibilidad y los documentos vigentes del fabricante antes de la adquisición o el cambio.
LAN y SAN: funciones diferentes
La LAN del data center usa Ethernet 10/25/50/100/200/400/800G según la plataforma, con VLAN/VRF para segmentación, VXLAN para escalar el overlay y BGP/OSPF/IS-IS en el underlay — transportando tráfico este-oeste, norte-sur, gestión, backup, storage IP y clústeres.
La SAN Fibre Channel es dedicada, con WWPN, zoning, name server, FSPF, ISL y VSAN/Virtual Fabric, operando caminos A/B independientes y multipathing en el host; FC-NVMe puede coexistir con FCP cuando es compatible de extremo a extremo.
RoCEv2, iSCSI y NVMe/TCP usan Ethernet para converger datos de storage y red, pero requieren un diseño propio de QoS, congestión, buffers, PFC/ECN cuando aplique, y aislamiento operativo — la convergencia exige cautela, no es un atajo automático.
Spine, leaf, ToR y border leaf
El fabric Clos reduce saltos, distribuye capacidad y permite una expansión horizontal predecible. El spine es la capa de alta capacidad: cada spine se conecta a todos los leafs y no recibe servidores directamente en el diseño estándar.
Leaf es la función en la arquitectura; ToR describe la posición física en el rack — un leaf puede ser ToR, middle-of-row o end-of-row. El border leaf hace la transición hacia WAN, Internet, firewalls, redes legadas, MPLS/EVPN u otro sitio, y debe dimensionarse para el tráfico norte-sur y las rutas externas. El service leaf conecta servicios como ADC, firewall, IDS/IPS, DNS y appliances — evite la inserción de servicios (service insertion) compleja sin observabilidad ni pruebas de simetría.
Topología LAN básica: dos spines y tres leafs
El patrón que elimina cuellos de botella comienza simple: cada leaf conectado a todos los spines, sin conexión directa entre leafs.
El tráfico este-oeste (servidor a servidor) cruza leaf-spine-leaf; con ECMP, múltiples caminos activos distribuyen los flujos. El tráfico norte-sur sale por un border leaf hacia firewall, WAN, Internet, balanceador o red legada. La pérdida de un enlace o spine reduce la capacidad, pero no debe interrumpir la conectividad — regla práctica: cada leaf debe tener al menos dos uplinks, uno hacia cada spine, con capacidad calculada en el peor caso N-1 y cableado, ópticas y MTU estandarizados en todo el fabric.
Topología LAN compleja: fabric corporativo redundante
Desde el borde hasta las cargas de trabajo, un fabric corporativo redundante elimina puntos únicos de falla en cada capa.
En este diseño, el underlay L3 usa adyacencias punto a punto, ECMP, BFD y direccionamiento /31 o unnumbered. El overlay VXLAN usa control plane BGP EVPN o, en el ACI, políticas distribuidas por el APIC. La capa de servicios — border leaf, service leaf, firewall, load balancer y gateways externos — debe ser redundante en cada uno de esos puntos.
Underlay, overlay y VXLAN
Separar la conectividad física de la conectividad lógica facilita la escala y la automatización. El underlay L3 usa enlaces enrutados leaf-spine con ECMP para múltiples caminos, BGP, OSPF o IS-IS según la arquitectura, BFD para detección rápida cuando es compatible, y MTU consistente, direccionamiento determinístico y sumarización cuando sea posible.
En el overlay VXLAN, los VTEPs encapsulan tramas/rutas en VXLAN; las VNIs representan segmentos L2 o VRFs L3, ampliando el espacio más allá de las VLANs. El BGP EVPN distribuye información MAC/IP y prefijos, reduce el flooding y habilita multihoming, anycast gateway y movilidad controlada. El tráfico BUM (broadcast, unknown unicast y multicast) exige política de replicación — monitoree el volumen y evite dominios L2 mayores de lo necesario.
Cisco ACI: arquitectura y objetos
El ACI transforma requisitos de conectividad en políticas aplicadas en el fabric Nexus 9000 y orquestadas por controladores APIC. El APIC es un clúster de controladores responsable del inventario, políticas, APIs, health score e integración; los spines y leafs Nexus 9000 realizan el reenvío distribuido en el fabric VXLAN; el Nexus Dashboard añade servicios operativos, visibilidad y orquestación según licenciamiento.
En el modelo de política, un tenant contiene VRFs, bridge domains y application profiles; los EPGs agrupan endpoints, y los contracts definen las relaciones permitidas entre EPGs. Los VMM domains, bare metal, L3Out, L2Out, service graphs y la conectividad multisite deben tratarse como bloques de diseño, no solo como objetos de GUI. El ACI no elimina los fundamentos de red: direccionamiento, routing, MTU, multicast, QoS, capacidad y dominios de falla siguen siendo esenciales.
ACI: flujo de política en lenguaje simple
La política parte de la intención de la aplicación y termina en reglas distribuidas en los leafs. Un ejemplo típico: tenant ENQ-PROD, VRF VRF-ERP, bridge domains BD-APP y BD-DB; EPG-APP contiene los servidores de aplicación, EPG-DB contiene las bases de datos, y un contract ERP-SQL permite solamente TCP/1433 de APP hacia DB.
Los endpoints se aprenden y se asocian al EPG; el gateway anycast puede existir en los leafs, y el contrato se aplica de manera distribuida. El L3Out conecta la VRF a routers o firewalls externos vía BGP/OSPF/rutas estáticas, con route control y políticas de importación/exportación. La gobernanza exige nomenclatura, plantillas, revisión por pares, versionado y pruebas — evite objetos huérfanos, contratos any-any y dependencia de configuración manual.
Cisco ACI: alta disponibilidad y escala
La disponibilidad debe considerar controladores, forwarding, servicios externos y operaciones. Planifique la cantidad y la distribución del clúster APIC según la escala soportada y el diseño del fabricante — un APIC fuera del quorum no debe interrumpir el forwarding ya programado, pero limita los cambios.
Los servidores y appliances pueden usar vPC para redundancia L2; valide LACP, orphan ports, hashing, consistencia y el comportamiento del equipo conectado. Multi-Pod extiende un único fabric con IPN; Multi-Site coordina fabrics independientes — la elección cambia el blast radius, la latencia, la operación y la recuperación. Para actualizaciones, lea las release notes, la matriz de compatibilidad y las rutas de upgrade, y realice pre-checks, backup de configuración, validación de faults y plan de rollback.
Juniper: fabric EVPN-VXLAN
En el enfoque Juniper, el QFX opera el fabric IP y el BGP EVPN provee el control plane del overlay; el Apstra puede añadir intención, validación y automatización. Los switches QFX fijos o modulares actúan como leaf, spine, border y super-spine según la escala; el Junos OS aporta routing policy, EVPN, VXLAN, telemetry y automatización; el Apstra ofrece diseño intent-based, blueprints, assurance y operación multivendor según soporte.
Los modelos EVPN incluyen VLAN-based, VLAN-aware bundle o VLAN bundle — la elección afecta la escala, el aislamiento y la operación; Type 2 anuncia MAC/IP, Type 5 anuncia prefijos IP. El EVPN multihoming usa Ethernet Segments y DF election, reduciendo la dependencia de MLAG en diseños compatibles. IRB y anycast gateway acercan el enrutamiento a las cargas de trabajo, reducen el hairpin y soportan movilidad dentro de los límites del diseño.
Juniper: diseño y operación
Un fabric basado en estándares ofrece flexibilidad, pero exige políticas BGP y automatización disciplinadas. eBGP en el underlay es común por la simplicidad de política y aislamiento; iBGP con route reflectors también es posible — el overlay EVPN necesita address families y políticas consistentes.
El Routing Type 5 permite anunciar prefijos IP independientemente del MAC, útil para servicios L3, border leaf y DCI. Para la interconexión entre data centers, evite extender L2 sin necesidad — compare EVPN DCI, inter-VRF routing, firewalls y replicación de la aplicación, ya que la latencia y el dominio de falla importan más que la conveniencia. El Assurance del Apstra valida cables, adyacencias, ASN, loopbacks, VNIs, VLANs, IRBs, policies y endpoints contra el blueprint antes y después de cada cambio.
Cisco ACI vs. Juniper EVPN-VXLAN
Son dos enfoques maduros, con operaciones diferentes. El ACI es un fabric basado en políticas (policy-based) con APIC sobre hardware Nexus 9000, donde el APIC mantiene la intención y las políticas, la segmentación usa tenant/VRF/BD/EPG/contract, el gateway es anycast/distributed en el leaf, la operación se centra en GUI/API sobre objetos ACI, y el multisite pasa por el Nexus Dashboard Orchestrator — la elección favorece a quien quiere el ecosistema ACI y una gobernanza integrada.
El Juniper EVPN-VXLAN es un fabric basado en estándares (standards-based) con BGP EVPN sobre QFX en Junos OS/Apstra, donde el BGP distribuye MAC/IP y rutas EVPN, la segmentación usa VRF/VLAN/VNI y políticas de firewall, el gateway es IRB anycast en el leaf, la operación se centra en CLI/API/automatización sobre EVPN, y el multisite pasa por EVPN DCI, Apstra y un diseño específico — la elección favorece la adherencia a estándares y la flexibilidad. No existe un ganador universal: la decisión debe ponderar equipo, automatización, soporte, interoperabilidad, costo total, roadmap y requisitos de seguridad.
Dimensionamiento de la LAN
Dimensionar significa transformar perfiles de tráfico en puertos, uplinks, buffers, ópticas, energía y margen de crecimiento. La oversubscription es la relación entre la capacidad de puertos de servidores y los uplinks del leaf — por ejemplo, 48 puertos de 25G suman 1,2 Tb/s, contra 6 uplinks de 100G que suman 600 Gb/s, una oversubscription nominal de 2:1.
En el escenario N-1, verifique si, con la pérdida de un spine o uplink, la capacidad restante atiende el pico aceptable — no use solamente el promedio diario. Los perfiles de tráfico difieren: la virtualización genera muchos flujos y movilidad, con foco este-oeste; el storage IP/RoCE trae microbursts, pérdida, latencia y congestión; la IA/HPC produce elephant flows, all-reduce, rail optimization y el job completion time como métricas centrales. Para ópticas y distancia, valide velocidad, breakout, FEC, tipo de fibra, potencia óptica, alcance, temperatura y compatibilidad del fabricante.
Topología SAN básica: dual fabric A/B
Dos redes independientes hasta cada controladora es el diseño de referencia de la SAN corporativa.
El aislamiento es real: el fabric A y B no tienen ISL entre sí, por lo que las fallas y los cambios permanecen contenidos en un fabric. El multipathing (MPIO) elige caminos y reacciona ante la pérdida de HBA, enlace, switch, puerto o controladora. Para el zoning, prefiera single-initiator/single-target o single-initiator/multi-target, según el estándar del array.
Fibre Channel: conceptos esenciales
FC es una red orientada a pérdida mínima y entrega confiable, con mecanismos propios de login, nombres, enrutamiento y control de flujo. En identidad, el WWNN identifica el nodo, el WWPN identifica el puerto, y el FCID se asigna tras el login en el fabric — documente los tres en el troubleshooting.
En los logins, FLOGI registra el puerto en el fabric, PLOGI crea la sesión entre puertos, y PRLI negocia el protocolo superior, como FCP o FC-NVMe. En el enrutamiento y control de flujo, el FSPF calcula caminos, y los buffer-to-buffer credits limitan cuántos frames pueden enviarse sin confirmación de buffer disponible. Los ISLs unen switches del mismo fabric; el trunking agrega enlaces compatibles — la distancia y el RTT pueden exigir créditos adicionales.
Cisco MDS: VSAN, zoning y operación
El Cisco MDS 9000 usa NX-OS y ofrece segmentación por VSAN, zoning, port-channels FC y telemetría, según modelo y licencia. La VSAN crea fabrics lógicos independientes sobre la infraestructura física compartida — cada VSAN posee servicios y FSPF propios, y debe usarse conscientemente para el aislamiento.
En el zoning, el modo puede ser basic o enhanced según la gobernanza; los aliases/device aliases reducen errores, y los zonesets deben activarse en la VSAN correcta — Smart Zoning puede reducir entradas de hardware en escenarios compatibles. El port-channel FC agrega ISLs compatibles, mejorando la utilización y la resiliencia; verifique velocidad, trunking, VSANs permitidas y consistencia. Para OAM, Cisco SAN Analytics/telemetry, syslog, SNMP, Call Home y dashboards ayudan a encontrar congestión, slow drain y errores físicos.
Brocade: Fabric OS y buenas prácticas
Brocade ofrece switches y directores Fibre Channel con Fabric OS, zoning, trunking, virtual fabrics y Fabric Vision, según plataforma y licencia. Virtual Fabrics usa logical switches para separar entornos y servicios — defina FIDs, base switch e inter-fabric routing solo cuando el caso lo requiera.
En el zoning, use aliases consistentes, zone configurations versionadas y peer zoning cuando corresponda; los cambios deben ser pequeños, revisados y reversibles. El ISL Trunking agrupa enlaces compatibles en trunks para el balanceo a nivel de frame — confirme licencia, distancia, ópticas y requisitos de port group. El Fabric Vision reúne métricas, MAPS, Flow Vision y diagnósticos para detectar degradación, congestión y dispositivos slow drain, según soporte/licencia.
Topología SAN compleja: core-edge con directores
Escalar la SAN exige dominios de falla bien definidos e ISLs calculados, no solo más puertos.
Las reglas de diseño centrales: separe el fabric A y B en switches, alimentación, patch panels, rutas físicas y dominios administrativos; dimensione los ISLs por el pico simultáneo, distancia, compresión, créditos de buffer y escenario N-1; evite fabrics excesivamente grandes, limitando el blast radius con virtual fabrics/VSANs cuando sea necesario; y monitoree CRC, enc_out, loss of sync, congestion, slow drain, credit zero y latencia de E/S continuamente.
Zoning y masking: defensa en profundidad
El zoning controla la comunicación en el fabric; el LUN masking controla la presentación en el array — ambos son necesarios. El modelo recomendado es una zona por initiator con uno o pocos targets, lo que reduce la interferencia, facilita la auditoría y limita el impacto de los cambios.
Los aliases deben incluir entorno, host, HBA/puerto, fabric y función — por ejemplo, PRD-DB01-HBAA y AFF01-CTA-P01. El proceso de cambio sigue: recopilar los WWPNs de una fuente confiable, validar el login en el fabric antes de crear la zona, modificar solamente un fabric a la vez cuando sea posible, y activar, probar MPIO, observar errores y registrar evidencias. Evite zonas all-access, mezcla de initiators sin justificación, targets de arrays diferentes en la misma zona, y la eliminación simultánea en A/B.
Congestión y slow drain
Un dispositivo lento puede retener credits y esparcir la congestión por el fabric, elevando la latencia y afectando cargas de trabajo no relacionadas. Las señales incluyen credit zero prolongado, timeouts, queueing y latencia de E/S; CRC, invalid transmission word, loss of sync/signal y enc_out; y backpressure persistente, frames descartados o caminos MPIO inestables.
En el diagnóstico, correlacione host, HBA, driver/firmware, SFP, fibra, puerto, ISL, controladora y array — un contador aislado rara vez cuenta toda la historia. La corrección pasa por sustituir componentes físicos comprobadamente defectuosos, corregir firmware/driver, redistribuir la carga, y solo aumentar ISL/credits cuando la causa y el dimensionamiento lo justifiquen. La prevención depende de baselines por puerto, alertas por tendencia, pruebas de failover, márgenes de capacidad y un proceso riguroso de compatibilidad.
Automatización e infraestructura como código
La automatización debe aumentar la consistencia y la evidencia, no acelerar los errores. En APIs y herramientas, Cisco ACI ofrece REST API, Cobra SDK, Ansible y Terraform providers según soporte; Juniper ofrece NETCONF/YANG, PyEZ, gNMI, Ansible, Terraform y Apstra; y Cisco MDS/Brocade ofrecen APIs, Ansible, scripts y plataformas de gestión según versión.
Un pipeline seguro incluye lint y validación de schema, laboratorio, diff, aprobación, ventana, ejecución en serie por dominio de falla, health checks y rollback. La fuente de verdad — NetBox/DCIM/CMDB o repositorio versionado — debe guardar IPAM, ASN, puertos, ópticas, VLAN/VNI, VRF, zones, WWPN y dependencias. Los secretos nunca deben almacenarse en el código: use vault, RBAC mínimo, rotación, logs de auditoría y cuentas individuales.
Seguridad de la infraestructura de red
El plano de gestión es un activo crítico y debe estar separado, autenticado, monitoreado y ser recuperable. En el management plane, use una red OOB independiente, AAA central con fallback controlado, TACACS+/RADIUS y MFA donde sea compatible; SSH, HTTPS y SNMPv3, desactivando servicios y cifrados legados; NTP autenticado cuando esté disponible; y RBAC por función con logs inmutables enviados a SIEM.
En el control plane, aplique CoPP/policers, autenticación de adyacencias, filtros de peers, TTL security cuando aplique y protección contra route leaks. En el data plane, use microsegmentación, contracts/policies mínimos, VRFs, firewalls y validación del tráfico permitido — el cifrado MACsec/IPsec/FC-SP depende del riesgo y del soporte. Para la resiliencia, mantenga backups exportados, golden configuration, piezas de repuesto, contactos de soporte y ejercicios de recuperación.
Observabilidad y SLOs
La disponibilidad no es "el ping responde": es necesario monitorear la experiencia de la aplicación, la capacidad y la salud por dominio. En la LAN, siga la utilización y el headroom por enlace/cola, drops, ECN/PFC cuando se usen, latencia y jitter; los neighbors de BGP/EVPN/OSPF/IS-IS, MAC moves, endpoint churn e inconsistencias; y las ópticas — Rx/Tx power, temperatura, FEC y errores.
En la SAN, siga IOPS, throughput y latencia por host/target/LUN; credits, congestión, CRC, link resets y slow drain; y el estado de zoneset/config, logins y paths MPIO. Defina SLOs medibles — disponibilidad, tiempo de convergencia, pérdida, latencia, headroom, plazo de corrección y éxito de cambios — y asegúrese de que los cambios, alertas, flujos, inventario y tickets compartan timestamp, activo y servicio afectado para permitir una correlación real.
Plan de implementación en ocho etapas
Implemente por olas pequeñas y verificables, manteniendo siempre un camino de retorno probado. En las etapas 1–2 (descubrimiento y HLD), levante requisitos, aplicaciones, tráfico, latencia, seguridad, crecimiento, RTO/RPO, sitios e integraciones, produciendo un HLD con decisiones y alternativas.
En las etapas 3–4 (LLD y staging), defina port maps, IPAM, ASN, VLAN/VNI, VRF, políticas, zoning, ópticas, cables, energía, configuración, pruebas y MOP, montando y actualizando los equipos fuera de producción. En las etapas 5–6 (piloto y migración), comience por un servicio no crítico, valide fallas y observabilidad, y migre en lotes con criterios de go/no-go y checkpoints. En las etapas 7–8 (estabilización y handover), siga los baselines, corrija desviaciones, actualice la documentación, capacite a las operaciones, registre el as-built y acepte formalmente el entorno.
Checklist de aceptación LAN
Use esta lista como punto de partida, adaptándola a los estándares y riesgos del entorno. En lo físico: racks, RU, airflow, alimentación A/B, aterramiento, cables y etiquetas verificados; ópticas compatibles, con niveles Tx/Rx y FEC dentro de lo esperado. En el underlay/overlay: todos los enlaces y neighbors up, ECMP instalado, MTU y BFD probados; VNIs/VLANs/VRFs/gateways/EPGs/contracts validados, sin flooding ni MAC moves anormales.
En la resiliencia: falla de enlace, leaf, spine, fuente y peer probada bajo carga representativa; border/firewall/LB con simetría y convergencia comprobadas. En la operación: backup, OOB, AAA, NTP, DNS, syslog, SNMP/telemetría y alertas funcionales; dashboards, runbooks, as-built, inventario y soporte entregados.
Checklist de aceptación SAN
Cada camino debe probarse de forma aislada y en combinaciones de falla plausibles. En el fabric: A/B físicamente independientes, domain IDs/FIDs/VSANs correctos, ISLs y trunks saludables, sin CRC, loss of sync, credit starvation ni congestión persistente. En hosts y arrays: WWPNs, firmware/driver de HBA e interoperabilidad de array confirmados; zoning y masking revisados, con todos los paths MPIO activos/optimizados según la política.
En las pruebas: remoción controlada de un fabric sin interrupción de la aplicación; failover de controladora, puerto, HBA e ISL según la matriz de pruebas; desempeño y latencia dentro del baseline en carga normal y pico. En la gobernanza: backups, aliases, zonesets/configs, port maps y as-built versionados; runbook de slow drain, falla física y cambio de zoning aprobado.
Conclusión
Las redes de data center bien diseñadas separan responsabilidades con claridad: la LAN transporta aplicaciones y usuarios sobre un fabric spine-leaf redundante, con Cisco ACI o Juniper EVPN-VXLAN como enfoques maduros y distintos; la SAN transporta bloques de almacenamiento sobre Fibre Channel con Cisco MDS o Brocade, aislada en dual fabric A/B. La convergencia con Ethernet — RoCEv2, iSCSI, NVMe/TCP — es posible, pero exige un diseño propio de QoS y aislamiento, no es un atajo.
El valor real aparece cuando el dimensionamiento, la redundancia, la automatización, la seguridad y la observabilidad se tratan como un único sistema, probados bajo falla real antes de entrar en producción — no como elecciones aisladas hechas en momentos diferentes del proyecto.