Cisco StackWise Virtual: Diseño de Campus Core para 2026

StackWise Virtual (SVL) es el sucesor definitivo de Virtual Switching System (VSS) para construir capas Core y de distribución empresariales resilientes y de alto ancho de banda. Si bien el concepto de emparejar dos chasis en un único switch lógico no es nuevo, la implementación de SVL en el hardware moderno de las series Catalyst 9500 y 9600 exige una comprensión matizada de su mecánica subyacente, particularmente el StackWise Virtual Link (SVL), la detección dual-active y los procesos de In-Service Software Upgrade (ISSU). Una implementación exitosa de SVL trasciende una simple mentalidad de "plug-and-play" y requiere decisiones de ingeniería precisas que tienen implicaciones significativas para la estabilidad y el rendimiento de la malla.

StackWise Virtual vs. VSS y Backplane Stacking

Es fundamental diferenciar SVL de sus predecesores y de sus hermanos de las series Catalyst 9200/9300. VSS, pionero en la serie Catalyst 6500, requería chasis idénticos, módulos supervisores específicos (como el VS-S2T-10G), y utilizaba los port-channels físicos como Virtual Switch Link (VSL). SVL en el Catalyst 9500/9600 hereda esta filosofía pero la implementa en la moderna arquitectura de ASIC UADP con IOS XE.

Por el contrario, el StackWise tradicional, como se ve en la serie Catalyst 9300 con StackWise-1T, utiliza cables de backplane propietarios (p. ej., STACK-T1) para conectar múltiples switches en una topología de anillo. Esto crea un único switch lógico con un plano de datos y un plano de control unificados, compartiendo una única IP address. SVL logra el mismo resultado lógico pero utiliza interfaces Ethernet estándar de 10/25/40/100G para la interconexión, conocida como StackWise Virtual Link. Esta distinción es primordial: SVL es para pares de switches de distribución/Core de alto rendimiento, mientras que StackWise es para apilar múltiples switches de capa de acceso en un armario de cableado.

Selección de Plataforma Hardware Core: Catalyst 9500 vs. 9600

La elección entre la serie Catalyst 9500 de configuración fija y la serie modular Catalyst 9600 para un par SVL depende completamente de la densidad de puertos, la escalabilidad futura y el presupuesto. Ambos están construidos sobre ASIC UADP de Cisco, lo que garantiza paridad de características para las funciones Core del campus.

Catalyst 9500: Core Fijo de Alto Rendimiento

La serie Catalyst 9500, particularmente los modelos de alto rendimiento, es ideal para bloques Core o de distribución compactos. Un emparejamiento común son dos switches C9500-48Y4C, que proporcionan 48 puertos SFP28 de 1/10/25G y 4 puertos QSFP de 40/100G. Para necesidades de mayor rendimiento, el C9500-32C ofrece 32 puertos QSFP28 de 40/100G. Estas plataformas, que se ejecutan en UADP 3.0, proporcionan importantes recursos de TCAM y buffer adecuados para la mayoría de los requisitos de Core empresarial. Su naturaleza fija significa que lo que se compra es lo que hay; la expansión futura implica un reemplazo de chasis, no la adición de una tarjeta de línea.

Catalyst 9600: Escala Modular para Grandes Campus

Para grandes campus empresariales o universitarios, el chasis Catalyst 9606R con un par de supervisores C9600-SUP-1 es la elección lógica. La modularidad permite una combinación de tarjetas de línea, como la C9600-LC-48YL (48 puertos de 1/10/25G) y la C9600-LC-24C (24 puertos de 40/100G). Esto permite un modelo de pago por crecimiento y la capacidad de adoptar futuras tecnologías, como 400G, mediante una nueva tarjeta de línea en lugar de un reemplazo completo del sistema. Un par SVL de chasis 9606R proporciona lo último en resiliencia y escala, capaz de soportar miles de usuarios y dispositivos.

Dimensionando el StackWise Virtual Link (SVL)

El SVL es el componente más crítico del diseño. Transporta toda la comunicación del plano de control y cualquier tráfico de datos que deba atravesar entre los dos chasis (es decir, "tráfico inter-chasis"). Subdimensionar el SVL priva a la malla de ancho de banda y puede provocar un rendimiento impredecible, mientras que sobredimensionarlo desperdicia puertos caros de alta velocidad. Es esencial un enfoque pragmático para el dimensionamiento.

Considere un bloque de distribución construido sobre un par SVL de switches C9500-32C. Este bloque sirve a diez stacks de capa de acceso de Catalyst 9300, cada uno con uplinks duales de 40G configurados en un Multi-chassis EtherChannel (MEC) al par SVL. La capacidad total de uplink es de 10 * (2 * 40 Gbps) = 800 Gbps. Una regla general común es aprovisionar el SVL con una capacidad igual al 25-50% del ancho de banda total del uplink conectado, asumiendo una distribución uniforme de la terminación del tráfico en ambos chasis.

Cálculo de Ejemplo:

• Ancho de Banda Total de Uplink: 800 Gbps
• Capacidad SVL Objetivo (regla del 30%): 800 Gbps * 0.30 = 240 Gbps
• Implementación: Un port-channel de tres puertos de interfaces de 100G (3 x 100 Gbps = 300 Gbps).

En cada C9500-32C, se aprovisionarían los puertos HundredGigE1/0/30, 1/0/31 y 1/0/32 para el SVL. Esto proporciona 300 Gbps de ancho de banda, superando el objetivo de 240 Gbps y ofreciendo redundancia N+1; la falla de un solo link aún deja 200 Gbps de capacidad. Ejecutar datos de misión crítica y tráfico de control sobre un solo link, incluso uno de 100G, es un antipatrón de diseño. Siempre use un port-channel con al menos dos miembros para el SVL.

Detección de Dual-Active: La Red de Seguridad Definitiva

Un escenario dual-active es el estado de falla más catastrófico para un par de switching virtualizado. Ocurre cuando el SVL falla y ambos switches creen que son el chasis activo. Esto conduce a la duplicación de IP addresses, inestabilidad de la tabla de MAC addresses y loops en toda la red. SVL emplea un mecanismo de detección de múltiples capas, una evolución de VSS, para evitar esto.

1. Keepalives de SVL: El método principal. Los headers propietarios de Cisco en el tráfico SVL incluyen keepalives. Si estos no se reciben durante el período de tiempo configurado (los valores predeterminados son agresivos, en cientos de milisegundos), el switch secundario inicia una secuencia de failover.
2. Fast-Hello: Este es un link obligatorio y fuera de banda. Implica una conexión layer-2 directa (p. ej., un único puerto SFP de 1G en cada switch, como Gi1/0/1 <--> Gi1/0/1) dedicado al envío de paquetes UDP keepalive. Si el SVL se cae pero los keepalives de Fast-Hello aún se reciben, el switch secundario sabe que el primario sigue vivo e inmediatamente entra en modo de recuperación, apagando todos sus puertos front-panel (excepto el SVL) para evitar loops.
3. Enhanced PAgP (ePAgP) / MEC: Este es el tie-breaker final y una mejora significativa sobre VSS. Si tanto el SVL como los links Fast-Hello fallan simultáneamente (p. ej., una falla de varias tarjetas o una falla de switch intermedio), el par SVL puede usar un switch downstream para comunicarse. Un PAgP TLV especial en el Multi-chassis EtherChannel (MEC) informa a cada miembro SVL de la existencia del otro. Si un switch se ve a sí mismo y a su peer en los mensajes PAgP de un dispositivo downstream, pero no puede alcanzar al peer a través del SVL, sabe que existe una condición dual-active.

Error Común: El Link Fast-Hello Compartido

Un error común es pasar el link Fast-Hello a través de otro equipo de red, como un switch de gestión, para ahorrar fibra. Esto es un defecto crítico de diseño. Si ese switch intermedio se reinicia o falla, ambos miembros SVL pierden la conectividad Fast-Hello, lo que activa un falso positivo. El link Fast-Hello DEBE ser una conexión directa y dedicada entre los dos chasis SVL, idealmente una sola hebra de fibra o un cable DAC si están co-ubicados. Escatimar aquí socava todo el diseño de alta disponibilidad.

Cuándo NO Usar StackWise Virtual

SVL es una herramienta poderosa, pero no es la solución universal para todos los diseños de campus. Aplicarlo en el contexto equivocado crea más problemas de los que resuelve.

• EVPN-VXLAN Fabrics: Para fabrics de campus avanzados que emplean un overlay EVPN-VXLAN con un plano de control BGP, SVL es el modelo incorrecto. Una verdadera arquitectura spine-leaf (CLOS) se basa en links L3 individualmente enrutados entre switches leaf y spine. Cada switch es una entidad de enrutamiento independiente. SVL, por el contrario, crea un gran dominio L2 con un único punto de control, lo cual es antitético a los principios de un routed fabric.
• Cores Geográficamente Dispersos: Intentar "estirar" un par SVL entre diferentes edificios o data centers a través de DWDM o fibra oscura es una práctica peligrosa. El protocolo SVL es extremadamente sensible a la latencia y al jitter. Cualquier latencia superior a unos pocos milisegundos (el límite oficial de Cisco a menudo se cita en función del alcance óptico, pero 5 ms es un techo práctico seguro) puede causar inestabilidad en la comunicación del plano de control. Una falla del link de larga distancia podría conducir a una condición dual-active que es difícil de solucionar. El dominio de falla se vuelve inaceptablemente grande.
• Implementaciones Pequeñas: Para un escenario simple de top-of-rack o armario de cableado con 2-4 switches, un par SVL completo de Catalyst 9500 es excesivo. Un stack de Catalyst 9300 que utiliza los cables de backplane dedicados StackWise-1T es mucho más rentable, más fácil de configurar y proporciona un plano de gestión unificado en un formato más apropiado.

ISSU y Stateful Switchover (SSO)

In-Service Software Upgrade (ISSU) es un beneficio clave de SVL, que permite actualizaciones de software con una interrupción mínima del tráfico. Sin embargo, su naturaleza "sin interrupciones" a menudo se malinterpreta. El proceso, gobernado por Stateful Switchover (SSO), funciona actualizando primero el chasis en standby. Se recarga con el nuevo código mientras el chasis activo continúa reenviando tráfico. Una vez que el standby vuelve a estar online y sincronizado, se activa un switchover manual o automático. El chasis recién activo, que ejecuta el nuevo código, asume el reenvío de tráfico. El chasis anteriormente activo (ahora en standby) se actualiza.

Este proceso mantiene el plano de datos: el reenvío continúa basándose en las tablas FIB y de adyacencia existentes. Sin embargo, el plano de control se reinicia. Los protocolos de enrutamiento como OSPF y EIGRP, cuando están configurados para Non-Stop Forwarding (NSF), realizarán un graceful restart, evitando flaps de vecinos. Las sesiones BGP también se reiniciarán de forma graceful. Sin embargo, no es un evento realmente "invisible". El proceso requiere IOS XE 17.3.2 o posterior y un estricto cumplimiento de la matriz de compatibilidad para las versiones de origen y destino. Siempre realice ISSU en una ventana de mantenimiento planificada con un procedimiento de rollback documentado.

Migrando de Catalyst VSS a StackWise Virtual

Muchas empresas se enfrentan al fin de vida útil de sus Core VSS Catalyst 6500/6800. La migración a un par SVL Catalyst 9500/9600 se puede realizar con un tiempo de inactividad mínimo utilizando un enfoque de swing migration.

1. Pre-configuración: Instale y configure el nuevo par SVL. Configure el SVL, Fast-Hello, todos los SVIs, protocolos de enrutamiento, ACLs y políticas de QoS. Mantenga los SVIs en estado de shutdown. Los nuevos port-channels MEC que miran a la capa de acceso deben configurarse pero estarán vacíos.
2. Swing Uplinks (Ventana de Mantenimiento): Para cada switch o stack downstream conectado al par VSS a través de MEC, realice el swing. Digamos que un stack Cat 9300 tiene un uplink a VSS-Active y uno a VSS-Standby.
• Mueva el uplink del chasis VSS-Standby a un puerto del nuevo chasis SVL-Standby. El port-channel en el Cat 9300 ahora tendrá un link miembro caído y uno activo (a VSS-Active).
• Mueva el uplink del chasis VSS-Active a un puerto del nuevo chasis SVL-Active. El port-channel en el Cat 9300 ahora estará completamente conectado al nuevo Core SVL. El tráfico aún no fluye ya que los SVIs están inactivos.
3. Corte de Enrutamiento: Este es el paso que afecta al servicio. En el nuevo Core SVL, ejecute un `no shutdown` en todos los SVIs del Core. Simultáneamente, `shutdown` todos los SVIs en el Core VSS antiguo. Esto obliga a todo el tráfico enrutado a fluir a través de la nueva malla. Las adyacencias de enrutamiento entre peers caerán del Core antiguo y se reformarán con el nuevo.
4. Desactivación: Después de un período de monitoreo para garantizar la estabilidad, apague y retire el chasis VSS antiguo.

StackWise Virtual, cuando se implementa en las robustas plataformas Catalyst 9500 y 9600, ofrece una solución formidable para construir la próxima generación de redes de campus empresariales. Su fortaleza no reside en la simplicidad de su concepto, sino en la ejecución detallada de sus componentes de soporte: un SVL dimensionado correctamente, un link Fast-Hello físicamente aislado y MECs configurados correctamente. Al evitar errores comunes y respetar sus límites de diseño, los ingenieros de red pueden construir un fabric de Core y distribución que ofrece la estabilidad y el rendimiento requeridos hasta 2026 y más allá. Para discutir un plan de migración personalizado o una revisión arquitectónica para su campus, contacte a los expertos de techleague.io.

Para obtener más información sobre el diseño de campus, consulte nuestras publicaciones sobre EVPN-VXLAN como Campus Fabric y una revisión de rendimiento del Catalyst 9300X con StackWise-1T.