Network automation & observability
Network automation means treating device configuration as data and code: a source of truth describes what should exist, templates and scripts render it, and tooling pushes it to routers, switches and firewalls the same way every time. Our team builds this with Ansible, Nornir and NAPALM for change execution, NetBox as the inventory and IP address record, and Git as the history of every change.
What we do
- Ansible, Nornir and NAPALM playbooks and scripts for repeatable network changes
- NetBox as the source of truth for devices, VLANs, prefixes and cabling
- Git-based review, history and rollback for network configuration
- NETCONF/YANG and gNMI/OpenConfig where the platform supports them
- Batfish checks of planned routing, reachability and ACL changes
- Oxidized backups with drift detection against the intended state
- Prometheus and Grafana dashboards for interfaces, BGP sessions and latency
- sFlow and IPFIX collection to see top talkers and flood sources
On the device side we use the standard management interfaces where the platform supports them: NETCONF (RFC 6241) with YANG models (RFC 7950), and gNMI with OpenConfig models for configuration and streaming telemetry. Before a change goes live, Batfish can check the planned configuration for routing, reachability and ACL errors, and Oxidized keeps a versioned backup of what is actually running.
Observability closes the loop. Prometheus and Grafana carry interface, session and latency metrics, while sFlow (RFC 3176) and IPFIX (RFC 7011) flow records show who is using the links and where a flood is coming from. This work belongs to our Managed IT and Cyber Automation services, and every automated change keeps a reviewer, a diff and a rollback.
Leading platforms we work with
- Ansible
- Nornir
- NAPALM
- NetBox
- Batfish
- Prometheus
- Grafana
- Oxidized
- OpenConfig
Platforms and practices
- NETCONF & YANG
- gNMI streaming telemetry
- sFlow
- IPFIX
- GitOps for network configuration
- Config backup & drift detection
- Source-of-truth inventory (IPAM/DCIM)
- Pre-change validation
- Alerting & dashboards
References
- Ansible documentation (open-source IT automation)
- Nornir documentation (Python automation framework)
- NAPALM documentation (core drivers: EOS, IOS, IOS-XR, NX-OS, Junos)
- NetBox documentation (IPAM, DCIM, source of truth)
- Batfish (network configuration analysis)
- Prometheus overview (CNCF-hosted monitoring and alerting)
- Grafana open source
- Oxidized README (network device configuration backup, 130+ OS types)
- OpenConfig projects (YANG models and gNMI)
- RFC 6241: Network Configuration Protocol (NETCONF)
- RFC 7950: The YANG 1.1 Data Modeling Language
- RFC 3176: InMon sFlow
- RFC 7011: IP Flow Information Export (IPFIX)
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
How we use Network automation & observability for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCyber Automation
Custom AI agents that do repetitive work around the clock, with human review where it matters.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageDo we need NETCONF or gNMI before we can automate a network?
No. Ansible, Nornir and NAPALM can change many devices through their usual management interfaces. We use NETCONF with YANG, and gNMI with OpenConfig, where the platform supports them, mainly for structured configuration and streaming telemetry. The device models in your network decide the mix.
What does Batfish check before a change goes live?
Batfish analyzes the planned configuration for routing, reachability and ACL errors before anyone touches a device. It answers questions such as whether a route will still be learned or a rule will block a service. It reduces surprises, but it does not replace a change window and a rollback plan.
What is the difference between sFlow and IPFIX?
Both show who is using your links and where a flood is coming from. sFlow (RFC 3176) is the InMon format for sampled traffic data. IPFIX (RFC 7011) is the IETF standard for exporting flow records. We collect whichever your switches and routers support and show the result in Grafana.
What does NetBox add if our configurations are already in Git?
Git records what the configuration was. NetBox records what should exist: devices, VLANs, prefixes and cabling, as the source of truth. Templates render the intended configuration from that record, so a change starts from data instead of from someone's memory of the network.
How do you find configuration drift?
Oxidized keeps a versioned backup of what is actually running on each device. We compare that with the intended configuration from the source of truth and Git. A difference means someone changed a device by hand, and we review it and either adopt it or correct it.
Can automation change devices without a human review?
Not in our practice. Every automated change keeps a reviewer, a diff and a rollback. Playbooks and templates are reviewed in Git like code, validated before the change where possible, and applied the same way every time. Automation makes changes repeatable and reviewable; it does not remove the review.