Network Automation · Plan / Build / Operate
We build the automation chain for your network: source of truth, configuration as code, validation and controlled execution — a tool for dependable changes, not an end in itself.
Discuss automation4 services · Network Automation
Good automation starts with dependable data and a bounded use case. We connect a source of truth, code, tests and approvals into a process your team can own.
Discuss your requirementsOrganise inventory, IP addresses and intended state into a dependable foundation for network operations.
Version, test and roll out recurring configurations with a controlled scope of change.
Connect changes to evidence through reviews, before-and-after tests and explicit pipeline approvals.
Connect controllers, inventory and tickets with traceable jobs and deliberate failure handling.
The exact scope follows your environment and its dependencies. Pricing, service hours and response targets are agreed in the proposal.
Scope
The building blocks of an automation chain that renders, validates and rolls out changes — and never loses sight of the live state.
NetBox as the leading data model: sites, devices, VLANs and prefixes — reconciled against reality.
Target configuration from Jinja2 templates and structured data, versioned in Git instead of loose files.
Render, diff, dry run, approval, deploy: every standard change travels the same proven track.
Pre- and post-checks for routing, adjacencies, redundancy and reachability — before and after every change.
Target-versus-actual comparison in operations: deviations surface before they become incidents.
Runbooks, roles and training: your team runs the chain — or we do, as a managed service.
Approach
Automation follows risk and economic benefit — in exactly that order.
How reliable are inventory, standards and the change process? Where does automation pay off first?
NetBox is built and populated; the truth moves out of spreadsheets and heads into a verified model.
One recurring change is automated end to end — with tests, approval and rollback.
Further use cases, mandatory peer review, separated environments and complete logging.
In plain language
Source of truth, configuration as code and tested changes: the foundations of traceable network operations, with explicit data ownership and approvals.
Recurring changes often apply the same requirements across many devices. Templates and Ansible can standardise that workflow. This reduces manual repetition but can also multiply a mistake. Reviewed input, a bounded scope and before-and-after checks therefore belong in the design from the start. We begin with one task whose value and risks can be assessed.
NetBox can document the intended state of sites, devices, VLANs and IP addresses. We define ownership, maintenance and approval before generating configuration from it. Changing a record does not automatically authorise a network change. Observed and intended state are reconciled separately, with conflicts requiring an explicit decision.
pyATS/Genie or appropriate alternatives can compare selected network functions before and after a change. Expected routes, neighbours or connections are explicitly defined. Missing data does not count as success, and a passing test does not prove every application works. Acceptance connects observations to the agreed expectations.
All templates and configurations live versioned in Git — the same tool software teams have trusted for decades. For every change it is recorded who made it, when and why, and what the state looked like before; a four-eyes review before approval is part of the process. For audits and certifications that means the evidence already exists instead of being reconstructed after the fact.
Tooling & platforms
Documented Configlane lab · TI-LFA
In the Next-Gen SP Core lab, CHG-0026 enables TI-LFA on R1–R7. This actual change connects inputs, approvals and operational evidence.
Seven device-specific intent files define candidate configuration and verification conditions. Ansible produces the diff; a manifest binds the plan, Git commit, target hosts and execution image.
A separate approver signs the reviewed plan. Signature, scope and manifest are checked again before serial application. A mismatch stops execution.
CHG-0026 proves operational SR repair paths on all 20 directed core interfaces. CHG-0027 then detaches R1–R2; the repair path through R3 carries traffic. CHG-0028 restores the link as a separate change.
FAQ
Repetition, data quality, risk and maintenance effort matter more than a fixed device count. We assess a specific use case and start where the benefit is defensible. A universal payback period would be a guess without that assessment.
No — it moves their work from the keyboard to the decision. Approvals stay with people; the machine takes over the error-prone typing and checking. Teams win back time for architecture and improvements instead of late-night routine changes.
To operate it: no. The pipeline is built so that standard changes run through maintained data and defined workflows — no coding required. If your team wants to go deeper, we provide training and runbooks; alternatively we keep operating the pipeline as a managed service.
The core of our practice: Cisco IOS-XE (Catalyst), NX-OS and the Meraki Dashboard API — and in principle anything with a usable API or SSH access. Ansible and Python are vendor-neutral; the initial assessment clarifies whether your environment is a fit.
Before the change, we define stop criteria, before-and-after checks and an appropriate recovery path. Check mode and restoration depend on the module, device and intervention. A failed run therefore does not automatically mean that every change can be reversed.
With the assessment: we review inventory, standards and your change process, then pick the one pipeline with the best ratio of benefit to risk. It first runs in parallel with your usual way of working until the results convince — only then does it become the standard.
Merged, replaced, overridden: how resource modules turn commands into state, why no run starts without a dry run and a diff — and which states run without any device at all.
6 min readAutomation · MethodAutomation needs one instance that says what should be true. Why NetBox holds the intended state instead of importing the live one, the order to fill it, and the handover to Ansible.
9 min readCryptography · OperationsFirst 200, then 100, from 2029 47 days: why shorter certificate lifetimes are mainly a network operations problem — and which places break first.
6 min readNext step
We start with the assessment, then automate the track that pays off first — traceable and under defined controls.
Request an assessmentAssessment → first dependable change
