O objetivo deste documento é destacar alguns detalhes importantes sobre possíveis cenários envolvendo dois Nexus7000 implementando vPCs. Como sabemos, num ambiente plenamente funcional tanto o vPC peer-link quanto o keepalive link estão ativos. Neste caso, temos ambos Nexus7000 realizando o forwarding do tráfego e ambos os lados do port-channel permanecem ativos.
Entre os possíveis cenários de falha, podemos destacar:
1- Falha no vPC Peer link:
Este cenário considera que todos os links no vPC Peer link (número este que deve ser maior que 1) estão "down" mas o peer keep-alive está ativo (up). O Nexus7000 operando no status "vPC secondary" irá derrubar (down) as SVIs e os port-channels vPC. Este comportamento está documentado no seguinte documento:
Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_vPC.html#wp1823154
"If a failover occurs on the vPC peer link, the VLAN interfaces on the vPC peer devices are also affected. If a vPC peer link fails, the system brings down associated VLAN interfaces on the secondary vPC peer device.
Beginning with Cisco NX-OS Release 4.2(1), you can ensure that specified VLAN interfaces do not go down on the vPC secondary device when the vPC peer link fails. Use the dual-active exclude interface-vlan command to configure this feature."
Em outras palavras, de forma a impedir que o status das SVIs vá para "down" no Nexus "vPC secondary", o comando "dual-active exclude interface-vlan" pode ser usado para definir quais VLANs devem permaneçer ativas (up), mantendo assim a conectividade para quaisquer hosts single-homed que porventura estejam presentes.
Cisco Nexus 7000 Series NX-OS Interfaces Command Reference - dual-active exclude interface-vlan
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/interfaces/command/reference/if_commands.html#wp1337258
2- Falha no vPC Peer link e falha *posterior* no keep-alive link:
Este exemplo descreve o cenário em que inicialmente temos uma falha no Peer link, e posteriormente temos uma falha no keep-alive link (exemplo: com o reboot do chassi primário). Nesta situação, cabe fazer um distinção entre o comportamento esperado dependendo da versão de NX-OS em uso:
a) NX-OS anterior à 5.2: O switch com status "vPC secondary" não irá assumir como "vPC primary". Esta é considerada uma falha dupla, pela qual o switch em "vPC secondary" irá permanecer em status "down".
b) NX-OS igual ou posterior à 5.2: Após a introdução da versão 5.2 (que está disponível no CCO desde o fim de Julho/2011) o NX-OS possui um comando que nos permite mudar este comportamento de modo a lidar com cenários de falha dupla. Esta feature é chamada "vPC AutoRecovery", e permite ao Nexus lidar com este cenário onde a falha ocorre incialmente no vPC Peer link. Maiores informações podem ser encontradas no seguinte documento:
Cisco Nexus 7000 Series NX-OS Release Notes, Release 5.2 - vPC Autorecovery
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/release/notes/52_nx-os_release_note.html#wp389578
"Currently when a vPC peer-link goes down, a secondary switch takes down all its vPCs if it finds a peer-keep alive is working. If the peer-link does not recover, and the primary switch goes down and is unable to forward any traffic, then the access switches are disconnected.
Autorecovery is the ability to recover from this kind of failure scenario. Autorecovery enables the secondary vPC peer device to set its vPC member ports to an up state in that particular case."
No documento abaixo podem ser encontradas as versões mínimas de NX-OS recomendadas para novas implementações e deployments já existentes.
Minimum Recommended Cisco NX-OS Releases for Cisco Nexus 7000 Series Switches
http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/recommended_releases/recommended_nx-os_releases.html
