How We Reduced Manual CLI Changes by 60% Using NETCONF and YANG: A Network Automation Story by Ashwani Sugandhi, Cisco Network Engineer

Expert Insight by

Ashwani Sugandhi

Network & Automation Engineer at Cisco Systems

Network Engineering / Network AutomationLinkedIn

Ashwani spent 4+ years at Cisco Systems automating enterprise data center operations for Microsoft, Standard Chartered Bank, Samsung, and Duke Energy. She holds CCNP, CCNA, and Cisco DevNet Associate certifications — a rare triple that spans both traditional networking and programmable infrastructure. She led the Master Automation Plan that standardized automation practices across Cisco project teams, trained new hires on Python and Robot Framework, and is currently pursuing an M.S. in Computer Science at the University of Cincinnati.

Verified Expert

Hundreds of CLI changes per week. That was the reality on one of Cisco's largest Microsoft data center engagements. Every interface configuration, every BGP neighbor, every QoS policy — typed by hand into a terminal, verified by eye, documented in a spreadsheet.

Then we started pushing structured configurations through NETCONF using YANG models. Not scripts that scraped CLI output. Not Ansible playbooks that still sent raw commands under the hood. Actual model-driven automation — where the network device understands the intent, validates the schema, and either accepts the change or rejects it cleanly.

Within months, 60% of manual CLI changes never touched a human keyboard again. But the technology was the easy part. The hard part was everything else.

Most network engineers think they're doing automation. They're not. They're doing faster typing.

There's a spectrum, and most teams are stuck at level 1:

At Microsoft, we operated between Level 2 and Level 3. The difference between Level 1 and Level 2 is night and day. When a Python script sends a CLI command, the device has no idea whether the command is syntactically valid, semantically correct, or even intended for that platform. It just executes whatever text it receives. With NETCONF and YANG, the device understands the data model. It validates the configuration against a schema before applying it. If something is wrong, it rejects the entire transaction — no partial configs, no half-applied changes sitting on a live production device.

Everyone teaches you Python for network automation. And you need it — Python is the glue. But Python is a language, not an architecture. The question isn't "do you know Python?" It's "do you know what to build with it?"

Here's the stack that worked across Microsoft data centers, Standard Chartered Bank's ACI fabric, and Samsung's VXLAN environments:

NETCONF + ncclient: Structured Configuration

NETCONF (RFC 6241) is the protocol. ncclient is the Python library. Together, they let you push structured XML configurations to network devices over SSH.

Here's what an actual NETCONF config push looks like in production. This isn't a tutorial example — it's the pattern we used to configure BGP neighbors across hundreds of IOS-XR routers:

from ncclient import manager

bgp_config = """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <bgp xmlns="http://openconfig.net/yang/bgp">
    <global>
      <config>
        <as>65001</as>
        <router-id>10.0.0.1</router-id>
      </config>
    </global>
    <neighbors>
      <neighbor>
        <neighbor-address>10.0.0.2</neighbor-address>
        <config>
          <peer-as>65002</peer-as>
          <description>DC-SPINE-02</description>
        </config>
      </neighbor>
    </neighbors>
  </bgp>
</config>
"""

with manager.connect(
    host="router-01.dc.microsoft.com",
    port=830,
    username=username,
    password=password,
    hostkey_verify=False,
    device_params={"name": "iosxr"}
) as m:
    response = m.edit_config(target="candidate", config=bgp_config)
    m.commit()

The critical difference from CLI: if the YANG model validation fails — wrong data type, missing required field, invalid neighbor address — the device rejects the entire change. No half-applied configuration. No production outage because one field was wrong.

YANG Models: The Schema That Makes It Work

YANG (RFC 7950) is the data modeling language that defines what a valid configuration looks like. Think of it as a schema for your network. Without YANG, NETCONF is just XML over SSH. With YANG, every configuration element has a defined type, constraints, and relationships.

gNMI + OpenConfig: Real-Time Telemetry

SNMP polling every 5 minutes tells you what happened 5 minutes ago. When a link flaps or a BGP session drops, 5 minutes is an eternity.

gNMI (gRPC Network Management Interface) with OpenConfig models provides streaming telemetry — the device pushes interface counters, routing state, and health metrics in real time. At Microsoft, we used this to replace SNMP polling with sub-second visibility into interface utilization and routing metrics.

PyATS + Robot Framework: Automated Validation

Pushing configs is half the job. Validating that they worked is the other half. PyATS (Python Automated Test System) from Cisco provides structured parsers for device output, so you can validate post-change state programmatically:

• Did the BGP neighbor come up?
• Is the interface in the correct VLAN?
• Are the expected routes in the routing table?

Robot Framework sits on top, providing readable test cases that non-Python engineers can understand and maintain.

This was the largest and most complex engagement — validating and automating large-scale data center topologies supporting IPv4/IPv6, BGP, MPLS, Segment Routing, VXLAN, QoS, and MACsec.

The Problem

Microsoft's data center fabric had rigorous standards. Every network change — interface configuration, routing policy update, QoS adjustment — required manual validation against Microsoft's specifications. Before automation, this meant:

• Engineers typing CLI commands one device at a time
• Manual comparison of running configs against baseline specifications
• Regression testing performed by hand after every software upgrade
• Throughput and latency benchmarking using Spirent — results validated manually

The volume was relentless. Hundreds of changes per sprint, across multiple device platforms (IOS-XR, NX-OS), with zero tolerance for deviation from Microsoft's standards.

The Solution

We replaced manual CLI operations with NETCONF-based configuration automation using Python and ncclient. The approach:

1. Define configurations as YANG-modeled templates — BGP neighbors, interface parameters, routing policies became structured data, not CLI scripts
2. Push via NETCONF with schema validation — the device validates before applying, eliminating typo-induced outages
3. Validate with PyATS and Robot Framework — automated post-change verification confirms the config produced the intended state
4. Benchmark with Spirent — traffic generation and performance analysis validated throughput and latency against Microsoft's standards

What Stayed Manual (And Why)

The 40% that remained manual wasn't a failure — it was a design decision. Some operations require human judgment:

• Troubleshooting live issues — when a BGP session flaps at 2 AM, you need an engineer reading show commands and making real-time decisions
• One-off debugging — packet captures, traceroutes, and protocol-level analysis don't lend themselves to templates
• Edge cases in new deployments — first-time configurations for new topologies require human validation before they can become templates

Automation replaces the repeatable. It amplifies the engineer — it doesn't eliminate them.

At Standard Chartered Bank, the challenge wasn't configuration — it was validation. The bank's ACI (Application Centric Infrastructure) data center fabric required rigorous pre- and post-change checks for every maintenance window. Each check was manual, time-consuming, and prone to human oversight.

The Problem

The Solution

We automated the entire pre/post-check workflow using Robot Framework with TextFSM for structured parsing:

• Pre-check automation: Scripts captured the state of ACI fabric — tenant configurations, endpoint groups, contracts, interface status — in a structured format before any change
• Post-check automation: The same scripts ran after the change, comparing results against the pre-change baseline
• Deviation alerting: Any difference between pre and post states was flagged automatically

But the real breakthrough was the CI/CD pipeline built with GitHub Actions:

The Results

The APIC API automation scripts earned recognition from Cisco leadership for creating new business opportunities in the APJC region — proving that automation isn't just an operational efficiency play, it's a revenue driver.

The Governance Battle

The hardest part wasn't building the pipeline. It was getting approval to use it.

Enterprise banks have strict change management governance. Every tool that touches production infrastructure requires security review, compliance sign-off, and integration with existing ITSM workflows. The technical build took weeks. The governance approval took months.

The lesson: if you're building network automation for a regulated industry, start the compliance conversation on day one — not after the code is written.

This one was about speed. Samsung needed VXLAN Testing Automation scripts — and they needed them fast.

The Sprint

Ten to twelve Robot Framework scripts per week. For an entire month. Each script validated a specific aspect of VXLAN fabric behavior: overlay tunnel establishment, VTEP discovery, VNI-to-VLAN mappings, BUM traffic handling, multi-tenancy isolation.

Why Speed Matters for Automation ROI

Most automation projects die in a pilot that takes too long. Stakeholders lose patience. Budgets get reallocated. The team moves on to the next priority.

The Samsung sprint proved something important: when automation delivers visible results fast, it generates its own funding. The 40+ scripts we delivered in one month demonstrated enough value that Samsung committed to a $600K expansion of the automation engagement.

Here's the contrarian take that four years at Cisco taught me: network automation failures are almost never technical. The tools work. NETCONF works. Python works. CI/CD works.

The failures are organizational.

The Master Automation Plan

At Cisco, I created the Master Automation Plan to solve exactly these problems. The plan had three pillars:

Instead of every engineer writing their own connection handler, parser, and output formatter, we built shared libraries that everyone used. This improved code reusability by 30-40% across projects.

I designed a training pathway on the Degreed learning platform and ran organization-wide sessions on Python, Robot Framework, and automation best practices. The goal was to make every team member capable of contributing to automation — not dependent on a single "automation person."

Every automation script went through code review, linting, and regression testing before deployment. This wasn't optional. If your script didn't pass CI, it didn't deploy. The same discipline that software engineering teams take for granted was completely absent from network operations.

After four years of using these tools in production across multiple enterprise clients, here's the unfiltered assessment — what works, what doesn't, and when to use each.

The Tool Nobody Talks About: Culture

No tool in this list matters if the team doesn't trust automation. The engineers who have been typing CLI commands for 15 years need to see automation succeed — in production, on their devices, without breaking anything — before they'll adopt it. That means starting small, proving value fast, and never deploying untested automation to production.