We will start configuring the ACI fabric by creating some policies and a couple of tenants.

The ACI policy model is all about mapping application requirements to policies. We need tenant A to talk to an SQL server; we create a policy for that. We also need tenant A to talk the storage system, so we create a policy for that.

The APIC looks after the policies. When we make a change to an object within the fabric, it is the job of the APIC to apply this change to the policy model, which then makes the change to the affected endpoint. Such an example would be adding a new device to the fabric. Communication with the new device is prohibited until the policy model is updated to include the new device.

There are different policies, but they can be split into fairly distinct groups: those that govern the ACI fabric as a whole and those that are concerned with tenants.

All the policies are recorded in the MIT, or management information tree.

The MIT

In this chapter, we will start by creating...

In this recipe, we will create an NTP policy and assign it to our pod. NTP is a good place to start, as having a common and synced time source is critical for third-party authentication, such as LDAP and logging.

In this recipe, we will use the Quick Start menu to create an NTP policy, in which we will define our NTP servers. We will then create a POD policy and attach our NTP policy to it. Lastly, we'll create a POD profile, which calls the policy and applies it to our pod (our fabric).

We can assign pods to different profiles, and we can share policies between policy groups. So we may have one NTP policy but different SNMP policies for different pods:

The ACI fabric is very flexible in this respect.

How to do it...

1. From the Fabric menu, select Fabric Policies. From the Quick Start menu, select Create an NTP Policy:

 

2. A new window will pop up, and here we'll give our new policy a name and (optional) description and enable it. We can also define any authentication keys...

Access policies control the operation of switch ports, allowing connectivity to resources such as storage and compute, hypervisors, and layer 4 to layer 7 devices and protocols such as CDP, LLDP, and STP.

In this recipe, we are going to look at access policies and enable a preconfigured policy. We will then look at how to override this policy on a per-port basis, and also to override blocks of ports on a leaf.

How to do it...

1. From the Fabric menu, select Access Policies. Go to Interface Policies | Policies | CDP Interface. We can see that there is already a default policy:

2. The default is for CDP to be disabled. So switch the Admin State to Enabled, and click on SUBMIT in the bottom corner of the window:

3. This has enabled CDP globally, but what if we need to be a little more selective and disable on a single port?

 

4. Right-click on CDP Interface and select Create CDP Interface Policy.

 

5. Name the new policy CDP-OFF and set the state to Disabled.

6. Click on SUBMIT.
7. We now have two...

Tenants can be anything we want them to be (within reason): they can be a customer, a business unit within an enterprise, or a grouping of policies. The term 'tenant' is flexible, but each tenant is (by default) an isolated unit within the fabric. It is a logical container, one that can remain self-contained or, through contracts, share resources with other tenants.

The MIT for the tenant is as follows:

Tenant MIT

As you can see from the diagram, tenants contain some different components, including application profiles, bridge domains, VRFs (also referred to as contexts), and contracts. Some of these components, such as bridge domains, have their own components, such as subnets.

We have a couple of tenants preconfigured. These are the “common” tenant (common), which holds policies for shared services, such as firewalls and DNS settings; the “infrastructure” tenant (infra), which holds policies and VXLAN pools; and the “management” tenant (mgmt), which is used for out-of-band...

Bridge domains (BDs) provide layer 2 forwarding within the fabric as well as a layer 2 boundary. A BD must be linked to VRF and must have at least one subnet associated with it. BDs define the unique layer 2 MAC address space and also the flood domain (if flooding is enabled). 

Bridge domains can be public, private, or shared. Public bridge domains are where the subnet can be exported to a routed connection, whereas private ones apply only within the tenancy. Shared bridge domains can be exported to multiple VRFs within the same tenant, or across tenants when part of a shared service.

In this recipe, we will create a bridge domain and, along with it, define a VRF and a subnet for communication within the tenancy. 

How to do it...

1. We start by going into the tenant we created in the previous recipe and going to Networking | Bridge Domains.

2. Click on Actions, and then on Create Bridge Domain.

 

 

3. This launches a new window. Here, we name our bridge domain and assign a VRF...

So far, we have configured a tenant and created a bridge domain and context for it. A context, also known as a VRF (Virtual Routing and Forwarding) is a unique layer 3 forwarding domain. We can have multiple VRFs within a tenant, and VRFs can be associated with more than one bridge domain (but we cannot associate a bridge domain with more than one VRF).

In this recipe, we will create a second VRF under TenantA and a new bridge domain.

How to do it...

1. From the Networking menu under the tenant, select VRFs.

2. From the Actions menu, select Create VRF.

 

 

3. Give the VRF a name, and select any applicable options. Here, I have chosen to add a DNS label of VRF2. We can create a new bridge domain (this is the default option) at this stage as well.

 

 

4. Click on NEXT, select the Forwarding setting (such as Optimize), and change any defaults (which I have not changed here).

5. When you have done this, click on FINISH. The new VRF will be shown underneath the first VRF we created.

Application profiles (APs) are containers for the grouping of endpoint groups (EPGs). We can have more than one EPG with an AP. For example, an AP could group a web server with the backend database, with storage, and so on. EPGs are assigned to different bridge domains.

Application profiles define different aspects to the tenancy, governing security, quality of service (QoS), service-level agreements (SLAs), and layer 4 to layer 7 services.

APs are so intrinsically linked to EPGs (and contracts to a lesser extent) that it is harder to create these as separate tasks. For this reason, we will create them in one recipe. As you can see from the following screenshot, we are even guided in the Quick Start menu to create the EPGs and contacts when we create the application profile.

If we click on the grid-style icon next to the play button, the help window for the task will pop up.