I85PREP
⌘ K
JNCIE-DC study materials
JNCIE-DC study resources

JNCIE-DC: Automation, Programmability, and Orchestration

JNCIE-DC · Work through your exam, one topic at a time.

All guide sections

Automation, Programmability, and Orchestration

Domain 6 tests whether you can change a fabric repeatably and safely: templates, an API, a check step, and a rollback path.

Tools and transports

  • NETCONF over SSH on port 830, which must be enabled with set system services netconf ssh; YANG models and OpenConfig sit on top.
  • Junos PyEZ (jnpr.junos.Device, jnpr.junos.utils.config.Config): load_config with a Jinja2 template, commit_check(), diff(), commit(), rollback().
  • The Junos REST API on port 3000 (/rpc/<rpc-name>), enabled with set system services rest https; JSON or XML responses.
  • Ansible with the juniper.device collection: junos_config, junos_command, junos_facts, usually over connection: netconf.
  • ZTP: a factory-default device gets an address by DHCP, learns the image and config location from DHCP options, pulls them over HTTP/TFTP, and applies them unattended.

Safety pattern

Always validate before committing and wrap the change in commit confirmed <minutes>, so a lost session reverts the device instead of locking you out of a spine.

Worked example

A PyEZ script pushes VLAN 100 to four leaves: it renders a Jinja2 template with per-leaf variables (loopback, VNI, RT), calls cu.load(template_path=..., template_vars=..., merge=True), runs cu.commit_check() and aborts on failure, then cu.commit(confirm=5, comment='vlan100'). After verifying with show evpn instance, the operator issues commit again to confirm. Nothing is overwritten globally, and any error leaves the fabric as it was.

Traps

Assuming NETCONF is on by default; passing override=True and erasing unrelated configuration; skipping commit_check; forgetting REST must be enabled; templating the RD but hard-coding the RT so every leaf collides.