Entenda a intertrabalho entre EVPN-MPLS e Junos Fusion Enterprise e MC-LAG

Começando pelo Junos OS Release 17.4R1, você pode usar a VPN Ethernet (EVPN) para estender uma rede Junos Fusion Enterprise ou grupo de agregação de enlaces multichassis (MC-LAG) em uma rede MPLS para um data center ou rede de campus. Com a introdução desse recurso, agora você pode interconectar locais dispersos de campus e data center para formar uma única ponte virtual de Camada 2.

A Figura 1 mostra uma topologia Junos Fusion Enterprise com dois switches EX9200 que servem como dispositivos de agregação (PE2 e PE3) aos quais os dispositivos satélites são multihomed. Os dois dispositivos de agregação usam um link de interchassis (ICL) e o protocolo Inter-Chassis Control Protocol (ICCP) do MC-LAG para conectar e manter a topologia Junos Fusion Enterprise. PE1 no ambiente EVPN-MPLS intertrabalha com PE2 e PE3 no Junos Fusion Enterprise com MC-LAG.

Figura 1: Intertrabalho entre EVPN-MPLS e Junos Fusion Enterprise EVPN-MPLS Interworking with Junos Fusion Enterprise

A Figura 2 mostra uma topologia MC-LAG na qual o dispositivo de borda do cliente (CE) CE1 é multihomed para PE2 e PE3. PE2 e PE3 usam um protocolo ICL e ICCP do MC-LAG para conectar e manter a topologia. PE1 no ambiente EVPN-MPLS intertrabalha com PE2 e PE3 no ambiente MC-LAG.

Figura 2: Intertrabalho entre EVPN-MPLS e MC-LAG EVPN-MPLS Interworking with MC-LAG

Ao longo deste tópico, a Figura 1 e a Figura 2 servem como referências para ilustrar vários cenários e pontos.

Os casos de uso descritos na Figura 1 e na Figura 2 exigem a configuração de multihoming EVPN no modo ativo e MC-LAG no PE2 e PE3. A EVPN com multihoming active-active e MC-LAG tem sua própria lógica de encaminhamento para lidar com tráfego, em particular, broadcast, unicast desconhecido e tráfego multicast (BUM). Às vezes, a lógica de encaminhamento para EVPN com multihoming ativo ativo e MC-LAG se contradiz e causa problemas. Este tópico descreve os problemas e como o recurso de intertrabalho EVPN-MPLS resolve esses problemas.

Nota:

Além das implementações específicas de intertrabalho EVPN-MPLS descritas neste tópico, EVPN-MPLS, Junos Fusion Enterprise e MC-LAG oferecem a mesma funcionalidade e funcionam da mesma forma que os recursos autônomos.

Benefícios de usar EVPN-MPLS com Junos Fusion Enterprise e MC-LAG

Use o EVPN-MPLS com o Junos Fusion Enterprise e o MC-LAG para interconectar campus dispersos e locais de data center para formar uma única ponte virtual de Camada 2.

Manuseio de tráfego BUM

Nos casos de uso mostrados na Figura 1 e Figura 2, PE1, PE2 e PE3 são pares de EVPN, e PE2 e PE3 são pares MC-LAG. Ambos os conjuntos de pares trocam informações de controle e encaminham tráfego uns aos outros, o que causa problemas. A Tabela 1 descreve os problemas que surgem e como a Juniper Networks resolve os problemas em sua implementação do recurso de intertrabalho EVPN-MPLS.

Tabela 1: Tráfego BUM: problemas e resoluções
Direção de tráfego BUM	EVPN intertrabalho com Junos Fusion Enterprise e MC-LAG Logic	Questão	Abordagem de implementação da Juniper Networks
North bound (PE2 recebe pacote BUM de uma interface única ou dupla conectada localmente).	PE2 inunda pacote BUM a seguir: Todas as interfaces conectadas localmente, incluindo a ICL, para um determinado domínio de broadcast. Todos os pares EVPN remotos para os quais o PE2 recebeu rotas multicast inclusivas.	Entre PE2 e PE3, existem dois caminhos de encaminhamento BUM — o MC-LAG ICL e um caminho EVPN-MPLS. Os múltiplos caminhos de encaminhamento resultam em duplicação e loops de pacotes.	O tráfego BUM é encaminhado apenas na ICL. O tráfego recebido do núcleo EVPN não é encaminhado na ICL. O tráfego recebido da ICL não é encaminhado para o núcleo EVPN.
South bound (PE1 encaminha pacote BUM para PE2 e PE3).	PE2 e PE3 recebem uma cópia do pacote BUM e inundam o pacote de todas as suas interfaces locais, incluindo a ICL.	PE2 e PE3 encaminham o pacote BUM para fora da ICL, o que resulta em duplicação de pacotes e loops.

Horizonte dividido

Nos casos de uso mostrados na Figura 1 e na Figura 2, o horizonte dividido impede que várias cópias de um pacote BUM sejam encaminhadas para um dispositivo CE (dispositivo satélite). No entanto, as implementações de horizonte dividido EVPN-MPLS e MC-LAG se contradizem, o que causa um problema. A Tabela 2 explica o problema e como a Juniper Networks o resolve em sua implementação do recurso de intertrabalho EVPN-MPLS.

Tabela 2: Tráfego BUM: problema e resolução relacionados ao horizonte dividido
Direção de tráfego BUM	EVPN intertrabalho com Junos Fusion Enterprise e MC-LAG Logic	Questão	Abordagem de implementação da Juniper Networks
North bound (PE2 recebe pacote BUM de uma interface localmente anexada de casa dupla).	Pela lógica de encaminhamento EVPN-MPLS: Apenas o encaminhamento designado (DF) para o segmento Ethernet (ES) pode encaminhar o tráfego BUM. A regra de viés local, na qual o peer local encaminha o pacote BUM e o peer remoto o derruba, não é suportada. De acordo com a lógica de encaminhamento do MC-LAG, o viés local é suportado.	A lógica de encaminhamento de EVPN-MPLS e MC-LAG se contradiz e pode impedir que o tráfego BUM seja encaminhado para o ES.	Suporte a vieses locais, ignorando assim o status df e não-DF da porta para tráfego comutada localmente.
South bound (PE1 encaminha pacote BUM para PE2 e PE3).	O tráfego recebido do PE1 segue as regras de encaminhamento EVPN DF e não-DF para um ES mulithomed.	Nenhum.	Não aplicável.

Aprendizado MAC

EVPN e MC-LAG usam o mesmo método para aprender endereços MAC — ou seja, um dispositivo PE aprende endereços MAC a partir de suas interfaces locais e sincroniza os endereços para seus pares. No entanto, dado que tanto a EVPN quanto o MC-LAG estão sincronizando os endereços, surge um problema.

A Tabela 3 descreve o problema e como a implementação de intertrabalho EVPN-MPLS impede o problema. Os casos de uso mostrados na Figura 1 e na Figura 2 ilustram o problema. Em ambos os casos de uso, PE1, PE2 e PE3 são pares de EVPN, e PE2 e PE3 são pares MC-LAG.

Tabela 3: MAC Learning: Problema de sincronização e implantação de EVPN e MC-LAG
Caso de uso de sincronização MAC	EVPN intertrabalho com Junos Fusion Enterprise e MC-LAG Logic	Questão	Abordagem de implementação da Juniper Networks
Endereços MAC aprendidos localmente em interfaces individuais ou duplas em PE2 e PE3.	Entre os pares EVPN, os endereços MAC são sincronizados usando o plano de controle EVPN BGP. Entre os pares MC-LAG, os endereços MAC são sincronizados usando o plano de controle MC-LAG ICCP.	PE2 e PE3 funcionam como pares EVPN e pares MC-LAG, o que resulta em vários caminhos de sincronização MAC nesses dispositivos.	Para PE1: use endereços MAC sincronizados pelo plano de controle BGP EVPN. Para PE2 e PE3: use endereços MAC sincronizados pelo plano de controle MC-LAG ICCP.
Endereços MAC aprendidos localmente em interfaces de casa única ou dupla no PE1.	Entre os pares EVPN, os endereços MAC são sincronizados usando o plano de controle EVPN BGP.	Nenhum.	Não aplicável.

Manuseio da ligação entre portas cascata e uplink no Junos Fusion Enterprise

Nota:

Esta seção se aplica apenas ao intertrabalho EVPN-MPLS com uma Junos Fusion Enterprise.

No Junos Fusion Enterprise mostrado na Figura 1, suponha que o dispositivo de agregação PE2 recebe um pacote BUM do PE1 e que a ligação entre a porta cascata no PE2 e a porta de uplink correspondente no dispositivo satélite SD1 está baixa. Independentemente de o pacote BUM ser tratado por MC-LAG ou multihoming EVPN ativo ativo, o resultado é o mesmo — o pacote é encaminhado através da interface ICL para PE3, que o encaminha para SD1 de dupla casa.

Para ilustrar ainda mais como a EVPN com multihoming active-active lida com essa situação com SD1 dual-homed, assuma que a interface DF reside no PE2 e está associada com o link para baixo e que a interface não-DF reside no PE3. Normalmente, por EVPN com lógica de encaminhamento ativo-ativo multihoming, a interface não-DF derruba o pacote. No entanto, devido ao link para baixo associado à interface DF, o PE2 encaminha o pacote BUM através da ICL para PE3, e a interface não-DF no PE3 encaminha o pacote para SD1.

Suporte para gateways de camada 3

O recurso de intertrabalho EVPN-MPLS oferece suporte à seguinte funcionalidade de gateway de Camada 3 para domínios de ponte estendidos e VLANs:

Interfaces de roteamento e ponte integradas (IRB) para encaminhar tráfego entre os domínios de ponte estendidos ou VLANs.
Gateways de Camada 3 padrão para encaminhar tráfego de um servidor físico (bare-metal) em um domínio de ponte estendido ou VLAN para um servidor físico ou máquina virtual em outro domínio de ponte estendido ou VLAN.

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.

Soltar

Descrição

17.4R1