Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Interfaces Ethernet agregadas

Os tópicos abaixo discutem a visão geral agregada de interfaces de ethernet, detalhes de configuração da agregação de links e interfaces Ethernet agregadas, solução de problemas e verificação de Interfaces Ethernet agregadas.

Entender interfaces agregadas de ethernet e LACP para switches

A agregação de enlace IEEE 802.3ad permite que você agrupar interfaces Ethernet para formar uma única interface de camada de link, também conhecida como um grupo de agregação de links (LAG) ou pacote.

Agregar vários links entre interfaces físicas cria um único enlace de tronco lógico ponto a ponto ou um LAG. O LAG equilibra o tráfego nos links de membros em um pacote Ethernet agregado e aumenta efetivamente a largura de banda de uplink. Outra vantagem da agregação de links é o aumento da disponibilidade, porque o LAG é composto por vários links de membros. Se um link de membro falhar, o LAG continua a transportar tráfego pelos links restantes.

Nota:

No QFX5100, QFX5120, EX4600, switches autônomos QFX10002 e em um QFX5100 Virtual Chassis e Virtual Chassis EX4600, você pode configurar uma taxa mista de velocidades de enlace para o pacote Ethernet agregado. Apenas as velocidades de enlace de 40G e 10G são suportadas. O balanceamento de carga não funcionará se você configurar velocidades de enlace que não são suportadas.

O protocolo de controle de agregação de links (LACP) é um subcomponente do padrão IEEE 802.3ad e é usado como um protocolo de descoberta.

Nota:

Para garantir o balanceamento de carga nas interfaces agregadas de Ethernet (AE) em um grupo de nó de servidor redundante, os membros da AE devem ser igualmente distribuídos pelo grupo de nós de servidor redundante.

Nota:

Durante uma troca de grupo no nó de rede, o tráfego pode ser descartado por alguns segundos.

Grupo de agregação de links

Você configura um LAG especificando o número do link como um dispositivo físico e, em seguida, associando um conjunto de interfaces (portas) com o link. Todas as interfaces precisam ter a mesma velocidade e estar no modo full-duplex. O sistema operacional Junos OS (Junos OS) da Juniper Networks para switches Ethernet da Série EX atribui uma prioridade única de ID e porta a cada interface. O ID e a prioridade não são configuráveis.

O número de interfaces que podem ser agrupadas em um LAG e o número total de LAGs suportados em um switch varia de acordo com o modelo do switch. A Tabela 1 lista os switches da Série EX e o número máximo de interfaces por LAG e o número máximo de LAGs que eles suportam.

LAGs com links de membros de diferentes tipos de interface, por exemplo, ge e mge não são suportados em switches multitratos.

Nota:

Para o Junos OS Evolved, o software não impõe um limite ao número máximo de interfaces AE em um pacote AE de taxa mista. Como todas as interfaces lógicas infantis pertencem à mesma interface física AE e compartilham o mesmo seletor, usando muito menos memória de equilíbrio de carga, as configurações de interface AE de taxa mista devem passar mesmo se excederem 64 interfaces lógicas.

Tabela 1: Interfaces máximas por LAG e LAGs máximos por switch (switches da Série EX)

Interruptor

Interfaces máximas por LAG

LAGs máximos

EX2200

8

32

EX2300

8

128

EX3200

8

32

Chassi virtual EX3300 e EX3300

8

32

EX3400

16

128

Chassi virtual EX4200 e EX4200

8

111

Chassi virtual EX4300 e EX4300

16

128

Chassi virtual EX4500, EX4500, EX4550 e Chassi Virtual EX4550

8

111

EX4400 16 128

EX4600

32

128

EX6200

8

111

EX8200

12

255

Chassi virtual EX8200

12

239

EX9200

64

150

Tabela 2: Interfaces máximas por LAG e LAGs máximos por switch (Switches da Série QFX)

Interruptor

Interfaces máximas por LAG

LAGs máximos

QFX3500

64

60

QFX3600

64

60

QFX5100

64

96

QFX5110

64

96

QFX5120

64

72

QFX5200

64

128

QFX5700

128

144

QFX10002

64

150

QFX10008

64

1000

QFX10016

64

1000

Nota:

Nos switches da Série QFX, se você tentar cometer uma configuração contendo mais de 64 interfaces Ethernet em um LAG, você receberá uma mensagem de erro dizendo que o limite de grupo de 64 foi excedido, e o checkout de configuração falhou.

Para criar um LAG:

  1. Crie uma interface Ethernet agregada lógica.

  2. Definir os parâmetros associados à interface Ethernet agregada lógica, como uma unidade lógica, propriedades de interface e protocolo de controle de agregação de enlace (LACP).

  3. Defina os links de membro a serem contidos na interface Ethernet agregada — por exemplo, duas interfaces Ethernet de 10 Gigabits.

  4. Configure LACP para detecção de enlaces.

Tenha em mente essas diretrizes de hardware e software:

  • Para o Junos OS Evolved, quando uma nova interface é adicionada como membro ao pacote Ethernet agregado, um evento de flap de enlace é gerado. Quando você adiciona uma interface ao pacote, a interface física é excluída como uma interface regular e depois adicionada de volta como um membro. Durante esse tempo, os detalhes da interface física são perdidos.

  • Até 32 interfaces Ethernet podem ser agrupadas para formar um LAG em um grupo de nó de servidor redundante, um grupo de nó de servidor e um grupo de nó de rede em um sistema QFabric. Até 48 LAGs são suportados em grupos redundantes de nós de servidor e grupos de nós de servidor em um sistema QFabric, e até 128 LAGs são suportados em grupos de nó de rede em um sistema QFabric. Você pode configurar LAGs em dispositivos de nó em grupos redundantes de nó de servidor, grupos de nó de servidor e grupos de nó de rede.

    Nota:

    Em um sistema Qfabric, se você tentar cometer uma configuração contendo mais de 32 interfaces Ethernet em um LAG, você receberá uma mensagem de erro dizendo que o limite de grupo de 32 foi excedido, e o checkout de configuração falhou.

  • Até 64 interfaces Ethernet podem ser agrupadas para formar um LAG, e em um Junos Fusion, até 1.000 LAGs são suportados em switches QFX10002 que atuam como dispositivos de agregação.

  • O LAG deve ser configurado em ambos os lados do enlace.

  • As interfaces de ambos os lados do enlace devem ser definidas na mesma velocidade e estar no modo full-duplex.

    Nota:

    O Junos OS atribui uma prioridade única de ID e porta a cada porta. O ID e a prioridade não são configuráveis.

  • Os sistemas QFabric oferecem suporte a um LAG especial chamado FCoE LAG, que permite transportar tráfego FCoE e tráfego Ethernet regular (tráfego que não é tráfego FCoE) pelo mesmo pacote de agregação de enlace. Os LAGs padrão usam um algoritmo de hashing para determinar qual link físico no LAG é usado para uma transmissão, de modo que a comunicação entre dois dispositivos pode usar links físicos diferentes no LAG para diferentes transmissões. Um FCoE LAG garante que o tráfego FCoE use o mesmo link físico no LAG para solicitações e respostas, a fim de preservar o enlace virtual ponto a ponto entre o adaptador de rede convergente (CNA) do dispositivo FCoE e o switch FC SAN em um dispositivo de nó do sistema QFabric. Um FCoE LAG não oferece balanceamento de carga ou redundância de enlace para o tráfego FCoE. No entanto, o tráfego Ethernet regular usa o algoritmo de hashing padrão e recebe os benefícios de LAG usuais de balanceamento de carga e redundância de enlace em um FCoE LAG. Consulte a compreensão dos LAGs FCoE para obter mais informações.

Protocolo de controle de agregação de links (LACP)

LACP é um método de agrupar várias interfaces físicas para formar uma interface Ethernet agregada lógica. Por padrão, os links Ethernet não trocam unidades de dados de protocolo LACP (PDUs), que contêm informações sobre o estado do link. Você pode configurar links Ethernet para transmitir Ativamente PDUs LACP ou configurar os links para transmiti-los passivamente, enviando PDUs LACP apenas quando o link Ethernet os recebe da extremidade remota. O modo LACP pode ser ativo ou passivo. O link transmissor é conhecido como o ator, e o link receptor é conhecido como o parceiro. Se o ator e o parceiro estiverem ambos no modo passivo, eles não trocarão pacotes LACP, e os links Ethernet agregados não aparecerem. Se o ator ou parceiro estiver ativo, eles trocam pacotes LACP. Por padrão, o LACP está no modo passivo em interfaces Ethernet agregadas. Para iniciar a transmissão de pacotes LACP e a resposta a pacotes LACP, você deve habilitar o modo ativo LACP. Você pode configurar interfaces de Ethernet agregadas e marcadas por VLAN sem LACP habilitado. O LACP é definido em IEEE 802.3ad, Aggregation of Multiple Link Segments.

O LACP foi projetado para alcançar o seguinte:

  • Adição e exclusão automáticas de links individuais ao LAG sem intervenção do usuário.

  • Monitoramento de link para verificar se ambas as extremidades do pacote estão conectadas ao grupo correto.

Em um cenário em que um servidor de casa dupla é implantado com um switch, as placas de interface de rede formam um LAG com o switch. Durante uma atualização de servidor, o servidor pode não ser capaz de trocar PDUs LACP. Nessa situação, você pode configurar uma interface para estar no up estado mesmo se nenhuma PDUs for trocada. Use a force-up declaração para configurar uma interface quando o peer tiver recursos LACP limitados. A interface escolhe o LAG associado por padrão, seja no modo ativo ou passivo. Quando as PDUs não são recebidas, o parceiro é considerado trabalhando no modo passivo. Portanto, as transmissões de PDU LACP são controladas pelo enlace transmissor.

Se a extremidade remota do enlace LAG for um dispositivo de segurança, o LACP pode não ser suportado porque os dispositivos de segurança exigem uma configuração determinística. Nesse caso, não configure LACP. Todos os links do LAG estão permanentemente operacionais, a menos que o switch detecte uma falha de enlace dentro da camada física de Ethernet ou das camadas de link de dados.

Quando o LACP está configurado, ele detecta erros de configuração na extremidade local ou na extremidade remota do link. Assim, o LACP pode ajudar a evitar falhas na comunicação:

  • Quando o LACP não está habilitado, um LAG local pode tentar transmitir pacotes para uma interface única remota, o que faz com que a comunicação falhe.

  • Quando o LACP está habilitado, um LAG local não pode transmitir pacotes a menos que um LAG com LACP também esteja configurado na extremidade remota do link.

Configuração de uma interface Ethernet agregada

Você pode associar uma interface física a uma interface Ethernet agregada.

Para configurar uma interface Ethernet agregada:

  1. Especifique se deseja configurar a interface de grupo de agregação de links.
  2. Configure a interface Ethernet agregada.

Você especifica o número x da instância da interface para completar a associação de enlace; Você também deve incluir uma declaração definindo aex no nível de [edit interfaces] hierarquia. Você pode especificar opcionalmente outras propriedades físicas que se aplicam especificamente às interfaces Ethernet agregadas; para obter detalhes, consulte a visão geral das Interfaces Ethernet.

Nota:

Em geral, os pacotes Ethernet agregados oferecem suporte aos recursos disponíveis em todas as interfaces suportadas que podem se tornar um link de membro dentro do pacote. Como exceção, os recursos de Ethernet IQ gigabit e alguns recursos Ethernet Gigabit mais novos não são suportados em pacotes Ethernet agregados.

As interfaces Gigabit Ethernet IQ e SFP podem ser links de membros, mas recursos específicos de IQ e SFP não são suportados no pacote Ethernet agregado, mesmo que todos os links de membros suportem esses recursos individualmente.

Você precisa configurar a velocidade correta do enlace para a interface Ethernet agregada para eliminar qualquer mensagem de aviso.

Nota:

Antes de cometer uma configuração Ethernet agregada, garanta que o modo de enlace não esteja configurado em nenhuma interface de membro do pacote Ethernet agregado; caso contrário, a verificação de confirmação de configuração falha.

Configuração de interfaces de ethernet agregadas marcadas

Para especificar interfaces Ethernet agregadas, inclua a vlan-tagging declaração no nível de [edit interfaces aex] hierarquia:

Você também deve incluir a vlan-id declaração:

Você pode incluir esta declaração nos seguintes níveis de hierarquia:

  • [edit interfaces interface-name unit logical-unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Para obter mais informações sobre as declarações e vlan-id declarações, consulte a vlan-tagging visão geral das VLANs 802.1Q.

Configuração de interfaces de ethernet agregadas não registradas

Quando você configura uma interface Ethernet agregada não registrada, as regras existentes para interfaces não registradas se aplicam. Essas regras são as seguintes:

  • Você pode configurar apenas uma interface lógica (unidade 0) na porta. A unidade lógica 0 é usada para enviar e receber unidades de dados de protocolo LACP ou marcador (PDUs) de e para os links individuais.

  • Você não pode incluir a vlan-id declaração na configuração da interface lógica.

Configure uma interface Ethernet agregada não registrada omitindo as declarações e vlan-id declaraçõesvlan-tagging da configuração:

Configuração do número de interfaces agregadas de ethernet no dispositivo (software aprimorado de camada 2)

Por padrão, nenhuma interface Ethernet agregada é criada. Você deve definir o número de interfaces Ethernet agregadas no dispositivo de roteamento antes de configurá-las.

  1. Especifique se deseja acessar a configuração agregada de Ethernet no dispositivo.
  2. Defina o número de interfaces Ethernet agregadas.

Você também deve especificar os links físicos constituintes, incluindo a 802.3ad declaração no nível da [edit interfaces interface-name ether-options] hierarquia.[edit interfaces interface-name ether-options]

Exemplo: configurar interfaces agregadas de ethernet

Interfaces Ethernet agregadas podem usar interfaces de diferentes FPCs, DPCs ou PICs. A configuração a seguir é suficiente para colocar uma interface Gigabit Ethernet agregada em funcionamento.

Exclusão de uma interface Ethernet agregada

Existem duas abordagens para excluir uma interface Ethernet agregada:

  • Você pode excluir uma interface Ethernet agregada da configuração da interface. O Junos OS remove as declarações de configuração relacionadas aex e define essa interface para baixo do estado.

  • Você também pode remover permanentemente a interface Ethernet agregada da configuração do dispositivo, excluindo-a da contagem de dispositivos no dispositivo de roteamento.

Para excluir uma interface Ethernet agregada:

  1. Exclua a configuração Ethernet agregada.

    Essa etapa altera o estado da interface para baixo e remove as declarações de configuração relacionadas a aex.

  2. Exclua a interface da contagem de dispositivos.

Resolução de problemas de uma interface Ethernet agregada

Resolução de problemas para interfaces Ethernet agregadas:

O comando do Show Interfaces mostra que o LAG está desativado

Problema

Descrição

O show interfaces terse comando mostra que o LAG está desativado.

Solução

Confira a seguir:

  • Verifique se não há incompatibilidade de configuração.

  • Verifique se todas as portas dos membros estão ativas.

  • Verifique se um LAG faz parte da ethernet da família — comutação (Lag de Camada 2) ou inet familiar (Lag de Camada 3).

  • Verifique se o membro LAG está conectado ao LAG correto na outra extremidade.

  • Verifique se os membros lag pertencem ao mesmo switch (ou ao mesmo Virtual Chassis).

Estatísticas lógicas de interface não refletem todo o tráfego

Problema

Descrição

As estatísticas de tráfego de uma interface lógica não incluem todo o tráfego.

Solução

Os campos de estatísticas de tráfego para interfaces lógicas em show interfaces comandos mostram apenas tráfego de controle; as estatísticas de tráfego não incluem tráfego de dados. Você pode ver as estatísticas para todo o tráfego apenas por interface física.

As estatísticas de tráfego da interface IPv6 não são compatíveis

Problema

Descrição

O IPv6 transit statistics comando show interfaces exibe todos os 0 valores.

Solução

Os switches da Série EX não oferecem suporte à coleta e ao relatório das estatísticas de trânsito IPv6.

SNMP contra-ataca seHCInBroadcastPkts e seInBroadcastPkts estiverem sempre 0

Problema

Descrição

Os valores para o SNMP contradiz seHCInBroadcastPkts e seInBroadcastPkts estiverem sempre 0.

Solução

O SNMP rebate seHCInBroadcastPkts e se oInBroadcastPkts não tiver suporte para interfaces Ethernet agregadas em switches da Série EX.

Configuração do reequilíbrio periódico de assinantes em uma interface Ethernet agregada

Se os assinantes estiverem frequentemente fazendo login e saindo da sua rede, você pode configurar o sistema para reequilibrar periodicamente os links com base em um tempo e intervalo específicos.

Para configurar o reequilíbrio periódico:

  1. Acesse a interface Ethernet agregada para a qual você deseja configurar o reequilíbrio periódico.
  2. Configure os parâmetros de reequilíbrio para a interface, incluindo o tempo e o intervalo entre ações de reequilíbrio.

Configuração do Ethernet LACP agregado

Para interfaces Ethernet agregadas, você pode configurar o Protocolo de Controle de Agregação de Enlace (LACP). LACP é um método de agrupar várias interfaces físicas para formar uma interface lógica. Você pode configurar a Ethernet agregada e marcada por VLAN com ou sem LACP habilitado.

Para agregação de enlace multichassis (MC-LAG), você deve especificar o system-id e admin key. Os colegas de MC-LAG usam o mesmo system-id ao enviar as mensagens LACP. Ela system-id pode ser configurada no dispositivo de rede MC-LAG e sincronizada entre pares para validação.

As trocas de LACP são feitas entre atores e parceiros. Um ator é a interface local em uma troca de LACP. Um parceiro é a interface remota em uma troca de LACP.

O LACP é definido em IEEE 802.3ad, agregação de múltiplos segmentos de enlace.

O LACP foi projetado para alcançar o seguinte:

  • Adição e exclusão automáticas de links individuais ao pacote agregado sem intervenção do usuário

  • Monitoramento de link para verificar se ambas as extremidades do pacote estão conectadas ao grupo correto

A implementação do LACP pelo Junos OS oferece monitoramento de enlaces, mas não adição automática e exclusão de links.

O modo LACP pode ser ativo ou passivo. Se o ator e o parceiro estiverem ambos no modo passivo, eles não trocam pacotes LACP, o que resulta em links Ethernet agregados não surgindo. Se o ator ou parceiro estiver ativo, eles trocam pacotes LACP. Por padrão, o LACP é desativado em interfaces Ethernet agregadas. Se o LACP estiver configurado, ele está no modo passivo por padrão. Para iniciar a transmissão de pacotes LACP e a resposta a pacotes LACP, você deve configurar LACP no modo ativo.

Para ativar o modo ativo LACP, inclua a lacp declaração no nível de [edit interfaces interface-name aggregated-ether-options] hierarquia e especifique a opção active :

Nota:

O processo LACP só existe no sistema se você configurar o sistema no modo LACP ativo ou passivo.

Para restaurar o comportamento padrão, inclua a lacp declaração no nível de [edit interfaces interface-name aggregated-ether-options] hierarquia e especifique a opção passive :

A partir da versão 12.2 do Junos OS, você também pode configurar o LACP para substituir o padrão IEEE 802.3ad e permitir que o link de espera sempre receba tráfego. Superar o comportamento padrão facilita o failover do subsecond.

Para substituir o padrão IEEE 802.3ad e facilitar o failover de subsecond, inclua a fast-failover declaração no nível de [edit interfaces interface-name aggregated-ether-options lacp] hierarquia.

Para obter mais informações, veja as seguintes seções:

Configuração do intervalo LACP

Por padrão, o ator e o parceiro enviam pacotes LACP a cada segundo. Você pode configurar o intervalo em que as interfaces enviam pacotes LACP, incluindo a periodic declaração no nível de [edit interfaces interface-name aggregated-ether-options lacp] hierarquia:

O intervalo pode ser rápido (a cada segundo) ou lento (a cada 30 segundos). Você pode configurar taxas periódicas diferentes em interfaces ativas e passivas. Quando você configura as interfaces ativas e passivas a taxas diferentes, o transmissor honra a taxa do receptor.

Nota:

A filtragem de endereços de origem não funciona quando o LACP está ativado.

Os policiais percentuais não são suportados em interfaces Ethernet agregadas com a família de protocolo CCC configurada. Para obter mais informações sobre policiais percentuais, consulte as políticas de roteamento, filtros de firewall e o guia de usuário dos policiais de tráfego.

Geralmente, o LACP é suportado em todas as interfaces Ethernet agregadas não registradas. Para obter mais informações, consulte Configuração de interfaces de ethernet agregadas não registradas.

Configuração da proteção de enlace LACP

Nota:

Ao usar a proteção de link LACP, você pode configurar apenas dois links de membros para uma interface Ethernet agregada: um ativo e um standby.

Para forçar links ativos e de espera dentro de uma Ethernet agregada, você pode configurar a proteção do enlace LACP e a prioridade do sistema no nível agregado da interface Ethernet usando as declarações e system-priority as link-protection declarações. Configurar valores nesse nível resulta apenas nas interfaces configuradas usando a configuração definida. A configuração da interface LACP também permite substituir as configurações de LACP globais (chassi).

A proteção de enlace LACP também usa a prioridade da porta. Você pode configurar a prioridade de porta no nível de hierarquia da interface [ether-options] Ethernet usando a port-priority declaração. Se você optar por não configurar a prioridade da porta, a proteção do link LACP usa o valor padrão para prioridade de porta (127).

Nota:

A proteção de link LACP oferece suporte à configuração de agendamento por unidade em interfaces Ethernet agregadas.

Para permitir a proteção de enlace LACP para interfaces Ethernet agregadas, use a link-protection declaração no nível de [edit interfaces aeX aggregated-ether-options lacp] hierarquia:

Por padrão, a proteção de enlace LACP é revertida para um enlace de maior prioridade (com menor número) quando esse enlace de maior prioridade se torna operacional ou um link é adicionado ao agregador que é determinado como mais prioritário. No entanto, você pode eliminar o cálculo do enlace adicionando a non-revertive declaração à configuração de proteção de enlace LACP. No modo nãoevertivo, uma vez que um link esteja ativo e coletando e distribuindo pacotes, a subsequente adição de um enlace de maior prioridade (melhor) não resulta em um switch e o link atual permanece ativo.

Se a proteção de enlace LACP estiver configurada para não serevertiva no nível global ([edit chassis] hierarquia), você pode adicionar a revertive declaração à configuração de proteção de enlace LACP para substituir a configuração nãoevertiva para a interface. No modo reversivo, a adição de um link de maior prioridade ao agregador resulta em LACP realizando um recalculação prioritário e comutação do link ativo atual para o novo link ativo.

CUIDADO:

Se ambas as extremidades de um agregador tiverem a proteção de link LACP ativada, certifique-se de configurar ambas as extremidades do agregador para usar o mesmo modo. A incompatibilidade dos modos de proteção de enlace LACP pode resultar em perda de tráfego.

Recomendamos fortemente que você use LACP em ambas as extremidades do agregador, quando você conecta uma interface Ethernet agregada com duas interfaces de membros a qualquer outro dispositivo de fornecedor. Caso contrário, o dispositivo do fornecedor (digamos um switch de Camada 2, ou um roteador), não será capaz de gerenciar o tráfego vindo do pacote Ethernet agregado de dois enlaces. Como resultado, você pode observar o dispositivo do fornecedor enviando de volta o tráfego para o link de membro de backup da interface Ethernet agregada.

Atualmente, MX-MPC2-3D, MX-MPC2-3D-Q, MX-MPC2-3D-EQ, MX-MPC1-3D, MX-MPC1-3D-Q e MPC-3D-16XGE-SFPP não derrubam o tráfego que volta ao link de backup, enquanto DPCE-R-Q-20GE-2XGE, DPCE-R-Q-20GE-SFP, DPCE-R-Q-40GE-SFP, DPCE-R-Q-4XGE-XFP, DPCE-X-Q-40GE-SFP e DPCE-X-Q-4XGE-XFP derrubam o tráfego que chega ao link de backup.

Configuração da prioridade do sistema LACP

Para configurar a prioridade do sistema LACP para interfaces Ethernet agregadas na interface, use a system-priority declaração no nível de [edit interfaces aeX aggregated-ether-options lacp] hierarquia:

A prioridade do sistema é um valor binário de 2 octetes que faz parte do ID do sistema LACP. O ID do sistema LACP consiste na prioridade do sistema como os dois octetes mais significativos e o endereço MAC da interface como os seis octetes menos significativos. O sistema com o valor numericamente menor para a prioridade do sistema tem a maior prioridade. Por padrão, a prioridade do sistema é 127, com um intervalo de 0 a 65.535.

Configuração do identificador do sistema LACP

Para configurar o identificador de sistema LACP para interfaces Ethernet agregadas, use a system-id declaração no nível de [edit interfaces aeX aggregated-ether-options lacp] hierarquia:

O identificador de sistema definido pelo usuário no LACP permite que duas portas de dois dispositivos separados atuem como se fizessem parte do mesmo grupo agregado.

O identificador de sistema é um campo único globalmente exclusivo de 48 bits (6 byte). Ele é usado em combinação com um valor de prioridade do sistema de 16 bits, o que resulta em um identificador único do sistema LACP.

Configuração de chave administrativa LACP

Para configurar uma chave administrativa para LACP, inclua a admin-key number declaração no nível de edit interfaces aex aggregated-ether-options lacp] hierarquia:

Nota:

Você deve configurar o MC-LAG para configurar a admin-key declaração. Para obter mais informações sobre o MC-LAG, consulte a configuração da agregação de enlace multichassis em roteadores da Série MX .

Configuração da prioridade de porta LACP

Para configurar a prioridade da porta LACP para interfaces Ethernet agregadas, use a port-priority declaração nos níveis de [edit interfaces interface-name ether-options 802.3ad aeX lacp] hierarquia ou [edit interfaces interface-name ether-options 802.3ad aeX lacp] :

A prioridade da porta é um campo de 2 octets que faz parte do ID da porta LACP. O ID da porta LACP consiste na prioridade da porta como os dois octetes mais significativos e o número da porta como os dois octetes menos significativos. O sistema com valor numericamente menor para prioridade de porta tem a maior prioridade. Por padrão, a prioridade da porta é 127, com uma faixa de 0 a 65.535.

A seleção de agregação de portas é feita por cada sistema com base na mais alta prioridade de porta e é atribuída pelo sistema com a mais alta prioridade. As portas são selecionadas e atribuídas a partir da porta de maior prioridade do sistema de maior prioridade e funcionam com prioridade a partir daí.

Nota:

A seleção de agregação de portas (discutida acima) é realizada para o link ativo quando a proteção de enlace LACP está ativada. Sem a proteção de enlace LACP, a prioridade da porta não é usada na seleção de agregação de portas.

Rastreamento das operações de LACP

Para rastrear as operações do processo LACP, inclua a traceoptions declaração no nível de [edit protocols lacp] hierarquia:

Você pode especificar as seguintes bandeiras na protocols lacp traceoptions declaração:

  • all— Todas as operações de rastreamento LACP

  • configuration— Código de configuração

  • packet— Pacotes enviados e recebidos

  • process— Eventos de processo LACP

  • protocol— máquina de estado de protocolo LACP

  • routing-socket— Eventos de soquete de roteamento

  • startup— Processar eventos de startup

Limitações de LACP

O LACP pode unir várias interfaces físicas diferentes, mas apenas recursos que são suportados em todos os dispositivos vinculados serão suportados no pacote de agregação de links (LAG) resultante. Por exemplo, diferentes PICs podem oferecer suporte a um número diferente de aulas de encaminhamento. Se você usar a agregação de enlace para unir as portas de um PIC que oferece suporte a até 16 aulas de encaminhamento com uma PIC que oferece suporte a até 8 classes de encaminhamento, o pacote LAG resultante só suportará até 8 aulas de encaminhamento. Da mesma forma, unir uma PIC que oferece suporte ao WRED com uma PIC que não aceita isso resultará em um pacote LAG que não aceita WRED.

Exemplo: configurar o Ethernet LACP agregado

Configure o Ethernet LACP agregado em uma interface marcada por VLAN:

LACP com Ethernet agregada VLAN-Tagged

Configure o Ethernet LACP agregado em uma interface não registrada:

LACP com Ethernet agregada não registrada

Verificar se o LACP está configurado corretamente e os membros do pacote estão trocando pacotes de protocolo LACP

Verifique se o LACP foi configurado corretamente e que os membros do pacote estão transmitindo pacotes de protocolo LACP.

Verificando a configuração do LACP

Propósito

Verifique se o LACP foi configurado corretamente.

Ação

Para verificar se o LACP foi habilitado como ativo em uma extremidade:

Significado

Este exemplo mostra que o LACP foi configurado com um lado tão ativo e o outro como passivo. Quando o LACP está habilitado, um lado deve ser definido como ativo para que o enlace empacotado esteja ativo.

Verificando se os pacotes LACP estão sendo trocados

Propósito

Verifique se os pacotes LACP estão sendo trocados entre interfaces.

Ação

Use o show lacp statistics interfaces interface-name comando para exibir informações de intercâmbio LACP BPDU.

Significado

A saída aqui mostra que o enlace está ativo e que as PDUs estão sendo trocadas.

Entender sessões independentes de micro-BFD para LAG

A partir do Junos OS Release 13.3, esse recurso é compatível com os seguintes tipos PIC/FPC:

  • PC-1XGE-XENPAK (FPC Tipo 3)

  • PD-4XGE-XFP (FPC Tipo 4)

  • PD-5-10XGE-SFPP (FPC Tipo 4)

  • SFPP 24x10GE (LAN/WAN), 12x10GE (LAN/WAN) SFPP, 1x100GE Tipo 5 PICs

  • Todos os MPCs da Série MX com MICs Ethernet

  • FPC-PTX-P1-A no PTX5000 com interfaces Ethernet de 10 Gigabit

  • FPC2-PTX-P1A no PTX5000 com interfaces Ethernet de 10 Gigabit no Junos OS Versão 14.1 e posterior

  • Todos os FPCs da Série PTX com interfaces Ethernet no Junos OS Versão 14.1R3 e posteriores 14.1 versões, e Junos 14.2 e posterior

Ponta:

Veja a compatibilidade PIC/FPC da Série PTX para uma lista de PICs que são compatíveis em cada FPC da Série PTX.

Nota:

A configuração micro-BFD com endereços de interface não é compatível com roteadores PTX na linha de switches FPC3 e QFX10000.

O protocolo de detecção de encaminhamento bidirecional (BFD) é um protocolo de detecção simples que detecta rapidamente falhas nos caminhos de encaminhamento. Um grupo de agregação de links (LAG) combina vários links entre dispositivos que estão em conexões ponto a ponto, aumentando assim a largura de banda, fornecendo confiabilidade e permitindo o balanceamento de carga. Para executar uma sessão de BFD em interfaces LAG, configure uma sessão de BFD de modo assíncronos e independente em cada link de membro LAG em um pacote LAG. Em vez de uma única sessão de BFD monitorando o status da porta UDP, sessões de micro BFD independentes monitoram o status de links individuais de membros.

As sessões individuais de BFD determinam a conectividade de Camada 2 e Camada 3 de cada link de membro no LAG. Uma vez estabelecida uma sessão de BFD em um link específico, os links de membros são conectados ao LAG e ao balanceador de carga por uma configuração estática ou pelo Protocolo de Controle de Agregação de Enlace (LACP). Se os links de membros forem conectados ao LAG por uma configuração estática, o processo de controle do dispositivo funcionará como o cliente para a sessão micro BFD. Quando os links de membros são conectados ao LAG pelo LACP, o LACP atua como o cliente para a sessão micro BFD.

Quando a sessão de micro BFD está ativa, um link LAG é estabelecido e os dados são transmitidos por esse enlace LAG. Se a sessão de micro BFD em um link de membro estiver baixa, esse link de membro em particular for removido do balanceador de carga e os gerentes de LAG pararem de direcionar o tráfego para esse link. Essas sessões de micro BFD são independentes umas das outras, apesar de terem um único cliente que gerencia a interface LAG.

Nota:
  • Começando com o Junos OS Release 13.3, a IANA alocou 01-00-5E-90-00-01 como endereço MAC dedicado para micro BFD. O modo MAC dedicado é usado por padrão para sessões de micro BFD, de acordo com o rascunho mais recente para BFD over LAG.

  • No Junos OS, os pacotes de controle do MicroBFD são sempre não registrados por padrão. Para interfaces agregadas L2, a configuração deve incluir vlan-taging ou marcação flexível de vlan no Aggregated Ethernet com BFD. Caso contrário, o sistema jogará erro ao cometer a configuração.

  • Quando você habilita a MicroBFD em uma Interface Ethernet agregada, a Interface agregada pode receber pacotes microBFD. Começando com o Junos OS Release 19.3 e posterior para MPC10E e MPC11E MPCs, você não pode aplicar filtros de firewall nos pacotes MicroBFD recebidos na Interface Ethernet agregada. Para MPC1E por meio do MPC9E, você pode aplicar filtros de firewall nos pacotes MicroBFD recebidos na Interface Ethernet agregada apenas se a Interface Ethernet agregada for configurada como uma Interface não registrada.

As sessões de micro BFD são executadas nos seguintes modos:

  • Modo de distribuição — as sessões de Micro BFD são distribuídas por padrão na Camada 3.

  • Modo de não distribuição — você pode configurar a sessão de BFD para ser executada neste modo, incluindo a no-delegate-processing declaração sob gerenciamento periódico de pacotes (PPM). Nesse modo, os pacotes estão sendo enviados ou recebidos pelo Mecanismo de Roteamento na Camada 2.

Um par de dispositivos de roteamento em pacotes BFD de troca de LAG em um intervalo regular especificado. O dispositivo de roteamento detecta uma falha no vizinho quando deixa de receber uma resposta após um intervalo especificado. Isso permite a verificação rápida da conectividade do enlace de membros com ou sem LACP. Uma porta UDP distingue BFD sobre pacotes LAG da BFD em IP de um único salto.

Nota:

A IANA alocou 6784 como a porta de destino UDP para micro BFD.

Para permitir a detecção de falhas para redes LAG para interfaces Ethernet agregadas:

  • Inclua a declaração de detecção de bfd-liveness na configuração.

  • Especifique um valor de intervalo suspenso para definir o tempo mínimo que a sessão de BFD deve permanecer ativa antes que uma notificação de alteração de estado seja enviada aos outros membros da rede LAG.

  • Especifique o intervalo mínimo que indica o intervalo de tempo para transmissão e recebimento de dados.

  • Começando com o Junos OS Release 14.1, especifique o vizinho em uma sessão de BFD. Em versões anteriores ao Junos OS Release 16.1, você deve configurar o endereço loopback do destino remoto como endereço vizinho. Começando com o Junos OS Release 16.1, você também pode configurar esse recurso em roteadores da série MX com endereço agregado de interface Ethernet do destino remoto como endereço vizinho.

    Nota:

    Nos roteadores T1600 e T4000, você não pode configurar o endereço de Interface Ethernet agregado local do destino remoto como endereço vizinho.

    CUIDADO:

    Desativar a detecção de bfd-liveness no nível de hierarquia ou desativar a interface Ethernet agregada antes de alterar o endereço vizinho do endereço IP do loopback para o [edit interfaces aex aggregated-ether-options] endereço IP agregado da interface Ethernet. Modificar o endereço local e vizinho sem desativar bfd-liveness-detection ou a interface Ethernet agregada primeiro pode causar falha nas sessões de micro BFD.

    Nota:

    Começando com a versão 16.1R2, o Junos OS verifica e valida o micro BFD local-address configurado contra a interface ou endereço IP de loopback antes que a configuração se comprometa. O Junos OS realiza essa verificação nas configurações de endereços micro BFD IPv4 e IPv6 e, se não corresponderem, o compromisso falha.

Nota:

Esse recurso só funciona quando ambos os dispositivos oferecem suporte a BFD. Se o BFD estiver configurado em uma extremidade do LAG, esse recurso não funcionará.

Para a família de endereços IPv6, desabite a detecção de endereços duplicado antes de configurar esse recurso com endereços de interface AE. Para desativar a detecção de endereço duplicada, inclua a dad-disable declaração no nível de [edit interface aex unit y family inet6] hierarquia.

Configuração de sessões de micro BFD para LAG

O protocolo de detecção de encaminhamento bidirecional (BFD) é um protocolo de detecção simples que detecta rapidamente falhas nos caminhos de encaminhamento. Um grupo de agregação de links (LAG) combina vários links entre dispositivos que estão em conexões ponto a ponto, aumentando assim a largura de banda, fornecendo confiabilidade e permitindo o balanceamento de carga. Para executar uma sessão de BFD em interfaces LAG, configure uma sessão de BFD de modo assíncronos e independente em cada link de membro LAG em um pacote LAG. Em vez de uma única sessão de BFD monitorando o status da porta UDP, sessões de micro BFD independentes monitoram o status de links individuais de membros.

Nota:

A partir do Junos OS Evolved Release 20.1R1, sessões independentes de detecção de encaminhamento micro bidirecional (BFD) são habilitadas em um link por membro de um pacote de grupo de agregação de links (LAG).

Para permitir a detecção de falhas para interfaces Ethernet agregadas:

  1. Inclua a declaração a seguir na configuração no nível de [edit interfaces aex aggregated-ether-options] hierarquia:
  2. Configure os critérios de autenticação da sessão de BFD para LAG.

    Para especificar os critérios de autenticação, inclua a authentication declaração:

    • Especifique o algoritmo a ser usado para autenticar a sessão de BFD. Você pode usar um dos seguintes algoritmos para autenticação:

      • keyed-md5

      • keyed-sha-1

      • meticuloso-keyed-md5

      • meticuloso-keyed-sha-1

      • senha simples

    • Para configurar a cadeia de chave, especifique o nome associado à chave de segurança para a sessão de BFD. O nome que você especificar deve combinar com uma das cadeias de chave configuradas na authentication-key-chains key-chain declaração no nível de [edit security] hierarquia.

    • Configure a verificação de autenticação solta na sessão BFD. Use apenas para períodos de transição quando a autenticação pode não estar configurada em ambas as extremidades da sessão de BFD.

  3. Configure temporistas BFD para interfaces Ethernet agregadas.

    Para especificar os timers BFD, inclua a detection-time declaração:

    Especifique o valor limite. Este é o intervalo de tempo máximo para detectar um vizinho BFD. Se o intervalo de transmissão for maior que esse valor, o dispositivo aciona uma armadilha.

  4. Configure um valor de intervalo suspenso para definir o tempo mínimo que a sessão de BFD deve permanecer acordado antes que uma notificação de alteração de estado seja enviada aos outros membros da rede LAG.

    Para especificar o intervalo de espera, inclua a holddown-interval declaração:

    Você pode configurar um número na faixa de 0 a 255.000 milissegundos, e o padrão é 0. Se a sessão de BFD diminuir e depois voltar para cima durante o intervalo de espera, o temporizador será reiniciado.

    Esse valor representa o intervalo mínimo em que o dispositivo de roteamento local transmite pacotes BFD, bem como o intervalo mínimo em que o dispositivo de roteamento espera receber uma resposta de um vizinho com o qual estabeleceu uma sessão de BFD. Você pode configurar um número na faixa de 1 a 255.000 milissegundos. Você também pode especificar o mínimo de transmissão e receber intervalos separadamente.

  5. Configure o endereço de origem para a sessão BFD.

    Para especificar um endereço local, inclua a local-address declaração:

    O endereço local da BFD é o endereço de loopback da origem da sessão de BFD.

    Nota:

    Começando com o Junos OS Release 16.1, você também pode configurar esse recurso com o endereço da interface AE como endereço local em uma sessão micro BFD. Para a família de endereços IPv6, desabite a detecção de endereço duplicado antes de configurar esse recurso com o endereço da interface AE. Para desativar a detecção de endereço duplicada, inclua a dad-disable declaração no nível de [edit interface aex unit y family inet6] hierarquia.

    Começando com a versão 16.1R2, o Junos OS verifica e valida o micro BFD local-address configurado contra a interface ou endereço IP de loopback antes que a configuração se comprometa. O Junos OS realiza essa verificação nas configurações de endereços micro BFD IPv4 e IPv6 e, se não corresponderem, o compromisso falha. O micro-BFD local-address configurado deve combinar com o micro-BFD neighbour-address configurado no roteador de peer.

  6. Especifique o intervalo mínimo que indica o intervalo de tempo para transmissão e recebimento de dados.

    Esse valor representa o intervalo mínimo em que o dispositivo de roteamento local transmite pacotes BFD, bem como o intervalo mínimo em que o dispositivo de roteamento espera receber uma resposta de um vizinho com o qual estabeleceu uma sessão de BFD. Você pode configurar um número na faixa de 1 a 255.000 milissegundos. Você também pode especificar o mínimo de transmissão e receber intervalos separadamente.

    Para especificar o mínimo de transmissão e receber intervalos para detecção de falhas, inclua a minimum-interval declaração:

    Nota:

    BFD é um protocolo intensivo que consome recursos do sistema. Especificar um intervalo mínimo para BFD inferior a 100 ms para sessões baseadas em mecanismos de roteamento e 10 ms para sessões distribuídas de BFD pode causar flapping BFD indesejado.

    Dependendo do seu ambiente de rede, essas recomendações adicionais podem se aplicar:

    • Para implantações de rede de grande escala com um grande número de sessões de BFD, especifique um intervalo mínimo de 300 ms para sessões baseadas em mecanismos de roteamento e 100 ms para sessões distribuídas de BFD.

    • Para implantações de rede de grande escala com um grande número de sessões de BFD, entre em contato com o suporte ao cliente da Juniper Networks para obter mais informações.

    • Para que as sessões de BFD permaneçam ativas durante um evento de comutação do Mecanismo de Roteamento quando o roteamento ativo sem parar for configurado, especifique um intervalo mínimo de 2500 ms para sessões baseadas em mecanismos de roteamento. Para sessões de BFD distribuídas com roteamento ativo sem parar configurados, as recomendações de intervalo mínimo ficam imutádas e dependem apenas da implantação de sua rede.

  7. Especifique apenas o intervalo mínimo de recebimento para detecção de falhas, incluindo a minimum-receive-interval declaração:

    Esse valor representa o intervalo mínimo em que o dispositivo de roteamento local espera receber uma resposta de um vizinho com o qual estabeleceu uma sessão de BFD. Você pode configurar um número na faixa de 1 a 255.000 milissegundos.

  8. Especifique o número de pacotes BFD que não foram recebidos pelo vizinho que faz com que a interface de origem seja declarada baixa, incluindo a multiplier declaração:

    O valor padrão é 3. Você pode configurar um número na faixa de 1 a 255.

  9. Configure o vizinho em uma sessão de BFD.

    O endereço do vizinho pode ser um IPv4 ou um endereço IPv6.

    Para especificar o próximo salto da sessão de BFD, inclua a neighbor declaração:

    O endereço vizinho do BFD é o endereço de loopback do destino remoto da sessão de BFD.

    Nota:

    Começando com o Junos OS Release 16.1, você também pode configurar o endereço de interface AE do destino remoto como o endereço vizinho do BFD em uma sessão micro BFD.

  10. (Opcional) Configure sessões de BFD para não se adaptar às mudanças nas condições da rede.

    Para desativar a adaptação da BFD, inclua a no-adaptation declaração:

    Nota:

    Recomendamos que você não desabilize a adaptação do BFD a menos que seja preferível não ter adaptação de BFD em sua rede.

  11. Especifique um limite para detectar a adaptação do tempo de detecção, incluindo a threshold declaração:

    Quando o tempo de detecção de sessão de BFD se adapta a um valor igual ou superior ao limite, uma única armadilha e uma mensagem de log do sistema são enviadas. O tempo de detecção é baseado no multiplicador do intervalo mínimo ou do valor mínimo de intervalo de recebimento. O limite deve ser um valor maior do que o multiplicador para qualquer um desses valores configurados. Por exemplo, se o intervalo mínimo de recebimento for de 300 ms e o multiplicador for 3, o tempo total de detecção é de 900 ms. Portanto, o limite de tempo de detecção deve ter um valor superior a 900.

  12. Especifique apenas o intervalo mínimo de transmissão para detecção de falhas, incluindo a transmit-interval minimum-interval declaração:

    Esse valor representa o intervalo mínimo em que o dispositivo de roteamento local transmite pacotes de BFD para o vizinho com o qual estabeleceu uma sessão de BFD. Você pode configurar um valor na faixa de 1 a 255.000 milissegundos.

  13. Especifique o limiar de transmissão para detectar a adaptação do intervalo de transmissão, incluindo a transmit-interval threshold declaração:

    O valor limite deve ser maior do que o intervalo de transmissão. Quando o tempo de detecção de sessão de BFD se adapta a um valor maior que o limite, uma única armadilha e uma mensagem de log do sistema são enviadas. O tempo de detecção é baseado no multiplicador do intervalo mínimo ou do valor mínimo de intervalo de recebimento. O limite deve ser um valor maior do que o multiplicador para qualquer um desses valores configurados.

  14. Especifique a versão BFD incluindo a version declaração:

    O padrão é detectar a versão automaticamente.

Nota:
  • A opção version não é compatível com a Série QFX. A partir do Junos OS Release 17.2R1, um aviso será exibido se você tentar usar este comando.

  • Esse recurso funciona quando ambos os dispositivos oferecem suporte a BFD. Se o BFD estiver configurado em apenas uma extremidade do LAG, esse recurso não funcionará.

Entendendo o algoritmo usado para hash lag bundle e saída tráfego ECMP next-hop

As Séries EX e QFX da Juniper Networks usam um algoritmo de hashing para determinar como encaminhar o tráfego por um pacote de grupo de agregação de enlaces (LAG) ou para o dispositivo next-hop quando o ECMP (Equal Cost Multipath) for ativado.

O algoritmo de hashing toma decisões de hashing com base em valores em vários campos de pacotes, bem como em alguns valores internos, como ID de porta de origem e ID de dispositivo de origem. Você pode configurar alguns dos campos que são usados pelo algoritmo de hashing.

Nota:

O suporte à plataforma depende da versão do Junos OS em sua instalação.

Este tópico contém as seguintes seções:

Entendendo o algoritmo de hashing

O algoritmo de hashing é usado para tomar decisões de encaminhamento de tráfego para o tráfego que entra em um pacote LAG ou para o tráfego que sai de um switch quando o ECMP está habilitado.

Para pacotes LAG, o algoritmo de hashing determina como o tráfego que entra em um pacote LAG é colocado nos links de membros do pacote. O algoritmo de hashing tenta gerenciar a largura de banda equilibrando uniformemente todo o tráfego recebido nos links de membros do pacote.

Para ECMP, o algoritmo de hashing determina como o tráfego recebido é encaminhado para o dispositivo next-hop.

O algoritmo de hashing toma decisões de hashing com base em valores em vários campos de pacotes, bem como em alguns valores internos, como ID de porta de origem e ID de dispositivo de origem. Os campos de pacotes usados pelo algoritmo de hashing variam de acordo com o EtherType do pacote e, em alguns casos, pela configuração no switch. O algoritmo de hashing reconhece os seguintes EtherTypes:

  • IP (IPv4 e IPv6)

  • MPLS

  • MAC-in-MAC

O tráfego que não é reconhecido como pertencente a nenhum desses EtherTypes é hashed com base no cabeçalho de Camada 2. O tráfego IP e MPLS também é hashed com base no cabeçalho de Camada 2 quando um usuário configura o modo hash como cabeçalho de Camada 2.

Você pode configurar alguns campos que são usados pelo algoritmo de hashing para tomar decisões de encaminhamento de tráfego. Você não pode, no entanto, configurar como certos valores dentro de um cabeçalho são usados pelo algoritmo de hashing.

Observe os seguintes pontos sobre o algoritmo de hashing:

  • Os campos selecionados para hashing são baseados apenas no tipo de pacote. Os campos não são baseados em nenhum outro parâmetro, incluindo a decisão de encaminhamento (ponte ou roteada) ou a configuração do pacote LAG de saída (Camada 2 ou Camada 3).

  • Os mesmos campos são usados para pacotes unicast e multicast de hashing. No entanto, os pacotes unicast e multicast são hashed diferente.

  • Os mesmos campos são usados pelo algoritmo de hash para hash ECMP e tráfego LAG, mas o algoritmo de hashing hashes ECMP e LAG tráfego de forma diferente. O tráfego LAG usa um hash de tronco, enquanto o ECMP usa hashing ECMP. Tanto o LAG quanto o ECMP usam a mesma semente RTAG7, mas usam compensações diferentes dessa semente 128B para evitar a polarização. A configuração inicial da função HASH para usar o tronco e a compensação de ECMP são definidas no tempo PFE Init. O hashing diferente garante que o tráfego não fique polarizado quando um pacote LAG faz parte do caminho de next-hop do ECMP.

  • Os mesmos campos são usados para hashing, independentemente de o switch estar ou não participando de um Virtual Chassis ou Virtual Chassis Fabric (VCF) misto ou não.

Os campos usados para hashing por cada EtherType, bem como os campos usados pelo cabeçalho de Camada 2 são discutidos nas seções a seguir.

IP (IPv4 e IPv6)

Os campos de carga em pacotes IPv4 e IPv6 são usados pelo algoritmo de hashing quando os pacotes IPv4 ou IPv6 precisam ser colocados em um link de membro em um pacote LAG ou enviados para o dispositivo de next-hop quando o ECMP estiver habilitado.

O modo hash é definido para o campo de carga de Camada 2, por padrão. Os campos de carga IPv4 e IPv6 são usados para hashing quando o modo hash é definido para carga de Camada 2.

Se o modo hash estiver configurado para cabeçalho de Camada 2, os pacotes IPv4, IPv6 e MPLS são hashed usando os campos de cabeçalho de Camada 2. Se você quiser os pacotes IPv4, IPv6 e MPLS recebidos pelo endereço MAC de origem, endereço MAC de destino ou campos EtherType, você deve definir o modo hash para cabeçalho de Camada 2.

A Tabela 5 exibe os campos de carga IPv4 e IPv6 que são usados pelo algoritmo de hashing, por padrão.

  • ✓— O campo é usado pelo algoritmo de hashing, por padrão.

  • Χ — O campo não é usado pelo algoritmo de hashing, por padrão.

  • (configurável)— O campo pode ser configurado para ser usado ou não pelo algoritmo de hashing.

Nos switches EX2300, os campos de carga em pacotes IPv4 e IPv6 são usados pelo algoritmo de hashing quando os pacotes IPv4 ou IPv6 precisam ser colocados em um link de membro em um pacote LAG ou enviados para o dispositivo de next-hop quando o ECMP estiver habilitado:

  • Para tráfego unicast no LAG - SIP, DIP, L4SP, L4DP

  • Para tráfego multicast conhecido no LAG - IP de origem, IP de destino, Ingress Mod Id e Ingress Port Id

  • Para transmissão, unicast desconhecido e tráfego multicast desconhecido no LAG - MAC fonte, Mac de destino, Ingress Mod Id e Ingress Port Id

  • Balanceamento de carga ECMP: IP de destino, porta de origem de Camada 4 e porta de destino de Camada 4

Tabela 5: Campos de hashing IPv4 e IPv6

Fields

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

 

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

MAC de origem

X

Χ

X

Χ

Χ

Χ

Χ

Χ

Χ

X

MAC de destino

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

EtherType

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

IP de origem ou IPv6

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

IP de destino ou IPv6

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

Protocolo (somente IPv4)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

Próximo cabeçalho (somente IPv6)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

Porta de origem de Camada 4

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

Porta de destino de Camada 4

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

Rótulo IPv6 Flow (somente IPv6)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Id mod de ingresso

(configurável)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Identificação de porta de entrada

(configurável)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

MPLS

O algoritmo de hashing temhes pacotes MPLS usando o IP de origem, IP de destino, rótulo MPLS 0, rótulo MPLS 1, rótulo MPLS 2 e campos MPLS 3. Nos switches QFX5110, QFX5120 e QFX5200, os roteadores LSR também oferecem suporte a ECMP. O ECMP usa esses campos para hashing em um roteador LSR:

  • VPN de Camada 3: Rótulos MPLS (top 3 rótulos), IP de origem, IP de destino e ID de porta de entrada

  • Circuito de Camada 2: Rótulos MPLS (top 3 rótulos) e ID de porta de ingresso

A Tabela 6 exibe os campos de carga MPLS que são usados pelo algoritmo de hashing, por padrão:

  • ✓— O campo é usado pelo algoritmo de hashing, por padrão.

  • Χ — O campo não é usado pelo algoritmo de hashing, por padrão.

Os campos usados pelo algoritmo de hashing para hashing de pacotes MPLS não são configuráveis pelo usuário.

Os campos ip de origem e destino nem sempre são usados para hashing. Para pacotes MPLS não encerrados, a carga é verificada se a bandeira inferior da pilha (BoS) é vista no pacote. Se a carga for IPv4 ou IPv6, os campos de endereço de origem IP e endereço de destino IP são usados para hashing junto com os rótulos MPLS. Se a bandeira BoS não for vista no pacote, apenas os rótulos MPLS são usados para hashing.

Tabela 6: Campos de hashing MPLS

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

MAC de origem

Χ

Χ

Χ

Χ

Χ

MAC de destino

Χ

Χ

Χ

Χ

Χ

EtherType

Χ

Χ

Χ

Χ

Χ

VLAN ID

Χ

Χ

Χ

Χ

Χ

IP de origem

IP de destino

Protocolo (para pacotes IPv4)

Χ

Χ

Χ

Χ

Χ

Próximo cabeçalho (para pacotes IPv6)

Χ

Χ

Χ

Χ

Χ

Porta de origem de Camada 4

Χ

Χ

Χ

Χ

Χ

Porta de destino de Camada 4

Χ

Χ

Χ

Χ

Χ

Laboratório IPv6 Flow

Χ

Χ

Χ

Χ

Χ

Rótulo MPLS 0

Χ

Rótulo MPLS 1

Rótulo MPLS 2

Rótulo MPLS 3

X

X

X

X

ID da porta de entrada

(LSR e L2Circuit)

X

X

X

(LSR e L2Circuit)

(LSR e L2Circuit)

Hashing de pacote MAC-in-MAC

Os pacotes que usam o MAC-in-MAC EtherType são hashed pelo algoritmo de hashing usando o MAC de fonte de carga de Camada 2, MAC de destino de carga de Camada 2 e campos EtherType de carga de Camada 2. Veja a tabela 7.

O hashing usando os campos no pacote MAC-in-MAC EtherType é suportado pela primeira vez em switches EX4300 na versão 13.2X51-D20. O hashing usando os campos no MAC-in-MAC EtherType não é suportado em versões anteriores.

Os campos usados pelo algoritmo de hashing para hashing MAC-in-MAC não são configuráveis para o usuário.

  • ✓— O campo é usado pelo algoritmo de hashing, por padrão.

  • Χ — O campo não é usado pelo algoritmo de hashing, por padrão.

Tabela 7: Campos de hashing MAC-in-MAC

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

MAC de fonte de carga de Camada 2

MAC de destino de carga de camada 2

EtherType de carga de camada 2

VLAN externo de carga de camada 2

Χ

Χ

Χ

Χ

Hashing de cabeçalho de Camada 2

Os campos de cabeçalho de camada 2 são usados pelo algoritmo de hashing quando o EtherType de um pacote não é reconhecido como IP (IPv4 ou IPv6), MPLS ou MAC-in-MAC. Os campos de cabeçalho de Camada 2 também são usados para hashing de tráfego IPv4, IPv6 e MPLS em vez dos campos de carga quando o modo de hash é definido para cabeçalho de Camada 2.

  • ✓— O campo é usado pelo algoritmo de hashing, por padrão.

  • Χ — O campo não é usado pelo algoritmo de hashing, por padrão.

  • (configurável)— O campo pode ser configurado para ser usado ou não pelo algoritmo de hashing.

Tabela 8: Campos de hashing de cabeçalho de Camada 2

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

MAC de origem

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

MAC de destino

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

EtherType

(configurável)

(configurável)

(configurável)

(configurável)

(configurável)

VLAN ID

Χ

(configurável)

Χ

(configurável)

Χ

(configurável)

(configurável)

(configurável)

Parâmetros de hashing

A partir do Junos OS Release 19.1R1, na linha de switches QFX5000, você pode mudar parâmetros de hashing para os algoritmos existentes implementados. Você pode alterar o limite de pools de buffer compartilhados para partições de buffer de entrada e saída e fazer alterações na seleção de funções de hash, algoritmo de hash e outros parâmetros adicionais. Veja a configuração de outros parâmetros de hashing mais tarde neste documento.

Configuração dos campos no algoritmo usado para hash LAG Bundle e ECMP Traffic (Procedimento de CLI)

Os switches da Série EX e QFX da Juniper Networks usam um algoritmo de hashing para determinar como encaminhar o tráfego por um pacote de grupo de agregação de enlace (LAG) ou para o dispositivo de próximo salto quando o multicaminho de igual custo (ECMP) for ativado.

O algoritmo de hashing toma decisões de hashing com base em valores em vários campos de pacotes.. Você pode configurar alguns dos campos que são usados pelo algoritmo de hashing.

Configurar os campos usados pelo algoritmo de hashing é útil em cenários onde a maior parte do tráfego que entra no pacote é semelhante e o tráfego precisa ser gerenciado no pacote LAG. Por exemplo, se a única diferença nos pacotes de IP para todo o tráfego recebido for o endereço IP de origem e destino, você pode ajustar o algoritmo de hashing para tomar decisões de hashing de maneira mais eficiente, configurando o algoritmo para tomar decisões de hashing usando apenas esses campos.

Nota:

A configuração do modo hash não é compatível com switches QFX10002 e QFX10008.

Configurando o algoritmo de hashing para usar campos no cabeçalho de camada 2 para hashing

Para configurar o algoritmo de hashing para usar campos no cabeçalho de Camada 2 para hashing:

  1. Configure o modo hash para cabeçalho de Camada 2:

    O modo hash padrão é a carga de Camada 2. Portanto, essa etapa deve ser executada se você não tiver configurado anteriormente o modo hash.

  2. Configure os campos no cabeçalho de Camada 2 que o algoritmo de hashing usa para hashing:

    Por padrão, o algoritmo de hashing usa os valores nos campos de endereço MAC de destino, Ethertype e mac de origem no cabeçalho para hash tráfego no LAG. Você pode configurar o algoritmo de hashing para não usar os valores nesses campos configurando no-destination-mac-address, no-ether-typeou no-source-mac-address.

    Você também pode configurar o algoritmo de hashing para incluir o campo de ID VLAN no cabeçalho configurando a opção vlan-id .

    Se você quiser que o algoritmo de hashing não use o campo Ethertype para hashing:

Configurando o algoritmo de hashing para usar campos na carga de IP para hashing

Para configurar o algoritmo de hashing para usar campos na carga de IP para hashing:

  1. Configure o modo de hash para carga útil de Camada 2:

    A carga de IP não é verificada pelo algoritmo de hashing a menos que o modo hash seja definido para carga de Camada 2. O modo hash padrão é a carga de Camada 2.

  2. Configure os campos na carga de IP que o algoritmo de hashing usa para hashing:

    Por exemplo, se você quiser que o algoritmo de hash ignore a porta de destino de Camada 4, a porta de origem da Camada 4 e os campos de protocolo e, em vez disso, tenha tráfego hash baseado apenas nos endereços de origem e destino IPv4:

Configurar o algoritmo hashing para usar campos no payload IPv6 para hashing

Para configurar o algoritmo de hashing para usar campos na carga IPv6 para hashing:

  1. Configure o modo de hash para carga útil de Camada 2:

    A carga do IPv6 não é verificada pelo algoritmo de hashing a menos que o modo hash seja definido para carga de Camada 2. O modo hash padrão é a carga de Camada 2.

  2. Configure os campos na carga IPv6 que o algoritmo de hashing usa para hashing:

    Por exemplo, se você quiser que o algoritmo de hash ignore a porta de destino de Camada 4, a porta de origem da Camada 4 e os campos next header e, em vez disso, o tráfego de hash baseado apenas nos campos de endereço de destino IPv6 e IPv6:

Configuração de outros parâmetros de hashing

Para configurar parâmetros de hashing para tráfego ECMP ou LAG:

  1. Configure o parâmetro de pré-processamento:
  2. Configure o parâmetro de função:
  3. Configure o valor de compensação:
Tabela de histórico de lançamento
Lançamento
Descrição
19.3
Começando com o Junos OS Release 19.3 e posterior para MPC10E e MPC11E MPCs, você não pode aplicar filtros de firewall nos pacotes MicroBFD recebidos na Interface Ethernet agregada. Para MPC1E por meio do MPC9E, você pode aplicar filtros de firewall nos pacotes MicroBFD recebidos na Interface Ethernet agregada apenas se a Interface Ethernet agregada for configurada como uma Interface não registrada.
19.1R1
na linha de switches QFX5000, você pode mudar parâmetros de hashing para os algoritmos existentes implementados.
16.1
Começando com o Junos OS Release 16.1, você também pode configurar esse recurso em roteadores da série MX com endereço agregado de interface Ethernet do destino remoto como endereço vizinho.
16.1
Começando com a versão 16.1R2, o Junos OS verifica e valida o micro BFD local-address configurado contra a interface ou endereço IP de loopback antes que a configuração se comprometa.
14,1X53-D25
Começando no Junos OS Versão 14.1X53-D25, o viés de link local pode ser habilitado globalmente para todos os pacotes LAG em um Virtual Chassis ou VCF, ou individualmente por pacote LAG em um Virtual Chassis.
14.1
Começando com o Junos OS Release 14.1, especifique o vizinho em uma sessão de BFD. Em versões anteriores ao Junos OS Release 16.1, você deve configurar o endereço loopback do destino remoto como endereço vizinho.
13.3
Começando com o Junos OS Release 13.3, a IANA alocou 01-00-5E-90-00-01 como endereço MAC dedicado para micro BFD.