Let’s open with a query: “How are you dealing with safety and segmentation necessities in your Cisco Utility Centric Infrastructure (ACI) cloth?”
I anticipate most solutions will relate to constructs of Endpoint Teams (EPGs), contracts and filters. These ideas are the foundations of ACI. However relating to any infrastructure capabilities, designs and clients’ necessities are continuously evolving, typically resulting in new segmentation challenges. That’s the reason I wish to introduce a comparatively latest, highly effective possibility referred to as Endpoint Safety Teams (ESGs). Though ESGs have been launched in Cisco ACI some time again (model 5.0(1) launched in Might 2020), there’s nonetheless ample alternative to unfold this performance to a broader viewers.
For many who haven’t explored the subject but, ESGs supply an alternate method of dealing with segmentation with the added flexibility of decoupling this from the sooner ideas of forwarding and safety related to Endpoint Teams. That is to say that ESGs deal with segmentation individually from the forwarding elements, permitting extra flexibility and chance with every.
EPG and ESG – Highlights and Variations
The simplest approach to handle endpoints with widespread safety necessities is to place them into teams and management communication between them. In ACI, these teams have been historically represented by EPGs. Contracts which can be hooked up to EPGs are used for controlling communication and different insurance policies between teams with totally different postures. Though EPG has been primarily offering community safety, it have to be married to a single bridge area. It is because EPGs outline each forwarding coverage and safety segmentation concurrently. This direct relationship between Bridge Area (BD) and an EPG prevents the opportunity of an EPG to span multiple bridge area. This design requirement could be alleviated by ESGs. With ESGs, networking (i.e., forwarding coverage) occurs on the EPG/BD degree, and safety enforcement is moved to the ESG degree.
Operationally, the ESG idea is much like, and extra easy than the unique EPG method. Identical to EPGs, communication is allowed amongst any endpoints inside the identical group, however within the case of ESGs, that is impartial of the subnet or BD they’re related to. For communication between totally different ESGs, we’d like contracts. That sounds acquainted, doesn’t it? ESGs use the identical contract constructs we have now been utilizing in ACI since inception.
So, what are the advantages of ESGs then? In a nutshell, the place EPGs are sure to a single BD, ESGs let you outline a safety coverage that spans throughout a number of BDs. That is to say you may group and apply coverage to any variety of endpoints throughout any variety of BDs underneath a given VRF. On the identical time, ESGs decouple the forwarding coverage, which lets you do issues like VRF route leaking in a way more easy and extra intuitive method.
ESG. A Easy Use Case Instance
To provide an instance of the place ESGs could possibly be helpful, take into account a brownfield ACI deployment that has been in operation for years. Over time issues are likely to develop organically. You may discover you’ve created increasingly more EPG/BD combos however later understand that many of those EPGs really share the identical safety profile. With EPGs, you’d be deploying and consuming extra contract sources to attain what you need, plus doubtlessly including to your administration burden with extra objects to regulate. With ESGs, now you can merely group all these brownfield EPGs and their endpoints and apply the widespread safety insurance policies solely as soon as. What’s necessary is you are able to do this with out altering something having to do with IP addressing or BD settings they’re utilizing to speak.
So how do I assign an endpoint to an ESG? You do that with a sequence of matching standards. Within the first launch of ESGs, you have been restricted within the sorts of matching standards. Ranging from ACI 5.2(1), we have now expanded matching standards to supply extra flexibility for endpoint classification and ease for the consumer. Amongst them: Tag Selectors (based mostly on MAC, IP, VM tag, subnet), entire EPG Selectors, and IP Subnet Selectors. All the main points about totally different selectors could be discovered right here: https://www.cisco.com/c/en/us/td/docs/dcn/aci/apic/6x/security-configuration/cisco-apic-security-configuration-guide-60x/endpoint-security-groups-60x.html.
EPG to ESG Migration Simplified
In case the place your infrastructure is diligently segmented with EPGs and contracts that mirror software tiers’ dependencies, ESGs are designed to let you migrate your coverage with just a bit effort.
The primary query that almost all most likely involves your thoughts is methods to obtain that? With the EPG Selector, one of many new strategies of classifying endpoints into ESGs, we allow a seamless migration to the brand new grouping idea by inheriting contracts from the EPG degree. That is a straightforward approach to shortly transfer all of your endpoints inside a number of EPGs into your new ESGs.
For a greater understanding, let’s consider the beneath instance. See Determine 1. Now we have a easy two EPGs setup that we’ll migrate to ESGs. At the moment, the communication between them is achieved with contract Ctr-1.
Excessive-level migration steps are as follows:
- Migrate EPG 1 to ESG 1
- Migrate EPG 2 to ESG 2
- Substitute the present contract with the one utilized between newly created ESGs.
Step one is to create a brand new ESG 1 the place EPG 1 is matched utilizing the EPG Selector. It signifies that all endpoints that belong to this EPG develop into a part of a newly created ESG abruptly. These endpoints nonetheless talk with the opposite EPG(s) due to an automated contract inheritance (Word: You can’t configure an express contract between ESG and EPG).
This state, depicted in Determine 2, is taken into account as an intermediate step of a migration, which the APIC experiences with F3602 fault till you migrate excellent EPG(s) and contracts. This fault is a method for us to encourage you to proceed with a migration course of so that each one safety configurations are maintained by ESGs. This may maintain the configuration and design easy and maintainable. Nevertheless, you do not need to do it abruptly. You may progress in keeping with your venture schedule.
As a subsequent step, with EPG Selector, you migrate EPG 2 to ESG 2, respectively. Remember that nothing stands in the way in which of inserting different EPGs into the identical ESG (even when these EPGs confer with totally different BDs). Communication between ESGs remains to be allowed with contract inheritance.
To finish the migration, as a ultimate step, configure a brand new contract with the identical filters as the unique one – Ctr-1-1. Assign one ESG as a supplier and the second as a client, which takes priority over contract inheritance. Lastly, take away the unique Ctr-1 contract between EPG 1 and EPG 2. This step is proven in Determine 3.
Straightforward Migration to ACI
The earlier instance is especially relevant when segmentation on the EPG degree is already utilized in keeping with the applying dependencies. Nevertheless, not everybody could understand that ESG additionally simplifies brownfield migrations from current environments to Cisco ACI.
A place to begin for a lot of new ACI clients is how EPG designs are applied. Sometimes, the most typical selection is to implement such that one subnet is mapped to 1 BD and one EPG to mirror previous VLAN-based segmentation designs (Determine 4). Thus far, shifting from such a state to a extra application-oriented method the place an software is damaged up into tiers based mostly on perform has not been trivial. It has typically been related to the necessity to switch some workloads between EPGs, or re-addressing servers/providers, which usually results in disruptions.
Introducing application-level segmentation in such a deployment mannequin is difficult until you utilize ESGs. So how do I make this migration from pure EPG to utilizing ESG? With the brand new selectors out there, you can begin very broadly after which, when prepared, start to outline extra element and coverage. It’s a multi-stage course of that also permits endpoints to speak with out disruption as we make the transition gracefully. Typically, the steps of this course of could be outlined as follows:
- Classify all endpoints into one “catch-all” ESG
- Outline new segmentation teams and seamlessly take out endpoints from “catch-all” ESG to newly created ESGs.
- Proceed till all endpoints are assigned to new safety teams.
In step one (Determine 5), you may allow free communication between EPGs, by classifying all of them utilizing EPG selectors and placing them (briefly) into one “catch-all” ESG. That is conceptually much like any “permit-all” options you could have used previous to ESGs (e.g. vzAny, Most well-liked Teams).
Within the second step (Determine 6), you may start to form and refine your safety coverage by seamlessly taking out endpoints from the catch-all ESG and placing them into different newly created ESGs that meet your safety coverage and desired consequence. For that, you should utilize different endpoint selector strategies out there – on this instance – tag selectors. Remember that there isn’t a want to alter any networking constructs associated to those endpoints. VLAN binding to interfaces with EPGs stays the identical. No want for re-addressing or shifting between BDs or EPGs.
As you proceed to refine your safety insurance policies, you’ll find yourself in a state the place all your endpoints at the moment are utilizing the ESG mannequin. As your knowledge middle cloth grows, you do not need to spend any time worrying about which EPG or which BD subnet is required as a result of ESG frees you of that tight coupling. As well as, you’ll achieve detailed visibility into endpoints which can be a part of an ESG that characterize a division (like IT or Gross sales within the above instance) or software suite. This makes administration, auditing, and different operational elements simpler.
Intuitive route-leaking
It’s effectively understood that getting Cisco ACI to interconnect two VRFs in the identical or totally different tenants is feasible with none exterior router. Nevertheless, two extra elements have to be ensured for one of these communication to occur. First is common routing reachability and the second is safety permission.
On this very weblog, I acknowledged that ESG decouples forwarding from safety coverage. That is additionally clearly seen when that you must configure inter-VRF connectivity. Consult with Determine 7 for high-level, intuitive configuration steps.
On the VRF degree, configure the subnet to be leaked and its destined VRF to ascertain routing reachability. A leaked subnet have to be equal to or be a subset of a BD subnet. Subsequent connect a contract between the ESGs in several VRFs to permit desired communication to occur. Lastly, you may put apart the necessity to configure subnets underneath the supplier EPG (as an alternative of underneath the BD solely), and make changes to outline the proper BD scope. These usually are not required anymore. The top result’s a a lot simpler approach to arrange route leaking with not one of the generally complicated and cumbersome steps that have been crucial utilizing the normal EPG method.
To discover extra particulars of this idea that the networking trade has dubbed “route leaking”, confer with the Endpoint Safety Teams chapter within the Cisco APIC Safety Configuration Information.
Abstract
Because of the idea of ESGs, the safety and segmentation capabilities of Cisco ACI grew to become extra versatile and highly effective. Notably utilizing ESGs within the migration path from a mannequin the place 1 EPG equals 1 BD, to a extra refined community coverage is one thing that appears to be typically missed.
Our work is just not but executed. We’ll proceed to allow new makes use of for ESG with new options. Essentially the most anticipated function that might be coming quickly is ESG help with Nexus Dashboard Orchestrator (NDO) for patrons who’ve chosen to deploy Multi-Web site throughout knowledge facilities and areas. Keep tuned!
Share: