Networklearner

Friday, 24 July 2026

Understanding AI Agents for Network Engineers: LLMs, Prompts, Tokens and Context Explained

Artificial Intelligence is rapidly becoming part of modern network operations. From troubleshooting assistants to automated change management, AI agents are beginning to work alongside network engineers.

But what exactly powers these agents?

If you've configured routing protocols, built automation scripts, or managed network monitoring systems, understanding AI agents isn't as complicated as it might seem. This guide walks through the core building blocks of AI agents using networking analogies that any network engineer will recognize.

What Is an AI Agent?

An AI agent is a software system that can understand a goal, make decisions, and take actions to achieve that goal.

Compare it to a traditional network automation script. A Python script might be programmed to check interface status, detect a down link, and send an alert — it follows predefined instructions, nothing more.

An AI agent works differently. Instead of following a fixed set of rules, it can:

Understand a request written in natural language
Analyze available information
Decide which action to perform
Adapt when unexpected situations occur

That flexibility is what makes AI agents powerful.

Traditional Automation vs. AI Agents

Traditional automation follows rigid logic, such as IF Interface Down → Send Email. It's predictable, easy to troubleshoot, and great for repetitive tasks — but it cannot handle unknown scenarios and lacks contextual understanding.

AI-powered agents focus on outcomes rather than rigid instructions. Given a prompt like "Analyze this network outage and suggest possible root causes," an agent can review logs, analyze symptoms, identify possible issues, and recommend troubleshooting steps. It understands natural language, adapts to new situations, and can handle partially known problems.

The LLM: The Brain Behind Every AI Agent

At the center of every AI agent is a Large Language Model (LLM) — think of it as the control plane of the system. Just as a network's control plane makes routing decisions, the LLM makes reasoning decisions: understanding requests, processing information, choosing tools, and generating responses. Without the LLM, an AI agent is just a collection of disconnected tools.

Why the System Prompt Matters

The System Prompt is like a design document combined with operating procedures. It tells the AI who it is, what it should do, what to avoid, and which tools it can use — for example: "You are a Network Operations Assistant. Help engineers troubleshoot enterprise networks. Explain reasoning clearly. Use available monitoring tools when necessary." Without a solid system prompt, an AI agent can produce inconsistent or irrelevant responses.

Understanding Temperature: The Creativity Dial

Temperature controls how predictable or creative an AI's output is.

Temperature = 0 — the model always picks the most likely answer. Best for troubleshooting, configuration validation, and change management, where consistency and accuracy matter most.
Higher temperature — more creative and exploratory output, useful for brainstorming and content generation, but with a higher risk of inconsistent answers and hallucinations.

For network operations, a range of 0 to 0.3 is generally preferred.

What Are Tokens?

A token is a small unit of text processed by an LLM. As a rough rule of thumb, one token is about 4 English characters, and 100 words is roughly 130 tokens. Tokens directly affect processing cost, response speed, and context limits.

The Context Window: AI's Working Memory

The context window is effectively the RAM of an AI agent — it holds the system prompt, tool definitions, conversation history, and the current request. The larger the window, the more the AI can "remember" during a session.

Just as troubleshooting gets harder if a monitoring system forgets earlier alerts mid-investigation, an AI agent's performance can degrade once its context window fills up: older details get dropped, and accuracy can suffer. Efficient context management is essential for enterprise AI solutions.

Other Important AI Agent Parameters

Max Tokens — the output limit for a single response, like a bandwidth cap.
Stop Sequences — signals that tell the model when to stop generating, often used when calling external tools or handing control back to a user or system.
Top-P — controls how many candidate next-words the model considers; lower values are more focused, higher values more diverse.
Frequency Penalty — reduces repetitive language, useful when generating reports, documentation, and troubleshooting guides.

Real-World Network Engineering Use Cases

Network troubleshooting — log analysis, root cause identification, incident summaries
Configuration assistance — config review, error detection, best-practice recommendations
Documentation generation — design docs, change records, runbooks
Knowledge management — searching engineering documentation, answering technical questions, step-by-step procedures

Key Takeaways

LLMs act as the reasoning engine of AI agents
System prompts define behavior and scope
Temperature controls creativity and consistency
Tokens are the building blocks of AI processing
Context windows determine what the agent can remember
Proper configuration leads to more reliable AI agents

Final Thoughts

Just as networking evolved from manual CLI configuration to automation, the industry is now entering an era of intelligent, AI-assisted operations. Understanding LLMs, prompts, temperature, and context windows gives network engineers the foundation to work with this next generation of tools — and you don't need to become a data scientist to get there. If you already understand how networks make decisions, you're closer to understanding AI than you might think.

FAQ

What is an AI agent?

A software system that uses an LLM to understand goals, make decisions, and perform tasks — adapting to new situations rather than following fixed rules.

How is it different from traditional network automation?

Traditional automation follows fixed rules ("if interface down, alert"). An AI agent can handle open-ended requests ("investigate why Branch A is slow") by analyzing logs and configs and reasoning about likely causes.

Can AI agents replace network engineers?

No. They're force multipliers for troubleshooting, documentation, and automation — but engineers remain responsible for design, security, governance, and business decisions.

What is hallucination?

When an AI generates plausible-sounding but inaccurate or fabricated information (e.g., a command or error message that doesn't exist). Always verify AI output before acting on it.

Which AI skills should network engineers learn first?

Prompt engineering, AI agents, generative AI fundamentals, basic Python, REST APIs, network automation, retrieval-augmented generation (RAG), and agentic AI workflows.

Thursday, 23 July 2026

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.

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

Why BGP Maximum-Paths Wasn't the Problem: Understanding Port-Channel Load Balancing and Traffic Imbalance

Recently, we investigated a case where traffic utilization across port-channel member interfaces was significantly unbalanced. One of the links was carrying the majority of the traffic while the other link remained underutilized. Since the environment was already configured with BGP maximum-paths 8, the initial assumption was that BGP load balancing might not be functioning correctly.

After reviewing the configuration, we confirmed that BGP ECMP was operating as expected and that multiple equal-cost paths were available. This shifted our focus from the routing layer to the port-channel load-balancing mechanism.

Why BGP Was Not the Problem

The configuration already included BGP maximum-paths 8, which allows the router to install and use multiple equal-cost paths. This means the network was capable of leveraging several routes simultaneously, eliminating BGP as the primary suspect.

It is important to understand that BGP ECMP and port-channel load balancing serve different purposes. BGP decides which routing path should be used, while the port-channel hashing algorithm determines which physical member link will carry the traffic.

Even when ECMP is working perfectly, traffic can still become concentrated on a single port-channel member if the hashing algorithm maps large flows to the same interface.

Current Hashing Algorithm Analysis

The port-channel was configured with the src-dst-ip enhanced load-balancing algorithm.

This algorithm uses only the source and destination IP addresses to calculate the hash. If a traffic flow continuously uses the same source and destination IP addresses, all packets belonging to that flow will be forwarded through the same member interface.

For example, a database replication stream between two servers will always generate the same hash result. As a result, the entire flow remains pinned to a single physical link regardless of how much unused bandwidth exists on other members of the port-channel.

This behavior is normal because Cisco port-channel load balancing is flow-based rather than packet-based. The objective is to avoid packet reordering and maintain application performance.

Considering src-dst-mixed-ip-port

To improve traffic distribution, we evaluated changing the load-balancing algorithm from src-dst-ip enhanced to src-dst-mixed-ip-port.

Unlike the current configuration, this method includes both Layer 3 and Layer 4 information in the hash calculation. In addition to source and destination IP addresses, it also considers source and destination TCP or UDP port numbers.

This creates a larger number of unique hash combinations and increases the likelihood that different application sessions between the same endpoints will be distributed across multiple member links.

In environments where users, applications, or servers establish numerous simultaneous connections, this approach often results in significantly improved bandwidth utilization across the port-channel.

Important Considerations Before Making the Change

Changing the load-balancing algorithm is generally considered a non-disruptive operation on most Cisco platforms. However, all existing traffic flows will be immediately re-hashed.

As traffic gets redistributed across available links, there may be a brief period of packet reordering. While this is typically minor and transparent to most applications, implementing the change during a maintenance window or low-utilization period is recommended.

Another important consideration is that even with Layer 4 information included, the load-balancing mechanism remains flow-based. If the imbalance is caused by a single high-bandwidth elephant flow, the entire flow will still be assigned to one member link.

In such cases, changing the hashing algorithm may provide only limited improvement.

Recommended Validation After the Change

After implementing the new load-balancing method, monitor interface utilization and traffic patterns for several hours.

Review the following:

Port-channel member utilization

Top bandwidth-consuming flows

NetFlow or telemetry statistics

Application traffic distribution

Interface counters

If traffic becomes more evenly balanced across the member interfaces, the change has achieved its objective. If the imbalance continues, further investigation should focus on identifying large elephant flows or application-specific traffic patterns.

Conclusion

Based on our analysis, BGP maximum-paths was not contributing to the bandwidth imbalance. The routing layer was functioning correctly and supporting multiple equal-cost paths as designed.

The more likely cause was the src-dst-ip enhanced hashing algorithm, which uses only Layer 3 information and can result in traffic concentration when a small number of large flows dominate bandwidth consumption.

Moving to src-dst-mixed-ip-port is a logical and widely adopted optimization because it introduces Layer 4 awareness into the hashing calculation and generally improves traffic distribution when multiple flows exist between the same source and destination hosts.

While it may not solve scenarios involving a single elephant flow, it represents the most appropriate next step before exploring more advanced traffic-engineering options

Wednesday, 22 July 2026

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:

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.
Confirm which interface ND is actually using. Nexus Dashboard > Infrastructure > Cluster Configuration shows whether the data or management network is used for fabric connectivity.
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.
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.
Check for SSL inspection/proxy devices sitting in the path — APIC's certificate handling doesn't play well with transparent SSL interception.
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.

Saturday, 11 July 2026

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.

The Three Models, in Networking Terms
The Same Incident, Handled Three Ways
Decision Framework: Which One Do You Actually Need?
Scoring Checklist for Your Own Use Case
Where Governance and Cost Actually Change
A Common Mistake: Over-Automating Too Early
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.

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

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.

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

Trade-offs
Agents vs Automation
Agency Spectrum
Agentic AI
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.

Friday, 24 July 2026

Understanding AI Agents for Network Engineers: LLMs, Prompts, Tokens and Context Explained

What Is an AI Agent?

Traditional Automation vs. AI Agents

The LLM: The Brain Behind Every AI Agent

Why the System Prompt Matters

Understanding Temperature: The Creativity Dial

What Are Tokens?

The Context Window: AI's Working Memory

Other Important AI Agent Parameters

Real-World Network Engineering Use Cases

Key Takeaways

Final Thoughts

FAQ

Related Reading on Networklearner

Thursday, 23 July 2026

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

TL;DR

The Symptom

Ruling Out BGP First

Checking the Current Hashing Algorithm

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

The Fix: Add Layer 4 to the Hash

Before You Make the Change

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

Verification Checklist

FAQ

Conclusion

Related Articles

Why BGP Maximum-Paths Wasn't the Problem: Understanding Port-Channel Load Balancing and Traffic Imbalance

Wednesday, 22 July 2026

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

Why this trips people up

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

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

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

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

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

Troubleshooting checklist {#troubleshooting}

FAQ {#faq}

Related reading on Networklearner

Saturday, 11 July 2026

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

Table of Contents

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

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

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

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

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

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

Quick Comparison Table {#quick-comparison}

FAQ {#faq}

Related Articles

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

Table of Contents

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

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

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

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

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

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

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

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

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

FAQ {#faq}

Related Articles

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