Guest

Preview Tool

Cisco Bug: CSCvt17173 - fabric id-recovery should abort id-import if policymgr DB is not clean

Last Modified

Feb 27, 2020

Products (1)

  • Cisco Application Policy Infrastructure Controller (APIC)

Known Affected Releases

3.2(9b)

Description (partial)

Symptom:
Fabric ID recovery include steps below in high level:

Step-1. Clean reload all APICs, Deploy configuration import policy, with import type = replace, start now = no
Step-2. Trigger fabric-recovery x (x=number of APICs)
Step-3. Trigger id-import y (y=number of pods)
Step-4. Trigger reconcile

Currently in Step-2, there is a validation from APIC1 if the cluster is clean. However there is no configuration validation in Step-3.  If someone by accident imported the configuration in step-1 by choosing start now = yes, we have no validation but unconditionally continue the id-import. With that, after step-2, the imported configurations would be replicated from APIC-1 to rest of the controllers. Continue Id-import at this stage will trigger all VIP pool corresponding tunnelCtrlPfxEntry removed from all switches, as a result, traffic behind of vPC will be dropped by the egress leaf in another pod, as they don't trust the source TEP address.

Conditions:
The APIC DB is not clean before trigger id-import.
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.