10 September 2026 · 8 min read · recloud engineering

Network provisioning automation with NETCONF, YANG and Ansible

Every operator says they want network automation; what they usually have is a folder of Ansible playbooks that push CLI lines and a standing agreement not to run them on Fridays. The difference between that and real provisioning automation isn't the tool — it's treating device configuration the way software teams treat code: generated from data, reviewed as a diff, validated before commit, and rolled back mechanically when wrong.

Source of truth first, playbooks second

Automation that reads its intent from the devices it configures is circular. Start with a source of truth — NetBox or Nautobot for inventory, IPAM and interface data — and generate configuration from it. The workflow becomes: change the data, review the generated diff, push. Nobody edits device config directly; the truth lives in one queryable place, which is also what your monitoring and provisioning pipelines should read.

NETCONF and YANG: transactions, not screen-scraping

CLI scraping breaks on a syntax change and cannot tell you what would happen. NETCONF gives you structured operations against YANG-modelled data, and — on Junos and IOS XR/XE alike — the two primitives that make automation safe:

Candidate configuration: stage a change, diff it against running, validate it on-box, then commit — or discard without a trace.
Confirmed commit: commit with a rollback timer, confirm only after your checks pass. If your change severs your own management path, the device restores itself.

# Junos via ncclient
with manager.connect(host=r, port=830, hostkey_verify=True) as m:
    m.lock("candidate")
    m.edit_config(target="candidate", config=render("bng-subscriber-vlan.xml", ctx))
    print(m.compare_configuration())      # human-readable diff for review
    m.validate(source="candidate")
    m.commit(confirmed=True, timeout="300")
    run_postchecks(r)                     # BGP up? subs authenticating?
    m.commit()                            # confirm inside the window

Ansible where it fits, not everywhere

Ansible is excellent as the orchestration layer — inventory, secrets, ordering, reporting — with junos_config / iosxr_config or netconf_config modules doing device I/O. Keep the intelligence in templates and the data model, keep playbooks thin, and run everything through CI: a merge request that shows the rendered device diff next to the data change is the review artefact that turns network changes into pull requests.

Validation is the half people skip

A change that commits cleanly can still be wrong. Automate the postchecks with the same seriousness as the change itself: BGP session states, expected route counts, subscriber session counts on affected BNGs, synthetic transactions through the affected path. Fail the pipeline — and trigger the confirmed-commit rollback — when postchecks fail. This is the step that converts automation from "faster typing" into "safer change".

Zero-touch provisioning for the access edge

For high-volume device turn-up (CPE, access switches, PON OLT shelves), close the loop with ZTP: the device boots, gets an identity from DHCP options, pulls its generated config from the provisioning service, and registers itself in the source of truth. Combined with the order pipeline from the NBN integration article, a new service can go from wholesale-complete to configured-and-monitored without a human touching a terminal.

Where to start

Don't boil the network. Pick one high-volume, low-variance change — subscriber VLAN turn-up, or firewall rule additions — and take it end-to-end: data model, template, diff review, validated commit, postchecks. One change class done properly recruits the rest of the team better than any architecture document.