Entender a intertrabalho EVPN-MPLS com o Junos Fusion Enterprise e o MC-LAG

A partir do 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 enlace multichassis (MC-LAG) em uma rede MPLS para um data center ou rede de campus. Com a introdução deste 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 EVPN-MPLS com o Junos Fusion Enterprise EVPN-MPLS Interworking with Junos Fusion Enterprise

A Figura 2 mostra uma topologia MC-LAG em que o dispositivo CE1 da borda do cliente (CE) é multihomed para PE2 e PE3. PE2 e PE3 usam um ICL e o protocolo 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-ativo e MC-LAG em PE2 e PE3. A EVPN com multihoming active-active e MC-LAG tem sua própria lógica de encaminhamento para lidar com o 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 contradize 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 do uso de EVPN-MPLS com Junos Fusion Enterprise e MC-LAG

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

Tratamento 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 na implementação do recurso de intertrabalho EVPN-MPLS.

Tabela 1: Tráfego BUM: problemas e resoluções
Direção de tráfego BUM	Interconexão de EVPN 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 domínio de broadcast específico. 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.
Sul (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 interfaces locais, incluindo a ICL.	PE2 e PE3 encaminham o pacote BUM para fora da ICL, o que resulta em duplicação e loops de pacotes.

Horizonte dividido

Nos casos de uso mostrados na Figura 1 e na Figura 2, o split horizon 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 na implementação do recurso de intertrabalho EVPN-MPLS.

Tabela 2: tráfego BUM: problema e resolução relacionados ao Split Horizon
Direção de tráfego BUM	Interconexão de EVPN 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 dual-homed conectada localmente).	Por lógica de encaminhamento EVPN-MPLS: Apenas o encaminhamento (DF) designado para o segmento de 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. Por lógica de encaminhamento 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 ao viés local, ignorando assim o status df e não-DF da porta para tráfego comutada localmente.
Sul (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 com 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: Problemas de sincronização e implementação de EVPN e MC-LAG
Caso de uso de sincronização MAC	Interconexão de EVPN 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 de EVPN e MC-LAG, o que resulta em vários caminhos de sincronização MAC.	Para PE1: use endereços MAC sincronizados pelo plano de controle EVPN BGP. Para PE2 e PE3: use endereços MAC sincronizados pelo plano de controle MC-LAG ICCP.
Endereços MAC aprendidos localmente em interfaces individuais ou duplas 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.

Manipulação da ligação entre portas Cascata e Uplink no Junos Fusion Enterprise

Nota:

Esta seção se aplica apenas à 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 de 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 pela interface ICL para PE3, que o encaminha para SD1 dual-homed.

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 ao link down 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, por causa do link down 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 à funcionalidade de gateway de Camada 3 a seguir 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 estendida ou VLANs.
Gateways padrão de Camada 3 para encaminhar tráfego de um servidor físico (bare-metal) em um domínio de ponte estendida ou VLAN para um servidor físico ou máquina virtual em outro domínio de ponte estendida ou VLAN.

Tabela de histórico de lançamento

Lançamento

Descrição

17.4R1