AvailabilitySign inBook a DemoJoin Waitlist
Back to Learning
Cisco · DEVASCBeginner

RESTCONF: Green Runs, No Change

Every run is green and the device never changed. Read the response and then read the device back, live, right below.

Interactive simAutomationRESTCONFYANG

Symptom

A Python script pushes config over RESTCONF and reports success every run, yet the device never actually changes.

Your mission

Inspect, recover, then verify

Format

Linux shell

Start interactive labSee the investigation plan ↓Need a hint? Reveal the root cause ↓
RESTCONF: Green Runs, No Change

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: Linux

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open RESTCONF: Green Runs, No Change, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

A Python script PATCHes interface config to an IOS-XE device over RESTCONF and returns 204 every run, but the change never sticks. Nothing errors, yet a follow-up GET shows the old value.

What you'll practice

  • Authenticate to IOS-XE RESTCONF and read a resource
  • Build a correct YANG-modeled JSON payload and Content-Type
  • Use PATCH vs PUT deliberately (merge vs replace)
  • Verify applied state with a read-back assertion
  • Diagnose a request that returns 2xx but changes nothing

The topology

A Linux automation host with Python and the device SDKs reaches a live IOS-XE device over RESTCONF, so every request runs against real YANG models and returns real device state rather than a mock.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Replay the call with headers shown
curl -sv -k -u admin:admin -X PATCH https://10.20.30.5/restconf/data/Cisco-IOS-XE-native:native/interface -H 'Content-Type: application/json' -d @payload.json
Read the resource back
curl -s -k -u admin:admin https://10.20.30.5/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=2 -H 'Accept: application/yang-data+json' | jq .
Inspect the payload
cat payload.json

Topology diagram

Fact-checked references

The commands and behaviour in this lab were checked against these primary references.

Frequently asked

Why would a 204 not change anything?

A device can accept a request against an unintended resource or ignore a body sent with the wrong media type, returning 2xx while the leaf you meant to change is never touched. The fix is to verify, not trust.

Is this DEVASC-level?

Yes. RESTCONF, YANG payloads and basic Python against real devices are core DevNet Associate (200-901) skills.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.

View availabilityBook a demo