AutomationCCNA 200-301

YANG Model Structure Mismatch in RESTCONF PUT Request

Presenting Symptom

A RESTCONF PUT request to modify a YANG data model on a Cisco IOS XE device fails with a 400 Bad Request error, and the device logs indicate a 'YANG model structure mismatch'.

Network Context

The network is a small enterprise branch office with a single Cisco Catalyst 9300 switch running IOS XE 17.3. The switch is configured as a NETCONF/RESTCONF server for automation. The network engineer is using a Python script to push configuration changes via RESTCONF using the ietf-interfaces YANG model. The script previously worked but now fails after a recent IOS upgrade.

Diagnostic Steps

Check RESTCONF API response details

Use a REST client (e.g., curl) to send a GET request to verify the current YANG model structure: curl -k -u admin:password https://192.168.1.1/restconf/data/ietf-interfaces:interfaces

A JSON response showing the current interface configuration, e.g., {"ietf-interfaces:interfaces":{"interface":[{"name":"GigabitEthernet1/0/1","type":"iana-if-type:ethernetCsmacd","enabled":true}]}}

If the GET request succeeds, the YANG model is accessible. Compare the structure with the PUT request payload. Look for differences in key names, nesting, or data types.

Inspect the PUT request payload for structural errors

Review the JSON payload sent in the PUT request. Example: {"ietf-interfaces:interface":[{"name":"GigabitEthernet1/0/1","type":"iana-if-type:ethernetCsmacd","enabled":"true"}]}

The payload should match the YANG model exactly. Note any discrepancies like incorrect key names (e.g., 'interfaces' vs 'interface'), missing namespace prefixes, or wrong data types (e.g., string instead of boolean for 'enabled').

A common mismatch is using 'interfaces' (plural) instead of 'interface' (singular) as the container key, or using a string 'true' instead of boolean true. The YANG model expects exact casing and types.

Check the device logs for YANG validation errors

show logging | include YANG

Log messages like: '%YANG-3-BAD_DATA: Data for 'interface' is invalid: expected boolean, got string' or '%YANG-3-MODEL_MISMATCH: Model structure mismatch for /ietf-interfaces:interfaces/interface'

The logs will pinpoint the exact field and expected type. For example, 'enabled' must be boolean, not string. This confirms the root cause.

Verify the YANG model version supported by the device

show restconf yang-modules | include ietf-interfaces

ietf-interfaces 2018-02-20 (or similar)

Ensure the YANG model version matches the one used in the payload. Different versions may have different structures. If the device has a newer version, the payload must conform to it.

Root Cause

The PUT request payload contains a YANG model structure mismatch: the 'enabled' field is sent as a string ('true') instead of a boolean (true). The ietf-interfaces YANG model defines 'enabled' as a boolean type. After the IOS upgrade, the device enforces stricter type validation, causing the request to fail with a 400 error.

Resolution

Correct the JSON payload to use proper boolean values. Example fix: Change 'enabled': 'true' to 'enabled': true. Ensure all fields match the YANG model exactly. No IOS CLI commands are needed; the fix is in the automation script.

Verification

Re-send the corrected PUT request and verify the response: curl -k -u admin:password -X PUT -H 'Content-Type: application/yang-data+json' -d '{"ietf-interfaces:interface":[{"name":"GigabitEthernet1/0/1","type":"iana-if-type:ethernetCsmacd","enabled":true}]}' https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1%2F0%2F1. Expect HTTP 204 No Content on success. Then GET the interface to confirm: curl -k -u admin:password https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1%2F0%2F1. Expected output includes "enabled": true.

Prevention

["Always validate JSON payloads against the YANG model schema before sending, using tools like pyang or yanglint.","Use a YANG model library or SDK that automatically handles data types and structure.","Test automation scripts in a lab environment after any IOS upgrade to catch model changes."]

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions about RESTCONF/NETCONF. The exam may present a multiple-choice question asking why a PUT request fails, with options including 'incorrect data type' or 'model mismatch'. Candidates must know that YANG models define strict data types (e.g., boolean vs string) and that RESTCONF uses JSON encoding with specific key names.

Exam Tips

Remember that YANG model keys are case-sensitive and must match exactly (e.g., 'interface' not 'interfaces').

Know that boolean values in JSON must be true/false (without quotes), not strings.

Be familiar with the ietf-interfaces model structure: container 'interfaces' contains list 'interface' with leafs like 'name', 'type', 'enabled'.

Commands Used in This Scenario

show logging

Displays the state of system logging (syslog) on the device, including buffer contents, logging configuration, and statistics, used for troubleshooting and monitoring system events.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions