A team is automating interface audits on 30 IOS XE routers with ncclient. The script runs <get-config> with a subtree filter and must record, per device, whether the router returned the interface data or reported an RPC failure such as an unsupported filter. Which reply-reading and error-handling pattern should the script use?
Select an answer to reveal the explanation.
Short Explanation
Failures arrive inside the reply itself, so you read the payload and watch for the error block the router wrote. Catching RPCError lets you log that one device and keep auditing the rest. The other patterns watch the handshake or the channel instead, and that's a layer too far from the data.
Full Explanation
In NETCONF, a get-config request the router cannot serve is normally answered with an rpc-error element inside the rpc-reply, without closing the channel. With ncclient's default raise mode, or when configured to raise on RPC errors, ncclient surfaces that as an RPCError you can catch per device while the rest of the run continues. The success check is the data element itself, which carries the interface subtree you requested, so one block both reads the result and classifies the failure. Checking for ok fails by concept, because ok acknowledges editing operations such as edit-config and lock rather than get-config, whose success is the data payload. Retrying on AuthenticationError fails because authentication happens while the session is established, not while an RPC runs, so a rejected filter does not raise it. Relying only on SessionCloseError fails because it reports a transport-level drop rather than a structured rejection the router sent while the session stayed open. Exam caveat: ncclient's exception classes live in a couple of modules and its raise mode is configurable, so learn the behaviour rather than one import path. Practical check: send a deliberately wrong filter to a lab router and confirm you get an exception while a good filter returns a data element.