• 08/17/2016
    7:30 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Q&A: Networking Pioneer Terry Slattery

CCIE #1026 talks about his start in networking, developing CLI, and the promise of SDN.

Terry Slattery is a veritable legend in the networking industry as the first non-Cisco person to earn the CCIE. He's CCIE #1026, second only to Stuart Biggs, who developed the CCIE exam as a Cisco engineer. Slattery took the CCIE written and lab exams while working as a consultant to Cisco, leading a team that developed the Cisco IOS command-line interface. He founded two companies, invented NetMRI, an automated network discovery and change management tool that's still sold today, and is a popular speaker at conferences such as Interop.

During his career, Slattery's had a front-row seat to some of the industry's major milestones. He witnessed the creation of the venerable ping network testing tool, and watched as a couple Unix experts reverse engineered the infamous Morris Worm the day it hit in 1988. He currently works as principal architect at NetCraftsmen. Network Computing recently met with Slattery to learn more about his amazing career journey.

Network Computing: How did you get started in networking?

Terry Slattery: I was working at the US Naval Academy taking care of some computer systems there in the computer-aided design department. We were running PDP-11s, and had just started using Unix. We wanted to facilitate file transfer....You could buy an interface card that ran TCP/IP in the card instead of in the operating system. We started doing TCP/IP networking. This was early 1980s. The way I learned about networking, or about TCP-IP, was by reading the RFCs [IETF Request for Comments]. There were no books, no training. I would print out the RFCs, take them home and read them. There was a group of people also doing networking at Aberdeen Proving Ground, which was then the Ballistic Research Laboratory. They were also running Unix, and developed their own IP gateway based on PDP-11 computers. I got in touch with them and whenever I had a question about what was in an RFC, I could send them an email and get something back. For email, we used Unix-to-Unix to copy. It was a very crude form of file transfer.

Around the mid-1980s, we got a connection to the Internet, which was Arpanet. We wound up with 9.2k modems that were hooked together using a duplexer -- channel bonding two 9.2k modems together to give us a 19.2k circuit -- that's kilobits per second. We were one of the first military organizations on the Internet, following in the footsteps of the Aberdeen Proving Ground folks. The guy who created ping, Mike Muuss, worked at Aberdeen. I happened to be there the evening he created it. He said, "We're going to make a network testing tool tonight." That's my history -- learning how to do initial networking and being around some of the industry giants doing their thing.

NWC: How did you become a CCIE?

TS: I left the Naval Academy, worked at Aberdeen for a couple years then started my own company, Chesapeake Computer Consultants. It became a company that did a lot of Cisco training; it trained about 30,000 network engineers how to use Cisco gear. During that time of getting the company started, I was consulting with Cisco. I talked with some people and they said, "You'll be a good first (CCIE) candidate." I asked, "What do I need to do?" They said, "You need to take the written qualifying test, then a hands-on test, two days in the lab." That's what became the CCIE program…I took the test and became #1026 in August 1993.

NWC: Was it difficult?

TS: Starting in 1990, one of the employees at Cisco asked if I could rewrite the user interface on the Cisco equipment so that it could be ported to network management platforms. The result is the user interface that Cisco gear has today. The same style of interface is used by many companies. Prior to 1990, there was no command-line function, no interactive help function, no command-line editing. A team of three to four people and I rewrote all the commands in the Cisco user interface. Collectively we touched every single command in the Cisco router. That was the basis to be able to pass the test…. Back in those days it was AGS routers, MGS routers, serial interfaces, and routing protocols that Cisco had at the time, which included things like AppleTalk and STUN, an acronym for serial tunneling.

NWC: Was it after you got the CCIE that you founded Netcordia?

TS: Yes. I did some consulting for a while and decided I wanted to build a network management program. It was something I wanted to do at Chesapeake, but it wasn't the right company do that since it was a training company -- too much of a diversion from our core competency. So I started Netcordia in 2000 and started product development in late 2002. It took nine months to put together a product. I had a five-and-half by eight-inch notepad that I brought on a sailing trip I took by myself. During that trip, I faced one of those, "What am I going to do when I grow up?" decision points. I decided I was going to build this and started writing specifications for what the system had to do.

The networking industry has moved forward. We have training, lots of books. It's has become a fundamental function for business operations. It was really interesting seeing the advent of Cisco advertising on TV. Networking had arrived on mainstream television. Now networks are more prevalent; they're in the home. More recently, we're seeing this whole shift in software-defined networking.

NWC: What do you think of SDN?

TS: Scott Shenker gave a talk in which he said we need new abstractions to simplify how we view networking and how we do networking. That just resonated with me. Since 1980 forward, we had these challenging constructs. For every problem, we create a new Band-Aid and stick it over the problem. There are layers of complexity on top of one another…..I see SDN as a way to create new abstractions, new methods of doing networking that aren't premised on destination, IP address space forwarding…. We can now take voice traffic and push it over one path and data traffic over another. With SDN, it's natural instead of being a bolt-on as with regular TCP/IP forwarding protocols. Another big advantage with SDN is it allows the network and the application to communicate with one another.

NWC: So you're pretty excited about SDN?

TS: We need ways that we can more easily test network functionality, like they do in the DevOps world. People building applications are firing up virtual instances of their application and virtual instances of their clients so they can test their changes before they roll them out into production. In the networking world, we don't have that ability. We might have a lab, but it doesn't run production network traffic….We have slow change processes that take hours, weeks to do. Then we try it to see what happens. That's not a good method. We need to get to a place that easier to do what I call NetOps, which is equivalent to what we see in the DevOps world for application and IT development. I see that being all part of SDN and this migration.

NWC: What advice do you have for network engineers?

TS: Start reading about SDN. Go to national conferences whenever you can, take in the sessions of interest to you and expand your horizons. That's the training piece, but don’t overlook the social aspect. It's not about going out and partying, but making contacts in the industry.

It helps when you have a significant problem that you can call up someone and say, "Here's a problem I have, what do you think is a way to solve this?" Expand your horizons and learn about new stuff. Having contacts that you talk with on a regular basis opens your eyes to this sort of thing. Build up those contacts; don’t be afraid of walking up to someone like Russ White or me and introduce yourself. 

Also, learn a bit about scripting. A lot of people are apprehensive about learning about programming. Learn about scripting instead; it might be something like Python. It's not a whole lot different than CLI. Learn about Python and the language that software development people use; learn what the DevOps people use so you can communicate with them and bridge the gap. … Don't become a dinosaur. Learn to adapt; the adaptable survive.

NWC: Any retirement plans?

TS: I tried retiring; it lasted 18 months. That's when I did the boat trip and came up with the idea for NetMRI.


Great perspective

Nice to hear such good historical perspective and recommendations for learning to keep up. I find it amusing that at one time, there was no command line function so CLI was an improvement.