A junior engineer automates an IOS XE router with ncclient. The router advertises the candidate datastore. The script must open a single NETCONF session on the standard NETCONF port, read the running configuration for one subtree, and then apply a new loopback description before disconnecting. Which ncclient call sequence should the script use?
Select an answer to reveal the explanation.
Short Explanation
Your session opens once on port 830, reads with get_config, and then writes with edit_config plus commit so the change reaches running. Closing after the read leaves the loopback description untouched. It's like signing the form instead of only reading it.
Full Explanation
ncclient's manager.connect opens one NETCONF session over SSH, normally on port 830 for IOS XE, and returns a manager object whose methods map to NETCONF operations. Use get_config with source set to the running datastore and a subtree filter to read only the configuration you asked for. Then use edit_config with the candidate datastore as the target and commit to copy the candidate configuration into running. The router in this scenario advertises candidate; on IOS XE, candidate support requires the netconf-yang candidate-datastore feature to be configured. Closing the connection after the read sends no write, so the router keeps its old description. Staging XML in candidate without committing leaves the change out of running. Opening a second session for the write violates the single-session requirement; a datastore lock held by the first session could also cause a conflict. Practical check: run the read first and compare its output with the same subtree from show running-config.