Yes, You Need IT Certifications

Certifications are often lambasted as “worthless pieces of paper” and “experience is more important.” But for some people, certifications are more important than experience.

A substitute for experience

Newcomers to the IT world face the classic problem: how do you get experience without a job? Sure, you can tinker around on your own time, but how do you prove that experience? That’s where certifications come in.

Certifications show a prospective employer that you care enough and have the initiative to spend your own time and money to become a better IT professional. You might have tons of experience with IT as a hobby. But how do you prove that?

With a piece of paper.

Certifications get you hired

They are what get your resume looked at, instead of being tossed into the shredder by HR.

They are what get you the interview.

They are the tie-breaker between you and that other equally qualified person who doesn’t have a cert.

If you have a stack of certifications under your belt, you’re going to be a step ahead of the naysayers who think certifications are a joke, a scam, or a racket.

Certifications mean higher pay

My first IT certification was the CompTIA A+ in 2002. That helped me land one very low paying job. During that time, I also got my Microsoft MCSA.

Fast-forward a few years. I got a job at a local technology reseller where I earned my Network+, Cisco CCNA, CCDA, and finally my CCNP, all within a year. Shortly after that, I was able to get a job that almost doubled my salary.

A couple years later, I got my Citrix CCA. My salary went up by 50%. It increased a few percent each year thereafter.

Oh, and I forgot to mention: no college degree.

You’re always a beginner

Even if you’ve been in the field for 20 years, you’re always a beginner when it comes to emerging technologies. You can work your tail off to get experience with the latest and greatest, but if you want to turn that experience into a raise or new position, you have to prove your skills.

When you put in your resume against someone fresh out of college – and they have that highly sought after certification and you don’t – well, you can guess who’s getting the callback.

It’s Time to Stop Using the Term Network Function Virtualization (NFV)

I think it’s time to stop using the term “network function virtualization”. Why? Because it doesn’t exist, at least not in the way the term suggests. The term is a category error, and when people try to make sense of the term, confusion and frustration ensue.

Think of it like this: what’s the difference between a “virtual network function” and a “non-virtual network function”? For example, how is “virtual IP forwarding” different than “non-virtual IP forwarding?” Answer: it’s not.

So what then exactly is network function virtualization?

The Right Idea, The Wrong Term

The European Telecommunications Standards Institute, which arguably coined the term NFV, said the following in a 2012 whitepaper (emphasis mine):

Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers

Look at the bold text. How does one consolidate many network equipment types onto commodity servers? Let’s add some specifics to make it more concrete. How does one consolidate a firewall, router, switch, and load-balancer onto a server? By implementing those network functions in software and putting that software on the server.

But here’s the problem with calling that “network function virtualization”: virtualization has nothing to do with implementing network functions in software. In the early days of the Internet, routers (gateways as they were called back then) ran on commodity x86 machines with no virtualization (with the exception, maybe, of virtual memory).

Network functions don’t need virtualizing, and in fact, can’t be virtualized. But the term NFV suggests otherwise.

And that’s where the confusion started….

NFV is like dividing by zero: undefined

Conceptually, NFV is just implementing network functions in software. That’s easy enough to understand. And yet it’s hard to find an actual definition of it anywhere. Instead, you’ll see a lot of hand-wavy things like this:

NFV is a virtual networking concept…
NFV is a network architecture concept that uses the technologies of IT virtualization…

Hence the letters “N” and “V”. And then you have those who gave up on a definition and just went straight for the marketing lingo:

NFV is the next step…
…is the future…
…is the progression/evolution…

Others get closer by hinting at what NFV does, but stop short of actually saying what it is:

NFV consolidates multiple network functions onto industry standard equipment

This seems to be pretty close, but where’s the virtualization part come in? Let’s try this blurb from Angela Karl at TechGenix:

[NFV lets] service providers and operators… abstract network services, including things such as load balancing, into a software that can run on basic server.

Bingo. NFV is not virtualizaton at all. It’s an abstraction of network functions!

NFV is Abstraction, not Virtualization

Before you accuse me of splitting hairs, let me explain the distinction between virtualization and abstraction. Put simply, virtualization is an imitation, while abstraction is a disguise.

Virtualization is an imitation

When you virtualize something, you’re creating an imitation of the thing you’re virtualizing.

For example, when you create a virtual disk in your favorite hypervisor, you’re hiding the characteristics of the underlying storage (disk geometry, partition info, formatting, interface, etc.). But in the same motion, you give the virtual disk the same types of characteristics: disk geometry, partition info, formatting, interface, and so on. To put it in programming lingo, the properties are the same, but the values are different.

Virtualization preserves the underlying properties and doesn’t add any property that’s not already there. Have you ever pinged a virtual disk? Probably not, because virtual disks, like real disks, don’t have network stacks.

Virtualization also preserves the behavior of the thing being virtualized. That’s why you can “shut down” and “power off” virtual machines and “format” and “repartition” virtual disks.

Now try fitting NFV into this definition of virtualization. How do you “virtually route” or “virtually block” a packet? It’s a category error.

Abstraction is a disguise

When you create an abstraction, you’re creating a disguise. Unlike virtualization, with abstraction you’re changing some of the properties of the thing you’re abstracting. You’re taking something and dressing it up to look and act completely different.

Swap space is a good example of an abstraction. It’s data on storage that looks and acts like random access memory (but way slower). Before the days of SSDs, swap was stored on spinning disks which were read and written sequentially. This is completely different than memory which can be read and written randomly. Swap space is a file (Windows) or partition (Linux) disguised as RAM.

The Case for Abstracting Network Functions

Let’s bring this around to networking. What’s it mean to abstract network functions like IP routing and traffic filtering? More importantly, why would you want to? Why not just use virtual routers, switches, and firewalls?

Simply put, virtualized network devices don’t scale. The reasons for this are too numerous to list here, but suffice it to say that TCP/IP and Ethernet networks have a lot of built-in waste and aren’t the most efficient. This is why cloud providers do network function abstraction to an extreme. It’s utterly necessary. Let’s take Amazon AWS as an example.

In AWS, an instance has a virtual network interface. But what’s that virtual network interface connected to? A virtual switch? Nope. Virtual router? Try again. A virtual firewall. Negative. Virtual routers, switches, and firewalls don’t exist on the AWS platform. So the question remains: what’s that virtual NIC connected to?

The answer: nothing. The word “connected” here is a virtual concept borrowed from the real world. You “connect” NICs to switches. In your favorite hypervisor, you “connect” a vNIC to a vSwitch.

But there are no virtual switches or routers in this cloud. They’ve been abstracted into network functions. AWS presents this as if you’re connecting a virtual interface to a “subnet” rather than a router. That’s because AWS has abstracted IP routing away from you, leaving you with nothing to “connect” to. After all, we’re dealing with data. Not devices. Not even virtual devices. So what happens? The virtual NIC passes its traffic to some software that performs network functions. This software does a number of things:

  • Switching – It looks at the Ethernet frame and checks the destination MAC address. If the frame contains an ARP request seeking the default gateway, it replies.
  • Traffic Filtering – If it’s a unicast for the default gateway, it looks at the IP header and checks the destination against the security group rules, NACLs, and routing rules.
  • Routing – If it needs to forward the packet, it forwards it (although forwarding may simply consist of passing it off to another function.)

This is a massive oversimplification, of course, but you get the idea. There’s no reason to “virtualize” anything here because all you’re doing is manipulating bits!

Overvirtualizing the Network

It’s possible to over-virtualize. To give an analogy, suppose you wanted to write a calculator application (let’s call it a virtual calculator). You’d draw a little box with numbers and operators, and let the user click the buttons to perform a calculation. Now imagine that you also decided to write a “virtual hand” application that virtually pressed buttons on the virtual calculator. That would be ridiculous, but that’s essentially what happens when you connect two virtual network devices together.

There an especially great temptation to do this in the cloud. Folks may spin up virtual firewalls, cluster them together, connect them to virtual load-balancers, IDSes, and whatnot. That’s not bad or technically wrong, but in many cases it’s just unnecessary. All of those network functions can be performed in software, without the additional complexity of virtual NICs connecting to this and that.

The Difference Between a Virtual Network Device and a Network Function

When it comes to the cloud, it’s not always clear what you’re looking at. Here are some questions I ask to figure out whether a thing in the cloud is a virtual device or just a abstracted network function:

Is there an obvious real world analog?

There’s a continuum here. An instance has a clear real world analog: a virtual machine. An Internet gateway sounds awfully like the router your ISP puts at your site, but “connecting” to it is a bit hand-wavy. You don’t get a next-hop IP or interface. Instead, your next hop is igw- followed by some gibberish. That smacks of an abstraction to me.

Can you view the MAC address table or create bogus ARP entries?

If  you can, it’s a virtual device (maybe just a Linux VM). If not, it’s likely some voodoo done in software.

Can you blackhole routes?

In AWS you can create blackhole routes, although people usually do it by accident. You can create a route with an internet gateway as a next hop, then delete the gateway. But can you create a route pointing to null0? If not, you have an abstraction, not a virtual device.

Does the TTL get decremented at each hop?

A TTL in an overlay can get decremented based on the hops in the underlay. But what I’m talking about here is not decrementing the TTL when you normally would. AWS doesn’t decrement the TTL at each hop. If you were to get into a routing loop, you’d have a nasty problem. Hence, AWS doesn’t allow transitive routing through its VPCs. So if your TTLs don’t go down at each hop, as with AWS, you’re probably dealing with an abstraction.

 

You failed your CCNP exam. Now what?

You took one of the Cisco CCNP Routing and Switching certification exams. You went to the exam center, sat down, and started the exam. About 2 hours later, you saw the dreaded news appear on the screen:

You didn’t pass.

I’ve failed certification exams in the past, so I can relate to the facepalm-worthy feeling you get when you realize you dropped a couple of Benjamins on an exam that you just failed. I know the feeling of wanting to give up, the thoughts of thinking that this whole certification thing is stupid, and the desire to assign blame to whomever or whatever led to your failure.

Failing certification exams is a reality of any IT professional. And from what I’ve seen, sadly, not many people handle failure very well. I want to talk through this.

This isn’t meant to be a pep talk or a “you’ll do better next time” motivational speech. Neither is it meant to be an assignment of blame to you or anyone else. Rather it’s a cold, hard look at why you failed, and how you can pass next time.. or the time after that.

Why you failed

I’ve taken a lot of Cisco certification exams and read a lot of Cisco books over the years and I’ve noticed a pattern. Cisco likes to play off of common misconceptions and little known technical facts. Here’s a non-real but representative example:

Two switches are connected via an 802.1Q trunk. You delete the switched virtual interface for VLAN 1 but both switches still exchange CDP messages. What will prevent CDP messages from traversing VLAN 1 without affecting Cisco IP phones?

Select the best answer:

A. Prune VLAN1 from the trunk

B. Disable VLAN1

C. Disable CDP globally

D. Disable CDP on the trunk

E. None of these

If you’ve watched my Pluralsight course series on the CCNP SWITCH exam, you’ll recall that you can’t disable VLAN1 or prune it from a trunk. Well, you can try to prune it, but CDP messages will still pass. But do you disable CDP globally or just on the trunk interface? This is where obscure knowledge comes in. Cisco IP phones use CDP to get voice VLAN information, so disabling CDP globally is out. That leaves only two answers: disable CDP on the trunk interface or none of the above. Disabling CDP on the trunk interfaces will certainly stop the CDP messages from moving between the switches, and it won’t affect Cisco IP phones since CDP messages never leave a collision domain.

Now here’s the thing: I made that question and answer up on the fly. You have to be able to do that if you want to do well on the exam.

The exam blueprint is like The Oracle, and sometimes just as wrong

If you remember The Matrix movies, you’ll remember the Oracle, a computer program that supposedly knows all. After seeing the Oracle for the first time, Neo asks Morpheus how accurate the Oracle’s “prophecies” are. Morpheus responds with something to the effect of, “Try not to think of it in terms of right and wrong. The Oracle is a guide to help you find the path.” Not surprisingly, it turned out the Oracle was kinda wrong on some stuff.

Well, the blueprint is a lot like that. It has stuff that never shows up on any exam. This is mainly because if the exam covered the entire blueprint, it would be 8 hours long. It also leaves off some topics that do appear on the exam. The lesson here is don’t depend on the exam blueprint. Make sure you know the topics for prerequisite and related exams. If you’re taking CCNP SWITCH, make sure you know the topics for ROUTE. If you’re taking TSHOOT, make sure you know ROUTE and SWITCH. Of course, make sure you know all the CCNA R&S topics upside down and backwards.

Each exam blueprint is a guide. It’s a guide to the other exam blueprints.

How to pass next time.. or the time after

If you’ve already taken a CCNP exam, the next time you go in to take the same exam, you’re technically “brain dumping” parts of it. I’m not talking about cheating. I mean you’ve seen the exam already, and you have a feel for what the questions are like. If you’ve got lots of time and money, you can take the same exam over and over again, getting slightly better each time until you pass. I don’t recommend this strategy, not just because it’s expensive, but because it puts you in the super awkward situation of telling others how many times you took the exam. Trying until you pass is respectable, but you should have some serious expertise to show for it. If I’m interviewing you and it took you 5 tries to pass a CCNP exam, I’m going to grill you hard on the technical questions.

If you want to have a great chance of passing the next time, then study for the certification one step higher than the one you want to attain. If you’re studying for the CCNA, act like you’re studying for the CCNP. If you want the CCNP, act like you’re studying for the CCIE. Obviously the topics are different. You don’t need to study multicast in-depth for your CCNP. But for the topics that overlap, it’s better to overshoot than aim for the bare minimum.

New book! Learn Cisco Network Administration in a Month of Lunches

The pre-release of my new book, Learn Cisco Network Administration in a Month of Lunches, is available from Manning Publications’ early access program.

The book is a tutorial designed for beginners who want to learn how to administer Cisco switches and routers. Set aside a portion of your lunch hour every day for a month, and you’ll start learning practical Cisco Network administration skills faster than you ever thought possible.

Pass the First Time: Study Tips for the CCNP Routing and Switching Certification

If you’re studying for or considering the CCNP R&S certification, here are a few things to keep in mind:

The CCNP exams test CCNA-level skills and knowledge, too

This is a good thing, because it helps weed out those who “brain dump” the exams. If you got lucky with OSPF on your CCNA exam, you’re not going to get lucky on the CCNP ROUTE exam. You really DO need to know this stuff. You can’t just pass the CCNA composite exam and then forget everything. You have to have a solid foundation to build on. You’re never too educated to go back and revisit the fundamentals.

Spend most of your time studying configuration and troubleshooting at the command line interface.

There’s no hard and fast rule on this, but a good rule of thumb is make sure AT LEAST 50% of your time is spent in IOS. Both the ROUTE and SWITCH exams have some simulations, but the TSHOOT exam has a LOT. If you’re not proficient with the command line interface, you won’t pass. Again, this weeds out the dumpers, and it raises the difficulty level of attaining the cert.

Write down all your questions in one place and periodically revisit them.

You’ll be amazed at how many questions you will learn the answer to without realizing it. Some questions you’ll look at and think, “Duh, that one’s easy. How did I not know that before?” From my CCIE studies, I have a list of questions that I organized by category: Layer 2, Layer 3, Security, QoS, etc. Writing down questions also reminds you of how much you DON’T know, highlights your misconceptions, and becomes a de-facto study guide. The last thing you want going into the exam is a false sense of security.

The exams cover a LOT of topics, and some of them are pretty in depth.

This is where a lot of people get frustrated, confused, or just overwhelmed. They look at the exam topics, see the magnitude of it all, and try to study and memorize everything about everything.

This is one of the biggest reasons I’m creating a series of CCNP R&S courses for Pluralsight.

The first one, Basic Networking for CCNP Routing and Switching 300-101 ROUTE was released this month. In each course I focus on real-world customer requirements and then demonstrate how to configure them step-by-step, explaining each command as I go. When watching the courses, you’ll quickly get an idea of what areas you need to study more and what areas you already know.

Not only that, each course module includes an assessment which thoroughly tests your knowledge of the relevant exam material. And, if you get an answer wrong, it will take you to the exact spot in the course where I cover that particular topic. It’s an incredibly effective way to study and learn quickly.

Check out the entire CCNP Routing and Switching learning path.