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 os dispositivos remotos e outro para a configuração global, que é essencialmente uma configuração que é 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 sobre SSH oferece 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 permitir a sincronização da 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 determinada configuração 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 [edit groups] nível hierárquicos. 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.

Aplicação de 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 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> comando na [edit system commit] hierarquia do 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, o problema 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:

Switch A

Se você quiser sincronizar apenas as configurações do Switch A para o 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 uma 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 os compromissos são sincronizados entre dispositivos

O dispositivo local (ou solicitação) no qual você habilita a peers-synchronize declaração ou emite as commit peers-synchronize cópias de comando e carrega sua configuração para o dispositivo remoto (ou resposta). Cada dispositivo então realiza 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 suas configurações para o dispositivo local e respondem que o compromisso está completo.

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

4. Se for bem-sucedida, a configuração será 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 há falhas devido aos seguintes motivos:

• A conexão SSH falha devido a 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.

• 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 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 de usar a verificação de consistência do MC-LAG

• Esse recurso ajuda você a encontrar inconsistências no parâmetro 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 de 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 depois 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 o compara com sua própria configuração MC-LAG.

   Se houver uma inconsistência severa 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 de 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 depois 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 o 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 serão 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 forma idêntica e alguns devem ser configurados exclusivamente nos pares MC-LAG. Por exemplo, a ID do chassi deve ser única 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 que, “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 do syslog, o desempenho será abaixo do ideal nesta 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 de 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 peers remotos não podem ser alcançados

Quando você emite um compromisso no peer local, e o peer remoto não é acessível, a verificação de consistência de configuração será aprovada 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 cairá e o sistema notifica você sobre o parâmetro que causou a inconsistência. Quando você corrige a inconsistência e emite um confirmação bem-sucedido, o sistema traz a interface.

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

A verificação de consistência é habilitada por padrão. A Tabela 1 fornece uma lista de exemplos de parâmetros MC-LAG comprometidos que são verificados para 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 verificação da consistência da configuração:

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

• Emita 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 reprovados.

• Emita o comando de configuração global mc-lag de multi-chassi para visualizar o status de verificação da consistência da 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 reprovados.

• Emita o comando de configuração icl-config de multi-chassi para exibir 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 reprovados.

• Emita o comando mcae-config de consistência de configuração mc-lag multi-chassi para visualizar o status de verificação da consistência da configuração para parâmetros relacionados à interface de 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 reprovados.

• Emita o comando vlan-config de consistência de configuração mc-lag multi-chassi para visualizar 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 reprovados.

• Emita o comando vrrp-config de consistência de configuração mc-lag multi-chassi para visualizar 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 reprovados.

• Emita as interfaces de exibição do comando mc-ae para visualizar o status de verificação de consistência da interface Ethernet agregada por 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 da consistência da configuração do 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 com o Junos OS Release 15.1X53-D60 em 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 pares MC-LAG.

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

No modo normal, com a eleição de roteador designado, 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 associação de 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 de roteador designado duplo

No modo de roteador designado duplo, ambos os pares MC-LAG atuam como roteadores designados (ativos e em espera) e enviam mensagens periódicas de junção e podamento upstream em direção ao ponto de encontro, ou fonte, e eventualmente se juntam 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 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 (OIL) vazia. Quando o peer MC-LAG de espera detecta a falha principal de peer-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.

Manuseio de falhas

Para garantir uma convergência mais rápida durante falhas, configure o endereço IP no peer MC-LAG primário com um endereço IP mais alto ou com uma prioridade de roteador designada mais alta. Fazer isso garante que o peer MC-LAG primário mantenha a associação de roteador designado 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 é inundado 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 vizinhança do PIM cairá. Neste 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 permanece operacional.

Funcionalidade de modo ativo ativo do IGMP Snooping no MC-LAG

O modo ativo ativo de grupo de agregação de enlaces multichassis (MC-LAG) e a espionagem de IGMP no modo active-standby 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 o IGMP bisbilhotar em um domínio de ponte com apenas interfaces de Camada 2

• Aprendizado qualificado

• Links de 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 em um switch de Camada 2 puro

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

• Suporte para mc-links sendo 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 ativos ativos

• Adicionar links de interchasse às 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 tipicamente suportada para o IGMP Snooping com pontes ativas MC-LAG

A Figura 1 mostra uma topologia de rede típica sobre a qual o IGMP bisbilhotando 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 links 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 link de 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 P-A do roteador é o chassi responsável por retirar o tráfego do núcleo IP. Dessa forma, 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 no 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 desencadeadas por pacotes recebidos em chassi remoto

A seguir, 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 pernas remotas de links multichassis e links S 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 nas pernas remotas de um link multichassis.

Encaminhamento de dados

Essa discussão pressupõe que o roteamento integrado e a ponte no Roteador P-A seja 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 entregar tráfego a hosts conectados à S-A (que não é o DR) no link de casa única como a I3, contamos com o link de interchasse. O tráfego que atinge a P-A é enviado pela ICL à S-A para ser entregue nos links que relataram interesses em s,g e nos links voltados para o roteador.

Quando a perna ae0 em P-A cai, os hosts conectados ao link multichassis recebem tráfego através da ICL. Na S-A, o tráfego recebido na ICL é enviado para links multichassis na lista de interface de saída para a qual a contraparte ae em P-A está baixa.

Topologia de Camada 2 pura sem roteamento integrado e pontes

A Figura 2 mostra que o chassi conectado 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 integrado e pontes

Aprendizado qualificado

Nesta topologia, as interfaces I1, I2, I3, I4, I5, I6, I7, I8, I9 e I10 são interfaces de casa única. Os links multichassis ae0.0 e ae0.1 pertencem ao mesmo domínio de ponte em ambos os chassis. As interfaces I10, I1,I7,I3,I5, ae0.0 e ae0.1 estão no mesmo domínio de 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 único 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 único switch.

Como não há links de 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 link de interchasse ICL1 corresponde 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 de passar 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 mais 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 aos hosts conectados ao Roteador S-A (que não é o DR) no link de casa única como I2, I4 (pertencente à ld1), contamos com a ICL1. O tráfego que atinge o Roteador P-A na interface I1 é enviado pelo link de interchasse ICL1 para o Roteador S-A a ser entregue aos links que relataram interesses em s,g ou os links que estão voltados para o roteador no domínio de aprendizado ld1.

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

Assume-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 interchassis no domínio de aprendizado ld3.

Grupos estáticos em interfaces de casa única

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 interface de saída padrão oferece suporte à entrega de tráfego para a 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 links de multichassis, mas em ambos os pares, o link multichassis deve ser considerado como voltado para o roteador.

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

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

• Espionagem 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 em domínios de ponte fazendo aprendizado qualificado

• MC-Links de interface voltada para roteadores

Os recursos a seguir são not suportados:

• Modo proxy para ativos ativos

• 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, as interfaces lógicas são sempre adicionadas como uma interface voltada para roteadores à lista de interfaces de saída.

Topologia MC-LAG com suporte

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 prioritárias 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 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ós 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 puros de QFX5100 (compostos apenas por QFX5100 switches) 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ós 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 da FIP no FCoE VLAN nos switches de trânsito TS1 e TS2. Você pode configurar VN_Port para VF_Port (VN2VF_Port) espionagem fip ou VN_Port para VN_Port (VN2VN_Port) espionagem fip, dependendo se os hosts FCoE precisam acessar alvos no FC SAN (VN2VF_Port espionagem 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 espionagem da FIP nos switches MC-LAG S1 e S2. (Não habilite a espionagem de 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:

  A Juniper Networks QFX10000 switches de agregação não suportam a 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 cos para oferecer suporte a transporte sem perdas. (Em cada switch MC-LAG, o nome, fila de saída e provisionamento 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 a espionagem 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ê permite 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 da FIP nos switches usados para criar o MC-LAG. Por exemplo, na Figura 3, você não permitiria que o FIP bisbilhotasse as VLANs FCoE nos switches S1 e S2.

Configure links entre switches como portas confiáveis do FCoE para reduzir a sobrecarga de espionagem do FIP e garantir que o sistema execute a espionagem de FIP apenas na borda de acesso. Na topologia de amostra, configure as portas TS1 e TS2 LAG do switch de trânsito 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 do FCoE.

Ponte 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 de 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 na 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 de FCoE pode ser mapeada para ponto 011 de código IEEE 802.1p (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 o transporte sem perdas. A configuração do ETS pode ser diferente em cada switch MC-LAG, desde que haja recursos suficientes programados para oferecer suporte ao transporte sem perdas para o tráfego FCoE esperado.

O Link Layer Discovery Protocol (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 de usar EVPN-MPLS com Junos Fusion Enterprise e MC-LAG

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

Manuseio de tráfego BUM

Nos casos de uso mostrados na Figura 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 em sua implementação do recurso de intertrabalho 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 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 para seus pares. No entanto, dado que tanto a EVPN quanto o MC-LAG estão sincronizando os endereços, surge um problema.

A Tabela 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.

Manuseio 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 satélite SD1 está baixa. Independentemente de o pacote BUM ser tratado por MC-LAG ou multihoming EVPN ativo ativo, o resultado é o mesmo — o pacote é encaminhado através da interface ICL para PE3, que o encaminha para SD1 de dupla casa.

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

Suporte para gateways de camada 3

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

• Interfaces de roteamento e ponte integradas (IRB) para encaminhar tráfego entre os domínios de ponte estendidos ou VLANs.

• Gateways de Camada 3 padrão para encaminhar tráfego de um servidor físico (bare-metal) em um domínio de ponte estendido ou VLAN para um servidor físico ou máquina virtual em outro domínio de ponte estendido ou VLAN.