EPG and ESG, from security filtering perspective

[SIMMN]

Here is a simple scenario to show the questions I would like to get some clarification regarding EPG and ESG.

I currently have 3 EPGs for VLAN 10, 20 and 30. intra-EPG isolation is not enabled. Each has a number of workloads/endpoints included and unique BD associated under single VRF. The BDs have the default gateway addresses for the VLANs. vzAny is used under the VRF.

I plan to create two ESGs and would use IP tag and VM tag to include only:

• Workloads A & B from EPG/VLAN 10 for ESG1
• Workload AA from EPG/VLAN 20 for ESG2

With this ESG setup, I want to create specific contracts/filters to:

• Allow workload A communication with workload AA for SSH
• Deny workload B communication with workload AA for SSH

Now the question is, with the existing vzAny, will workloads under the same EPG still be able to communicate with each other, whether it is included as part of ESG or not? Will inter-EPG communication be still allowed? Initially I am quite positive but after reading the ESG design guide, linked below, I am not too sure anymore...

Referencing following from the ESG design guide:

Q.    Can I configure contracts between ESGs and EPGs?

A.    No. When using ESGs, all security should be handled in ESGs, and EPGs should be used only for network constructs such as VLAN. When migrating EPGs to ESGs, EPG selectors can be used. EPG selectors enable you to inherit contracts from matched EPGs to the ESG such that communications between the matched EPGs that migrated to the ESG and other EPGs that have yet to migrate to ESGs are allowed during the migration phase.

Will this apply to vzAny OR only to specific contracts? Or it requires me to have all the EPGs mapped into ESGs in order to utilize ESG feature?

https://www.cisco.com/c/en/us/td/docs/dcn/whitepapers/cisco-aci-esg-design-guide.html

[AshSe]

Hello @SIMMN kindly share the logical diagram (mentioning Tenant, VRF, BD, AP, and EPGs) for better clarity and appropriate solution.

Please check the below diagram and confirm if this what you were talking about:

[SIMMN]

Thanks for the diagram and yes, that is what I want to accomplish. But the sametime maintain the inter-workload communication within EPG as well as between EPGs when source/destination are not workload A, B or AA.

[AshSe · Accepted solution]

With the logical connectivity diagram cleared, Let's address your specific questions regarding the behavior of workloads under the same EPG and inter-EPG communication with the existing vzAny configuration.

Here are the answers to your questions:

Q. 1) With the existing vzAny, will workloads under the same EPG still be able to communicate with each other, whether it is included as part of ESG or not? 

1. Intra-EPG Communication with Existing vzAny:

1. Intra-EPG Communication: Workloads within the same EPG will still be able to communicate with each other by default, as intra-EPG isolation is not enabled. This behavior is independent of whether the workloads are included as part of an ESG or not.
   1. Reason: Intra-EPG communication is controlled by the EPG configuration itself. Since intra-EPG isolation is not enabled, all endpoints within the same EPG can communicate freely.
   2. Impact of ESGs: The creation of ESGs does not inherently change the intra-EPG communication behavior. ESGs are used to apply specific security policies and contracts, but they do not override the default intra-EPG communication settings unless specific contracts are applied to restrict it.

   Q.2) Will inter-EPG communication be still allowed?

2. Inter-EPG Communication with Existing vzAny:

1. Inter-EPG Communication: By default, vzAny allows communication between all EPGs within the same VRF unless explicitly denied by contracts.
   1. Reason: vzAny acts as a catch-all contract that permits communication between all EPGs in the VRF. This means that, unless you create specific contracts to deny or restrict communication, EPGs will be able to communicate with each other.
   2. Impact of ESGs and Contracts: You can use ESGs and specific contracts to control and restrict inter-EPG communication. For example, you can create contracts to allow or deny specific types of traffic (e.g., SSH) between specific workloads in different EPGs.

Summary:

1. Intra-EPG Communication: Workloads under the same EPG will still be able to communicate with each other, whether they are included as part of an ESG or not, as long as intra-EPG isolation is not enabled.
2. Inter-EPG Communication: Inter-EPG communication will still be allowed by default with vzAny, unless you create specific contracts to restrict or deny communication between EPGs.

By leveraging ESGs and contracts, you can fine-tune the communication policies to meet your specific requirements while maintaining the default behavior for intra-EPG and inter-EPG communication where applicable.

Best Wishes!!!

AshSe

Please rate this post if it was helpful; your feedback is appreciated!

[SIMMN]

Thanks for the information and it does make sense. I would be running the test to validate in the fabric.