Network device command line interfaces

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

So, the obvious solution is to buy the products of vendors whose CLIs one finds least offensive, is it not?

;>

Jonathon Exley (Jonathon.Exley) writes:

However vendors of low cost routers/switches/muxes

  Hi Jonathon, have you ever tried to work with a Catalyst Express 500 ?
  A good example of a fully functional IOS device, where the vendor went
  out of their way to disable Telnet/SSH, and force one to run CLI
  commands via the a Web UI. You can do everything, but even "vty 0 x"
  and "transport input telnet" won't give access.

seem to take a stab in the dark and produce some really nasty stuff.

  Cisco isn't exactly low cost, but the point here is exactly that:
  take away CLI and tools that make automation easier, so that customers
  will feel compelled to buy the more expensive stuff if they want
  the fancy stuff (which, in this case, is actually LESS fancy).

  It's not incompetence, it's called crippleware, and it's a business
  model :slight_smile:

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?

  Yes, don't buy the cheap stuff :slight_smile:

  Phil

If only it were that simple.

Try explaining the difference between the blinky lights on a 3750 and the
netgear switch to a CFO who has little tech background.

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.

Not necessarily it has to be cheap to have text based menus and binary
config backups, it can be damn expensive... mmmm remember Alcatel PSAX even
their old PABX series..

In our recent encounters with real cheap stuff (switches m routers) the CLI
is so much friendly :).

Regards,

Aftab A. Siddiqui

Does anyone else despair at the CLIs produced by networking vendors?

Yes.

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.

Use whatever scaremongering tactics and other necessary creativity to
enact a security policy that requires RANCID and anything else you need.
Then only purchase equipment that meets said policy. Or just live with
it and write perl to get through the worst.

Disabling the web UIs completely is not out of the question, then the
CLI has to work. Using a web UI without a proper SSL cert is obviously
horribly insecure and completely out of the question. SSH has a
different model so it is ok.

(just spent a morning diffing Fortigate configs. Love their abominable
configs that are not really much more useful than a binary blob. Even
the interface ordering in the config seems to be random between
devices...)

Yes, don't buy the cheap stuff :slight_smile:

Until we do, the other stuff remains expensive.

mike

That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with".
I don't really believe that manufacturers make crippleware user interfaces for thier products to encourage people to buy a more expensive range. I am more inclined to think that the software developers didn't have a good requirements spec to work from and made it up off thier own back.
With the wealth of experience of people using these devices in this forum, maybe we could collate some good advice on what features of a UI are really important.
Hopefully there are some manufactures listening who can take the advice on board for the next product they develop.

Jonathon

That's where you get a chance to impress the business folks by using
terms like "total cost of ownership." You make the case that while
product X may have a higher capex, that's a one-time expense that can be
amortized and/or depreciated. Whereas the opex for product Y is going to
be higher for the life of the thing. Make sure to tart up your estimate
by including the developer costs of the tools you will need to verify
that changes are correct and/or disaster recovery because everyone is
human, and the horrible UI magnifies the likelihood of an "innocent"
fat-finger mistake turning into a complete meltdown (or worse, a
security hole that no one sees until it's too late).

Of course I'm just throwing stuff against the wall here since I don't
know exactly what tools you're talking about, but if your PHBs have any
clue at all they will understand your point if you can put it into their
language. Look at it this way. Think of how hard you have to fight the
urge to wince in pain when one of your PHBs start describing the wonders
of some new technological marvel ... "We simply must have this new
widget I read about in AAdvantage magazine." That's exactly how they
feel most of the time when we try to talk to them about why product Y is
"better" even though it's more expensive.

hth,

Doug

Doug Barton <dougb@dougbarton.us> writes:

That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with".

That's where you get a chance to impress the business folks by using
terms like "total cost of ownership." You make the case that while
product X may have a higher capex, that's a one-time expense that can be
amortized and/or depreciated. Whereas the opex for product Y is going to
be higher for the life of the thing. Make sure to tart up your estimate
by including the developer costs of the tools you will need to verify
that changes are correct and/or disaster recovery because everyone is
human, and the horrible UI magnifies the likelihood of an "innocent"
fat-finger mistake turning into a complete meltdown (or worse, a
security hole that no one sees until it's too late).

What Doug said. Also, don't forget the value of letting the decision
makers know the worst-case. It's not really FUD if you're just
opening their eyes to the consequences of their buying decisions. For
instance, if you can't back the config of the device up in a
human-readable/mergeable format (or worse yet, can't back it up _at
all_), consider the cost per hour of downtime on a 24 port switch with
a bunch of random office workers connected whose fully loaded hourly
cost (including cost of office space, health insurance, employer part
of FICA, etc) is, um, let's be cheap and say $40/hour. Funny how this
puts the cost of both CLI-based stuff *and on-site spares* in
perspective.

"We can't buy it if I can't back it up with RANCID because of the
negative impact it has on our business continuity" is a good way to
put this into terms that the folks who hold the purse strings can
understand.

-r

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.

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.

That's kinda what I was talking about. That command isn't that bad actually. MQC and juniper firewall filters (in set mode) are no simpler. The annoying part is the obscurity.

Jonathon Exley <Jonathon.Exley@kordia.co.nz> wrote;

That's the problem - as a propellorhead I don't make the purchasing decisi
ons. I can recommend products but low cost speaks more loudly than "this g
ear is a dog to work with".
I don't really believe that manufacturers make crippleware user interfaces
for thier products to encourage people to buy a more expensive range. I a
m more inclined to think that the software developers didn't have a good r
eq uirements spec to work from and made it up off thier own back.
With the wealth of experience of people using these devices in this forum,
maybe we could collate some good advice on what features of a UI are real
ly important.
Hopefully there are some manufactures listening who can take the advice on
board for the next product they develop.

The trick to deailing with this as a propellorhead[sic] is to include a
*monetized* estimate of the increased manpower OPEX of using the 'dog to
work with' box. And a TCOS figure over the projected lifetime of the
units. No need to 'fight' with management about it, just understand
'how' they make the decisions, and give them the informatin they need
to make the decision come out 'your way'.

Aside -- on your other point, there are *many* _documented_ cases of
manufactuers deliberately crippling certain features so as to not
cannibalize the sales of higher-riced units.

IBM was medium-notorious for this. The original IBM-PC keyboard had 'non-
standard' positioning for several keys (the extra key between 'z' and 'left
shift', the location of 'caps lock', and the bastardized shape/position of
'enter') -- *expressly* to discourage using a PC in place of a dedicated
higher-priced IBM 'word processor' (the Displaaywriter ??). Also, the PCjr
used the _same_ floppy-controller chip as it's big brothers, *BUT* the
interrupt line was not connected, and _extra_ hardware had to be included
in the to compensate for the failure to use the interrupt. This was done
exprerssly to cripple performance -- so it was useful only for hobby/game
use, and not for any 'real' work (i.e. couldn't do serial I/O _while_ any
floppy I/O was in prgress. To do file transfers, it took custom code
that would 'suspend' the serial port operation while reading/writing the
floppy, and then 'resume' it after the floppy operation was complete.
There is absolutely no doubt that this was a deliberate 'crippleware' design,
given that they had to -add- extra hardware, vs doing it the 'compatible'
way. Yup, they deliberately spent extra money to make it 'incompatible'.

I'd say that the ethical thing to do is to give them the information they
need to make a decision, not to get it your way. I see, for instance,
people buying local closet switches from brand A when brand B is much, much
cheaper (but lacks the prestige of brand A), had a perfectly workable
management interface, and will perform identically, with similar support
offered by both vendors. But they are an ACNA or whatever, or they've just
heard of (insert brand here), so they buy it. Because it's easy and
familiar.

It's also possible that a web managed switch (which I despise) might
actually be the right choice for a business - because factors other than a
technologist's distaste might be important.

Part of being ethical (and NOT like the business people we might all
despise!) is to be honest. So we don't compare brand A to brand B
unfairly. We don't inflate the cost of brand B by adding brand B's
management infrastructure to the cost when we darn well know we just will
need a minor tweak to our scripts that can already manage brand A. That
sort of thing.

I generally agree with what Robert said: It's about what makes sense to the
business. If operating expenses will increase ("Well have to grow
headcount by 3 to support this"), then bring that up. A caution though:
"Takes less effort to run" doesn't equate to dollars (the question a former
manager would ask me when I tried that line was, "So who do you think we
should lay off then to get the dollar savings?" Fortunately he was a good
manager who wasn't serious, but was rather trying to get me to think about
what I'm saying). I like paychecks, which is why I work for a living -
it's about the dollars. So it's not unreasonable for my management to also
care about the money (since it's a key motivation for myself, after all!).
Yes, I'm fortunate to do a job I love and get paid for it at the same time.

I can say, for a CUI interface, operations over low-speed links (wireless
VPN when I'm away from the office and in a bad cell zone, for instance) is
likely important. So is ability to script common tasks to allow people
like the help desk to do their jobs at low risk. Flexibility is also
important - when I'm stuck with this piece of gear (which is shiny today)
in 5-7 years, when it's not so shiny, is it going to have flexibility to
last a bit longer if the business needs to conserve cash - or will a minor
change in how we do business make this thing functionally obsolete?

Relating to the discussion on the tier 1 mentor thread, someone who wants
to go far in networking won't be married to a particular vendor or way of
doing things. They'll excel and find ways to overcome challenges,
including less than perfect equipment, that they might have to deal with.
They'll do so in a way that makes the customer and their own management
happy. A highly paid network engineer who complains about work being
difficult probably won't do that. One that finds a $500 replacement for a
$5000 router probably will stick around, provided they can actually deliver
what they promised (the guy that puts the $500 replacement in only to have
to replace it in a year with a $5000 router again won't go far, so be
careful! And you better have figured in the real costs of running a network
with $500 routers, not just the cost of the router).

What this really comes down to, I think, is figuring out how your "gut level" concerns fit into the big picture, and to then put that into terms that the people responsible for the big picture can use to make a good decision.

Finances do matter. Getting your employer to spend money it doesn't have to on network equipment generally means there's less money available to spend on other things that might matter, like making your network bigger, hiring people to help you, or even keeping you employed. If you want to spend more on equipment than the bare minimum, you ought to have a reason. To get anybody else to come to the same conclusion, you ought to be able to explain that reason.

That said, I think it's valid to buy something because you're comfortable with it, and valid to not buy something because you're not comfortable with it. "I don't want to buy new device X because I don't want to have to learn how to use it" sounds lazy, but most of us are busy, and if the device you're comfortable with will do the job for an affordable price, it's generally good not to create extra work for yourself.

Saying "we shouldn't do that because I don't know how" is hard. It may be because something is new and complicated, and nobody has experience with it. Or it may be because you're not familiar with it when lots of other people are. You may have a different specialty, or it may be because you're less experienced than the people they could have hired if they'd paid or shopped around more. But, your expertise or lack thereof is a legitimate thing to take into account when making decisions, as is the likely expertise of people who will have to manage the system in the future.

Unfamiliar network equipment is expensive to manage, whether the CLI is well done or not. Even in a one person shop, you won't yet have encountered the device's pitfalls -- its easily circumventable bugs, the configurations that seem intuitive but aren't, etc. It's going to take you longer to design and configure your networks, and you're going to create problems by doing the wrong thing more often. You're probably going cause some outages, or even buy equipment and then find that you missed something and need to buy something else. If you work with a large team, and maybe even have NOC people working the night shift in another location supporting the thing, it gets worse. All those people have to be trained on the new device, and come up to speed on it.

It's also good to understand the reliability requirements for something you're building. We don't have licensing requirements for Network Engineers, but some other more established engineering professions do. If a structural engineer signs off on a building despite being unfamiliar with some aspect of the construction technology and the building collapses, that can be career ending.

Internet networks that have become pretty important too. If you're building a network where a failure will cause a heart attack victim to not be able to call 911 from their VOIP phone, it isn't good enough to say "I've never seen this piece of equipment but I don't have any reason to think it won't work." If you're building a network to connect some office PCs, the stakes are probably lower.

And, of course, there's also the option of learning about unfamiliar technology. Play with it in your lab. Put it in a peripheral site that can fail without causing too many problems. Get your NOC staff familiar with it. And maybe, in the end, you'll find that you actually like it. That it does something your old hardware doesn't. That cheap hardware lets you afford a level of redundancy, and thus reliability, that was simply unaffordable with you're previously preferred equipment.

But that testing and familiarity has a cost, just as buying expensive equipment does, and just as running unfamiliar equipment does. It's a matter of balancing it all out, and coming to an agreement with your management on what the best strategy is.

-Steve

One of the biggest benefits to a CLI is the ability to easily script tasks.
In a Cisco environment I can roll out major changes to hundreds of
switches in seconds, for example.

A lot of network vendors have been trying to make network devices more
simple and easier to use while the complexity of networking has gone up.
Seems like the wrong direction to me. If someone wants a managed switch,
they probably intend to manage it.

I think a big key to the success of Cisco (and Juniper, etc) has been that
they "get it" in this respect.

Even companies like Vyatta have invested time in a Web UI rather than
expanding the core functionality offered (multicast routing support, for
example), which doesn't seem like the best idea.

And that's all there is to be said about that. Nicely played, Ray.

Cheers,
-- jra

Well said. I write scripts all day long to perform automation on networking
equipment. A device needs to have a CLI, but if you have a GUI too make for
darn sure that I can access all features in either one.

If you've done a proper CLI, you can easily do a good REST API. If you've done that a good Web GUI is possible.

It doesn't work the other way round.