Introdução
Este documento descreve o processo de eleição da função do Virtual PortChannel (vPC) nos switches da série Nexus.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- vPC em switches Nexus Series
- STP (Spanning Tree Protocol)
Componentes Utilizados
As informações neste documento são baseadas na plataforma do switch Nexus 9000 Series.
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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Tecnologia PortChannel Virtual
Os Virtual PortChannels (vPCs) permitem que os links fisicamente conectados a dois switches Cisco diferentes apareçam como um único PortChannel para um terceiro dispositivo. O terceiro dispositivo pode ser um switch, um servidor ou qualquer outro dispositivo de rede que suporte PortChannels IEEE 802.3ad. O vPC também permite a criação de PortChannels de Camada 2 que englobem dois switches. No momento, o vPC é implementado nas plataformas Cisco Nexus 9000, 7000, 5000 e 3000 Series (com ou sem extensores de estrutura Cisco Nexus 2000 Series).
Observação: os vPCs do software Cisco NX-OS e os Cisco Catalyst Virtual Switching Systems (VSS) são de tecnologias semelhantes. Para a tecnologia Cisco EtherChannel, o termo MCEC (Multi-chassis EtherChannel) se refere a qualquer tecnologia de forma intercambiável.
Função do vPC
Embora ambos os switches vPC apareçam como um único switch para um dispositivo downstream, entre eles, dois switches vPC têm funções de vPC claramente definidas: vPC primário e vPC secundário.
As funções do vPC não são preventivas, o que significa que um dispositivo pode ser configurado como vPC primário, mas operar como dispositivo de peer secundário do vPC. Isso pode acontecer neste cenário:
- Quando o dispositivo primário original falha, o dispositivo vPC secundário torna-se o novo dispositivo primário.
- Quando o sistema se recupera, o dispositivo primário anterior agora é o dispositivo secundário e vice-versa.
A função vPC define qual dos dois dispositivos pares do vPC processa BPDUs (Bridge Protocol Data Units) e responde a solicitações ARP (Address Resolution Protocol). A função vPC também define um conjunto de ações a serem tomadas pelo vPC primário e pelo vPC secundário em resposta à situação de link par do vPC inativo.
Prioridade de Função do vPC
Você também pode usar a prioridade de função no comando do modo de domínio vPC para influenciar o processo de Eleição do vPC. O intervalo de valores é de 1 a 65636, e o valor padrão é 32667. Um valor mais baixo significa que esse switch tem uma chance melhor de ser o vPC principal.
Quando você altera a prioridade dos dispositivos pares do vPC, isso pode fazer com que as interfaces da rede fiquem ativas e inativas. Se desejar configurar a prioridade de função novamente para tornar um dispositivo vPC o dispositivo primário, configure a prioridade de função no dispositivo vPC primário com um valor de prioridade mais baixo e no dispositivo vPC secundário com o valor mais alto. Em seguida, desligue o link de peer do vPC em ambos os dispositivos e insira o comando shutdown e, finalmente, reative o canal de porta em ambos os dispositivos e insira o comando no shutdown.
Mudança de função do vPC malsucedida
O recurso de alteração de função sem interrupções do vPC fornece uma estrutura para alternar funções do vPC entre pares do vPC sem afetar os fluxos de tráfego. A troca de funções do vPC é feita com base no valor de prioridade de função do dispositivo no domínio do vPC. Um dispositivo par vPC com prioridade de função mais baixa é selecionado como o dispositivo vPC principal quando o comando vpc role preempt é executado.
Consulte Cenário de caso de uso para alteração de função do vPC sem distúrbio para obter mais detalhes.
Comportamento de sistemas vPC quando um link par vPC é desativado
Quando o link peer-keepalive do vPC falha e o link peer-keepalive do vPC ainda está ativo, o dispositivo peer secundário do vPC executa estas operações:
- Suspende suas portas membro do vPC.
- Desliga a SVI associada à VLAN do vPC.
Esse comportamento protetor do vPC redireciona todo o tráfego de sul para norte para o dispositivo primário do vPC.
Observação: quando o link de peer do vPC está inoperante, ambos os dispositivos de peer do vPC não podem mais sincronizar entre si, portanto, o mecanismo de proteção projetado leva ao isolamento de um dos dispositivos de peer (na ocorrência, o dispositivo de peer secundário) do caminho de dados.
Bit Sticky primário vPC
O bit Sticky Primário do vPC é um Mecanismo de Proteção Programada introduzido para evitar alterações de função desnecessárias (que poderiam causar interrupção na rede) quando o Switch Primário é recarregado inesperadamente. O Bit Sticky Primário do vPC permite que o switch ativo mantenha sua função PRIMARY quando um switch inoperante voltar a funcionar ou quando um switch isolado for integrado de volta ao domínio do VPC.
Alternando Bits Autoadesivos Primários do vPC:
1. O valor do Bit Sticky Primário do vPC é definido como VERDADEIRO neste cenário:
- O vPC primário atual é reinicializado e o switch habilitado para vPC altera sua função de vPC secundário para vPC operacional primário. O bit sticky não será definido se a função for alterada de vPC Operational Secondary para vPC Primary.
- Um switch habilitado para vPC altera sua função de Nenhum estabelecido para vPC Primário quando o temporizador de restauração de recarregamento (240 seg por padrão) expira.
2. O valor do Bit Sticky Primário do vPC é definido como FALSE nestes cenários:
- Um switch habilitado para vPC é reinicializado (Sticky Bit é definido como FALSE por padrão).
- A prioridade da função vPC é alterada ou inserida novamente.
O bit vPC Sticky Primary é informado na estrutura do componente de software do vPC Manager e pode ser verificado com esse comando do modo exec do NX-OS.
Campus_N7K2-VPC# show system internal vpcm info global | include ignore-case sticky
Sticky Primary: TRUE
Campus_N7K2-VPC#
Restauração de atraso do vPC
Depois que um dispositivo de peer vPC é recarregado e reativado, o protocolo de roteamento precisa de tempo para reconvergir. O segmento de recuperação de vPCs pode fazer um buraco negro no tráfego roteado desde o acesso à agregação/núcleo até que a conectividade de Camada 3 do uplink seja restabelecida.
O recurso Restauração de Atraso do vPC atrasa a ativação do segmento de vPC no dispositivo par do vPC que se recupera. A Restauração de Atraso do vPC permite que os protocolos de roteamento de Camada 3 converjam antes de permitirem qualquer tráfego no segmento do vPC. Isso resulta em uma restauração mais tranquila e perda de pacote nula durante a fase de recuperação (o tráfego ainda é desviado no dispositivo de peer vPC ativo). Esse recurso é habilitado por padrão com um temporizador padrão de restauração vPC de 30 segundos. O temporizador pode ser ajustado para uma linha de base de convergência específica da Camada 3 de 1 a 3600 segundos.
Vlan de Interface de Restauração de Atraso do vPC
Para atrasar a ativação das interfaces VLAN no dispositivo de peer vPC restaurado, use a opção interfaces-vlan do comando delay restore. Esse recurso é habilitado por padrão com um temporizador padrão de restauração do vPC de 10 segundos.
Restauração de atraso do vPC ao usar a configuração de SVI escalonada do 4000 SVI
Um novo comando delay restore interface-VLAN batch <1-4094> é introduzido para configurar o pacer para ativar a VLAN ou as interfaces de domínio de ponte em um lote de 200 SVIs de cada vez. O comando do temporizador de restauração de atraso do vPC delay restore <Timeout value> pode ser configurado para um valor maior que a soma de todos os temporizadores de lote configurados. Isso é feito para que o segmento VPC seja ativado somente depois que todos os SVIs tiverem sido completamente ativados para evitar qualquer buraco negro de tráfego.
Exemplo: 4000 Vlans, 200 lotes, atraso de 15 segundos
atraso na restauração > (4000/200)x 15
Processo de Eleição do vPC
Em um sistema vPC, um dispositivo par vPC é definido como vPC primário e um é definido como vPC secundário, com base nesses parâmetros e nessa ordem
- Bit sticky primário vPC definido como 0 ou 1.
- Prioridade de função do vPC definida pelo usuário (o software Cisco NX-OS usa o menor valor numérico para selecionar o dispositivo primário).
- Valor do endereço MAC do sistema (o software Cisco NX-OS usa o endereço MAC mais baixo para selecionar o dispositivo primário).
Este fluxograma (Imagem 1) resume as etapas pelas quais ambos os dispositivos pares do vPC passam durante o processo de eleição do switch principal do vPC.
- O primeiro parâmetro verificado entre dois dispositivos durante o processo de eleição primária do vPC é o bit adesivo primário do vPC. Se o dispositivo par vPC ganhar essa comparação, ele se tornará vPC primário, independentemente do valor de prioridade da função vPC ou dos endereços MAC do sistema que ambos os pares tiverem.
- Se ambos os switches pares do vPC tiverem o mesmo valor de bit de aderência, o processo de eleição prosseguirá para a próxima etapa para comparar a prioridade de função do vPC definida pelo usuário.
- Se ambas as funções do vPC estiverem configuradas com o mesmo valor, o processo de eleição prosseguirá para comparar os endereços MAC do sistema.
Imagem 1
Como mostrado na imagem, quando o switch vPC tem o bit adesivo primário vPC definido como 1 (condição TRUE) e seu peer com o bit adesivo definido como 0 (condição FALSE), o lado TRUE ganha a eleição e assume a função de vPC primário.
Bit Sticky do Peer 1 do vPC definido como 1 |
Bit Sticky de par 2 do vPC definido como 1 |
vPC Primário |
Falso (0) |
Falso (0) |
Gravata |
Verdadeiro (1) |
Falso (0) |
Peer 1 do vPC |
Falso (0) |
Verdadeiro (1) |
Peer 2 do vPC |
Verdadeiro (1) |
Verdadeiro (1) |
Gravata |
Cenário de recuperação do vPC
É importante entender o processo de Eleição do vPC e ele não pode ser subestimado, especialmente em cenários de recuperação do vPC.
A imagem 2 mostra uma configuração VPC típica, Nexus-01 é o VPC primário e Nexus-02 é o VPC secundário. Ambos têm seus bits sticky redefinidos como FALSE por padrão.
Imagem 2
Como mostrado nesta imagem, o Nexus-01 agora tem uma queda de energia e foi isolado da rede. O Nexus-02 se promoveu ao vPC Primary e definiu o vPC Sticky Bit como TRUE.
E o Nexus-02 agora se torna Operational Primary e o bit sticky agora está definido como TRUE.
Imagem 3
Como mostrado nesta imagem, quando o Nexus-01 volta a ficar on-line após a queda de energia ter sido restaurada, o Nexus-02 mantém a função de PRIMÁRIO operacional independentemente de sua prioridade de função (porque tem um bit sticky VERDADEIRO) e o Nexus-01 assume a função de SECUNDÁRIO quando fica on-line. Somente o Nexus-01 inicia o processo de inicialização do VPC, enquanto o Nexus-02 permanece como PRIMARY e encaminha o tráfego como de costume. Portanto, nenhuma interrupção de rede é vista.
Há dois temporizadores associados ao processo de inicialização do vPC no Nexus-01, que agora é o dispositivo secundário operacional do vPC:
- delay restore SVI (10 segundos por padrão)
- delay restore (30 segundos por padrão)
Como resultado, você pode esperar um tempo de recuperação de 40 segundos no Nexus-01 depois que o Nexus-01 for reintroduzido na rede como um dispositivo vPC secundário. No entanto, como o Nexus-02 assume a função principal, todo o tráfego passa agora pelo Nexus-01 como mencionado acima, nenhuma interrupção de rede é vista.
Imagem 4
Exemplo de interrupção de rede relevante para definir incorretamente bit sticky
A interrupção da rede é causada por um bit difícil definido INCORRETAMENTE quando um switch isolado (Nexus-02) é introduzido de volta no domínio VPC
No entanto, uma interrupção de rede pode ocorrer depois que um switch isolado é introduzido de volta ao domínio VPC se os bits não forem definidos corretamente em ambos os switches Nexus. Antes que um switch isolado seja introduzido de volta no domínio VPC, seu bit sticky deve ser definido como FALSE. (Para obter procedimentos para substituir um chassi N7K, consulte Procedimento de substituição de chassi do Nexus 7000.)
Como mostrado na imagem 5, o Nexus-01 é configurado com uma prioridade de função de VPC mais alta que o Nexus-02, e o Nexus-02 tem seu bit adesivo definido como TRUE. Os links E1/1 e E1/2 do Nexus-01 estão no estado forwarding, enquanto E1/1 e E1/2 estão em um estado shutdown.
Imagem 5
Quando o PKA e o Peer Link são restaurados, o Nexus-02 assume a função PRIMARY independentemente de sua prioridade de função (porque tem um bit sticky TRUE) e força o Nexus-01 a se tornar SECUNDÁRIO e o processo de inicialização do VPC começa no Nexus-01. Portanto, o link E1/1 e E1/2 do Nexus-01 é suspenso pelo VPC e fica on-line depois que os temporizadores de restauração do relé (40 segundos por padrão) expiram. Nesse caso, uma interrupção de rede de 40 segundos é vista depois que o PKA e o Peer Link são restaurados, como mostrado na imagem 6.
Imagem 6
Observação: quando um Nexus é reintroduzido no domínio vPC, você deve garantir que não haja alteração de função do vPC no dispositivo vPC ativo. Para evitar uma alteração de função do vPC quando os bits aderentes de ambos os switches são definidos com o mesmo valor, o dispositivo vPC ativo deve ter uma prioridade de função mais alta para que ele mantenha sua função PRIMARY. Consulte a Imagem 1 neste documento para obter mais informações sobre o processo de eleição de funções do VPC.