A Python script uses ncclient to fetch the running configuration and print every interface description on an IOS XE router. The router may answer with a normal data payload or an rpc-error inside the reply, and the automation job must log a clear NETCONF error instead of crashing. Which reply handling approach should the script use?
Select an answer to reveal the explanation.
Short Explanation
Your reply is XML in a sealed envelope, so you open it through the element built for the payload instead of eyeballing raw text. With ncclient's raise mode set to ERRORS, an rpc-error raises RPCError, and catching it turns that into a readable log line. Skip that catch and you're blind to why the call failed.
Full Explanation
In ncclient, a successful get-config reply exposes its payload as an XML element on reply.data, so you can walk it with namespace-aware queries and read every interface description without touching raw text. With ncclient's raise mode set to ERRORS, an rpc-error raises RPCError; catching it lets you print the error tag and message instead of losing the run. Catching only SSHException covers a transport failure but leaves application-level errors unhandled. Running a regular expression over raw reply text is fragile for structured XML and is not a reliable way to walk the configuration tree. Decoding the payload with json.loads is inappropriate because NETCONF replies are XML. Check that the session uses raise mode ERRORS; other raise modes can change whether an rpc-error is raised as an exception. A practical check is to send a filter the router rejects and confirm your handler logs the reason while the process keeps running.