The Fragility of the Manual CLI
I once spent six hours on a Tuesday night manually updating VLAN tags across 40 access switches. It was mind-numbing work. Halfway through, I fat-fingered a single IP address on a core trunk link, instantly dropping 200 users from the network. This is the inherent risk of the Command Line Interface (CLI). When you are managing 500 devices, a 1% error rate means five major outages.
The CLI was built for human eyes, not for scripts. It produces unstructured text that varies between a Cisco Catalyst running IOS-XE and a Juniper MX series. To automate the CLI, you usually have to rely on Regular Expressions (Regex) to “scrape” data. This approach is brittle; a simple software update that changes a single space in a command output can break your entire automation pipeline. We need a more robust way to talk to our hardware.
YANG and NETCONF: The Modern Standards
To move toward true Infrastructure as Code (IaC), we need a standardized way to model data and a reliable protocol to move that data. This is where the combination of YANG and NETCONF changes the game. This shift moves us from sending “commands” to managing “state.”
YANG: The Data Modeling Blueprint
YANG (Yet Another Next Generation) acts as the schema for your router. If you have ever worked with databases, think of YANG as the table definition. It dictates exactly what data is valid. For instance, a YANG model for an interface ensures the “MTU” is an integer between 64 and 9216, rather than just a random string of text.
Using YANG models like OpenConfig allows you to write one script that works across multiple vendors. You no longer need to care if the specific command is ip address or set address. You simply provide the data that fits the model, and the device handles the rest. This standardization can reduce the time spent writing vendor-specific logic by up to 70%.
NETCONF: The Reliable Courier
If YANG defines the message, NETCONF (Network Configuration Protocol) is the secure delivery truck. Standardized by the IETF in RFC 6241, it replaces the aging SNMP and the unpredictable CLI. NETCONF runs over SSH and uses XML to ensure every exchange is structured and readable by machines.
The most powerful feature here is the “transactional” nature of changes. Unlike a CLI script that might fail halfway through and leave a router in a broken state, NETCONF supports a candidate configuration. You can push a massive change, validate it, and commit it as a single atomic action. If the validation fails, the router rejects the entire block. This single feature can eliminate the “half-configured” state that causes so many production outages.
Preparing Your Lab
Most enterprise-grade hardware from the last five years supports NETCONF. To follow along, you can use a Cisco IOS-XE device, such as a CSR1000v or a C9000 series switch. First, enable the NETCONF subsystem on your device:
conf t
netconf-yang
username admin privilege 15 password 0 cisco
line vty 0 4
login local
transport input sshOn your management workstation, install the ncclient library. This is the most popular Python library for interacting with NETCONF devices.
pip install ncclientFetching Data Without Regex
Let’s retrieve the running configuration. Instead of parsing a wall of text, we will get structured XML that Python can read like a dictionary.
from ncclient import manager
import xml.dom.minidom
device = {
"host": "10.1.1.5",
"port": 830,
"username": "admin",
"password": "cisco",
"hostkey_verify": False
}
with manager.connect(**device) as m:
# Request the running configuration
config = m.get_config(source='running')
# Pretty-print the XML output
parsed_xml = xml.dom.minidom.parseString(config.xml)
print(parsed_xml.toprettyxml())The output is a predictable XML tree. You can use Python’s ElementTree to grab the IP of GigabitEthernet1 in three lines of code. No complex Regex patterns are required, and the script won’t break if the router adds a new descriptive line to the output.
Pushing Changes with Confidence
Updating an interface description becomes a structured operation rather than a series of typed commands. We send an XML snippet that targets the specific YANG module on the device.
config_data = """
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<interface>
<GigabitEthernet>
<name>2</name>
<description>Uplink_to_Core_01</description>
</GigabitEthernet>
</interface>
</native>
</config>
"""
with manager.connect(**device) as m:
response = m.edit_config(target='running', config=config_data)
if response.ok:
print("Configuration applied successfully!")The response.ok check is vital. It confirms the router accepted the data and applied it. If you sent a malformed XML tag, the router would return an rpc-error. This allows your script to catch errors immediately before they propagate through the network.
Why This Matters for Your Career
The shift toward “Infrastructure as Code” is no longer optional for senior engineers. Companies are moving away from manual hop-by-hop configuration. They want repeatable, version-controlled workflows. Teams adopting NETCONF and YANG often see deployment windows shrink from hours to minutes.
Mastering these tools allows you to integrate your network into CI/CD pipelines. You can test a configuration change in a virtual lab (like CML or GNS3) and then deploy the exact same XML payload to production. This level of precision is impossible with manual CLI entries.
Conclusion
Moving from the CLI to NETCONF and YANG requires a different way of thinking. You stop focusing on the “how” (which commands to type) and start focusing on the “what” (the desired state of the data). While XML might seem verbose compared to a quick CLI command, the reliability it offers at scale is unmatched. Start small by automating a simple task like NTP or DNS updates across your lab. Once you experience the stability of structured data, the CLI will feel like a relic of the past.
