Cisco Bug: CSCvv25887 - Port created via traffic w/o inventory blocks epp download
Oct 01, 2020
- Cisco Application Policy Infrastructure Controller (APIC)
Known Affected Releases
Symptom: - On AVE VM A's port is stuck in the WAIT_ATTACH_ACK for a long period of time (15 mins up to multiple hours) - The VM port is created/brought up due to dataplane traffic prior to inventory download from the attached ESXi host's Leafs - When another VM - VM B - with port is brought up on the same AVE VM/ESXi host in the same PortGroup ... its port will be stuck in a WAIT_EPP state because VM-A's port is still pending inventory download to the Leaf and onto the AVE - After a long time the inventory info for the ports is downloaded onto the Leafs and pushed to the AVE VM at which points the ports transition to a FWD state Conditions: Issue Is caused by the following sequence of events: 1. On AVE - VM port with MAC-A created/brought up via dataplane traffic. There is no EP inventory for MAC-A in Datapath Agent (DPA). 2. AVE sends PORT-ATTACH-REQ to Leaf with the download EPP (dldEpp) flag enabled for the PortGroup of the new VM port (step 1). 3. Leaf does not have inventory for MAC-A, thus responds with an PORT-ATTACH-RETRY message via OpFlex. The dldEpp request is ignored. 4. AVE re-sends PORT-ATTACH-REQ after a short wait. Leaf again sends PORT-ATTACH-RETRY msg via OpFlex. Steps 2-3 repeat multiple times... 5. During these retries, inventory for another EP with MAC-B is downloaded to AVE. MAC-B uses the same portgroup as MAC-A. 6. AVE brings up VM port with MAC-B. It sends PORT-ATTACH-REQ without the dldEpp flag since MAC-A already requested the same EPP. 7. Leaf sends PORT-ATTACH-ACK for MAC-B. AVE transitions VM port with MAC-B to a WAIT_EPP state. 8. VM port for MAC-B is stuck in a WAIT_EPP state since the Leaf still can't process the dldEpp request due to MAC-A not being in its inventory. 9. Eventually, inventory for MAC-A is downloaded to the Leaf and it processes the dldEpp request. 10. EPP is pushed to AVE and the VM port with MAC-A transitions to a forwarding state. Same happens to VM port with MAC-B after.
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