The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
Why Engineers Prefer the CLI
By stretch | Monday, October 25, 2010 at 12:00 a.m. UTC
One of the reasons engineers tend to prefer the command line over graphical interfaces is efficiency. Imagine you have to instruct a junior admin with little networking knowledge at a remote site on configuring NAT on the branch router there. Which of the two following hypothetical emails would you prefer sending?
Log into SDM (you might have to download it from the router first) and go to the configure tab. In the tasks pane on the left side, click NAT. Click "Advanced NAT" and the launch button. Click next, and when it asks to select the ISP-facing interface select FastEthernet0 from the drop-down list. Click next.
The next step should list both interfaces again. Select Vlan1 (192.168.1.0/24) this time and click next.
The last step should say "Specify Public IP Addresses for Servers." We need to add a static NAT rule for the VPN server, so click the "Add" button next to the empty list. Use these values:
- Private IP address: 192.168.1.204
- Public IP address: Select "IP address of FastEthernet0"
- Type of Server: Other
- Original Port: 1194
- Translated Port: 1194
- Protocol: UDP
Then click OK, and click next again (make sure the static rule shows up in the window first). Click "Finish" at the last step. It will pop up another window and should say something like "configuration saved" after a few seconds. Hit OK and close SDM.
Log into the router via Telnet or SSH and paste this config:
configure terminal interface FastEthernet0 ip nat outside ! interface Vlan1 ip nat inside ! ip nat inside source static udp 192.168.1.204 1194 interface FastEthernet0 1194 ip nat inside source list 1 interface FastEthernet0 overload ! access-list 1 permit 192.168.1.0 0.0.0.255 exit copy run start
Hit enter to confirm the last command.
Posted in Configuration Management
October 25, 2010 at 1:46 a.m. UTC
(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.
October 25, 2010 at 2:21 a.m. UTC
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.
October 25, 2010 at 2:24 a.m. UTC
Typo? Ctrl+C, Ctrl+V. :)
October 25, 2010 at 5:09 a.m. UTC
One of the reasons I've enjoyed the Microsoft world rediscovering CLI in the form of powershell.
GUI has its purpose... but rarely.
October 25, 2010 at 7:15 a.m. UTC
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?
October 25, 2010 at 8:19 a.m. UTC
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.
October 25, 2010 at 10:00 a.m. UTC
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
October 25, 2010 at 12:24 p.m. UTC
Sometimes what you'd like to do isn't available through the CLI. For an example of this, take a look at CSD on ASA devices through ASDM. That really isn't practical or possible through CLI. Aside from that, having a junior or less experienced admin setting up some things such as VPNs is easier through a GUI - a lot of the heavy lifting of allowing the right ports and protocols is done behind the scenes by the GUI, leaving the admin to worry about source, destination, and public facing niterfaces. Don't get me wrong; I prefer the CLI in most things, but there really are places where a GUI is a natural fit.
October 25, 2010 at 1:10 p.m. UTC
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 :-)
October 25, 2010 at 1:58 p.m. UTC
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. :)
October 25, 2010 at 2:25 p.m. UTC
The GUI is nice in some cases where the CLI may be cryptic, but I've found that with tools such as clogin (from rancid), its easy to distribute uniform changes and updates across dozens of devices with a high degree of uniformity and precision. In settings where there is a need to help clarify things and fewer devices are being managed, a GUI offers certain advantages. But for larger scale management, CLI tools like clogin are nearly indispensable.
October 25, 2010 at 6:13 p.m. UTC
i personally feel CLI way to configure hardware is better than GUI
October 25, 2010 at 7:37 p.m. UTC
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.
October 25, 2010 at 8:54 p.m. UTC
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.
October 25, 2010 at 10:27 p.m. UTC
Please stop implicitly referring to yourself as an engineer. Why not take it a step further and prefix your name with a "Dr."?
October 25, 2010 at 10:29 p.m. UTC
@P.Eng: Because I'm not a doctor. I am, however, an engineer, as are many of the site's readers. If that upsets you, tough luck.
October 25, 2010 at 10:48 p.m. UTC
@P. Eng: thanks for the useless comment. Many of us on these forums and in this field do "engineer" solutions and complex network designs; hence the engineer title. Isn't there a PE site somewhere you can spend your time on?
October 25, 2010 at 10:54 p.m. UTC
@stretch, @ENGINEER: He's right though. Whether you like it or not.
October 25, 2010 at 11:08 p.m. UTC
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
October 26, 2010 at 2:13 a.m. UTC
We're getting well off-topic from the blog post, but Tom Hollingsworth has a great post regarding engineers and hurt feelings over at The Networking Nerd.
October 26, 2010 at 10:54 a.m. UTC
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.
October 26, 2010 at 1:19 p.m. UTC
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.
October 26, 2010 at 1:32 p.m. UTC
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.
October 26, 2010 at 2:01 p.m. UTC
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.
October 26, 2010 at 4:12 p.m. UTC
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.
October 26, 2010 at 5:27 p.m. UTC
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.
October 26, 2010 at 8:07 p.m. UTC
ethan- very nice! any number of expletives could have preceded p.eng's nickname...
October 27, 2010 at 2:35 a.m. UTC
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.
October 27, 2010 at 7:53 a.m. UTC
Wow Sean, thanks for the very thorough explanation on the Canadian system. I found it quite enlightening.
October 27, 2010 at 11:00 p.m. UTC
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…
October 31, 2010 at 1:33 p.m. UTC
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.
February 7, 2013 at 3:58 p.m. UTC
turn off http and telnet. these are first things to do on a fresh box.
"wr" or "do wr" from config are much faster ways to save config rather then "copy run start".