Conceitos avançados de MC-LAG

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

A sincronização de configuração permite propagar, sincronizar e confirmar 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ções

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 os 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 [edit system commit] instrução na hierarquia para sincronizar as configurações e confirmações entre os dispositivos por padrão. O NETCONF sobre 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 de aplicação.

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 instrução ou emita o commit peers-synchronize comando para sincronizar e confirmar as configurações entre dispositivos locais e remotos.

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

É possível 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 remoto é usado pelo dispositivo remoto e um grupo de configuração global é compartilhado entre os dispositivos locais e remotos.

Por exemplo, você pode 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 remoto 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 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 da [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), poderá 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 instrução no nível da [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), emita o set apply-groups [ GroupA GroupB GroupC ] comando.

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

Para sincronizar as 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> [edit system commit] comando na hierarquia no dispositivo local.

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

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

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

Interruptor A

Se você deseja sincronizar apenas as configurações do Switch A para o Switch B, Switch C e Switch D, não é necessário configurar a peers declaração no Switch B, Switch C e Switch D.

Os detalhes de configuração das peers declarações também são usados para estabelecer uma conexão NETCONF sobre 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 confirmações são sincronizadas entre dispositivos

O dispositivo local (ou solicitante) no qual você habilita a peers-synchronize instrução ou emite o commit peers-synchronize comando copia e carrega sua configuração para o dispositivo remoto (ou de resposta). Em seguida, cada dispositivo executa uma verificação de sintaxe no arquivo de configuração que está sendo confirmado. Se nenhum erro for encontrado, a configuração será ativada e se tornará a configuração operacional atual em todos os dispositivos. Os commits são propagados usando uma chamada de procedimento remota (RPC).

Os seguintes eventos ocorrem durante a sincronização de 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 a confirmação foi concluída.

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

4. Se for bem-sucedida, a configuração será confirmada.

A sincronização de configuração não será bem-sucedida se a) o dispositivo remoto estiver indisponível ou b) o dispositivo remoto estiver acessível, mas houver falhas devido aos seguintes motivos:

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

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

• O carregamento da configuração falha devido a 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 instruçã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 deseja sincronizar a configuração com o dispositivo remoto, basta emitir o commit comando no dispositivo local. No entanto, se você emitir o commit comando no dispositivo local e o dispositivo remoto não estiver acessível, você receberá uma mensagem de aviso informando que o dispositivo remoto não está acessível e apenas a configuração no dispositivo local está confirmada:

Aqui está um exemplo de mensagem de aviso:

Se você não tiver a peers declaração configurada com as informações do dispositivo remoto e emitir o commit comando, somente a configuração no dispositivo local será confirmada. Se o dispositivo remoto estiver inacessível e houver outras falhas, a confirmação não será bem-sucedida nos dispositivos local e remoto.

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 estiver acessível, mas houver outras falhas, a confirmação falhará nos dispositivos local e remoto.

Benefícios de usar a verificação de consistência MC-LAG

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

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

Os seguintes eventos ocorrem durante a verificação de consistência de configuração depois que você emite um commit no peer MC-LAG local:

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

2. O ICCP analisa a configuração do MC-LAG e, em seguida, 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 inconsistência grave entre as duas configurações do MC-LAG, a interface MC-LAG será desativada e mensagens de syslog serão emitidas.

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

Os seguintes eventos ocorrem durante a verificação de consistência de configuração depois que você emite uma confirmação no peer MC-LAG remoto:

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

• O ICCP analisa a configuração do MC-LAG e, em seguida, 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 inconsistência grave entre as duas configurações, a interface MC-LAG será desativada e mensagens de syslog serão emitidas.

  Se houver uma inconsistência moderada entre as duas configurações, as mensagens 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 exclusivos, o que significa que alguns parâmetros devem ser configurados de forma idêntica e outros 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 imposição dos requisitos de consistência (idênticos ou exclusivos) é obrigatório ou desejado. Quando o nível de imposição é obrigatório e você configura o parâmetro MC-LAG incorretamente, o sistema desativa a interface e emite uma mensagem de syslog.

Por exemplo, você recebe uma mensagem 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 commit bem-sucedido, o sistema abrirá a interface. Quando a imposição é desejada e você configura o parâmetro MC-LAG incorretamente, 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. This may lead to sub-optimal performance of the feature." Conforme observado na mensagem de syslog, o desempenho será abaixo do ideal nessa situação. Você também pode emitir o show interfaces mc-ae comando 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 será mostrada. Se o nível de imposição de um parâmetro MC-LAG for obrigatório e você não configurou esse parâmetro corretamente, o comando mostrará que a interface MC-LAG está inativa.

Quando os pares remotos não estão acessíveis

Quando você emite uma confirmação no peer local e o peer remoto não está acessível, a verificação de consistência de configuração será aprovada para que o peer local possa aparecer no modo autônomo. Quando o peer remoto é ativado, o ICCP troca as configurações entre os peers. Se a verificação de consistência falhar, a interface MC-LAG ficará inativa e o sistema notificará você sobre o parâmetro que causou a inconsistência. Quando você corrige a inconsistência e emite um commit bem-sucedido, o sistema ativa a interface.

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

A verificação de consistência é habilitada por padrão. A Tabela 1 fornece uma lista de amostra de parâmetros MC-LAG confirmados que são verificados quanto à consistência, juntamente com seus requisitos de consistência (idênticos ou exclusivos), hierarquias nas quais os parâmetros são configurados e os níveis de imposiçã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 verificação de consistência de configuração:

• Emita o show multi-chassis mc-lag configuration-consistency list-of-parameters comando para visualizar a lista de parâmetros MC-LAG confirmados que são verificados quanto a inconsistências, o requisito de consistência (idêntico ou exclusivo) e o nível de aplicação (obrigatório ou desejado).

• Emita o show multi-chassis mc-lag configuration-consistency comando para visualizar a lista de parâmetros MC-LAG comprometidos que são verificados quanto a inconsistências, o requisito de consistência (idêntico ou exclusivo), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show multi-chassis mc-lag configuration-consistency global-config comando para visualizar 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 exclusivo), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show multi-chassis mc-lag configuration-consistency icl-config comando para visualizar o status da verificação de consistência de configuração para parâmetros relacionados ao enlace de controle do interchassis, 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 de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show multi-chassis mc-lag configuration-consistency mcae-config comando para visualizar 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 exclusivo), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show multi-chassis mc-lag configuration-consistency vlan-config comando para visualizar o status de verificação de consistência de configuração para parâmetros relacionados à configuração de VLAN, o requisito de consistência (idêntico ou exclusivo), o nível de aplicação (obrigatório ou desejado) e o resultado da verificação de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show multi-chassis mc-lag configuration-consistency vrrp-config comando para visualizar o status da verificação de consistência de configuração para parâmetros relacionados à configuração do 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 de consistência de configuração. Os resultados são aprovação ou reprovação.

• Emita o show interfaces mc-ae comando 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 será mostrada. Se o nível de imposição do parâmetro MC-LAG for obrigatório e você não configurou esse parâmetro corretamente, o comando mostrará que a interface MC-LAG está inativa.

Operação PIM com eleição de roteador designado de modo normal

No modo normal com a eleição do roteador designado, as interfaces IRB ou RVI em ambos os pares MC-LAG são configuradas com o PIM habilitado. Nesse modo, um dos pares MC-LAG se torna o roteador designado por meio do mecanismo de eleição do roteador designado pelo PIM. O roteador designado eleito mantém a árvore de pontos 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 junção e remoção de PIM em direção ao ponto de encontro ou à origem.

O gatilho para iniciar essas atividades de junção e remoção são os relatórios de associação IGMP recebidos dos receptores interessados. Os relatórios IGMP recebidos por interfaces Ethernet agregadas multichassis (potencialmente hashing em qualquer um dos pares MC-LAG) e links single-homed 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 atua como uma interface de roteador multicast (mrouter).

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

Operação PIM com o modo de roteador designado duplo

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

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

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

Para habilitar um roteador designado duplo 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 designada mais alta. Isso garante que o peer MC-LAG primário retenha a associação de roteador designada se o peering PIM cair.

Para garantir que o tráfego converja se uma interface MC-AE ficar inativa, a interface ICL-PL é sempre adicionada como uma porta mrouter. O tráfego da Camada 3 é inundado através da entrada padrão ou da 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 vizinhança PIM cairá. Nesse caso, ambos os pares MC-LAG se tornam o roteador designado. O peer MC-LAG de backup derruba seus links e o peering de roteamento é perdido. Se a conexão ICCP cair, o peer MC-LAG de backup altera o ID do sistema LACP e derruba as interfaces MC-AE. O estado dos vizinhos do PIM permanece operacional.

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

O modo ativo-ativo do grupo de agregação de enlace multichassis (MC-LAG) e a bisbilhotagem de IGMP no modo de espera ativo 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 no nível de nó, multihoming e uma rede de Camada 2 sem loop sem executar o Spanning Tree Protocol (STP). Os seguintes recursos são suportados:

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

• Aprendizagem qualificada

• Links multichassis voltados para o roteador

Os seguintes aprimoramentos na ponte ativo-ativo e no protocolo de redundância de roteador virtual (VRRP) sobre roteamento e ponte integrados (IRB) são suportados:

• Suporte a MC-LAG para bisbilhotamento de IGMP em um switch de Camada 2 puro

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

• Suporte para MC-Links sendo interfaces voltadas para o roteador

As seguintes funções são not suportadas:

• MC-LAG para instâncias VPLS

• Portas de tronco MC-Links

• Modo proxy para ativo-ativo

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

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

Topologia de rede normalmente suportada para IGMP Snooping com MC-LAG Active-Active Bridging

A Figura 1 mostra uma topologia de rede típica na qual a espionagem IGMP com a ponte ativa-ativa MC-LAG é suportada.

Figura 1: Rede típica na qual o ativo-ativo é suportado

As interfaces I3 e I4 são interfaces single-homed. Os links multichassis ae0.0 e ae0.1 pertencem ao mesmo domínio de bridge em ambos os chassis. As interfaces I3, ae0.0 e ae0.1 estão no mesmo domínio de bridge no roteador secundário ativo (S-A). As interfaces I4, ae0.0 e ae0.1 estão no mesmo domínio de bridge 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 primário é o chassi no qual o roteamento e a ponte integrados se tornaram PIM-DR. O roteador ativo secundário é o chassi no qual o roteamento e a ponte integrados não são PIM-DR. O roteador P-A é o chassi responsável por puxar o tráfego do núcleo de IP. Portanto, a eleição de PIM-DR é usada para evitar a duplicação do tráfego de dados.

Os domínios de aprendizagem são descritos em Aprendizagem qualificada.

Para os alto-falantes IGMP (hosts e roteadores) no domínio de aprendizagem, PA e SA juntos devem aparecer como um 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 no 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 associação no roteamento multicast de Camada 3 é atualizado como resultado de relatórios aprendidos em trechos remotos de links multichassis e S-links anexados ao chassi remoto.

• O estado de associação e a entrada de roteamento na espionagem são atualizados quando os relatórios são recebidos nos trechos remotos de um enlace multichassis.

Encaminhamento de dados

Esta discussão pressupõe que o roteamento e a ponte integrados no Roteador P-A sejam o PIM-DR. Ele extrai 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á alteração na forma como os dados são entregues.

Para entregar tráfego a hosts conectados ao S-A (que é o não-DR) no link single-homed como o I3, contamos com o link interchassis. O tráfego que atinge P-A é enviado pela ICL para S-A para ser entregue aos links que relataram interesses em s,g e aos links voltados para o roteador.

Quando o trecho ae0 no P-A cai, os hosts conectados ao enlace multichassis recebem tráfego pela ICL. No S-A, o tráfego recebido na ICL é enviado para links multichassis na lista de interface de saída para os quais a contraparte ae no P-A está inativa.

Topologia de Camada 2 pura sem roteamento e pontes integrados

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

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

Aprendizagem Qualificada

Nessa topologia, as interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 e I10 são interfaces single-homed. Os links multichassis ae0.0 e ae0.1 pertencem ao mesmo domínio de bridge em ambos os chassis. As interfaces I10, I1, I7, I3, I5, ae0.0 e ae0.1 estão no mesmo domínio de bridge, bd1 em PA. As interfaces I9, I2, I8, I4, I6, ae0.0 e ae0.1 estão no mesmo domínio de bridge, bd1 em S-A.

Esta discussão pressupõe a seguinte configuração:

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

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

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

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

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

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

Como não há links multichassis no domínio de aprendizado ld3, para os alto-falantes IGMP (hosts e roteadores) no domínio de aprendizado ld3, PA e SA não parecerão ser um switch.

Esta discussão pressupõe que o link de interchassis ICL1 corresponde ao domínio de aprendizado ld1 e o link de interchassis ICL2 corresponde ao domínio de aprendizado ld2.

Há suporte para o fluxo de pacotes de controle, com exceção da passagem de informações para o IRB.

Encaminhamento de dados com aprendizado qualificado

Esta discussão pressupõe um domínio de aprendizado (LD), ld1, e pressupõe 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 entregar tráfego a hosts conectados ao Roteador S-A (que é o não-DR) no link single-homed como I2, I4 (pertencente a ld1), contamos com ICL1. O tráfego que atinge o Roteador P-A na interface I1 é enviado pelo enlace ICL1 do interchassis para o Roteador S-A para ser entregue aos enlaces que relataram interesses em s,g ou aos enlaces voltados para o roteador no domínio de aprendizado ld1.

Quando a interface ae0 leg no Roteador P-A cai, os hosts conectados ao enlace multichassis recebem tráfego da interface I1 usando o enlace interchassis ICL1. No Roteador S-A, o tráfego recebido no enlace ICL1 do interchassis é enviado para enlaces multichassis na lista de interfaces de saída para os quais a contraparte Ethernet agregada no Roteador P-A está inativa.

Supõe-se ainda que a interface I9 no Roteador S-A pertence ao domínio de aprendizado ld3 com interesses em s,g, e que a interface I10 no domínio de aprendizado ld3 no Roteador P-A recebe tráfego para s,g. A interface I9 não recebe dados nesta topologia porque não há links multichassis (no modo a-a) e, portanto, nenhum link de interchassis 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 single-homed 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 para a interface em uma configuração estática.

Interfaces voltadas para roteadores como links multichassis

As consultas IGMP podem chegar em qualquer trecho dos links multichassis, mas em ambos os pares, o enlace multichassis deve ser considerado voltado para o roteador.

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

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

• Bisbilhotamento não proxy

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

• IGMP bisbilhotando em um switch de Camada 2 puro

• IGMP bisbilhotando em domínios de ponte fazendo aprendizado qualificado

• Interface voltada para o roteador MC-Links

Os seguintes recursos são not suportados:

• Modo proxy para ativo-ativo

• Suporte a MC-LAG para instâncias VPLS

• Portas de tronco como links multichassis

• Adição de interfaces lógicas a interfaces de saída conforme a necessidade.

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

Topologia MC-LAG suportada

Para oferecer suporte ao transporte sem perdas do tráfego FCoE através de um MC-LAG, você deve configurar a classe de serviço (CoS) apropriada em ambos os switches com membros de 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 informações de classe de encaminhamento e prioridade IEEE 802.1p.

Switches que não estão diretamente conectados a 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 com U invertido . A Figura 3 mostra uma topologia em U invertido usando switches QFX3500.

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

Os switches autônomos oferecem suporte a MC-LAGs. As configurações do Virtual Chassis Fabric (VCF) e do modo misto do Virtual Chassis Fabric não oferecem suporte ao FCoE. Somente VCFs QFX5100 puros (consistindo apenas em switches QFX5100) suportam FCoE.

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

As regras e diretrizes a seguir 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 a 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. FCoE Transit Switches TS1 e TS2 podem ser switches autônomos.

• 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 bisbilhotagem de FIP na VLAN FCoE 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 na SAN FC (VN2VF_Port bisbilhotamento FIP) ou alvos na rede Ethernet (VN2VN_Port bisbilhotamento FIP).

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

  Observação:

  Os switches QFX10000 não oferecem suporte a bisbilhotamento FIP; portanto, eles não podem ser usados como switches de acesso de espionagem FIP (Transit Switches TS1 e TS2) nesta topologia.

• A configuração de CoS deve ser consistente nos switches MC-LAG. Como os MC-LAGs não carregam nenhuma classe de encaminhamento ou informações de prioridade, cada switch MC-LAG precisa ter a mesma configuração de CoS para oferecer suporte ao 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 FCoE)

Portas confiáveis de FIP Snooping e FCoE

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

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

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

CoS e pontes de data center (DCB)

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

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

• Fila de saída FCoE — Por exemplo, a classe de encaminhamento pode ser mapeada para a fcoe 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 o 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 de transmissão aprimorada (ETS) nas interfaces MC-LAG para fornecer recursos de agendamento suficientes (largura de banda, prioridade) para transporte sem perdas. A configuração do ETS pode ser diferente em cada switch MC-LAG, desde que recursos suficientes estejam programados para oferecer suporte ao transporte sem perdas para o tráfego FCoE esperado.

O Link Layer Discovery Protocol (LLDP) e o Data Center Bridging Capability Exchange Protocol (DCBX) devem ser habilitados em cada interface de membro do MC-LAG (LLDP e DCBX são habilitados por padrão em todas as interfaces).

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

Horizonte dividido

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

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 4 descreve o problema e como a implementação de interfuncionamento EVPN-MPLS evita 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 EVPN, e PE2 e PE3 são pares MC-LAG.

Como lidar com o enlace descendente entre portas em cascata e uplink no Junos Fusion Enterprise

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

Comportamento de MC-LAG específico da plataforma