What are the Endpoint Security Groups (ESGs) of ACI ?

On 18 mai 2020 by Benoit With 0 Comments - ACI, CISCO, Data Center

You should have noticed the release 5.0(1) of Cisco ACI last week, it introduces a few new features among which we can find the Endpoint Security Groups (ESGs).

As per the configuration guide of ACI 5.0(x), the Endpoint Security Groups (ESGs) are a new security component in ACI. It will not replace the endpoint groups (EPGs) which are already here to group a set of endpoints, but to add a new layer of segmentation.

EPGs are associated to a single bridge domain (BD) and used to define security zones within a BD. EPGs define both forwarding and security segmentation at the same time. The direct relationship between the BD and an EPG limits the possibility of an EPG to spanning more than one BD.This limitation of EPGs is resolved by using the new ESG constructs because it will allow the relationship between endpoints from multiple BD / EPGs (but limited to a single VRF).

The following diagram represents two ESGs (Front and Back) with all the other Tenant Objects. They are grouping endpoints from different EPGs, different BD but inside a single VRF.

How the ESGs can help ?

From an customer standpoint, I can see the interest as most of the companies are beginning their migrations from Legacy to ACI by moving their networks into a “Network Centric” model as it is easier than migrating application per application (it is almost impossible to find the detailed flows to be opened between every application tiers… ). With this network centric model, after the migration to ACI, every EPGs are binded to their respective Bridge Domains (BD) and it can limits the benefits of the “application profiles”, the micro-segmentation, L4-L7 service insertion between EPGs… and so on.

In these cases, the addition of an Endpoint Security Group (ESG) can help the companies to move towards an “Application Centric” model, instead of spending too much time to prepare a proper migration from a network centric to application centric model. This is why you should be interested in ESGs, I think they can save you some time :)

What about the contracts ?

The contract usage in the ESGs is the same as the EPGs.

Endpoints that belong to the same ESG can communicate without the need for a contract.
To enable communication between endpoints that belong to different ESGs, you need to configure contracts between the ESGs.

For the communication with devices outside of the Cisco ACI fabric, you need to configure a contract between the L3Out external EPG (l3extInstP) and the ESG. You can also use a Layer 4 to Layer 7 service graph in conjunction with a contract between the ESGs.

Note that the contracts between an EPG and an ESG are not supported.

At the time of this release, it is supported to apply a contract between:

ESG and ESG
ESG and L3Out EPG
ESG and inband-EPG
ESG and vzAny

Contracts between the ESGs and the EPGs (or uSeg EPGs) are not supported. When an endpoint in an ESG needs to communicate with other endpoints in the EPG, the other endpoints need to be migrated to the ESGs first.

Where are configured the ESGs ?

We can find the ESGs inside the Tenant tab > Application Profiles > Endpoint Security Groups (at the same place where you can also find the EPGs). Right click on the folder, create, and from here you go !

Note that the ESGs must be linked to a VRF (like de BDs)

We can also configure :

Intra-ESG isolation, Enforced of Unenforced depending on the behavior you want to have between your endpoints, do they need to communicate with or without contracts inside an ESG ?
Preferred group, for allowing two enforced ESGs to communicate without contract, same behavior as for the EPGs, if you don’t forget to enable the option inside the VRF.

Some limitations as well

The limitations that seemed important to me:

Contracts between ESGs and EPGs are not supported.
The ESG feature is not integrated with the Cisco ACI Multi-Site.
An ESG contract can be applied only for routed traffic with IP as the selector. The layer 2 traffic is not filtered !
To prevent Layer 2 traffic (that is, non-routed traffic) from bypassing ESG security when IP is used as the selector, enable an intra EPG contract with a permit-all rule, such as the common default contract, on all of the EPGs that provide VLAN-to-interface binding for the ESG endpoints. If all the endpoints in the EPGs are classified to ESGs, you can alternatively enable intra EPG isolation with proxy ARP on the EPGs instead of the intra EPG contract. If the EPG is used only for VMM DVS integration, you can alternately enable the Allow Micro-Segmentation option instead of the other two options mentioned above. Either feature forces all communication between ESG endpoints to go through Layer 3 routing.
Inter-VRF service graphs between ESGs are not supported.
Be careful of your hardware, as well, as only the EX and newer generation of leaf nodes are supported for ESG deployment.

All of them are listed here.

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.