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.

1. Confirm the leaf is discovered and registered in APIC
2. Assign the node ID and confirm it joins the fabric membership policy
3. Verify the leaf inherits the correct Pod policy group and interface policies
4. Confirm VPC pairing (if applicable) comes up cleanly
5. Validate the leaf's health score stabilizes above threshold
6. 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:

1. Diff the contract and subject/filter changes against the last known-good version
2. Check for drop_pkts counters on ingress/egress leaf interfaces for the affected EPGs
3. Confirm the contract scope (VRF vs Tenant vs Global) still matches the endpoints' actual VRF placement
4. Check zoning-rule programming on the affected leaves (show zoning-rule equivalent) to confirm the contract actually rendered in hardware
5. Verify no overlapping deny contract or vzAny rule is taking precedence
6. 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:

• AI Agent Reasoning Loop (ReAct) Explained for Network Engineers
• AI Agent Perception and Context Windows Explained for Network Engineers
• Understanding AI Agents for Network Engineers: LLMs, Prompts, Tokens and Context Explained
• Agentic AI for Network Engineers: What It Actually Means
• Reactive Automation vs Generative AI vs Agentic AI in Networking
• More posts 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

BGP Timers on a VRF in ACI Multi-Site — Why NDO Can't Do It and What Cisco TAC Confirmed

 If you've gone looking for a VRF-level BGP Timer Policy in Nexus Dashboard Orchestrator and come up empty, you're not missing a menu — it genuinely isn't there yet. Here's what we found while troubleshooting this on a live Multi-Site fabric with a mix of stretched and local VRFs, the workaround Cisco TAC confirmed as supported, and exactly how to verify the new timers actually took effect instead of just assuming they did.

• The gap: NDO does not expose a BGP Timer Policy at the VRF level for ACI Multi-Site — only at the L3Out node level (via L3Out Node Routing Policy → BGP Node Settings).
• The workaround: Create and apply the BGP Timer Policy directly on APIC, per site, against the target VRF (local or stretched). Cisco TAC confirmed this is the correct and supported method.
• The catch: BGP timers are negotiated during the initial handshake. Changing the policy alone does nothing to an already-established session — you need a hard reset of the BGP session for the new keepalive/hold values to take effect.
• Don't trust the config alone. "Configured" timers and "negotiated" (active) timers are two different things in show bgp output — always verify the negotiated value after the reset, not just the configuration.

The Problem: No VRF-Level BGP Timer Option in NDO

In a single-site APIC deployment, applying a custom BGP Timer Policy to a VRF is straightforward — it's a native object under Tenant → Networking → VRF → BGP Context Per Address Family. In Multi-Site environments managed through NDO, that granularity isn't there. NDO's L3Out configuration model lets you attach a BGP Node Routing Policy (with its own keepalive/hold timers) to a node group inside an L3Out template — but there's no equivalent construct for applying timers at the VRF level, independent of a specific L3Out's node groups.

For environments running mixed local and stretched VRFs across sites, that's a real gap: you may want consistent BGP timer behavior tied to the VRF itself, not scattered across every L3Out node group that happens to reference it.

What We Asked Cisco TAC

Rather than guess, we opened a case and asked directly. Here's the exchange, included for anyone hitting the same wall:

Our question:

We need to deploy BGP timers on a VRF within our ACI Multi-Site fabric. Our environment contains both stretched and local VRFs. We do not see an option in NDO to apply BGP timers at the VRF level. Therefore, we are planning to use the following approach: 1) Create a BGP Timer Policy on the APIC. 2) Apply the BGP Timer Policy to the target VRF (local or stretched) via APIC only. Could you please confirm whether the above procedure is the correct and supported method for configuring BGP timers in an ACI Multi-Site environment? Additionally, after applying the policy, we do not see the updated timer values reflected on the BGP neighbour sessions. Is a BGP session reset (hard reset) required for the new timer values to take effect, or are there any additional steps that need to be performed?

Cisco's response:

Configuration Method: Your proposed approach is correct. As NDO does not currently support configuring BGP Timer Policies at the VRF level, applying these policies directly via the APIC on each respective site is the standard and supported method. 

Session Reset: Yes, a BGP session reset (hard reset) is required for the new timer values to take effect. Because these timers are negotiated during the initial BGP handshake, the existing sessions must be torn down and re-established to renegotiate the new keepalive and hold-down values with the neighbor.

Two things worth underlining from that response: this is a per-site, APIC-side configuration — NDO is not the tool for VRF-level BGP timers today — and a hard reset is mandatory, not optional, for the values to actually apply.

Step-by-Step: Applying the BGP Timer Policy to a VRF via APIC

1. Log into the APIC GUI for the site containing the target VRF (do this per site for stretched VRFs — there's no single-pane push for this from NDO).
2. Navigate to Tenants → <tenant> → Networking → VRFs → <vrf-name>.
3. Under the VRF, go to the BGP Context Per Address Family (create one for each address family in use — IPv4 and/or IPv6).
4. Set the BGP Timers field to a custom BGP Timer Policy, or create a new one:
   • Go to Tenants → <tenant> → Policies → Protocol → BGP → BGP Timers, right-click and Create BGP Timers Policy.
   • Set Keepalive Interval (sec) and Hold Interval (sec) to your target values (keep the standard 1:3 ratio — e.g., 4/12 or 10/30 — most implementations expect hold time to be roughly 3x keepalive).
5. Apply the policy to the VRF's BGP Context Per Address Family and submit.
6. Repeat per site for any stretched VRF — this is not propagated automatically across the Multi-Site domain since it's an APIC-local object, not an NDO-managed one.
7. Confirm the object landed correctly:

   GET https://<apic>/api/node/mo/uni/tn-<tenant>/ctx-<vrf>/bgpCtxAfP-ipv4-ucast.json

Check for the tnBgpTimersPolName attribute pointing to your new policy.

Why the Timers Won't Show Up Until You Reset the Session

This trips people up every time: BGP keepalive and hold timers are exchanged in the OPEN message during session establishment — they're not a live, continuously-enforced parameter that updates on the fly. Changing the policy updates the configuration, but an already-established session keeps running on whatever timers it originally negotiated until it's torn down and rebuilt.

That means after step 7 above, show bgp will show your configured timers, but the negotiated/active timers on any existing session will still be the old values — until you force a reset.

Verifying the Change Actually Took Effect

Don't just trust the APIC MO or the CLI's "configured" line — verify the negotiated value, which is what's actually governing the session.

1. Check the configured value on the border leaf:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name>

Look for: Configured hold time is 12, keepalive interval is 4 seconds

2. Check the negotiated (active) value in the same output: Look for: Hold time is X, keepalive interval is Y seconds If X/Y still show the old defaults, the session hasn't renegotiated — move to step 3.

3. Force the hard reset:

clear bgp <afi> unicast <peer-ip> vrf <tenant>:<vrf-name>

A soft clear will not renegotiate timers — timers only get exchanged at session establishment, so this has to be a hard clear.

4. Re-check the negotiated value after the reset:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name>

The negotiated value will be the lower of what each side offers — if your peer's own BGP timer configuration is set higher (or lower) than yours, that governs the final negotiated result, not your configured value alone.

5. Confirm real-world keepalive cadence:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name> | include "Last read"

Run this two or three times a few seconds apart — "Last read" should reset roughly every N seconds, matching your new keepalive interval.

6. Watch for flapping after the change, especially with aggressive timers like 4/12:

show bgp <afi> unicast neighbors <peer-ip> vrf <tenant>:<vrf-name> | include "Last reset"
show logging logfile | include BGP

A Word of Caution on Aggressive Timers

Tighter timers (like 4-second keepalive / 12-second hold) improve failure-detection speed, but they raise the risk of false-positive flaps on links with variable latency, high CPU load on the peer device, or congested control-plane paths. Before rolling this out broadly across a Multi-Site fabric, test it on a single non-critical VRF/L3Out first and monitor for a few days.

FAQ

Does NDO support VRF-level BGP timers at all? Not currently. The only BGP timer construct exposed in NDO is at the L3Out node group level (L3Out Node Routing Policy → BGP Node Settings). VRF-level BGP Timer Policies must be applied directly on APIC, per Cisco TAC's confirmation.

Will this survive an NDO template push or resync? Since the VRF-level BGP Timers Policy is applied directly on APIC and not modeled in the NDO template, it should not be overwritten by a standard template redeploy — but any workflow that deletes and recreates the VRF from NDO would remove it. Treat it as an out-of-band configuration and document it clearly for your team.

Do I need to reset the session on both sides of the peering, or just my side? Just your side's session needs a hard clear to force renegotiation — BGP will tear down and rebuild the full session, which inherently re-triggers the handshake and timer exchange on both ends.

What's a safe keepalive/hold ratio to use? Cisco and most vendors expect hold time to be roughly 3x keepalive (e.g., 4/12, 10/30, 20/60). Going below that ratio, or setting a very low hold time on a link with real latency or jitter, increases false-positive flap risk.

Is this the same procedure for a stretched VRF across multiple sites? Yes, but it must be repeated per site — this is an APIC-local object, and NDO doesn't propagate it across the Multi-Site domain automatically. For a stretched VRF, log into each site's APIC and apply the same BGP Timer Policy independently.

Related Reading on Networklearner

• Why BGP Maximum-Paths Wasn't the Problem: Fixing Uneven Port-Channel Traffic on Cisco Nexus and IOS
• Complete Firewalls Port Reference for Cisco ACI, Nexus Dashboard, NDO and NDI
• BGP: Active Open Failed - No Route to Peer
• Weight Attribute - BGP
• BGP Attributes: Well Known vs Optional
• BGP Attribute - AS Prepend
• Cisco ACI Static EPG Configuration – Step-by-Step Deployment Guide
• Complete Steps to Create vPC in Cisco ACI (via APIC GUI)

---

Author note: 

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.
Contact me for consulting, troubleshooting, design reviews, and project support.

Complete Firewalls Port Reference for Cisco ACI, Nexus Dashboard, NDO and NDI

 

If you've ever tried to onboard an APIC site into Nexus Dashboard Orchestrator (NDO) or Nexus Dashboard Insights (NDI) only to watch the connection sit at "Not Reachable," the cause is almost always the same: a firewall or ACL between Nexus Dashboard and the ACI fabric is blocking a port nobody told you about.

This guide consolidates every port you need — APIC to leaf/spine, APIC to Nexus Dashboard, NDO-specific ports, NDI-specific ports, and the internal ports a multi-node ND cluster needs between its own nodes — into one reference you can hand straight to your firewall team.

Quick jump:

• Why this trips people up
• Management vs. data network — pick correctly
• Port table: ND cluster ↔ outside world
• Port table: NDO ↔ APIC
• Port table: NDI ↔ APIC / fabric
• Port table: APIC ↔ Leaf/Spine (fabric internal)
• Troubleshooting checklist
• FAQ

---

Why this trips people up

Nexus Dashboard isn't one service — it's a platform that runs NDO, NDI, and NDFC as apps on top of a shared cluster. Each app has its own port requirements on top of the base cluster ports, and each app can reach the fabric through a different interface (management network vs. data network, in-band vs. out-of-band APIC). Miss that distinction and you'll open the right port on the wrong interface — the connection still fails, and it looks identical to a wrong-port problem.

---

Management vs. data network — pick correctly {#management-vs-data-network}

Nexus Dashboard interface	What it's for	Reaches APIC via
Management (mgmt) network	UI access, NTP, DNS, firmware upgrades, Intersight, DC proxy	Can reach APIC OOB or in-band, if routed
Data network	Node-to-node cluster traffic, and all app traffic — NDO, NDI, NDFC	APIC in-band or OOB for NDO; in-band only for NDI

Rule of thumb: if you're only running NDI, or NDI alongside other services, the ND data interface must have IP reachability to the in-band management network of the APIC and every switch in the fabric — NDI pulls switch-level telemetry that OOB simply doesn't carry. NDO is more flexible and can use either OOB or in-band APIC reachability.

---

Port table: ND cluster ↔ outside world {#nd-cluster-ports}

These are baseline ports every Nexus Dashboard cluster needs, regardless of which app (NDO/NDI/NDFC) you run on top.

Also allow outbound to your NTP, DNS, and (if used) TACACS+/LDAP/RADIUS servers, plus internet/proxy access if the cluster needs firmware downloads or Intersight connectivity.

---

Port table: NDO ↔ APIC {#ndo-apic-ports}

NDO's actual data-plane traffic to sites is just the APIC REST API over TCP 443. If you're only building day-0/day-1 policy through NDO (no NDI), this is the shortest port list of the three.

---

Port table: NDI ↔ APIC / fabric {#ndi-apic-ports}

NDI is the most sensitive to the in-band requirement — before onboarding a fabric, confirm the in-band management EPG, bridge domain, and subnet are already built and that every leaf, spine, and APIC has a reachable in-band address. This is the step people skip and then spend hours troubleshooting "site unreachable" errors that are actually EPG/BD issues, not firewall issues.

---

Port table: APIC ↔ Leaf/Spine (fabric internal) {#apic-fabric-ports}

This traffic stays inside the ACI infra VRF and normally isn't firewalled, but it's worth documenting for anyone running APIC connectivity through an external device (e.g., a device sitting between APIC and a remote-leaf pair):

If you're extending remote leaf switches over a routed IPN, also confirm OSPF, DHCP relay, and multicast (PIM Bidir) are permitted, with a minimum MTU of 9150 bytes end to end.

---

Troubleshooting checklist {#troubleshooting}

Work through these in order before opening a TAC case:

1. Ping test first. Confirm basic IP reachability from the ND data interface to the APIC in-band (for NDI) or in-band/OOB (for NDO) address. No ping = no point checking ports yet.
2. Confirm which interface ND is actually using. Nexus Dashboard > Infrastructure > Cluster Configuration shows whether the data or management network is used for fabric connectivity.
3. Verify APIC in-band is actually built (mgmt tenant, in-band BD, in-band EPG, node management addresses) — this is the single most common NDI onboarding blocker, not the firewall itself.
4. Test port 443 directly from an ND node to the APIC IP with curl -vk https://<apic-ip> or openssl s_client -connect <apic-ip>:443.
5. Check for SSL inspection/proxy devices sitting in the path — APIC's certificate handling doesn't play well with transparent SSL interception.
6. Re-check site status after any firewall change — NDO/NDI cache connectivity state and may need a manual "Refresh" or re-registration, not just a rule change.

---

FAQ {#faq}

Does NDO need port 80, or just 443? In current releases, TCP 443 alone is sufficient for APIC REST API communication. Port 80 was referenced in older MSO documentation and is generally not required if 443 is reachable.

Can NDI use the APIC out-of-band address? No. NDI depends on in-band reachability to both APIC and the switches for telemetry collection; OOB-only connectivity will not work for NDI.

Do NDO and NDI need different firewall rules if both run on the same ND cluster? Yes — treat them as separate rule sets. NDO needs 443 to APIC. NDI additionally needs 443 (and sometimes 22) to every switch in the fabric over the in-band network.

What's the minimum MTU I need between Nexus Dashboard and the fabric? 1500 bytes minimum on the ND data interface; higher MTU is supported if your infrastructure already runs jumbo frames.

My rules look correct but the site still shows "Not Reachable." What next? Check for SSL-inspecting firewalls/proxies in the path, confirm the APIC certificate hasn't expired, and verify NTP is in sync across APIC and ND — clock skew alone can break TLS session establishment.

---

Related reading on Networklearner

• ThousandEyes Firewall Requirements: Agent to Dashboard Ports and Rules — same port-table format, useful cross-link since readers researching ACI firewall rules often also manage ThousandEyes agents
• Recovering and Reinitializing a Standby APIC to Active APIC in Cisco ACI
• How to Safely Decommission a Leaf Switch in Cisco ACI — Step-by-Step Guide with Checklist
• Cisco ACI Decommission Only vs Remove vs Secure Remove — Complete Guide with Management IP Behavior
• ACI Leaf Switch Replacement
• Complete Steps to Create vPC in Cisco ACI (via APIC GUI)
• Cisco ACI Static EPG Configuration – Step-by-Step Deployment Guide
• What is a Contract Preferred Group in ACI?
• COOP: Council of Oracle Protocol - Cisco ACI
• Configuring Port Profiles in Cisco ACI (NX-OS Style CLI)
• Cisco ACI Mis-Cabling Protocol (MCP) – Loop Detection Simplified

Reactive Automation vs Generative AI vs Agentic AI: A Decision Framework for Network Engineers

 I am a network professional with over 18 years of experience in enterprise and data‑center networking. I am a CCIE Data Center certified engineer with strong hands‑on expertise in Cisco Nexus and Cisco ACI design, deployment, troubleshooting, and operations. I work on production ACI fabrics and am available for Cisco ACI and Nexus freelancing or consulting work. 

Most teams don't have a shortage of "intelligent" tooling anymore — they have three different kinds running simultaneously, often without anyone having deliberately chosen which one belongs where. An EEM applet restarts a process. An engineer pastes a syslog snippet into ChatGPT at 2 a.m. A vendor's new "AI-powered" NOC dashboard promises to investigate incidents on its own. These are not the same technology wearing different logos — they're three genuinely different intelligence models, and picking the wrong one for a given job either wastes the tool's potential or creates real operational risk.

This post isn't another "here's what Agentic AI means" explainer. It's a working decision framework: how to tell which of the three you actually need for a specific network operations problem, with a scoring checklist you can run against your own use cases.

Table of Contents

1. The Three Models, in Networking Terms
2. The Same Incident, Handled Three Ways
3. Decision Framework: Which One Do You Actually Need?
4. Scoring Checklist for Your Own Use Case
5. Where Governance and Cost Actually Change
6. A Common Mistake: Over-Automating Too Early
7. FAQ

---

1. The Three Models, in Networking Terms {#three-models}

Reactive Automation — EEM applets, SNMP trap handlers, cron-scheduled scripts, Ansible playbooks triggered on a webhook. Fixed IF-THEN logic, no memory of past events, same input always produces the same output. This has run enterprise networks reliably for decades and isn't going anywhere.

Generative AI — ChatGPT, Copilot, Claude, or a vendor's embedded assistant, used the way you'd use a very well-read colleague: you ask, it explains, you decide what to do. It understands natural language and context within a session but takes no action on its own and has no persistent memory of your fabric across conversations unless you explicitly feed it that context each time.

Agentic AI — given a goal rather than a question ("resolve this packet loss," "bring this BGP session back up"), it independently gathers telemetry, reasons through multiple hypotheses, takes or recommends action, checks whether the action worked, and either closes the loop or escalates with evidence attached.

2. The Same Incident, Handled Three Ways {#same-incident}

Take an OSPF adjacency stuck in EXSTART between two data center routers.

Reactive automation's role: a monitoring script notices the neighbor state hasn't reached FULL within an expected window and pages the on-call engineer. It has no opinion on why — it just knows the state is wrong.

Generative AI's role: the paged engineer asks an assistant "why would OSPF get stuck in EXSTART," and gets a solid explanation — MTU mismatch, duplicate router ID, or an interface flapping mid-negotiation — along with the show commands to check each. The engineer still has to run those commands and decide.

Agentic AI's role: given the goal "restore OSPF adjacency between these two routers," the agent pulls the interface MTU on both sides, checks router IDs, reviews recent interface error counters, forms a ranked hypothesis, and either proposes a specific fix or — if authorized for read-only + low-risk actions only — clears the interface counters and re-triggers negotiation, then verifies the adjacency actually reached FULL before closing the loop.

None of these three replaces the other two. The monitoring script still needs to exist to trigger the whole chain. The assistant is still useful when a human wants to understand why, not just get a fix. The agent is valuable specifically when the investigation itself is the time-consuming part.

3. Decision Framework: Which One Do You Actually Need? {#decision-framework}

Ask these questions about the specific task in front of you, in order:

Is the correct response always identical, regardless of context? If yes — stick with reactive automation. Interface down → generate a ticket. There's no ambiguity to reason through, so paying for reasoning is waste.

Does a human need to understand the "why" before acting, and is there time for that? If yes — generative AI is the right layer. Documentation review, config audits before a change window, explaining an unfamiliar error message — these benefit from an assistant, not autonomous action.

Does resolving this require pulling data from multiple sources, forming a hypothesis, and iterating — and is speed more valuable than having a human drive each step? If yes — this is where an agent earns its keep. Multi-source root cause analysis, correlating a config change with a metrics regression, is exactly the kind of "read a lot, reason a bit, then act" work reactive scripts can't do and manual assistant use is too slow for.

4. Scoring Checklist for Your Own Use Case {#scoring-checklist}

Score each statement 1 (no) to 3 (strongly yes) for the task you're evaluating:

• The correct action is identical every single time this trigger fires
• A human explanation of root cause has real standalone value here, separate from fixing it
• Multiple data sources need to be correlated before you'd even know what to try
• Getting it wrong has low blast radius (a restarted service, not a routing change on a core switch)
• Speed of resolution matters more than having a human in the loop for every step

Mostly 1s on correlation/speed, high on "always identical" → reactive automation is enough; don't over-build. High on "human explanation has value," low on "always identical" → generative AI, used interactively, is the right fit. High on correlation and speed, and you've separately confirmed blast radius is controlled → agentic AI is worth piloting, with tight scoping on write access.

5. Where Governance and Cost Actually Change {#governance-cost}

This is the part most comparison posts skip. As you move from left to right across the three models, three things change together, not independently:

Blast radius. A misconfigured EEM applet affects one device. A generative AI assistant giving bad advice affects whatever the human chooses to act on — there's still a human check. An agent with write access across multiple devices, acting on its own reasoning, has a blast radius as large as the scope of its credentials — which is exactly why that scope has to be deliberately narrow.

Auditability requirements. Nobody demands to know "why" a cron job restarted a service — the rule is the explanation. An agent's action needs the reasoning chain logged alongside the command, because "why did it do that" has to be answerable after the fact, especially for anything customer-facing.

Cost per incident. Reactive automation costs almost nothing per trigger. Generative AI costs a bit more per query but is bounded by how much a human chooses to ask. An agent that calls out to a model repeatedly across a busy fabric, on every event, can accumulate real compute cost — scope which events actually warrant agentic investigation rather than routing everything through it by default.

6. A Common Mistake: Over-Automating Too Early {#common-mistake}

The most common failure pattern isn't under-using AI — it's reaching for an agent before the underlying reactive automation and monitoring are solid. An agent reasoning over noisy, incomplete telemetry will produce confident, plausible-sounding conclusions that are wrong just as often as a junior engineer working from bad data would. Get the boring Level 1 monitoring accurate and complete first; the agent is only as good as the data it's reasoning over.

Quick Comparison Table {#quick-comparison}

For anyone skimming, here's the whole post in one table:

Approach	What Happens	Pros	Cons
Reactive	Alert → Page on-call	Reliable, fast	No diagnosis
Generative	ChatGPT explains possible causes	Helpful context	Human must act
Agentic	Agent investigates, diagnoses, proposes fix	End-to-end handling	Requires trust and guardrails

FAQ {#faq}

Q: Do these three models replace each other, or work together? They work together — reactive automation still generates the initial trigger, generative AI still supports human-driven investigation and documentation, and agentic AI adds a new layer on top for multi-step autonomous work. None of them eliminates the need for the other two.

Q: Which one should a small network team with no AI experience try first? Generative AI, used interactively for documentation and troubleshooting explanations — it requires no new infrastructure, no write access to devices, and lets the team build intuition for what these models are good at before considering anything autonomous.

Q: Is Agentic AI overkill for a small enterprise network? Often, yes, at least initially — the operational overhead of governance and access scoping only pays off once you have enough recurring, multi-source troubleshooting volume to make the investigation-time savings meaningful.

Q: How do you decide how much autonomy to give an agent? Start read-only. Let it diagnose and recommend for a defined period, compare its conclusions against what your engineers found independently, and only extend action-taking permissions for the specific, narrow set of actions it has proven reliable on.

Q: What's the single biggest risk in this whole progression? Granting write access before trust has actually been earned through a track record — the risk isn't that the AI is unintelligent, it's that broad credentials plus a confidently wrong conclusion is a worse outcome than a slower, correct one.

---

Related Articles

• Agentic AI for Network Engineers: What It Actually Means for BGP, ACI, and Your NOC
• Cisco ACI + NetScaler HA Failover: The Bridge Domain Settings Your Migration Plan Probably Missed
• Cisco ACI Service Graph Management Models Explained
• COOP: Council of Oracle Protocol - Cisco ACI

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.
Contact me for consulting, troubleshooting, design reviews, and project support.

Agentic AI for Network Engineers: What It Actually Means for BGP, ACI, and Your NOC

 I am a network professional with over 18 years of experience in enterprise and data‑center networking. I am a CCIE Data Center certified engineer with strong hands‑on expertise in Cisco Nexus and Cisco ACI design, deployment, troubleshooting, and operations. I work on production ACI fabrics and am available for Cisco ACI and Nexus freelancing or consulting work. 

Every network engineer has lived through some version of this: an EEM applet or a Python script fires a canned remediation the moment a threshold is crossed, and half the time it fixes the symptom while the actual root cause — a flapping optic, a bad BGP peer, a Bridge Domain misbehaving under load — keeps quietly causing damage somewhere else. That gap between "react to a threshold" and "actually understand what's wrong" is precisely the gap that a new category of AI, called Agentic AI, is built to close.

This isn't another "AI will change everything" piece. It's a practical look at where Agentic AI sits relative to the automation tooling you already run — Ansible, EEM, NetBox-driven pipelines, ServiceNow integrations — and where it genuinely changes how a NOC or a network engineering team operates.

Table of Contents

1. Agentic AI in One Sentence
2. Automation You Already Run vs. What an Agent Adds
3. The Agency Spectrum, Mapped to Real Network Tooling
4. Where This Actually Shows Up: NOC, SOC, and Change Management
5. A Worked Example: Packet Loss on an ACI Fabric
6. The Real Risks — Not Hype, Operational Reality
7. Should Network Engineers Be Worried About Their Jobs?
8. Quick-Reference Table for Interviews and Team Discussions
9. FAQ

---

1. Agentic AI in One Sentence {#one-sentence}

An AI agent is given a goal instead of a script — "restore the WAN link," not "if interface down, run these five commands" — and it gathers data, reasons about the cause, takes action, checks whether that action worked, and adjusts if it didn't. The goal persists across steps; a traditional script does not.

2. Automation You Already Run vs. What an Agent Adds {#automation-vs-agent}

Nothing here replaces your existing automation stack — it sits on top of it.

Your EEM applet or monitoring threshold today:

Interface errors > threshold
↓
Send SNMP trap
↓
Restart interface or open a ticket

That's useful, and it's fast. It's also blind — it doesn't know why the errors started, and it can't tell a transient issue from a symptom of something bigger.

What an agent adds on top of the same trigger:

Interface errors > threshold
↓
Pull interface counters, optics DOM data, neighbor CDP/LLDP info
↓
Correlate against recent config changes and similar past incidents
↓
Form a hypothesis (e.g., degrading optic vs. duplex mismatch vs. upstream congestion)
↓
Take or recommend a targeted action
↓
Re-check the interface after the action
↓
Escalate with a documented root cause if it didn't resolve

The script executes a rule. The agent pursues an outcome — and keeps working the problem until the outcome is reached or it runs out of safe options to try.

3. The Agency Spectrum, Mapped to Real Network Tooling {#agency-spectrum}

It helps to place tools you already use on a spectrum, rather than treating "AI" as one bucket.

Level 1 — Reactive (most of your existing automation lives here). SNMP trap handlers, EEM applets, cron-scheduled scripts, simple threshold monitors. No memory of past incidents, no adaptation — same input always produces the same output. Fast and predictable, which is exactly why it's still the right tool for a huge share of network operations.

Level 2 — Adaptive/Generative (where most "AI in networking" products sit today). Think Cisco's AI-assisted troubleshooting features, GitHub Copilot for writing your Python/Ansible, or a chatbot that answers "why is OSPF stuck in EXSTART" using your documentation. These understand context and generate useful output, but they wait for you to ask — they don't go execute a fix on their own.

Level 3 — Autonomous Agentic Systems. This is genuinely new: a system that takes a goal ("keep this VIP available during HA failover," "resolve this WAN packet loss"), independently gathers telemetry across multiple sources, reasons through several possible causes, acts, verifies, and only escalates once it has a real answer or has run out of safe moves.

4. Where This Actually Shows Up: NOC, SOC, and Change Management {#where-it-shows-up}

NOC / Network Operations. An agent watching a multi-vendor environment (routers, switches, firewalls, SD-WAN edges) can triage and prioritize incidents on its own — deciding a flapping BGP session between two branch sites is more urgent than a single access-port CRC error, without a human writing a priority rule for every possible combination.

Root Cause Analysis. Instead of an engineer manually correlating a spike in retransmits with a routing change from two hours earlier, an agent can pull both data sets, line them up on a timeline, and propose the correlation directly.

Security Operations. An agent watching NetFlow/IPFIX and firewall logs can flag an anomaly, pull the relevant session data, and build a preliminary investigation packet before a SOC analyst even opens the ticket.

Change Management. An agent that validates a proposed config change against the current running state, checks for known-bad patterns, and monitors post-change behavior — rolling back automatically if metrics degrade — is a very different (and much more attractive) proposition than a static pre-change checklist.

5. A Worked Example: Packet Loss on an ACI Fabric {#worked-example}

Take a scenario an ACI engineer will recognize: intermittent packet loss reported by an application team, no obvious interface errors.

A Level 1 threshold monitor won't even trigger — nothing crossed a hard threshold. A Level 2 assistant can help you interpret logs once you've pulled them, if you ask the right question. A Level 3 agent, given the goal "identify the cause of reported packet loss between EPG-App and EPG-DB," could independently:

• Pull endpoint learning history for both EPGs from the fabric
• Check for recent Rogue EP Detection or COOP events on the relevant leaf switches
• Cross-reference contract/filter hit counters for drops
• Correlate the timing against any recent Bridge Domain or L3Out changes
• Present a ranked list of likely causes with supporting evidence, rather than a single generic alert

Whether or not it's allowed to act on that fabric autonomously is a separate, important governance decision — but the diagnostic value alone is a meaningful step beyond what threshold-based monitoring can offer.

6. The Real Risks — Not Hype, Operational Reality {#real-risks}

Reliability. An agent can misread telemetry or draw the wrong conclusion with full confidence. Any agent with write access to production network devices needs guardrails — dry-run modes, approval gates for anything beyond read-only diagnostics, and a hard stop on ambiguous situations rather than a forced action.

Access and blast radius. An agent wired into APIC, device CLIs, ServiceNow, and cloud APIs simultaneously has a much larger blast radius than any single script. Scope its credentials as tightly as you would for a junior engineer on their first week — least privilege, not "give it admin so it stops asking."

Auditability. Every action an agent takes on network infrastructure needs to be logged with the reasoning attached, not just the command executed. "Why did it do that" has to be answerable after the fact, especially for anything customer-facing.

Cost. Agents that call out to large models repeatedly, on every event, across a busy fabric, can rack up real compute and API cost. Scope which events actually warrant agentic investigation versus a cheaper Level 1 rule.

7. Should Network Engineers Be Worried About Their Jobs? {#job-impact}

Short answer: the job shifts, it doesn't disappear. Someone still has to design the Bridge Domain policy, decide which failover behaviors are acceptable, define what "safe to act autonomously" means for a given system, and be the accountable human when an agent's action needs explaining to a customer or an auditor. The engineers who get the most value out of this shift are the ones who understand the underlying network deeply enough to know when the agent's reasoning is right — and when it's confidently wrong.

8. Quick-Reference Table {#quick-reference}

Concept	What It Means in Networking Terms
Agentic AI	A system that pursues a network operations goal autonomously, not just a single scripted response
Reactive (L1)	EEM applets, SNMP traps, cron jobs — fast, rule-based, no memory
Adaptive/Generative (L2)	Copilot-style assistants, chat-based troubleshooting help — context-aware, but user-driven
Autonomous Agent (L3)	Goal-driven, multi-step reasoning, takes action, verifies outcome, escalates only when needed
Biggest operational risk	Uncontrolled write-access blast radius, not the AI's intelligence itself
What doesn't change	You still need to understand BGP, ACI, and your own topology to know when the agent is wrong

Match the Following — Agentic AI Concepts {#match-the-following}

A quick self-check to see if the concepts above have landed. Match each term on the left to its correct description on the right, then check your answers below.

Terms

1. Trade-offs
2. Agents vs Automation
3. Agency Spectrum
4. Agentic AI
5. Key Characteristics

Descriptions A. Agents pursue goals; automation follows scripts B. Goal-directed, autonomous, multi-step reasoning, action-taking C. Systems that perceive, reason, act, and learn autonomously D. More capability brings more risk — design carefully E. Reactive → Adaptive → Autonomous

<details> <summary>Click to reveal answers</summary>

Term	Correct Match
Trade-offs	D — More capability brings more risk, design carefully
Agents vs Automation	A — Agents pursue goals; automation follows scripts
Agency Spectrum	E — Reactive → Adaptive → Autonomous
Agentic AI	C — Systems that perceive, reason, act, and learn autonomously
Key Characteristics	B — Goal-directed, autonomous, multi-step reasoning, action-taking

</details>

FAQ {#faq}

Q: Is Agentic AI just a rebrand of AIOps? There's real overlap, but AIOps historically leans toward correlation and alerting across telemetry, while Agentic AI specifically emphasizes autonomous, multi-step action-taking toward a goal — not just smarter alerting.

Q: Can an agent safely make changes on a production ACI fabric today? Most mature deployments today restrict agents to read-only diagnostics and recommendations, with a human approving any change — full autonomous write access is still the exception, not the norm, and should be earned incrementally with strong audit trails.

Q: What's the first place a network team should try this, low-risk? Root cause correlation and pre-change validation are generally the safest starting points — high diagnostic value, no direct write access to production state required.

Q: Does this replace tools like Ansible or NetBox? No — an agent typically calls the same APIs and playbooks you already have; it decides when and why to use them based on reasoning about a goal, rather than replacing the underlying automation plumbing.

Q: How is an AI agent different from an EEM applet I already run today? An EEM applet executes a fixed sequence of commands the moment a condition is met and stops there. An agent, given the same trigger, gathers additional context, considers multiple possible causes, chooses among them, and verifies whether its action actually resolved the issue — closer to how a senior engineer would work the ticket.

Q: Do I need a data science background to work with Agentic AI in networking? No — the highest-value skill remains deep knowledge of your own network (BGP, ACI, SD-WAN, whatever you run). Understanding prompts, tool integration, and guardrail design is helpful, but it builds on network expertise rather than replacing it with a data science one.

Q: What's a realistic first pilot project for a network team? A read-only diagnostic agent scoped to a single well-understood problem — such as correlating interface errors with recent config changes — is a low-risk way to evaluate the technology before granting any write access to production devices.

Q: Are vendors like Cisco actually shipping Level 3 autonomous agents today? Most current vendor "AI" features in networking sit at Level 2 (assistants and recommendation engines) rather than fully autonomous Level 3 agents; genuinely autonomous, write-capable agents in production networks are still early and typically limited in scope.

---

Related Articles

• Cisco ACI + NetScaler HA Failover: The Bridge Domain Settings Your Migration Plan Probably Missed
• Cisco ACI Service Graph Management Models Explained
• COOP: Council of Oracle Protocol - Cisco ACI
• Cisco ACI Mis-Cabling Protocol (MCP) – Loop Detection Simplified