Cisco ACI: From Fabric to Application Policy

Cisco ACI treats the data-center network as a common policy domain rather than a collection of unrelated switch configurations. Its physical foundation consists of spine and leaf nodes. Servers and external connections terminate at the leaf layer, while spines provide connectivity between leaves. The APIC cluster supplies policy and management; it is not an inline security appliance through which application packets must pass. This separation establishes an important design decision: management access, fabric connectivity and application reachability need independent validation. The Cisco reference below provides a starting point for examining physical placement and dual connections.

A tenant organizes policy objects and their administrative context. A VRF defines a routing context, while a bridge domain defines the associated Layer 2 domain and network behavior. An EPG groups endpoints that receive common policy. Treating these objects simply as replacements for old VLAN numbers can disconnect the design from application needs. First identify which teams require separate administration and which workloads need independent routing contexts. Then evaluate addressing, gateway placement and external connectivity together. This gives operations a usable framework for distinguishing an object-association problem from a routing or policy problem, without relying on familiar VLAN names alone.

An EPG can place endpoints from an application's web, service or data tier into a shared policy group. Contracts describe communication conditions between providers and consumers, with filters defining permitted traffic. Naming an EPG “database” does not by itself demonstrate that access is appropriately restricted. Work with the application owner to identify actual sources, destinations, protocols and ports. Include supporting flows such as administration, backup and health checks. Positive tests should demonstrate required communication; negative tests should demonstrate that unnecessary communication is denied. This makes the resulting policy an evidenced application decision, rather than a set of configuration objects whose names merely suggest the intended isolation.

ACI uses an L3Out to connect the fabric to external Layer 3 networks. This involves more than enabling an uplink: external routing, learned routes and external EPG policy need to be considered together. Record dependencies such as DNS, identity services, internet access and other data centers in a traffic inventory. If the existing network must coexist during migration, examine return paths and the possibility of asymmetric traffic separately. External router icons in a reference diagram do not guarantee internet service; actual reachability depends on the organization's transport connections and policy. Documenting this distinction keeps the drawing and the migration decision aligned.

ACI can be designed around the connectivity and policy requirements of both physical and virtual workloads. The chosen VMM integration and software versions require their own compatibility checks. VM icons below servers in the source drawing should not be interpreted as additional devices directly attached to APIC. For each workload, identify host connectivity, port or domain association, gateway and policy group. Moving a virtual machine to another host can affect the application's reachability as well as the host attachment. A useful pilot therefore includes the organization's relevant mobility and restart scenarios alongside physical-port checks, with application owners confirming the expected behavior.

Rather than beginning with a single cutover of the whole network, choose an application group whose dependencies are understood. Record existing traffic and critical operating periods, then define target policy, connection order, responsible teams and rollback steps. Successful endpoint discovery should not be the only acceptance condition. Exercise real business workflows, including user transactions, service calls, persistence and reporting. For the period in which old and new environments coexist, assign ownership and removal conditions to temporary rules. This approach places the technical migration sequence and application accountability in the same plan, making approval and rollback decisions easier to explain.

An acceptance record should cover intended application flows, prohibited access, administrative reachability and redundant-connection behavior. Associate each finding with the test performed, its expected outcome and the evidence collected. Handover should explain tenant and EPG naming, contract ownership, configuration backups and the change process. When a new application is introduced, operations should know which objects may change and who approves the decision. Trustnet's catalog describes analysis, design, planning, implementation and support as the delivery framework; actual scope and acceptance thresholds are agreed against the organization's requirements. The reference architecture is a starting point, while production design consists of the documented decisions built around it.