Nexus 7000 vPC Auto-Recovery Feature

一、应用场景

为什么需要vPC自动恢复？此vPC增强的主要原因有两个：

• 在数据中心停机或断电时，由Nexus 7000交换机组成的两个vPC对等体都处于关闭状态。有时，只能恢复其中一个对等体。由于其他Nexus 7000仍处于关闭状态，因此vPC对等链路和vPC对等保持连接链路也处于关闭状态。在此场景中，即使已打开的Nexus 7000也不会打开vPC。所有vPC配置都必须从该Nexus 7000的端口通道中删除，以使端口通道工作。当其他Nexus 7000打开时，您必须再次进行配置更改，以包括所有vPC的vPC配置。在版本5.0(2)及更高版本中，您可以在vPC域配置下配置reload restore命令来解决此问题。
• 由于某种原因，vPC对等链路断开。由于vPC对等保持连接仍处于打开状态，因此vPC辅助对等设备会由于双活检测而关闭其所有vPC成员端口。因此，所有流量都通过vPC主交换机。由于某种原因，vPC主交换机也关闭。此交换机问题会使流量黑洞，因为辅助对等设备上的vPC仍处于关闭状态，因为它在vPC主交换机关闭之前检测到双活检测。

在版本5.2(1)及更高版本中，vPC自动恢复功能合并了这两项增强功能。

二、配置自动恢复

在交换机S1上

S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc

在交换机S2上

S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2(config-vpc-domain)# auto-recovery reload-delay 300 将默认的240s调整为300s，可选配置，默认直接auto-recovery即可
S2# show vpc

三、自动恢复实际如何工作？

假设vPC自动恢复已配置并保存到交换机S1和S2的启动配置中。

1. 断电会同时关闭两个Nexus 7000 vPC对等体，并且只能打开一台交换机。
   

• S1和S2都打开。vPC已正确形成，开启对等链路和对等保持连接。
• S1和S2同时关闭电源。
• 现在，只有一台交换机能够通电。例如，S2是唯一打开电源的交换机。
• S2等待vPC自动恢复超时(默认值为240秒，可以使用auto-recovery reload-delay x 命令进行配置，其中x 为240-3600秒)，以验证vPC对等链路或对等保持连接状态是否已打开。如果其中任何链路处于打开状态（对等链路或对等保持连接状态），则不会触发自动恢复。
• 超时后，如果两个链路仍处于关闭状态（对等链路和对等保持连接状态），则vPC自动恢复将启用，S2将成为主要设备并启动，以便打开其本地vPC。由于没有对等体，因此会绕过一致性检查。
• 现在S1开启。此时，S2保留其主角色，S1承担辅助角色，执行一致性检查，并采取适当的操作。

2. vPC对等链路先关闭，然后主vPC对等链路关闭。

• S1和S2都打开，vPC正确形成，对等链路和对等保持连接打开。
• 由于某种原因，vPC对等链路首先断开。
• 由于vPC对等保持连接仍处于打开状态，因此它会检测双活检测。vPC辅助S2关闭其所有本地vPC。
• 现在vPC主S1关闭或重新加载。
• 此故障还会关闭vPC对等保持连接链路。
• S2等待三个连续的对等保持连接消息丢失。由于某种原因，vPC对等链路打开或S2收到对等保持连接消息，并且自动恢复不启用。
• 但是，如果对等链路保持关闭状态，并且三个连续的对等保持连接消息丢失，则vPC自动恢复将启用。
• S2承担主要角色并启用其绕过一致性检查的本地vPC。
• 当S1完成重新加载时，S2保留其主角色，S1成为次要角色，执行一致性检查，并采取适当的操作。

注意：如两个场景中所述，即使对等链路打开，解除vPC角色并自动恢复的交换机仍保持主要状态。另一对等体承担辅助角色并挂起其自己的vPC，直到完成一致性检查。

例如：

    S1断电。S2如预期成为运行主设备。对等链路和对等保持连接以及所有vPC链路都与S1断开连接。S1未通电。由于S1完全隔离，它会因自动恢复而打开vPC（尽管物理链路已断开），并充当主要角色。

    如果S1和S2之间连接了对等链路或对等保持连接，S1将保持主链路的角色，S2将成为次链路。此配置导致S2暂停其vPC，直到vPC对等链路和对等保持连接都打开并完成一致性检查。由于S2 vPC是辅助PC，并且S1物理链路关闭，因此此场景会导致流量黑洞。

三、是否启用vPC自动恢复

      vPC自动恢复功能可能会创建双主用场景，这种可能性很小。例如，如果首先丢失对等链路，然后丢失对等保持连接，则会出现双活场景。所以建议始终启用此特性；

Auto-recovery特性有2个增强：

• Primary down引起peer link down之后的恢复机制；
• 当2台设备都重启了，但最后只有一台正常启动；

机制1：此功能默认不启用；

• VPC peer link down，secondary shutdown all it's vpc member port；
• N7K1 down，7K2不再通过peer keep alive link收到7K1的消息；
• 3个连续的keepalive超时后，7K2将自己的role切换为operational primary，然后启用所有挂起的端口；

N7K(config-vpc-domain)# auto-recovery

机制2：默认不启用

• 2台设备同时重启，但只有7K2正常起来了，7K1没有起来；
• 当2台设备重启后，默认情况下所有的vpc member port都会被挂起直到vpc peer关系重新建立；
• 如果只有1台VPC peer起来，它的本地端口将保持挂起状态，不能使用；
• auto-recovery reload-delay feature允许设置一个计时器，在计时器超时后，单独设备可以启用它的本地端口，不再等另一台peer起来；

四、vpc reload restore and auto-recovery

vpc初始状态：

1. peer-link起来之前一定要把 peer-keepalive 同步成功，必须被对端识别。

peer-keepalive识别是peer-link起来的必要条件。

2. 所有vpc控制层面的报文 都是承载在CFS报文里面 通过peer-link传到对端。
3. 只有做完一致性检查之后，vpc才能起来

vpc reload restore：（只处理以下情况）

       如果在2台vpc重启的过程中，如果其中一台设备起不来，会导致整个vpc都起不来（keepalive同步不了，peer-link起不了，一致性做不了）。这样导致会下联业务中断。为了解决这种情况，可以启用vpc reload restore。

      启用了reload restore之后，会等240s，对端还是起不了的话，会把stp和lacp的active接管过来，保证数据的传输。

vpc auto-recovery：

      在nx-os 5.2.1之后用auto-recovery替代reload restore。reload restore只能处理以上情况， auto-recovery可以处理更多的情况。

处理的情景：

1. peer-link fail 紧接着 primary switch fail
2. 2个vpc 重启，只有一个起来。