We continue to explore the technical details of Cisco NSO and its role in network automation. Today's topic is NETCONF/YANG, with answers to all the when, where, and how questions. There will be many comparisons with SNMP, especially version 2c, so while a solid understanding of SNMP, its history, and design isn’t mandatory, it definitely provides a good foundation to get the most out of this article on Cisco NSO and network automation.
What is NETCONF/YANG?
NETCONF and YANG are two distinct but closely related technologies:
These two technologies are often discussed together in network automation since they are frequently used in combination, but they are not necessarily dependent on each other.
NETCONF
NETCONF is an XML-based protocol that uses an RPC-style communication model. Unlike SNMP, NETCONF operates as a session where one side identifies as a server and the other as a client.
With the NETCONF call home function—where, unlike SNMP (ignoring traps for now), the device can connect to the management system instead of passively waiting for incoming connections—NETCONF must define who is the server and who is the client. Cisco NSO leverages this feature for network automation by automatically handling devices that "call home."
NETCONF call home provides two immediate advantages:
Instead of creating firewall exceptions for incoming traffic into secure environments, the connection is initiated from the device outward.
The management system becomes more efficient, as it no longer needs to test connections to inactive nodes that may not respond depending on the situation.
Regardless of whether a NETCONF session is established via call home or not, it must meet several requirements that SNMP does not enforce:
Authentication
Confidentiality (encryption)
Guaranteed delivery and execution order
Just like in HTTP, pipelining is allowed—commands can be sent before responses are received—but the responses must be delivered in the same order as the commands were received. This is a key difference from an SNMP walk, where UDP packets can be reordered without violating the protocol standard.
Additionally, a critical aspect of NETCONF is how it handles device capabilities.
A NETCONF session starts with both sides identifying as either a server (receiving commands) or a client(sending commands).
Both sides announce which additional features they support, beyond the required NETCONF core functions.
If both sides support an extra feature, it can be used within that session.
Why is this important?Because many network devices claim to support NETCONF but only implement
basic functionality—or not even that. Just because "NETCONF" appears on a product datasheet doesn’t mean it will work as expected. This is a critical factor for Cisco NSO consultants when working with network automation.
YANG
Yet Another Next Generation (YANG) is a modeling language used to define where and how data is managed in a NETCONF-enabled system.
YANG creates a tree-structured data model, similar to how SNMP works. A YANG file for a device serves the same purpose as an SNMP MIB file, specifying:
Where a specific data variable is located within the hierarchy
How the data should be interpreted
Which values are acceptable and which are not
Just as SNMP MIB files define variables in ASN.1/SNMP format, YANG data is converted into an XML representationwhen transported over NETCONF. This XML format is sometimes called YIN.
This conversion process is central to how Cisco NSO handles configurations within network automation, as the NEDs(covered in our previous article) rely on this representation.
A major difference between SNMP and NETCONF/YANG is that:
A NETCONF/YANG-enabled device should provide its YANG model files directly for a NETCONF client to download.
In contrast, SNMP MIB files are sometimes only available from the vendor and may not be public.
Why NETCONF/YANG?
With the above descriptions, it should be quite clear that NETCONF/YANG is an improvement over SNMP, especially for devices that support advanced NETCONF features such as:
Candidate configurations
Automatic rollback in case of errors
For devices that only support basic functions, the main advantage is the ability to lock configurations from other sessions, which is not possible with SNMP.
As always, things are not that simple.
One major drawback is that NETCONF support varies widely across different network devices. Even if a datasheet claims a device supports NETCONF, testing is required to confirm that it functions correctly in practice, particularly in the context of network automation with Cisco NSO.
Other technologies, such as RESTCONF, sometimes use YANG over REST instead of NETCONF, offering an alternative somewhere between SNMP and NETCONF for data management.
Another consideration is the attempts to create standardized YANG models that work across vendors—similar to RFC-defined MIB files in SNMP.
In NETCONF/YANG, these efforts are led by OpenConfig.
However, just like in SNMP, vendor-specific YANG models are still necessary because different vendors implement features in unique ways.
Unlike SNMP, where failing to follow RFC MIB specifications technically means the implementation is not compliant, YANG models rarely have such strict standardization.
A Side Note: Streaming Telemetry and Alerts
If you’ve read this far—well done! You might have wondered about SNMP traps for alerts, which I deliberately skipped earlier. How do we collect metrics from devices without SNMP?
An essential aspect of network automation is how NETCONF handles alerts and telemetry, which is critical for Cisco NSO.
For SNMP traps, NETCONF provides a similar function called event notifications.
Unlike SNMP, where devices send traps to a predefined system whether it requested them or not,
NETCONF clients subscribe to a list of events.
This list can include anything from specific events to literally all supported events.
The NETCONF server then sends notifications, just like SNMP traps.
For metrics collection, a NETCONF client can subscribe to specific data:
For example, packet-per-second statistics on an interface.
Data can be sent at intervals (like SNMP polling) or only when it changes.
For certain data types, change-based updates are beneficial—such as monitoring the number of prefixes received in a BGP session.
Need Help Getting Started with Network Automation and Cisco NSO?
Whether you need help with analysis, implementation, or long-term support, our experienced Cisco NSO consultantscan guide you through every step of the process.
With the right support, you can:
✅ Maximize the benefits of network automation
✅ Reduce costs
✅ Improve overall network efficiency
Contact us today to learn how we can help your business succeed with network automation and Cisco NSO!
Comments