Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Interconexão de data center (DCI) / Gateways EVPN remotos (virtual)

Overvew de gateway DCI /EVPN

Historicamente, as empresas utilizam a tecnologia de Interconexão de Data Center (DCI) como um bloco de construção para a continuidade dos negócios, recuperação de desastres (DR) ou continuidade das operações (COOP). Esses casos de uso de disponibilidade de serviços dependiam principalmente da necessidade de conectar data centers geograficamente separados com conectividade de Camada 2 para disponibilidade e desempenho de aplicativos.

Com o surgimento de data centers definidos por software (SDDC), computação em nuvem e, mais recentemente, computação de borda, surgiram casos de uso adicionais:

  • Expansão de colocation: compartilhe recursos de computação e armazenamento para instalações de data center de colocation.
  • Agrupamento de recursos: compartilhe e mude aplicativos entre data centers para aumentar a eficiência ou melhorar a experiência do usuário final.
  • Escalabilidade rápida: expanda a capacidade de um local limitado a recursos para outra instalação ou data center.
  • Migração legável: mova aplicativos e dados de equipamentos e arquitetura mais antigos e ineficientes para uma arquitetura mais eficiente, de alto desempenho e econômica.

Com o software Apstra, você pode implantar e gerenciar uma solução de DCI inclusiva de fornecedor que é simples, flexível e baseada em intenção. O Apstra utiliza o MP-BGP EVPN baseado em padrões com VXLAN, que alcançou ampla adoção de software e hardware no setor de redes. Você pode escolher entre uma vasta seleção de hardware de commodities econômicos, de fornecedores tradicionais a ODMs e opções de software que vão desde sistemas operacionais de rede (NOS) integrados por fornecedores convencionais até opções de código aberto desagregadas.

A EVPN VXLAN é uma abordagem baseada em padrões (RFC-7432) para a construção de data centers modernos. Ele incorpora tanto o encapsulamento de plano de dados (VXLAN) quanto um plano de controle de roteamento (MP-BGP EVPN Address Family) para estender os domínios de transmissão de Camada 2 entre hosts e domínios roteado de Camada 3 em redes spine-leaf. Contando com uma camada inferior de Camada 3 pura para o roteamento do tráfego em túnel VXLAN entre os Endpoints do túnel VXLAN (VTEPs), a EVPN introduz uma nova família de endereços à família de protocolo MP-BGP e oferece suporte à troca de endereços MAC/IP entre VTEPs. O anúncio de MACs e IPs de endpoint, bem como a "supressão de ARP/ND", elimina a necessidade de uma grande maioria do tráfego Broadcast/Desconhecido/Multicast (BUM) e depende do roteamento unicast ECMP do VXLAN, do VTEP de origem ao VTEP de destino. Isso garante uma seleção de rotas ideal e um compartilhamento eficiente de carga de caminhos de encaminhamento para tráfego de rede overlay.

Assim como a EVPN VXLAN funciona em um único local para estender a Camada 2 entre hosts, o recurso DCI permite a conectividade de Camada 2 entre os locais. O recurso Apstra DCI permite a extensão dos serviços de Camada 2 ou Camada 3 entre data centers para recuperação de desastres, balanceamento de carga de locais ativos ou mesmo para facilitar a migração de serviços de um data center para outro.

Limitações:

  • A EVPN-GW (DCI) entre a malha EVPN de diferentes fornecedores não é suportada.

  • O IPv6 não é suportado em gateways EVPN remotos. (Rotas EVPN reais podem conter IPv6 Tipo 2 e Tipo 5.)

Opções de implantação de DCI

Você pode implementar a Interconexão de Data Center usando os seguintes métodos:

  • Exagerado
  • Gateways (GW)
  • Roteador de borda de sistema autônomo (ASBR)

Para obter assistência na seleção da melhor opção para sua organização, consulte seu Arquiteto de Soluções Apstra (SA) ou Engenheiro de Sistemas (SE).

As seguintes características se aplicam a todas as opções de implantação:

  • Você pode estender o Apstra DCI para outros data centers gerenciados pelo Apstra, data centers gerenciados fora do Apstra ou até mesmo para dispositivos não spine-leaf legados.
  • A implementação e o comportamento do Apstra são os mesmos nos três casos.
  • Não importa se a extremidade remota é outra DCI GW ou uma ASBR, ela é transparente para o Apstra.
  • O Apstra não gerencia nem os GWs nem os ASBRs.

Exagerado

DCI "Over the Top" é uma solução transparente, o que significa que as rotas EVPN são encapsuladas em IP padrão e ocultas do transporte subjacente. Isso torna a extensão dos serviços simples e flexível e muitas vezes é escolhida porque as equipes de data center podem implementá-la com pouca ou nenhuma coordenação com grupos de WAN ou provedores de serviços. Isso reduz os tempos de implementação e os atritos internos da empresa. No entanto, a compensação é escalabilidade e resiliência.

Gateway (GW)

Com base no recurso de gateway EVPN remoto do Apstra, você pode especificar opcionalmente que o gateway EVPN remoto é um sistema genérico externo (marcado como um roteador externo) no mesmo site, estendendo assim os atributos EVPN para o referido gateway. Essa solução cria um domínio de falhas por site, impedindo que falhas afetem a convergência em locais remotos e criando vários domínios de falhas. As tabelas de endpoint IP/MAC para locais remotos são processadas e mantidas em estado em um gateway genérico (marcado como roteador externo). Você também pode implementar qoS e segurança wan, juntamente com otimizações que a tecnologia de transporte disponibiliza (MPLS TE, por exemplo). No entanto, essa solução é mais complexa operacionalmente, exigindo hardware e custo adicionais.

Roteador de borda de sistema autônomo (ASBR)

Usando o recurso de gateway EVPN remoto do Apstra, você pode especificar opcionalmente que o gateway EVPN remoto é um dispositivo de borda ASBR WAN. Essa EVPN de ponta a ponta permite o encapsulamento uniforme e remove o requisito de GW dedicado. Ele é operacionalmente complexo, mas tem maior escalabilidade em comparação com "DCI Usando Gateway" e "Over the Top".

Implementação

Você pode estender zonas de roteamento e redes virtuais (VN) para abranger blueprints gerenciados pelo Apstra (em pods) ou até redes remotas (entre data centers) que o Apstra não gerencia. Esse recurso introduz a função EVPN Gateway (GW), que pode ser um switch que participa da malha ou do RouteServer(s) em um sistema genérico (tagado como servidor) que é conectado à malha.

Casos de uso de gateways EVPN

  • Abrange domínios de isolamento de Camada 3 (VRFs/zonas de roteamento) a vários pods gerenciados pelo Apstra (blueprints) ou se estendem a domínios remotos de EVPN.
  • Forneça extensões de domínio de Camada 2 para redes virtuais/L2VNI.
  • Ajude a estender o domínio EVPN do Apstra para o Apstra gerenciado e o Apstra para pods não gerenciados.
  • Sem terminação de tráfego VXLAN nos dispositivos spine — conecte sistemas genéricos externos (marcados como roteadores externos) em dispositivos spine. Isso é para oferecer suporte à conectividade externa IPv4 (underlay). Aqui, os dispositivos spine não precisam encerrar o tráfego VXLAN, ao contrário dos dispositivos leaf de borda, quando conectados a sistemas genéricos externos (marcados como roteadores externos). Em poucas palavras, usar isso pode trocar rotas IPv4 por VTEPs remotos (na zona de roteamento padrão/VRF) e apenas a conectividade de Camada 3 é necessária:

Exagerado

Quando o peering EVPN BGP é feito "por cima", o gateway de data center (DC-GW) é uma função de transporte IP pura e o peering BGP EVPN é estabelecido entre gateways em diferentes data centers.

As próximas seções descrevem os procedimentos para interconectar dois ou mais sites de VPN Ethernet (EVPN) baseados em BGP de forma escalável em uma rede IP. A motivação é dar suporte à extensão de sites EVPN sem precisar confiar em tecnologias típicas de Interconexão de Data Center (DCI), como MPLS/VPLS, que muitas vezes são difíceis de configurar, às vezes proprietárias e provavelmente legadas por natureza.

"Over the Top" é uma solução simples que só requer roteamento IP entre data centers e um MTU ajustado para oferecer suporte ao encapsulamento de VXLAN entre endpoints de gateway. Em tal implementação, as rotas EVPN são estendidas de ponta a ponta via MP-BGP entre os locais. O BGP multi-hop é habilitado com a suposição de que haverá vários saltos de Camada 3 entre sites em uma WAN. Caso contrário, os decrementos de TTL padrão para 0 e pacotes são descartados e não chegam ao roteador remoto. O Apstra torna automaticamente a configuração necessária para atender a essas limitações.

Esse design mescla os domínios EVPN-VXLAN separados e túneis VXLAN entre os locais. A fusão de domínios EVPN anteriormente separados em diferentes locais realiza o benefício de estender os serviços de Camada 2 e Camada 3 (VRF) entre sites, mas também torna os sites como um único domínio de falha. Assim, uma falha em um site é necessariamente propagada. Além disso, sempre que você estende a Camada 2 pela WAN entre os locais, você também está estendendo o domínio de inundação e, juntamente com ele, todo o tráfego de transmissão em seus dispendiosos links WAN. Neste momento, essa solução não oferece nenhuma filtragem ou QoS.

Nota:

Quando os blueprints do Apstra separados gerenciam sites individuais (ou quando apenas um site é gerenciado pelo Apstra) você deve criar e gerenciar zonas de roteamento estendidas (VRFs) e redes virtuais (Camada 2 e/ou Sub-redes definidas de Camada 3) de forma independente em cada site. Você deve mapear manualmente VRFs e VNs entre sites (criando sobrecarga administrativa).
Nota:

Se você estiver configurando conexões P2P entre dois data centers (blueprints) no mesmo controlador Apstra, cada blueprint deve retirar recursos de diferentes pools de IP para evitar erros de construção. Para isso, crie dois pools de IP com a mesma sub-rede IP, mas com nomes diferentes.

Essa solução "Over the Top" é a mais fácil de implantar, não requer hardware adicional e não introduz nenhuma configuração wan adicional além de aumentar o MTU. É o mais flexível e tem a menor barreira à entrada. No entanto, a desvantagem é que existe um único plano de controle EVPN e uma anomalia de roteamento em um local afetará a convergência e a acessibilidade no(s) outro(s) local(s). A extensão dos domínios de inundação de Camada 2 também implica que uma tempestade de broadcast em um local se estende para o(s) outro(s) site(s).

Com qualquer implementação de DCI, é necessário planejamento e coordenação cuidadosos de recursos. Adicionar mais sites requer um aumento exponencial nesse planejamento e coordenação. Os loopbacks de VTEP na underlay precisam ser vazados. Os VNIDs devem combinar entre locais e, em alguns casos, devem ser importados alvos de rota (RTs) adicionais. Isso é detalhado mais tarde neste documento.

Extensão do plano de dados: Camada 3

Os VXLAN Network IDs (VNIDs) são uma parte do cabeçalho VXLAN que identifica túneis VXLAN exclusivos, cada um dos quais estão isolados dos outros túneis VXLAN em uma rede IP. Os pacotes de camada 3 podem ser encapsulados em um pacote VXLAN ou quadros MAC de Camada 2 podem ser encapsulados diretamente em um pacote VXLAN. Em ambos os casos, um VNID exclusivo está associado à sub-rede de Camada 3 ou ao domínio de Camada 2. Ao estender os serviços de Camada 3 ou Camada 2 entre os locais, você está essencialmente costurando túneis VXLAN entre os locais. Portanto, os VNIDs precisam combinar entre sites.

É importante entender que um VNID em particular estará associado a apenas um VRF (ou zona de roteamento no Apstra). Os VNIDs existem dentro de um VRF. Eles estão ligados a um VRF. Para serviços de Camada 3, a costura, ou extensão, de cada VNID é feita com a exportação e importação de RTs dentro de uma zona de roteamento (VRF). As sub-redes de camada 3 (rotas) são identificadas via RTs. Todos os VNIDs são exportados automaticamente no gateway EVPN (borda) em direção à WAN. Por outro lado, as RTs com o mesmo valor são importadas automaticamente no gateway EVPN (borda) que entra na malha. Então, se você coordenar os VNIDs de Camada 3 em um local para combinar com o outro, nenhuma configuração adicional será necessária.

Na imagem acima, não é necessária nenhuma exportação ou importação adicional. Tudo é exportado automaticamente (Export All) e, como os RTs correspondem, eles são automaticamente importados.

No entanto, se um VNID em DC1 for diferente de um VNID em DC2, então você deve importar os RTs, respectivamente. Cada gateway respectivo ainda importa automaticamente RTs do mesmo valor. No exemplo abaixo, é necessária uma etapa adicional de adicionar manualmente os RTs do outro site.

Extensão do plano de dados: Camada 2

Uma rede virtual pode ser um serviço de Camada 2 puro (o gateway anycast de Camada 3 não é instanciado). Ele pode ser rack-local (VLAN em portas voltadas para servidor contidas em um rack) ou VXLAN (selecione os racks para estender o domínio de inundação de Camada 2 e broadcast entre racks. Este domínio de Camada 2 tem seu próprio VNID, e os quadros MAC (em oposição aos pacotes IP) são encapsulados no cabeçalho VXLAN com o VNID do domínio de Camada 2.

Os mesmos princípios se aplicam à exportação de todos os VNIDs no gateway EVPN (neste caso, os endereços Tipo 2/MAC) e os RTs correspondentes são automaticamente importados. No entanto, a localização da importação e exportação de RTs não está no nível da zona de roteamento, mas sim na própria rede virtual.

Fluxo de trabalho do Apstra

Extensão de plano de controle: gateway EVPN

O Apstra usa o conceito de um "gateway EVPN". Este dispositivo pode teoricamente ser um nó de malha leaf, spine ou superspine, bem como o dispositivo DCI. Os gateways EVPN separam o lado da malha da rede que interconecta os locais e mascara os VTEPs internos do site.

No Apstra, um gateway EVPN é um dispositivo que pertence e reside na borda de uma malha EVPN que também é anexada a uma rede IP externa. Em um modelo EVPN do Apstra, este é sempre um dispositivo border-leaf. O gateway EVPN de um data center estabelece peering EVPN BGP com um gateway EVPN recíproco, ou gateways, em outro data center. O "outro" gateway EVPN é o "gateway EVPN remoto" no Apstra. Assume-se que o gateway EVPN local seja um dos dispositivos gerenciados pelo Apstra no blueprint e é selecionado ao criar o "Gateway EVPN remoto". O gateway EVPN local será o switch border-leaf com uma ou mais conexões de roteamento externas para tráfego dentro e fora da malha EVPN Clos.

Devido a esse recurso, você pode configurar um gateway EVPN local (sempre um switch gerenciado pelo Apstra) para peer com um dispositivo não gerenciado pelo Apstra, ou mesmo um dispositivo não Spine-Leaf, em outro DC. O peering BGP do gateway EVPN é usado para transportar todos os atributos EVPN de dentro de um pod para fora do pod. No ambiente Apstra, cada blueprint representa um data center. Se dois ou mais sites estiverem sob o gerenciamento do Apstra, você ainda deve configurar cada site para apontar para o(s) Gateway (s) EVPN remoto em outros sites. Recomendamos que você crie vários gateways EVPN redundantes para cada data center. Atualmente, também existe um requisito de malha completa entre gateways EVPN, embora em versões futuras esse requisito seja removido.

Anúncios de rota VTEP underlay

A acessibilidade underlay para endereços IP VTEP, ou uma rota sumária equivalente, deve ser estabelecida de forma recíproca. Cada site deve anunciar esses loopbacks VTEP de dentro da zona de roteamento padrão para os anúncios underlay BGP (IPv4) exportados. Os loopbacks na política de roteamento são habilitados por padrão.

Crie gateways EVPN remotos

CUIDADO:

Por padrão, o msb ESI MAC (byte mais significativo) está definido para 2 em todos os blueprints. Todos os modelos do Apstra conectados devem ter um msb exclusivo para evitar problemas que afetam os serviços. Antes de criar gateways, altere o MSB ESI MAC de acordo. (Você pode deixar um deles pelo valor padrão.)

O gateway EVPN remoto é uma função lógica que você pode instanciar em qualquer lugar e em qualquer dispositivo. Ela requer suporte BGP em geral, L2VPN/EVPN AFI/SAFI especificamente. Para estabelecer uma sessão BGP com um gateway EVPN, conectividade IP, bem como conectividade à porta TCP 179 (IANA aloca portas BGP TCP), deve estar disponível.

Nota:

Para resiliência, recomendamos ter pelo menos dois gateways remotos para o mesmo domínio EVPN remoto.
  1. Desde o blueprint, navegue até o Staged > Virtual > gateways EVPN remotos e clique em Criar gateway EVPN remoto.
  2. No diálogo aberto, preencha as seguintes informações para o gateway EVPN remoto.

    Ao estender as redes L2 entre malhas de data center, você tem a opção (começando pela versão 4.1.0 do Apstra) de trocar apenas prefixos EVPN Tipo RT-5 (modelo sem interface). Isso é útil quando não há necessidade de trocar todas as rotas de host entre locais de data center. Isso resulta em requisitos menores para a base de informações de roteamento (RIB), também conhecida como tabela de roteamento, e a base de informações de encaminhamento (FIB), também conhecida como tabela de encaminhamento, em equipamentos de DCI.

  3. Selecione os nós do gateway local. Estes são os dispositivos no blueprint que serão configurados com um gateway EVPN local. Você pode selecionar um ou mais dispositivos para peer com o gateway EVPN remoto configurado. Você pode usar a função de consulta para ajudar a localizar os nós apropriados. Recomendamos o uso de vários dispositivos border-leaf que tenham conexões diretas com sistemas genéricos externos (marcados como roteadores externos).
  4. Clique em Criar para organizar o gateway e retornar à vista da tabela.
  5. Quando estiver pronto para implantar os dispositivos no blueprint, confirme suas mudanças.

Recomendamos o uso de vários gateways EVPN remotos. Para configurar gateways EVPN remotos adicionais, repita as etapas acima.

Se você estiver configurando o(s) gateway(s) EVPN remoto para outro modelo apstra, você deve configurar e implantar o(s) gateway(s) EVPN remoto(s) separadamente nesse blueprint.

Assim que a mudança é implantada, o Apstra monitora a sessão BGP para os gateways EVPN remotos. Para ver quaisquer anomalias do blueprint, navegue até anomalias active >.

Zona de roteamento aprimorada

Políticas de importação/exportação de RT (route-target) em dispositivos que fazem parte da instalação de rotas EVPN de governança de serviço estendido. Especifique as políticas de destino de rota para adicionar metas de rota de importação e exportação que o Apstra usa para zonas de roteamento/VRFs. Você faz isso quando cria zonas de roteamento. Navegue até zonas de roteamento > virtual > e clique em Criar zona de roteamento. Para obter mais informações, veja Zonas de roteamento.

Nota:

A meta de rota padrão gerada para zonas de roteamento é < VNI>:1. Você não pode alterar esse valor padrão.

Para confirmar se as rotas corretas são recebidas no VTEP, certifique-se de que as L3VNIs e o alvo de rota sejam idênticos entre o blueprint e os domínios remotos de EVPN.

Redes virtuais aprimoradas

Você pode adicionar metas adicionais de importação e exportação que o Apstra usa para redes virtuais.

Nota:

A meta de rota padrão que o Apstra gera para redes virtuais é < VNI>:1. Você não pode alterar isso.

Para comunicação intra-VNI, é usado RT específico L2VNI. O RT de importação é usado para determinar quais rotas recebidas são aplicáveis a um VNI específico. Para estabelecer conectividade, as VNIs de Camada 2 devem ser as mesmas entre o blueprint e os domínios remotos. As sub-redes SVI devem ser idênticas entre domínios.

Representação de topologia de gateway remoto

Os gateways EVPN remotos são representados na visão de topologia como elementos de nuvem com conexões de linha pontilhadas aos elementos de blueprint com os quais as sessões BGP são estabelecidas conforme mostrado na imagem abaixo. (A imagem abaixo é um pouco diferente das versões mais recentes.)