Important concepts in ACI Physical/Access polices Concepts
I know Cisco ACI has been around for a long time. The first time I got into it was in 2021. It was not that hard to relate the legacy concepts with ACI but doing a job via CLI and doing it via GUI have a lot of differences. In this particular blog, I will discuss the key concepts without explaining the ACI core components like leaf switches, spine switches, and APIC. Cisco ACI is a policy-driven solution in which everything has an object assigned to it, and you need to connect all those dots to make your network work.
In a legacy network, we have devices like bare metal servers, L2 switches, L3 switches, routers, and firewalls. We connect the networks using different protocols to make our network work, but sometimes there are physical requirements that need to be fulfilled to get the required topology.
In Cisco ACI, we have all these kinds of devices, and they are connected to our fabric. However, in ACI, we have a term called "domains," which include four different types: Physical, L3 domain, external bridge domain, and VMM (Virtual Machine Manager). From the names, one can understand their use cases, but I will briefly go over each one.
Physical Domain: This domain contains devices that we want to connect as bare metal, which can include servers or any network devices. It doesn't matter if it's a switch or a server; it all depends on what you want to achieve.
L3 Domain: This includes devices that will build an L3 (routing) relationship with the fabric. We can use these to establish a routing protocol with a connected device, which could be a firewall, router, or L3 switch running static, BGP, or OSPF routing protocols.
External Bridge domain: As the name suggests, when we want to bridge or extend an L2 domain, we will use this connectivity with our end device. This can include an old legacy switch running an old workload that is still in the process of being migrated.
VMM: When we need to integrate our fabric with a virtualization solution like VMware or OpenStack, we use this domain. In this domain, hypervisors and the fabric will communicate to control the deployments.
I have explained the glue that connects the physical path (Fabric Access Policies) of ACI with the logical part (Tenants).
Now, the second dot in the ACI Fabric is VLAN Pools. This VLAN pool needs to be connected with domains to make it work. As I mentioned earlier, it's a policy-driven solution, and I will go step by step.
VLAN Pool: In Cisco ACI, we have simple VLAN pools and VxLAN pools. Right now, I am not going into the differences between the two and will just discuss the VLAN Pool.
We define the VLAN pool ranges for each of our domains, which we discussed earlier, and map this VLAN pool to each domain as per our requirements. One domain can have a single VLAN Pool, and a VLAN Pool can have multiple VLANs. We can add or remove VLANs as per our requirements; static and dynamic allocations can be done as needed.
AAEP: Attachable Access Entity Profile is a profile in ACI that connects physical interfaces with the VLAN or domains that we have created. It helps the APIC controller to push the required VLAN to the respective ports based on user requirements and planning. AAEP is always used in an Interface Policy Group (IPG), which we will discuss next.
Interface Policy Group: We all remember the old legacy configuration where we needed to define the configuration of interfaces with respect to speed, duplex, and other access-level configurations like enabling or disabling CDP, as well as configuring port channels. In Cisco ACI, we have policies for access level and port channels. We define all those policies and then group all the configurations into a single policy called an Interface Policy Group, which contains port-level configurations and also has AAEP attached to it. The MCP feature is also defined here, which allows ACI to automatically detect a loop using this feature. So, the IPG is used to link the interface-level access policies and AAEP into a single profile. IPG is also referred to as a Path in the logical part of ACI, making it a very important component if you are creating an IPG for a VPC.
Interface Profile/Selector: In Cisco ACI, we create an Interface Profile, which contains the number of interfaces, and the Interface Policy Group is attached to it. This Interface Profile actually connects the Interface Policy Group with the particular port. Hold your horses—we are just mapping the interface and Interface Policy Group; the switch still needs to come into the picture.
Switch Profile: In Cisco ACI, we have a Switch Profile for each leaf/node. We can create Switch Profiles for each switch separately, and for VPC peers, we can create a single profile containing both switches. It depends on how you plan it. For VPC, we have another concept of a protection group, which we will discuss in later blogs. We create a Switch Profile, and in that Switch Profile, we call the Interface Profile, which contains the port number and all configurations related to the port. All configurations are done on the physical level. You have successfully configured the switch as per your requirements, and now you need to move to the logical part of Cisco ACI, which is Tenant. Remember, as I mentioned earlier, Domains and IPG, which we defined here, will be used to glue the physical configuration with the logical.
That’s all for today. I will try to cover the logical part in the next blog. I have tried my best to explain the access policies in a very simple way.
Raja Shajeel Ahmad
Enterprise DC Engineer
Happy Learning
The limit is the sky.
Comments