Posso usar switches da série 9300 mais antigos (não EX/FX) como Border Gateways?

ASICs Cloud Scale como o FX2 ou GX são necessários porque suportam a 'dupla pesquisa' VXLAN-para-VXLAN exigida por um BGW. ASICs mais antigos não podem realizar a encapsulação e decapsulação necessárias em uma única passagem na velocidade da linha.

É necessário vPC para a Alta Disponibilidade do Border Gateway?

Anycast BGW é significativamente melhor para escalabilidade. Ele permite que múltiplos BGWs compartilhem um IP virtual, permitindo L3 ECMP para tráfego inter-site e evitando as limitações proprietárias e os riscos de domínio de falha de um vPC Peer-Link.

Quais são os requisitos específicos para a Inter-Site Network (ISN)?

A ISN só precisa fornecer IP reachability e suportar um MTU de pelo menos 1550 bytes. Não precisa ser VXLAN-aware ou EVPN-aware; ela simplesmente roteia os pacotes encapsulados entre os VTEPs BGW.

O que o comando 'rewrite-evpn-rt-asn' realmente faz?

O comando 'rewrite-evpn-rt-asn' permite que um BGW re-origem rotas EVPN com seu próprio ASN, o que é crucial para designs multi-AS onde os Route Targets devem ser mapeados corretamente entre domínios BGP independentes.

Devo usar Ingress Replication ou Multicast para tráfego BUM entre sites?

Para a maioria das empresas, Ingress Replication (IR) é o método preferencial. Ele simplifica a configuração da ISN usando o BGW para replicar o tráfego BUM como unicast para sites remotos, eliminando a necessidade de PIM ou um RP no core.

Dominando Cisco Nexus 9000 VXLAN EVPN Multi-Site: Guia de Design 2026

A era do domínio Layer 2 "esticado" via OTV ou VPLS está morta, e se você ainda está usando vPC back-to-back para conectividade multi-pod, seu raio de explosão é uma bomba-relógio. Em 2026, a única arquitetura defensável para interconectar data centers distribuídos de alta performance é o modelo Nexus 9000 VXLAN EVPN Multi-Site, alavancando funções de Border Gateway (BGW) baseadas em hardware para localizar domínios de falha, mantendo a mobilidade de workload contínua.

A Falácia da Fabric Esticada

Por anos, arquitetos de rede buscaram o "santo graal" de uma fabric única e unificada através de múltiplos sites físicos. Essa abordagem, embora teoricamente simplificasse vMotion e consistência de IP, criou um ambiente frágil de "fate-sharing". Uma única tempestade BUM (Broadcast, Unknown Unicast, Multicast) no Site A poderia, e frequentemente o fazia, derrubar os Sites B e C simultaneamente. A implementação NX-OS da Cisco de VXLAN EVPN Multi-Site resolve isso desacoplando os protocolos de site internos da Inter-Site Network (ISN).

Em um design Multi-Site padrão, cada site opera seu próprio control plane BGP EVPN independente. Os Border Gateways (BGWs) atuam como o ponto de terminação para túneis VXLAN intra-site e o ponto de origem para túneis inter-site. Ao contrário do esticamento tradicional, o BGW reescreve o Next-Hop e modifica os Route Targets, garantindo que o aprendizado de MAC/IP seja isolado. Se ocorrer um loop no Site A, o Spanning Tree ou os mecanismos de controle de tempestade dentro desse site o pegam antes que se propague através do link ISN de alta latência.

Seleção de Hardware: Cloud Scale ou Nada

Não tente executar Multi-Site em switches Nexus 9300 de primeira geração. Você precisa dos ASICs Cloud Scale (EX, FX, FX2, FX3, ou as séries mais recentes GX/GX2) para suportar a terminação VXLAN-para-VXLAN necessária e as entradas TCAM para mapeamento L3VNI e L2VNI. Especificamente para a função de Border Gateway, o Nexus 9364C-GX ou o 9336C-FX2 são nossos padrões ouro para densidade de 100G/400G.

A série 9300-GX é particularmente crítica em 2026 à medida que avançamos para backbones de 400G. Eles fornecem os deep buffers necessários para lidar com micro-bursts que ocorrem na transição de spines internos de alta largura de banda para circuitos ISN potencialmente de menor largura de banda. Evite a série 9200 para funções de BGW; a paridade de recursos simplesmente não existe para implantações complexas de EVPN Multi-Site.

Arquitetura do Border Gateway (BGW)

O Border Gateway é o componente mais crítico neste design. Você tem dois modelos de implantação primários: BGW Distribuído (Spines como BGWs) ou BGW Dedicado (Leafs como BGWs). Na TechLeague, nós quase exclusivamente recomendamos o modelo de BGW Dedicado (Border Leafs) para ambientes empresariais de larga escala. Embora usar Spines como BGWs economize alguns RUs de espaço em rack, isso força seus spines a manter uma tabela de roteamento BGP completa para o mundo externo, aumentando a pressão da CPU e complicando seu limite de gerenciamento.

Alta Disponibilidade: Anycast BGW vs. vPC BGW

Engenheiros da velha guarda ainda tentam colocar seus BGWs em um par vPC. Isso é um erro. VXLAN EVPN Multi-Site suporta o modelo de Anycast BGW (IP virtual). Nesta configuração, múltiplos BGWs compartilham o mesmo endereço IP anycast para o VTEP (VXLAN tunnel endpoint). Usar Anycast BGW permite até 6 ou 8 caminhos ECMP através da ISN, proporcionando resiliência e throughput muito maiores do que um cluster vPC de dois nós.


evpn multisite border-gateway 100
  delay-restore time 30
  provision-model anycast-gw
  multisite-id 1

Ao usar o modelo anycast, você elimina a necessidade de um vPC Peer-Link entre os gateways, que tradicionalmente tem sido um ponto de falha em ambientes sensíveis à convergência. Se um BGW falhar, a convergência BGP na ISN simplesmente redireciona o tráfego para os outros membros anycast sem exigir negociação LACP complexa.

A Inter-Site Network (ISN): Pare de Complicar Demais

A ISN é frequentemente a parte mais mal compreendida do design. Ela não precisa falar EVPN. Na verdade, não deveria. A ISN é puramente um meio de transporte que fornece IP reachability entre os VTEPs BGW. Ela deve suportar MTU 1550+ (para acomodar o cabeçalho VXLAN de 50 bytes) e executar um IGP como OSPF ou IS-IS.

Os BGWs estabelecem peerings MP-BGP EVPN Multi-Hop uns com os outros sobre a ISN. Defendemos fortemente o uso de BGP Peer Groups para gerenciar essas conexões, especialmente ao escalar além de três sites. Aqui está um snippet de configuração típico de BGW para peering ISN:


router bgp 65001
  neighbor 10.255.255.10 remote-as 65002
    description Peer_to_Site_B_BGW
    update-source loopback1
    ebgp-multihop 5
    address-family l2vpn evpn
      send-community extended
      rewrite-evpn-rt-asn

O comando rewrite-evpn-rt-asn é vital. Ele permite que o BGW traduza Route Targets entre sites, garantindo que os labels sejam interpretados corretamente à medida que o tráfego se move pela ISN.

L3 Multicast e Tratamento de Tráfego BUM

Lidar com o tráfego BUM entre sites sem sobrecarregar sua WAN é o diferencial entre um administrador júnior e um engenheiro sênior. Você tem duas escolhas: Ingress Replication (IR) ou Local-Bias Multicast. Para designs de 2026, Ingress Replication com otimizações Multi-Site é o padrão, a menos que você tenha requisitos muito específicos de multicast de alta largura de banda. O IR cria cópias unicast individuais de pacotes BUM para cada site remoto, mas o BGW é inteligente o suficiente para enviar apenas uma cópia para o site remoto, que o BGW remoto então replica localmente para seus leafs. Essa "Head-end Replication" reduz significativamente a carga de largura de banda na sua ISN.

Se você precisar usar Multicast no core, certifique-se de que sua ISN suporte PIM-BSR ou PIM-RP. No entanto, a complexidade de gerenciar um RP através de múltiplos domínios administrativos geralmente supera os ganhos de eficiência para 90% das empresas.

Segurança e Política: Micro-segmentation com Group-Based Policy (GBP)

O VXLAN EVPN padrão apenas transporta o VNI e as informações L2/L3. Se você deseja manter a postura de segurança entre sites, deve implementar VXLAN-GPO (Group-Based Policy). Isso permite que você carregue SGTs (Scalable Group Tags) no cabeçalho VXLAN. Quando um usuário no Site A (SGT 10) se comunica com um servidor no Site B, o BGW preserva essa tag. Isso permite que seus firewalls ou leafs Nexus no Site B apliquem políticas com base no SGT, em vez de um endereço IP que pode ter mudado.

Como detalhamos em nosso guia sobre Nexus ACI vs. Standalone EVPN, a orquestração manual de SGTs no NX-OS é o principal "ponto de dor" que muitas vezes leva os clientes ao ACI. No entanto, se você é um negócio que prefere CLI, manter o NX-OS Multi-Site oferece melhor visibilidade do control plane e evita a natureza de "caixa preta" do APIC.

Verificação e Realidade Operacional

A resolução de problemas Multi-Site requer um domínio dos comandos show nve multisite. Você não está apenas verificando a adjacência; você está verificando se o BGW está realmente anunciando o site-id correto. Um ponto comum de falha é a incompatibilidade de Site-IDs dentro da mesma fabric, o que faz com que o BGW desligue o VIP Inter-Site para evitar loops.


# Verifique o status do BGW
show nve multisite border-gateway
# Verifique a acessibilidade do site remoto
show bgp l2vpn evpn summary
# Verifique o mapeamento VNI entre sites
show nve vni

Espere que a latência de sua ISN desempenhe um papel na convergência BGP. Ajuste seus timers keepalive e holdtime, mas não vá para menos de um segundo, a menos que você tenha um link de fibra escura dedicado. Em um tráfego WAN padrão de 10ms-20ms, um keepalive de 3 segundos é o "sweet spot" para evitar flapping durante pequenos eventos de jitter.

Conclusão

Cisco Nexus 9000 VXLAN EVPN Multi-Site é a única maneira de escalar data centers modernos sem herdar os riscos de um domínio Layer 2 gigante e plano. Ao usar Anycast BGWs e ASICs Cloud Scale, você constrói um ambiente resiliente e multi-homed que suporta as demandas de alta velocidade de 2026. Se o seu design atual depende de vPCs esticados ou overlays OTV complexos, é hora de fazer o re-platform. Para obter uma análise especializada do seu design de fabric ou para trazer uma equipe de engenharia Tier-3 para sua implantação, visite nossa página de preços techleague.io para ver como podemos acelerar a modernização da sua infraestrutura.