ACI Dynamic VLAN Pool Configuration for ESXi Trunks

The Core Constraint: Avoiding Static Port Bindings The question presents a scenario with 10 ESXi hosts, each having trunk ports carrying 200 VLANs. The critical constraint is to "streamline operations" and avoid configuring a static port binding for each EPG on each interface. Manually creating 200 static bindings per host would result in 2,000 configurations per host, which is operationally prohibitive.

Dynamic vs. Static Resolution In ACI, endpoint groups (EPGs) are typically bound to physical domains via Attachable Access Entity Profiles (AAEPs). However, standard static bindings require explicit mapping of specific interfaces to specific EPGs. To handle dynamic endpoint attachment without manual per-port configuration, ACI utilizes the Virtual Machine Manager (VMM) integration or Dynamic Port Groups.

Analyzing Option A Mapping an EPG to an AAEP in global policies is the standard method for attaching an EPG to a physical domain. However, this alone does not solve the scalability issue if the ports are not dynamically assigned to EPGs based on traffic or VM placement. If you simply map all EPGs to the AAEP, you still need to define where they go unless the infrastructure supports dynamic discovery. But wait, the prompt says "Another engineer already created the necessary access policies and 200 endpoint groups... with domain association." This implies the EPGs are already associated with the domain. The missing piece is how the ports are handled. If we use static bindings, we violate the requirement. Therefore, we need a mechanism that allows the fabric to dynamically associate the trunked VLANs with the correct EPGs without manual static port assignments.

**Re-evaluating the Options based on "Streamlining" and "No Static Ports" Option B suggests VMM integration and a dynamic VLAN pool. While VMM is great for VM-centric management, the question specifies ESXi hosts on trunk ports carrying 200 VLANs. This sounds more like a traditional data center network connectivity scenario rather than a pure vCenter-managed VM lifecycle scenario. Furthermore, a "dynamic virtual LAN pool" is not a standard ACI construct for mapping existing static VLANs to EPGs in this context.

Let's look closer at Option A. In many ACI contexts, "mapping each EPG to the attachable access entity profile" is the definition of associating an EPG with a Physical Domain. If the EPGs are already associated with the domain, why is this the answer? Perhaps the question implies that the previous step was incomplete. The comment states: "This is physical domain... Requirement is to avoid static EPG (C)." This suggests that by correctly applying the EPG to the AAEP (which is part of the domain policy), the system can handle the traffic. But does it avoid static ports?

Actually, there is a nuance here. If you have 200 VLANs on a trunk, and you want them mapped to 200 EPGs, you traditionally do this via static bindings. To avoid this, you might use Dynamic EPGs or L2Out. However, L2Out (Option D) is for external networks connecting to the fabric, not for internal ESXi host connectivity.

Let's reconsider the "Static Port" prohibition. In ACI, you can bind an EPG to a leaf interface statically. You can also use Dynamic Port Groups via VMM. But the question mentions "ESXi hosts" and "trunk port". If the ESXi hosts are managed by vCenter, VMM integration (Option B) is the standard way to dynamically map VLANs to EPGs as VMs move. However, the option says "add the virtual LANs to a dynamic virtual LAN pool". ACI has a feature called "Dynamic VLAN Pool" used in conjunction with VMM integration to automatically create EPG-Port bindings. When a VM is placed on a port group that maps to a specific VLAN, ACI dynamically creates the static binding between the leaf port and the EPG. This fulfills the requirement of establishing connectivity without manually configuring a static port in each EPG for each interface—the automation handles it.

Why is A wrong? Mapping EPGs to AAEPs is a prerequisite, but it doesn't inherently solve the "no static config" problem for 200 VLANs on a trunk unless combined with dynamic mechanisms. The comment argues A is correct because it's the "physical domain" setup. But the key is the dynamic aspect. Wait, let's look at the comment again: "This is physical domain, ESXi in text is to confuse so that takes out B." This comment is misleading. ESXi is relevant to VMM.

Let's look at the official behavior. To avoid static port bindings for multiple VLANs on a trunk, Cisco recommends using VMM Integration with a Dynamic VLAN Pool. The VMM integration allows ACI to learn endpoints and dynamically create the necessary port bindings when traffic is seen or VMs are powered on/moved. This eliminates the need for pre-provisioning static bindings for every single VLAN/Port combination.

Therefore, Option B is the technically correct action to streamline operations and avoid manual static configurations. The comment favoring A is likely incorrect or referring to a different interpretation. The mention of "dynamic virtual LAN pool" in Option B is the key ACI feature designed exactly for this purpose: automating the mapping of VLANs to EPGs on trunk ports without manual static entry.

Wait, I must double-check. Does ACI support "Dynamic VLAN Pool"? Yes, in the context of VMM integration, you can configure a VLAN pool that is dynamic, allowing the fabric to dynamically assign EPGs to ports based on the VLAN ID seen in traffic. This is the modern best practice for large-scale trunked environments.

However, some older interpretations might argue that simply associating the EPG with the AAEP (Option A) is sufficient if the switch side is configured correctly, but ACI requires explicit binding unless dynamic features are used. Given the emphasis on "streamline operations" and "without configuring a static port", Option B is the only one that introduces a dynamic automation element.

Let's re-read carefully. "Another engineer already created the necessary access policies and 200 endpoint groups (EPGs) with domain association." This means the EPGs are already linked to the Physical Domain (via AAEP). So Option A is effectively redundant or already done. The missing link is how the traffic gets mapped. That is where the Dynamic VLAN Pool comes in.

Thus, the correct answer is B.