Cisco APIC Layer 2 Networking Configuration Guide, Release 6.2(x)

PDF

Cisco APIC Layer 2 Networking Configuration Guide, Release 6.2(x)

Endpoint groups

Updated: July 7, 2026

Want to summarize with AI?

Log in

Describes the most important object in the policy model and its relationship to other objects in the tenant.

An endpoint group (EPG) is a managed object that

  • contains a collection of endpoints with common policy requirements such as security, virtual machine mobility (VMM), QoS, or Layer 4 to Layer 7 services

  • is fully decoupled from the physical and logical topology, and

  • enables centralized policy management for groups of endpoints rather than individual endpoint configuration.

The following figure shows where application EPGs are located in the management information tree (MIT) and their relation to other objects in the tenant.

Figure 1. Endpoint groups


Endpoints are devices that are connected to the network directly or indirectly. They have an address (identity), a location, attributes (such as version or patch level), and can be physical or virtual. Knowing the address of an endpoint also enables access to all its other identity details. Endpoint examples include servers, virtual machines, network-attached storage, or clients on the Internet. Endpoint membership in an EPG can be dynamic or static.

The ACI fabric can contain the following types of EPGs:

  • Application endpoint group (fvAEPg)

  • Layer 2 external outside network instance endpoint group (l2extInstP)

  • Layer 3 external outside network instance endpoint group (l3extInstP)

  • Management endpoint groups for out-of-band (mgmtOoB) or in-band ( mgmtInB) access.

Policies apply to EPGs, never to individual endpoints. An EPG can be statically configured by an administrator in the APIC, or dynamically configured by an automated system such as vCenter or OpenStack.

Note
When an EPG uses a static binding path, the encapsulation VLAN associated with this EPG must be part of a static VLAN pool. For IPv4/IPv6 dual-stack configurations, the IP address property is contained in the fvStIp child property of the fvStCEp MO. Multiple fvStIp objects supporting IPv4 and IPv6 addresses can be added under one fvStCEp object. When upgrading ACI from IPv4-only firmware to versions of firmware that support IPv6, the existing IP property is copied to an fvStIp MO.

Regardless of how an EPG is configured, EPG policies are applied to the endpoints they contain.

Note

If a leaf switch is configured for static binding (leaf switches) under an EPG, the following restrictions apply:

  • The static binding cannot be overridden with a static path.

  • Interfaces in that switch cannot be used for routed external network (L3out) configurations.

  • Interfaces in that switch cannot be assigned IP addresses.

Static and dynamic EPG configuration examples

WAN router connectivity to the fabric is an example of a configuration that uses a static EPG. To configure WAN router connectivity to the fabric, an administrator configures an l3extInstP EPG that includes any endpoints within an associated WAN subnet. The fabric learns of the EPG endpoints through a discovery process as the endpoints progress through their connectivity life cycle. Upon learning of the endpoint, the fabric applies the l3extInstP EPG policies accordingly. For example, when a WAN connected client initiates a TCP session with a server within an application (fvAEPg) EPG, the l3extInstP EPG applies its policies to that client endpoint before the communication with the fvAEPg EPG web server begins. When the client server TCP session ends and communication between the client and server terminate, that endpoint no longer exists in the fabric.

Virtual machine management connectivity to VMware vCenter is an example of a configuration that uses a dynamic EPG. Once the virtual machine management domain is configured in the fabric, vCenter triggers the dynamic configuration of EPGs that enable virtual machine endpoints to start up, move, and shut down as needed.

ACI policy configuration in EPG shutdown

ACI policy configuration in EPG shutdown is a network management state that

  • removes ACI policy configuration related to the EPG from all switches

  • deletes the EPG from all switches while maintaining it in the ACI Data Store in inactive mode, and

  • prevents hosts attached to the EPG from sending or receiving traffic to/from the EPG.

In the APIC GUI you can check the box to remove the EPG from service.

Note

Hosts attached to a EPG in shutdown mode cannot send or receive to/from the EPG.

Access policies that automate assigning VLANs to EPGs

Access policies that automate assigning VLANs to EPGs are fabric access configurations that

  • enable fabric external-facing interfaces to connect to external devices such as virtual machine controllers, hypervisors, hosts, routers, or Fabric Extenders (FEXs)

  • configure port channels, virtual port channels, and protocols such as LLDP, CDP, or LACP

  • automate VLAN assignment from VLAN pools to reduce manual configuration overhead, and

  • deploy EPGs to all ports through the Attacheable Access Entity Profile (AEP).

While tenant network policies are configured separately from fabric access policies, tenant policies are not activated unless their underlying access policies are in place. Fabric access external-facing interfaces connect to external devices such as virtual machine controllers and hypervisors, hosts, routers, or Fabric Extenders (FEXs). Access policies enable an administrator to configure port channels and virtual port channels, protocols such as LLDP, CDP, or LACP, and features such as monitoring or diagnostics.

Figure 2. Association of endpoint groups with access policies

In the policy model, EPGs are tightly coupled with VLANs. For traffic to flow, an EPG must be deployed on a leaf port with a VLAN in a physical, VMM, L2out, L3out, or Fibre Channel domain. For more information, see Networking Domains.

In the policy model, the domain profile associated to the EPG contains the VLAN instance profile. The domain profile contains both the VLAN instance profile (VLAN pool) and the attacheable Access Entity Profile (AEP), which are associated directly with application EPGs. The AEP deploys the associated application EPGs to all the ports to which it is attached, and automates the task of assigning VLANs. While a large data center could easily have thousands of active virtual machines provisioned on hundreds of VLANs, the ACI fabric can automatically assign VLAN IDs from VLAN pools. This saves a tremendous amount of time, compared with trunking down VLANs in a traditional data center.

VLAN Guidelines

Use the following guidelines to configure the VLANs where EPG traffic will flow.

  • Multiple domains can share a VLAN pool, but a single domain can only use one VLAN pool.

  • To deploy multiple EPGs with same VLAN encapsulation on a single leaf switch, see Per port VLAN.

Per port VLAN

A per port VLAN is a VLAN configuration that

  • enables deploying multiple EPGs with the same VLAN encapsulation on a given leaf switch or FEX

  • allows multiple EPGs to use the same encapsulation number on a single leaf switch, and

  • requires EPGs to be associated with different bridge domains and deployed on different ports.

You can deploy multiple EPGs with the same VLAN encapsulation on a given leaf switch (or FEX), in the Per Port VLAN configuration, similar to the following diagram:

Guidelines for per-port VLAN configuration

To enable deploying multiple EPGs using the same encapsulation number, on a single leaf switch, these guidelines apply:

  • EPGs must be associated with different bridge domains.

  • EPGs must be deployed on different ports.

  • Both the port and EPG must be associated with the same domain that is associated with a VLAN pool that contains the VLAN number.

  • Ports must be configured with portLocal VLAN scope.

  • When an EPG has more than one physical domain with overlapping VLAN pools, avoid adding more than one domain to the AEP that is used to deploy the EPG on the ports. This avoids the risk of traffic forwarding issues.

  • When an EPG has only one physical domain with overlapping VLAN pool, you can associate multiple domains with single AEP.

For example, with Per Port VLAN for the EPGs deployed on ports 3 and 9 in the diagram above, both using VLAN-5, port 3 and EPG1 are associated with Dom1 (pool 1) and port 9 and EPG2 are associated with Dom2 (pool 2).

Traffic coming from port 3 is associated with EPG1, and traffic coming from port 9 is associated with EPG2.

This does not apply to ports configured for Layer 3 external outside connectivity.

Limitations for per-port VLAN configuration

To enable deploying multiple EPGs using the same encapsulation number, on a single leaf switch, these limitations apply:

  • Only ports that have the vlanScope set to portlocal allow allocation of separate (Port, VLAN) translation entries in both ingress and egress directions. For a given port with the vlanScope set to portGlobal (the default), each VLAN used by an EPG must be unique on a given leaf switch.

  • Per Port VLAN is not supported on interfaces configured with Multiple Spanning Tree (MST), which requires VLAN IDs to be unique on a single leaf switch, and the VLAN scope to be global.

  • To discern the same VLAN ID of different EPGs using the per-port VLAN feature, those VLAN IDs must be of different VLAN pools. Those VLANs (same ID, but for different EPGs) cannot be deployed on the same interface at the same time even with the per-port VLAN feature.

  • You cannot configure multiple interfaces with the same VLAN pool.

  • You can have a maximum of 7,331,840 per port VLANs across the APIC fabric as the range is between 8,192 and 7,340,032. Therefore, we recommend you limit the VLAN pool size to the number of VLANs that you need for deploying EPGs on a single leaf switch.

Reusing VLAN numbers previously used for epgs on the same leaf switch

If you have previously configured VLANs for EPGs that are deployed on a leaf switch port, and you want to reuse the same VLAN numbers for different EPGs on different ports on the same leaf switch, use a process, such as the following example, to set them up without disruption:

In this example, EPGs were previously deployed on a port associated with a domain including a VLAN pool with a range of 9-100. You want to configure EPGs using VLAN encapsulations from 9-20.

  1. Configure a new VLAN pool on a different port (with a range of, for example, 9-20).

  2. Configure a new physical domain that includes leaf ports that are connected to firewalls.

  3. Associate the physical domain to the VLAN pool you configured in step 1.

  4. Configure the VLAN Scope as portLocal for the leaf port.

  5. Associate the new EPGs (used by the firewall in this example) to the physical domain you created in step 2.

  6. Deploy the EPGs on the leaf ports.

Requirement: VLAN guidelines for epgs deployed on vpcs

Figure 3. Vlans for two legs of a vpc

When an EPG is deployed on a vPC, associate it with the same domain (with the same VLAN pool) that is assigned to the leaf switch ports on the two legs of the vPC.

In this diagram, EPG A is deployed on a vPC that is deployed on ports on Leaf switch 1 and Leaf switch 2. The two leaf switch ports and the EPG are all associated with the same domain, containing the same VLAN pool.