A colleague is automating a router with ncclient and wants one NETCONF script that reads the hostname and a loopback interface, then rewrites that loopback IPv4 address. The maintenance window expects the change to take effect immediately, so the write must apply to the live configuration. Which ncclient call sequence covers the connection, read and write steps?
Select an answer to reveal the explanation.
Short Explanation
Exactly — one session object handles the connection, the read and the write. You open it with manager.connect, pull the XML with get_config, and push the change with edit_config over NETCONF.
Full Explanation
ncclient's manager.connect builds a NETCONF session over SSH from the connection parameters you pass in, and that session object exposes the operations the protocol defines. get_config with a source of running returns the configuration XML the device is using, which is the correct read when the window expects the change to land immediately, and edit_config targeting running applies your interface XML straight to the live configuration. Staging the change in candidate assumes a two-stage workflow this job rules out, so the loopback address would sit uncommitted until someone commits it. Using an HTTP PUT confuses NETCONF with RESTCONF, which maps operations onto HTTP verbs and bodies instead of NETCONF RPCs. Dropping to paramiko and issuing a show command hands you free-form text rather than structured NETCONF data, so parsing becomes fragile. Caveat: when a platform offers candidate, that same write needs a commit to take effect. Practical check: run get_config first and diff its XML against the running configuration.