I'd argue that's not documentation at all, but a statement of intent. A *proposed* state or maybe even a snapshot of a particular time is more likely. - Josh On Wed, Mar 19, 2025, 6:40 AM borg--- via NANOG <nanog@lists.nanog.org> wrote:
Hmm, I somehow reversed the model here. The source of trust is documentation, NOT the network. Works pretty well here, but I guess because I have very small scale. Managing around 200+ switches (campus and R&D networks).
Yeah, it requires a discipline how you work. First, change the docs. Then do validation and review. Commit and then change the network.
---------- Original message ----------
From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 11:12:24 +0100
If there was such a world, I would quickly invent CLI tools to do the things I need. Do note I would not automatically set those tools to actually login to boxes and do things, but perhaps use the command line to rationally poke at the infrastructure serving web pages, and make it do stuff.
In the present, not quite so perfect world, the ability of the available commercial management solutions to present a concise and detailed picture of errors is severely vectorised -- it is quite good at some things while it is right horrible and smash-the-keyboard-in-the-screen-rage-inducingly bad at others. Probably they excel the most in helicopter view ability: You can see and sometimes do things to a lot of systems in parallel.
Further, all management solutions I've seen, no exceptions, are severely constrained in what solutions they can support. In effect, the management platform works like a T-Ford; you can build any network you want, as long as it is a spine-leaf model and you connect the yellow cables to the leftmost port. And a host of similar stupid but understandable constraints.
Finally, given the extraction of truth source from the network element into the management layer, you basically are requiring the management platform to be 100% available. Any local fault mitigation at the network element layer will add an inconsistency between the phantom image of network state in the management layer, and the actual state in the network.
Adding those together, most network management systems give you pinhole 20/20 vision on some things while lying to you in other directions, and also tying your hands in both planning and operations.
This leaves us with a mixed picture. (yes, I am an optimist!) I would rank my desired improvements thusly starting with the most important:
* The network must be the source of truth, once configured.
* The management systems must support all the quirky things we can do at the command line. On the "router".
* Management systems should have their own CLI. Following the simple Unix rules of powerful, understated, automatable, and incomprehensible.
The source of truth is the most important because if it is done right, we can leverage all kinds of tools and all systems will be aligned to the actual state. It also is not trivial. By far.
The full support includes things like "I want to manage my transition in this brownfield by setting up a connection that not only is sub-par and ugly, but also necessary." Much of the niceties will happen under bullet no 1 above, because I can do all specials on the CLI and the system should follow suit -- but if it could be done in any management channel there could be a wider adaptation.
Finally, a management solution aimed at professionals must be extendable and the command line still has the lowest threshold there. Especially if you are trying to onboard greybeards in your new shining world.
</soapbox> -- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I want another RE-WRITE on my CEASAR SALAD!! _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XIOANOB2...