A national retailer added a VLAN to an ACI VLAN pool, but hosts on the leaf port still cannot use it. That pool is not referenced by the physical domain on the AAEP for the port. What should be fixed?
Select an answer to reveal the explanation.
Short Explanation
You can think of the VLAN pool as a crate of tags: the physical domain connects those tags to the access policy used by the port’s AAEP. Attach the pool to that domain so the leaf can use the VLAN; preferred group changes contract enforcement, not interface VLAN programming.
Full Explanation
ACI access policies deliver VLAN encapsulations to leaf ports through a chain: the VLAN pool is associated with a physical domain, the domain with an attachable access entity profile (AAEP), and the AAEP with the interface policy group on the port. A VLAN that exists only in a pool not referenced by the port’s physical domain is not made available on that leaf port. Associating the pool with the physical domain already used by the AAEP completes the relevant link in the chain. Clearing the spine COOP database does not fix this: COOP tracks endpoint location for fabric forwarding, not VLAN-pool associations. Enabling preferred group on the VRF changes contract enforcement among member EPGs; it does not program VLAN encapsulations on interfaces or replace the access policy. Creating a vPC peer-link between the leaves is also unrelated: a vPC peer-link is not the ACI mechanism for associating a VLAN pool with a leaf access port. Caveat: the EPG still needs a static path or VMM binding that selects the VLAN and port; associating the pool alone does not place the endpoint in the EPG. Practical check: verify that the pool, physical domain, AAEP, and interface policy group form the intended chain, then confirm the VLAN appears on the leaf interface.