Network Automation with Junos and APIs
Network Automation with Junos and APIs
This domain tests how to programmatically read and change Junos state using NETCONF, REST, XML, YANG, and telemetry interfaces.
Core rules
- Junos supports NETCONF over SSH (default TCP 830), the Junos XML API, and a REST API over HTTP/HTTPS. REST requires the
restservice configured undersystem services; use HTTPS in production. - NETCONF session flow: exchange
<hello>and capabilities, use<edit-config>against the candidate datastore, then<commit>. Junos also supports<get-config>and operational<rpc>requests. - Junos XML API RPCs include
<get-interface-information>,<load-configuration>, and<commit-configuration>. XML namespaces matter; use a parser, not string slicing. - YANG models describe configuration and state; OpenConfig models are vendor-neutral. Junos supports native YANG and OpenConfig for many features, but coverage is not universal.
- REST endpoints:
/rpcfor operational commands,/configfor configuration. SetContent-TypeandAccepttoapplication/xmlorapplication/json. Junos Telemetry Interface streams operational data over gRPC and is read-only monitoring, not a config channel.
Worked example
Get interface status with curl:
curl -k -u auto:secret https://10.0.0.1/rpc/get-interface-information -H 'Accept: application/json'
Reasoning: -k skips certificate validation for a lab only; -u supplies credentials; /rpc/ invokes an operational RPC; Accept: application/json asks Junos to return JSON instead of XML. For configuration, POST to /config/ with an XML payload, then commit through /rpc/commit-configuration.
Traps
- Using port 22 for NETCONF; it is 830.
- Sending configuration to
/rpcinstead of/config. - Forgetting the commit after
edit-config; candidate changes are not active. - Ignoring XML namespaces or using
-kin production. - Assuming every OpenConfig path is supported on every Junos release.