NESTA PÁGINA
Peer MC-LAG secundário com controle de status definido como standby torna-se inativo
Filtros de redirecionamento têm prioridade sobre os filtros definidos pelo usuário
A conexão ICCP pode levar até 60 segundos para se tornar ativa
O endereço MAC não é aprendido remotamente em uma VLAN padrão
As entradas de espionagem aprendidas em interfaces Ethernet agregadas multichassis não são removidas
O ICCP não aparece depois que você adiciona ou exclui uma chave de autenticação
Nenhuma verificação de confirmação é feita para interfaces ICL-PL
O tráfego multicast inunda a VLAN quando a interface ICL-PL fica cada vez mais inativa
As entradas de tabela ARP e MAC ficam fora de sincronia em uma configuração MC-LAG
Solução de problemas de agregação de enlace multichassis
Use as seguintes informações para solucionar problemas de configuração de agregação de enlace multichassis:
Os endereços MAC aprendidos em interfaces Ethernet agregadas multichassis não são removidos da tabela de endereços MAC
Problema
Descrição
Quando ambas as interfaces Ethernet agregadas multichassis em ambos os pares de grupo de agregação de enlace multichassis (MC-LAG) conectados estão inativas, os endereços MAC aprendidos nas interfaces Ethernet agregadas multichassis não são removidos da tabela de endereço MAC.
Por exemplo, se você desabilitar a interface Ethernet agregada multichassis (ae0) em ambos os peers MC-LAG emitindo o set interfaces ae0 disable comando e confirmar a configuração, a tabela MAC ainda mostrará os endereços MAC como sendo aprendidos nas interfaces Ethernet agregadas multichassis de ambos os peers MC-LAG.
user@switchA> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:00 Learn(L) 3:55 ae0.0 (MCAE) v10 00:00:5E:00:53:01 Learn(R) 0 xe-0/0/9.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:03 Static - Router
user@switchB> show ethernet-switching table Ethernet-switching table: 6 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v10 * Flood - All-members v10 00:00:5E:00:53:04 Learn(R) 0 ae0.0 (MCAE) v10 00:00:5E:00:53:05 Learn 40 xe-0/0/10.0 v20 * Flood - All-members v30 * Flood - All-members v30 00:00:5E:00:53:06 Static - Router
Solução
Esse é o comportamento esperado.
O PEER MC-LAG não entra no modo de espera
Problema
Descrição
Um peer de grupo de agregação de enlace multichassis (MC-LAG) não entra no modo de espera se o endereço IP do peer MC-LAG especificado na configuração do Inter-Chassis Control Protocol (ICCP) e o endereço IP especificado na configuração de proteção multichassis forem diferentes.
Solução
Para evitar a falha ao entrar no modo de espera, certifique-se de que o endereço IP do peer nas configurações do ICCP e o endereço IP nas configurações de proteção multichassis sejam os mesmos.
Peer MC-LAG secundário com controle de status definido como standby torna-se inativo
Problema
Descrição
Quando o link de proteção de enlace de controle de interchassis (ICL-PL) e as interfaces Ethernet agregadas de multichassis ficam inativas no peer de grupo de agregação de enlace multichassis (MC-LAG) primário, as interfaces Ethernet agregadas de multichassis do peer MC-LAG secundário com controle de status definido como standby tornam-se inativas em vez de ativas.
Solução
Esse é o comportamento esperado.
Filtros de redirecionamento têm prioridade sobre os filtros definidos pelo usuário
A saída do comando operacional está errada
Problema
Descrição
Depois de desativar o Inter-Chassis Control Protocol (ICCP), a saída do show iccp comando operacional ainda mostra daemons de cliente registrados, como mcsnoopd, lacpd e eswd.
Por exemplo:
user@switch> show iccp Client Application: MCSNOOPD Redundancy Group IDs Joined: None Client Application: lacpd Redundancy Group IDs Joined: 1 Client Application: eswd Redundancy Group IDs Joined: 1
A show iccp saída do comando sempre mostra os módulos registrados, independentemente de os pares ICCP estarem configurados ou não.
Solução
Esse é o comportamento esperado.
A conexão ICCP pode levar até 60 segundos para se tornar ativa
A idade do endereço MAC aprendida em uma interface Ethernet agregada multichassis é redefinida para zero
Problema
Descrição
Quando você ativa e desativa um link de proteção de enlace entre chassis (ICL-PL), a idade do endereço MAC aprendida na interface Ethernet agregada multichassis é redefinida para zero. As alterações na interface do próximo salto acionam atualizações de endereço MAC no hardware, que acionam atualizações antigas no Mecanismo de Encaminhamento de Pacotes. O resultado é que a idade do endereço MAC é atualizada para zero.
Por exemplo, o ICL-PL foi desativado e a saída do show ethernet-switching table comando mostra que os endereços MAC têm uma idade de 0.
user@switch> show ethernet-switching table Ethernet-switching table: 3 entries, 2 learned, 0 persistent entries VLAN MAC address Type Age Interfaces v100 * Flood - All-members v100 00:10:00:00:00:01 Learn(L) 0 ae0.0 (MCAE) v100 00:10:00:00:00:02 Learn(L) 0 ae0.0 (MCAE)
Solução
Esse é o comportamento esperado.
O endereço MAC não é aprendido remotamente em uma VLAN padrão
As entradas de espionagem aprendidas em interfaces Ethernet agregadas multichassis não são removidas
Problema
Descrição
Quando as interfaces Ethernet agregadas multichassis são configuradas em uma VLAN habilitada para espionagem multicast, as entradas de associação aprendidas nas interfaces Ethernet agregadas multichassis na VLAN não são apagadas quando as interfaces Ethernet agregadas multichassis caem. Isso é feito para acelerar o tempo de convergência quando as interfaces são ativadas ou sobem e descem.
Solução
Esse é o comportamento esperado.
O ICCP não aparece depois que você adiciona ou exclui uma chave de autenticação
Problema
Descrição
A conexão ICCP (Inter-Chassis Control Protocol) não é estabelecida quando você adiciona uma chave de autenticação e a exclui apenas no nível global do ICCP. No entanto, a autenticação funciona corretamente no nível do peer ICCP.
Solução
Exclua a configuração ICCP e adicione a configuração ICCP.
O status local está em espera quando deveria estar ativo
Problema
Descrição
Se a interface Ethernet agregada multichassis estiver inativa quando a máquina de estado estiver em um estado sincronizado, o status local do peer do grupo de agregação de enlace multichassis (MC-LAG) estará em espera. Se a interface Ethernet agregada multichassis ficar inativa depois que a máquina de estado estiver em um estado ativo, o status local permanecerá ativo e o estado local indicará que a interface está inativa.
Solução
Esse é o comportamento esperado.
Loop de pacotes no servidor quando o ICCP falha
Problema
Descrição
Quando você habilita a detecção de vivacidade de backup para um grupo de agregação de enlace multichassis (MC-LAG) e os pacotes de detecção de vivacidade de backup são perdidos devido a uma falha temporária no MC-LAG, ambos os pares no MC-LAG permanecem ativos. Se isso acontecer, ambos os pares MC-LAG enviam pacotes para o servidor conectado.
Solução
Esse é o comportamento esperado.
Ambos os pares MC-LAG usam o ID do sistema padrão após uma reinicialização ou uma alteração na configuração do ICCP
Problema
Descrição
Após uma reinicialização ou após uma nova configuração do Inter-Chassis Control Protocol (ICCP) ter sido confirmada e a conexão ICCP não se tornar ativa, as mensagens do Link Aggregation Control Protocol (LACP) transmitidas pelas interfaces Ethernet agregadas multichassis usam o ID padrão do sistema. O ID do sistema configurado é usado em vez do ID do sistema padrão somente depois que os pares MC-LAG são sincronizados entre si.
Solução
Esse é o comportamento esperado.
Nenhuma verificação de confirmação é feita para interfaces ICL-PL
Cenário de failover duplo
Problema
Descrição
Se os seguintes eventos acontecerem nesta ordem exata — o protocolo de controle entre chassis (ICCP) fica inativo e a interface Ethernet agregada multichassis no peer do grupo de agregação de enlace multichassis (MC-LAG) no modo ativo fica inativa — ocorre um failover duplo. Nesse cenário, o peer MC-LAG no modo standby não detecta o que acontece no peer MC-LAG ativo. O peer MC-LAG no modo de espera opera como se a interface Ethernet agregada multichassis no MC-LAG no modo ativo estivesse ativa e bloqueasse o tráfego do link de proteção de enlace (ICL-PL) entre chassis. O tráfego ICL-PL não é encaminhado.
Solução
Esse é o comportamento esperado.
O tráfego multicast inunda a VLAN quando a interface ICL-PL fica cada vez mais inativa
Problema
Descrição
Quando o link de proteção de enlace entre chassis (ICL-PL) fica inativo e ativado, o tráfego multicast é inundado para todas as interfaces no VLAN. O sinalizador Mecanismo de Encaminhamento de Pacotes Ip4McastFloodMode para a VLAN é alterado para MCAST_FLOOD_ALL. Esse problema ocorre apenas quando um grupo de agregação de enlace multichassis (MC-LAG) é configurado para a Camada 2.
Solução
Esse é o comportamento esperado.
O tráfego de Camada 3 enviado para o peer MC-LAG em standby não é redirecionado para o peer MC-LAG ativo
Problema
Descrição
Quando o Inter-chassis Control Protocol (ICCP) está inativo, o status de um peer MC-LAG remoto é desconhecido. Mesmo que o peer MC-LAG esteja configurado como standby, o tráfego não será redirecionado para esse peer porque se supõe que esse peer esteja inativo.
Solução
Esse é o comportamento esperado.
Interfaces Ethernet agregadas ficam inativas
Problema
Descrição
Quando uma interface Ethernet agregada multichassis é convertida em uma interface Ethernet agregada, ela retém algumas propriedades de interface Ethernet agregada multichassis. Por exemplo, a interface Ethernet agregada pode reter a chave administrativa da interface Ethernet agregada multichassis. Quando isso acontece, a interface Ethernet agregada fica inativa.
Solução
Reinicie o protocolo de controle de agregação de enlaces (LACP) no peer do grupo de agregação de enlaces multichassis (MC-LAG) que hospeda a interface Ethernet agregada para ativar a interface Ethernet agregada. Reiniciar o LACP remove as propriedades Ethernet agregadas multichassis da interface Ethernet agregada.
Flooding de tráfego upstream
Problema
Descrição
Quando a sincronização MAC está habilitada, o peer do grupo de agregação de enlace multichassis (MC-LAG) pode resolver entradas do Address Resolution Protocol (ARP) para a interface VLAN roteada (RVI) MC-LAG com qualquer um dos endereços MAC do peer MC-LAG. Se o tráfego downstream for enviado com um endereço MAC (MAC1), mas o peer tiver resolvido o endereço MAC com um endereço MAC diferente (MAC2), o endereço MAC2 pode não ser aprendido por nenhum dos switches da camada de acesso. A inundação do tráfego upstream para o endereço MAC2 pode ocorrer.
Solução
Certifique-se de que o tráfego downstream seja enviado dos peers MC-LAG periodicamente para evitar que os endereços MAC envelheçam.
As entradas de tabela ARP e MAC ficam fora de sincronia em uma configuração MC-LAG
Problema
Descrição
As tabelas de endereço MAC e ARP em uma configuração MC-LAG normalmente permanecem sincronizadas, mas as atualizações podem ser perdidas em situações extremas quando as atualizações de tabela estão acontecendo com muita frequência, como quando o flapping de link ocorre em um grupo MC-LAG.
Solução
Para evitar que as entradas ARP e MAC fiquem fora de sincronia em uma configuração MC-LAG, você pode configurar a opção arp-l2-validate na interface IRB do switch, da seguinte forma:
user@switch> set interfaces irb arp-l2-validate
A arp-l2-validate opção está disponível apenas nos switches da Série QFX.
Essa opção ativa a validação de entradas de tabela ARP e MAC, aplicando atualizações automaticamente se elas ficarem fora de sincronia. Talvez você queira habilitar essa opção como uma solução alternativa quando a rede estiver enfrentando outros problemas que também causam perda de sincronização ARP e MAC, mas desative-a durante a operação normal, pois essa opção pode afetar o desempenho nas configurações de escala.