Walk me through a full NETCONF change session, from connecting to closing, including what can go wrong.

Step by step

1. Transport. SSH to TCP 830, subsystem netconf. Authentication is normal SSH (password or key, often via AAA).
2. Hello. The server sends its capabilities and a session-id; the client sends its own. If both list base:1.1, framing switches to chunked.
3. Lock the candidate (and running, if the platform asks for it).
4. edit-config to the candidate.
5. validate the candidate (with :validate).
6. commit with <confirmed/> and <confirm-timeout>.
7. Check reachability and state from the automation side.
8. Confirming commit (a plain <commit/>), then unlock and close-session.

The same flow with ncclient

from ncclient import manager

CONFIG = """
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet2</name>
      <description>to SW1 Gi1/0/48</description>
    </interface>
  </interfaces>
</config>
"""

with manager.connect(host="10.0.0.1", port=830, username="netops",
                     password="secret", hostkey_verify=False) as m:
    with m.locked(target="candidate"):
        m.discard_changes()
        m.edit_config(target="candidate", config=CONFIG)
        m.validate(source="candidate")
        m.commit(confirmed=True, timeout="120")
        # run post-checks here; if they fail, do nothing and the device rolls back
        m.commit()

discard_changes() first clears anything another session left in a shared candidate. hostkey_verify=False is for a lab; in production load known host keys.

What an error looks like

<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rpc-error>
    <error-type>protocol</error-type>
    <error-tag>lock-denied</error-tag>
    <error-severity>error</error-severity>
    <error-info>
      <session-id>31</session-id>
    </error-info>
  </rpc-error>
</rpc-reply>

error-type is transport, rpc, protocol or application. For lock-denied, error-info names the session holding the lock. The error-message text varies by vendor.

Common failures

• Port 830 refused: NETCONF not enabled, or an ACL on the management plane.
• MissingCapabilityError in ncclient: you targeted the candidate on a device that does not offer it.
• unknown-element or invalid-value: wrong namespace, a typo, or a node the platform does not support.
• lock-denied: another session or a stuck session holds the lock; kill-session frees it if you are sure.