ACI Policy Blueprint

Compile application communication requirements into a reviewable Cisco ACI policy design, a communication matrix and traceable engineering reports.

My role
Design & implementation
Scope
Offline ACI policy design compiler
Release
v0.1.0

Validation scope

Offline model validated

94 tests across Python 3.11–3.13 and seven CLI scenarios. Three-tier example: three EPGs, two contracts and four matrix rows. No APIC or fabric test.

Policy requirements translated into distinct tenant spaces and a connected data-center fabric.
Conceptual illustration

Inside the work

How it works

  1. Describe communication intent

    Define a user tenant, VRFs, bridge domains, EPGs and TCP/UDP IPv4 flows in explicit JSON requirements.

  2. Reject inconsistent models

    Validate references, gateway/subnet semantics and service bounds. Reject cross-VRF flows, overlapping subnets and ambiguous intent.

  3. Compile one review package

    Generate the APIC object tree, bidirectional CSV matrix, findings and engineering review from the same canonical model.

  4. Retain reproducible evidence

    Record input and artifact hashes. Write into a new directory and publish the manifest last to mark a complete run.

Decisions & trade-offs

One contract per flowOne consumer and one provider

One consumer and one provider

Each contract represents one declared application relationship, avoiding additional consumer/provider combinations. Reverse-port rows are explicit.

The trade-off

More policy objects than shared contracts. Filters remain stateless, not connection-tracking firewall rules.

Stop at a reviewable designOffline compilation only

Offline compilation only

Generate policy intent without credentials, APIC transport or changes to an existing tenant. Engineering review remains a separate step.

The trade-off

Payload acceptance, bindings and effective access require APIC and fabric validation beyond this release.

Preserve each runFresh directory with a final manifest

Fresh directory with a final manifest

Refuse to overwrite previous output. A manifest records input and artifact hashes and identifies whether the model was valid.

The trade-off

Hashes detect changed bytes relative to the manifest; they are not a signature or proof of deployment correctness.

Technologies by purpose

  • Python

    Dependency-free offline compiler and command-line interface.

  • Cisco ACI

    Logical tenant, VRF, BD, EPG, contract and filter model.

  • JSON requirements

    Explicit intent, schema bounds and canonical input.

  • CSV & Markdown

    Bidirectional matrix and human-readable engineering review.

  • SHA-256 & CI

    Artifact traceability and repeatable tests on three Python versions.

Scope & evidence

Published evidence

Validation limits

  • No APIC acceptance, deployment, fabric reachability or effective isolation was tested.
  • Stateless TCP/UDP IPv4 filters; intra-EPG traffic remains unenforced. An absent matrix row does not prove denial.
  • No L3Out, route leaking, bindings, IPv6, reconciliation or rollback. Existing fabric policies can alter effective access.

Test captures

Recorded evidence rendered as documents · not a product interface.

Three-tier communication matrix — recorded evidence documentEnlarge

Three-tier communication matrix

Explicit forward and reverse-port rules generated from synthetic requirements. Offline model validation; not observed connectivity.

Source · 2026-10-29
Cross-VRF flow rejected — recorded evidence documentEnlarge

Cross-VRF flow rejected

The synthetic model returns exit 1 before an APIC payload is generated. No APIC connection or fabric test.

Source · 2026-10-29