The endpoint group (EPG) is the most important object in the policy model. 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 6. Endpoint Groups
An EPG is a managed
object that is a named logical entity that contains a collection of endpoints.
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. EPGs are fully
decoupled from the physical and logical topology. 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.
EPGs contain endpoints that have common policy requirements such as security, virtual machine mobility (VMM), QoS, or Layer 4 to Layer 7 services. Rather than configure and manage endpoints individually, they are placed in an EPG and are managed as a group.
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.
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
Regardless of how an
EPG is configured, EPG policies are applied to the endpoints they contain.
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
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
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.
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.
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.
Although encapsulation-based EPGs are commonly used, IP-based EPGs are suitable in networks where there is a need for large numbers of EPGs that cannot be supported by Longest Prefix Match (LPM) classification. IP-based EPGs do not require allocating a network/mask range for each EPG, unlike LPM classification. Also, a unique bridge domain is not required for each IP-based EPG. The configuration steps for an IP-based EPG are like those for configuring a virtual IP-based EPG that is used in the Cisco AVS vCenter configuration.
Observe the following guidelines and limitations of IP-based EPGs:
IP-based EPGs are supported starting with the APIC 1.1(2x) and ACI switch 11.1(2x) releases on the following Cisco Nexus N9K switches:
Switches with "E" on the end of the switch name, for example, N9K-C9372PX-E.
Switches with "EX" on the end of the switch name, for example, N9K-93108TC-EX.
The APIC raises a fault when you attempt to deploy IP-based EPGs on older switches that do not support them.
IP-based EPGs can be configured for specific IP addresses or subnets, but not IP address ranges.
IP-based EPGs are not supported in the following scenarios:
In combination with static EP configurations.
External, infrastructure tenant (infra) configurations will not be blocked, but they do not take effect, because there is no Layer 3 learning in this case.
In Layer 2-only bridge domains, IP-based EPG does not take effect, because there is no routed traffic in this case. If proxy ARP is enabled on Layer 3 bridge domains, the traffic is routed even if endpoints are in the same subnet. So IP-based EPG works in this case.
Configurations with a prefix that is used both for shared services and an IP-based EPG.