NETCONF/YANG Solution Architecture

The Need for a New Approach

Your work as a solutions engineer has likely exposed you to the limitations of traditional network management methods.

• CLI (Command-Line Interface): While intuitive for humans, it's difficult for machines to parse. Commands are vendor-specific strings, and error handling often involves screen-scraping, which is brittle and unreliable.
• SNMP (Simple Network Management Protocol): Though excellent for monitoring (getting state), its capabilities for configuration (setting state) are weak and rarely used in practice. It lacks the transactional integrity needed for complex configuration changes.

These limitations created a need for a programmatic, standardized, and reliable way to manage network devices.

To understand the problems NETCONF and YANG were designed to solve, let's start with a short video.

The video sets the stage perfectly. The industry needed a solution that was:

• Programmatic: Designed for applications, not just humans.
• Standardized: To enable multi-vendor interoperability.
• Transactional: To ensure that configuration changes are applied atomically—either they all succeed, or they all fail, leaving the device in a known state.

Introducing the NETCONF/YANG Solution

The IETF's answer to these needs was a two-part solution:

1. NETCONF (Network Configuration Protocol): A protocol (RFC 6241) that defines operations for installing, manipulating, and deleting the configuration of network devices.
2. YANG (Yet Another Next Generation): A data modeling language (RFC 7950) used to define the structure, syntax, and semantics of the data used by NETCONF.

Think of it this way: YANG is the blueprint that describes every configurable parameter of a device—like an interface's IP address, its description, and its state. NETCONF is the transport mechanism and set of verbs (get, edit, commit) used to manipulate the data described by that blueprint.

The NETCONF Architecture

NETCONF is built on a simple client-server model and is conceptually divided into four layers.

Here's a breakdown of the key components:

• Manager (Client): An application, such as a Python script or a network controller, that initiates the connection and sends requests.
• Agent (Server): Software running on the managed network device (e.g., a router or switch) that listens for and responds to manager requests.
• Transport Layer: NETCONF messages are transported over a secure, connection-oriented session. SSH is the mandatory transport protocol, typically using TCP port 830.
• RPC Layer: NETCONF uses a Remote Procedure Call (RPC) model. The manager sends <rpc> requests, and the agent sends <rpc-reply> responses. All messages are encoded in XML.
• Operations Layer: This defines a set of standard protocol operations, such as <get-config> and <edit-config>.
• Content Layer: This is the data being manipulated, which is structured according to YANG models.

Core Components in Practice

Now let's examine the key operational components that make a NETCONF/YANG solution work.

1. Configuration Datastores

NETCONF defines several datastores, which are distinct copies of the device's configuration. This is a major advantage over traditional methods, enabling transactional changes.

• <running>: The active configuration currently running on the device. This is the only mandatory datastore.
• <candidate>: A staging area for configuration changes. You can modify this datastore without affecting the device's actual operation. This allows you to build a set of changes, validate them, and then apply them all at once.
• <startup>: The configuration that is loaded when the device boots.

The typical workflow is to lock the <candidate> datastore, make changes using <edit-config>, and then apply them to the <running> datastore with a single <commit> operation. This ensures atomic updates.

2. NETCONF Operations

The protocol defines a set of base operations that a manager can invoke.

3. A Practical Walkthrough

Theory is essential, but seeing the components in action solidifies understanding. Given your background, a practical demonstration using Python will connect these concepts to real-world application.

This demo brings all the pieces together: the manager (Python script), the agent (CSR 1000V), the SSH transport, the XML-encoded RPC, and the YANG-structured data.

Diving Deeper into YANG

YANG is what gives NETCONF its power and structure. It defines what is possible to configure.

A YANG model defines:

• Data structure: Using containers (groupings), lists (sequences of items, like a list of interfaces), and leaves (individual data points, like an IP address).
• Data types: Such as string, int32, boolean, and enumeration.
• Constraints: Rules like a VLAN ID must be between 1 and 4094.
• RPCs and Notifications: Can also define custom operations beyond the NETCONF base set.

Types of YANG Models

In a real-world network, you will encounter different categories of YANG models. Understanding them is key to building portable automation.

The main categories are:

1. IETF Standard Models: Developed by the IETF for fundamental network features (e.g., ietf-interfaces, ietf-routing).
2. OpenConfig Models: A collaborative effort by network operators to create a set of vendor-neutral models for common features like BGP, LLDP, and VLANs.
3. Vendor-Native Models: Models developed by vendors like Cisco, Juniper, or Arista to expose the full set of their proprietary features. These are the most comprehensive but are not portable across platforms.

Conclusion

This lesson concludes our journey through the key topics of the CCNP ENCOR curriculum. We've dissected the components of a NETCONF/YANG solution, moving from the high-level goals of network automation to the specific protocols and data structures that make it a reality.

Key Takeaways:

• NETCONF is a standardized protocol that provides a programmatic and transactional way to manage network devices, overcoming the limitations of CLI and SNMP.
• YANG is a data modeling language that provides the "blueprint" for device configuration, defining the structure, syntax, and semantics of the data that NETCONF manipulates.
• A NETCONF/YANG solution consists of a manager (client) and an agent (server) communicating over SSH. The manager sends XML-encoded RPCs (like <edit-config>) to manipulate data in datastores (candidate, running), and the agent responds accordingly.
• The choice between vendor-native, IETF, and OpenConfig YANG models is a critical design decision, trading off feature completeness against vendor neutrality.

You have now covered the full breadth of the ENCOR exam blueprint, from foundational enterprise architecture and advanced routing to wireless, security, and finally, network automation. Your background as a solutions engineer, combined with the deep technical knowledge you've gained throughout this course, positions you excellently not only for the certification exam but for designing and managing the complex, automated networks of the future. Congratulations on completing the course