RE: Network device command line interfaces

[Jonathon Exley <Jonathon.Exley () kordia co nz>]

Yeah, I guess Cisco IOS isn't that good an example of a consistent syntax. Others do it better - Junos sets the ASN 
with the 'routing-options autonomous-system' command, and TiMOS uses 'router autonomous-system'

My rant wasn't about having to deal with new CLIs but about the lack of CLIs in those devices that seem to prefer menu 
based UIs (text or web), and CLIs that have nasty commands. Check this out:

add flow fid-5-5 EVC-30600-Data codefault enable multi swap 99968000 100032000 1024 1024 5000 ctag push 15-0 stag none

Now what does that string of numbers mean? It's the Adva 825 way of specifying the CIR and EIR for a flow but I can 
never remember what each position represents.

Compare this to TiMOS:


        sap-ingress 93 create

            description "Test LNS"

            queue 1 create

                rate 2000

                mbs 25 kilobytes

            exit

This creates a queue with max rate 2000 kbit/s and a max burst size of 25 kB. It's much easier to read than the Adva 
config, because each parameter is labelled.

The Adva CLI isn't actually all that bad, but it's possible that had their developers had some sort of usability guide 
when they wrote the OS then they might have done things better.

I was hoping that there was already some sort of usability guide around that could be shown to the manufacturers with a 
"please read this" note attached. Is anyone aware of such a thing?


Jonathon.


From: Keegan Holley [mailto:keegan.holley () sungard com]
Sent: Friday, 25 November 2011 4:12 p.m.
To: Jonathon Exley
Cc: nanog () nanog org
Subject: Re: Network device command line interfaces

I may have a different opinion here, but I not sure I'd call any CLI easy to work with.  Cisco's training machine is so 
efficient that some learn IOS before leaving high school, so the fact that we all consider IOS easy to work with is 
relative.  Just look at the "router" command.  Most of us know that this is cisco's way of enabling protocols, but I 
would hardly call this intuitive if I didn't know it already.  Then it's different for each protocol. So "router BGP #" 
starts the BGP process and sets your local AS number (very important). "router eigrp #" starts eigrp and sets a 
different AS number that doesn't really count (also important). "router ospf #" just sets a process ID in case you want 
to run multiple instances.  There's also a config mode autonomous-system command but that only counts if your running 
EGP which is still in the CLI but isn't supported and doesn't start.  Then there's all the different things you 
can/must do with access-lists because they were too lazy to code a different sort of filter.  Remember CBAC?  Did I 
mention this is the CLI we like?  I don't mind wrestling with a new CLI because it's all relative.  Most have read at 
least one cisco book and probably one juniper book so those CLI's are considered standard and all their sins are 
forgiven.  Most of us have not gone through, training with extreme, enterasys, 3COM, netgear, foundry, fortigate, etc. 
etc. etc.  So those become the PITA CLI's and suddenly non-standard commands and bad help menus become a crime again.  
I do find text-based menus obnoxious, unless it's a linux box and the text menu is a curses interface.  In that case 
it's super-cool and I'm even willing to play games with text based menus.

2011/11/23 Jonathon Exley <Jonathon.Exley () kordia co nz<mailto:Jonathon.Exley () kordia co nz>>
Does anyone else despair at the CLIs produced by networking vendors?
Real routers use a CLI that is command based, like IOS, TiMOS or Junos. These interfaces work well over low bandwidth 
connections (unlike web interfaces), can work with config backup systems like RANCID, have a (mostly) consistent 
structure and good show commands.
However vendors of low cost routers/switches/muxes seem to take a stab in the dark and produce some really nasty stuff. 
I have a personal hate of text based menus and binary config backup files.
Doe this p*** off anyone else? The business part of the company says "This device is great! It's cheap and does 
everything." However the poor sap who is given the task to make it work has to wrestle with a badly designed user 
interface and illogical syntax.
Maybe the vendors need some sort of best practices guide for what manageability features their kit needs to support to 
make them acceptable to the market. Does anyone know if there is anything along these lines?


Jonathon.


This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not 
be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate 
an information system; and do not give rise to any liability for Kordia(R).

This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not 
be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate 
an information system; and do not give rise to any liability for Kordia(R).