Study guide
11.2 NETCONF Protocol & Cisco IOS-XE Wireless YANG Data Models
Cisco WLCOR 350-101 CCNP Wireless Core
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Foundation Strategy
1.1 WLCOR 350-101 Exam Structure, Blueprint & Certification Strategy 1.2 Enterprise Wireless Architecture Evolution & Hands-On Lab Setup
2 Chapter 2: RF Fundamentals: Wave Propagation & Signal Measurements
2.1 RF Wave Behavior, Propagation Phenomena & Path Loss Modeling 2.2 RF Signal Measurements, Noise Floor & Link Quality Metrics
3 Chapter 3: RF Mathematics, Link Budget & Antenna Technologies
3.1 RF Mathematics, dB Decibel Rules & Link Budget Calculations 3.2 Antenna Theory, Radiation Patterns, Gain & Beamforming
4 Chapter 4: 802.11 Standards, Governance & Spectrum Architecture
4.1 Regulatory Domains, Governance Bodies & Wi-Fi Standards Evolution 4.2 Frequency Spectrum, Channel Allocations & Power Limitations (2.4 GHz, 5 GHz, 6 GHz) 4.3 802.11 PHY & MAC Layer Protocols, Modulation & Frame Formats
5 Chapter 5: Wireless Network Implementation & Catalyst 9800 Architecture
5.1 Cisco Enterprise Wireless Deployment Architectures 5.2 Physical Infrastructure, Power over Ethernet (PoE) & Multi-Gigabit Networking 5.3 Cisco Catalyst 9800 Modular Configuration Architecture & Tag-Based Modeling
6 Chapter 6: Access Point Lifecycle & Infrastructure Operation
6.1 Catalyst 9800 Controller Initialization & High Availability SSO 6.2 Access Point CAPWAP Discovery, DTLS Cryptography & Controller Join Mechanics
7 Chapter 7: AP Operating Modes & Client Policy Enforcement
7.1 Access Point Operational Modes & FlexConnect Architecture 7.2 WLAN Profile Creation, Client Access Policies & QoS Mapping 7.3 Multi-Platform Client Management & Policy Enforcement
8 Chapter 8: Wireless Security & Authentication Architecture
8.1 External Identity Systems, 802.1X Architecture & EAP Protocols 8.2 Controller-Level Security Suites, WPA3, OWE & Web Authentication
9 Chapter 9: Client Connectivity, Roaming & Guest Networking
9.1 Multi-OS Client Connectivity & Native Supplicant Configuration 9.2 Fast Roaming Protocols & Mobility Architecture (802.11r, 802.11k, 802.11v, 802.11w) 9.3 Enterprise Guest Networking, Web-Auth & Foreign/Anchor Mobility Tunnels
10 Chapter 10: Wireless Monitoring, Troubleshooting & Platform Integrations
10.1 IOS-XE Wireless Software Maintenance & Lifecycle Management 10.2 Client Monitoring, Health Metrics & Real-Time CLI Diagnostics 10.3 Systematic Troubleshooting & Embedded Packet Capture (EPC) 10.4 Cisco Catalyst Center Assurance & Ecosystem Integrations
11 Chapter 11: Wireless Automation, Programmability & AI Operations
11.1 Python Fundamentals for Cisco Wireless Network Automation 11.2 NETCONF Protocol & Cisco IOS-XE Wireless YANG Data Models 11.3 RESTCONF API Operations & Cisco Catalyst Center Intent APIs 11.4 Artificial Intelligence in Wireless: AI-Enhanced RRM & Predictive Analytics
11.2 NETCONF Protocol & Cisco IOS-XE Wireless YANG Data Models
Key Takeaways Explain This Topic AI
YANG defines the schema, data types, constraints, and operations; NETCONF is the protocol that manipulates YANG-modeled data over a secure transport, normally SSH TCP 830.
NETCONF exchanges XML RPC messages and begins with a capabilities exchange so clients can discover supported base versions, models, datastores, and optional features.
Base 1.0 uses an end-of-message delimiter, while Base 1.1 uses chunked framing; negotiated framing is a transport boundary mechanism, not permission to place illegal XML text in a field.
Candidate and startup datastores are capability-dependent; automation must inspect server capabilities instead of assuming every datastore and operation exists.
A safe edit workflow locks where appropriate, retrieves current configuration, applies a validated edit, checks RPC errors, commits if required, verifies, and unlocks.
Last updated: September 2026
11.2 NETCONF and Cisco IOS XE Wireless YANG Models
NETCONF and YANG solve different parts of automation. YANG is a modeling language: it defines containers, lists, leaves, types, keys, constraints, configuration data, operational state, notifications, and RPCs. NETCONF is a protocol: it carries operations such as get, get-config, edit-config, lock, commit, and action/RPC requests between client and server.
On Catalyst 9800, NETCONF normally runs over SSH on TCP 830. SSH supplies confidentiality, integrity, user authentication, and server host-key authentication. The XML payload is structured according to IETF and Cisco YANG modules.
Session establishment and capabilities
After SSH authentication, client and server exchange hello messages. Each advertises capabilities. The client must read them before choosing operations. Important examples include:
- NETCONF base 1.0 or 1.1
- writable-running support
- candidate datastore support
- confirmed-commit support
- startup datastore support
- XPath filtering support
- YANG module names, namespaces, and revisions
Capabilities prevent assumptions. A candidate workflow is valid only when the server advertises candidate. A startup copy is meaningful only when the relevant datastore and capability exist on that release and platform.
Message framing
NETCONF base 1.0 terminates a message with the delimiter ]]>]]> . Base 1.1 uses chunked framing, in which length markers delimit one or more chunks followed by an end marker. Peers select behavior through the hello negotiation.
The benefit of base 1.1 is unambiguous protocol framing and efficient handling of message streams. It is misleading to say that an ordinary AP description containing the literal delimiter is the expected cause: well-formed XML character data cannot legally contain the sequence ]]> as normal text. A client should use a conforming XML library and the framing negotiated for the session, not concatenate raw strings.
Read operations and filters
A get-config operation reads configuration from a named datastore. A get operation can retrieve configuration and operational state. A subtree or XPath filter limits the reply and reduces controller work and network transfer. <filter xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" type="subtree">
- <wlan-cfg-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-wireless-wlan-cfg"/>
- </filter>
Namespaces are not decorative. The same local element name in two modules can mean different data. Always use the namespace and structure defined by the module revision supported on the device.
Edit operations
An edit-config request selects a target datastore and supplies configuration. The default operation may merge data, while per-element operations can create, merge, replace, or delete. Their semantics matter:
merge changes supplied nodes and preserves unspecified siblings.
replace replaces the target node’s configuration with the supplied content.
create fails if the target already exists.
delete fails if the target does not exist; remove is tolerant of absence where supported by the base semantics.
Do not use replace when the intent is to change one leaf unless the complete replacement object is deliberate and validated.
A candidate-capable workflow can isolate changes:
Confirm the candidate and commit capabilities.
Lock the target datastore if the operational policy permits it.
Copy or otherwise synchronize the candidate with the intended baseline as required by the platform workflow.
Apply a small edit to candidate.
Validate if the capability is available.
Commit, or use confirmed commit with a safe confirmation and rollback plan when supported.
Read the state back and unlock.
On a writable-running-only device, target running and account for the fact that the change can take effect immediately. NETCONF is transactional at the protocol/datastore level; it does not make a service-impacting configuration harmless.
Interpreting replies
A successful request returns an OK element or requested data. A failure returns one or more RPC error elements. Inspect error type, tag, severity, path, and message. Common causes include a wrong namespace, missing list key, invalid value, unsupported operation, lock conflict, or authorization failure.
The message ID correlates each reply to its RPC. An asynchronous client must not assume replies arrive in the same order as application requests without using that identifier.
YANG tooling and data validation
Retrieve or obtain the exact module revision supported by the controller. Tools such as YANG Suite, pyang, and model-driven API explorers help identify paths and constraints. Native models usually expose Cisco features in more detail; OpenConfig models can improve portability when the required function is represented. “Standards-based” does not mean two models have identical paths or behavior.
Before a write, validate required list keys, leaf types, ranges, enumerations, and dependencies. After a write, query both configuration and relevant operational state. A WLAN may exist in configuration yet fail to advertise because its policy, tag assignment, radio state, or security dependency is wrong.
Security and operations
Use SSH host-key verification and least-privilege accounts. Limit NETCONF reachability to management networks. Do not log credentials or complete sensitive XML. Coordinate locks to avoid blocking other automation. Keep a change record and a recovery path. The strongest NETCONF workflow is capability-driven, namespace-correct, minimally scoped, and verified after commit.