A Python script using ncclient fetches the interface subtree from a fleet of routers and prints each interface name. One device rejects the subtree and raises an error, while another returns a valid reply containing no interface nodes. Which handling reads the reply and reports that device failure correctly?
Select an answer to reveal the explanation.
Short Explanation
Catch RPCError, log the device and error message, then move on to the next router; parse reply.data only when the call succeeds. It’s like checking whether a package arrived before opening it: a valid but empty reply means there were no matching interfaces, not a failure.
Full Explanation
ncclient's Manager.get_config builds a get-config RPC and sends it over the session. When the router answers with an rpc-error and ncclient is configured to raise on RPC errors, ncclient raises RPCError instead of returning a normal reply object. Catching that exception by class lets you record the device and reason and move on, while the success path gives reply.data as a parsed tree you can walk for interface nodes. The proposed text-parsing approach does not handle the exception path; classifying every response with no interface-name tags as a connection failure also mislabels a valid empty result. Re-raising immediately turns one bad device into a failed run, while blanket retrying assumes a deterministic rejection is transient. Exception names and message wording can vary between ncclient versions, so match the class rather than the text. Practical check: request an unsupported subtree on purpose and confirm the loop logs one device and keeps going.