NESTA PÁGINA
A ID de um membro desconectado não está disponível para redesignação
Padrão de fábrica de carga não se compromete em um chassi virtual multiember
A ID do membro persiste quando um switch de membro é desconectado de um chassi virtual
Um switch de membro não está participando de um chassi virtual misto
As mudanças de configuração relacionadas à interface não são aplicadas após a mudança de switch
Resolução de problemas de um chassi virtual da Série EX
Este tópico descreve os seguintes problemas de solução de problemas para um Virtual Chassis:
A ID de um membro desconectado não está disponível para redesignação
Problema
Descrição
Você desconectou um switch do Virtual Chassis, mas a ID de membro do switch desconectado ainda está exibida na saída de status. Você não pode realocar a ID do membro para outro switch.
Solução
Quando você desconecta um membro de uma configuração do Virtual Chassis, o principal retém a ID do membro e a configuração do membro em seu banco de dados de configuração. A saída do show virtual-chassis comando continua a exibir a ID do membro desconectado com um status de NotPrsnt.
Se quiser desconectar permanentemente o switch de membro, você pode liberar a ID do membro usando o request virtual-chassis recycle comando. Isso também limpará a situação desse membro.
Padrão de fábrica de carga não se compromete em um chassi virtual multiember
Problema
Descrição
O load factory-default comando falha em um Virtual Chassis multimember.
Solução
O load factory-default comando não é suportado em uma configuração multiember virtual Chassis. Para obter informações sobre como reverter os switches no Virtual Chassis para configurações padrão de fábrica, veja Reverter para a configuração padrão de fábrica para o switch da Série EX.
A ID do membro persiste quando um switch de membro é desconectado de um chassi virtual
Problema
Descrição
As interfaces Gigabit Ethernet mantêm seus números de slot anteriores quando um switch de membro é desconectado do Virtual Chassis.
Solução
Se um switch tivesse sido conectado anteriormente como um membro de uma configuração do Virtual Chassis, ele retém a ID do membro que foi atribuído como membro dessa configuração mesmo depois de desconectado e operando como um switch autônomo. As interfaces que foram configuradas enquanto o switch era um membro da configuração do Virtual Chassis mantêm a ID do membro antigo como o primeiro dígito do nome da interface.
Por exemplo, se o switch fosse anteriormente membro 1, suas interfaces serão nomeadas ge-1/0/0 e assim por diante.
Para alterar a ID de membro do switch, para que sua ID de membro seja 0 e renomeie as interfaces do switch de acordo:
Para mudar a ID do membro para 0:
user@switch> request virtual-chassis renumber member-id 1 new-member-id 0
Renomear as interfaces para combinar com a nova ID de membro:
[edit virtual-chassis] user@switch# replace pattern ge-1/ with ge-0/
Um switch de membro não está participando de um chassi virtual misto
Problema
Descrição
Um switch de membro em um Virtual Chassis misto não está participando do Virtual Chassis. A show virtual-chassis saída indica que o status do switch de membro é Inactive ou NotPrsnt.
É mais provável que esse problema ocorra imediatamente após o cabo de um Virtual Chassis misto.
Solução
O modo Virtual Chassis no switch pode não ser definido para o mixed modo. Se o switch de membro for um switch EX4500 e for cabeado no Virtual Chassis por meio da porta dedicada do Virtual Chassis (VCP), o modo PIC também pode ser definido para Intraconnect virtual-chassis.
Para verificar o modo Virtual Chassis:
user@switch> show virtual-chassis mode fpc0: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc1: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc2: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc3: -------------------------------------------------------------------------- Mixed Mode: Enabled fpc4: -------------------------------------------------------------------------- Mixed Mode: Disabled fpc5: -------------------------------------------------------------------------- Mixed Mode: Enabled
Para alterar o modo Virtual Chassis em um switch de membro (neste caso, ID 4 do membro) para o mixed modo:
user@switch> request virtual-chassis mode mixed member 4
(somente com switch EX4500) Para verificar o modo PIC:
user@switch> show chassis pic-mode
fpc0:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc1:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc2:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc3:
--------------------------------------------------------------------------
Pic Mode: Not-Applicable
fpc4:
--------------------------------------------------------------------------
Pic Mode: PIC 3: Intraconnect
fpc5:
--------------------------------------------------------------------------
Pic Mode: PIC 3: virtual-chassis
Alterar o modo PIC em um switch EX4500 para virtual-chassis modo (neste caso, ID 4 do membro):
user@switch> request chassis pic-mode virtual-chassis member 4
O switch de membro deve ser reiniciado para o modo Virtual Chassis ou mudança de configuração do modo PIC para fazer efeito. Para reiniciar o switch de membro (neste caso, iD 4 do membro):
user@switch> request system reboot member 4
Looping de tráfego desconhecido ocorre após configurar uma porta de uplink como um VCP redundante com um VCP dedicado
Problema
Descrição
Em um Virtual Chassis composto por switches EX4200, EX4500 ou EX4550, você observa loops irrecuperáveis de tráfego unicast ou multicast desconhecido após a inclusão de um link VCP redundante entre dois switches membros, quando os dois membros são conectados por um link VCP dedicado e o link redundante foi criado pela conversão de portas uplink para VCPs.
Esse comportamento pode ocorrer se o link VCP redundante for criado configurando as portas manualmente como VCPs ou se o recurso de conversão de VCP automático for invocado e converter as portas em VCPs automaticamente.
Solução
Reinicialize o Virtual Chassis para detectar adequadamente o VCP convertido como um link redundante com o link de VCP dedicado.
Após a conversão de uma porta de rede para um VCP, a tabela de filtro de saída não é atualizada e o VCP redundante permanece habilitado para encaminhamento, o que causa o comportamento de looping. O processo de reinicialização detecta a porta convertida como UM VCP e a traz como desabilitada para encaminhamento.
Como resultado, não recomendamos conectar portas VCP de uplink convertidas redundantes entre membros já conectados por VCPs dedicados em um Virtual Chassis ativo; em vez disso, planeje adicionar conexões VCP redundantes de uplink durante uma janela de manutenção que pode incluir um ciclo de reinicialização do Virtual Chassis. Essa recomendação também se aplica ao adicionar um novo membro a um Virtual Chassis ativo existente, onde você está adicionando links VCP redundantes entre o novo membro e um de seus vizinhos que misturam VCPs dedicados e VCPs de uplink convertidos.
As mudanças de configuração relacionadas à interface não são aplicadas após a mudança de switch
Problema
Descrição
Após um switchover gracioso do mecanismo de roteamento, a operação de confirmação para mudanças de configuração relacionadas à interface é bem sucedida, mas as mudanças de configuração não são aplicadas. Nenhuma mensagem de erro é gerada como parte da operação de confirmação.
Solução
Quando uma nova interface de membro é adicionada a um pacote Ethernet agregado, a validação pode falhar em caso de uma incompatibilidade de velocidade entre o pacote e a nova interface de membro. Após uma troca de mecanismo de roteamento graciosa, o processo de DCD sai na startup devido à validação falha. Nenhuma mudança de configuração relacionada à interface não é aplicada a partir de então.
Verifique se há mensagens de erro relacionadas à incompatibilidade de velocidade entre o pacote Ethernet agregado e a nova interface de membro. Se esses erros ocorrerem durante a inicialização de DCD, então o processo de DCD sai.
Para corrigir isso:
Remova a interface de membro do pacote Ethernet agregado e comprometa a configuração.
Reinicie o processo de DCD usando o
restart interface-controlcomando.Verifique se o processo de DCD está sendo executado.