NETCONF And XML API practice questions

Subtree filtering using XML element tags matching the configuration hierarchy

Subtree filtering sends XML element tags mirroring the configuration hierarchy, so the device returns only the matching hostname node rather than the entire configuration. This satisfies the stem's efficiency constraint by minimising payload and server-side processing compared with retrieving everything and filtering locally.

<rpc><commit><confirmed/><confirm-timeout>5</confirm-timeout></commit></rpc>

The `<confirmed/>` tag activates Junos's rollback-on-timeout mechanism, while `<confirm-timeout>5</confirm-timeout>` sets the five-minute window before automatic rollback. Both elements nest inside `<commit>` within the `<rpc>` envelope, satisfying the stem's confirmed-commit requirement precisely. Omitting either tag would either skip confirmation entirely or default to the ten-minute timeout.

NETCONF traceoptions output file or /var/log/messages

NETCONF traceoptions capture the full XML exchange, logging malformed payloads with parse-error detail that syslog cannot express. Enabling `traceoptions` under `[edit system services netconf]` writes to a configurable file, satisfying the stem's need for detailed error logging on the Junos device.

show system services netconf ssh

This operational command displays NETCONF-over-SSH service state, confirming the subsystem is enabled and listening on its port. It directly satisfies the stem's verification requirement, unlike configuration-only commands that show intent rather than active listener status.

http://xml.juniper.net/junos/*/junos-rpc

The wildcard namespace `http://xml.juniper.net/junos/*/junos-rpc` identifies Junos-specific RPC and operational tags, where the asterisk is substituted with the actual Junos version at runtime. This satisfies the stem's requirement for the namespace tied to Junos RPCs, distinguishing it from the configuration namespace used for candidate configuration elements.

set system services netconf traceoptions file netconf-debug.log set system services netconf traceoptions flag all

The traceoptions file statement directs NETCONF trace output to netconf-debug.log, and flag all captures every protocol message including XML payloads. This satisfies the requirement to log all NETCONF messages for diagnosing the XML parsing issue.

The <running/> datastore capability is supported, but explicit locking rules or device state might restrict it if unsupported parameters are sent.

The running datastore capability is generally advertised, but the request can still fail or return empty when unsupported parameters are included or locking and device state interfere. This satisfies the stem by explaining why an otherwise valid get-config request yields no usable result.

<command>show version</command>

The <command> RPC element encapsulates raw Junos CLI operational commands within a NETCONF request, returning the output as XML. This satisfies the scenario's requirement to run operational commands such as 'show version' without mapping them to dedicated RPCs.

<validate><source><candidate/></source></validate>

The validate RPC with a candidate source instructs Junos to syntax-check and semantically verify the candidate configuration without committing it. This satisfies the stem's requirement to validate without committing, returning errors or warnings while leaving the active configuration untouched.

format="text"

The format="text" attribute on the Junos XML API request tells the device to return plain-text output instead of structured XML. It satisfies the stem's constraint by overriding the default XML encoding, which is useful when human-readable command output is preferred over parseable tags.

Include the indent="true" attribute in the RPC request element.

Adding indent="true" to the RPC request element instructs the Junos XML API to return pretty-printed, indented XML, satisfying the stem's formatting requirement. The attribute is parsed server-side and alters only serialisation whitespace, leaving the operational data itself unchanged, so the response remains valid while being easier to read.

The device returns an <rpc-error> indicating an invalid namespace or unrecognized element.

Junos validates incoming RPCs against the loaded YANG schema, so a prefix bound to an undeclared namespace fails parsing before any datastore lookup occurs. The device returns an `<rpc-error>` with an invalid-namespace or unknown-element condition, satisfying the stem's mismatched-prefix constraint rather than silently ignoring it.

Juniper specific capability strings for commit/rollback features advertised in the hello banner.

Juniper advertises proprietary capability URIs in its NETCONF hello banner, such as `junoscript` and commit-related extensions, which explicitly signal support for rollback to previous commit points. Standard base capabilities like candidate or confirmed-commit do not convey this vendor-specific rollback functionality, so the Juniper strings satisfy the stem's requirement.

Executing multiple RPCs or using container elements such as <get-system-information> and <get-chassis-inventory>.

No single standard RPC returns both; scripts must issue separate calls such as <get-system-information> and <get-chassis-inventory>, or combine them within one NETCONF request using multiple RPC elements. This satisfies the requirement to gather software version and hardware inventory together.

Yes, changes applied to the candidate datastore require an explicit <commit> RPC to become active in running configuration.

The candidate datastore holds edits in a staging area, so the <commit> RPC is required to copy them into the running configuration. Without it, the routing protocol changes stay inactive, contradicting the stem's requirement that they take effect immediately.

candidate

The candidate datastore holds uncommitted configuration changes, letting NETCONF clients stage edits and validate them before committing to the running configuration. This satisfies the stem's requirement for a commonly supported datastore, since Junos exposes candidate as a standard NETCONF capability for transactional, atomic configuration changes.

running

The running datastore holds the active, committed configuration in Junos and is the default target for NETCONF edit-config operations, satisfying the stem's requirement for a commonly supported datastore. Junos exposes it through the standard NETCONF `<running/>` element, so automation tooling can retrieve or modify live configuration directly.

target

target specifies which datastore (e.g., candidate) receives the edits.

default-operation

default-operation defines how nodes without explicit operations are handled.

session-timeout

Session timeouts are configured separately, but target and default-operation are direct edit-config parameters.

Appropriate XML namespace definitions (xmlns)

Namespaces are required for XML parsing and RPC validation.

<commit-timeout>

Timeout is optional for commits, but rpc and namespace are mandatory wrappers.

<rpc>

The <rpc> element wraps every NETCONF request message.

Junos PyEZ library

Junos PyEZ is a Python library that abstracts the Junos XML API, connecting over NETCONF or telnet/console to load configuration and retrieve facts. It satisfies the stem's requirement for an alternative interface to the XML API beyond NETCONF over SSH.

XML API over HTTP/HTTPS (mgmt daemon)

The Junos management daemon exposes the XML API directly over HTTP or HTTPS, accepting XML-formatted RPCs without NETCONF framing. This satisfies the stem's requirement for another protocol that interacts with the Junos XML API besides NETCONF over SSH.

<candidate/>

<get-config> accepts <candidate/> as a source target, allowing retrieval of the candidate configuration datastore on Junos. This is valid because Junos supports the candidate datastore capability, distinguishing it from targets such as <startup/> that <get-config> cannot address.

<running/>

<running/> is a mandatory <get-config> source target under the NETCONF base specification, representing the active running configuration. Junos supports it alongside <candidate/>, making it a valid target for retrieving configuration data via the <get-config> RPC.