Cisco Bug: CSCvt17173 - fabric id-recovery should abort id-import if policymgr DB is not clean
Feb 27, 2020
- Cisco Application Policy Infrastructure Controller (APIC)
Known Affected Releases
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)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases