Visão geral multihoming da EVPN
Introdução ao Multihoming EVPN
Uma VPN Ethernet (EVPN) é composta por dispositivos de borda do cliente (CE) conectados a dispositivos de borda de provedor (PE), que formam a borda da infraestrutura MPLS. Um dispositivo CE pode ser um host, um roteador ou um switch. Os dispositivos PE fornecem conectividade de ponte virtual de Camada 2 entre os dispositivos CE. Pode haver várias EVPNs na rede do provedor. O aprendizado entre os roteadores PE ocorre no plano de controle usando BGP, ao contrário da ponte tradicional, onde o aprendizado ocorre no plano de dados.
Em versões anteriores ao Junos OS Release 15.1, o suporte à funcionalidade EVPN em roteadores da Série MX estava limitado a roteadores usando apenas interfaces MPC e MIC. A partir do Junos OS Release 15.1, os roteadores da Série MX usando DPCs podem ser usados para fornecer suporte à EVPN na interface voltada para dispositivos CE.
O suporte de DPC para EVPN é fornecido com as seguintes considerações:
Os DPCs oferecem suporte para a EVPN no modo de operação de espera ativa, incluindo suporte para os seguintes:
Instância EVPN (EVI)
Switch virtual
Interfaces de roteamento e ponte integradas (IRB)
Os DPCs destinados a fornecer o suporte ativo de espera EVPN devem ser a placa de linha voltada para dispositivos CE. O dispositivo PE no domínio EVPN deve ser interfaces MPC ou interfaces MIC.
O recurso multihoming EVPN permite que você conecte um site do cliente a dois ou mais dispositivos de PE para fornecer conectividade redundante. Um dispositivo CE pode ser multihomed para diferentes dispositivos PE ou o mesmo dispositivo PE. Um dispositivo PE redundante pode fornecer serviço de rede ao site do cliente assim que uma falha for detectada. Assim, o multihoming EVPN ajuda a manter o serviço EVPN e o encaminhamento de tráfego de e para o local multihomed no caso dos seguintes tipos de falhas de rede:
Falha no link do dispositivo PE para CE
Falha no dispositivo pe
Falha de alcance do MPLS entre o dispositivo PE local e um dispositivo PE remoto
A Figura 1 ilustra como um dispositivo CE pode ser multihomed para dois roteadores PE. O dispositivo CE 1 é multihomed para roteadores PE 1 e PE 2. O dispositivo CE 2 tem dois caminhos potenciais para chegar ao Dispositivo CE 1, e dependendo do modo multihoming de redundância, apenas um caminho ou ambos os caminhos estão ativos a qualquer momento. O modo de operação multihoming também determina quais roteadores ou roteadores PE encaminham o tráfego para o dispositivo CE. O roteador PE que encaminha o tráfego para o dispositivo CE (também chamado de encaminhamento designado) usa túneis MPLS LSP ou GRE para encaminhar o tráfego. Se ocorrer uma falha nesse caminho, um novo encaminhador designado será eleito para encaminhar o tráfego ao Dispositivo CE 1.
PE
Recursos de multhoming MPLS EVPN suportados por switches QFX10000
A partir do Junos OS 17.4R1, os switches QFX10000 oferecem suporte a multihoming para EVPN MPLS. Apenas o multihoming ativo e ativo é suportado. As subfeaturas a seguir são suportadas:
A configuração de ESI (apenas configuração manual do tipo 0 e IFD (interfaces físicas) são suportadas)
Rota de aliasing e rótulo
Rota EVPN Tipo 4 (rota do segmento Ethernet)
Comunidades estendidas
Tráfego BUM
Funções de Eleição de Encaminhador Designado (DF): DF e BDF
QFX10000 switches em um núcleo MPLS EVPN só suportam a instância de roteamento de switch padrão. Uma instância EVPN (EVI) não é suportada.
Multihoming EVPN MPLS em roteadores ACX5448
A partir do Junos OS Release 19.4R1, os roteadores ACX5448 oferecem suporte a multihoming para EVPN MPLS. Apenas o multihoming ativo e ativo é suportado. Para permitir o multihoming ativo e EVPN em ACX5448 roteador, inclua a evpn-mh-profile declaração de configuração no nível [edit system packet-forwarding-options firewall-profile] de hierarquia.
user@host# set system packet-forwarding-options firewall-profile ? Possible completions: default-profile Set the profile to support default services. evpn-mh-profile Set the profile to support evpn-mh
Depois de mudar o perfil e commetê-lo, você precisa reiniciar o processo de gerenciamento do chassi emitindo o restart chassis-control comando CLI para criar o novo perfil.
Um aviso de syslog parece reiniciar o PFE.
Entendendo os conceitos multihoming da EVPN
A Figura 2 mostra uma topologia de rede EVPN simples para definir conceitos de multihoming EVPN.
EVPN simples
Ethernet segment— Quando um dispositivo CE é multihomed para dois ou mais roteadores PE, o conjunto de links Ethernet constitui um segmento Ethernet. Um segmento de Ethernet aparece como um grupo de agregação de links (LAG) para o dispositivo CE.
Os links dos roteadores PE1 e PE2 para Device CE1 formam um segmento de Ethernet.
Em multihoming de standby ativo, os links que constituem um segmento de Ethernet formam um domínio de ponte. Em multihoming ativo, um segmento de Ethernet aparece como um LAG para o dispositivo CE.
ESI— Um segmento de Ethernet deve ter um identificador não-zero exclusivo, chamado de identificador de segmentoS Ethernet (ESI). A ESI é codificada como um inteiro de 10 octets. Ao configurar manualmente um valor de ESI, o octeto mais significativo, conhecido como byte do tipo, deve ser 00. Quando um dispositivo CE de casa única é conectado a um segmento Ethernet, todo o valor de ESI é zero.
O segmento Ethernet do dispositivo multihomed CE1 tem um valor de ESI de 00:11:22:33:44:55:66:77:88:99 atribuído. O dispositivo CE2 de casa única tem um valor de ESI de 0.
EVI— Uma instância EVPN (EVI) é uma instância de roteamento e encaminhamento EVPN que abrange todos os roteadores de PE que participam dessa VPN. Um EVI é configurado nos roteadores PE por cliente. Cada EVI tem um diferencial de rota exclusivo e um ou mais alvos de rota.
Um EVI está configurado nos roteadores PE1, PE2 e PE3.
Ethernet tag— Uma tag Ethernet identifica um domínio de broadcast específico, como um VLAN. Uma instância EVPN consiste em um ou mais domínios de broadcast. As tags Ethernet são atribuídas aos domínios de broadcast de uma determinada instância EVPN pelo provedor dessa EVPN. Cada roteador PE nessa instância EVPN realiza um mapeamento entre identificadores de domínio de broadcast entendidos por cada um de seus dispositivos CE anexados e a tag Ethernet correspondente.
Ethernet segment route (EVPN Type 4 route)— Os roteadores PE conectados a um dispositivo CE multihomed usam mensagens de rota de segmento BGP Ethernet para descobrir que cada um dos roteadores PE está conectado ao mesmo segmento de Ethernet. Os roteadores PE anunciam a rota do segmento Ethernet, que consiste em uma comunidade estendida de importação de ES e ES.
Os roteadores PE1 e PE2 anunciam uma rota ES com uma comunidade estendida de importação ES (juntamente com outras comunidades estendidas, como o alvo da rota). Os roteadores PE também constroem um filtro baseado em uma comunidade estendida de importação ES, o que resulta apenas nesses roteadores PE importando a rota ES e identificando que eles estão conectados ao mesmo segmento de Ethernet.
Extended community— Uma comunidade estendida é semelhante na maioria das maneiras a uma comunidade regular. As EVPNs usam comunidades estendidas porque o valor regular da comunidade de 4 octets não oferece expansão e flexibilidade suficientes. Uma comunidade estendida é um valor de 8 octets dividido em duas seções principais.
BUM traffic— Esse tipo de tráfego é enviado para vários destinos, incluindo tráfego de broadcast, tráfego unicast desconhecido que é transmitido no segmento Ethernet e tráfego multicast.
DF— Quando um dispositivo CE é multihomed para dois ou mais roteadores PE, um ou todos os roteadores de PE multihomed são usados para chegar ao site do cliente, dependendo do modo de operação multihoming. O roteador PE que assume o papel principal para o encaminhamento do tráfego BUM ao dispositivo CE é chamado de roteador designado (DF).
BDF— Cada roteador no conjunto de outros roteadores PE anunciando a rota de autodiscovamento por segmento Ethernet para o mesmo ESI, e servindo como caminho de backup no caso do DF encontrar uma falha, é chamado de encaminhamento designado para backup (BDF). Um BDF também é chamado de roteador não-DF.
DF election— Em todos os segmentos de Ethernet, os roteadores DEP participam de um procedimento chamado eleição de encaminhamento designado para selecionar o DF e os roteadores BDF PE.
Modo de operação multihoming EVPN
Os diferentes modos de operação para multihoming EVPN incluem:
Único — Quando um roteador PE é conectado a um site de um único cliente, esse modo está em operação. O modo único é o modo padrão de operação, e não requer que os valores do segmento de Ethernet sejam configurados.
Espera ativa — Quando apenas um único roteador PE, entre um grupo de roteadores PE ligados a um segmento de Ethernet, é permitido encaminhar tráfego de e para esse segmento de Ethernet, o segmento de Ethernet é definido como operando no modo de redundância de standby ativo .
Para configurar o modo de espera ativo, inclua o valor da ESI e a
single-activedeclaração sob o nível de[edit interfaces]hierarquia.Nota:Não oferecemos suporte ao modo multihoming de standby ativo em switches da Série QFX ou em configurações de EVPN com overlays VXLAN. Como resultado, se você configurar a opção
single-activeem switches da Série QFX ou em configurações de EVPN-VXLAN, o dispositivo ignora esse item de configuração.Ativo—Quando todos os roteadores PE conectados a um segmento de Ethernet podem encaminhar tráfego de e para o segmento Ethernet, o segmento de Ethernet é definido como operando no modo de redundância ativo-ativo .
Nota:No Junos OS Release 14.2 e anterior, o switch da Série EX9200 oferece suporte apenas ao modo de operação de standby ativo para multihoming EVPN.
Nota:Começando com o Junos OS Release 14.1x53-D30 para switches QFX5100 e o Junos OS Release 18.2R1 para switches EX4600, esses switches oferecem suporte ao modo de operação ativo-ativo para multihoming EVPN. Nesse cenário, os switches QFX5100 e EX4600 funcionam como switches top-of-rack (ToR) no data center para redes virtuais. A funcionalidade ativa ativa multihoming EVPN é usada para fornecer acesso aos servidores bare-metal conectados aos switches top-of-rack.
Nota:Começando pelo Junos OS Release 14.1R4, 14.2, 15.1F6 e 16.1R1, o Junos OS oferece suporte ao modo ativo para multihoming EVPN em roteadores da Série MX.
A partir dos versões Junos OS 16.1R4 e 16.2R2, todos os switches EX9200 oferecem suporte ao modo ativo-ativo para multihoming EVPN.
A partir do Junos OS, os switches 17.4R1 QFX10000 oferecem suporte ao modo ativo para multihoming EVPN.
Para configurar o modo ativo-ativo, inclua o valor de ESI e a
all-activedeclaração no nível de[edit interfaces]hierarquia.A Figura 3 mostra uma topologia de referência para multihoming ativo EVPN. O segmento ESI1 Ethernet para Dispositivo CE2 é multihomed para roteadores PE1, PE2 e PE3. O segmento Ethernet no dispositivo CE pode ser configurado como um grupo de agregação de links (LAG) ou como um caminho ECMP. Os dispositivos CE1 e CE3 são os dispositivos de borda de um único cliente e têm um valor de ESI de 0.
EVPN ativo e ativo
Implementação multihoming da EVPN
O modo de operação multihoming ativo de standby da EVPN oferece redundância para falhas de link de acesso e falha de nó PE para o dispositivo CE multihomed, e é baseado no draft-ietf-l2vpn-evpn-03 da EVPN.
A implementação do Junos OS dos modos de operação ativos e ativos de standby multihoming EVPN inclui:
- Novas NLRIs BGP
- Novas comunidades estendidas
- Tipos de rota EVPN mais novos
- Anúncio de rota de endereço IP e MAC de proxy multihomed
- Atualização para a tabela de encaminhamento MAC
- Fluxo de tráfego
- Aliasing
- Agregação de enlaces multihoming ativo e multichassis da EVPN
- Multihoming ativo EVPN e IRB
- Configuração de amostra
Novas NLRIs BGP
Para oferecer suporte a multihoming EVPN, foram introduzidas as seguintes novas rotas de informações de acessibilidade de camada de rede BGP (NLRI):
Rota de autodiscovamento por segmento de ethernet
Recursos de rota de autodiscovery
Os recursos NLRI da rota de autodiscovaria incluem:
Esta é uma rota obrigatória do Tipo 1, usada para convergência rápida e para publicidade do rótulo split horizon. Também é conhecida como a rota de retirada em massa.
Os diferenciadores de rota tipo 1 são usados com o endereço IP (loopback) do roteador PE de origem como o valor do diferencial da rota.
Essa rota transporta o ESI na NLRI (nãozero quando é um PE multihomed, zero de outra forma).
O rótulo de horizonte dividido é apenas para ESI, e carrega um NULL explícito (0).
O bit no campo de bandeira de espera ativa na comunidade estendida do rótulo ESI é usado para sinalizar o modo de espera ativo (conjunto de bits).
Os valores de rótulo de 3 byte na NLRI e na tag Ethernet são zero.
Essa rota é anunciada e importada por todos os roteadores PE multihomed e remotos que compartilham o mesmo EVI no ESI publicitário.
Anúncio da rota de autodiscovery
Modo de espera ativo
No modo de espera ativo, o roteador designado (DF) anuncia a rota de autodiscovery por segmento Ethernet com uma comunidade estendida de rótulo ESI MPLS que tem o bit de espera definido para 1. A rota de autodiscovamento é anunciada por ESI, e o rótulo ESI é definido para 0 quando o modo de espera ativo estiver em operação.
A rota de autodiscovamento é importada por todos os roteadores PE multihomed e remotos que fazem parte do EVI. Ao receber a rota de autodiscovamento, os roteadores PE na topologia de rede descobrem que o modo multihoming ativo está em operação para o ESI anunciado.
Modo ativo
No modo ativo-ativo, cada um dos dispositivos de PE multihomed anuncia uma rota de autodiscovery obrigatória por segmento Ethernet como no estado de espera ativo. No entanto, no estado ativo ativo, a rota de autodiscovamento por segmento de Ethernet é modificada de modo que o bit de espera ativo transportado na comunidade estendida MPLS seja liberado para indicar que o modo ativo está em operação. A rota de autodiscovamento por segmento Ethernet no modo ativo-ativo também inclui o rótulo split horizon.
Na Figura 3, para o segmento ESI1 Ethernet, os roteadores PE1, PE2 e PE3 anunciam a rota de autodiscovamento. O roteador PE4 recebe essa rota de autodiscovaamento.
Retirada de rota de autodiscovamento
A rota de autodiscovamento por retirada do segmento de Ethernet pode resultar em retirada em massa. O recurso de retirada em massa é usado quando há uma falha de link na ESI ou quando a configuração da ESI muda.
Quando a ligação entre um dispositivo CE multihomed e um dispositivo PE multihomed falha, o dispositivo PE retira a rota de autodiscovery por segmento Ethernet. Nesse caso, o recurso de retirada em massa é tratado das seguintes maneiras pelos outros dispositivos PE:
Dispositivo PE remoto
Quando um dispositivo PE remoto recebe a atualização BGP para retirada em massa, o seguinte é realizado no dispositivo PE remoto:
O próximo salto atual para alcançar o dispositivo remoto de ESI ou CE é excluído.
Um novo salto próximo através dos dispositivos PE multihomed restantes é criado para alcançar o dispositivo ESI ou CE remoto.
Todas as rotas MAC por trás do dispositivo CE são atualizadas com o próximo salto recém-criado.
Começando pelo Junos OS Release 17.4R1, o Junos OS oferece suporte ao Dynamic List Next Hops em uma rede EVPN. Agora, quando a ligação entre o dispositivo CE e um dispositivo multihome PE falha, o próximo salto para o ESI ou CE é atualizado, reduzindo assim a necessidade de uma retirada em massa. Para obter mais informações sobre como habilitar o Next Hop da Lista Dinâmica, veja Configurando a lista dinâmica próximo salto.
Outro dispositivo de PE multihomed
Como resultado da retirada em massa, o balanceamento de carga no dispositivo CE multihomed acontece por causa do seguinte:
Quando os outros dispositivos de PE multihomed recebem o mesmo conjunto de endereços MAC no link para o ESI em questão.
Neste caso, as rotas locais são preferidas. Se as rotas remotas aprendidas com o dispositivo DF PE forem retiradas, ela não afetará as rotas que apontam para a ESI local.
Quando os outros dispositivos de PE multihomed não tiverem recebido o mesmo conjunto de endereços MAC no link para o ESI em questão.
Neste caso, os dispositivos PE instalam as rotas MAC que apontam para a ESI em questão, embora os MACs sejam aprendidos remotamente com o dispositivo DF PE. Quando o dispositivo DF PE retira essas rotas, as rotas retiradas são liberadas. Os pacotes destinados aos endereços MAC lavados estão inundados em todos os segmentos locais.
Rota do segmento de ethernet
Recursos de rota por segmentos de ethernet
Os recursos NLRI da rota do segmento Ethernet incluem:
Esta é uma rota EVPN Tipo 4. O objetivo dessa rota é permitir que os roteadores PE conectados ao mesmo segmento de Ethernet se descubram automaticamente com configuração mínima na troca dessa rota.
Essa rota está associada a uma comunidade estendida de importação de ES com um valor de ESI condensado a 6 bytes, semelhante a uma meta de rota.
Essa rota é anunciada e importada apenas por roteadores PE que são multihomed no segmento Ethernet de publicidade.
Anúncio de rota por segmentos de Ethernet
A rota do segmento Ethernet é trocada entre todos os roteadores PE dentro de um data center com a comunidade estendida de importação ES. A comunidade estendida de importação ES é construída com base nos roteadores ESI PE que são multihomed, e a rota do segmento Ethernet transporta o valor de ESI relacionado ao segmento Ethernet no qual os roteadores PE são multihomed.
As rotas do segmento Ethernet são filtradas com base na comunidade estendida de importação ES, de modo que apenas os roteadores PE que são multihomed no mesmo segmento de Ethernet importam esta rota. Cada roteador PE conectado a um determinado segmento de Ethernet constrói uma regra de filtragem de importação para importar uma rota que transporta a comunidade estendida de importação de ES.
Rota de autodiscovery por instância EVPN
No modo ativo-ativo, cada um dos dispositivos de PE multihomed anuncia uma rota de autodiscovery por instância EVPN (EVI) com um rótulo MPLS válido. Essa rota é anunciada por ESI e é importada pelos dispositivos pe remotos. O rótulo MPLS incluído na rota de autodiscovamento por EVI é usado posteriormente para aliasing.
Novas comunidades estendidas
Uma comunidade estendida é semelhante na maioria das maneiras a uma comunidade regular. Algumas implementações de rede, como redes virtuais privadas (VPNs), usam comunidades estendidas porque o valor regular da comunidade de 4 octets não oferece expansão e flexibilidade suficientes. Uma comunidade estendida é um valor de 8 octets dividido em duas seções principais.
Para oferecer suporte a multihoming de standby ativo, as seguintes comunidades estendidas foram introduzidas:
ESI-Import
Esta comunidade estendida é anexada à rota ES e é povoada a partir do valor de importação de ESI extraído do valor configurado de ESI sob a interface. Para resolver o problema de um conflito com outra meta de rota regular, o tipo está definido para 0x06, que foi alocado pela IANA.
A meta de rota de comunidade estendida para importação de ESI preenche a lista de alvos de rota de importação configurados para a instância especial a partir de onde a rota ES que usa esta comunidade é anunciada.
Portanto, as rotas de ESI de entrada com o mesmo valor de importação de ESI na comunidade estendida são importadas pelos roteadores PE, se o roteador PE estiver configurado com um segmento de Ethernet que tenha o mesmo valor de ESI. Assim que o roteador PE receber um conjunto dessas rotas de ESI que tenham o mesmo valor de comunidade estendido de importação de ESI, a eleição do DF e do BDF pode ser feita localmente.
Quando a comunidade estendida de importação de ESI não for criada implicitamente, uma política deve ser configurada para anexar todos os alvos de rota à rota de autodiscovamento por segmento de Ethernet.
Horizonte dividido
Com referência à Figura 3 , por exemplo, quando um dispositivo CE que é multihomed para dois ou mais dispositivos PE em um segmento de Ethernet (ESI1) e operando no modo de redundância ativa e ativa envia um pacote BUM para um dos dispositivos PE não-DF (digamos PE1), então o Dispositivo PE1 encaminha esse pacote para todos ou um subconjunto dos outros dispositivos PE naquela instância EVPN, incluindo o dispositivo DF PE para esse segmento de Ethernet. Neste caso, o dispositivo DF PE que o dispositivo CE é multihomed para derrubar o pacote sem encaminhá-lo de volta para o dispositivo CE. Essa filtragem é referida como horizonte dividido.
Sinalização de horizonte dividido
A comunidade estendida do horizonte dividido é anexada à rota de autodiscovamento por segmento Ethernet. O valor da comunidade estendida é o horizonte dividido ou o próprio rótulo Poisson, que é 3 bytes, e é anunciado como um atributo opaco.
Anúncio de horizonte dividido
No modo standby ativo, o bit de espera na comunidade estendida de horizonte dividido está definido para 1, e o rótulo de horizonte dividido da ESI está definido para 0.
No modo ativo-ativo, a comunidade estendida do horizonte dividido é modificada para limpar o bit de espera para 0 e inclui um rótulo ESI válido usado para fins de horizonte dividido.
Rotas MPLS de horizonte dividido
O dispositivo DF PE anuncia uma rota de autodiscovamento por segmento Ethernet com um rótulo A de horizonte dividido, e uma rota multicast inclusiva com rótulo B para encaminhamento de tráfego BUM. No DF, o pacote BUM do núcleo pode vir com os seguintes rótulos:
Quando os dispositivos NÃO-DF PE recebem um pacote BUM em suas ESIs de casa única, o pacote BUM é enviado para o dispositivo DF PE com rótulo B multicast.
Quando os dispositivos NÃO-DF PE recebem um pacote BUM no ESI1, o pacote BUM é enviado ao dispositivo DF PE com duas etiquetas MPLS — o rótulo B multicast como o rótulo externo, e o rótulo de horizonte dividido A como o rótulo interno.
No cenário multihoming EVPN, o rótulo B multicast tem o conjunto S-bit para 1 quando é o único rótulo na pilha de rótulos. Neste caso, o pacote BUM precisa ser inundado em todas as ESIs locais no dispositivo DF PE. Mas o rótulo B tem o conjunto S-bit para 0 quando o rótulo A de horizonte dividido é o rótulo mais interno na pilha de rótulos. Neste caso, os pacotes BUM precisam ser inundados em todas as ESIs locais no dispositivo DF PE, exceto o ESI que mapeia para o rótulo A do horizonte dividido.
Assumindo que os pacotes se originaram de um dispositivo CE multihomed para um dispositivo NÃO DF PE no segmento multihomed ESI1, quando o dispositivo não DF PE envia este pacote para o dispositivo DF PE, o rótulo ESI que o DF anunciou para o dispositivo NÃO DF PE em sua rota de autodiscovery por segmento Ethernet é empurrado primeiro. O dispositivo não-DF PE também empurra o rótulo multicast inclusivo que o dispositivo DF PE anunciou em sua rota multicast inclusiva e empurra ainda mais o rótulo LSP. Assim, o cabeçalho MPLS contém duas etiquetas em um campo de 32 bits.
A funcionalidade EVPN base usa um salto de tabela ao lado para costurar a tabela MPLS com sua tabela EVPN EVI correspondente. Na tabela EVPN EVI, a busca mac é realizada para mudar o pacote.
As rotas a seguir são programadas na tabela mpls.0 para multicast EVPN:
O (multicast-label, S=1) aponta para o salto próximo da tabela EVPN-EVI.
O (multicast-label, S=0) aponta para o salto próximo da tabela MPLS. Essa rota faz o loop do pacote de volta à tabela MPLS depois de estalar o rótulo multicast.
A rota (rótulo de horizonte dividido) aponta para o salto próximo da tabela EVPN-EVI. Este é o mesmo salto de tabela a seguir que é usado pelo rótulo multicast, rota S=1.
Tipos de rota EVPN mais novos
O modo multihoming EVPN oferece suporte aos seguintes tipos de rota EVPN:
Rota de autodiscovamento por segmento de Ethernet
Rota de autodiscovery por instância EVPN (EVI)
Rota do segmento de Ethernet
Esses tipos de rota estão em conformidade com a seguinte convenção de nomenclatura:
<route-type>:<RD>::<esi>::<route-specific>/304
Por exemplo:
Rota de autodiscovamento por segmento de Ethernet—
1:10.255.0.2:0::112233445566778899::0/304Rota de autodiscovabilidade por EVI—
1:100.100.100.1:1::22222222222222222222::0/304Rota do segmento de ethernet—
4:10.255.0.1:0::112233445566778899:10.255.0.1/304
onde:
route-type— Tipo de rota EVPN.1 — Rota de autodiscovamento por segmento de Ethernet.
1 — Rota de autodiscovabilidade por EVI.
4 — Rota do segmento Ethernet.
5 — Roteamento com encapsulamento VXLAN/MPLS
RD— Valor do diferencial de rota.O valor do diferencial de rota é definido para o endereço IP do roteador PE seguido de 0.
esi— identificador de segmentos de ethernet. Exibidos como 10 bytes de bytes hexadecimal, e os 00 bytes líderes não são exibidos.route-specific— Difere por tipo de rota.Rota de autodiscovery por segmento Ethernet e rota de autodiscovery por EVI — Esse valor é um rótulo MPLS.
Nota:O rótulo MPLS é exibido na saída extensa, embora não esteja incluído no prefixo.
Rota do segmento Ethernet — Esse valor é o endereço IP de origem.
304— Número máximo de bits em uma rota EVPN. Essas informações não são muito úteis e podem ser removidas do display. No entanto, pode ser útil identificar rapidamente uma rota EVPN, visualmente ou com operadores compatíveis.
Anúncio de rota de endereço IP e MAC de proxy multihomed
A partir do Junos OS Release 18.4R1, o Junos envia anúncio de rota DE ENDEREÇO IP e MAC proxy de PEs que são multihomed para um dispositivo CE. O Junos usa uma bandeira de proxy nos atributos de camada 2 da EVPN para identificar a mensagem como um anúncio de endereço IP e MAC proxy. Um PE que aprende sobre um endereço MAC e IP envia um anúncio de rota EVPN tipo 2 (ENDEREÇO MAC e IP) normal. Os outros PEs do Segmento de Ethernet que aprendem sobre a nova rota a partir do PE remoto agora enviam uma mensagem de rota DE MAC e IP com o conjunto de bits proxy. Se a entrada de endereço MAC e IP estiver fora ou se o enlace entre o PE e o CE falhar, as entradas precisam ser ressarcidas e o tráfego pode ser perdido. Isso evita a perda de tráfego quando uma das conexões com um dispositivo leaf falha. O MAC proxy multihomed é habilitado automaticamente.
Atualização para a tabela de encaminhamento MAC
No multihoming EVPN em standby ativo, os endereços MAC são tratados como endereços roteáveis, e o protocolo MP-IBGP é usado para transportar os endereços MAC do cliente. O aprendizado MAC nos roteadores PE não ocorre no plano de dados, mas no plano de controle. Isso leva a mais controle aplicado em termos do mecanismo de aprendizado.
Um roteador PE realiza o aprendizado MAC no plano de dados para pacotes vindos de uma rede do cliente para um EVI específico. Para endereços CE MAC que estão por trás de outros roteadores PE, os endereços MAC são anunciados no BGP NLRI usando um novo tipo de rota de anúncio MAC.
O aprendizado MAC é de dois tipos:
Aprendizado MAC local — os roteadores PE devem suportar o processo local de aprendizado MAC por meio de protocolos padrão.
Aprendizado MAC remoto — Assim que o processo de aprendizagem local for concluído, os roteadores de PE podem anunciar o endereço MAC aprendido localmente em nós de roteador PE remoto através do MP-IBGP. Esse processo de recebimento dos endereços MAC remotos de clientes conectados por meio do MP-IBGP é conhecido como o processo remoto de aprendizado MAC.
O tipo de rota de anúncio MAC é usado para anunciar endereços MAC aprendidos localmente em BGP para roteadores PE remotos. Se um endereço MAC individual for anunciado, o campo de endereço IP corresponde a esse endereço MAC. Se o roteador PE vir uma solicitação de ARP para um endereço IP de um dispositivo CE e se o roteador PE tiver a vinculação de endereço MAC para esse endereço IP, o roteador PE executará proxy ARP e responderá à solicitação de ARP.
O proxy ARP é executado apenas para o gateway e não para o host.
O campo de rótulo MPLS depende do tipo de alocação. O roteador PE pode anunciar um único rótulo MPLS para todos os endereços MAC por EVI, o que requer o menor número de rótulos MPLS e economiza a memória do roteador PE. No entanto, ao encaminhar para a rede do cliente, o roteador PE deve realizar uma busca MAC que possa causar um atraso e aumentar o número de ciclos de CPU.
Fluxo de tráfego
No multihoming da EVPN, o fluxo de tráfego é realizado no plano de encaminhamento. As rotas de inundação são criadas para inundar os pacotes e são usadas nos seguintes cenários:
Quando um pacote é recebido em uma ESI local
Quando um pacote é recebido do núcleo
Os fluxos de tráfego em multihoming EVPN podem ser baseados nos dois tipos de tráfego:
Tráfego Unicast
O tráfego Unicast é uma comunicação ponto a ponto com um remetente e um receptor. Em uma EVPN multihomed, o tráfego unicast é encaminhado da seguinte forma:
No modo de espera ativa
CE ao núcleo — O tráfego é aprendido e encaminhado pelo roteador DF PE.
Núcleo a CE — o roteador PE remoto aprende os endereços MAC do DF e encaminha todo o tráfego unicast para o roteador DF PE.
No modo ativo
CE ao núcleo — o tráfego é equilibrado em carga para todos os dispositivos de PE multihomed conectados.
Núcleo a CE — O tráfego dos dispositivos PE remotos é equilibrado em carga para todos os dispositivos DEP multihomed conectados ao dispositivo CE remoto.
Tráfego BUM
Tráfego que é enviado para vários destinos, incluindo tráfego de broadcast, tráfego unicast desconhecido que é transmitido no segmento Ethernet, e tráfego multicast é conhecido como tráfego BUM. Em uma EVPN multihomed, o tráfego BUM é encaminhado da seguinte forma:
No modo de espera ativa
CE para núcleo — o dispositivo CE inunda qualquer tráfego BUM para todos os links do segmento Ethernet. O roteador DF PE com o caminho ativo encaminha os pacotes BUM até o núcleo. O roteador BDF PE no modo de espera derruba todo o tráfego do dispositivo CE, porque o status multihomed EVPN da interface está em estado de bloqueio. No entanto, se o dispositivo CE estiver conectado aos dispositivos PE usando links ou LAGs separados, o tráfego BUM atingirá os dispositivos DF e BDF PE.
Núcleo a CE — os roteadores PE remotos inundam todo o tráfego BUM para os roteadores DF e BDF PE. Apenas o DF encaminha o tráfego BUM para o dispositivo CE. O roteador BDF PE derruba todo o tráfego, porque o status multihomed EVPN da interface está em estado de bloqueio.
No modo ativo
Com base nos requisitos, inundações e comutação entre ESIs locais podem ser habilitadas ou desabilitadas no modo ativo-ativo. Isso é referido como o comportamento sem comutação local.
O núcleo do serviço EVPN oferece uma conectividade full-mesh entre os dispositivos de PE multihomed. Por causa disso, a EVPN usa um horizonte dividido no núcleo, de modo que um pacote recebido do núcleo nunca é trocado ou inundado de volta para o núcleo. Em vez disso, a replicação de entrada é usada para replicar os pacotes nos dispositivos pe remotos.
Para inundar pacotes para dispositivos pe remotos, o multicast e o horizonte dividido próximo hops são usados. O próximo hop multicast tunela o pacote com o rótulo multicast inclusivo, e o horizonte dividido próximo tunela o pacote com um rótulo multicast e um rótulo de horizonte dividido. Um desses saltos seguintes é necessário por ESI multihomed por dispositivo PE remoto.
As seguintes rotas de inundação são usadas no modo ativo-ativo:
Rota de inundação all-CE
Esta rota de inundação é usada pelas ESIs locais para o seguinte:
Inundando o pacote nas ESIs locais (quando a comutação local é permitida).
Inundando o pacote para os dispositivos pe remotos. Os dispositivos pe remotos inundam o pacote em suas ESIs locais.
Como o tráfego BUM é encaminhado apenas pelo Designated Forwarder (DF), e não pelos dispositivos de PE não-DF multihomed, os não-DFs usam o horizonte de divisão próximo salto para inundar este pacote para outros dispositivos PE. No entanto, as ESIs locais multihomed para as quais o dispositivo PE é um não-DF não participam da inundação.
A rota de inundação all-CE não é usada pelas ESIs não-DF, e o próximo salto para essas rotas de inundação é criado em conformidade. Nesses casos, a rota de inundação não-DF ESI é usada.
Rota de inundação All-VE
Esta rota de inundação é usada quando o pacote é recebido do núcleo. Ele é usado para inundar o pacote recebido do núcleo para as ESIs locais. Como o pacote recebido do núcleo pode vir apenas com rótulo multicast ou com rótulo multicast e rótulo de horizonte dividido, as regras de encaminhamento apropriadas devem ser seguidas para soltar o pacote no ESI multihomed que mapeia para o rótulo de horizonte dividido.
Rota de inundação não-DF
Esta rota de inundação é usada para o seguinte:
Inundando o pacote nas ESIs locais.
Inundando o pacote para os dispositivos pe remotos usando replicação de entrada com rótulo SH para o DF para a ESI.
Aliasing
A partir do Junos OS Release 15.1, o Junos OS oferece suporte a uma EVPN. Aliasing é a capacidade de um dispositivo PE remoto de carregar o tráfego unicast de Camada 2 em todos os outros dispositivos PE que têm o mesmo segmento Ethernet em direção a um dispositivo CE.
Aliasing no modo ativo-ativo
Na Figura 3, o aliasing no modo ativo-ativo funciona da seguinte forma:
O ESI1 está configurado nos roteadores PE1, PE2 e PE3. Os roteadores PE1, PE2 e PE3 anunciam a rota de autodiscovery por segmento Ethernet para ESI1.
O dispositivo CE1 envia tráfego de Camada 2 com endereço MAC de origem (MAC1) para o Roteador PE1.
O Roteador PE1 aprende o endereço MAC1 (ESI1, vlan X) e o anuncia a todos os roteadores PE usando BGP.
O roteador PE4 recebe a rota MAC1 pelo BGP.
Como o Roteador PE4 também recebeu a rota de autodiscovabilidade por EVI dos roteadores PE2 e PE3, ele sabe que o MAC1 deve ser acessível através dos roteadores PE2 e PE3. O roteador PE4 constrói seu estado de encaminhamento para equilibrar a carga do tráfego de Camada 2 para MAC1 entre os roteadores PE1, PE2 e PE3.
Rotas de aliasing e autodiscovery
As rotas de autodiscovery dos roteadores PE2 e PE3 podem vir em qualquer ordem. Como resultado, essas rotas são instaladas pelo processo de Camada 2 da seguinte forma:
Após receber o MAC1 do Roteador PE1 e se alguma rota de autodiscovamento não tiver sido recebida pelo Roteador PE4, o MAC1 é programado pelo PE4 com um próximo salto apontando para o Roteador PE1. Quando o PE4 recebe a rota de autodiscovamento do Roteador PE2 para o mesmo ESI, o próximo salto é instalado para que o tráfego para MAC1 seja equilibrado em carga para os roteadores PE1 e PE2. Quando o PE4 recebe a rota de autodiscovamento do Roteador PE3 para o mesmo ESI, o próximo salto é atualizado para equilibrar o tráfego para MAC1 entre roteadores PE1, PE2 e PE3.
Se o Roteador PE4 já tiver recebido as rotas de autodiscovamento de mais de um dispositivo PE (PE1, PE2 e PE3), o PE4 instala as rotas MAC com o próximo salto multi destino.
Rota de aliasing e rótulo
Qualquer dispositivo PE que anuncia a rota de autodiscovamento por EVI com um rótulo MPLS válido programa o rótulo anunciado na tabela de roteamento mpls.0. Por exemplo, se o Roteador PE2 anunciasse a rota de autodiscovamento por EVI com o rótulo A, a entrada mpls.0 será a seguinte:
Label A route points para o próximo salto de tabela EVPN-EVI.
Quando o Roteador PE4 remoto envia um pacote de dados unicast em direção ao Roteador PE2 com este rótulo A, a busca é feita na tabela de encaminhamento do Roteador PE2 e, como resultado dessa busca, o pacote é encaminhado no ESI1.
Aliasing e encaminhamento de pacotes Unicast
Quando os pacotes unicast para MAC1 vêm do roteador remoto PE4 para o Roteador PE2, pode haver dois casos:
O Roteador PE2 também recebeu o mesmo conjunto de MACs em seu link para o ESI1 — neste caso, as rotas locais são preferidas e, como resultado da busca mac, os pacotes são encaminhados para o ESI1.
O Roteador PE2 não recebeu o mesmo conjunto de MACs em seu link para o ESI1 — neste caso, o Roteador PE2 ainda instala rotas MAC apontando para o ESI1, embora os MACs sejam aprendidos remotamente com o Roteador PE1. Como resultado, os pacotes são encaminhados para o ESI1.
Agregação de enlaces multihoming ativo e multichassis da EVPN
Quando um dispositivo CE é configurado com um LAG em direção aos dispositivos PE, as duas opções a seguir estão disponíveis para executar LACP nos dispositivos PE:
Configure o mesmo ID do sistema LACP em todos os dispositivos PE.
Configure a agregação de enlaces multichassis nos dispositivos PE.
Quando a agregação de enlaces multichassis é configurada com EVPN, é necessário um conjunto reduzido de procedimentos para agregação de enlaces multichassis ativa. Esses procedimentos fornecem redundância de nível de enlace e nó. A agregação de enlace multichassis é completamente transparente para o dispositivo CE e é realizada como um LAG puro. A agregação de enlaces multichassis também opera no nível da porta. Isso significa essencialmente que, se a agregação de enlaces multichassis for configurada como ativa, todas as VLANs nas portas de agregação de enlaces multichassis funcionam no modo multihoming ativo.
Quando a agregação de enlaces multichassis é configurada junto com a EVPN, considera-se o seguinte:
Tanto a agregação de enlaces multichassis quanto a ESI EVPN devem ser habilitadas para trabalhar apenas no modo ativo.
As funções a seguir não são necessárias para a agregação de enlaces multichassis com a EVPN:
Sincronização mac — Isso é executado no plano de controle BGP da EVPN.
Enlace de ICL — Isso é tratado pelo recurso de aliasing da EVPN.
Sincronização de ARP — Isso é tratado pelo plano de controle BGP com funcionalidade IRB.
Multihoming ativo EVPN e IRB
Quando o IRB está configurado, as rotas EVPN contêm informações MAC e IP. O multihoming ativo-ativo requer sincronização de ARP entre os dispositivos PE multihomed porque as respostas de ARP podem ser hashed para um determinado dispositivo PE.
Configuração de amostra
A seguir, uma configuração de amostra para multihoming ativo de standby EVPN nos seguintes tipos de interfaces:
Configuração da interface Ethernet
ge-0/1/2 { encapsulation ethernet-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; unit 0 { family bridge; } }Configuração única da interface VLAN
ge-0/1/3 { encapsulation extended-vlan-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; vlan-tagging unit 0 { family bridge; vlan-id 1; } }
Um valor de ESI de 0 e todos os FFs estão reservados e não são usados para configurar um segmento Ehernet multihomed.
Duas interfaces no mesmo EVI não podem ser configuradas com o mesmo valor de ESI.
A seguir, uma configuração de instância de roteamento de amostra para multihoming de standby ativo da EVPN:
Configuração de instância de roteamento
routing-instances { evpn-0 { instance-type evpn; route-distinguisher value; vrf-target value; vlan-id vlan-ID; interface ge-0/1/2.0; interface ge-1/1/1.0; interface ge-2/2/2.0; protocols { evpn { designated-forwarder-election-hold-time time; } } } }
Com a configuração do modo standby ativo, a rota de autodiscovamento por segmento de Ethernet é anunciada com o bit de espera ativo definido para 1 para cada segmento de Ethernet.
Eleição para encaminhamento designado
As seções a seguir discutem a eleição do DF:
- Funções eleitorais do DF
- Eleição do DF conforme RFC 7432
- Eleição do DF baseada em preferência
- Eleição do DF para switch virtual
- Falha no manuseio
Funções eleitorais do DF
O processo eleitoral de encaminhamento designado (DF) envolve a seleção de um papel de encaminhamento da seguinte forma:
Designated forwarder (DF)— O endereço MAC do site do cliente só pode ser alcançado através do roteador PE anunciando a rota de anúncio MAC associada. Este roteador PE é o roteador PE principal que é selecionado para encaminhar o tráfego BUM para o dispositivo CE multihomed, e é chamado de roteador de encaminhamento designado (DF) PE.
Backup designated forwarder (BDF)— Cada roteador PE no conjunto de outros roteadores PE anunciando a rota de autodiscovamento por segmento Ethernet para o mesmo ESI, e servindo como o caminho de backup no caso do DF encontrar uma falha, é chamado de encaminhamento designado para backup (BDF).
Como resultado do processo eleitoral do DF, se um roteador PE local for eleito como BDF, a interface multihomed que se conecta ao site do cliente é colocada em um estado de bloqueio para o modo de espera ativo. A interface permanece no estado de bloqueio até que o roteador PE seja eleito como o DF para o segmento Ethernet do qual a interface pertence.
-
Non-designated forwarder (non-DF)— Outros roteadores pe não selecionados como o DF. O BDF também é considerado um não-DF.
Eleição do DF conforme RFC 7432
Procedimento eleitoral do DF
O procedimento padrão para a eleição do DF na granularidade do ESI e EVI é referido como escultura de serviço. Com a escultura de serviços, é possível eleger vários DFs por segmento de Ethernet (um por EVI) a fim de realizar o balanceamento de carga do tráfego multidestinação destinado a um determinado segmento de Ethernet. Os procedimentos de balanceamento de carga esculpiram o espaço EVI entre os nós pe uniformemente, de tal forma que cada PE é o DF para um conjunto de EVIs desarticulado.
O procedimento para escultura de serviços é o seguinte:
Quando um roteador PE descobre a ESI do segmento Ethernet conectado, ele anuncia uma rota de autodiscovery por segmento Ethernet com o atributo de comunidade estendida de importação ES associado.
O roteador PE então inicia um temporizador (valor padrão de 3 segundos) para permitir a recepção das rotas de autodiscovamento de outros nós PE conectados ao mesmo segmento de Ethernet. Esse valor do timer deve ser o mesmo entre todos os roteadores PE conectados ao mesmo segmento de Ethernet.
O tempor de espera padrão pode ser substituído usando a declaração de
designated-forwarder-election-hold-timeconfiguração.Quando o temporizador expira, cada roteador PE cria uma lista ordenada dos endereços IP de todos os nós PE conectados ao segmento Ethernet (incluindo ele mesmo), em uma ordem numérica crescente. Cada roteador PE recebe então uma indicação ordinal de sua posição na lista ordenada, começando com 0 como ordinal para PE com o endereço IP numericamente mais baixo. Os ordinais são usados para determinar qual nó de PE é o DF para um determinado EVI no segmento Ethernet.
O roteador PE que é eleito como o DF para um determinado EVI desbloqueia o tráfego para as tags Ethernet associadas a esse EVI. O DF PE desbloqueia o tráfego multidestinação na direção de saída em direção ao segmento Ethernet. Todos os roteadores NÃO-DF PE continuam a diminuir o tráfego multidestinação (para as EVIs associadas) na direção de saída em direção ao segmento Ethernet.
Na Figura 3, a eleição do DF para multihoming ativo-ativo é realizada entre roteadores PE1, PE2 e PE3. Como resultado desta eleição do DF, cada um desses roteadores pode se tornar o DF para uma VLAN específica de uma variedade de VLANs configuradas no ESI1. O DF é responsável por encaminhar o tráfego BUM naquele ESI e VLAN para o qual é eleito como o DF. Os roteadores NÃO-DF PE bloqueiam o tráfego BUM naquele segmento Ethernet em particular.
Gatilho da eleição do DF
Em geral, um processo eleitoral do DF é desencadeado nas seguintes condições:
Quando uma interface é configurada recentemente com um ESI não zero, ou quando o roteador PE faz a transição de um estado isolado do núcleo (sem sessão BGP) para um estado conectado ao núcleo (estabeleceu a sessão BGP), um temporizador de espera é imposto. Por padrão, a interface é colocada em um estado de bloqueio até que o roteador PE seja eleito como o DF.
Após concluir um processo eleitoral do DF, um roteador PE recebe uma nova rota de segmento Ethernet ou detecta a retirada de uma rota de segmento Ethernet existente, sem um tempo de espera imposto.
Quando uma interface de um roteador PE não-DF se recupera de uma falha no enlace, o roteador PE não tem conhecimento do tempo de espera imposto por outros roteadores PE. Como resultado, nenhum tempor de espera é imposto para o roteador PE recuperado para evitar perda de tráfego.
Eleição do DF baseada em preferência
A eleição do DF com base na RFC 7432 não atende a alguns dos requisitos operacionais necessários por alguns provedores de serviços. Como solução para isso, a partir do Junos OS Release 17.3, a eleição do DF em uma rede EVPN multihoming pode ser controlada usando um valor de preferência administrativa para uma ESI.
No processo de eleição padrão do DF (conforme especificado na RFC 7432), o DF é eleito aleatoriamente de um dos dispositivos multihoming com operação de modulo. Com a eleição do DF baseada em preferência, o DF é eleito manualmente usando opções de configuração de interface, como o valor de preferência, o bit Don't Preempt (DP) e o ID do roteador ou endereço de loopback.
Procedimento de eleição do DF baseado em preferência
A eleição do DF baseada em preferência é apoiada em EVPN e PBB-EVPN, e permite a eleição manual de um DF. Isso é útil quando há a necessidade de escolher o DF com base em atributos de interface, como a largura de banda associada a uma interface.
A eleição do DF baseada em preferência é executada da seguinte forma:
O tipo de eleição do DF e o valor de preferência estão configurados sob um ESI. Por padrão, o tipo de eleição df baseada em preferência é baseado na operação modulo (MOD).
O valor de preferência configurado e o bit DP são anunciados para os dispositivos PE multihoming usando a comunidade estendida da eleição do DF nas rotas EVPN Type 4.
Após receber a rota EVPN Tipo 4, o dispositivo PE constrói a lista de dispositivos DF candidatos, na ordem do valor de preferência, bit DP e endereço IP.
Quando o temporizador DF expira, o dispositivo PE seleciona o DF com base no valor de preferência mais alto.
Por padrão, o DF é eleito com base na maior preferência por EVI. No entanto, a eleição do DF baseada em preferência permite a eleição do DF com base no menor valor de preferência quando a
designated-forwarder-preference-leastdeclaração é incluída no nível hierárquica[edit routing-instances routing-instance-name protocols evpn].Nota:A
designated-forwarder-preference-leastconfiguração deve ser a mesma em ambos os EVIs multihoming; caso contrário, pode haver dois DFs causando perda de tráfego ou loop.Quando o mesmo valor de preferência é configurado, então o dispositivo PE seleciona o DF com base no bit DP. Quando o bit DP também é o mesmo, o DF é eleito com base no endereço IP mais baixo.
Incompatibilidade entre algoritmos de eleição do DF
Quando há uma incompatibilidade entre um algoritmo de eleição df configurado localmente e o algoritmo de eleição df de um dispositivo PE remoto, então todos os dispositivos PE devem voltar para a eleição padrão do DF, conforme especificado no RFC 7432.
Migração do algoritmo de eleição do DF
Durante a migração da antiga eleição do DF para a nova eleição do DF, espera-se que mude a configuração durante a janela de manutenção derrubando o ESI, e mudando o algoritmo eleitoral do DF.
Para fazer a migração, faça o seguinte:
Após uma atualização de software, no dispositivo não-DF, derrube todas as interfaces que têm a mesma ESI.
Configure o novo algoritmo de eleição do DF no DF PE.
Configure o algoritmo de eleição do DF em outros dispositivos PE multihoming.
Traga todas as interfaces nos dispositivos não-DF PE.
Mudando a preferência pela manutenção
Depois de migrar o algoritmo de eleição do DF, e todo o dispositivo PE multihoming estiver executando o algoritmo de eleição df baseado em preferência, as tarefas de manutenção exigidas no DF existente podem ser executadas simplesmente alterando o valor de preferência configurado. Isso muda o DF para uma determinada ESI.
Mudar o DF para um determinado ESI:
Altere o valor de preferência para um valor mais alto no dispositivo não-DF atual.
Altere o valor de preferência para um valor mais baixo no dispositivo DF atual.
Mudar o valor de preferência por uma ESI pode levar a alguma perda de tráfego durante a curta duração necessária para integrar o atraso na propagação atualizada da rota BGP com o novo valor de preferência.
Eleição do DF para switch virtual
O switch virtual permite vários domínios de ponte em uma única instância EVPN (EVI). O switch virtual também oferece suporte a portas de tronco e acesso. O Junos OS permite serviços Ethernet flexíveis na porta; portanto, diferentes VLANs em uma única porta podem fazer parte de diferentes EVIs.
A eleição do DF para switch virtual depende do seguinte:
Modo de porta — sub-interface, interface de tronco e porta de acesso
Modo EVI — switch virtual com EVPN e EVPN-EVI
No switch virtual, várias tags Ethernet podem ser associadas a um único EVI, no qual o valor de tag Ethernet numericamente mais baixo no EVI é usado para a eleição do DF.
Falha no manuseio
Um failover pode ocorrer quando:
O roteador DF PE perde seu papel no DF.
Há uma falha de link ou porta no roteador DF PE.
Ao perder a função df, a interface voltada para o cliente no roteador DF PE é colocada no estado de bloqueio.
No caso de falha no enlace ou na porta, um processo eleitoral do DF é acionado, resultando na escolha do roteador BDF PE como o DF. Nesse momento, o tráfego unicast e o fluxo de tráfego BUM são afetados da seguinte forma:
Tráfego Unicast
CE para Núcleo — o dispositivo CE continua a inundar o tráfego em todos os links. O roteador BDF PE anterior altera o status multihomed EVPN da interface do estado de bloqueio para o estado de encaminhamento, e o tráfego é aprendido e encaminhado por este roteador PE.
Núcleo para CE — o roteador DF PE com falha retira a rota de autodiscovamento por segmento Ethernet e as rotas MAC aprendidas localmente, fazendo com que os roteadores PE remotos redirecionem o tráfego para o BDF.
A transição do roteador BDF PE para a função DF pode levar algum tempo, fazendo com que o status multihomed EVPN da interface continue no estado de bloqueio, resultando em perda de tráfego.
Tráfego BUM
CE para Núcleo — todo o tráfego é roteado em direção ao BDF.
Núcleo a CE — os roteadores PE remotos inundam o tráfego BUM no núcleo.
ESIs sobre ethernet agregada física e interfaces lógicas
Em versões antes do Junos OS Release 15.1F6 e 17.1R1 para roteadores da Série MX e o Junos OS Release 17.3R1 para switches EX9200, você pode especificar uma ESI apenas em uma interface Ethernet física ou agregada, por exemplo set interfaces ae0 esi 00:11:22:33:44:55:66:77:88:99. Se você especificar uma ESI em uma interface Ethernet física ou agregada, tenha em mente que uma ESI é um fator no processo de eleição de encaminhamento designado (DF). Por exemplo, suponha que você configure o standby ativo multihoming EVPN em interface Ethernet agregada ae0, e dado que a ESI configurada em ae0 e outros fatores determinantes, a eleição do DF resulta em umae0 estar no estado em baixa. Além disso, todas as interfaces lógicas configuradas na interface Ethernet agregada ae0, por exemplo, set interfaces ae0 unit 1 também set interfaces ae0 unit 2 estão no estado de baixa, o que torna as interfaces lógicas ae0.1 e ae0.2 incapazes de fornecer serviços aos seus respectivos sites de clientes (VLANs).
Para utilizar melhor interfaces lógicas no modo ativo-standby ou ativo ativo multihoming da EVPN, começando pelos versões Junos OS 15.1F6 e 17.1R1 para roteadores da Série MX e o Junos OS Release 17.3R1 para switches EX9200, você pode especificar uma ESI em uma interface lógica. Como resultado, mesmo que uma interface lógica seja não-DF, outras interfaces lógicas na mesma interface Ethernet física ou agregada ainda são capazes de fornecer serviços aos seus respectivos sites de clientes (VLANs).
Para obter mais informações, veja Exemplo: configuração de uma ESI em uma interface lógica com multihoming EVPN.
ESIs geradas automaticamente
A partir do Junos OS Release 18.4R1, você pode configurar interfaces Ethernet agregadas e interfaces lógicas Ethernet agregadas para obter ESIs automaticamente da configuração LACP. Oferecemos suporte a esse recurso nos seguintes ambientes:
Em dispositivos da Juniper Networks que oferecem suporte a esse recurso e são multihomed no modo ativo em uma rede overlay EVPN-VXLAN.
Em dispositivos da Juniper Networks que oferecem suporte a esse recurso e são multihomed no modo ativo de espera ou ativo em uma rede overlay EVPN-MPLS.
Para obter mais informações, veja Como entender as ESIs geradas automaticamente em redes EVPN.
Convergência em uma rede EVPN
Quando há mudanças na topologia de rede em um sistema EVPN de grande escala, o tempo de convergência pode ser significativo. Você pode priorizar atualizações de NLRI que são essenciais para a seleção de rotas em políticas de roteamento para melhorar a convergência. A Tabela 1 lista os tipos de rota NLRI e a prioridade que deve ser configurada na política de roteamento.
Tipo de rota NLRI |
Descrição |
Prioridade |
|---|---|---|
Rota NLRI Tipo 1 |
Rota de autodescoberta da Ethernet — o Tipo 1 oferece suporte a convergência rápida e aliasing e é usado para sinalizar a retirada em massa de MAC. |
Alto |
Rota NLRI Tipo 2 |
Rota de anúncio MAC/IP — o Tipo 2 é usado para anunciar endereços MAC e endereços IP em redes EVPN. |
Baixo |
Rota NLRI Tipo 3 |
Tag Ethernet multicast inclusiva — o Tipo 3 é usado para configurar um caminho para o tráfego BUM. |
Baixo |
Rota NLRI Tipo 4 |
Rota do segmento Ethernet — O EVPN Type 4 é usado na seleção de um encaminhador designado. |
Alto |
Para priorizar o tipo de rota NLRI, definir o bgp-output-queue-priority priority para nlri-route-type [edit policy-options policy-statement] nível de hierarquia em todos os roteadores de borda de provedores e refletores de rota na rede EVPN. Neste exemplo, uma alta prioridade foi configurada para a rota NLRI tipo 1 e a rota NLRI Tipo 4.
user@PE1#show policy-options
policy-statement evpn-rt-priority-policy {
term 1 {
from {
family evpn;
nlri-route-type 1;
}
then {
bgp-output-queue-priority priority 16;
}
}
term 2 {
from {
family evpn;
nlri-route-type 2;
}
then {
bgp-output-queue-priority priority 1;
}
}
term 3 {
from {
family evpn;
nlri-route-type 3;
}
then {
bgp-output-queue-priority priority 2;
}
}
term 4 {
from {
family evpn;
nlri-route-type 4;
}
then {
bgp-output-queue-priority priority 16;
}
}
}
Há 17 filas de saída priorizadas: uma fila acelerada que tem a maior prioridade, e 16 filas numeradas para as quais1 é a menor prioridade e 16 é a mais alta.
Para obter mais informações sobre como configurar políticas de roteamento, veja políticas de roteamento, filtros de firewall e guia de usuários de policiais de tráfego.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.