AI and machine learning in network operations

A real-life situation

Monday, 9 a.m. Users in one building say Wi-Fi is "slow". Overnight the network produced thousands of Syslog messages and millions of flow records. Reading them by hand would take a day. Your controller's analytics page already shows a note: "Client onboarding time in Building B is far above its normal Monday level; most failures are DHCP timeouts." That points you straight at the DHCP server.

Ten minutes later a colleague asks an AI chatbot how to add a VLAN to a trunk, pastes the answer into a switch, and cuts off every VLAN on the link. Both stories are AI in network operations. One saved time; the other caused an outage. This lesson explains what these tools are, what they are good at, and where they fail.

What it is

• Artificial intelligence (AI): the broad field of making computers do tasks that normally need human judgement, such as spotting patterns, making predictions or writing text.
• Machine learning (ML): a part of AI where the system learns patterns from data instead of following rules a programmer wrote. Feed it months of interface counters and it learns what "normal" looks like.

Machine learning comes in three main types:

Network products use AI in two broad ways:

Generative AI tools are usually built on a large language model (LLM): a model trained on huge amounts of text to predict likely next words. That is why its answers read well, and also why they can be wrong in ways that sound right.

Why it works that way

Traditional monitoring uses static thresholds: "alert if CPU is above 80%" or "alert if a link is above 90%". These are crude. A backup link at 95% at 2 a.m. may be perfectly normal, while 40% on a link that usually sits at 5% may be an attack.

Machine learning builds a dynamic baseline for each metric: what is normal for this link, at this hour, on this day of the week. It then flags anomalies, values far from that baseline. With thousands of devices, only a machine can watch every metric that closely. It can also correlate events, noticing that 200 separate alerts started within a minute of one switch reboot.

Generative AI works for a different reason: it has seen a lot of text, including documentation and configurations, so it can draft and summarize quickly. But it predicts what is likely, not what is true for your network, platform and software version. It doesn't know your topology unless you tell it.

How it works step by step

A predictive AI feature, such as the assurance analytics in a controller, follows a pipeline:

In the course lab, Catalyst Center plays the analytics role:

Generative AI fits into the same workflow at the ends: a person asks in plain language ("why is Building B slow?"), and the assistant queries the data and summarizes the answer, or drafts a change for review. Cisco, like other vendors, now builds both kinds of feature into its management platforms; the details change quickly from release to release.

How to configure the network for it

There is no "AI" command on a router. What you configure is the data the AI depends on. Bad data means bad answers, so two things matter most: every device must send its data, and every timestamp must be accurate so events can be lined up. On SW1 in the lab (R1 at 10.10.1.1 provides time):

Details of each are in NTP on Cisco IOS and SNMP and Syslog.

How to verify it

SW1#show ntp status
Clock is synchronized, stratum 3, reference is 10.10.1.1
...

SW1#show logging | include Trap|Logging to
    Trap logging: level informational, 58 message lines logged
        Logging to 10.10.0.10  (udp port 514, audit disabled,

Using generative AI safely: a worked example

The colleague in the opening story asked an assistant: "How do I add VLAN 30 to the trunk on Gi1/0/24?" The answer looked reasonable:

SW1#show interfaces trunk
Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/24    on               802.1q         trunking      1

Port        Vlans allowed on trunk
Gi1/0/24    30

Port        Vlans allowed and active in management domain
Gi1/0/24    30

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/24    30

A safe routine for any AI-drafted change:

1. Give context: platform, software version, what the interface does now.
2. Read every line and make sure you understand what it does. If you can't explain it, don't paste it.
3. Check the command reference for your platform and version.
4. Test in a lab, or with a dry run such as Ansible --check.
5. Apply through normal change control, with a rollback plan.
6. Verify with show commands afterwards.

What goes wrong and how to handle it

Common mistakes

• Treating AI output as fact. It is a suggestion until you have verified it.
• Mixing up the terms: predictive AI analyses and forecasts; generative AI creates content.
• Thinking machine learning needs no data work. Without clean, complete, time-synchronized data it learns the wrong things.
• Letting an AI make changes directly in production with no review or rollback.
• Pasting configurations with secrets into public AI tools.

💡 Exam tip: the CCNA v1.1 blueprint added AI and machine learning in network operations. Expect conceptual questions: tell predictive AI (baselines, anomaly detection, forecasting) from generative AI (creating text and configs from prompts), know that ML learns from data rather than fixed rules, recognize supervised vs. unsupervised learning, and know the limits, especially hallucination and the need for human verification. No commands are tested.

Key takeaways

• AI is the broad field; machine learning learns patterns from data.
• Predictive AI: dynamic baselines, anomaly detection, forecasting, root-cause hints.
• Generative AI: assistants that summarize, answer questions and draft configs.
• Good AI needs good data: configure Syslog, SNMP, flows and accurate NTP.
• AI output can be confidently wrong. Review, test, then verify on the device.

Check yourself