É possível misturar diferentes modelos Catalyst 9500 em um par StackWise Virtual?

Não. Os dois switches em um domínio StackWise Virtual devem ser do mesmo número de modelo (PID), rodando a mesma versão do IOS XE e o mesmo nível de licença (por exemplo, DNA Advantage). Isso garante paridade completa de recursos e desempenho entre os chassis.

Qual é a distância máxima para um StackWise Virtual Link (SVL)?

A distância física é ditada pelo transceptor óptico utilizado (por exemplo, 100G-LR4 permite até 10km). No entanto, a verdadeira restrição é a latência. Os protocolos do plano de controle do SVL são projetados para latência próxima a zero, e um limite prático e seguro é em torno de 5 milissegundos. É fortemente recomendado manter ambos os chassis dentro do mesmo data center ou sala de comunicação.

Como o StackWise Virtual lida com o Quality of Service (QoS)?

As marcações de QoS (DSCP, CoS) são preservadas quando os frames transitam pelo SVL. No entanto, as políticas de queuing, policing e shaping são aplicadas por chassis. Isso significa que o tráfego que ingressa no Switch 1 está sujeito às políticas de egress queuing do Switch 1, mesmo que seu destino final seja uma porta no Switch 2.

Como o licenciamento é tratado para um par StackWise Virtual?

Ambos os switches devem ter o mesmo nível de licença de assinatura Cisco DNA (por exemplo, Essentials, Advantage ou Premier). Um único DNA Center pode gerenciar o par como uma entidade lógica, mas as licenças de hardware e software são adquiridas e aplicadas por chassis.

Posso agrupar portas 40G e 100G no mesmo SVL?

Não. Todos os links membros dentro do port-channel designado como StackWise Virtual Link devem ter a mesma velocidade. Você não pode misturar interfaces 40G e 100G no mesmo bundle. Você deve escolher uma velocidade e provisionar múltiplas interfaces dessa velocidade para capacidade e redundância.

O que acontece especificamente da perspectiva do secundário em um cenário dual-active?

Se o SVL falhar e o link Fast-Hello também falhar, o switch secundário assume que o primário está inoperante e transiciona para se tornar ativo. No entanto, se ele então receber um ePAgP hello de um switch downstream que indica que o primário original também está ativo, ele sabe que existe uma condição dual-active. Ele imediatamente coloca todas as suas interfaces de painel frontal, não-SVL, em estado error-disabled para evitar loops e proteger a rede.

Uma conexão direta de fibra é realmente obrigatória para o link Fast-Hello?

Embora possa funcionar através de um switch intermediário, é uma violação crítica de design. O propósito do link Fast-Hello é ser uma verificação simples e out-of-band da vivacidade do peer. Executá-lo através de qualquer outro dispositivo introduz shared fate; se esse dispositivo falhar, pode-se acionar uma detecção falsa de dual-active. Um cabo DAC direto ou um único filamento de fibra é o único design suportado e arquitetonicamente sólido.

Cisco StackWise Virtual: Design de Campus Core para 2026

StackWise Virtual (SVL) é o sucessor definitivo do Virtual Switching System (VSS) para a construção de camadas de distribuição e core de campus empresarial resilientes e de alta largura de banda. Embora o conceito de emparelhar dois chassis em um único switch lógico não seja novo, a implementação do SVL em hardware moderno da série Catalyst 9500 e 9600 exige uma compreensão aprofundada de sua mecânica subjacente, particularmente o StackWise Virtual Link (SVL), a detecção dual-active e os processos de In-Service Software Upgrade (ISSU). Uma implantação bem-sucedida de SVL vai além de uma mentalidade de "plug-and-play" e requer decisões de engenharia precisas que têm implicações significativas para a estabilidade e o desempenho da fabric.

StackWise Virtual vs. VSS e Backplane Stacking

É fundamental diferenciar SVL de seus predecessores e de seus 'primos' da série Catalyst 9200/9300. O VSS, pioneiro na série Catalyst 6500, exigia chassis idênticos, módulos supervisor específicos (como o VS-S2T-10G) e usava os port-channels físicos como Virtual Switch Link (VSL). O SVL no Catalyst 9500/9600 herda essa filosofia, mas a implementa na arquitetura moderna de ASIC UADP com IOS XE.

Por outro lado, o StackWise tradicional, como visto na série Catalyst 9300 com StackWise-1T, usa cabos de backplane proprietários (por exemplo, STACK-T1) para conectar múltiplos switches em uma topologia em anel. Isso cria um único switch lógico com um plano de dados e um plano de controle unificados, compartilhando um único endereço IP. O SVL alcança o mesmo resultado lógico, mas usa interfaces Ethernet padrão de 10/25/40/100G para a interconexão, conhecido como StackWise Virtual Link. Essa distinção é primordial: o SVL é para pares de switches de distribuição/core de alto desempenho, enquanto o StackWise é para empilhar múltiplos switches da camada de acesso em um wiring closet.

Seleção da Plataforma de Hardware Core: Catalyst 9500 vs. 9600

A escolha entre o Catalyst 9500 Series de configuração fixa e o Catalyst 9600 Series modular para um par SVL depende inteiramente da densidade de portas, escalabilidade futura e orçamento. Ambos são construídos sobre ASICs UADP da Cisco, garantindo paridade de recursos para funções de campus core.

Catalyst 9500: Core Fixo de Alto Desempenho

O Catalyst 9500 Series, particularmente os modelos de alto desempenho, são ideais para blocos de core ou distribuição compactos. Um emparelhamento comum são dois switches C9500-48Y4C, fornecendo 48 portas 1/10/25G SFP28 e 4 portas 40/100G QSFP. Para necessidades de maior desempenho, o C9500-32C oferece 32 portas 40/100G QSFP28. Essas plataformas, rodando em UADP 3.0, fornecem recursos significativos de TCAM e buffer adequados para a maioria dos requisitos de core empresarial. Sua natureza fixa significa que o que você compra é o que você obtém; a expansão futura envolve a substituição de um chassis, não a adição de uma line card.

Catalyst 9600: Escala Modular para Grandes Campi

Para grandes campi universitários ou empresariais, o chassi Catalyst 9606R com um par de supervisors C9600-SUP-1 é a escolha lógica. A modularidade permite uma mistura de line cards, como o C9600-LC-48YL (48 portas 1/10/25G) e o C9600-LC-24C (24 portas 40/100G). Isso permite um modelo de 'pague conforme cresce' e a capacidade de adotar tecnologias futuras, como 400G, através de uma nova line card em vez de uma substituição completa do sistema. Um par SVL de chassis 9606R fornece o máximo em resiliência e escala, capaz de suportar milhares de usuários e dispositivos.

Dimensionando o StackWise Virtual Link (SVL)

O SVL é o componente mais crítico do design. Ele transporta toda a comunicação do plano de controle e qualquer tráfego de dados que precise atravessar entre os dois chassis (ou seja, tráfego "inter-chassis"). Subdimensionar o SVL priva a fabric de largura de banda e pode levar a um desempenho imprevisível, enquanto superdimensionar desperdiça portas de alta velocidade caras. Uma abordagem pragmática para o dimensionamento é essencial.

Considere um bloco de distribuição construído em um par SVL de switches C9500-32C. Este bloco atende dez stacks de camada de acesso de Catalyst 9300s, cada um com uplinks duplos de 40G configurados em um Multi-chassis EtherChannel (MEC) para o par SVL. A capacidade total de uplink é de 10 * (2 * 40 Gbps) = 800 Gbps. Uma regra geral comum é provisionar o SVL com uma capacidade igual a 25-50% da largura de banda total de uplink conectada, assumindo uma distribuição uniforme do tráfego através de ambos os chassis.

Cálculo do Exemplo:

Largura de Banda Total do Uplink: 800 Gbps
Capacidade Alvo do SVL (regra de 30%): 800 Gbps * 0.30 = 240 Gbps
Implementação: Um port-channel de três portas de interfaces 100G (3 x 100 Gbps = 300 Gbps).

Em cada C9500-32C, você provisionaria as portas HundredGigE1/0/30, 1/0/31 e 1/0/32 para o SVL. Isso fornece 300 Gbps de largura de banda, excedendo o alvo de 240 Gbps e oferecendo redundância N+1; a falha de um único link ainda deixa 200 Gbps de capacidade. Executar dados e tráfego de controle de missão crítica sobre um único link, mesmo um de 100G, é um antipadrão de design. Sempre use um port-channel com pelo menos dois membros para o SVL.

Detecção Dual-Active: A Rede de Segurança Suprema

Um cenário dual-active é o estado de falha mais catastrófico para um par de switching virtualizado. Ocorre quando o SVL falha e ambos os switches acreditam ser o chassis ativo. Isso leva à duplicação de endereços IP, instabilidade da tabela de endereços MAC e loops em toda a rede. O SVL emprega um mecanismo de detecção multicamadas, uma evolução do VSS, para evitar isso.

SVL Keepalives: O método primário. Headers proprietários da Cisco no tráfego SVL incluem keepalives. Se estes não forem recebidos pelo período de tempo configurado (os defaults são agressivos, na casa dos milissegundos), o switch secundário inicia uma sequência de failover.
Fast-Hello: Este é um link out-of-band obrigatório. Envolve uma conexão direta de camada 2 (por exemplo, uma única porta 1G SFP em cada switch, como Gi1/0/1 <--> Gi1/0/1) dedicada ao envio de pacotes UDP keepalive. Se o SVL cair, mas os keepalives Fast-Hello ainda forem recebidos, o switch secundário sabe que o primário ainda está vivo e imediatamente entra em modo de recuperação, desligando todas as suas portas de painel frontal (exceto o SVL) para evitar loops.
Enhanced PAgP (ePAgP) / MEC: Este é o desempate final e uma melhoria significativa em relação ao VSS. Se tanto o SVL quanto os links Fast-Hello falharem simultaneamente (por exemplo, falha de múltiplas cards ou falha de switch intermediário), o par SVL pode usar um switch downstream para se comunicar. Um TLV especial de PAgP no Multi-chassis EtherChannel (MEC) informa cada membro SVL da existência do outro. Se um switch se vê e seu peer nas mensagens PAgP de um dispositivo downstream, mas não consegue alcançar o peer sobre o SVL, ele sabe que existe uma condição dual-active.

Armadilha Comum: O Link Fast-Hello Compartilhado

Um erro comum é passar o link Fast-Hello através de outro equipamento de rede, como um switch de gerenciamento, para economizar fibra. Isso é uma falha crítica de design. Se esse switch intermediário reiniciar ou falhar, ambos os membros SVL perdem a conectividade Fast-Hello, acionando um falso positivo. O link Fast-Hello DEVE ser uma conexão direta e dedicada entre os dois chassis SVL — idealmente um único filamento de fibra ou um cabo DAC se co-localizado. Economizar aqui mina todo o design de alta disponibilidade.

Quando NÃO Usar StackWise Virtual

O SVL é uma ferramenta poderosa, mas não é a solução universal para todos os designs de campus. Aplicá-lo no contexto errado cria mais problemas do que resolve.

Fabrics EVPN-VXLAN: Para fabrics de campus avançadas empregando um overlay EVPN-VXLAN com um plano de controle BGP, o SVL é o modelo errado. Uma verdadeira arquitetura spine-leaf (CLOS) depende de links L3 roteados individualmente entre switches leaf e spine. Cada switch é uma entidade de roteamento independente. O SVL, por outro lado, cria um grande domínio L2 com um único ponto de controle, o que é antitético aos princípios de uma fabric roteada.
Cores Geograficamente Dispersos: Tentar "esticar" um par SVL entre diferentes edifícios ou data centers sobre DWDM ou fibra escura é uma prática perigosa. O protocolo SVL é extremamente sensível à latência e ao jitter. Qualquer latência acima de alguns milissegundos (o limite oficial da Cisco é frequentemente citado com base no alcance óptico, mas 5ms é um teto prático seguro) pode causar instabilidade na comunicação do plano de controle. Uma falha do link de longa distância poderia levar a uma condição dual-active que é difícil de solucionar. O domínio de falha torna-se inaceitavelmente grande.
Implantações Pequenas: Para um cenário simples de top-of-rack ou wiring closet com 2-4 switches, um par SVL completo de Catalyst 9500s é um exagero. Um stack de Catalyst 9300s usando os cabos de backplane dedicados StackWise-1T é muito mais econômico, mais simples de configurar e fornece um plano de gerenciamento unificado em um formato mais apropriado.

ISSU e Stateful Switchover (SSO)

O In-Service Software Upgrade (ISSU) é um benefício chave do SVL, permitindo atualizações de software com interrupção mínima do tráfego. No entanto, sua natureza "hitless" é frequentemente mal compreendida. O processo, governado pelo Stateful Switchover (SSO), funciona atualizando primeiro o chassis standby. Ele recarrega com o novo código enquanto o chassis ativo continua a encaminhar o tráfego. Assim que o standby está online novamente e sincronizado, um switchover manual ou automático é acionado. O chassis recém-ativo, rodando o novo código, assume o encaminhamento do tráfego. O chassis antes ativo (agora standby) é então atualizado.

Este processo mantém o plano de dados — o encaminhamento continua baseado nas tabelas FIB e de adjacência existentes. No entanto, o plano de controle sofre um reset. Protocolos de roteamento como OSPF e EIGRP, quando configurados para Non-Stop Forwarding (NSF), realizarão um graceful restart, evitando flaps de vizinhos. As sessões BGP também farão um graceful restart. No entanto, não é um evento verdadeiramente "invisível". O processo requer IOS XE 17.3.2 ou posterior e adesão estrita à matriz de compatibilidade para as versões de origem e destino. Sempre realize o ISSU em uma janela de manutenção planejada com um procedimento de rollback documentado.

Migrando de Catalyst VSS para StackWise Virtual

Muitas empresas estão enfrentando o fim da vida útil de seus cores VSS Catalyst 6500/6800. A migração para um par SVL Catalyst 9500/9600 pode ser realizada com tempo de inatividade mínimo usando uma abordagem de swing migration.

Pré-Staging: Rack e stack o novo par SVL. Configure o SVL, Fast-Hello, todos os SVIs, protocolos de roteamento, ACLs e políticas de QoS. Mantenha os SVIs em estado de shutdown. Os novos port-channels MEC voltados para a camada de acesso devem ser configurados, mas estarão vazios.
Swing Uplinks (Janela de Manutenção): Para cada switch downstream ou stack conectado ao par VSS via MEC, execute o swing. Digamos que um stack Cat 9300 tenha um uplink para VSS-Active e um para VSS-Standby.

Mova o uplink do chassis VSS-Standby para uma porta no novo chassis SVL-Standby. O port-channel no Cat 9300 agora terá um link membro down e um up (para VSS-Active).
Mova o uplink do chassis VSS-Active para uma porta no novo chassis SVL-Active. O port-channel no Cat 9300 agora estará totalmente conectado ao novo core SVL. O tráfego ainda não está fluindo, pois os SVIs estão down.

Cutover de Roteamento: Esta é a etapa que afeta o serviço. No novo core SVL, execute um `no shutdown` em todos os SVIs de core. Simultaneamente, `shutdown` todos os SVIs no core VSS antigo. Isso força todo o tráfego roteado a fluir pela nova fabric. As adjacências de roteamento peer cairão do core antigo e se reformarão com o novo.
Descomissionamento: Após um período de monitoramento para garantir a estabilidade, desligue e remova o chassis VSS legado.

O StackWise Virtual, quando implementado nas robustas plataformas Catalyst 9500 e 9600, oferece uma solução formidável para a construção da próxima geração de redes de campus empresariais. Sua força reside não na simplicidade de seu conceito, mas na execução detalhada de seus componentes de suporte: um SVL dimensionado corretamente, um link Fast-Hello fisicamente isolado e MECs configurados corretamente. Ao evitar armadilhas comuns e respeitar seus limites de design, engenheiros de rede podem construir uma fabric de core e distribuição que oferece a estabilidade e o desempenho necessários até 2026 e além. Para discutir um plano de migração personalizado ou revisão arquitetônica para o seu campus, entre em contato com os especialistas em techleague.io.

Para mais sobre design de campus, veja nossos posts sobre EVPN-VXLAN como um Campus Fabric e uma revisão de desempenho do Catalyst 9300X com StackWise-1T.