We’ve learned about the ACI object model in reference to the Tenants. However, to apply an EPG to a port you need the Access Policy Model.

The access policy model consists of a few object in the model that in the end make up the configuration of the physical port on a switch.

This chapter will cover all the objects in the image above.

Vlan Pools

A vlan pool is a set of vlans that can be used at a later time in the policy. To be able to use a vlan on a physical port it must be defined in a vlan pool.

When you’re creating a vlan pool you have to define the type of allocation which is used by the vlan pool. There are two types:

• Static allocation
• Dynamic allocation

The difference between the two is the way the vlan is picked and used on a port. A vlan pool which is using static allocation requires the administrator to make a choice about which vlan will be used. This is used primarily to attach physical devices to the fabric. For example when you need to connect your fabric to a switch that is already using vlans that you have to match. You will need to configure the vlan encap manually to be sure they match.

On the other hand, the dynamic allocation means that ACI decides which vlan is used for a specific EPG. Most often you’ll see this when integrating with a hypervisor like VMware. In this case ACI defines the vlan that will be used (and will configure the portgroup on the hypervisor to use that specific vlan). This is ideal for situations in which you don’t care which vlan runs underneath the traffic, as long as it is mapped into the right EPG.

VXLAN Pools

For completeness, there are also VXLAN pools. You can use these to attach to devices that support VXLAN. This could be your hypervisor. Most fabrics (at least the ones I encounter) only use Vlan pools. Be aware that they exist and that you could use them if required.

Domains

Domains are used to map an EPG to a vlan pool. An EPG must be member of a domain, and the domain must reference a vlan pool. This makes it possible for an EPG to have a vlan encap.

There are several types of domains:

• Physical domains
• Virtual domains
• External Bridged domains
• External Routed domains (or L3 domains)
• Fibre Channel domains

Three of these will probably be the ones you’ll be working with most. These are the Physical, Virtual and L3 domains. The physical domain is used for all endpoints that are connected to the fabric. With endpoints I mean servers. If you connect a (non-fabric) switch to your fabric and you want to extend layer 2 to that switch you could use the external bridged domain, or you could use the physical domain and just create a layer 2 trunk. The last one is easier and is seen more often than the external bridged domain.

The virtual domain, or more accurately, the VMM domain is a special type of domain that attaches to a hypervisor. The VMM domain isn’t configured in the same place as the other domains, but can be found under the Virtual Networking header in the GUI.

The external routed domain is used to connect routers to the fabric. Within this domain protocols like OSPF and BGP can be used to exchange routes.

So now you have a vlan pool and a domain which can be used to map an EPG to a vlan. This must now be connected to a physical port. This mapping is done using Attachable Access Entity Profiles (AAEPs)

AAEP

The AAEP is another connector. It connects the domain (and thereby the vlan and the EPG) to the Policy Group which defines the policy on a physical port. When defining an AAEP you need to specify which domains are to be available to the AAEP. These domains (and their vlans) will be usable by the physical port.

Sometimes you need to configure a lot of EPGs on a lot of ports. Say for example you’re not doing any VMware integration, but you do need to have ESXi hosts connected to your fabric. The old way of doing this was to create trunk ports and trunk all the required vlans to the VMware host. In ACI you’d need to configure a static port to the ESXi host on all EPGs that need to be available on the ESXi host. If you’re not automating this, it could take a lot of work. Even with automation this might be a messy way to do this.

That’s why you can configure an EPG directly under the AAEP. This will cause every port that will be member of the same AAEP to automatically have all the EPGs defined at the AAEP level.

Leaf Policy Group

The Leaf Policy Group (or Spine Policy Group) is a group of policies (like the name implies). These policies define the operation of the physical interface. Think of stuff like the Speed of the interface, CDP settings, BPDU settings, LACP and more.

This is also the place where the AAEP is referenced. So the Leaf Policy Group takes care of attaching the vlan, domain and EPG to an interface through the AAEP.

The specific policies are interface policies which are configured beforehand.

You can reuse LPGs for multiple ports. However, when you reuse a (v)PC based LPG all ports that are assigned to the same LPG will become member of the same port channel. This implies that you need to define separate LPGs for each port channel you define.

Leaf Interface Profiles & Interface Selectors

Leaf Interface Profiles are the way the Policy Group is attached to a switch. Part of a Leaf Interface Profile is the Interface Selector. The Interface selector specifies the interfaces and attaches the policy to that specific interface. However, it does not specify which switch(es) those interfaces belong to.

You can have multiple interface selectors listed under a single LIP. It depends on the way you like to work how you’re going to use them.

• A LIP per switch
• A LIP per LPG

Personally I like to use a Leaf Interface Profile (and corresponding Interface Selector) per LPG. But you can use the same LIP to apply different LPG’s to ports on a switch, since the policy is applied on the Interface Selector level. The advantage of using a single LIP for all ports on a switch, regardless of the LPG they will belong to is that you can keep the mapping between the Leaf Interface Profiles and the switch profiles simple. You’ll only have as many LIPs as you have switches (plus probably one for vPC pairs). In larger fabrics this is probably the way to go.

The advantage of using a LIP per LPG is that you can use consistent naming to map LPGs to LIPs, making it easier to find the LIP where a LPG is attached to. However, if you have a lot of LPGs, this could cause long lists in the GUI. This way of working is (in my experience) better suited for automation when you’re working in large fabrics.

Switch Profiles

A switch profile is the mapping between the policy model and the actual physical switch. The switch profile maps the Leaf Interface Policy, containing the interface selectors to the physical switch. So, as soon as you apply a LIP onto a switch profile it will program the ports according to the LPG you defined.

Wrapping it all up together

So, we’ve just read that all these policies in the end configure a port with specific parameters. We’ve also read that the domain and the AAEP ensure that an EPG can be programmed onto a port. But how does the ACI fabric know which EPGs to put onto the port?

Several options exist. The most common ones are:

• Static configuration
• Dynamic configuration through VMM domains

Static configuration

As to static configuration. You as an administrator either configure static ports at the EPG level. You need to define which port (or portchannel) to use and which encap must be used. Encap in this context is usually a vlan tag, but could in theory also be a VXLAN or QinQ tag.

Another way is to attach an EPG directly onto the AAEP. This causes the EPG with the specified encap to be attached to all LPGs that are configured with this AAEP as described earlier.

Dynamic Configuration

The dynamic configuration based on VMM domains automatically created a port group in the virtual machine manager that corresponds to the EPG when the EPG is configured to be a member of the VMM domain.