I went to Networking Field Day 40 expecting Netris to show me something about AI clusters. They did. Alex Saroyan walked us through how they automate networks for neo-cloud operators running thousands of switches and tens of thousands of GPUs. That is not your network. It is not my network. The closest thing most of us run to a “GPU cluster” is the rack where the security camera NVR lives.<\/p>\n\n\n\n
But about two-thirds of the way through the session, a delegate asked a question that has nothing to do with AI.<\/p>\n\n\n\n
The question was, paraphrased: “With your product in place, do your customers still back up their configs?”<\/em><\/p>\n\n\n\n Alex’s answer was a flat no. No per-switch config backups. Switch dies, you slot in a replacement, the agent on the new switch wakes up, calls home to the controller, looks at the model of what that switch is supposed to be, and regenerates the config from scratch. The controller gets backed up. The switches don’t.<\/p>\n\n\n\n What got me was the delegate’s follow-up: he kind of shrugged and said he knew enterprise networks that didn’t back up their configs either, and they moved on like it was a minor side note.<\/p>\n\n\n\n That side note is this post. Because the more I sat with that exchange, the more I realized it exposes something I had never thought to say out loud about how most of us actually run our networks.<\/p>\n\n\n\n If you’re running a mid-sized business network, your config backup story probably looks something like one of these:<\/p>\n\n\n\n This has been “best practice” for as long as I have been in networking. Nobody has ever taken me aside and told me to stop doing it. The auditors love seeing the backups. The disaster recovery plan references them. Everybody nods.<\/p>\n\n\n\n But step back and ask what the act of backing up the config is actually saying. It is saying: the running config on that box is the primary record of how this part of the network is supposed to work. If that box dies, that file is the thing we need to rebuild from. The config isn’t just an artifact; it is<\/em> the network’s memory.<\/p>\n\n\n\n That’s the part that snuck up on me at NFD40. I had never thought of it that way before.<\/p>\n\n\n\n I’m not going to turn this into a vendor tour. I will just say enough about the Netris model to make the contrast clear, because the contrast is the whole point.<\/p>\n\n\n\n In Netris’s world, intent lives in the controller. Topology, IPAM, what services should exist on what switches, what tenant gets what VRF, all of that. Each switch runs an agent. The agent’s job is to look at what the controller says this switch should be doing, and translate that into actual device config on the box. The config is an output<\/em> of the model, not the input.<\/p>\n\n\n\n So when a switch dies, the procedure is: pull the dead one, rack a new one, let the agent boot up and call home. Controller goes, “oh, you’re switch 17, here’s what you should look like,” and the agent regenerates the config. No backup file restored. No copy-paste from a Word doc. The new switch arrives at the right state because the source of truth knew what the right state was the whole time.<\/p>\n\n\n\n This only works because the network is declarative<\/strong>, not imperative.<\/p>\n\n\n\n Jargon Box: Declarative vs. Imperative Networking<\/strong><\/p>\n\n\n\n Imperative<\/em> means you tell the device how<\/em> to do something, step by step. “Configure interface gig 1\/0\/1, set it to access mode, put it in VLAN 20, save the config.” Most of us spent our careers typing imperative commands into a CLI.<\/p>\n\n\n\n Declarative<\/em> means you describe what<\/em> the network should look like, and something else figures out the commands to get there. “Switch 17 is a leaf in fabric A and serves tenant Bravo.” The system works out the rest.<\/p>\n<\/blockquote>\n\n\n\n Here’s the part that earned this post its title.<\/p>\n\n\n\n If you’re backing up your switch configs, you are admitting that the device is the only place certain pieces of knowledge actually live. Maybe most of it lives in your documentation, but there is something on that box that you cannot reconstruct without it. Otherwise, you wouldn’t need the backup.<\/p>\n\n\n\n Which means your “source of truth,” whatever you call it (NetBox, a SharePoint site, a Visio diagram from before the Slack migration, your inventory in SolarWinds), is not really the<\/em> source of truth. It’s a description. The running config is the truth, and your documentation is just whatever you remembered to write down about it, with however much drift has crept in since the last time somebody updated it.<\/p>\n\n\n\n That’s the inversion. In a healthy model, configs are a consequence<\/em> of the source of truth. In most of our networks, the running config is<\/em> the source of truth, and everything else is a partial, lagging copy.<\/p>\n\n\n\n Jargon Box: Configuration Drift<\/strong><\/p>\n\n\n\n When the running state of a device gradually diverges from what your documentation says it should be. Caused by emergency changes that nobody documented, “temporary” fixes that became permanent, and that one engineer who left in 2021 and never told anyone about the static route he added at 2 a.m.<\/p>\n<\/blockquote>\n\n\n\n I want to be fair to us. The economics of going fully declarative have never quite worked out for a 30-switch network. Buying a real network automation platform for that scale is overkill. Building your own with Ansible and a NetBox install is a meaningful chunk of somebody’s time, and that somebody is also patching servers, arguing with the firewall vendor, and figuring out why the conference room TV won’t connect to Zoom.<\/p>\n\n\n\n The CLI is sticky because it’s how all of us learned. It’s how we troubleshoot at 2 a.m. when the change window is closing. It is genuinely faster, for one box, to just type the commands than to update a model and let something else generate the config.<\/p>\n\n\n\n I am not saying midmarket networks are doing it wrong. I am saying we should be honest about what our tooling is telling us. If your primary recovery plan is “restore from the config backup,” then the config backup is your source of truth, no matter what your network diagram claims.<\/p>\n\n\n\n You’re not going to go full Netris. Nobody is selling you the midmarket version of that, at least not at a price your CFO is going to approve this year. But you can move the center of gravity, even on a small network:<\/p>\n\n\n\n None of that requires a platform purchase. It requires admitting that the way most of us run networks today has the relationship between documentation and configuration exactly backwards.<\/p>\n\n\n\n Alex’s offhand answer at NFD40 wasn’t really about Netris. It was a paradigm exposure. The question isn’t whether you should <\/em>back up your configs. The question is, what does it mean that you have to?<\/em><\/p>\n\n\n\n I am not arguing that every mid-sized network needs to go declarative. Most of us won’t, and that is fine. But the gap between “the running config is my source of truth” and “my source of truth generates the running config” is the same gap that, on a much bigger scale, separates the way Netris runs a 50,000 GPU cluster from the way most of us have been running networks for 25 years.<\/p>\n\n\n\n The thing worth stealing from the AI networking conversation isn’t the rail-optimized fabrics or the DPUs or the InfiniBand. It’s the discipline. If you walk away from this post and do exactly one thing, let it be this: the next time you make a change to your network, write down why<\/em> before you write the config. That one habit, repeated for a year, will put you in a better position than any platform purchase will.<\/p>\n\n\n\n The backup is just a sanity check. It should not be the plan.<\/p>\n\n\n\n Disclosure: I attended Networking Field Day 40 as a delegate. Travel, accommodations, and meals during the event were covered by Tech Field Day. I was not asked to write about Netris or any other presenter, and my opinions here are entirely my own.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" At Networking Field Day 40, Alex Saroyan from Netris illustrated how their AI clusters automate networks without the need for config backups. The discussion revealed a common issue: many networks rely on outdated backup practices, treating running configs as the primary truth. A shift towards documenting intent can enhance network management.<\/p>\n","protected":false},"author":1,"featured_media":1893,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"Your switch config backups are telling on you. If you need them to rebuild, your \"source of truth\" isn't. A takeaway from Networking Field Day 40 that applies whether you run 30 switches or 3,000. #nfd40","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[88,165],"tags":[89,176],"class_list":["post-1890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-tech-field-day","tag-blog","tag-tech-field-day"],"yoast_head":"\nWhat we’re really doing when we back up configs<\/h2>\n\n\n\n
\n
show run<\/code> to a file share every night<\/li>\n\n\n\nThe Netris contrast (briefly, I promise)<\/h2>\n\n\n\n
\n
The quiet admission<\/h2>\n\n\n\n
\n
Why midmarket landed here<\/h2>\n\n\n\n
What you can actually steal from this<\/h2>\n\n\n\n
\n
Final Thoughts<\/h2>\n\n\n\n
\n\n\n\n