A NETCONF edit is rejected and the session stays up. The payload names a real node, and the value is outside the range that node allows. Why was it rejected?
Select an answer to reveal the explanation.
Short Explanation
The session is still there, so the path worked. You handed the node a value it is not allowed to hold. The model rejected the value, not the connection.
Full Explanation
A model defines which nodes exist and which values those nodes accept. This edit names a real node and supplies a value outside the allowed range, so it is rejected while the session stays up. The SSH session did not drop. A rejection is not the same event as a closed session. YANG does not accept every value. Unknown nodes are one failure, and illegal values are another. A get is not a prerequisite that makes a value legal. The value is legal or not on its own. The NETCONF session stays up and the model rejects the value. The transport worked. The value is not one the model allows. Check one live client after the change and leave the rest of the floor alone until that client matches the result you expected. Confirm the symptom on the next attempt before changing anything else. Exam caveat: two platforms can use different ranges for a similar knob. A value that worked on another controller can be illegal here. Operational check: read the allowed range for that node, send a value inside it, and confirm the edit is accepted on the same session.