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


Description (partial)

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.

The APIC DB is not clean before trigger id-import.
Bug details contain sensitive information and therefore require a 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.