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.

Why BGP Maximum-Paths Wasn't the Problem: Fixing Uneven Port-Channel Traffic on Cisco Nexus and IOS

 If you've ever pulled up interface counters and seen one port-channel member carrying 70–80% of the traffic while its bundle-mate sits nearly idle, your first instinct is probably the same one we had: "BGP load balancing must be broken."

It usually isn't. Here's the case we worked through, why BGP was innocent from the start, and the actual fix.

TL;DR

• Symptom: One port-channel member interface was carrying the majority of traffic; the other was underutilized.
• First suspect: BGP maximum-paths — already configured correctly, and confirmed working via ECMP.
• Real cause: The port-channel load-balancing algorithm (src-dst-ip enhanced) was hashing large, persistent flows onto the same physical link every time.
• Fix: Move to src-dst-mixed-ip-port (or the NX-OS equivalent src-dst ip-l4port) to add Layer 4 entropy to the hash.
• Caveat: If the imbalance is caused by a single "elephant flow," even L4 hashing won't split it — that needs a different tool entirely.

The Symptom

The environment was already running router bgp with maximum-paths 8 configured, so multiple equal-cost paths were expected to be installed and used. But interface counters told a different story — one member of the port-channel was consistently running hot while the other stayed quiet, day after day, regardless of overall traffic volume.

Router# show interface port-channel 10 | include rate
  5 minute input rate 812000000 bits/sec, 95000 packets/sec
  5 minute output rate 790000000 bits/sec, 92000 packets/sec

Router# show interface gigabitethernet 1/1 | include rate
  5 minute input rate 780000000 bits/sec, 91000 packets/sec

Router# show interface gigabitethernet 1/2 | include rate
  5 minute input rate 32000000 bits/sec, 4000 packets/sec

That's roughly a 96/4 split across two members of the same bundle — not something you'd expect from a healthy port-channel.

Ruling Out BGP First

Before touching anything on the switching side, we confirmed the routing layer was actually doing its job.

Router# show ip bgp summary
Router# show ip route 10.20.30.0
Routing entry for 10.20.30.0/24
  Known via "bgp 65001", distance 20, metric 0
  Routing Descriptor Blocks:
  * 192.168.1.1, from 192.168.1.1
      192.168.1.2, from 192.168.1.2

Two next-hops installed for the same prefix, exactly as maximum-paths 8 should produce when the paths are equal-cost. BGP ECMP was functioning correctly — routing decisions were being made across multiple paths, so it made no sense to keep chasing BGP config as the root cause.

That's the key thing to internalize: BGP ECMP and port-channel load balancing are two completely separate mechanisms operating at two different layers.

Layer	Mechanism	Decides
Layer 3 (Routing)	BGP maximum-paths / ECMP	Which path (next-hop) traffic takes
Layer 2 (Switching)	Port-channel hash algorithm	Which physical member link within a bundle carries a given flow

Even with BGP perfectly distributing traffic across paths, each of those paths might egress through a port-channel — and it's entirely possible for the hashing algorithm on that port-channel to funnel most flows onto one member link regardless of what BGP is doing upstream.

Checking the Current Hashing Algorithm

Next step: find out what hash algorithm the port-channel was actually using.

On IOS / IOS-XE:

Router# show etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-dst-ip

On Nexus (NX-OS):

Switch# show port-channel load-balance
Port Channel Load-Balancing Configuration:
System: src-dst ip

Both confirmed the same thing: the algorithm was using only Layer 3 information — source and destination IP address — to compute the hash and select a member link.

Why src-dst-ip Pins Big Flows to One Link

The hash is deterministic. Given the same source IP and destination IP, the algorithm produces the same result every single time, which means every packet in that flow is sent down the same physical link.

That's fine when you have many different flows between many different IP pairs — the hash spreads them out reasonably well. It falls apart when a small number of flows dominate the traffic, which is exactly what a database replication stream, a backup job, or a storage sync between two fixed IPs looks like: same source, same destination, forever — one hash result, one link, permanently.

This isn't a bug. Cisco's port-channel load balancing is intentionally flow-based, not packet-based, specifically to avoid packet reordering within a TCP session. The trade-off is that a big, long-lived flow can dominate a single member link even when the bundle as a whole has spare capacity.

The Fix: Add Layer 4 to the Hash

Switching from src-dst-ip to src-dst-mixed-ip-port pulls TCP/UDP source and destination port numbers into the hash calculation alongside the IP addresses.

IOS / IOS-XE:

Router(config)# port-channel load-balance src-dst-mixed-ip-port

NX-OS (Nexus):

Switch(config)# port-channel load-balance src-dst ip-l4port

Some Nexus platforms go a step further and support VLAN as an additional hash input for even more entropy:

Switch(config)# port-channel load-balance src-dst ip-l4port-vlan

With source/destination ports added, two different application sessions between the same pair of servers (say, a web server and a database server running several concurrent connections) will now very likely produce different hash results — and land on different physical links — instead of all piling onto whichever link the IP-only hash happened to pick.

In environments with many concurrent sessions between the same endpoints (application servers, load balancers, hypervisor clusters), this alone often meaningfully improves the balance.

Before You Make the Change

A few things worth knowing before you touch a production bundle:

• It's generally non-disruptive on most Cisco platforms — you don't need to shut the port-channel.
• Every existing flow gets re-hashed immediately. Expect a brief window of packet reordering as flows redistribute across members. It's usually transparent to TCP, but schedule the change for a maintenance window or low-traffic period if the environment is sensitive (VoIP, storage replication, etc.).
• This is still flow-based hashing, just with more inputs. A single elephant flow — one enormous, sustained stream between one IP:port pair — will still be pinned to one physical link even after adding L4 information. Layer 4 hashing splits up multiple flows between the same hosts; it does not split a single flow.

If It's an Elephant Flow, Hashing Alone Won't Fix It

If, after the change, one link is still running noticeably hotter than the others, don't keep tweaking the hash algorithm — look for a dominant flow instead:

Router# show interface port-channel 10 | include rate
Switch# show flow monitor <name> cache

or pull top talkers from NetFlow/sFlow/telemetry. If you find one flow consuming most of the bandwidth, your real options are traffic engineering (splitting the application across multiple sessions/IPs if possible), platform-specific dynamic load balancing features (several Nexus platforms support Dynamic Load Balancing, which rebalances flows based on real-time link utilization rather than a static hash), or simply accepting that a single-flow workload isn't a great fit for port-channel-based scaling in the first place.

Verification Checklist

After changing the algorithm, give it a few hours under real traffic and check:

• Port-channel member interface utilization (show interface … | include rate on each member)
• Top bandwidth-consuming flows (NetFlow/sFlow/telemetry)
• Interface error/discard counters (rule out anything unrelated masquerading as imbalance)
• Application-level traffic distribution if you have flow visibility tools

If the split moves from something like 96/4 toward 55/45 or 60/40, the change did its job. If it barely moves, you're very likely looking at an elephant-flow scenario rather than a hashing-algorithm problem.

FAQ

Does changing the port-channel load-balancing algorithm cause an outage? No — on most Cisco IOS, IOS-XE, and NX-OS platforms this is a non-disruptive change. Existing flows get re-hashed and may briefly reorder, but the port-channel itself stays up.

Will src-dst-mixed-ip-port always produce perfectly even traffic distribution? No. It improves distribution when multiple flows exist between the same endpoints, but a single very large flow will still be pinned to one member link, since hashing is flow-based, not packet-based.

How do I check the current load-balancing algorithm on a Nexus switch? show port-channel load-balance on NX-OS. On IOS/IOS-XE, use show etherchannel load-balance.

Is BGP maximum-paths related to port-channel hashing at all? No — they operate at different layers. maximum-paths controls how many equal-cost paths BGP installs at Layer 3. Port-channel hashing controls which physical member link, at Layer 2, carries a given flow once it's already been routed onto that path.

What's the best load-balancing algorithm for Cisco port-channels in general? There isn't a universal "best" — it depends on traffic patterns. src-dst-mixed-ip-port (or NX-OS's ip-l4port) is a strong general-purpose default for environments with many concurrent sessions between the same hosts, since it adds the most useful entropy without added complexity.

Conclusion

BGP maximum-paths was never the issue in this case — it was correctly installing and using multiple equal-cost paths exactly as designed. The imbalance lived one layer down, in the port-channel's src-dst-ip hashing algorithm, which pins any given source/destination IP pair to a single physical link. Moving to src-dst-mixed-ip-port added Layer 4 awareness to the hash and meaningfully improved distribution — with the caveat that a genuine elephant flow needs a different fix entirely.

The broader lesson: when you see uneven link utilization on a bundle, don't assume the routing protocol is at fault. Check where the imbalance actually lives — Layer 3 path selection or Layer 2 hash distribution — before you start changing BGP configuration that may already be working exactly as intended.

---

Related Articles

If this was useful, these go deeper on the BGP and Cisco fundamentals that sit underneath this issue:

• Weight Attribute - BGP
• BGP Attributes: Well Known vs Optional
• BGP Attribute - AS Prepend
• MTU in EIGRP Metric
• Forward Error Correction (FEC) in Cisco ACI
• BGP: Active Open Failed - No Route to Peer

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.