Showing posts with label Data Center. Show all posts

Friday, 14 August 2026

Question 1

A contract subject is configured with scope "VRF" instead of "Tenant." What does this actually control?

Options

A. Whether the contract can be reused by other tenants

B. Which EPGs within the fabric the contract's filter rules are allowed to apply between

C. The QoS priority assigned to matched traffic

D. Whether the contract requires stateful firewall inspection

Correct Answer

✅ B. Which EPGs within the fabric the contract's filter rules are allowed to apply between

Explanation

Contract scope controls the boundary within which a contract's consumer/provider relationship is valid — VRF scope restricts it to EPGs within the same VRF, Tenant scope extends it to any VRF within the same tenant, and Global scope allows it across tenants. Getting this wrong is a common cause of contracts silently failing to apply between EPGs that appear correctly configured otherwise.

Question 2

Which ACI construct is responsible for propagating endpoint reachability information (which leaf owns which endpoint) across the fabric?

Options

A. Zoning-rules

B. COOP (Council of Oracle Protocol)

C. LLDP

D. OSPF between leaf and spine

Correct Answer

✅ B. COOP (Council of Oracle Protocol)

Explanation

COOP runs between leaf switches and spine switches to synchronize the fabric-wide endpoint database, so any leaf can look up where an endpoint currently lives. This is distinct from zoning-rules, which enforce policy (what's allowed to talk to what) rather than reachability (where something physically is).

Question 3

What is the KEY architectural difference between ACI Multi-Pod and ACI Multi-Site?

Options

A. Multi-Pod supports more leaf switches per Pod than Multi-Site

B. Multi-Pod uses a single APIC cluster and fabric-wide policy domain; Multi-Site uses independent APIC clusters per site orchestrated centrally

C. Multi-Site does not support Layer 3 connectivity between sites

D. Multi-Pod requires Nexus Dashboard Orchestrator; Multi-Site does not

Correct Answer

✅ B. Multi-Pod uses a single APIC cluster and fabric-wide policy domain; Multi-Site uses independent APIC clusters per site orchestrated centrally

Explanation

Multi-Pod extends one fabric (single APIC cluster, single policy domain) across pods connected by an IPN. Multi-Site keeps each site as its own independent fabric with its own APIC cluster, and coordinates policy between them via Nexus Dashboard Orchestrator — giving genuine fault-domain isolation that Multi-Pod doesn't provide.

Question 4

An engineer configures EPG-WEB as the consumer and EPG-DB as the provider of a contract, but traffic from DB to WEB is unexpectedly blocked while WEB to DB works fine. What is the MOST likely cause?

Options

A. The Bridge Domain is set to flood mode

B. The contract's filter is unidirectional and "Apply Both Directions" was not enabled (or a reverse filter wasn't added)

C. The VRF is in unenforced mode

D. The two EPGs are in different tenants

Correct Answer

✅ B. The contract's filter is unidirectional and "Apply Both Directions" was not enabled (or a reverse filter wasn't added)

Explanation

By default, ACI contracts can be configured to apply filters in both directions automatically, but if that option is disabled, the consumer-to-provider direction is permitted while the reverse (provider-to-consumer) traffic needs its own explicit filter entry. This is one of the most common real-world contract misconfigurations.

Question 5

What is the purpose of `vzAny` in an ACI tenant?

Options

A. It disables all contract enforcement within a VRF

B. It represents all EPGs in a VRF as a single group, allowing one contract to apply to every EPG in that VRF at once

C. It is the default deny rule applied to unmatched traffic

D. It defines the L3Out external EPG

Correct Answer

✅ B. It represents all EPGs in a VRF as a single group, allowing one contract to apply to every EPG in that VRF at once

Explanation

vzAny is a shortcut object representing every EPG within a VRF. Associating a contract to vzAny (as provider or consumer) avoids configuring the same contract relationship individually for dozens of EPGs — commonly used for shared services like DNS or NTP that every EPG needs to reach.

Question 6

An APIC cluster is running with a target size of 3, but only 2 controllers are currently healthy. What is the operational impact?

Options

A. The fabric immediately goes into a full outage

B. The fabric continues to run on existing policy, but the cluster is out of quorum for making and validating new configuration changes reliably

C. Only Tenant-level changes are blocked; Fabric Access Policy changes still work normally

D. APIC automatically demotes itself to a single-controller cluster with no impact

Correct Answer

✅ B. The fabric continues to run on existing policy, but the cluster is out of quorum for making and validating new configuration changes reliably

Explanation

Data plane forwarding on the leaf/spine switches is independent of APIC availability — it keeps running on already-programmed policy. But losing quorum in the APIC cluster means new configuration changes may not be reliably validated or replicated, which is why restoring cluster health quickly matters even though traffic isn't immediately affected.

Question 7

Which ACI feature allows two endpoints within the SAME EPG to be prevented from communicating with each other?

Options

A. Intra-EPG Isolation

B. Preferred Group Member

C. Taboo Contract

D. Unenforced VRF mode

Correct Answer

✅ A. Intra-EPG Isolation

Explanation

By default, endpoints in the same EPG can freely communicate with each other since they share the same policy. Intra-EPG Isolation overrides this, blocking east-west traffic between endpoints in the same EPG — useful for scenarios like a shared VDI or DMZ EPG where individual endpoints shouldn't reach each other directly.

Question 8

What is the primary function of an L3Out in Cisco ACI?

Options

A. To create a Layer 2 extension between two Bridge Domains

B. To provide Layer 3 connectivity between the ACI fabric and external networks, and control which external routes are imported/exported

C. To define QoS policy for external traffic only

D. To replace the need for a Bridge Domain in a tenant

Correct Answer

✅ B. To provide Layer 3 connectivity between the ACI fabric and external networks, and control which external routes are imported/exported

Explanation

An L3Out defines the routing protocol (BGP, OSPF, EIGRP, or static) used to exchange routes with an external network, along with route-map-based import/export control over which external subnets are learned into the fabric and which internal subnets are advertised out.

Question 9

What does a VMM (Virtual Machine Manager) domain in ACI primarily enable?

Options

A. Automatic firmware upgrades for ESXi hosts

B. Direct integration between APIC and a hypervisor manager (like vCenter) so EPGs can be dynamically mapped to VM port groups

C. A dedicated management VRF for hypervisor traffic

D. Automatic contract creation between all VMs in a cluster

Correct Answer

✅ B. Direct integration between APIC and a hypervisor manager (like vCenter) so EPGs can be dynamically mapped to VM port groups

Explanation

A VMM domain lets APIC push EPGs directly into the hypervisor as port groups (e.g., in vCenter), so VM placement automatically inherits the correct network policy without a network admin manually configuring VLANs or trunk ports for every new VM.

Question 10

A leaf switch shows a health score of 45 with no active critical faults listed. What does this indicate?

Options

A. The health score is unrelated to faults and only reflects hardware temperature

B. The health score is a weighted aggregate that can be pulled down by multiple minor/major faults even without any single critical fault present

C. A health score below 50 always means the leaf is about to fail

D. The health score only reflects the previous 24 hours and resets automatically

Correct Answer

✅ B. The health score is a weighted aggregate that can be pulled down by multiple minor/major faults even without any single critical fault present

Explanation

ACI health scores are calculated as a weighted aggregate across all faults affecting an object, including minor and major severities — not just critical ones. A moderate score with no critical faults often means several smaller issues are compounding, which is why it's worth reviewing the full fault list rather than only filtering for critical severity.

Key Takeaways

Policy Model

Contracts define what's allowed to communicate — scope defines the boundary they operate within
vzAny simplifies shared-services contracts across an entire VRF
Intra-EPG Isolation blocks communication within a single EPG when needed

Fabric Architecture

COOP synchronizes endpoint location, independent of policy enforcement
Multi-Pod = one fabric, one APIC cluster; Multi-Site = independent fabrics, centrally orchestrated
APIC cluster health affects config changes, not existing data-plane forwarding

Connectivity and Integration

L3Out controls both routing protocol adjacency and route import/export to external networks
VMM domains connect APIC directly to hypervisor managers for automatic policy-to-VM mapping

Operations

Health scores are weighted aggregates — always check the full fault list, not just the score

Conclusion

These ten questions cover the concepts that separate engineers who can navigate the APIC GUI from engineers who genuinely understand why ACI behaves the way it does — contract scope, zoning-rule enforcement, fabric architecture, and health-score interpretation all come up constantly in real troubleshooting. Use these as a quick self-check before an interview, a CCIE Data Center study session, or your next production change window.

Related Reading on Networklearner:

Need help with Cisco ACI, Nexus, data center networking, or network automation?

I am a CCIE Data Center engineer with 18+ years of enterprise networking experience, working hands-on with production ACI fabrics.

Contact me for consulting, troubleshooting, design reviews, and project support: rockingoa@gmail.com

Tuesday, 11 August 2026

Multi-Agent AI Systems Explained for Cisco ACI Engineers: Supervisor, Peer-to-Peer, and Hierarchical Patterns

One AI agent can only be so good at everything. Ask it to inventory devices in a Pod, check health scores, correlate a traffic anomaly, and draft a fix — and you're asking one generalist to do the job of four specialists. On a large ACI environment with multiple Pods, tenants, and Sites, that generalist starts to strain.

That's the problem multi-agent systems solve: instead of one agent doing everything, you split the work across several agents, each good at one thing, coordinated in a specific pattern. This post walks through the three orchestration patterns you'll see in agentic AI tooling — Supervisor, Peer-to-Peer, and Hierarchical — each mapped to a real ACI operational scenario.

When Does an ACI Team Actually Need Multiple Agents?

Before reaching for a multi-agent design, it's worth being honest about when it earns its complexity:

Complex workflows. Investigating a fabric issue genuinely needs different skills — pulling topology, reading health scores, interpreting zoning-rule programming. One agent trying to be great at all three ends up mediocre at each.
Parallel work. Checking three leaf switches at once, or querying both the APIC fault database and the Nexus Dashboard Insights API simultaneously, is naturally parallel — a single sequential agent just makes you wait longer.
Specialization. A "contract analysis" agent can be tuned with ACI-specific prompts and tools that would just be noise for a "topology lookup" agent.
Separation of concerns. Smaller, focused agents are easier to test and debug than one do-everything agent whose failures could be coming from anywhere.

The catch: more agents means more coordination overhead, more places for something to go wrong, and a harder system to debug. If a single agent with a couple of tools can already answer the question, that's the better answer. Start simple. Add agents only when a single agent hits its limits.

Pattern 1: Supervisor — One Coordinator, Specialized Workers

This is the most common pattern, and usually the right starting point. One supervisor agent receives the request, decides what needs to happen, and delegates to specialized worker agents — then assembles their results into a final answer.

ACI scenario: "Why is EPG WEB slow?"

The Supervisor decides this needs topology context, current fault data, and a contract check — in that order.
→ Topology Agent: maps EPG WEB to its leaf switches and ports. ← Returns: EPG WEB spans Leaf-101, Leaf-102, and Leaf-104.
→ Fault Agent: pulls current faults and health scores for those three leaves. ← Returns: Leaf-104 health score is 68; two contract-related faults are active.
→ Contract Agent: checks whether the contract between EPG WEB and EPG DB actually rendered correctly on Leaf-104. ← Returns: zoning-rule programming shows a stale entry from a contract update two days ago.
Supervisor assembles the answer: "EPG WEB's slowness traces to a stale zoning-rule entry on Leaf-104 from the last contract push — a policy resolve/redeploy should clear it."

When this works well: You want central control, a clean audit trail, and predictable delegation — which matters a lot in change-managed ACI environments where you need to show exactly which check ran and in what order.

The trade-off: the Supervisor is a single point of failure and can become a bottleneck if too much routing logic gets crammed into it.

Other ACI Supervisor use cases:

A single "fabric health assistant" that routes questions to a health-score agent, a fault-summary agent, or a capacity-planning agent depending on what's asked
Coordinating a Multi-Site health check across a Topology Agent, Latency Agent, and Schema-Sync Agent

Pattern 2: Peer-to-Peer — No Coordinator, Agents Consult Each Other

Here there's no central agent directing traffic. Any agent can talk to any other agent directly, and the answer emerges from their back-and-forth — closer to a group of specialists in a room than a chain of command.

ACI scenario: Voice quality complaints from Building A.

[Health Agent]: "Seeing 95% CPU on Leaf-103 in Building A — anyone have context?"

[Topology Agent] responds: "Leaf-103 serves EPG VOICE and EPG WEB. A contract update landed on it about an hour ago."

[Contract Agent] chimes in: "That update added a new filter to the VOICE-to-WAN contract. Checking whether it's over-matching traffic…"

[Security Agent] adds: "No threat signatures on this leaf — this looks operational, not malicious."

[Contract Agent] concludes: "Confirmed — the new filter is unintentionally catching broadcast traffic, consistent with the CPU spike."

Agents collectively surface: "CPU spike on Leaf-103 traced to an over-broad contract filter added in the last update."

When this works well: genuine collaboration where no agent has the full picture alone, and where resilience matters — if the Security Agent is unavailable, the other three can still reach a conclusion.

The trade-off: harder to debug. There's no single transcript to read top-to-bottom — the reasoning is scattered across several conversations.

Other ACI Peer-to-Peer use cases:

Multi-Site troubleshooting where a Latency Agent, a Schema Agent, and a Connectivity Agent need to jointly rule causes in or out
A design-review "roundtable" where a Security Agent, Capacity Agent, and Topology Agent debate a proposed contract change before it's finalized

Pattern 3: Hierarchical — Layered Control for Large Fabrics

This mirrors an org chart. An executive agent sets fabric-wide strategy and delegates to leads — one per Pod, Site, or domain — and each lead manages its own workers. Results roll back up the chain.

ACI scenario: "Is the whole campus experiencing slowness, or just one Pod?"

[Executive Agent]: "Delegate a health check to each Pod lead."
- → [Pod 1 Lead]
  - → Research Worker: inventories Pod 1 leaves → Leaf-101 through Leaf-104
  - → Diagnostics Worker: checks health scores → Leaf-104 at 68, one active fault
  - ← Pod 1 Lead reports: "Localized issue on Leaf-104."
- → [Pod 2 Lead]
  - → Research Worker: inventories Pod 2 leaves → Leaf-201, Leaf-202
  - → Diagnostics Worker: checks health scores → all normal
  - ← Pod 2 Lead reports: "No issues."
[Executive Agent] aggregates: "Campus slowness is isolated to Pod 1 — specifically Leaf-104. Pod 2 is healthy."

When this works well: your ACI environment is already organized this way — multiple Pods, multiple Sites, regional teams each owning their domain — so the agent hierarchy just mirrors structure you already have.

The trade-off: more layers means more latency. A question has to travel down through leads to workers and back up again before you get an answer.

Other ACI Hierarchical use cases:

A Multi-Site environment where each Site has its own lead agent managing local Pod-level workers, rolling up to a global orchestrator
Change-approval workflows where a request has to pass through a Tenant-level lead and then a Fabric-level executive before being approved — naturally mapping to an approval chain that mirrors your org structure

Choosing a Pattern for Your ACI Use Case

If you need…	Choose	Why
Simple delegation with clear, well-defined tasks	Supervisor	Most common pattern — straightforward and predictable
A workflow spanning multiple Pods, Sites, or tenant domains	Hierarchical	Mirrors how large fabrics and teams are already organized
Flexible collaboration where agents genuinely need to consult each other	Peer-to-Peer	Best for ambiguous, multi-cause investigations — but harder to debug
A clear audit trail for change management or compliance	Supervisor	Central control point makes the decision path traceable
High resilience with no single point of failure	Peer-to-Peer	The investigation continues even if one agent is unavailable

Complexity Trade-offs: Single Agent vs. Multi-Agent

Factor	Single agent	Multi-agent
Simplicity	Simple	Complex
Debugging	Easy	Harder
Latency	Lower	Higher
Cost	Lower	Higher

The rule that matters most: start simple, and only add agents once a single agent actually hits its limits. Most day-to-day ACI questions — "what's this leaf's health score," "list active faults on this EPG" — don't need a multi-agent system at all. Reach for one when the task genuinely spans multiple domains of expertise, the way a real fabric-wide incident does.

Final Thoughts

None of these patterns are about the AI being "smarter" — they're about matching the coordination structure to the shape of the problem. A quick lookup doesn't need a supervisor and three workers. A campus-wide incident spanning multiple Pods might genuinely benefit from one. The skill isn't picking the most sophisticated pattern — it's picking the one that fits the blast radius and complexity of what you're actually investigating, the same instinct that makes a good ACI engineer good at escalation and delegation in the first place.

FAQ

Q: Should every ACI troubleshooting AI system use multiple agents? A: No. Most single-EPG or single-device questions are handled better and faster by one agent with the right tools. Multi-agent systems earn their overhead on genuinely multi-domain problems — Multi-Site investigations, campus-wide incidents, or workflows that already mirror an organizational hierarchy.

Q: Which pattern gives the clearest audit trail for change management? A: Supervisor. Because one agent owns delegation and assembles the final answer, there's a single, traceable decision path — useful when you need to show exactly what was checked and in what order.

Q: Is Peer-to-Peer riskier to run against production APIC? A: Not inherently riskier in terms of what it does, but harder to review before the fact, since there's no single plan to inspect — the reasoning is distributed across several agent-to-agent exchanges. Pair it with the same execution guardrails (preview mode, confirmation, scoped tools) you'd use for any other agent design.

Related Reading on Networklearner:

Need help with Cisco ACI, Nexus, data center networking, or network automation?

I am a CCIE Data Center engineer with 18+ years of enterprise networking experience, working hands-on with production ACI fabrics.

Contact me for consulting, troubleshooting, design reviews, and project support: rockingoa@gmail.com

Tuesday, 4 August 2026

How AI Agents Actually "Touch" Your Cisco ACI Fabric: Tools, Schemas, and Guardrails Explained

An AI agent that can only talk isn't much use to an ACI operations team. It can summarize a fault log you paste in, sure — but it can't tell you Leaf-104's health score right now, and it definitely shouldn't be pushing a contract change just because it "reasoned" its way there. What separates a chatbot from something you'd actually let near APIC is tools — the functions an agent is allowed to call to read from, act on, or talk about your fabric.

This post breaks down how tools work in an AI agent, using Cisco ACI as the running example throughout, so the concepts map directly onto things you already manage — health scores, contracts, EPGs, and change windows.

Why "Just Talking" Isn't Enough on ACI

Picture an agent with no tools at all:

Agent: "I think Leaf-104 might be unhealthy, but I have no way to check."

Not useful. Now give it a single tool that can query APIC's health score API:

Agent: [calls get_node_health(node="Leaf-104")] → "Leaf-104's health score is 62. Two contract-related faults are currently active on this leaf."

Same question, completely different value. That's the entire point of tools — they turn an agent from something that speculates into something that can actually verify against the fabric's real state.

The Four Tool Categories, Mapped to ACI

Every tool an ACI-aware agent might use falls into one of four buckets. Knowing which bucket a task belongs to tells you immediately how much oversight it needs.

1. Retrieval Tools — Read-Only Lookups

These pull information without changing anything: health scores, fault counts, contract relationships, endpoint locations.

ACI examples:

get_node_health(node) — pull a leaf or spine's current health score
get_epg_faults(epg) — list active faults on a given EPG
get_endpoint_location(ip_or_mac) — find which leaf/port an endpoint is learned on
get_contract_relationships(tenant, epg) — list which contracts an EPG consumes/provides

Retrieval tools are the safest category — an agent can call these freely without much risk, which is exactly why they're the easiest place to start trusting AI in ACI operations.

2. Execution Tools — Tools That Change the Fabric

These make actual changes: pushing a contract, modifying a Bridge Domain setting, restarting a service, triggering a firmware upgrade. Because ACI's policy model propagates changes fabric-wide, execution tools deserve the most design care of any category.

ACI examples:

deploy_contract(tenant, epg_consumer, epg_provider, filter, mode)
update_bridge_domain(tenant, bd, setting, value, mode)
trigger_firmware_upgrade(node, target_version, mode)

Notice the repeated mode parameter — more on that below. It's the single most important detail in an ACI execution tool's design.

3. Communication Tools — Looping in Humans

These don't touch the fabric at all — they notify people. Sending a Slack alert about a degraded leaf, opening a ServiceNow ticket for a recurring fault, paging the on-call engineer when a Multi-Site link drops.

ACI examples:

send_slack_alert(channel, message) — e.g., posting when a leaf's health score drops below threshold
create_servicenow_ticket(summary, severity, affected_tenant)
page_oncall(team, reason) — for something like an APIC cluster losing quorum

These tools are how an agent stays useful even when it shouldn't act on its own — escalating to a human is often the correct behavior, not a fallback.

4. Perception Tools — Making Sense of Raw Data

These interpret information rather than fetch or change it: parsing a wall of fault codes into a plain-English summary, correlating a traffic spike with a recent contract change, summarizing a week of APIC audit logs.

ACI examples:

summarize_faults(tenant, time_range) — turn 200 raw fault codes into three actionable findings
correlate_traffic_anomaly(epg, time_range) — check if a spike lines up with a recent policy push
parse_audit_log(node, time_range) — extract what actually changed and who changed it

Perception tools are what let an agent reason well before it decides whether a retrieval or execution tool is even needed.

How the Agent Actually Picks a Tool

The agent doesn't understand ACI the way you do — it reads tool descriptions and matches them against the question. This is why the wording of a tool's description matters as much as the code behind it.

Say someone asks: "Is EPG WEB-EPG healthy right now?"

The agent scans its available tools and finds get_epg_faults described as "Retrieve current fault count and severity for a given EPG." That's a strong match — it extracts WEB-EPG as the input and calls it.

A vague description like "Gets ACI stuff" would leave the agent guessing between three different tools that all sound plausible. A precise description — naming exactly what the tool returns and for what object type — is what makes tool selection reliable instead of a coin flip.

Anatomy of an ACI Tool Schema

Take deploy_contract as a worked example of what a well-designed execution tool schema looks like:

Name: deploy_contract — the unique identifier the agent calls
Description: "Push a contract between two EPGs in a tenant. Warning: makes real fabric changes." — the explicit warning matters; it tells the agent (and anyone reviewing its plan) that this isn't a harmless lookup
Input schema:
- tenant — which tenant this applies to
- epg_consumer / epg_provider — the two EPGs the contract connects
- filter — the port/protocol filter being applied
- mode — constrained to an enum of "preview" or "apply", defaulting to "preview"

That last field is the load-bearing detail. A default of preview means the agent's first call only shows what would happen — the actual zoning-rule programming on the leaves doesn't happen until a human (or a separate, explicit step) chooses apply.

Schema design principles worth carrying into any ACI tool you build:

Write descriptions specific enough that two tools never sound interchangeable
Type every input (don't let a device ID be passed as a free-text string with no validation)
Use enums to constrain choices like mode, severity, or scope
Default to the safe option, never the destructive one
Mark required fields so the agent can't fire a call with the tenant or EPG left blank

Safety Considerations for ACI-Facing Tools

A tool that can act on a shared fabric needs guardrails baked in from the start — not bolted on after the first incident.

Destructive actions. A tool like update_bridge_domain can affect flooding or ARP behavior fabric-wide. Mitigation: default to preview mode, require explicit confirmation before applying, and never let an agent's very first call against a tool be a live push.

Credential exposure. If a tool logs its inputs and one of those inputs happens to include an APIC admin token or a TACACS credential passed through for auth, that's a real exposure. Mitigation: never log sensitive fields — scrub credentials before anything gets written to a log or a transcript.

Ineffective guardrails. A tool scoped to "manage the entire fabric" is too broad — it hands an agent far more blast radius than any single task requires. Mitigation: scope each tool tightly — a contract-deployment tool shouldn't also be able to touch fabric access policies.

Cascading failures. ACI workflows chain tool calls — the output of a health check might feed into whether a firmware upgrade proceeds. If one tool returns bad or stale data, a downstream tool can act on it. Mitigation: build rollback into any tool that changes state, and don't let a single failed check silently get treated as a pass.

The Validation Pipeline Before Anything Executes

Before an execution tool is allowed to actually touch APIC, three checks should pass, in order:

Schema compliance — Are all required fields present and correctly typed? If tenant is missing or mode isn't one of the allowed enum values, reject the call before it goes anywhere near the fabric.
Authorization — Does this user or agent identity actually have permission to call this tool? An agent scoped to read-only monitoring shouldn't be able to invoke deploy_contract at all, regardless of what it "decides" to do.
Safety checks — Is this action allowed right now? A change-freeze window, an active P1 incident, or an in-progress firmware upgrade are all reasons to block an otherwise-valid call.

Only after all three pass should the tool actually run against APIC.

Quick Reference: Tool Category vs. Oversight Needed

Category	ACI Example	Oversight Level
Retrieval	`get_node_health`, `get_epg_faults`	Minimal — safe to run freely
Execution	`deploy_contract`, `update_bridge_domain`	High — preview mode, confirmation, rollback
Communication	`send_slack_alert`, `page_oncall`	Low — but should avoid alert fatigue
Perception	`summarize_faults`, `correlate_traffic_anomaly`	Low — but accuracy matters, since downstream decisions rely on it

Final Thoughts

Tools are what make an AI agent useful on a real ACI fabric instead of just a chatbot that can describe what a health score is. The four categories — retrieval, execution, communication, perception — map cleanly onto operations work you already do every day. The schema design determines whether tool selection is reliable or a guessing game. And the safety layer — preview-by-default execution, tight scoping, credential hygiene, and a validation pipeline before anything runs — is what determines whether you'd actually trust an agent near production APIC.

None of this replaces your judgment. It's what lets an agent earn a little bit of it, one well-scoped tool at a time.

FAQ

Q: Should an AI agent ever have direct, unsupervised write access to APIC? A: Generally no. Execution tools should default to preview mode and require explicit confirmation before applying, with authorization and safety checks run before every call — the same discipline you'd want from any junior engineer making fabric changes.

Q: What's the biggest mistake in designing ACI tool schemas for an agent? A: Vague tool descriptions. If two tools' descriptions sound interchangeable, the agent will eventually pick the wrong one — and on ACI, the wrong tool call can mean a fabric-wide policy change instead of a simple status check.

Q: Are perception tools (like fault summarization) risky the same way execution tools are? A: Not in the same way — they don't change the fabric — but their accuracy still matters, because a bad summary can lead a human or a downstream tool call to the wrong conclusion.

Monday, 3 August 2026

AI Planning Strategies for Cisco ACI Engineers: From a Single APIC Query to Multi-Site Design Decisions

If you run ACI in production, you already know the job isn't really "networking" — it's decision-making under a policy model. Every ticket forces the same question: is this a quick lookup, a known runbook, an investigation, a design choice, or something that needs a second pass before it goes live?

AI agents face the exact same fork in the road. The strategy an agent picks — how much it plans before it acts — determines whether it's useful or dangerous on your fabric. This post walks through the five planning patterns showing up in agentic AI tooling today, each mapped to a real ACI scenario instead of a generic networking example.

Why This Matters More on ACI Than on Traditional Networks

On a traditional CLI-driven network, a bad AI action is usually contained to one box. On ACI, everything is a shared, declarative policy model — an EPG, a contract, or a Bridge Domain change can ripple across every leaf in the fabric in seconds, and a Multi-Site change can ripple across data centers.

That's exactly why how an AI agent plans matters so much here. A tool that fires configuration pushes without a reviewable plan is a liability on APIC. A tool that reasons, drafts a plan, and lets you approve it before touching the MIT (Management Information Tree) is something you can actually trust near production.

1. Single-Step ReAct — One Question, One Answer

This is the simplest pattern: gather what's needed, answer, done. No multi-turn planning required.

ACI scenario: "What's the health score of leaf switch Leaf-103?"

The agent queries the APIC health score API for that node and returns the number — no further steps needed.

Other single-step ACI use cases:

Pulling the fault count on a specific EPG
Checking whether a contract is currently applied between two EPGs
Looking up which leaf a given endpoint is learned on
Reporting APIC cluster health (avread state across controllers)
Checking the current firmware version on a switch node

Fast, low-risk, read-only. This is where most engineers will first trust an AI agent — because there's nothing to approve, only something to report.

2. Multi-Step ReAct — Following a Known Runbook

Some ACI tasks are a fixed, well-rehearsed sequence. The agent doesn't need to design anything — it needs to execute the checklist correctly, step by step, reacting to what each step returns.

ACI scenario: Onboarding a new leaf switch into the fabric.

Confirm the leaf is discovered and registered in APIC
Assign the node ID and confirm it joins the fabric membership policy
Verify the leaf inherits the correct Pod policy group and interface policies
Confirm VPC pairing (if applicable) comes up cleanly
Validate the leaf's health score stabilizes above threshold
Push a test EPG/BD binding and confirm endpoint learning works

If step 4 fails — say, the VPC doesn't form — the agent reacts, checks the peer-link and policy-group config before moving to step 5, the same way you would.

Other multi-step ACI use cases:

APIC cluster firmware upgrade sequence (validate → stage → upgrade controllers one at a time → validate cluster health before proceeding)
Tenant onboarding (create Tenant → VRF → Bridge Domains → EPGs → Contracts, in order)
Scheduled maintenance window pre-checks and post-checks
Rolling switch firmware upgrades across a pod without dropping VPCs

3. Plan-and-Execute — For When the Fabric Is Telling You Conflicting Things

This is the pattern that matters most for ACI troubleshooting, because ACI failures are rarely single-cause. A contract issue can look like an endpoint-learning issue. A Bridge Domain flooding setting can look like an application performance problem. Jumping straight into action wastes time and, worse, risks a config change based on a wrong guess.

Plan-and-Execute forces the agent to draft the full investigation before touching anything — and critically, you get to review or edit that plan first.

ACI scenario: Two EPGs that used to communicate fine are now silently dropping traffic after a contract update.

Rather than guessing, the agent proposes a plan like:

Diff the contract and subject/filter changes against the last known-good version
Check for drop_pkts counters on ingress/egress leaf interfaces for the affected EPGs
Confirm the contract scope (VRF vs Tenant vs Global) still matches the endpoints' actual VRF placement
Check zoning-rule programming on the affected leaves (show zoning-rule equivalent) to confirm the contract actually rendered in hardware
Verify no overlapping deny contract or vzAny rule is taking precedence
Correlate fault codes on the EPG and contract objects in APIC

Only after you approve (or the agent completes) that plan does it move into fault correlation and root-causing — and because the plan is visible, you can spot immediately if it's about to check the wrong VRF.

Other Plan-and-Execute ACI use cases:

Multi-Site latency or convergence issue reported across three data centers
APIC cluster split-brain or quorum-loss investigation
Migrating a legacy VLAN-based network into ACI EPGs without an outage
Investigating intermittent BD flooding storms across a Pod

4. Tree of Thoughts — For Architecture and Design Decisions

Good ACI architects don't commit to a design on the first idea — they weigh options against the actual requirements. Tree of Thoughts gives an AI agent that same discipline: generate multiple candidate approaches, evaluate trade-offs, then recommend.

ACI scenario: A customer needs a second data center for DR and asks whether to extend the existing ACI fabric or stand up something new.

The agent lays out and compares several branches:

Option	Strength	Trade-off
Stretched Fabric (single APIC cluster, no Multi-Pod)	Simplest operationally	Fragile — single failure domain, not resilient to WAN issues between sites
ACI Multi-Pod	Single APIC domain, fast failover, unified policy	Requires low-latency IPN between sites, less DC-to-DC fault isolation
ACI Multi-Site	True fault-domain isolation, independent APIC clusters per site, policy orchestrated centrally via Nexus Dashboard Orchestrator	More complex to operate, higher initial design and cost overhead
Standalone fabric with VXLAN EVPN + external interconnect	Maximum isolation, vendor-neutral if needed	Loses ACI's centralized policy model between sites; more manual policy reconciliation

The agent weighs these against stated requirements — RTT between sites, whether independent APIC failure domains are a hard requirement, existing IPN bandwidth — and recommends the best fit, the same way you'd whiteboard it with a customer.

Other Tree of Thoughts ACI use cases:

Choosing between contract-based (whitelist) vs. vzAny-based (preferred group) segmentation for a new tenant
Deciding EPG-per-VLAN vs. EPG-per-application microsegmentation strategy
L3Out design: shared L3Out in common Tenant vs. per-tenant L3Out
Evaluating Remote Leaf vs. Cloud ACI vs. Multi-Site for a hybrid-cloud expansion

5. Self-Reflection — Catching Mistakes Before They Hit the Fabric

This is arguably the most important pattern for anything that writes to APIC. Self-Reflection means the agent reviews its own output — a proposed contract, a migration plan, a config template — against a checklist before handing it to you.

ACI scenario: An agent drafts a new contract and filter set to allow a application team's new microservice to talk to a database EPG.

Before presenting the contract, it reflects:

Does this filter scope traffic to only the required ports, or is it accidentally permit-any?
Is the contract scope set correctly (this VRF only, not Global, unless cross-VRF was actually intended)?
Does this contract accidentally shadow or conflict with an existing vzAny rule?
Does the direction (consumer/provider) match the actual traffic flow, or did roles get reversed?
Does this change match the customer's segmentation standard (e.g., default-deny between tiers)?

Catching a reversed consumer/provider relationship — a mistake every ACI engineer has made at least once — before it goes to APIC is exactly the kind of check Self-Reflection is built for.

Other Self-Reflection ACI use cases:

Reviewing an auto-generated Bridge Domain configuration for correct flooding/ARP settings before applying
Validating a drafted Multi-Site schema template against the target sites' existing object naming conventions
Auditing a generated compliance report against actual fault/audit logs before it's sent to a customer
Second-pass review of an AI-suggested firmware upgrade plan for skipped compatibility checks

Which Strategy Fits Your ACI Task?

ACI Scenario	Recommended Strategy
Checking a leaf's health score or fault count	Single-Step ReAct
Onboarding a switch or running a known upgrade runbook	Multi-Step ReAct
Troubleshooting a Multi-Site latency or contract-drop issue	Plan-and-Execute
Choosing Multi-Pod vs. Multi-Site vs. Remote Leaf	Tree of Thoughts
Drafting a contract, schema, or migration config for review	Self-Reflection

Final Thoughts

None of these patterns replace ACI expertise — they formalize it. Single-Step ReAct is how you'd answer a quick Slack question. Multi-Step ReAct is your runbook discipline. Plan-and-Execute is how a senior engineer investigates a messy, multi-cause outage instead of guessing. Tree of Thoughts is the whiteboard session before a design gets signed off. Self-Reflection is the second pair of eyes on a change before it hits production.

As AI agents get closer to actually touching APIC and pushing policy, the strategy behind how they plan matters as much as what they execute. An agent that can show you its plan — and reflect on its own output — is one you can actually let near a production fabric.

FAQ

Q: Which planning strategy should an AI agent use before pushing a config change to APIC? A: Self-Reflection at minimum, and ideally combined with Plan-and-Execute — the agent should draft the change, reflect on it against a checklist (scope, contract direction, filter correctness), and only then present it for approval before anything touches the fabric.

Q: Is Plan-and-Execute overkill for a simple ACI health check? A: Yes. A single health-score lookup only needs Single-Step ReAct. Plan-and-Execute earns its overhead on multi-cause, cross-domain problems like a Multi-Site outage — not routine lookups.

Q: Can Tree of Thoughts be used for troubleshooting, not just design? A: It can, when there are genuinely multiple plausible root causes with different fixes (for example, "is this a contract issue, a BD flooding issue, or an MTU mismatch on the L3Out?") — but for most fault-finding, Plan-and-Execute's linear investigation plan is the better fit.

Related Reading on Networklearner:

Need help with Cisco ACI, Nexus, data center networking, or network automation?

I am a CCIE Data Center engineer with 18+ years of enterprise networking experience, working hands-on with production ACI fabrics.

Contact me for consulting, troubleshooting, design reviews, and project support: rockingoa@gmail.com

Friday, 14 August 2026

Top 10 Cisco ACI Multiple Choice Questions (MCQs) with Answers and Explanations

Question 1

A contract subject is configured with scope "VRF" instead of "Tenant." What does this actually control?

Options

Correct Answer

Explanation

Question 2

Which ACI construct is responsible for propagating endpoint reachability information (which leaf owns which endpoint) across the fabric?

Options

Correct Answer

Explanation

Question 3

What is the KEY architectural difference between ACI Multi-Pod and ACI Multi-Site?

Options

Correct Answer

Explanation

Question 4

An engineer configures EPG-WEB as the consumer and EPG-DB as the provider of a contract, but traffic from DB to WEB is unexpectedly blocked while WEB to DB works fine. What is the MOST likely cause?

Options

Correct Answer

Explanation

Question 5

What is the purpose of vzAny in an ACI tenant?

Options

Correct Answer

Explanation

Question 6

An APIC cluster is running with a target size of 3, but only 2 controllers are currently healthy. What is the operational impact?

Options

Correct Answer

Explanation

Question 7

Which ACI feature allows two endpoints within the SAME EPG to be prevented from communicating with each other?

Options

Correct Answer

Explanation

Question 8

What is the primary function of an L3Out in Cisco ACI?

Options

Correct Answer

Explanation

Question 9

What does a VMM (Virtual Machine Manager) domain in ACI primarily enable?

Options

Correct Answer

Explanation

Question 10

A leaf switch shows a health score of 45 with no active critical faults listed. What does this indicate?

Options

Correct Answer

Explanation

Key Takeaways

Policy Model

Fabric Architecture

Connectivity and Integration

Operations

Conclusion

Tuesday, 11 August 2026

Multi-Agent AI Systems Explained for Cisco ACI Engineers: Supervisor, Peer-to-Peer, and Hierarchical Patterns

Multi-Agent AI Systems Explained for Cisco ACI Engineers: Supervisor, Peer-to-Peer, and Hierarchical Patterns

When Does an ACI Team Actually Need Multiple Agents?

Pattern 1: Supervisor — One Coordinator, Specialized Workers

Pattern 2: Peer-to-Peer — No Coordinator, Agents Consult Each Other

Pattern 3: Hierarchical — Layered Control for Large Fabrics

Choosing a Pattern for Your ACI Use Case

Complexity Trade-offs: Single Agent vs. Multi-Agent

Final Thoughts

FAQ

Tuesday, 4 August 2026

How AI Agents Actually "Touch" Your Cisco ACI Fabric: Tools, Schemas, and Guardrails Explained

Why "Just Talking" Isn't Enough on ACI

The Four Tool Categories, Mapped to ACI

1. Retrieval Tools — Read-Only Lookups

2. Execution Tools — Tools That Change the Fabric

3. Communication Tools — Looping in Humans

4. Perception Tools — Making Sense of Raw Data

How the Agent Actually Picks a Tool

Anatomy of an ACI Tool Schema

Safety Considerations for ACI-Facing Tools

What is the purpose of `vzAny` in an ACI tenant?