Why Engineers Prefer the CLI

Hi Stretch,

(Disclosure: company I work for has a strong partner that is primarily GUI-based)

Pretty good article, but I think there's a few things that need to be considered:

• While configuring a specific element (or a couple of them, as in the example above) of a single device is indeed more streamlined with a CLI, distributing changes across multiple devices is much easier with a GUI: select devices the change applies to and push "publish" (or something similar to that). Imagine you have to push a global policy such as "add new IP x.x.x.x as a valid managament workstation" to a global network of firewalls. Logging into each one and adding it to an ACL is a LOT more time consuming than just pushing policy out.

• The simplicity of the email being sent may be countered by the debugging to be done if the junior admin makes a typo...

Don't get me wrong, I like CLIs very much, but I wouldn't wish to manage complex/large/distributed security policies, VPNs, NATs, objects, ... with CLIs.

Just saying that there's a proper tool for each job.

Cheers,
Fernando

Actually I disagree with Fernando.

I can deploy large changes with change scripts. I often can't do it quite as easily with a gui.

Also GUI's have a habit of often hiding important parts of security configs (eg, checkpoint where nat options related a specific rule are in a seperate page).

By the time central management through a GUI might really save you time, going the full effort and using central configs pushed from a DB that covers all devices, not one gui for firewalls, one for switches etc. just pays off in droves.

Amen.

One of the reasons I've enjoyed the Microsoft world rediscovering CLI in the form of powershell.

GUI has its purpose... but rarely.

The argument that GUI is better for mass changes makes less sense than using it for simple changes.

Scripts can push changes out to thousands of devices and conditions can be applied based on readings that can be taken real-time from the device.

The GUI might be able to push a new management IP to hundreds of devices, but can it push different management IPs to devices based on the subnet or BGP autonomous system they are in?

I think the comment about a junior admin is perhaps not the best way to argue this. Often a junior admin will come up against problems that he doesn't understand and a GUI generally provides help options and guiding text, both of which are shown in your screenshots. GUIs reduce the learning curve considerably and once an junior admin is familiar with the concepts then he can move to the CLI where necessary.

There is a reason Check Point has sold so much product and it's certainly not down to the firewall kernel.

To be honest I think your configuration in the CLI is inefficient.

Copy it with an extra blank line at the end so you dont even need to hit enter :D

I would send both alternatives and ask the engineer to have a look on both and follow the one that he felt more confident to implement.

Personally with Cisco devices I feel way better using CLI, but to be honest I really like Checkpoint's GUI :-)

I'm finding more and more I'm faster and more efficient at the CLI on the ASAs over ASDM for most tasks. That said, editing ACLs in ASDM is a bit faster although doing it by CLI forces you to be more consistent I find.

Then you also have how incredibly crappy some ASDM releases are...

All in all, I'll take the CLI any day over a GUI any day. :)

If you could batch out commands, then commit after (ala Juniper) then we'd have it pretty good. SDM does what it can with the limited CLI provided (since all it does is unintelligently insert CLI commands anyway). You can do some dumb things from the CLI to disconnect your session in the same ways.

In SDM Express (at least all the versions I've used on the 8xx series), if you choose to bridge your WLAN to your LAN on the initial, SDM will disconnect in the middle of executing commands due to changing the management IP you are connected to from the VLAN1 interface to the newly created BVI1 interface.

If you run SDM from the WAN, and make an edit to your WAN ACL, it does a 'no access-list' and disconnects you immediately, and is unable to commit the following commands. In addition, it uses numbered ACLs instead of named ACLs which you cannot safely modify in-line without renumbering.

I like any device to at least have a text configuration for configuration backup and management (via RANCID, etc). ASDM handles all my needs on my ASA units at least.

I think the question should be reworded, what is the advantage of using SDM instead of CLI, other than the obvious answer.

Jeremy has pointed out the intuitiveness of SDM, is countered by its cumbersomeness.

I raise the following point, would not the use of a GUI and incorporating network-aware intelligence programs as envisioned by SONA and IIIN, devalue the sophistication and efficient use of the CLI upon which the networking professional partly stands upon. Is not simplicity a threat to complexity, not when its countered by cumbersomeness.

Cheers

I think it would be a correct assessment to say that more people would find getting trained as a P. Eng easier than getting certified as a CCIE. Perhaps its an over-simplification, but I raise a valid point.

I believe if the offense lies in equating the characteristics of apt judgement, sharp intelligence and mental dexterity and clarity reputed in CCIE to P. Eng, then I would not be the person to make the correct assessment as I am currently neither.

However listening to trusted members who are CCIEs, I believe the designation "Engineer" does not fall into disrepute if you include CCIEs under that designation, only makes it more valuable.

I hope one day, in the short future, through hardwork and dedication, I will obtain my full CCIE certification.

Kudos to Jeremy, and other Network Engineers. You deserve your title, and I patronize no one.

God bless you all

Dear 'P.Eng'

Cisco Network Engineers are accredited by IET and can apply for and use the designation MIET and receive CEng and PEng accreditations in recognition of skills and experience.

"The IET is one of the world’s leading professional societies for the engineering and technology community, with more than 150,000 members in 127 countries and offices in Europe, North America and Asia-Pacific. The IET provides a global knowledge network to facilitate the exchange of ideas and promote the positive role of science, engineering and technology in the world."

Details on Cisco and IET relationship discussed in detail here: http://etherealmind.com/iet-cisco-engineers/

A prompt apology would be appreciated.

You twat.

EtherealMind.

The row over the use of the term engineer seems to me fraught with more distraction than usefulness. The argument by some that licensing for the title should be required by specialties directly impacting public safety and shouldn't affect the use of the term by IT people does not take into account the history of computing. An incident involving an Xray machine killing people comes to mind, not to mention networks and computer programs controlling nuclear reactors, guided missiles, and some manufacturing facilities. IT people affect public safety directly in some cases in ways relative to their specific areas of expertise.

However, the use of one term to cover so broad an array of specialties is misleading regardless of licensing or other requirements. You wouldn't want an electrical engineer to design a bridge, unless perhaps its a wheatstone bridge. Nor would it be very helpful to ask a windows system administrator how set up BGP with a backbone provider or how to structure OSPF for some number of remotely connected locations. You wouldn't necessarily ask a mechanical engineer or architectural engineer either. Of course anyone in one specialty can learn tasks in another to some extent, but that's not the point.

Each area of specialization can be legitimately seen as a skill set involving very similar types of problem solving skills and challenges than can qualify as engineering from a methodological point of view, as noted by ENGINEER earlier. That's because the general cognitive skills are similar, but the experience in many cases is exclusive.

The term engineer may benefit more from inclusion and growth as technology itself grows and expands than it would from restriction. As pointed out above, engineering organizations are expanding the qualifications of the term to more specialized skill sets, which I think is a good thing.

As usual, I suspect the real answer lies in the middle.

In Canada, at least, the terms "P.Eng.", "Professional Engineer", and to some extent "Engineer", are protected and enforced by a provincial act and have a dedicated body to oversee compliance. To use them, you have to be registered with the provincial engineering body.

To be registered with the provincial body, you have to have an undergraduate engineering degree from an accredited university, pass exams in engineering ethics and law, and spend 2-4 years under the direction of another P.Eng, with your progress monitored by the accreditation body on 6 month intervals.

After that you pay your yearly dues and, depending on the province, have to submit paperwork showing that you're continuing to develop professionally. This is all for the privilege of having a body whose job it is to find members who are not practicing up to standard or violating our code of ethics and then impose sanctions. By contrast, if I were a doctor I would have a similar body, but I would also have a quasi union covering my back.

I could not find any documentation about the IET and any credit that it gives you with your provincial body. I'm not saying it doesn't exist, but given my experience with being a registered P.Eng in Manitoba, I'm going to say it's not as simple as getting your number and then applying for your stamp. I know that people who have honest-to-goodness engineering degrees from the UK and many years of practice have problems when they come to Canada.

In fact, looking at the link you (@etherealmind) cite (http://www.theiet.org/membership/cisco/prof-and-prof-reg.cfm), I don't see anything about a "P.Eng". With a CCIE you can be a "Chartered Engineer (CEng), Incorporate Engineer (IEng) or Engineering Technician (EngTech)."

A few examples to show how seriously the P.Eng trademark is protected in Canada: - The CCPE filed a lawsuit against Microsoft several years back over "Microsoft Certified Systems Engineer". It went back and forth for a while, then the Canadian MCSEs got a letter from Microsoft saying "call yourself an MCSE, not an engineer" - The CCPE took a Halifax school to court over their "Software Engineer" curriculum. - A guy I went to school (and lived across the hall from) with had business cards that said "design engineer" when he was still going through the mentorship phase. He got in a heap of trouble over that, and had to turn over the business cards.

@ip - I haven't got my CCIE, but having got my P.Eng and at least being familiar with the CCIE outline, I'm going to say that the CCIE would be the easier one. That's not to say the CCIE is easy, but hey, there's no calculus :)

While PENG's flippant comment was unnecessary, he's not the twat in this discussion.

I say let's not stop with pissing off one group of professionals, what about all the Network Architects out there who aren't proficient in AutoCAD?!

Regardless of where my lat/long are, I'm an Engineer/Architect and I Engineer and build IP based networks. I don't understand why someone would get so damn butt hurt over professional terminology. If you don't have enough to do, let me know, I'll start you on a CCNA course so you can get some real work going.

It is a title. That is all. Outside of my career title of a VOIP / Data Network Engineer I am also a Paramedic. All titles to describe what I do. Not what I know or who I am. Sorry, but people get too bent about titles.... but that's what makes us human ;) Prove yourself thru actions not names.

Relax and breath.

John

If it's just a title, then PENG's comment is perfectly valid. For that matter, I'll just call myself a CCIE if it's "only a title".

But in some places, "Engineer" is not a title, it's a professional designation. The same way I can't call my self "Dr." or "MD", I can't call myself an "Engineer" in the province of Manitoba, or anywhere else in Canada: http://web2.gov.mb.ca/laws/statutes/ccsm/e120e.php#58

In the United States, the term isn't as heavily regulated, so you can call yourself whatever you want.

Just thinking I'd set up a site dedicated for people like P.Eng. It won't be accessible via the internet unless P.Eng can engineer a way to access it via non- network engineer methods.

Get a clue man, this is 2010.

I don’t want to be an engineer. I want to be an artist. My networks are beautiful. So that’s art, right? Hang on a minute, they sound good too. I must be a network musician.

So in P Eng’s world you can’t use words in the English language to describe yourself without passing some exam and paying your subs to a professional society? Grow up, mate.

Anyway, weren’t we talking about CLI’s or something…

Pip pip

I've always been a true believer in "right tool for the job". CLI and GUI both have places in our IT lives. I think Microsoft caught onto this with the Windows XP/2003 product line and have simply grown this idea ever since. In the Microsoft world, there is very little that cannot be accomplished by either CLI or GUI methods.

For example, when a simple quick change (such as group change, rename) is required in Active Directory, I'm going to use the "Active Directory Users & Computers" MMC tool. If I need to import 50 users into AD, I'm going to use the dsadd or powershell CLI tools.

GUI is great when complex information needs to be presented to a user. I'm not saying CLI is bad at this, GUI is just better due to it's graphics nature. CLI is great when automating, scripting and doing other such things that are nearly impossible with GUI (except maybe with the assistance of AutoIt).

That is a Microsoft world.

In a cisco/vyatta/router world, CLI rules supreme I believe for on main reason: presenting routing configuration firewall rules, etc etc is so deeply ingrained in the culture of network engineers, you'll never change this. And lets face it; CLI does EXACTLY what you tell it to do, with ALL options being available to you. With SO many configuration items available, any GUI would be overly complex and difficult to use.