Conceitos avançados de MC-LAG

Benefícios da sincronização de configuração

A sincronização de configuração permite propagar, sincronizar e comprometer configurações de um dispositivo para outro. Você pode fazer login em qualquer um desses dispositivos para gerenciar todos os dispositivos, tendo assim um único ponto de gerenciamento.

Como funciona a sincronização de configuração

Use grupos de configuração para simplificar o processo de configuração. Por exemplo, você pode criar um grupo de configuração para o dispositivo local, um ou mais para dispositivos remotos e um para a configuração global, que é essencialmente uma configuração comum a todos os dispositivos.

Além disso, você pode criar grupos condicionais para especificar quando uma configuração é sincronizada com outro dispositivo. Você pode habilitar a peers-synchronize declaração na [edit system commit] hierarquia a sincronizar as configurações e os compromissos entre os dispositivos por padrão. O NETCONF over SSH fornece uma conexão segura entre os dispositivos, e o Secure Copy Protocol (SCP) copia as configurações com segurança entre eles.

Como habilitar a sincronização de configuração

Para habilitar a sincronização de configuração, execute as seguintes etapas:

1. Mapeie estaticamente o dispositivo local para os dispositivos remotos.

2. Crie grupos de configuração para configurações locais, remotas e globais.

3. Crie grupos condicionais.

4. Crie grupos aplicáveis.

5. Habilite o NETCONF sobre SSH.

6. Configure os detalhes do dispositivo e os detalhes de autenticação do usuário para sincronização de configuração.

7. Habilite a peers-synchronize declaração ou emita o commit peers-synchronize comando para sincronizar e comprometer as configurações entre dispositivos locais e remotos.

Como a sincronização de configuração é suportada

Nos roteadores da Série MX e no Junos Fusion, o suporte para sincronização de configuração começou com o Junos OS Release 14.2R6. Nos switches da Série QFX, o suporte para sincronização de configuração começou com o Junos OS Release 15.1X53-D60.

Grupos de configuração para configurações locais, remotas e globais

Você pode criar grupos de configuração para configurações locais, remotas e globais. Um grupo de configuração local é usado pelo dispositivo local, um grupo de configuração remota é usado pelo dispositivo remoto, e um grupo de configuração global é compartilhado entre os dispositivos locais e remotos.

Por exemplo, você poderia criar um grupo de configuração local chamado Grupo A, que incluiria a configuração usada pelo dispositivo local (Switch A), um grupo de configuração remota chamado Grupo B, que incluiria a configuração usada por dispositivos remotos (Switch B, Switch C e Switch D), e um grupo de configuração global chamado Grupo C, que incluiria a configuração que é comum a todos os dispositivos.

Crie grupos de configuração no nível de [edit groups] hierarquia.

Criação de grupos condicionais para determinados dispositivos

Você pode criar grupos condicionais para especificar quando uma configuração específica deve ser aplicada a um dispositivo. Se você quiser aplicar a configuração global a todos os dispositivos em uma configuração de quatro dispositivos, por exemplo, habilite a when peers [<name of local peer> <name of remote peer> <name of remote peer> <name of remote peer>] declaração no nível de [edit groups] hierarquia. Se, por exemplo, você quiser aplicar a configuração global (Grupo C) aos dispositivos locais e remotos (Switch A, Switch B, Switch C e Switch D), você pode emitir o set groups Group C when peers [Switch A Switch B Switch C Switch D] comando.

Aplicando grupos de configuração

Para aplicar grupos de configuração, habilite a apply-groups declaração no nível de [edit] hierarquia. Por exemplo, para aplicar o grupo de configuração local (Grupo A, por exemplo), o grupo de configuração remota (Grupo B, por exemplo) e o grupo de configuração global (Grupo C, por exemplo), emitem o set apply-groups [ GroupA GroupB GroupC ] comando.

Detalhes da configuração do dispositivo para sincronização de configuração

Para sincronizar configurações entre dispositivos, você precisa configurar o nome de host ou endereço IP, nome de usuário e senha para os dispositivos remotos. Para fazer isso, emita o set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string> comando na [edit system commit] hierarquia do dispositivo local.

Por exemplo, para sincronizar uma configuração do Switch A ao Switch B, emita o set peers SwitchB user administrator authentication test123 comando no Switch A.

Você também precisa mapear esteticamente o dispositivo local para os dispositivos remotos. Para isso, emitimos set system commit peers

Por exemplo, para sincronizar uma configuração do Switch A ao Switch B, Switch C e Switch D, configure o seguinte no Switch A:

Switch A

Se você só quiser sincronizar configurações do Switch A ao Switch B, Switch C e Switch D, você não precisa configurar a peers declaração no Switch B, Switch C e Switch D.

Os detalhes de configuração das declarações de pares também são usados para estabelecer um NETCONF sobre a conexão SSH entre os dispositivos. Para habilitar o NETCONF sobre SSH, emita o set system services netconf ssh comando em todos os dispositivos.

Como as configurações e compromissos são sincronizados entre dispositivos

O dispositivo local (ou solicitação) no qual você habilita a peers-synchronize declaração ou emite as cópias de commit peers-synchronize comando e carrega sua configuração para o dispositivo remoto (ou resposta). Cada dispositivo então executa uma verificação de sintaxe no arquivo de configuração que está sendo cometido. Se não forem encontrados erros, a configuração será ativada e se tornará a configuração operacional atual em todos os dispositivos. Os compromissos são propagados usando uma chamada processual remota (RPC).

Os eventos a seguir ocorrem durante a sincronização da configuração:

1. O dispositivo local envia o arquivo sync-peers.conf (a configuração que será compartilhada com os dispositivos especificados no grupo condicional) para os dispositivos remotos.

2. Os dispositivos remotos carregam a configuração, enviam os resultados da carga para o dispositivo local, exportam sua configuração para o dispositivo local e respondem que o commit está completo.

3. O dispositivo local lê as respostas dos dispositivos remotos.

4. Se for bem-sucedida, a configuração está comprometida.

A sincronização de configuração não é bem sucedida se a) o dispositivo remoto não estiver disponível ou b) o dispositivo remoto é acessível, mas existem falhas devido aos seguintes motivos:

• A conexão SSH falha por causa de problemas de usuário e autenticação.

• O Junos OS RPC falha porque um bloqueio não pode ser obtido no banco de dados remoto.

• Carregar a configuração falha por causa de problemas de sintaxe.

• A verificação de confirmação falha.

A peers-synchronize declaração usa o nome de host ou endereço IP, nome de usuário e senha para os dispositivos que você configurou na peers declaração. Com a peers-synchronize declaração habilitada, você pode simplesmente emitir o commit comando para sincronizar a configuração de um dispositivo para outro. Por exemplo, se você configurou a peers declaração no dispositivo local e quiser sincronizar a configuração com o dispositivo remoto, você pode simplesmente emitir o commit comando no dispositivo local. No entanto, se você emitir o commit comando no dispositivo local e o dispositivo remoto não for acessível, você receberá uma mensagem de aviso dizendo que o dispositivo remoto não é acessível e apenas a configuração no dispositivo local é comprometida:

Aqui está uma mensagem de aviso de exemplo:

Se você não tiver a peers declaração configurada com as informações remotas do dispositivo e emitir o commit comando, apenas a configuração no dispositivo local será comprometida. Se o dispositivo remoto for inalcançável e houver outras falhas, o commit não será bem sucedido nos dispositivos locais e remotos.

O commit peers-synchronize comando também usa o nome de host ou endereço IP, nome de usuário e senha para os dispositivos configurados na peers declaração. Se você emitir o commit peers-synchronize comando no dispositivo local para sincronizar a configuração com o dispositivo remoto e o dispositivo remoto for acessível, mas houver outras falhas, o commit falha nos dispositivos locais e remotos.

Benefícios do uso da verificação de consistência MC-LAG

• Esse recurso ajuda você a encontrar inconsistências de parâmetros de configuração entre os pares do grupo de agregação de enlaces multichassis (MC-LAG).

Como as verificações de consistência do MC-LAG funcionam

Os eventos a seguir ocorrem durante a verificação da consistência da configuração após você emitir um compromisso no peer MC-LAG local:

1. Comprometa uma configuração MC-LAG no peer MC-LAG local.

2. O ICCP analisa a configuração MC-LAG e envia a configuração para o peer MC-LAG remoto.

3. O peer MC-LAG remoto recebe a configuração MC-LAG do peer MC-LAG local e a compara com sua própria configuração MC-LAG.

   Se houver uma grave inconsistência entre as duas configurações MC-LAG, a interface MC-LAG será derrubada e as mensagens de syslog forem emitidas.

   Se houver uma inconsistência moderada entre as duas configurações, as mensagens de syslog serão emitidas.

Os eventos a seguir ocorrem durante a verificação da consistência da configuração após você emitir um compromisso no peer MC-LAG remoto:

• Comprometa uma configuração MC-LAG no peer MC-LAG remoto.

• O ICCP analisa a configuração MC-LAG e envia a configuração para o peer MC-LAG local.

• O peer MC-LAG local recebe a configuração do peer MC-LAG remoto e a compara com sua própria configuração.

  Se houver uma grave inconsistência entre as duas configurações, a interface MC-LAG será derrubada e as mensagens de syslog forem emitidas.

  Se houver uma inconsistência moderada entre as duas configurações, as mensagens de syslog serão emitidas.

Requisitos de consistência de configuração

Existem diferentes requisitos de consistência de configuração, dependendo dos parâmetros MC-LAG. Os requisitos de consistência são idênticos ou únicos, o que significa que alguns parâmetros devem ser configurados de maneira idêntica e alguns devem ser configurados exclusivamente nos pares MC-LAG. Por exemplo, o ID do chassi deve ser exclusivo em ambos os pares, enquanto o modo LACP deve ser idêntico em ambos os pares.

O nível de aplicação dos requisitos de consistência (idênticos ou únicos) é obrigatório ou desejado. Quando o nível de aplicação é obrigatório e você configura o parâmetro MC-LAG incorretamente, o sistema derruba a interface e emite uma mensagem de syslog.

Por exemplo, você recebe uma mensagem de syslog que diz “Some of the Multichassis Link Aggregation (MC-LAG) configuration parameters between the peer devices are not consistent. The concerned MC-LAG interfaces were explictly brought down to prevent unwanted behavior.” : Quando você corrige a inconsistência e emite um compromisso bem-sucedido, o sistema criará a interface. Quando a aplicação é desejada e você configura o parâmetro MC-LAG incorretamente, você recebe uma mensagem de syslog que diz que, "Some of the Multichassis Link Aggregation(MC-LAG) configuration parameters between the peer devices are not consistent. This may lead to sub-optimal performance of the feature." como observado na mensagem de syslog, o desempenho será sub-ideal nessa situação. Você também pode emitir as interfaces de exibição do comando mc-ae para exibir o status de verificação de consistência de configuração da interface Ethernet agregada multichassis.

Se houver várias inconsistências, apenas a primeira inconsistência é mostrada. Se o nível de aplicação de um parâmetro MC-LAG for obrigatório e você não configurar esse parâmetro corretamente, o comando mostra que a interface MC-LAG está baixa.

Quando os pares remotos não são alcançáveis

Quando você emite um commit no peer local, e o peer remoto não é acessível, a verificação de consistência de configuração passará para que o peer local possa aparecer em modo autônomo. Quando o peer remoto aparece, o ICCP troca as configurações entre os pares. Se a verificação de consistência falhar, a interface MC-LAG diminuirá e o sistema notificará você do parâmetro que causou a inconsistência. Quando você corrige a inconsistência e emite um commit bem-sucedido, o sistema traz a interface.

Habilitando a verificação da consistência da configuração MC-LAG

A verificação de consistência é habilitada por padrão. A Tabela 1 fornece uma lista amostra de parâmetros MC-LAG comprometidos que são verificados em busca de consistência, juntamente com seus requisitos de consistência (idênticos ou únicos), hierarquias nas quais os parâmetros estão configurados e os níveis de aplicação de verificação de consistência (obrigatórios ou desejados).

Aprendendo o status de uma verificação de consistência de configuração

Os comandos a seguir fornecem informações sobre o status da consistência da configuração:

• Emitimos o comando de lista de parâmetros de consistência de configuração mc-lag multi-chassi para visualizar a lista de parâmetros MC-LAG comprometidos que são verificados por inconsistências, o requisito de consistência (idêntico ou único) e o nível de aplicação (obrigatório ou desejado).

• Emitimos o comando de consistência de configuração mc-lag multi-chassi para visualizar a lista de parâmetros MC-LAG comprometidos que são verificados por inconsistências, o requisito de consistência (idêntico ou único), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação da consistência da configuração. Os resultados são aprovados ou falham.

• Emitimos o comando de configuração global mc-lag multi-chassi para exibir o status de verificação de consistência de configuração para todas as configurações globais relacionadas à funcionalidade MC-LAG, o requisito de consistência (idêntico ou único), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação da consistência da configuração. Os resultados são aprovados ou reprovam.

• Emita o comando de configuração de mc-lag multi-chassi para visualizar o status de verificação da consistência da configuração para parâmetros relacionados ao link de controle de interchasse, ao requisito de consistência (idêntico ou único), ao nível de aplicação (obrigatório ou desejado) e ao resultado da verificação da consistência da configuração. Os resultados são aprovados ou falham.

• Emita o comando mcae-config de consistência de configuração mcae-config multi-chassi para exibir o status de verificação de consistência de configuração para parâmetros relacionados à interface Ethernet agregada multichassis, o requisito de consistência (idêntico ou único), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação da consistência da configuração. Os resultados são aprovados ou falham.

• Emita o comando vlan-config com consistência de configuração multi-chassi para exibir o status de verificação da consistência da configuração para parâmetros relacionados à configuração de VLAN, o requisito de consistência (idêntico ou único), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação da consistência da configuração. Os resultados são aprovados ou reprovam.

• Emitimos o comando de configuração vrrp-config multi-chassi para exibir o status de verificação da consistência da configuração para parâmetros relacionados à configuração VRRP, o requisito de consistência (idêntico ou único), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação da consistência da configuração. Os resultados são aprovados ou falham.

• Emitimos as interfaces de show do comando mc-ae para visualizar o status de verificação de consistência de configuração da interface Ethernet agregada multichassis. Se houver várias inconsistências, apenas a primeira inconsistência é mostrada. Se o nível de aplicação do parâmetro MC-LAG for obrigatório e você não configurar esse parâmetro corretamente, o comando mostrará que a interface MC-LAG está baixa.

Suporte para verificação de consistência de configuração MC-LAG

Ambos os switches da Série EX e os switches da Série QFX oferecem suporte à verificação da consistência da configuração MC-LAG.

Começando pelo Junos OS Release 15.1X53-D60 nos switches QFX10000, a verificação da consistência da configuração usa o Protocolo de Controle Inter-Chassis (ICCP) para trocar parâmetros de configuração MC-LAG (ID do chassi, ID de serviço e assim por diante) e verifica se há inconsistências de configuração entre os pares MC-LAG.

Operação pim com modo normal Eleição de roteador designado

No modo normal, com a eleição de roteador designada, as interfaces IRB ou RVI em ambos os pares MC-LAG estão configuradas com o PIM habilitado. Nesse modo, um dos pares MC-LAG torna-se o roteador designado através do mecanismo de eleição de roteador designado pelo PIM. O roteador designado eleito mantém a árvore de ponto de encontro (RPT) e a árvore de caminho mais curto (SPT) para que possa receber dados do dispositivo de origem. O roteador designado eleito participa de atividades periódicas de PIM em direção ao ponto de encontro ou à fonte.

O gatilho para iniciar essas atividades de adesão e podar são os relatórios de membros do IGMP que são recebidos de receptores interessados. Os relatórios IGMP recebidos por interfaces Ethernet agregadas por multichassis (potencialmente hashing em qualquer um dos pares MC-LAG) e links de casa única são sincronizados com o peer MC-LAG através do ICCP.

Ambos os pares MC-LAG recebem tráfego em sua interface de entrada (IIF). O roteador não designado recebe tráfego por meio da interface ICL, que funciona como uma interface de roteador multicast (mrouter).

Se o roteador designado falhar, o roteador não designado precisa construir toda a árvore de encaminhamento (RPT e SPT), o que pode causar perda de tráfego multicast.

Operação PIM com modo roteador duplo designado

No modo roteador duplo designado, ambos os pares MC-LAG atuam como roteadores designados (ativos e de espera) e enviam mensagens periódicas de junção e podamento rio acima em direção ao ponto de encontro, ou fonte, e eventualmente se juntam ao RPT ou SPT.

O peer MC-LAG principal encaminha o tráfego multicast para os dispositivos receptores, mesmo que o peer MC-LAG de espera tenha uma métrica de preferência menor.

O peer MC-LAG de espera também se junta à árvore de encaminhamento e recebe os dados multicast. O peer MC-LAG de espera derruba os dados porque ele tem uma lista de interface de saída vazia (OIL). Quando o peer MC-LAG de espera detecta a falha primária de peer MC-LAG, ele adiciona o receptor VLAN ao OIL e começa a encaminhar o tráfego multicast.

Para habilitar um roteador de dupla designação multicast, emita o set protocols pim interface interface-name dual-dr comando nas interfaces VLAN de cada peer MC-LAG.

Tratamento de falhas

Para garantir uma convergência mais rápida durante falhas, configure o endereço IP no peer MC-LAG principal com um endereço IP mais alto ou com uma prioridade de roteador mais alta designada. Isso garante que o peer MC-LAG principal retenha a assinatura de roteador designada se o peering PIM cair.

Para garantir que o tráfego converga se uma interface MC-AE cair, a interface ICL-PL é sempre adicionada como uma porta mrouter. O tráfego de camada 3 é alagado pela entrada padrão ou pela entrada de espionagem na interface ICL-PL, e o tráfego é encaminhado na interface MC-AE no peer MC-LAG. Se a interface ICL-PL cair, a vizinha PIM cairá. Nesse caso, ambos os pares MC-LAG tornam-se o roteador designado. O peer MC-LAG de backup reduz seus links e o peering de roteamento é perdido. Se a conexão ICCP cair, o peer de backup MC-LAG muda o ID do sistema LACP e derruba as interfaces MC-AE. O estado dos vizinhos do PIM continua operacional.

IGMP Snooping na funcionalidade do modo ativo-ativo MC-LAG

O modo ativo ativo de grupo de agregação de enlace multichassis (MC-LAG) e a espionagem de IGMP no modo de espera ativa são suportados. O MC-LAG permite que um dispositivo forme uma interface LAG lógica com dois ou mais dispositivos de rede. O MC-LAG oferece benefícios adicionais, incluindo redundância de nível de nó, multihoming e uma rede de Camada 2 sem loop sem executar o Spanning Tree Protocol (STP). Os recursos a seguir são suportados:

• Sincronização de estado entre pares para IGMP bisbilhotar em um domínio de ponte com apenas interfaces de Camada 2

• Aprendizado qualificado

• Links multichassis voltados para roteador

Os seguintes aprimoramentos para a ponte ativa e o protocolo de redundância de roteador virtual (VRRP) sobre roteamento integrado e ponte (IRB) são suportados:

• Suporte MC-LAG para IGMP bisbilhotando um switch de Camada 2 puro

• Suporte MC-LAG para bisbilhotar IGMP em domínios de ponte fazendo aprendizado qualificado

• Suporte para o MC-Links ser interfaces voltadas para roteadores

As funções a seguir são not suportadas:

• MC-LAG para instâncias VPLS

• Portas de tronco MC-Links

• Modo proxy para ativo-ativo

• Adicionando links de interchasse a interfaces de saída conforme necessário

  Os links de interchassis podem ser adicionados à lista de interfaces de saída como interfaces voltadas para roteadores.

Topologia de rede normalmente suportada para bisbilhotar IGMP com ponte ativa MC-LAG

A Figura 1 mostra uma topologia de rede típica sobre a qual o IGMP com a ponte ativa MC-LAG é suportado.

Figura 1: rede típica sobre a qual o active-active é suportado

Interfaces I3 e I4 são interfaces de casa única. Os enlaces multichassis ae0.0 e ae0.1 pertencem ao mesmo domínio de ponte em ambos os chassis. As interfaces I3, ae0.0 e ae0.1 estão no mesmo domínio de ponte no roteador ativo secundário (S-A). As interfaces I4, ae0.0 e ae0.1 estão no mesmo domínio de ponte no roteador ativo primário (P-A). As interfaces I3, I4, ae0.0 e ae0.1 estão no mesmo domínio de aprendizado que o enlace interchassis (ICL) que conecta os dois chassis.

O roteador ativo principal é o chassi no qual o roteamento integrado e a ponte se tornaram PIM-DR. O roteador ativo secundário é o chassi no qual o roteamento integrado e a ponte não é PIM-DR. O roteador P-A é o chassi responsável por retirar o tráfego do núcleo IP. Assim, a eleição do PIM-DR é usada para evitar a duplicação do tráfego de dados.

Os domínios de aprendizagem são descritos em Aprendizado Qualificado.

Para os alto-falantes IGMP (hosts e roteadores) no domínio de aprendizado, P-A e S-A juntos devem aparecer como um único dispositivo com interfaces I4, I3, ae0.0 e ae0.1.

Nenhum pacote de controle duplicado deve ser enviado em links multichassis, o que significa que o pacote de controle deve ser enviado por apenas um link.

Atualizações de estado do plano de controle acionadas por pacotes recebidos em chassi remoto

A seguir estão as atualizações de estado do plano de controle que são acionadas pelos pacotes recebidos no chassi remoto:

• O estado de adesão ao roteamento multicast de Camada 3 é atualizado como resultado de relatórios aprendidos em pernas remotas de links multichassis e links S conectados ao chassi remoto.

• O estado de adesão e a entrada de roteamento na espionagem são atualizados quando os relatórios são recebidos nas pernas remotas de um link multichassis.

Encaminhamento de dados

Essa discussão assume que o roteamento integrado e a ponte no P-A do roteador é o PIM-DR. Ele puxa o tráfego de fontes no núcleo. O tráfego também pode vir em interfaces de Camada 2 no domínio da ponte. Para hosts conectados diretamente ao chassi P-A, não há mudança na forma como os dados são entregues.

Para fornecer tráfego a hosts conectados à S-A (que não é o DR) no enlace único como o I3, contamos com o link de interchasse. O tráfego que atinge a P-A é enviado por ICL para S-A para ser entregue nos links que relataram interesses em s,g e nos enlaces voltados para o roteador.

Quando a perna ae0 em P-A cai, os hosts conectados ao enlace multichassis recebem tráfego através da ICL. No S-A, o tráfego recebido no ICL é enviado para links multichassis na lista de interfaces de saída para a qual a contrapartida Ae em P-A está baixa.

Topologia de Camada 2 pura sem roteamento e ponte integrados

A Figura 2 mostra que o chassi que se conecta ao PIM-DR é o roteador ativo principal (P-A) e o outro é o roteador ativo secundário (S-A).

Figura 2: Configuração de Camada 2 sem roteamento e ponte integrados

Aprendizado qualificado

Nesta topologia, as interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 e I10 são interfaces de casa única. Os enlaces multichassis ae0.0 e ae0.1 pertencem ao mesmo domínio de ponte em ambos os chassis. Interfaces I10, I1,I7, I3,I5, ae0.0 e ae0.1 estão no mesmo domínio da ponte, bd1 em P-A. As interfaces I9, I2, I8, I4, I6, ae0.0 e ae0.1 estão no mesmo domínio da ponte, bd1 em S-A.

Esta discussão assume a seguinte configuração:

• Em P-A e S-A, o aprendizado qualificado é ON no bd1.

• As interfaces I1, I2, I3, ae0.0 e I4 pertencem ao vlan1, domínio de aprendizado ld1.

• As interfaces I7, I8, I5, ae0.1 e I6 pertencem ao vlan2, domínio de aprendizado ld2.

• As interfaces I9 e I10 pertencem ao vlan3, domínio de aprendizado ld3.

Para os alto-falantes IGMP (hosts e roteadores) no mesmo domínio de aprendizado ld1, P-A e S-A vinculados devem parecer ser um switch.

Para os alto-falantes IGMP (hosts e roteadores) no mesmo domínio de aprendizado ld2, P-A e S-A vinculados devem parecer ser um switch.

Como não existem links multichassis no domínio de aprendizado ld3, para os alto-falantes IGMP (hosts e roteadores) no domínio de aprendizado ld3, P-A e S-A não parecerão ser um único switch.

Essa discussão pressupõe que o enlace interchassis ICL1 corresponda ao domínio de aprendizado ld1 e o enlace de interchasse ICL2 corresponde ao domínio de aprendizado ld2.

O fluxo de pacotes de controle é suportado, com exceção da passagem de informações para a IRB.

Encaminhamento de dados com aprendizado qualificado

Essa discussão assume um domínio de aprendizado (LD), ld1 e assume ainda que a interface I1 no Roteador P-A está conectada ao PIM-DR no domínio de aprendizado e puxa o tráfego de fontes no núcleo.

Para fornecer tráfego a hosts conectados ao Roteador S-A (que não é o DR) no enlace único como I2, I4 (pertencente à ld1), contamos com o ICL1. O tráfego que atinge o P-A do roteador na interface I1 é enviado pelo enlace interchassis ICL1 para o Roteador S-A a ser entregue aos links que relataram interesses em s,g ou nos enlaces que estão voltados para o roteador no domínio de aprendizado ld1.

Quando a interface ae0 leg no Roteador P-A diminui, os hosts conectados ao enlace multichassis recebem tráfego da interface I1 usando o enlace de interchasse ICL1. No Roteador S-A, o tráfego recebido no enlace interchassis ICL1 é enviado para links multichassis na lista de interface de saída para a qual a contrapartida Ethernet agregada no Roteador P-A está baixa.

Presume-se ainda que a interface I9 no Roteador S-A pertence ao domínio de aprendizado ld3 com interesses em s,g, e essa interface I10 no domínio de aprendizado ld3 no roteador P-A recebe tráfego para s,g. Interface I9 não recebe dados nesta topologia porque não há links de multichassis (em um modo) e, portanto, nenhum link de interchasse no domínio de aprendizado ld3.

Grupos estáticos em interfaces single-homed

Para links multichassis, a configuração de grupo estático deve existir em ambas as pernas, e a sincronização com o outro chassi não é necessária.

A sincronização dos grupos estáticos em interfaces de casa única entre o chassi não é suportada. No entanto, a adição de interfaces lógicas à lista de interfaces de saída padrão oferece suporte à entrega de tráfego à interface dentro de uma configuração estática.

Interfaces voltadas para roteadores como links multichassis

As consultas de IGMP podem chegar em qualquer etapa dos enlaces multichassis, mas em ambos os pares, o enlace multichassis deve ser considerado como voltado para o roteador.

Os relatórios devem sair apenas uma vez do enlace multichassis, ou seja, de apenas uma perna.

O seguinte suporte MC-LAG para bisbilhotar IGMP no IRB é fornecido:

• Bisbilhotamento sem proxy

• Interfaces lógicas devem ser interfaces de saída para todas as rotas, incluindo a rota padrão

• IGMP bisbilhotando um switch de Camada 2 puro

• IGMP bisbilhotando domínios de ponte fazendo aprendizado qualificado

• MC-Links de interface voltada para roteador

Os recursos a seguir são not suportados:

• Modo proxy para ativo-ativo

• Suporte a MC-LAG para instâncias VPLS

• Portas de tronco como links multichassis

• Adicionando interfaces lógicas às interfaces de saída conforme necessário.

  No entanto, interfaces lógicas são sempre adicionadas como uma interface voltada para roteadores à lista de interfaces de saída.

Topologia MC-LAG suportada

Para oferecer suporte ao transporte sem perdas de tráfego FCoE em um MC-LAG, você deve configurar a classe de serviço (CoS) apropriada em ambos os switches com membros da porta MC-LAG. A configuração de CoS deve ser a mesma em ambos os switches MC-LAG, porque os MC-LAGs não transportam a classe de encaminhamento e as informações de prioridade do IEEE 802.1p.

Switches que não estão diretamente conectados aos hosts FCoE e que atuam como switches de trânsito de passagem oferecem suporte a MC-LAGs para tráfego FCoE em uma topologia de rede invertida de U . A Figura 3 mostra uma topologia de U invertida usando switches QFX3500.

Figura 3: Topologia suportada para um MC-LAG em um switch de trânsito FCoE

Switches autônomos oferecem suporte a MC-LAGs. Os dispositivos de nó do sistema QFabric não oferecem suporte a MC-LAGs. As configurações de Virtual Chassis e Virtual Chassis Fabric (VCF) de modo misto não oferecem suporte a FCoE. Apenas VCFs QFX5100 puros (compostos apenas por switches QFX5100) oferecem suporte a FCoE.

As portas que fazem parte de uma configuração de gateway FCoE-FC (uma malha de gateway FCoE-FC virtual) não oferecem suporte a MC-LAGs. As portas que são membros de um MC-LAG atuam como portas de switch de trânsito de passagem.

As seguintes regras e diretrizes se aplicam aos MC-LAGs quando usados para tráfego FCoE. As regras e diretrizes ajudam a garantir o manuseio adequado e as características de transporte sem perdas necessárias para o tráfego FCoE.

• Os dois switches que formam o MC-LAG (switches S1 e S2) não podem usar portas que fazem parte de uma malha de gateway FCoE-FC. As portas do switch MC-LAG devem ser portas de switch de trânsito de passagem (usadas como parte de um switch de trânsito intermediário que não está diretamente conectado aos hosts FCoE).

• Os switches MC-LAG S1 e S2 não podem ser conectados diretamente aos hosts FCoE.

• Os dois switches que servem como dispositivos de acesso para hosts FCoE (FCoE Transit Switches TS1 e TS2) usam LAGs padrão para se conectar aos switches MC-LAG S1 e S2. Os switches FCoE Transit TS1 e TS2 podem ser switches autônomos ou podem ser dispositivos de nó em um sistema QFabric.

• Os switches de trânsito TS1 e TS2 devem usar portas de switch de trânsito para os hosts FCoE e para os LAGs padrão para os switches MC-LAG S1 e S2.

• Habilite a espionagem fip sobre o FCoE VLAN nos switches de trânsito TS1 e TS2. Você pode configurar VN_Port para VF_Port (VN2VF_Port) bisbilhotamento fip ou VN_Port para VN_Port (VN2VN_Port) bisbilhotamento FIP, dependendo se os hosts FCoE precisam acessar alvos no FC SAN (VN2VF_Port bisbilhotamento FIP) ou alvos na rede Ethernet (VN2VN_Port espionagem FIP).

  A espionagem FIP deve ser realizada na borda de acesso e não é suportada em switches MC-LAG. Não habilite a bisbilhotagem FIP nos switches MC-LAG S1 e S2. (Não habilite a espionagem FIP nas portas MC-LAG que conectam switches S1 e S2 aos switches TS1 e TS2 ou nas portas LAG que conectam Switch S1 a S2.)

  Nota:

  Os switches de agregação QFX10000 da Juniper Networks não oferecem suporte à espionagem FIP, portanto, eles não podem ser usados como switches de acesso de espionagem FIP (Switches de trânsito TS1 e TS2) nesta topologia.

• A configuração de CoS deve ser consistente nos switches MC-LAG. Como os MC-LAGs não têm informações de classe de encaminhamento ou prioridade, cada switch MC-LAG precisa ter a mesma configuração de CoS para oferecer suporte a transporte sem perdas. (Em cada switch MC-LAG, o nome, a fila de saída e o provisionamento de CoS de cada classe de encaminhamento devem ser os mesmos, e a configuração de controle de fluxo baseado em prioridade (PFC) deve ser a mesma.)

• Switches de trânsito (acesso ao servidor)
• Switches MC-LAG (agregação de FCoE)

Portas confiáveis para FIP Snooping e FCoE

Para manter um acesso seguro, habilite VN2VF_Port FIP ou VN2VN_Port FIP bisbilhotando as portas de acesso do switch de trânsito conectadas diretamente aos hosts FCoE. A espionagem FIP deve ser realizada na borda de acesso da rede para evitar acesso não autorizado. Por exemplo, na Figura 3, você habilita a fip a bisbilhotar as VLANs FCoE nos switches de trânsito TS1 e TS2 que incluem as portas de acesso conectadas aos hosts FCoE.

Não habilite a bisbilhotagem FIP nos switches usados para criar o MC-LAG. Por exemplo, na Figura 3, você não habilitaria a FIP a bisbilhotar as VLANs FCoE nos switches S1 e S2.

Configure links entre switches como portas confiáveis do FCoE para reduzir a sobrecarga de bisbilhotamento FIP e garantir que o sistema realize espionagem FIP apenas na borda de acesso. Na topologia da amostra, configure as portas DE LAG do switch de trânsito TS1 e TS2 conectadas aos switches MC-LAG como portas confiáveis do FCoE, configure as portas S1 e S2 MC-LAG conectadas aos switches TS1 e TS2 como portas confiáveis do FCoE e configure as portas no LAG que conecta switches S1 a S2 como portas confiáveis FCoE.

Ponte de cos e data center (DCB)

Os links MC-LAG não transportam informações de classe ou prioridade de encaminhamento. As propriedades cos a seguir devem ter a mesma configuração em cada switch MC-LAG ou em cada interface MC-LAG para oferecer suporte a transporte sem perdas:

• Nome da classe de encaminhamento FCoE — Por exemplo, a classe de encaminhamento para tráfego FCoE poderia usar a classe de encaminhamento padrão fcoe em ambos os switches MC-LAG.

• Fila de saída de FCoE — por exemplo, a fcoe classe de encaminhamento pode ser mapeada para a fila 3 em ambos os switches MC-LAG (a fila 3 é o mapeamento padrão para a fcoe classe de encaminhamento).

• Classificador — A classe de encaminhamento para tráfego FCoE deve ser mapeada para o mesmo ponto de código IEEE 802.1p em cada interface de membro do MC-LAG em ambos os switches MC-LAG. Por exemplo, a classe fcoe de encaminhamento FCoE pode ser mapeada para o ponto 011 de código IEEE 802.1p (o ponto 011 de código é o mapeamento padrão para a fcoe classe de encaminhamento).

• Controle de fluxo baseado em prioridade (PFC)— o PFC deve ser habilitado no ponto de código FCoE em cada switch MC-LAG e aplicado a cada interface MC-LAG usando um perfil de notificação de congestionamento.

Você também deve configurar a seleção aprimorada de transmissão (ETS) nas interfaces MC-LAG para fornecer recursos de agendamento suficientes (largura de banda, prioridade) para transporte sem perdas. A configuração de ETS pode ser diferente em cada switch MC-LAG, desde que sejam programados recursos suficientes para oferecer suporte ao transporte sem perdas para o tráfego FCoE esperado.

O protocolo de descoberta de camadas de enlace (LLDP) e o protocolo de troca de recursos de ponte de data center (DCBX) devem ser habilitados em cada interface de membro MC-LAG (LLDP e DCBX são habilitados por padrão em todas as interfaces).

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 4 e Figura 5, 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 2 descreve os problemas que surgem e como a Juniper Networks resolve os problemas na implementação do recurso de intertrabalho EVPN-MPLS.

Horizonte dividido

Nos casos de uso mostrados na Figura 4 e na Figura 5, 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 3 explica o problema e como a Juniper Networks o resolve na implementação do recurso de intertrabalho EVPN-MPLS.

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 4 descreve o problema e como a implementação de intertrabalho EVPN-MPLS impede o problema. Os casos de uso mostrados na Figura 4 e na Figura 5 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.

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

No Junos Fusion Enterprise mostrado na Figura 4, 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.

Benefícios dos gateways Anycast

• Com os dois dispositivos juniper networks multihomed atuando como gateways anycast em uma rede EVPN-MPLS ou MC-LAG, um host na mesma rede que gera pacotes de Camada 3 com destinos em outras redes agora pode enviar os pacotes para o gateway anycast local. Após o recebimento desses pacotes de Camada 3, o gateway anycast roteia os pacotes na rede principal com base na busca por IP de destino.

Diretrizes de configuração de gateway anycast

• Em geral, ao configurar endereços para um gateway anycast:

  • Para endereços IPv4 ou IPv6, você pode especificar qualquer sub-rede.

  • Para endereços MAC, você pode usar o endereço MAC que o dispositivo Juniper Networks gera automaticamente (MAC do chassi) ou configurar explicitamente um endereço MAC usando o CLI.

  • Seu esquema de sub-rede de endereço IP determinará se você usa a sintaxe de comando de interface IRB ou a sintaxe de comando VGA para configurar seu gateway anycast.

Para configurar seus dispositivos multihomed como quaisquer gatewayscast, fornecemos as seguintes diretrizes de configuração:

• Diretriz 1 — Se o endereço IP para gateways anycast estiver na sub-rede /30 ou /31 (para IPv4) ou /126 ou /127 (para IPv6):

  • Você deve configurar o mesmo endereço IP para a interface IRB em cada um dos dispositivos multihomed usando um dos seguintes comandos.

  • Você deve configurar explicitamente o endereço MAC usando o seguinte comando:

  • Você não deve configurar um VGA (endereços IP e MAC).

• Diretriz 2 — Se o endereço IP para gateways decast for uma sub-rede diferente de /30, /31, /126 ou /127, então um VGA pode ser configurado:

  • Você deve configurar o mesmo endereço IP para o VGA em cada um dos dispositivos multihomed usando um dos seguintes comandos.

  • Você deve configurar explicitamente o endereço MAC usando um dos seguintes comandos:

  • Ao especificar um endereço MAC para o VGA, não recomendamos usar o mesmo endereço MAC usado para VRRP.

Limitações de configuração de gateway anycast

Ao configurar o gateway anycast usando diretrizes descritas anteriormente neste tópico, tenha em mente o seguinte:

• Em geral, não recomendamos o uso de um endereço MAC VRRP como endereço MAC para uma interface IRB. No entanto, se você precisa fazer isso, como é a prática geral ao configurar VRRP em dispositivos Juniper Networks, você deve usar um endereço MAC VRRP IPv4 para a família IPv4 e um endereço MAC VRRP IPv6 para a família IPv6.

  Dado esses parâmetros, a única diretriz de configuração com a qual essa limitação funcionará é a diretriz de configuração 2.

• Ao configurar quaisquer endereços de gatewaycast usando a diretriz 1 em um ambiente EVPN-MPLS, você também deve especificar as default-gateway do-not-advertise declarações de configuração em uma instância de roteamento. Por exemplo:

• Em um ambiente EVPN-MPLS, se seus endereços IP de gateway anycast estiverem em sub-redes diferentes e você especificar os endereços em várias instâncias de roteamento:

  • Se você configurou um endereço IP de gateway decast usando a diretriz de configuração 1 em uma instância de roteamento e outro endereço IP de gateway anycast usando a diretriz de configuração 2 em uma instância de roteamento diferente, você também deve especificar as default-gateway no-gateway-community declarações de configuração dentro da instância de roteamento:

    Essa configuração adicional se aplica apenas à instância de roteamento que inclui quaisquer endereços IP de gatewaycast configurados usando a diretriz 1.

  • Para cada instância de roteamento em que você especificou o endereço IP de gateway anycast usando a diretriz de configuração 1, recomendamos especificar um único endereço MAC não-VRRP.

• A geração de ESI automática é habilitada por padrão em dispositivos com multihoming EVPN para redundância de gateway virtual. Recomendamos que você desabiide a geração de ESI automática para redes EVPN-VXLAN com overlays de ponte com roteamento de borda (ERB). Nesse caso, você pode incluir a no-auto-virtual-gateway-esi declaração no nível de [edit interfaces irb unit logical-unit-number] hierarquia.

  A partir do Junos OS Release 22.1R1, MX960, MX2020 e MX10008 roteadores também permitem a geração automática de ESI por padrão para ESIs de interface IRB de gateway EVPN Camada 3. No entanto, a no-auto-virtual-gateway-esi declaração não é suportada com redes EVPN-MPLS. Como resultado, você sempre verá ESIs geradas automaticamente para interfaces IRB neste caso.

• Em um ambiente EVPN-VXLAN com multihoming, você pode usar várias instâncias de roteamento EVPN em dispositivos de borda de provedores de peer (PE) que compartilham um segmento de Ethernet (ES). Quando você configura quaisquer gatewayscast com a default-gateway declaração, não oferecemos suporte para misturar o comportamento padrão (opção de anúncio) com a opção de comunidade sem gateway nos links que participam do mesmo ES.

  Como resultado, se você configurar a default-gateway declaração com a opção no-gateway-community em quaisquer instâncias de roteamento EVPN em qualquer dispositivo de PE peer que compartilhe um ES, você deve configurar esta declaração:

  • Em todas as instâncias de roteamento que compartilham o ES em um dispositivo PE,

  • Em todos os dispositivos peer PE que compartilham o ES

  • Somente com a opção no-gateway-community ou a do-not-advertise.

  Você não pode omitir a configuração da declaração de gateway padrão ou incluir a declaração com a opção de anúncio em qualquer instância de roteamento em qualquer dispositivo peer PE.

• Temos suporte para definir um endereço IP de gateway anycast em interfaces IRB em dispositivos ACX5448. No entanto, para interfaces IRB com /30 ou /31 endereços IP em conexões entre interfaces de dispositivos PE e customer edge (CE), o dispositivo CE não tem espaço de pool suficiente para a alocação de endereço IP da sessão BGP. Como resultado, não oferecemos suporte a BGP com interface IRB/30 e /31 endereços IP anycast.