Switches : Switches Cisco Nexus 7000 Series

Exemplo de configuração da característica da Auto-recuperação do vPC do nexo 7000

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como configurar a característica virtual da auto-recuperação de PortChannel (vPC) no nexo 7000.

Contribuído por Bhutta viral, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

Por que nós precisamos a Auo-recuperação do vPC?

Há dois motivos principais para este realce do vPC:

  • Em uma indisponibilidade ou em uma interrupção de energia do centro de dados, ambos os pares do vPC que são compreendidos de 7000 Switch do nexo estão. Ocasionalmente, somente um dos pares pode ser restaurado. Desde que o outro nexo 7000 é ainda fora, o par-link do vPC e o link do par-keepalive do vPC são igualmente fora. Nesta encenação, o vPC não se aproxima mesmo para o nexo 7000 que é já sobre. Todas as configurações do vPC têm que ser removidas do canal de porta naquela o nexo 7000 para fazer com que o canal de porta trabalhe. Quando o outro nexo 7000 se aproxima, você tem que outra vez fazer alterações de configuração para incluir a configuração do vPC para todos os vPCs. Na liberação 5.0(2) e mais atrasado, você pode configurar o comando restore do reload sob a configuração de domínio do vPC endereçar este problema.
  • Por qualquer motivo, o par-link do vPC apaga-se. Desde que o par-keepalive do vPC é ainda sobre, o dispositivo de peer secundário do vPC gerencie todas suas portas membro do vPC fora de devido à detecção duplo-ativa. Daqui todo o tráfego atravessa o interruptor preliminar do vPC. Por qualquer motivo, o interruptor preliminar do vPC igualmente apaga-se. Buracos negros deste problema do interruptor o tráfego desde que os vPCs no dispositivo de peer secundário são ainda fora porque detectou a detecção duplo-ativa antes que o interruptor preliminar do vPC se apagar.

Na liberação 5.2(1) e mais atrasado, a característica da auto-recuperação do vPC funde estes dois realces.

Configuração

A configuração da auto-recuperação do vPC é direta. Você precisa de configurar a auto-recuperação sob o domínio do vPC em ambos os pares do vPC.

Este é um exemplo de configuração:

No interruptor S1

S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
                (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                     : 1 
Peer status                       : peer adjacency formed ok    
vPC keep-alive status             : peer is alive
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : primary
Number of vPCs configured         : 5 
Peer Gateway                      : Enabled
Peer gateway excluded VLANs       : -
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id   Port   Status Active vlans  
--   ----   ------ --------------------------------------------------
1    Po1    up     1-112,114-120,800,810
                                
vPC status
-----------------------------------------------------------------------
id   Port   Status Consistency Reason                     Active vlans
--   ----   ------ ----------- ------                     ------------
10   Po40   up     success     success                    1-112,114-1
                                                          20,800,810    

No interruptor S2

S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
               (*) - local vPC is down, forwarding via vPC peer-link
vPC domain id                     : 1 
Peer status                       : peer adjacency formed ok    
vPC keep-alive status             : peer is alive               
Configuration consistency status  : success
Per-vlan consistency status       : success
Type-2 consistency status         : success
vPC role                          : secondary
Number of vPCs configured         : 5 
Peer Gateway                      : Enabled
Peer gateway excluded VLANs       : -
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Enabled (timeout = 240 seconds)

vPC Peer-link status
---------------------------------------------------------------------
id   Port   Status Active vlans  
--   ----   ------ --------------------------------------------------
1    Po1    up     1-112,114-120,800,810
                                 
vPC status ----------------------------------------------------------------------
id   Port   Status Consistency Reason                     Active vlans
--   ----   ------ ----------- ------                     ------------
40   Po40   up     success     success                    1-112,114-1
                                                          20,800,810    

Como a auto-recuperação trabalha realmente?

Esta seção discute cada comportamento mencionado na seção de informações de fundo separadamente. A suposição é que a auto-recuperação do vPC está configurada e salvar à configuração de inicialização no Switches S1 e no S2.

  1. Uma interrupção de energia cortou ambos os nexos 7000 pares do vPC simultaneamente e somente um interruptor pode aproximar-se.
    116187-configure-vPC-01.jpg
    • O S1 e o S2 estão ambos ligada. o vPC é formado corretamente com par-link e par-keepalive sobre.
    • S1 e sem energia S2 simultaneamente.
    • Agora somente um interruptor pode pôr sobre. Por exemplo, o S2 é o único interruptor que põe sobre.
    • O S2 espera o intervalo da auto-recuperação do vPC (o padrão é 240 segundos que podem ser configuradas com o comando x do reload-atraso da auto-recuperação, onde x é segundos do 240-3600) a fim verificar se potências do estado do par-link ou do par-keepalive do vPC sobre. Se qualquens um links estão ligada (estado do par-link ou do par-keepalive), a auto-recuperação não está provocada.
    • Após o intervalo, se ambos os links são ainda fora (estado do par-link assim como do par-keepalive), a auto-recuperação do vPC permite e o S2 torna-se preliminar e inicia-se a fim pôr sobre seu vPC local. Desde que não há nenhum par, a verificação consistente é contorneada.
    • Agora o S1 aproxima-se. Neste tempo, o S2 retém seu papel principal e o S1 toma um papel secundário, uma verificação consistente é executada, e as ações apropriadas são tomadas.
  2. sem energia do par-link do vPC primeiramente e então os sem energia preliminares do par do vPC.
    116187-configure-vPC-02.jpg
    • O S1 e o S2 estão ambos ligada e o vPC é formado corretamente com par-link e par-keepalive sobre.
    • Por qualquer motivo, o par-link do vPC apaga-se primeiramente.
    • Desde que o par-keepalive do vPC é ainda sobre, detecta a detecção duplo-ativa. O vPC S2 secundário desliga todos seus vPCs locais.
    • Agora o vPC S1 preliminar apaga-se ou reloads.
    • Esta indisponibilidade igualmente desliga o link do par-keepalive do vPC.
    • O S2 espera três mensagens consecutivas do par-keepalive a ser perdidas. Por qualquer motivo, ou o par-link do vPC aproxima-se ou o S2 recebe uma mensagem do par-keepalive, e a auto-recuperação não permite.
    • Contudo, se o par-link permanece fora e três mensagens consecutivas do par-keepalive estão perdidas, a auto-recuperação do vPC permite.
    • O S2 supõe o papel de preliminar e permite seu vPC local que contorneia a verificação consistente.
    • Quando o S1 termina o reload, o S2 retém seu papel de preliminar e o S1 torna-se secundário, uma verificação consistente é executada, e as ações apropriadas são tomadas.

Nota: Como explicado em ambas as encenações, o interruptor que os unsuspends seu papel do vPC com auto-recuperação do vPC continuam a permanecer preliminares mesmo depois que o par-link está ligada. O outro par toma o papel de secundário e suspende seu próprio vPC até que uma verificação consistente esteja completa.

Por exemplo:

O S1 é posto fora. O S2 transforma-se o preliminar operacional como esperado. o Par-link e par-keepalive e todos os links do vPC são desligados do S1. O S1 não é posto sobre. Desde que o S1 é isolado completamente, põe o vPC (embora os enlaces físicos estão para baixo) em devido à auto-recuperação e toma o papel de preliminar. Agora, se o par-link ou o par-keepalive são conectados entre o S1 e o S2, o S1 mantém o papel de preliminar e o S2 torna-se secundário. Esta configuração faz com que o S2 suspenda seu vPC até que o par-link e o par-keepalive do vPC estejam postos sobre e a verificação consistente estiver completa. Esta encenação causa o tráfego ao buraco negro desde que o vPC S2 é secundário e os enlaces físicos S1 estão.

Devo eu permitir a auto-recuperação do vPC?

É uma boa prática permitir a auto-recuperação em seu ambiente do vPC.

Há uma pequena possibilidade que a característica da auto-recuperação do vPC pôde criar uma encenação duplo-ativa. Por exemplo, se você perdeu primeiramente o par-link e então você perdeu o par-keepalive, você terá a encenação duplo-ativa.

Nesta situação, cada porta membro do vPC continua a anunciar o mesmo protocolo link aggregation control ID que fez antes da falha duplo-ativa.

Uma topologia do vPC protege intrinsecamente dos laços em caso das encenações duplo-ativas. Em um cenário do pior caso, há uns quadros duplicados. Apesar disto, como um mecanismo da laço-prevenção, cada do interruptor bridge protocol data units para a frente (BPDU) com o mesmo ID de bridge BPDU que antes da falha duplo-ativa do vPC.

Quando não intuitivo, é ainda possível e desejável continuar a enviar o tráfego da camada de acesso à camada da agregação sem gotas para fluxos de tráfego atuais, contanto que as tabelas do Address Resolution Protocol (ARP) são povoadas já em ambos os pares do 7000 Series do nexo de Cisco para todos os anfitriões necessários.

Se os endereços novos MAC precisam de ser aprendidos pela tabela ARP, as edições puderam elevarar. As edições elevaram porque a reação ARP do server pôde ser picada a um dispositivo do 7000 Series do nexo de Cisco e não ao outro, que faz impossível para que o tráfego flua corretamente.

Supõe, contudo, que antes da falha na situação apenas descrita, o tráfego esteve distribuído ingualmente aos dispositivos do 7000 Series do nexo de Cisco por um PortChannel correto e por uma configuração Multipath dos custos iguais (ECMP). Neste caso, o server-à-server e o tráfego do cliente-à-server continuam com a advertência que único-anexou os anfitriões conectados diretamente ao 7000 Series do nexo de Cisco não poderá se comunicar (para a falta do link do par). Também, os endereços novos MAC aprendidos em um 7000 Series de um nexo de Cisco não podem ser aprendidos no par, porque este causaria o tráfego de retorno que chega no dispositivo do 7000 Series do nexo de Cisco do par para inundar.

Consulte para paginar 19 do Software Cisco NX-OS PortChannel virtual: Conceitos fundamentais para mais informação.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshooting

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas



Document ID: 116187