Network automation for ISPs Network automation for ISPs. One person.
Most platforms ask you to reshape your operation to fit their model. I build on Nautobot the other way round — a source of truth that reflects how your network actually works, with intended configuration rendered from it and pushed over NETCONF to IP Infusion OcNOS and Juniper.
Most tools make you change how you work to suit them. I do it the other way round: model your network as it actually is in Nautobot, generate the config from that, and push it over NETCONF. Mostly OcNOS and Juniper.
No change. Candidate matches running — nothing to commit.
What I do
I start from the data you already have and the way your team already works. A source of truth that nobody trusts produces automation that nobody runs.
I start from what you've already got and how your team already works. If people don't trust the source of truth, they won't run anything built on top of it.
Modelling the network as data — sites, devices, circuits, IPAM and the relationships between them — populated from what is actually deployed.
Getting the network into Nautobot as real data: sites, devices, circuits, IPAM. Based on what's actually deployed, not what the spreadsheet says.
Templates that render intended configuration from the source of truth and push it over NETCONF, with the candidate-versus-running diff visible before anything commits.
Templates that build the config from the source of truth and push it over NETCONF. You see exactly what will change before it commits.
Jobs, webhooks and CI that connect Nautobot to the rest of your operation, so a change is made in one place and lands everywhere it needs to.
Jobs, webhooks and CI so Nautobot actually talks to everything else, and you change a thing once instead of in five systems.
Platforms
Source of truth, custom jobs, NETCONF config delivery, and the data modelling work that determines whether any of it holds up under real operations.
Source of truth, custom jobs, pushing config over NETCONF, and getting the data model right so the rest doesn't fall apart later.
Config templating, NETCONF delivery and device onboarding on disaggregated platforms.
Templating, NETCONF pushes and onboarding for OcNOS boxes.
Intended configuration and NETCONF-driven change across edge and aggregation.
Same work on Junos, across edge and aggregation kit.
Subscriber provisioning and modem diagnostics. CableOS is the primary test platform for ProvOSS.
Subscriber provisioning and modem diagnostics. CableOS is what I test ProvOSS against.
How this works
A defined problem with a defined end — a failure you cannot close, or automation that has stopped being trusted.
One nasty problem, fixed. Something broken nobody can close out, or automation everybody has quietly stopped running.
A source of truth build, a NETCONF config rollout, or a migration — scoped, delivered, and documented so your team owns it afterwards.
A source of truth build, a NETCONF config rollout or a migration. Scoped up front and written down properly so your team can run it once I'm gone.
Ongoing availability for operators who want an automation specialist on hand without carrying the headcount.
I'm around when you need me. Cheaper than hiring someone full-time for a problem that only turns up some weeks.
Contact
Include your platforms and roughly what you are trying to automate. I reply to every operator who writes in.
Say what kit you run and what you're trying to automate. I read and answer everything from an actual operator.