Access policies: These policies control the operation of leaf switch
access ports, which provide fabric connectivity to resources such as
virtual machine hypervisors, compute devices, storage devices, and so
on. Several access policies come built in with the ACI fabric by default.
The fabric administrator can tweak these policies or create new ones, as
necessary.
Fabric policies: These policies control the operation of the switch
fabric ports. Configurations for time synchronization, routing
protocols, and domain name resolution are managed with these
policies.
VM domains: Virtual machine (VM) domains group virtual machine
controllers that require similar networking policy configurations. The
APIC communicates with the VM controller to push network
configurations all the way to the VM level.
Integration automation framework: The Layer 4 to Layer 7
service integration automation framework enables a system to respond
to services coming online or going offline.
AAA policies: Access, authentication, and accounting (AAA) policies
control user privileges, roles, and security domains for the ACI fabric.
The hierarchical policy model fits very well with the
REST API interface. As the ACI fabric performs its
functions, the API reads and writes to objects in the MIT.
The API resources represented by URLs map directly
into the distinguished names that identify objects in the
MIT.
Next, let’s explore the building blocks of the Cisco ACI
fabric policies.
Building Blocks of Cisco ACI Fabric Policies
Tenants are top-level MOs that identify and separate
administrative control, application policies, and failure
domains. A tenant can represent a customer in a
managed service provider environment or an
organization in an enterprise environment, or a tenant
can be a convenient grouping of objects and policies. A
tenant’s sublevel objects can be grouped into two
categories: tenant networking and tenant policy. Figure
9-4 provides a graphical representation of how a tenant