Accepted Solutions
Endpoint Security Groups provide a flexible mechanism to group endpoints. It's similar in concept to an EPG. Where an EPG is constrained to including endpoints from a single Bridge Domain, the ESG can include endpoints from anywhere within a VRF. ESGs are a great way to improve your security posture when starting with a network-centric type of deployment design, and want to move more towards an more secure application policy model.
ESGs use selectors to define which endpoints belong to them. These can be based on:
1) Subnet (endpoints within the VRF are moved to the ESG based on an IP prefix match)
2) Explicit EPG Name (any endpoint assigned to a particular EPG is matched into the ESG
3) Tags (ACI objects can use REGEX patterns to match specific objects & values)
Just like EPGs, contracts are applied between ESGs to allow the endpoints within it to communicate.
One functional consideration of ESGs is that contracts must be applied between ESGs. You can't apply a contract between an ESG & EPG. The only exception is an L3Out EPG. A contract may be applied between ESG & L3Out EPGs.
This example shows what a configuration using EPG contracts would look like in comparison to using ESGs instead.
Robert
As of the latest version, policy tags are supported on the following ACI objects:
•fvEpMacTag (Endpoint MAC)
•fvEpIpTag (Endpoint IP)
•fvStCEp (silent-host)
•fvSubnet (BD Subnet)
•__vmm:vmname (VM Name)
A tag key-value pair is assigned to the above objects, then ESGs can leverage these policy tags as a matching mechanism. You might look at the Tag options and think - "fvSubnet tag?, can't we already use an IP Subnet Selector for ESG classification? Yes, you can however this introduces another level of abstraction. With an ESG IP Subnet selector you explicitly define subnet prefixes used to match endpoints into an ESG. With an Subnet tag - you are instead using a key and value combination assigned to subnets independently in order to create a match.
For example, let's imagine I had a bunch of subnets, some were production, and some where development. If I happen to know exactly which subnets were used for Production, sure I could just use an ESG selector and add those subnets. In the other case, perhaps I have thousands of small subnets, and I can't recall offhand which were Prod and which were used for Dev. With the fvSubnet policy tag, when I created the subnet, I could easily add a key "esg" and value "prod" to that object. Now when I go to create my ESGs, I can rely on these tags to filter the subnets of interest.
First I'll assign the policy tag key of "esg" (my choice, but can be anything) the Subnet, and the value of "prod_subnets" - which I will assign to any prod subnet object.
Next I will create an ESG called "prod_esg" with a Tag Selector using the same key and value pair. Notice you can use expressions like Contains, Equals and even Regex to give you max flexibility.
Lastly, I'll check the ESG operational tab to see if the endpoint I expect has been matched - which it has. Notice it also shows me the Base EPG in which the VM endpoint happens to be assigned to.
By now hopefully you're thinking - "Hey this sure looks alot of uSeg/Attributed based EPGs!?!" - and you'd be correct. The goal with ESGs is to provide a more flexible endpoint grouping method that isn't constrained by BD boundaries.
As with many things in ACI, there's many ways to accomplish your goal- the key is finding the feature/tool that does this in the easiest, and most simple way.
Regards,
Robert
