Microsegmentation in Cisco ACI: uSeg EPGs, ESGs and Intra-EPG Isolation
Every ACI fabric starts life with good intentions: one EPG per application tier, contracts between them, whitelist everywhere. Then reality arrives. The payment servers get built in the same subnet as the ordinary web farm because re-addressing was out of scope, the auditor asks why a compromised web host could reach the cardholder database, and nobody wants to open a change to split a bridge domain on a Friday. That is the exact problem microsegmentation in ACI solves: you change which security group an endpoint belongs to without touching its VLAN, its subnet or its default gateway.
Why the EPG is not enough on its own
In ACI, policy is not enforced on VLANs or IP subnets. It is enforced on a class ID, the pcTag, which the leaf assigns to every endpoint it learns. Contracts are compiled into zoning rules that say "traffic from pcTag X to pcTag Y on these ports is permitted", and anything without a matching rule is dropped once the VRF is in enforced mode.
In a classic design the pcTag comes from the EPG, and the EPG is chosen by the encapsulation the packet arrives on: VLAN 110 on this port means EPG-WEB. That is simple and predictable, but it means every endpoint on the same encap shares one security identity. Two hosts in EPG-WEB can talk to each other freely, and both inherit every contract EPG-WEB consumes.
Microsegmentation breaks that link. The endpoint still arrives on the same encap and still lives in the same bridge domain, but the fabric classifies it into a different group based on an attribute of the endpoint itself, and that group carries its own pcTag and its own contracts. The topology at the top of this article shows the idea: four hosts in one EPG and one subnet, split into two security groups, and only one of those groups is allowed to reach the database.
Three tools, three different jobs
ACI gives you three mechanisms that all get called microsegmentation. They solve different problems, and mixing them up is the most common reason a design review goes in circles.
Intra-EPG isolation
This is the blunt instrument. Set Intra EPG Isolation to Enforced on an EPG and endpoints inside it can no longer talk to each other at all, while their contracts to other EPGs still work. It is ideal for a flat server VLAN where the hosts have no business talking sideways, such as a jump-host farm or backup clients. If you need some sideways traffic, an intra-EPG contract (available since APIC 4.0) lets you permit specific ports between members of the same EPG instead of all or nothing.
Microsegmented EPGs (uSeg EPGs)
A uSeg EPG is an EPG with attribute-based classification instead of encap-based classification. You define match criteria, such as an IP address or subnet, a MAC address, or for VMware integrations a VM name, guest OS, VM tag or custom attribute, and any endpoint from the base EPG that matches is reclassified into the uSeg EPG. The uSeg EPG must use the same bridge domain as the base EPG it pulls endpoints from.
This is still the tool of choice when your grouping logic lives in vCenter, for example "every VM whose name starts with PAY belongs in the PCI group", because the VM attributes come from the VMM integration.
Endpoint Security Groups (ESGs)
ESGs arrived in APIC 5.0 and are the direction Cisco has taken since. An ESG is a pure security construct: it has no bridge domain, no encap and no domain association. It is scoped to a VRF and classifies endpoints through selectors, such as an IP subnet selector, a tag selector or an EPG selector that pulls in a whole existing EPG. Because it is VRF-scoped, one ESG can gather endpoints from several bridge domains, which uSeg EPGs cannot do.
The practical consequence is that ESGs let you separate forwarding from security completely. EPGs and bridge domains describe how the network is built; ESGs describe who may talk to whom. For a new design on a current fabric, that separation is worth having.
What happens on the wire
The part people skip, and then regret, is how the leaf actually gets to see the traffic it is supposed to police.
On bare-metal endpoints and physical domains, classification happens on the ingress leaf, and IP or MAC based microsegmentation requires the newer leaf ASICs (the EX, FX and later generations). On a mixed fabric with older first-generation leaves still in service, check the hardware before you promise anything.
With a VMware distributed switch, two VMs on the same host and the same port group would normally switch locally inside the hypervisor and never touch the fabric. For uSeg EPGs to work, you enable Allow Micro-Segmentation when you associate the EPG with the VMM domain. APIC then pushes private VLANs to the distributed switch, which forces all VM traffic up to the leaf where the pcTag is applied and the zoning rules are enforced. The same private VLAN mechanism is what makes intra-EPG isolation work for VMs. If the upstream blade switch or fabric interconnect between the hypervisor and the leaf does not carry the secondary VLANs, you get endpoints that learn and then silently fail to talk.
Configuring an ESG split
The example below takes the four hosts from the topology at the top of this article. EPG-WEB sits in BD-WEB with subnet 192.0.2.0/24. The ordinary web servers use 192.0.2.0/28, the payment servers use 192.0.2.16/28, and the database tier lives in 198.51.100.0/24 in a separate bridge domain but the same VRF.
Create the ESGs with IP subnet selectors
Post this to the APIC REST API at /api/mo/uni/tn-DEMO/ap-SHOP.json to create the PCI group. The JSON is flat on purpose so it pastes cleanly into Postman or a Python script:
{"fvESg":{"attributes":{"name":"ESG-PCI"},"children":[{"fvRsScope":{"attributes":{"tnFvCtxName":"VRF-PROD"}}},{"fvEPSelector":{"attributes":{"matchExpression":"ip=='192.0.2.16/28'"}}},{"fvRsCons":{"attributes":{"tnVzBrCPName":"PCI-DB"}}}]}}
Repeat for ESG-WEB with the selector ip=='192.0.2.0/28' and without the PCI-DB contract, and create ESG-DB with a selector for 198.51.100.0/24 that provides PCI-DB. The contract itself is ordinary: one subject with a filter for TCP 5432, scoped to the VRF.
Keep the old EPG contracts in mind
ESG contracts work between ESGs and with L3Out external EPGs, not with regular application EPGs. When you migrate an existing application, plan the contract model in ESG terms from the start instead of trying to mix the two. The cleanest pattern is to build the ESGs, move contracts across during one change window, and leave the EPGs as pure forwarding constructs afterwards.
The uSeg EPG equivalent
If you are on an older release or you need VM attributes, the same split as a uSeg EPG looks like this, posted to the same application profile:
{"fvAEPg":{"attributes":{"name":"uSeg-PCI","isAttrBasedEPg":"yes"},"children":[{"fvRsBd":{"attributes":{"tnFvBDName":"BD-WEB"}}},{"fvCrtrn":{"attributes":{"name":"default","match":"any"},"children":[{"fvIpAttr":{"attributes":{"name":"pci-hosts","ip":"192.0.2.16/28"}}}]}},{"fvRsCons":{"attributes":{"tnVzBrCPName":"PCI-DB"}}}]}}
Remember to add the VMM or physical domain association as well, with Allow Micro-Segmentation enabled for a VMware distributed switch. A uSeg EPG with no domain has nowhere to deploy and nothing will be reclassified.
Verification
Do not trust the GUI tree view alone. The question you are answering is simple: which pcTag did the leaf give this endpoint, and do zoning rules exist for that pcTag.
Check the endpoint classification
On the leaf where the payment server is attached:
show system internal epm endpoint ip 192.0.2.21
Look at the sclass value. It should match the pcTag of ESG-PCI or uSeg-PCI, not the pcTag of the base EPG-WEB. You can confirm the group's pcTag on APIC:
moquery -c fvESg -f 'fv.ESg.name=="ESG-PCI"' | grep pcTag
If the endpoint still shows the base EPG's sclass, the selector did not match. Check for a typo in the subnet, a missing domain association on a uSeg EPG, or on older hardware, a leaf that cannot classify by IP at all.
Check the zoning rules
show zoning-rule scope 2654209
The scope is the VRF VNID, which you can read from the endpoint output above. You should see a permit rule between the ESG-PCI pcTag and the ESG-DB pcTag for the PCI-DB filter, and nothing between ESG-WEB and ESG-DB. On the leaf, the bundled script gives a friendlier view with names instead of numbers:
contract_parser.py --vrf DEMO:VRF-PROD
Watch the drops
show logging ip access-list internal packet-log deny
Try a connection from 192.0.2.11 to the database on TCP 5432. It should appear here as a deny, which is your proof that the web tier is now genuinely separated from the database even though it shares a subnet with the payment servers.
Mistakes that bite in production
The VRF is in unenforced mode
Microsegmentation only changes pcTags. If the VRF policy enforcement is set to Unenforced, every pcTag can talk to every other one and your carefully built groups do nothing. This is common on fabrics that were migrated from a legacy network-centric design and never flipped to enforced.
Preferred group quietly overrides the design
If the base EPG is a member of the VRF preferred group, its endpoints talk freely to other preferred group members without contracts. Reclassify a host into a uSeg EPG that is not in the preferred group and it suddenly loses connectivity it had yesterday. Decide on preferred group membership for each new group deliberately.
Private VLANs do not survive the path to the leaf
Blade chassis switches, UCS fabric interconnects and nested virtual switches all need to carry the primary and secondary VLANs that APIC allocates. The symptom is an endpoint that appears in the fabric and then drops everything, including ARP. Trace the VLANs hop by hop before blaming the contract.
Overlapping selectors nobody documented
Two groups that both match the same host force the fabric to apply precedence rules, and the outcome is rarely what the person who created the second group expected. Keep selectors non-overlapping, and if you cannot, write down which group is meant to win and verify it with the sclass check above.
The takeaway
Microsegmentation in ACI is about moving an endpoint's security identity away from its VLAN and subnet. Intra-EPG isolation stops sideways traffic inside a group, uSeg EPGs reclassify endpoints by IP, MAC or VM attributes within one bridge domain, and ESGs do the same job across a whole VRF while keeping security completely separate from forwarding. Whatever you pick, the proof is always the same: the sclass on the leaf and the zoning rules behind it.
For a lab exercise, take a single EPG with four endpoints in one subnet on the ACI simulator or the Cisco DevNet sandbox. Split them into two ESGs with IP subnet selectors, give only one group a contract to a database ESG, and then use the endpoint, zoning-rule and deny-log commands above to prove that the second group is blocked. Once that works, repeat the exercise with intra-EPG isolation enforced and watch what changes in the zoning rules.