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. On Wed, Nov 23, 2011 at 8:51 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:

On Nov 24, 2011, at 11:41 AM, Jonathon Exley wrote:

...

I have a personal hate of text based menus and binary config backup files.

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

;>

----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

The basis of optimism is sheer terror.

-- Oscar Wilde

-- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

On 11/24/2011 11:58, Jonathon Exley wrote:

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). 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 -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/

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

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 On Nov 25, 2011, at 8:15 AM, Joel Maslak wrote:

On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi <bonomi@mail.r-bonomi.com>wrote:

...

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

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

Yes, don't buy the cheap stuff :)

Until we do, the other stuff remains expensive. mike On Wed, Nov 23, 2011 at 8:53 PM, Phil Regnauld <regnauld@nsrc.org> wrote:

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

...

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

       Phil

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

On Mon, Nov 28, 2011 at 1:25 PM, Ray Soucy <rps@maine.edu> wrote:

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.

On Wed, Nov 23, 2011 at 11:41 PM, Jonathon Exley < Jonathon.Exley@kordia.co.nz> wrote:

...

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

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

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.

Ray Soucy <rps@maine.edu> wrote:

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.

On Wed, Nov 23, 2011 at 11:41 PM, Jonathon Exley < Jonathon.Exley@kordia.co.nz> wrote:

...

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

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

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. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Would love to a good open source TR69 interface. On Mon, Nov 28, 2011 at 3:35 PM, Ray Soucy <rps@maine.edu> wrote:

...

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.

This.

I would love a good REST API for everything; I would almost be willing to give up the CLI for it (almost).

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/