What Is YANG Data Model in Networking?
Also known as: YANG data model, CCNP automation, NETCONF vs YANG, YANG model types, Cisco YANG exam
On This Page
Quick Definition
Think of YANG as a blueprint for how network devices like routers and switches organize their settings. It uses a clear, structured format to describe which configuration options exist, what values they can take, and how they relate to each other. This allows network automation tools to read and change device settings in a consistent way, without needing to rely on old-style command-line interfaces.
Must Know for Exams
YANG data models appear in the Cisco CCNP Enterprise exam (350-401 ENCOR) as a key part of the Automation and Programmability section, which is worth about 15-20% of the exam questions. The exam objectives explicitly state that candidates must 'Describe the characteristics of YANG models (containers, lists, leaves, leaf-lists, modules, submodules)' and 'Compare and contrast native, IETF, and OpenConfig YANG models'. This is not a side topic; it is a significant area that requires focused study.
In the exam, you may see multiple-choice questions that ask you to identify the correct YANG statement about a particular data node type. For example, a question might ask: 'Which YANG statement is used to define a collection of ordered entries?' The correct answer is 'list', but a distractor might say 'container' or 'leaf-list'. Another question could present a snippet of YANG code and ask you to identify the data type of a leaf. You must be comfortable reading basic YANG syntax, including the use of `leaf`, `container`, `list`, `type`, `mandatory`, and `default` statements.
Beyond syntax, exams test your understanding of the ecosystem. You might get a scenario question: 'A network engineer wants to configure a multi-vendor network using a single set of YANG models. Which type of YANG model should they choose?' The answer is OpenConfig or IETF models, because they are vendor-neutral. Another question might ask you to order the steps for a NETCONF operation: establish an SSH session, exchange capabilities, send an edit-config message, validate against the YANG model, apply the changes. Understanding the flow is critical.
Finally, the ENCOR exam integrates YANG with other automation topics like RESTCONF, NETCONF, Ansible, and Python scripts. You may be asked how a Python script using the ncclient library interacts with a YANG model on a router. The key is to remember that YANG defines the data structure, while NETCONF and RESTCONF are the transport protocols that carry the data. Master this distinction, and you will be well prepared for the exam questions on this topic.
Simple Meaning
Imagine you are building a model house with Lego bricks. Before you start, you need a set of instructions that tells you exactly which bricks go where, how many of each type you need, and what the final house should look like. This instruction set is like a YANG data model. In networking, a YANG data model provides a structured, formal way to describe all the settings and information that a network device like a router or switch can hold. It defines the shape of the data. For example, it might say there is a setting called 'hostname' that must be a text string between 1 and 63 characters, and it lives under a section called 'system'.
Without YANG, network engineers had to use many different command-line interfaces (CLIs) from different vendors, each with their own syntax and quirks. YANG creates a common language that any tool or script can understand. It is like having a universal remote control for all your electronics instead of needing a separate remote for each device. YANG models are written in a plain-text format and are used with protocols like NETCONF or RESTCONF to actually send the configuration to the device. So YANG is the blueprint, and NETCONF is the builder who follows the blueprint to change the house. This separation is crucial because it allows network automation tools to work consistently across devices from Cisco, Juniper, Arista, and others, as long as they all understand the same YANG model. For beginners preparing for CCNP exams, understanding YANG means you can move from manually typing commands to writing code that manages the entire network automatically. It is the foundation of network programmability and automation that is now a core part of modern networking exams.
Full Technical Definition
YANG, which stands for Yet Another Next Generation, is a data modeling language originally defined in RFC 6020 and later revised in RFC 7950. It is used to model the configuration and state data of network devices, as well as the operations and notifications they support. YANG modules define a hierarchical tree of nodes, where each node can be a container (a grouping of related nodes), a list (a sequence of entries), a leaf (a single value), or a leaf-list (an array of values). Each leaf has a data type, such as string, integer, boolean, or an enumeration, and may have constraints like a range or pattern.
YANG models are typically exchanged using NETCONF (Network Configuration Protocol, RFC 6241) or RESTCONF (RFC 8040). NETCONF uses SSH or TLS for transport and sends XML-encoded data that matches the structure defined in the YANG model. RESTCONF uses HTTPS and can send JSON or XML data, making it more accessible for web developers. For example, a YANG model might define an interface container with leaf nodes for name, description, IP address, and MTU. A NETCONF client can then send an XML message like `<interface><name>GigabitEthernet1</name><ip-address>10.0.0.1</ip-address></interface>` to configure that interface. The device validates the incoming data against the YANG model before applying it, preventing many common misconfigurations.
Cisco uses YANG models in its IOS XE and NX-OS operating systems. The Cisco OpenConfig YANG models are a set of standard models developed by network operators for multi-vendor interoperability. Additionally, Cisco publishes its own native YANG models that expose all device-specific features. For the CCNP Enterprise exam (ENCOR 350-401), candidates must understand how YANG fits into the network automation architecture, including the difference between standard models (like those from OpenConfig or IETF) and vendor-specific models. YANG models are also used in Cisco DNA Center and other orchestration platforms to abstract network configuration. The key technical aspects to remember are the modular structure (imports, includes, containers, lists, leaves), the use of XML or JSON encoding, the role of NETCONF and RESTCONF as transport protocols, and how YANG enables model-driven telemetry by defining which state data to stream.
Real-Life Example
Think of a large office building with a complex security system. The building has many doors, each with an electronic card reader. Instead of every door being programmed separately by a security guard physically walking to each one, the building uses a central system. The blueprint for this system is the YANG data model. The blueprint defines what information every door reader holds: it says each door has a unique ID, a list of authorized badge numbers, a schedule of allowed access times, and a status (locked or unlocked). This blueprint is written in a standard format that the central security software understands.
Now, when a new employee joins the company, the security administrator does not need to go to each door. They simply use a tool (like a NETCONF client) that reads the blueprint. They send a message saying 'for door ID 103, add badge number 4567 to the authorized list'. The central system checks that 4567 is a valid badge number format and that 103 is a valid door ID, based on the blueprint. If the data matches the blueprint, the change is applied. If someone tries to send 'set door 103 color to blue', the system rejects it because 'color' is not defined in the blueprint.
This analogy maps directly to YANG. The building is the network, the doors are network interfaces or services, the badges are configuration parameters, and the blueprint is the YANG model. The central security software is the NETCONF/RESTCONF protocol running on the network device. The key insight is that the blueprint is separate from the action of changing the locks. The blueprint ensures consistency, prevents errors, and allows any compliant tool to manage any door, even if different doors are from different manufacturers. This is exactly what YANG does for network devices from different vendors: it provides a common model so that automation tools can work with any device that supports that model.
Why This Term Matters
YANG data models matter because they are the backbone of modern network automation and programmability. In real IT work, manually configuring hundreds or thousands of network devices using command-line interfaces is slow, error-prone, and impossible to scale. YANG provides a structured way to define what can be configured, which allows tools like Ansible, Puppet, or custom Python scripts to automate changes reliably. For example, a network engineer can write a script that reads a YANG model for the BGP configuration of a router, dynamically generate the correct configuration for a new peer, and push it to the device via NETCONF, all without needing to know the exact CLI syntax of that particular device model.
Beyond configuration, YANG enables model-driven telemetry. Instead of polling devices every few minutes with SNMP, which is inefficient, an engineer can use a YANG-defined subscription to stream data. For instance, the device can send an update whenever the CPU utilization crosses a threshold. This is far more efficient and provides real-time visibility into network health. In cybersecurity, YANG models help enforce security baselines. A security policy can be expressed as a YANG model, and a compliance checker can verify that every device's configuration matches that model. If a device drifts from the model, an alert is triggered. This is exactly how Cisco DNA Center and other intent-based networking systems work.
For organizations adopting DevOps or NetOps practices, YANG is critical because it allows network configuration to be treated as code. Configurations become version-controlled files in a Git repository, changes are reviewed in pull requests, and deployments are automated. This reduces human error, speeds up changes, and improves auditability. Without YANG, network teams remain stuck in a manual, brittle process that cannot keep up with the pace of modern business. For the CCNP certification, understanding YANG is essential because automation is no longer optional—it is a core exam topic and a required skill for any senior network engineer.
How It Appears in Exam Questions
In certification exams like CCNP ENCOR, YANG appears in several distinct question formats. The most common is the direct knowledge question, where you are asked to identify YANG keywords or concepts. For example: 'Which YANG statement is used to create a grouping of related configuration parameters?' The answer is 'container'. Another version asks you to match YANG statements with their descriptions: 'leaf-list' matches 'a sequence of values', 'leaf' matches 'a single value', and 'list' matches 'a collection of entries with keys'. These questions test your memorization of the YANG grammar.
Scenario-based questions are also frequent. A typical scenario describes a network engineer who needs to automate the configuration of interface descriptions across 200 switches. The question asks: 'Which combination of protocol and data model should the engineer use to achieve this reliably?' The correct answer involves using NETCONF with a standard YANG model, while the distractors might suggest SNMP with MIBs (older technology) or CLI scripts (brittle and error-prone). Another scenario might describe a situation where a device rejects a configuration change, and you must identify the likely cause: the XML message did not conform to the YANG model.
Troubleshooting questions can also appear. For instance, a question may show a YANG model snippet and a NETCONF reply with an error message like 'data not found'. You are asked to determine why the error occurred. The answer could be that the YANG model uses mandatory leafs that were not provided, or that the path used in the NETCONF operation does not match the YANG hierarchy. Finally, some questions ask you to interpret a YANG model and predict what configuration it represents. You might be given a container called 'ospf' with leaves for 'router-id', 'area', and 'network-type', and then asked which configuration command corresponds to setting the 'router-id' leaf. This tests your ability to translate between YANG and traditional CLI, a skill that is increasingly important in hybrid environments.
Study encor
Test your understanding with exam-style practice questions.
Example Scenario
A medium-sized company is expanding and needs to add 50 new VLANs across 10 access switches. The network engineer, Sarah, used to log into each switch manually using SSH and type `vlan 10`, `name Sales`, `exit`, then repeat for all 50 VLANs on all 10 switches. This process took her an entire day and was prone to typos. Her manager asks her to find a faster, more reliable way.
Sarah decides to use a YANG-based automation approach. She first finds the standard IETF YANG model for VLANs, which defines a structure called `vlan-list`. This structure has a key leaf called `vlan-id` and a leaf called `name`. She writes a Python script that generates an XML file containing all 50 VLAN definitions. The script uses the ncclient library to connect to each switch via NETCONF, authenticate, and send an `edit-config` operation with the XML payload. Each switch validates the incoming data against its internal YANG model. Because the YANG model defines that `vlan-id` must be between 1 and 4094, and that `name` must be a string, the switch rejects any data that violates these rules. Sarah catches these errors in her script and corrects them instantly. The entire operation completes in under 10 minutes across all switches, with zero manual errors.
This scenario shows how YANG data models enable reliable, scalable automation. The YANG model provides the contract between Sarah's script and the switches, ensuring that both sides agree on the structure and constraints of the data. Without YANG, she would have to write separate scripts for different switch models or rely on error-prone CLI parsing.
Common Mistakes
Thinking YANG is a protocol like NETCONF or RESTCONF
YANG is a data modeling language, not a protocol. It defines the structure and constraints of the data, but it does not handle transport or communication. NETCONF and RESTCONF are the protocols that carry the data defined by YANG. Confusing them leads to incorrect answers on exam questions that ask about the roles of different technologies.
Remember: YANG is the blueprint (the model), NETCONF/RESTCONF are the delivery trucks (the protocols). You cannot send a blueprint itself; you need a truck to carry it. Similarly, YANG models define the data structure, but they are used with NETCONF or RESTCONF to actually configure devices.
Believing that YANG is only used by Cisco or only for Cisco devices
YANG is an IETF standard (RFC 7950) and is used by many vendors, including Juniper, Arista, Huawei, and others. OpenConfig YANG models are specifically created for multi-vendor interoperability. Cisco has its own native YANG models, but YANG itself is vendor-neutral. This misconception can lead to choosing incorrect answers on questions about multi-vendor automation.
YANG is like the English language for network configuration. Many different devices and vendors speak it, each with their own local dialects (native models). The standard dialects (IETF, OpenConfig) allow different devices to understand each other.
Assuming YANG models are always written in XML or JSON
YANG models themselves are written in a human-readable text format with its own syntax (similar to SMI for SNMP). The data that is exchanged using NETCONF is typically encoded in XML, and RESTCONF supports both XML and JSON. But the model file itself is not XML or JSON. Mistaking the model format for the data encoding is a common exam error.
Think of it like a recipe book. The recipe (YANG model) is written in plain English (YANG syntax). The actual ingredients you put in the kitchen (configuration data) can be written on a shopping list in XML or JSON. The recipe language is different from the list language.
Overlooking the difference between configuration data and state data in YANG
YANG models can define both config:true and config:false nodes. Config:true nodes are intended for configuration and can be written by a client. Config:false nodes represent state data that is read-only, such as interface statistics or CPU load. Some learners assume all YANG data is configurable, which leads to attempts to configure state data via NETCONF, resulting in errors. Exam questions test this distinction.
Always check the 'config' statement in a YANG model. If config is 'false', that data is read-only. You can read it using a 'get' operation, but you cannot change it using 'edit-config'. Treat state data like a gauge on your car dashboard—you can look at it, but you cannot twist it to change the speed.
Confusing YANG lists with containers
A container holds a collection of related nodes but is not a list of entries. A list, on the other hand, defines a sequence of entries, each identified by a unique key. For example, 'interface' is often a list with key 'name', because you can have multiple interfaces. A container called 'system' might hold the hostname and domain name, which are single values. Mixing these up causes errors in exam questions that ask you to identify the correct YANG structure for a given scenario.
If you need to represent a single group of settings that occur only once, use a container. If you need to represent multiple instances of a group (multiple VLANs, multiple interfaces), use a list with a key. The key is the unique identifier for each entry, like a primary key in a database.
Exam Trap — Don't Get Fooled
The exam question states: 'A network engineer wants to monitor the CPU utilization of a router in real-time. The engineer decides to use NETCONF and a YANG model to stream the data. Which of the following is the most important characteristic of the YANG model for this purpose?'
The options include 'The model uses a list to define the CPU utilization value' or 'The model marks the CPU utilization leaf as config false'. Remember that streaming telemetry is about reading operational state, not writing configuration. The key characteristic is that the YANG model defines the CPU utilization leaf as 'config false', meaning it is state data that can be subscribed to for streaming.
A list would be incorrect because there is only one CPU utilization value per device at any given time. Always look for the 'config false' statement when the scenario involves monitoring or telemetry.
Commonly Confused With
YANG is the data modeling language that defines the structure of configuration and state data. NETCONF is the network configuration protocol used to transport that data between a client and a device. YANG is the blueprint; NETCONF is the delivery mechanism. You cannot use NETCONF without a YANG model, and a YANG model without NETCONF is just words on paper.
A library uses a card catalog (YANG) to describe every book's title, author, and location. The library assistant (NETCONF) uses the card catalog to find a book and hand it to you. The card catalog is the model, the assistant is the protocol.
Both NETCONF and RESTCONF are protocols that use YANG models, but RESTCONF uses HTTP/HTTPS and supports both JSON and XML, while NETCONF uses SSH or TLS and typically only XML. RESTCONF is simpler for web developers and is often used in modern automation frameworks. They both rely on YANG models, but they differ in transport and data encoding.
Think of NETCONF as a courier that delivers a package in a special secure truck (SSH) and only accepts a specific packing slip format (XML). RESTCONF is like a standard postal service (HTTP) that can deliver packages in either a box (XML) or a padded envelope (JSON), and it uses a simpler tracking number (URL).
SNMP MIBs (Management Information Bases) are older data models used with SNMP to monitor and manage network devices. MIBs use a different language (SMI) and are primarily focused on reading monitoring data (polling). YANG is more modern, supports both configuration and state, is human-readable, and is designed for programmatic automation. YANG models also support more complex data structures like lists with keys, which MIBs do not.
SNMP with MIBs is like using a landline phone to call a friend and ask 'What is the temperature?' every hour (polling). YANG with NETCONF is like having a smart thermostat that sends you a text message when the temperature changes (push), with the ability to also send a new target temperature (configuration). YANG is far more flexible and efficient.
OpenConfig is a specific set of YANG models developed by a consortium of network operators (like Google, Microsoft, AT&T) to be vendor-neutral. They are designed to work across devices from different vendors. In contrast, 'native YANG models' are vendor-specific, such as Cisco's native YANG models that expose all Cisco-specific features. Both are YANG models, but OpenConfig aims for broad interoperability, while native models provide full device-specific functionality.
OpenConfig YANG models are like a universal power adapter that works in many countries. Native YANG models are like the specific power cord that comes with a laptop from a particular manufacturer. If you travel (multi-vendor), you want the universal adapter. If you are at home (single vendor), the specific cord may give you extra features.
Step-by-Step Breakdown
Define the data structure with YANG statements
A YANG model is written in a text file using keywords like module, container, list, leaf, leaf-list, and type. For example, a module called 'example-interface' might define a container called 'interface-config' with a leaf 'mtu' of type uint16. This is the blueprint creation stage, where the network architect decides exactly what data the device can hold.
Import or include other modules
YANG models can reuse definitions from other models using import or include statements. For instance, a model for VLANs might import the standard 'ietf-interfaces' model to use its interface definitions. This promotes modularity and reuse, preventing the need to redefine common structures.
Compile the YANG model on the network device
The device OS (like Cisco IOS XE or NX-OS) loads the YANG model and makes it available as a schema. The device can validate incoming data against this schema. Without the model, the device cannot support NETCONF or RESTCONF operations for that feature.
Establish a NETCONF or RESTCONF session
A network management tool or script initiates a connection to the device using SSH (for NETCONF) or HTTPS (for RESTCONF). During session establishment, the client and server exchange a list of supported YANG models (capabilities exchange). This ensures both sides agree on which models will be used.
Send the configuration or query data
The client sends an XML or JSON payload that conforms to the YANG model structure. For example, a POST request to RESTCONF on the path /restconf/data/ietf-interfaces:interfaces/ might contain JSON data defining a new interface. The device processes this request by first validating the data against the YANG model.
Validate and apply the data
The device checks that the incoming data matches the YANG model: all mandatory leafs are present, data types are correct, values are in range, and no unknown nodes exist. If validation passes, the device applies the change to its running configuration. If validation fails, an error is returned to the client.
Respond with an acknowledgment or result
If the operation succeeds, the device sends a success response (e.g., a 201 Created for RESTCONF, or an <ok/> element for NETCONF). If it fails, the response includes an error message indicating the specific violation. This response allows the automation tool to log success or trigger a rollback in case of failure.
Practical Mini-Lesson
To work with YANG data models in a practical context, start by understanding the three main types of YANG models you will encounter. Native YANG models are vendor specific and expose every feature of a device. For example, Cisco's native YANG models for IOS XE include 'Cisco-IOS-XE-interfaces.yang' which has all the interface features a Cisco engineer expects. Standard IETF YANG models, like 'ietf-interfaces.yang', are defined by the Internet Engineering Task Force and are intended to be vendor neutral. OpenConfig YANG models are another set of standard models, often more feature-rich than IETF models, and are widely adopted in large-scale service provider and cloud networks. When automating a multi-vendor network, prefer IETF or OpenConfig models to ensure your automation works across all devices.
In practice, you will not write YANG models from scratch as a network engineer. Instead, you will use existing models. Tools like Ansible have plugins that use YANG models to generate configuration. For example, the 'network_setup' module in Cisco's collection can read a YANG model and dynamically create the correct NETCONF payload. To test your understanding, try this exercise: download a YANG model from Cisco's GitHub repository (e.g., 'Cisco-IOS-XE-native.yang'). Open it in a text editor. Look for a 'list' statement, such as 'interface GigabitEthernet'. Notice the key leaf 'name'. Then look for a 'leaf' statement inside that list, such as 'description'. Note the data type 'string'. This simple reading exercise builds your ability to interpret exam scenarios that show YANG snippets.
A common task in real-world automation is to retrieve the current configuration of a device in YANG format. Using a tool like 'curl' with RESTCONF, you can send a GET request to 'https://device-ip/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1'. The device will return a JSON or XML document that matches the YANG model structure. You can then use Python's 'json' library to parse this data and extract specific parameters, like the IP address. This is how modern network automation integrates with systems like Ansible, Terraform, or custom Python scripts.
What can go wrong? The most common issue is a mismatch between the YANG model version on the device and the model used by the client. If the client assumes a leaf exists that the device's model does not support, the device returns an error. Always verify the capabilities exchange at session start. Another pitfall is forgetting that some YANG models require data to be sent in a specific order (e.g., a list entry must have its key leaf first). Also, be cautious with 'mandatory true' leafs: if you omit them, the device rejects the entire operation. In production, always test your payloads against a lab device first.
YANG connects to broader IT concepts like CI/CD pipelines. You can store YANG-generated configurations in a Git repository, use a CI tool to validate the JSON against the model, and then deploy it via NETCONF. This makes network configuration tracking as reliable as server provisioning, a key goal of the DevOps movement in networking.
Memory Tip
YANG is the Blueprint: Blueprints define structures, not deliveries. YANG defines data structure; NETCONF and RESTCONF deliver the data.
Covered in These Exams
Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Frequently Asked Questions
Do I need to memorize all YANG keywords for the CCNP exam?
You do not need to memorize every keyword, but you must know the most common ones: module, container, list, leaf, leaf-list, type, mandatory, default, key, and import. Be able to recognize them in a code snippet and understand what each defines.
Can I use YANG without NETCONF or RESTCONF?
No, YANG is just the model. It defines the structure of the data, but you need a protocol like NETCONF or RESTCONF to actually read or modify that data on a device. Think of YANG as the language and NETCONF as the phone call.
What is the difference between a native YANG model and an OpenConfig model?
Native YANG models are vendor-specific and expose all features of a particular OS, like Cisco IOS XE. OpenConfig models are standard models designed for multi-vendor interoperability. Use OpenConfig when you need to manage devices from different vendors consistently.
How do I know which YANG models a Cisco device supports?
You can connect to the device via SSH and use NETCONF's <get-schema> operation, or send a GET request to the RESTCONF endpoint /restconf/data/netconf-state/schemas/. The device will return a list of all supported models with their versions.
Is YANG only for configuration, or can it be used for monitoring too?
YANG models both configuration (config true) and operational state data (config false). State data includes counters, status, and statistics. You can subscribe to this state data for model-driven telemetry and stream it to a collector like Prometheus or Splunk.
What happens if I send a NETCONF message that does not match the YANG model?
The device will reject the message and return an error response. The error includes a path pointing to the invalid node and a description of the violation, such as 'data type mismatch' or 'mandatory leaf not present'. This validation prevents misconfigurations.
Do I need to learn XML to work with YANG?
XML is the native encoding for NETCONF, but RESTCONF also supports JSON, which is easier to read and use with Python. For the exam, you should be familiar with basic XML structure (elements, attributes, namespaces) because many exam scenarios show XML snippets.
Summary
YANG data models are the foundation of modern network automation. They provide a structured, human-readable, and machine-verifiable way to define the configuration and state data of network devices. Unlike older methods like CLI scripts or SNMP MIBs, YANG enables consistent, scalable, and error-resistant automation across multi-vendor environments.
For the CCNP Enterprise exam, you must understand the core YANG statements (container, list, leaf, leaf-list), the role of native versus standard models (IETF and OpenConfig), and how YANG integrates with protocols like NETCONF and RESTCONF. The exam tests both conceptual knowledge and your ability to interpret YANG snippets in scenario questions. In real-world IT work, YANG empowers engineers to move from manual, device-by-device configuration to automated, code-driven network management.
This shift is not just a trend—it is a core requirement for network engineers in cloud, service provider, and large enterprise environments. Remember that YANG is the blueprint, not the delivery truck. Master this distinction, practice reading YANG models, and you will be well prepared for both the exam and your career as a network automation professional.