Weighing in a little late, but... Love it, need it, for everything.  Down to telneting to a port and interacting with protocol directly. It's pretty hard to compose operations, write scripts, automate any kind of process - without a CLI interface. sh, stdin, stdout, stderr forever. In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown

Hi Mark, folks, IMHO there's no reason to use a GUI on a routing or switching platform; it just makes things - more complicated to achieve (properly) - more difficult to replicate - impossible to automate apart from - creating CPU load and memory overhead - blowing up the code tenfold - inviting protocol attacks and incurring CVEs galore - everybody cooking their own and nothing being familiar on mixed platforms Ggraphing etc? Fine, but why would that have to be built into the box? Debugging? Yeah, try tweaking a hundred times through a GUI. Orchestration? If you need some kind of process-oriented software for this, automation is available with a standard protocol (netconf), and it's being used with different levels of success (smart implementations allow CLI add-ins.) Nobody in their right mind clicks a config. I can, btw, see a case for a fancier frontend on firewalls, where the changes will trigger automation in the backend. But still the first thing to disable on any network gear - for me - is disabling that ***censored*** that is being forced on us. Just my 2 Eurocents, from an old fart, Elmar.

...

Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?

Speaking of gmail keyboard shortcuts, did you by any chance see this yet. https://support.google.com/mail/answer/6594 From: Shawn L via NANOG <nanog@lists.nanog.org> Date: Wednesday, 19 March 2025 at 4:21 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Shawn L <shawnl@up.net> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? "Grew up" on elm and vi (someone please make a gmail addon that supports VI keys) -- CLI all the way. I will admit (grudgingly) that there are some things that a GUI is more suited for. It can be a lot easier to visualize traffic flows with graphs, etc. rather than packet counters. There is also a lot of new gear where just putting a port on a vlan and accepting un-tagged traffic becomes a 10 line config in cli. Who thought this was a good idea? Yes, I can do it with 10 clicks in the GUI, but I don't want to, I want to blow a standardized config on it, then just make a couple of tweaks. -----Original Message----- From: "borg--- via NANOG" <nanog@lists.nanog.org> Sent: Tuesday, March 18, 2025 6:11pm To: nanog@lists.nanog.org Cc: borg@uu3.net Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? CLI forever ;) But more seriously. CLI is great, its quick, can run on toaster and its easya automated using scripting (generate, replace, preprocess). I like CLI to the point that my docs stuff runs under CLI terminal. The GUI is only used for visualizers. I hope that CLI will stay for a long time... ---------- Original message ---------- From: Mark Prosser via NANOG <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: Mark Prosser <mark@zealnetworks.ca> Subject: [NANOG] The Network CLI -- Love it ? Hate it? Needed? Date: Tue, 18 Mar 2025 15:05:33 -0400 Hi NANOG community, I posed this question in several chat groups, but I'd like to get your opinions. Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network? This applies to both provisioning and troubleshooting; to which, you may have different answers. So far, I've seen a variety of replies around the usual "should/must/must not/should not". Warm regards, -- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/M7MASHV2... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DXLGLBTJ...

That one, for sure. Remove or disable things that are not being used. It can't fail or be compromised if it's not there. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jeff Moore via NANOG" <nanog@lists.nanog.org> To: "North American Network Operators Group" <nanog@lists.nanog.org> Cc: "Jeff Moore" <mail@jeffmoore.com> Sent: Tuesday, March 18, 2025 6:11:32 PM Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Always been CLI first. Probably too oldschool but have always felt that one of the best security commands on network gear is "no ip http server". Old unix instructor I had always beat it into our head if you don't use it every day remove it. Every added service/component is one more avenue into your system and another potential failure point. On Tue, Mar 18, 2025 at 4:07 PM Suresh Ramasubramanian via NANOG < nanog@lists.nanog.org> wrote:

Speaking of gmail keyboard shortcuts, did you by any chance see this yet. https://support.google.com/mail/answer/6594

From: Shawn L via NANOG <nanog@lists.nanog.org> Date: Wednesday, 19 March 2025 at 4:21 AM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Shawn L <shawnl@up.net> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed?

"Grew up" on elm and vi (someone please make a gmail addon that supports VI keys) -- CLI all the way.

I will admit (grudgingly) that there are some things that a GUI is more suited for. It can be a lot easier to visualize traffic flows with graphs, etc. rather than packet counters.

There is also a lot of new gear where just putting a port on a vlan and accepting un-tagged traffic becomes a 10 line config in cli. Who thought this was a good idea? Yes, I can do it with 10 clicks in the GUI, but I don't want to, I want to blow a standardized config on it, then just make a couple of tweaks.

-----Original Message----- From: "borg--- via NANOG" <nanog@lists.nanog.org> Sent: Tuesday, March 18, 2025 6:11pm To: nanog@lists.nanog.org Cc: borg@uu3.net Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed?

CLI forever ;) But more seriously. CLI is great, its quick, can run on toaster and its easya automated using scripting (generate, replace, preprocess).

I like CLI to the point that my docs stuff runs under CLI terminal. The GUI is only used for visualizers. I hope that CLI will stay for a long time...

---------- Original message ----------

From: Mark Prosser via NANOG <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: Mark Prosser <mark@zealnetworks.ca> Subject: [NANOG] The Network CLI -- Love it ? Hate it? Needed? Date: Tue, 18 Mar 2025 15:05:33 -0400

Hi NANOG community,

I posed this question in several chat groups, but I'd like to get your opinions.

Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?

This applies to both provisioning and troubleshooting; to which, you may have different answers.

So far, I've seen a variety of replies around the usual "should/must/must not/should not".

Warm regards,

-- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/M7MASHV2... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DXLGLBTJ... _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/T6TVCGBI...

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/B26CL3SV...

CLI is the way to go, but tools are wonderful for automating repetitive CLI tasks and ensuring that provisioning/deprovisioning is done consistently is massively helpful. GUIs have their place, as long as they're not web apps that require client-side Java (Cisco ASDM for example) are just plain evil... Thank you jms On Tue, Mar 18, 2025, 10:46 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:

...

There is also a lot of new gear where just putting a port on a vlan and accepting un-tagged traffic becomes a 10 line config in cli. Who thought this was a good idea? Yes, I can do it with 10 clicks in the GUI, but I don't want to, I want to blow a standardized config on it, then just

make a

...

couple of tweaks.

I don't know who needs 10 lines of config for this, but I hear copy paste is a viable option for such a need.

On Tue, Mar 18, 2025 at 6:51 PM Shawn L via NANOG <nanog@lists.nanog.org> wrote:

...

"Grew up" on elm and vi (someone please make a gmail addon that supports VI keys) -- CLI all the way.

I will admit (grudgingly) that there are some things that a GUI is more suited for. It can be a lot easier to visualize traffic flows with

graphs,

...

etc. rather than packet counters.

There is also a lot of new gear where just putting a port on a vlan and accepting un-tagged traffic becomes a 10 line config in cli. Who thought this was a good idea? Yes, I can do it with 10 clicks in the GUI, but I don't want to, I want to blow a standardized config on it, then just make a couple of tweaks.

-----Original Message----- From: "borg--- via NANOG" <nanog@lists.nanog.org> Sent: Tuesday, March 18, 2025 6:11pm To: nanog@lists.nanog.org Cc: borg@uu3.net Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed?

CLI forever ;) But more seriously. CLI is great, its quick, can run on toaster and its easya automated using scripting (generate, replace, preprocess).

I like CLI to the point that my docs stuff runs under CLI terminal. The GUI is only used for visualizers. I hope that CLI will stay for a long time...

---------- Original message ----------

From: Mark Prosser via NANOG <nanog@lists.nanog.org> To: nanog@lists.nanog.org Cc: Mark Prosser <mark@zealnetworks.ca> Subject: [NANOG] The Network CLI -- Love it ? Hate it? Needed? Date: Tue, 18 Mar 2025 15:05:33 -0400

Hi NANOG community,

I posed this question in several chat groups, but I'd like to get your opinions.

Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?

This applies to both provisioning and troubleshooting; to which, you may have different answers.

So far, I've seen a variety of replies around the usual "should/must/must not/should not".

Warm regards,

-- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/M7MASHV2...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/DXLGLBTJ...

...

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5BLI6ZUE...

Distilled, for commentary: A properly trained brain can communicate via CLI at a much higher baud rate than a GUI as we have much more tactile bandwidth at our disposal. The fewer senses involved (ie, no aiming) the better. On Wed, Mar 19, 2025 at 3:11 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

I am almost sure that this is not just Network, but this applies to everything people use computers for.

If an application is something that you use infrequently, people will prefer GUI. If an application is something you work hours on end, people will prefer CLI.

I wholly believe that any call center worker will prefer the CLI ticketing system.

I have some anecdotes to support this, like companies migrating from legacy CLI tools to GUI tools. Like Telia UniOSS or factory/warehouse inventory system, in both cases after migration to GUI users were very unhappy, because what used to be fast and didn't require attention to display, now took great care with keyboard, mouse and display.

People will think they will prefer GUI, because we are projecting short-term, and on-boarding to GUI is fast and seems cognitively cheaper compared to scary looking CLI. And managers who make these decisions will never have to use the end product hours every day. The problem looks very different depending on this use-pattern.

Will will be happier and more efficient with the CLI tool they can blaze through, which is responsive, and predictable in that you know what is on screeen after each button press, without looking at the screen. You can navigate deeply nested UX in milliseconds, because you know your workflow and you know the display will catch up.

When I look at a typical network provisioning system, it is essentially an SQL editor and this is the worst possible way you can implement GUI UX.

Of course all of the above is wrongthink and no one will take you seriously if you propose that in the adults table. And making decisions that are good for your career is better than making good decisions.

On Tue, 18 Mar 2025 at 21:06, Mark Prosser via NANOG <nanog@lists.nanog.org> wrote:

...

Hi NANOG community,

I posed this question in several chat groups, but I'd like to get your opinions.

Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?

This applies to both provisioning and troubleshooting; to which, you may have different answers.

So far, I've seen a variety of replies around the usual "should/must/must not/should not".

Warm regards,

-- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

_______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV...

-- ++ytti _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TNGHG2HI...

Thanks Alex. Additionally, not sure post-covid as I've stopped traveling but I used to be shocked how often when you rent a car, check in to a hotel, purchase a SIM card, get your boarding pass, or any such thing. You end up waiting for the service desk, sometimes +10min, and you hear a lot of mouse clicking and keyboard punching. And I can't help to wonder, I'm doing the most common thing this person has to do in their job, and the UX experience to them is this? What is going on? Didn't anyone at all care that this should be 60x faster, this is not the punt-path, this is the fast-path. The service desk should be bandwidth gapped by the customer, not by their UX. On Wed, 19 Mar 2025 at 10:14, Alex Buie <abuie@cytracom.com> wrote:

Distilled, for commentary: A properly trained brain can communicate via CLI at a much higher baud rate than a GUI as we have much more tactile bandwidth at our disposal. The fewer senses involved (ie, no aiming) the better.

On Wed, Mar 19, 2025 at 3:11 AM Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:

...

I am almost sure that this is not just Network, but this applies to everything people use computers for.

If an application is something that you use infrequently, people will prefer GUI. If an application is something you work hours on end, people will prefer CLI.

I wholly believe that any call center worker will prefer the CLI ticketing system.

I have some anecdotes to support this, like companies migrating from legacy CLI tools to GUI tools. Like Telia UniOSS or factory/warehouse inventory system, in both cases after migration to GUI users were very unhappy, because what used to be fast and didn't require attention to display, now took great care with keyboard, mouse and display.

People will think they will prefer GUI, because we are projecting short-term, and on-boarding to GUI is fast and seems cognitively cheaper compared to scary looking CLI. And managers who make these decisions will never have to use the end product hours every day. The problem looks very different depending on this use-pattern.

Will will be happier and more efficient with the CLI tool they can blaze through, which is responsive, and predictable in that you know what is on screeen after each button press, without looking at the screen. You can navigate deeply nested UX in milliseconds, because you know your workflow and you know the display will catch up.

When I look at a typical network provisioning system, it is essentially an SQL editor and this is the worst possible way you can implement GUI UX.

Of course all of the above is wrongthink and no one will take you seriously if you propose that in the adults table. And making decisions that are good for your career is better than making good decisions.

On Tue, 18 Mar 2025 at 21:06, Mark Prosser via NANOG <nanog@lists.nanog.org> wrote:

...

Hi NANOG community,

I posed this question in several chat groups, but I'd like to get your opinions.

Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?

This applies to both provisioning and troubleshooting; to which, you may have different answers.

So far, I've seen a variety of replies around the usual "should/must/must not/should not".

Warm regards,

-- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV...

-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TNGHG2HI...

-- ++ytti

My wife is in medical billing and Medicaid compliance paperwork for children’s therapy. Their software is old as hell but you know what? It’s got tabbable fields. Haha. It’s amazing to hear her in full bore doing 100+ wpm. type a name, tab tab tab tab tab type another name, tab tab tab tab tab type an address tab type a city tab etc. But it’s faster than aiming still.

On Thu, 20 Mar 2025 at 05:21, Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:

Of course, this is why we have APIs. So you can do the once in a while version of a task via an easy to use GUI, but when you need to do it hundreds or thousands of times, you can write code to automate the job.

Not everything on the network has an API, and not everything can easily be done via API even when there is one...so sometimes the CLI is the best way to get the job done.

I wonder if the list is talking about multiple different questions. To me SSH is an API. You could certainly create a REPL CLI loop over GRPC, SOAP, CORBA, REST (which I think is both the newest and worst attempt at RPC, implemented by people who refused to understand why CORBA and SOAP are complex, then implemented very incomplete and poor RPC and started to add complexity once they learned why RPC is more complex than naive idea of REST was). I feel some are reading the question 'should you automate or not' and some are reading the question as 'what UX should data entry/provisioning have' If you can entirely remove humans, that's in my mind a very different question to what kind of tool humans use for provisioning. I understood it as human is needed to provision and we're talking about the UX human has. But I may have misunderstood. Having said that, I also don't believe automation is something that is axiomatically desirable. Humans are really bad at skill retention if skill is not used. CLI jockey things have very many outages that last very little time. Heavily automated things have very few outages that last very long time very. I have some anecdotes for this when a new vendor was introduced with a high degree of automation for it, old vendor issues were quickly solved, even most trivial issues on the new vendor got escalated to design and took a very long time to solve. This lack of routine exposure to the systems also makes it harder to design new solutions well. I don't know what is the right balance, but I do think we are using _too much_ automation, underestimating the cost of trade-offs and outright ending up with a poorer business case. -- ++ytti

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!!

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...

Yeah, you are right here. There is tooling that is able to dump all configs from network devices and compare it to docs and generate reports. I never had to use something like this, but seems usefull to enforce state of trust from documentation.. If deviation is detected, it have to be fixed right away.. And is even easy to blame who made deviation. You can use 'svn blame' from docs and access log from devices. In my small team (5 ppl) it was solved by saying: docs is the only source of trust, if you find deviation, docs telling the true. In case of complains, 'svn blame' + logs to the rescue. ---------- Original message ---------- From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Josh Reynolds <joshr@spitwspots.com>, Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:37:30 +0100

A *proposed* state or maybe even a snapshot of a particular time is more likely.

Documentation that deviates from reality will get ignored, forgotten and rejected. Treating it as plans and intents will work much better. We probably do that without reflecting over it already. Officially acknowledging it will only improve the process. -- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"!

The live network _should_ be the truth, but unless you have really nailed config and change management then your truth is what you remember and humans make terrible eye witnesses. Things might be working, but are your customers getting billing correctly, or the correct service? Or does that failover work? Did you put back in that filter you took out to debug something? I see a number of orgs doing all they can to prevent/minimise any use of CLI and in my view I think it’s the only direction the network can go in. There is way to much complexity and that is growing and growing and managing the truth in your head as what you remember will one day hurt. Outside of power I’d guess CLI makes up the vast majority of network outages. In my view it can’t be the future. Neil. From: sronan--- via NANOG <nanog@lists.nanog.org> Date: Wednesday, 19 March 2025 at 17:08 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: nanog@lists.nanog.org <nanog@lists.nanog.org>, sronan@ronan-online.com <sronan@ronan-online.com> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? It seems people are confusing “source of truth” with “intended truth”, or maybe people have a different definition of truth than I do. The network is always the only source of truth as it is what is actually deployed in the network, it is the truth about what is, while I can intend for that truth to be different, that doesn’t change the reality of the situation. Shane

On Mar 19, 2025, at 12:54 PM, borg--- via NANOG <nanog@lists.nanog.org> wrote:

Yeah, you are right here. There is tooling that is able to dump all configs from network devices and compare it to docs and generate reports.

I never had to use something like this, but seems usefull to enforce state of trust from documentation.. If deviation is detected, it have to be fixed right away.. And is even easy to blame who made deviation. You can use 'svn blame' from docs and access log from devices.

In my small team (5 ppl) it was solved by saying: docs is the only source of trust, if you find deviation, docs telling the true. In case of complains, 'svn blame' + logs to the rescue.

---------- Original message ----------

From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Josh Reynolds <joshr@spitwspots.com>, Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:37:30 +0100

...

A *proposed* state or maybe even a snapshot of a particular time is more likely.

Documentation that deviates from reality will get ignored, forgotten and rejected. Treating it as plans and intents will work much better. We probably do that without reflecting over it already. Officially acknowledging it will only improve the process.

-- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"! _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4UUWI6QO...

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/N3RZ6WKQ...

Hey Mel :D LOL – Of course there is only one truth – But you’ve just underlined the problem with humans and the CLI; humans have their own perspective of the truth and that interferes with the real truth, no I don’t like to have to say that but to ignore it is folly. Customers not configured on the right service, or during a failure the config gets restored from back up where it isn’t accurate because Freddo configured the upgrade but didn’t put it into some type of inventory… The minute you have humans involved in engaging with the CLI is the minute you lose the truth, are there tasks the CLI can be used for without that risk – of course but for anything to do with configuration humans just can’t be involved via CLI. There are far too many important networks in the world that are still being managed like this and our mission as network operators is to maximise the use of the network and ensure that there is trust in what we are providing then more and more and more applications and cool uses of the network will arrive. Neil. From: Mel Beckman <mel@beckman.org> Date: Wednesday, 19 March 2025 at 18:06 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Neil J. McRae <neil@domino.org>, nanog@lists.nanog.org <nanog@lists.nanog.org>, nanog@lists.nanog.org <nanog@lists.nanog.org> Subject: Re: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? LOL! Come on now, Neil. There is only one truth, and that is what is in the network. It isn’t what you remember, or what you think it is, because those can all be faulty. There is no “your truth“, or “my truth“. There is only “The Truth“. The network configuration may be incorrect, but it is still the true state of things. If we can’t even agree on the basic definition of “what is truth“, how can we have a meaningful discussion? -mel

On Mar 19, 2025, at 10:53 AM, Neil J. McRae via NANOG <nanog@lists.nanog.org> wrote:

The live network _should_ be the truth, but unless you have really nailed config and change management then your truth is what you remember and humans make terrible eye witnesses.

Things might be working, but are your customers getting billing correctly, or the correct service? Or does that failover work? Did you put back in that filter you took out to debug something?

I see a number of orgs doing all they can to prevent/minimise any use of CLI and in my view I think it’s the only direction the network can go in. There is way to much complexity and that is growing and growing and managing the truth in your head as what you remember will one day hurt.

Outside of power I’d guess CLI makes up the vast majority of network outages. In my view it can’t be the future.

Neil.

From: sronan--- via NANOG <nanog@lists.nanog.org> Date: Wednesday, 19 March 2025 at 17:08 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: nanog@lists.nanog.org <nanog@lists.nanog.org>, sronan@ronan-online.com <sronan@ronan-online.com> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? It seems people are confusing “source of truth” with “intended truth”, or maybe people have a different definition of truth than I do.

The network is always the only source of truth as it is what is actually deployed in the network, it is the truth about what is, while I can intend for that truth to be different, that doesn’t change the reality of the situation.

Shane

...

On Mar 19, 2025, at 12:54 PM, borg--- via NANOG <nanog@lists.nanog.org> wrote:

Yeah, you are right here. There is tooling that is able to dump all configs from network devices and compare it to docs and generate reports.

I never had to use something like this, but seems usefull to enforce state of trust from documentation.. If deviation is detected, it have to be fixed right away.. And is even easy to blame who made deviation. You can use 'svn blame' from docs and access log from devices.

In my small team (5 ppl) it was solved by saying: docs is the only source of trust, if you find deviation, docs telling the true. In case of complains, 'svn blame' + logs to the rescue.

---------- Original message ----------

From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Josh Reynolds <joshr@spitwspots.com>, Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:37:30 +0100

...

A *proposed* state or maybe even a snapshot of a particular time is more likely.

Documentation that deviates from reality will get ignored, forgotten and rejected. Treating it as plans and intents will work much better. We probably do that without reflecting over it already. Officially acknowledging it will only improve the process.

-- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"! _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4UUWI6QO...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/N3RZ6WKQ... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EKEW2ODG...

There is one truth but humans are fallable. Hence why CLI isn’t the future. From: Mel Beckman <mel@beckman.org> Date: Wednesday, 19 March 2025 at 19:18 To: Neil J. McRae <neil@domino.org> Cc: nanog@lists.nanog.org <nanog@lists.nanog.org> Subject: Re: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Neil, Sorry, that argument is not persuasive. If there is no one truth, conceptually, we are all doomed. Something can be true, yet incorrectly implemented, at the same time. That’s our job to figure it out and resolve. The Truth, however, has to be the gold standard for The Way Things Are Right Now. -mel beckman On Mar 19, 2025, at 12:01 PM, Neil J. McRae <neil@domino.org> wrote:  Hey Mel :D LOL – Of course there is only one truth – But you’ve just underlined the problem with humans and the CLI; humans have their own perspective of the truth and that interferes with the real truth, no I don’t like to have to say that but to ignore it is folly. Customers not configured on the right service, or during a failure the config gets restored from back up where it isn’t accurate because Freddo configured the upgrade but didn’t put it into some type of inventory… The minute you have humans involved in engaging with the CLI is the minute you lose the truth, are there tasks the CLI can be used for without that risk – of course but for anything to do with configuration humans just can’t be involved via CLI. There are far too many important networks in the world that are still being managed like this and our mission as network operators is to maximise the use of the network and ensure that there is trust in what we are providing then more and more and more applications and cool uses of the network will arrive. Neil. From: Mel Beckman <mel@beckman.org> Date: Wednesday, 19 March 2025 at 18:06 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Neil J. McRae <neil@domino.org>, nanog@lists.nanog.org <nanog@lists.nanog.org>, nanog@lists.nanog.org <nanog@lists.nanog.org> Subject: Re: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? LOL! Come on now, Neil. There is only one truth, and that is what is in the network. It isn’t what you remember, or what you think it is, because those can all be faulty. There is no “your truth“, or “my truth“. There is only “The Truth“. The network configuration may be incorrect, but it is still the true state of things. If we can’t even agree on the basic definition of “what is truth“, how can we have a meaningful discussion? -mel

On Mar 19, 2025, at 10:53 AM, Neil J. McRae via NANOG <nanog@lists.nanog.org> wrote:

The live network _should_ be the truth, but unless you have really nailed config and change management then your truth is what you remember and humans make terrible eye witnesses.

Things might be working, but are your customers getting billing correctly, or the correct service? Or does that failover work? Did you put back in that filter you took out to debug something?

I see a number of orgs doing all they can to prevent/minimise any use of CLI and in my view I think it’s the only direction the network can go in. There is way to much complexity and that is growing and growing and managing the truth in your head as what you remember will one day hurt.

Outside of power I’d guess CLI makes up the vast majority of network outages. In my view it can’t be the future.

Neil.

From: sronan--- via NANOG <nanog@lists.nanog.org> Date: Wednesday, 19 March 2025 at 17:08 To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: nanog@lists.nanog.org <nanog@lists.nanog.org>, sronan@ronan-online.com <sronan@ronan-online.com> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? It seems people are confusing “source of truth” with “intended truth”, or maybe people have a different definition of truth than I do.

The network is always the only source of truth as it is what is actually deployed in the network, it is the truth about what is, while I can intend for that truth to be different, that doesn’t change the reality of the situation.

Shane

...

On Mar 19, 2025, at 12:54 PM, borg--- via NANOG <nanog@lists.nanog.org> wrote:

Yeah, you are right here. There is tooling that is able to dump all configs from network devices and compare it to docs and generate reports.

I never had to use something like this, but seems usefull to enforce state of trust from documentation.. If deviation is detected, it have to be fixed right away.. And is even easy to blame who made deviation. You can use 'svn blame' from docs and access log from devices.

In my small team (5 ppl) it was solved by saying: docs is the only source of trust, if you find deviation, docs telling the true. In case of complains, 'svn blame' + logs to the rescue.

---------- Original message ----------

From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Josh Reynolds <joshr@spitwspots.com>, Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:37:30 +0100

...

A *proposed* state or maybe even a snapshot of a particular time is more likely.

Documentation that deviates from reality will get ignored, forgotten and rejected. Treating it as plans and intents will work much better. We probably do that without reflecting over it already. Officially acknowledging it will only improve the process.

-- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"! _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4UUWI6QO...

---

NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/N3RZ6WKQ... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/EKEW2ODG...

Well, you have to anchor your truth somewhere. Either NOS or docs. So, maybe going slighty out of topic. How you handle cabling? No docs at all? Once a month review to update docs? Same about HW list and status.. etc etc? We keep everything in those docs. I made I choice about our mode of operation and we commited to it. Docs here have dual purpose. Source of truth (or short lived intent) and resource reservation. Once you commit stuff, the port, the IP, the VLAN, etc are allocated to you. When you see: Commited revision X. you are done.. You can go home now worring that I need to implement it ASAP, resources are here to stay. Others can do review, provide comments or even point issues. I know that this is not ideal system, there were tensions about workflow, but thats the job of Tech Lead to smooth it out. For now, I cannot find anything better that will suit that workflow and be true AID to work. Once you commit the changes, you have everything nicely provided to you as a changeset of that revision. Grab this server, install in here, plug it into that port, configure it.. then assign this IP. I work like this for 15 years. The planing phase is nicely decoupled from implementation phase. Once first phase is done, you can relax, because it will aid you with info to do implementation.. ---------- Original message ---------- From: sronan@ronan-online.com To: nanog@lists.nanog.org Cc: borg@uu3.net, nanog@lists.nanog.org Subject: Re: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:07:11 -0400 It seems people are confusing ˙˙source of truth˙˙ with ˙˙intended truth˙˙, or maybe people have a different definition of truth than I do. The network is always the only source of truth as it is what is actually deployed in the network, it is the truth about what is, while I can intend for that truth to be different, that doesn˙˙t change the reality of the situation. Shane

On Mar 19, 2025, at 12:54˙˙PM, borg--- via NANOG <nanog@lists.nanog.org> wrote:

˙˙Yeah, you are right here. There is tooling that is able to dump all configs from network devices and compare it to docs and generate reports.

I never had to use something like this, but seems usefull to enforce state of trust from documentation.. If deviation is detected, it have to be fixed right away.. And is even easy to blame who made deviation. You can use 'svn blame' from docs and access log from devices.

In my small team (5 ppl) it was solved by saying: docs is the only source of trust, if you find deviation, docs telling the true. In case of complains, 'svn blame' + logs to the rescue.

---------- Original message ----------

From: Mns Nilsson via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Josh Reynolds <joshr@spitwspots.com>, Mns Nilsson <mansaxel@besserwisser.org> Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, 19 Mar 2025 13:37:30 +0100

...

A *proposed* state or maybe even a snapshot of a particular time is more likely.

Documentation that deviates from reality will get ignored, forgotten and rejected. Treating it as plans and intents will work much better. We probably do that without reflecting over it already. Officially acknowledging it will only improve the process.

-- M˙˙ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Xerox your lunch and file it under "sex offenders"! _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/4UUWI6QO...

Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, Mar 19, 2025 at 02:22:02PM +0200 Quoting Saku Ytti via NANOG (nanog@lists.nanog.org):

Yes this fits the brown field terribly. But it is actually easy to move to this in a brownfield too.

step1) dump native config to text-file in git step2) this is now your central-state, you edit the text-files and dump them to network upon changes step3) you start to remove lines from text-file as you model them in RDBMS

step3 continues forever, you're never done.

I want your brownfield. You can have mine. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I'm having a MID-WEEK CRISIS!

Måns Nilsson via NANOG wrote on 19/03/2025 12:31:

Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, Mar 19, 2025 at 02:22:02PM +0200 Quoting Saku Ytti via NANOG (nanog@lists.nanog.org):

...

Yes this fits the brown field terribly. But it is actually easy to move to this in a brownfield too.

step1) dump native config to text-file in git step2) this is now your central-state, you edit the text-files and dump them to network upon changes step3) you start to remove lines from text-file as you model them in RDBMS

step3 continues forever, you're never done.

I want your brownfield. You can have mine.

meh, no need to be so pessimistic - step3 can stop at the point that your data model fully understands all the nuances of your network. No problem, right?? Nick

Subject: [NANOG] Re: The Network CLI -- Love it ? Hate it? Needed? Date: Wed, Mar 19, 2025 at 08:36:00AM -0400 Quoting brent saner via NANOG (nanog@lists.nanog.org):

*NIX sysops (not netops) lurker here.

<snip>

Y'all's Tab keycaps must be worn through.

As a rest from things before Unix, we also have something the Unixen don't do, we have a minimum length parser. As seen in amon others OpenVMS. Syntax becomes: $ sh int te 0/0/0/1 tran det (for "show interface TenGigabitEthernet 0/0/0/1 transceiver details") You don't need to tab. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I'm rated PG-34!!

On Wed, Mar 19, 2025, 08:57 brent saner <brent.saner@gmail.com> wrote:

(...) notably the ipeoute2 suite's commands.

s/ipeoute2/iproute2/, of course... whoops

On 2025-03-19 13:08, Matthew Petach wrote:

Hi Mark,

I think you're setting up a false dichotomy here.  :(

<snipping really good stuff I agree with here>

via 'CLI', and never through a 'GUI'--if that helps answer your somewhat false dichotomy.  ^_^;

Thanks!

Matt

Matt, really great stuff here. I like your perspective, your insight, and your workflow. Therefore, I just don't understand how you feel I've asserted any of the positions you've blamed me for. I've purposely left the question open ended (I didn't say what defines a Network CLI, for example), to allow for folks to speak from the heart & share their stories. The true nature of my curiosity is the position of the community, in matters of taste. Best regards, -- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

On 2025-03-21 16:56, Matthew Petach wrote:

In looking at the thread, I will argue (feebly) in my defense that I wasn't the only one falling prey to the "if he's asking about CLI, the counterpoint must be GUI" error.  ^_^;

The thread definitely went in that direction. But it also went in other wild & wonderful directions as well :)

I will also take this moment to second Brian's amazingly sage point that thus far, there doesn't seem to be a non-CLI way of managing devices that works over serial-based communication lines to the physical console of a device; so out of necessity, pretty much every network engineer I've run into is at least familiar enough with the device CLI to get it onto the network enough that they can switch to their favorite GUI/API/management tool. <snipped really good stuff here>

It's very true in a lot of environments. The problem set is a bit fragmented in approach thus far -- in my opinion, at least -- but it's an important situation to consider.

And so, for the third aspect of "Love it/Hate it/Needed?", I would say that some type of CLI-ish access to the device is always going to be necessary in order to configure it with initial network parameters for environments where there is no ZTP-type provisioning system in place (yet).

Yeah, I knew the "needed" part would be the most controversial of the question. But I wouldn't have asked, if I hadn't heard enough folks suggest it's not.

But back to you, Mark--you're absolutely right, I took your neutral question, and brought my own soapbox along to perch on, and in doing so, I attributed to you what was not originally present--and for that, I apologize.  :(

That's alright, Matt. No apology needed. I was just letting you know that we're birds of a feather; finding pragmatic solutions together.

Thanks!

Matt

Thank you for your responses. Best regards, -- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca

On 2025-03-24 15:51, Mike Hammett wrote:

Mikrotik has many UIs: Windows application, CLI, web interface, and API. I prefer the Windows application by a mile. That said, I still use the CLI. I never use the web UI (except for web UI only things like historical resource graphs).

Other devices, I just use the CLI, despite a web UI being available. Other devices, I use the web UI, despite a CLI being available.

It seems to vary based on how in-depth the work I need to do is and what the individual UI is like.

----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

Midwest-IX http://www.midwest-ix.com

That's cool, Mike. I've used the Mikrotik GUI but I haven't dabbled much in the CLI. There might be a day where we migrate our volunteer non-profit WISP from crumbling EdgeOS -> RouterOS. I'd prefer VyOS, if I can find a viable hardware solution (good, cheap, fast... I want all three). Thank you all for your valued responses. I learned a lot and gained a lot of perspective; I would love for a community champion to bring this thread to the NANOG stage. Warm regards, -- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca