Visão geral da arquitetura spine colapsada com multihoming EVPN
Sobre este exemplo de configuração de rede
Este exemplo de configuração de rede (NCE) mostra como configurar uma malha de data center spine colapsada que permite que você use seus switches top-of-rack de Camada 2 existentes no lugar de dispositivos leaf. Ele também mostra como usar o multihoming EVPN para fornecer funcionalidade LAG multichassis para switches top-of-rack de Camada 2.
Além disso, ele mostra opcionalmente como configurar a interconexão de data center e serviços avançados de segurança para tráfego entre locatários por meio de um cluster de chassi SRX.
A Juniper Networks requer uma licença para EVPN-VXLAN em switches da Série QFX. Consulte o Guia de licenciamento para obter mais informações.
Veja também
Visão geral do caso de uso
Grandes data centers empresariais estão migrando para arquiteturas baseadas em overlay usando uma malha IP de ponta a ponta com um overlay VXLAN e um plano de controle EVPN. Usando uma underlay baseada em IP de Camada 3 no núcleo, juntamente com um overlay EVPN-VXLAN nos switches top-of-rack (ToR), os operadores de data center e nuvem podem implantar redes muito maiores do que são possíveis com arquiteturas tradicionais baseadas em Ethernet de Camada 2.
No entanto, os switches ToR legados podem não oferecer suporte a EVPN-VXLAN. Nos data centers com esses switches ToR que oferecem suporte apenas ao tráfego de Camada 2, os switches spine são responsáveis pelo roteamento entre VLAN. É necessária uma arquitetura de data center que desacopla a rede underlay da rede de sobreposição de locatários com tecnologias como a VXLAN. Você pode realizar isso com uma arquitetura spine colapsada.
Uma arquitetura spine colapsada não tem camada leaf. Em vez disso, a underlay baseada em IP de Camada 3 e a funcionalidade de overlay EVPN-VXLAN que normalmente é executado em switches leaf são colapsadas nos switches spine. Os switches spine também atuam como um gateway de borda.
Uma arquitetura spine colapsada com multihoming EVPN é ideal para organizações com:
Planeja migrar para uma arquitetura baseada em malha ip com overlay EVPN-VXLAN.
Pequenos data centers com um padrão de tráfego principalmente norte-sul.
Uma necessidade de estender o tráfego de Camada 2 por data centers.
Switches ToR legados de vários fornecedores que não oferecem suporte a EVPN-VXLAN.
Requisitos atuais ou futuros para oferecer suporte a mais de dois switches spine para garantir uma largura de banda adequada durante a manutenção ou uma falha na spine.
Uma necessidade de uma alternativa a uma arquitetura MC-LAG (protocolo ICCP).
Visão geral técnica
- Spine colapsada com visão geral da arquitetura multihoming EVPN
- Entendendo a arquitetura spine colapsada
- Entendendo o multihoming da EVPN
- Entendendo o VXLAN
- Entendendo a EVPN
- Rede overlay
- Rede underlay
- Top-of-Rack Switches
- Servidores
- Cluster de chassi SRX
Spine colapsada com visão geral da arquitetura multihoming EVPN
Este NCE mostra como implantar uma arquitetura spine colapsada para dois data centers que cada um tem dois switches spine QFX5120 e dois switches ToR de Camada 2 implantados como um Virtual Chassis. Os data centers estão conectados entre si por meio de dispositivos spine com a Interconexão de Data Center de Camada 3 (DCI). Use o multihoming EVPN para multicascar os switches ToR para os dispositivos spine. Os servidores são multihomed para os switches ToR. A Figura 1 mostra a arquitetura spine colapsada completa.
EVPN
Para suporte multicast, oferecemos:
-
Multicast de camada 3 em uma QFX5120 design spine colapsado usando OISM EVPN com domínios de ponte simétrica.
-
IGMPv2 multicast de Camada 2 bisbilhotando eVPN-VXLAN usando:
-
Rotas de EVPN Seletiva multicast Ethernet Tag (SMET) Tipo 6
-
A EVPN se junta e deixa sincronizar (Tipo 7 e Tipo 8) quando um receptor multicast é multihomed na Camada 2 até os dispositivos spine colapsados usando um ESI-LAG.
-
Entendendo a arquitetura spine colapsada
Em uma arquitetura spine colapsada, os dispositivos spine agem como dispositivos spine e leaf. Como os ToRs são apenas de Camada 2 e não oferecem suporte ao VXLAN, eles não agem como dispositivos leaf. A atividade normal do dispositivo leaf é tratada ou colapsada nos dispositivos spine, o que significa que o VXLAN é necessário apenas nos dispositivos spine. A spine colapsada opera como um gateway de Camada 3 e lida com o tráfego entre as VXLANs usando interfaces IRB.
Entendendo o multihoming da EVPN
Em um data center legado com uma arquitetura spine colapsada, os switches ToR precisam ser conectados aos switches spine com grupos de agregação de enlaces multichassis (MC-LAGs) para melhorar a resiliência da rede. O MC-LAG oferece redundância no nível de nó e redundância no nível do link. Tradicionalmente, os switches spine nesses data centers usam o Inter-Chassis Control Protocol (ICCP) para fornecer funcionalidade MC-LAG. No entanto, MC-LAG com ICCP:
É uma tecnologia proprietária.
Não é possível estender de forma eficiente a Camada 2 entre data centers.
Não oferece suporte a mais de dois switches spine.
A EVPN oferece uma solução de multihoming baseada em padrões que escala horizontalmente em dois ou mais switches spine para obter resiliência e largura de banda adicionais em caso de falha na spine. O multihoming EVPN, também conhecido como ESI-LAG, oferece funcionalidade MC-LAG para os switches ToR de Camada 2 e os servidores nesta arquitetura sem as desvantagens do MC-LAG baseado em ICCP.
Uma arquitetura spine colapsada onde os switches ToR são multihomed para as spines é uma arquitetura de data center que oferece suporte a switches ToR legados quando eles não oferecem suporte à EVPN-VXLAN. A Figura 2 mostra uma arquitetura spine colapsada com dois switches spine para simplicidade e um dispositivo ToR implementado como um Virtual Chassis (ver Understanding Virtual Chassis).
ToR
Veja também
Entendendo o VXLAN
Os overlays de rede são criados encapsulando o tráfego e tunelando-o em uma rede física. O protocolo de tunelamento VXLAN encapsula quadros Ethernet de Camada 2 em pacotes UDP de Camada 3. O VXLAN permite sub-redes ou segmentos virtuais de Camada 2 que podem abranger a rede física de Camada 3 subjacente.
Em uma rede overlay VXLAN, cada sub-rede ou segmento de Camada 2 é identificada exclusivamente por um identificador de rede virtual (VNI). Um VNI segmenta o tráfego da mesma maneira que um VLAN ID segmenta o tráfego. Como acontece com as VLANs, os endpoints dentro da mesma rede virtual podem se comunicar diretamente entre si. Endpoints em diferentes redes virtuais exigem um dispositivo que ofereça suporte ao roteamento entre VNI.
A entidade que executa o encapsulamento e a descapsulação VXLAN é chamada de endpoint de túnel VXLAN (VTEP). Cada VTEP normalmente recebe um endereço IP exclusivo.
Entendendo a EVPN
A EVPN é uma das extensões para BGP que permite que a rede carregue informações de acessibilidade de camada de rede (NLRI), como endereços MAC de Camada 2 e endereços IP de Camada 3. Essa tecnologia de plano de controle usa MP-BGP para distribuição de endpoint de endereço MAC e IP, onde os endereços MAC são tratados como rotas. A EVPN permite que os dispositivos atuem como VTEPs para trocar informações de alcance entre si sobre seus endpoints.
A EVPN oferece encaminhamento e redundância multicaminho por meio de um modelo totalmente ativo. A camada de acesso pode se conectar a dois ou mais dispositivos spine e encaminhar tráfego usando todos os links. Se um link de acesso ou dispositivo spine falhar, o tráfego flui da camada de acesso em direção à camada spine usando os links ativos restantes. Para tráfego em outra direção, os dispositivos spine remotos atualizam suas tabelas de encaminhamento para enviar tráfego aos dispositivos spine ativos restantes conectados ao segmento Ethernet multihomed.
Rede overlay
Essa arquitetura usa o VXLAN como protocolo de encapsulamento de plano de dados overlay e MP-BGP com sinalização EVPN como protocolo de plano de controle de overlay.
Overlay de plano de dados
Essa arquitetura usa o VXLAN como o protocolo de encapsulamento do plano de dados overlay nos switches spine colapsado. Um switch que funciona como um gateway VXLAN de Camada 2 ou Camada 3 atua como o endpoint do túnel VXLAN e pode encapsular e descapsular pacotes de dados.
Em uma única implantação de data center com dois switches spine, a sobreposição VXLAN entre os switches spine é usada para tráfego entre os dois dispositivos. Por exemplo, se houver um servidor de casa única conectado a um dos dispositivos spine, o overlay VXLAN leva o tráfego para o outro dispositivo spine, seja por design ou no caso de uma falha no link.
Como mostrado na figura abaixo, o servidor DHCP é de casa única para o Spine 1. O tráfego do cliente DHCP pode ser enviado para a Spine 2 por causa do compartilhamento de carga. O Spine 2 envia o tráfego para o servidor DHCP sobre a sobreposição VXLAN com o Spine 1.
sobreposição de plano de dados
Overlay de plano de controle
MP-BGP com sinalização EVPN atua como o protocolo de plano de controle de overlay neste exemplo. Os switches spine estabelecem sessões de IBGP entre si. A Figura 4 mostra a topologia da rede overlay.
overlay de plano de controle
Veja também
Rede underlay
Em data centers menores não há camada super spine, então os switches spine estão diretamente conectados entre si. Os switches spine podem usar um protocolo de roteamento dinâmico no underlay. O principal requisito na rede underlay é que todos os dispositivos spine tenham acessibilidade de loopback. Você pode usar qualquer protocolo de roteamento de Camada 3 para trocar endereços de loopback entre os dispositivos de núcleo e spine.
Neste exemplo, usamos o EBGP como o protocolo de roteamento underlay entre os switches spine. O EBGP oferece benefícios como uma melhor filtragem de prefixo, engenharia de tráfego e tags de tráfego. A Figura 5 mostra a topologia da rede spine underlay.
spine underlay
Use pelo menos duas ligações entre os switches spine. A perda de conectividade entre os switches spine pode levar a um estado de cérebro dividido. Consulte o Split-Brain State para obter mais informações.
Top-of-Rack Switches
Como os switches ToR não participam da malha EVPN-VXLAN e operam apenas na Camada 2, você pode implementá-los como um Virtual Chassis. Neste exemplo, os switches ToR são implantados como um Virtual Chassis de dois membros.
Os uplinks dos switches ToR para os switches spine são portas LAG de tronco de Camada 2 com VLANs relevantes para o switch ToR. Cada Virtual Chassis é multihomed para dois switches spine usando multihoming EVPN. A Figura 6 mostra a topologia de um Virtual Chassis como um dispositivo ToR que é multihomed para os dois dispositivos spine. Para redundância e melhor resiliência, esse número mostra conexões spine para ToR Virtual Chassis que se conectam a diferentes membros do Virtual Chassis, de modo que o dispositivo Virtual Chassis ToR ainda é acessível mesmo se um dos membros do Virtual Chassis cair.
do switch tor
As conexões spine to ToR Virtual Chassis nos links Ethernet agregados multihoming também podem incluir links para o mesmo membro do Virtual Chassis, que é como este exemplo de configuração de rede é configurado. A Figura 7 mostra uma visão lógica da topologia multihoming que combina com a configuração deste documento.
de configuração de rede
Entendendo o Virtual Chassis
Neste exemplo, implementamos os switches ToR em um Virtual Chassis. O Virtual Chassis pode interconectar vários switches autônomos em um único dispositivo lógico e gerenciar o dispositivo lógico como um único chassi. Use o Virtual Chassis para os switches ToR para:
Gerencie vários dispositivos como um único dispositivo com os mesmos ou semelhantes recursos que o dispositivo autônomo.
Aumente a tolerância a falhas e a alta disponibilidade.
Achate sua rede e reduza a sobrecarga da rede, permitindo que os dispositivos de rede sincronizam com um dispositivo lógico resiliente.
Habilite uma topologia de rede de Camada 2 simplificada que minimiza ou elimina a necessidade de protocolos de prevenção de loop, como o Spanning Tree Protocol (STP).
Forneça redundância e compartilhamento de carga para servidores multihomed entre os membros do Virtual Chassis.
O Virtual Chassis oferece um plano de controle único e um plano de dados distribuído para gerenciamento simplificado na camada ToR. Os switches ToR se comportam como placas de linha em um único chassi. Como o Virtual Chassis se comporta como um único chassi, os servidores conectados ao Virtual Chassis podem experimentar inatividade durante as atualizações de software dos switches ToR.
Veja também
Servidores
Os servidores de data center neste exemplo são multihomed para os switches ToR que são implantados como um Virtual Chassis. A conectividade do servidor pode ser distribuída entre os dois switches ToR com LAG.
multihomed
Cluster de chassi SRX
Neste exemplo, estamos implantando dispositivos de segurança SRX em um cluster de chassi que está conectado aos dispositivos spine para fornecer segurança avançada. Em um cluster de chassi, dois firewalls da Série SRX operam como um único dispositivo para fornecer redundância de dispositivo, interface e nível de serviço. Os arquivos de configuração e os estados dinâmicos de sessão de tempo de execução são sincronizados entre firewalls da Série SRX em um cluster de chassi. Use um cluster de chassi SRX para:
Evite falhas em um único dispositivo que resultem em perda de conectividade.
Forneça alta disponibilidade entre dispositivos de segurança ao conectar links de filiais e locais remotos a escritórios corporativos maiores.
Garanta a conectividade em caso de falha em um dispositivo ou link.
de cluster do chassi SRX