Entender a interoperação de EVPN-MPLS com o Junos Fusion Enterprise e o MC-LAG
Você pode usar a VPN Ethernet (EVPN) para estender uma rede Junos Fusion Enterprise ou de grupo de agregação de enlace multichassis (MC-LAG) através de uma rede MPLS para uma rede de data center ou 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 do Junos Fusion Enterprise com dois switches EX9200 que servem como dispositivos de agregação (PE2 e PE3) para os quais os dispositivos satélites são multihomed. Os dois dispositivos de agregação usam um enlace de interchassis (ICL) e o protocolo de controle entre chassis (ICCP) do MC-LAG para conectar e manter a topologia do Junos Fusion Enterprise. O PE1 no ambiente EVPN-MPLS interfunciona com o PE2 e o PE3 no Junos Fusion Enterprise com o MC-LAG.
A Figura 2 mostra uma topologia MC-LAG na qual o dispositivo de borda do cliente (CE) CE1 é multihomed para PE2 e PE3. O PE2 e o PE3 usam uma ICL e o protocolo ICCP do MC-LAG para conectar e manter a topologia. O PE1 no ambiente EVPN-MPLS interfunciona com o PE2 e o PE3 no ambiente 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 de EVPN no modo ativo-ativo e MC-LAG em PE2 e PE3. A EVPN com multihoming ativo-ativo e MC-LAG tem sua própria lógica de encaminhamento para lidar com tráfego, em particular, tráfego de broadcast, unicast desconhecido e multicast (BUM). Às vezes, a lógica de encaminhamento para EVPN com multihoming ativo-ativo e MC-LAG se contradizem e causam problemas. Este tópico descreve os problemas e como o recurso de interfuncionamento EVPN-MPLS resolve esses problemas.
Além das implementações específicas de interfuncionamento 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, exceto nos seguintes cenários:
-
Não oferecemos suporte ao recurso de isolamento de núcleo com interfuncionamento ativo/ativo EVPN-MPLS e ativo/ativo MC-LAG.
Benefícios de usar o EVPN-MPLS com o Junos Fusion Enterprise e o 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 na Figura 2, PE1, PE2 e PE3 são pares EVPN, e PE2 e PE3 são pares MC-LAG. Ambos os conjuntos de pares trocam informações de controle e encaminham o tráfego entre si, o que causa problemas. A Tabela 1 descreve os problemas que surgem e como os resolvemos na implementação do recurso de interfuncionamento EVPN-MPLS.
|
BUM Direção de Tráfego |
Interfuncionamento da EVPN com o Junos Fusion Enterprise e a lógica MC-LAG |
Questão |
Abordagem de implementação da Juniper Networks |
|---|---|---|---|
|
Limite norte (PE2 recebe pacote BUM de interfaces single-homed ou dual-homed conectadas localmente). |
O PE2 inunda o pacote BUM para o seguinte:
|
Entre o PE2 e o PE3, existem dois caminhos de encaminhamento do BUM: o MC-LAG ICL e um caminho EVPN-MPLS. O encaminhamento múltiplo pa=++++ Isso resulta em duplicação e loops de pacotes. |
|
|
Sentido sul (PE1 encaminha pacote BUM para PE2 e PE3). |
O PE2 e o PE3 recebem uma cópia do pacote BUM e inundam o pacote de todas as suas interfaces locais, incluindo a ICL. |
O PE2 e o 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 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 interfuncionamento EVPN-MPLS.
|
BUM Direção de Tráfego |
Interfuncionamento da EVPN com o Junos Fusion Enterprise e a lógica MC-LAG |
Questão |
Abordagem de implementação da Juniper Networks |
|---|---|---|---|
|
Limite norte (PE2 recebe pacote BUM de uma interface dual-homed conectada localmente). |
|
A lógica de encaminhamento EVPN-MPLS e MC-LAG se contradiz e pode impedir que o tráfego BUM seja encaminhado para o ES. |
Oferecer suporte ao viés local, ignorando assim o status DF e não DF da porta para tráfego comutado localmente. |
|
Sentido 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 multihomed. |
Nenhum. |
Não aplicável. |
Aprendizagem MAC
A EVPN e a MC-LAG usam o mesmo método para aprender endereços MAC — ou seja, um dispositivo PE aprende endereços MAC de suas interfaces locais e sincroniza os endereços com seus pares. No entanto, como a EVPN e o MC-LAG estão sincronizando os endereços, surge um problema.
A Tabela 3 descreve o problema e como a implementação de interfuncionamento EVPN-MPLS evita 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 EVPN, e PE2 e PE3 são pares MC-LAG.
|
Caso de uso de sincronização MAC |
Interfuncionamento da EVPN com o Junos Fusion Enterprise e a lógica MC-LAG |
Questão |
Abordagem de implementação da Juniper Networks |
|---|---|---|---|
|
Endereços MAC aprendidos localmente em interfaces single-homed ou dual-homed em PE2 e PE3. |
|
O PE2 e o PE3 funcionam como pares EVPN e MC-LAG, o que faz com que esses dispositivos tenham vários caminhos de sincronização MAC. |
|
|
Endereços MAC aprendidos localmente em interfaces single- ou dual-homed no PE1. |
Entre os peers EVPN, os endereços MAC são sincronizados usando o plano de controle BGP da EVPN. |
Nenhum. |
Não aplicável. |
Como lidar com o enlace descendente entre portas em cascata e uplink no Junos Fusion Enterprise
Esta seção se aplica apenas ao interfuncionamento de EVPN-MPLS com um Junos Fusion Enterprise.
No Junos Fusion Enterprise mostrado na Figura 1, suponha que o dispositivo de agregação PE2 receba um pacote BUM do PE1 e que o enlace entre a porta em cascata no PE2 e a porta de uplink correspondente no dispositivo de satélite SD1 esteja inativo. Independentemente de o pacote BUM ser tratado por MC-LAG ou EVPN multihoming ativo-ativo, o resultado é o mesmo — o pacote é encaminhado pela interface ICL para PE3, que o encaminha para SD1 dual-homed.
Para ilustrar melhor como a EVPN com multihoming ativo-ativo lida com essa situação com o SD1 dual-homed, suponha que a interface DF resida no PE2 e esteja associada ao link descendente e que a interface não DF resida no PE3. Normalmente, por EVPN com lógica de encaminhamento ativo-ativo multihoming, a interface não DF descarta o pacote. No entanto, devido ao link descendente associado à interface DF, o PE2 encaminha o pacote BUM via ICL para o PE3, e a interface não DF no PE3 encaminha o pacote para o SD1.
Suporte a gateway de Camada 3
O recurso de interfuncionamento EVPN-MPLS suporta a seguinte funcionalidade de gateway de Camada 3 para domínios de ponte estendidos e VLANs:
-
Interfaces integradas de roteamento e ponte (IRB) para encaminhar o 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 bridge estendido ou VLAN para um servidor físico ou máquina virtual em outro domínio de bridge estendido ou VLAN.
Tabela de histórico de alterações
A compatibilidade com recursos é determinada pela plataforma e versão utilizada. Use o Explorador de recursos para determinar se um recurso é compatível com sua plataforma.