On the evening of December 3rd, the Twitterverse, IRC, and other geek outlets pretty much exploded with news of the version 5 update to the Routing and Switching track of the Cisco Certified Internetwork Expert program, or CCIEv5.

There have been some significant changes in the exam material blueprints, as well as changes in format and underlying technology in the lab exam. Overall, I think the change looks very positive at this point, but I have some thoughts on each of these changes that I’ll share here.

Format Changes

Apparently little will change in delivery of the written exam, except that for the first time the CCIE R&S written exam will not be exam 350-001, but rather 400-101. Nothing major here.

The lab, however has some bigger changes coming. This graphic from Cisco’s “What’s Changing” document (link below) shows that there will be a brand new section added to the lab, and in addition some time flexibility has been added:

source: http://bit.ly/1bggAO4

The Troubleshooting section will remain largely the same as it has been. The main difference is that you can “borrow” time from the config section, up to 30 minutes, to keep working on TS. You’ve always been able to go the other way — those few people who finish TS early and with confidence have already been allowed to move on to Config and get some additional, precious minutes. I’m glad Cisco kept the TS section. I think rapid troubleshooting is a hallmark skill of CCIEs, and the pressure in this section is truly intense, forcing you to be incredibly focused and skillful in the act of troubleshooting. I actually enjoyed the large TS labs quite a bit. I think the time flexibility option certainly could be helpful for candidates. Since failing any one section means failing the lab, I can see the appeal of being able to take just a couple extra minutes to finish a ticket that you know you would fail the section without. On one of my attempts I had a real buzzer-beater, literally examining and answering a ticket in the 30 second countdown to the section automatically ending and shutting me out. While I think candidates would be wise not to give up too much time from the Config section, I know in that case I’d have been grateful for 3 extra minutes to verify that solution and make sure that no errant logging or other script-tripping mistakes had been left enabled.

New to the v5 lab is the Diagnostic section. Cisco’s documentation states that this module is exactly 30 minutes, and will serve to test candidates on their ability to diagnose issues outside of the constraints of the troubleshooting section, but using limited diagnostic information. Candidates will be expected to identify where an issue is located by selecting a device on a diagram, or answering a multiple choice question. This sounds to me like prime written-exam material, so why include it in the lab? After discussing with some contacts on Twitter and in IRC, I agree with the idea that this module takes the place of the Open Ended Questions (OEQs) in the initial incarnation of the v4 exam. Like the OEQ, this section is short, but has high value (failing this section will still cause you to fail the overall exam). There is no interactive device access necessary in this section; instead candidates will be reading emails, ticket updates, examining diagrams, or even analyzing packet captures to diagnose an issue. The key here is that because it has no device dependency, the potential question pool can be enormous. With a large question pool, probably constantly-changing content, and high value riding on the section, I am convinced this is for the same purpose as the OEQs were: To guard against cheating. Unfortunately, cheating is a fact of life in IT certification exams, even the CCIE lab. The OEQ section was meant as a means to foil cheaters, however it was universally criticized as being too subjective due to the open-ended questions and the fact that they were hand-graded by the proctors. Cisco alludes to the contrast of the Diagnostic section in one of their documents, which furthers my belief that this section takes the place of the OEQs:

Tickets will not require candidates to write anything in order to provide the answer to a ticket. All tickets will be close- ended (as opposed to open-ended) so that the grading will be deterministic, ensuring a fair and consistent scoring.

Cisco has gained experience with difficult, multichoice questions based on a variety of pieces of evidence through the more advanced CCNP-level exams and even the CCDE qualifying and practical exams, so they should have this down pretty well.

The configuration module will be a bit shorter (contributing time to the Diagnostic section) and could be further shortened by time borrowed to complete the TS section, so I suspect the pace may be even crazier than in the past. The big change in this section is that all equipment will be virtual (almost certainly using the same IOU/L2IOU virtual devices as the TS section has been for the entire lifetime of the v4 exam). This necessitates some content changes that I will discuss shortly, but it will reduce Cisco’s cost in operating the labs, could enable many more lab pods to be available, and be available in more places (imagine mobile labs that would only need a couple monster servers with them, rather than shaky connections back to racks in San Jose), and will also allow the topology to be much larger than is practical with physical equipment. Moving to virtual hardware also supports Cisco’s focus on protocols and configuration, rather than hardware-specific nuance in the CCIE lab exam.

While I understand there are many benefits to virtualizing the lab hardware (just as there are in virtualizing many other IT infrastructures), I do feel it takes away a bit from a CCIE’s prep to be totally ignorant of the hardware on which IOS runs. Certainly in “the real world” understanding the various behaviors, benefits, and detriments of certain hardware components is paramount to being an expert. Early in the CCIE program, candidates had to physically build their network and even troubleshoot faulty cables and modules, just like we do in the real world.

Blueprint Topics

I think one could do a good job summing up the blueprint changes with the phrase “out with the old [and unused], in with the new.” Notable new topics to the written and lab blueprints include (I am paraphrasing and grouping some of these):

• Troubleshooting Methodologies
• ISIS routing protocol
• Basic DMVPN (single hub), GET VPN, IPSec VPN
• Chassis virtualization and aggregation technologies — possible references to CSR, VRF-Lite, and/or VSS/Stacking?
• Basic L2VPN
• BFD
• Interpreting packet captures

And Cisco has seen fit to remove some lesser-used or outdated features. Most of these eliminations are a good thing, in my opinion. These bullet points come from Cisco’s published documents, with my own commentary included in italics.

• Flexlink, ISL, Layer 2 Protocol Tunneling — Flexlinks and ISL are good targets to remove. L2PT goes with QinQ, but I’m pretty sure QinQ isn’t supported in L2IOU
• Frame-Relay (LFI, FR Traffic Shaping) — Good riddance!
• WCCP — A candidate was never able to verify this in the lab anyway (and product support is limited, it’s not heavily used these days, etc.)
• IOS Firewall and IPS — ZBFW has lots of restrictions (NVI, etc). CBAC is pretty common, but more appropriate for the Security track. Almost no one (I know) does IOS IPS (and again, impossible to verify in the lab)
• RITE, RMON — These are not core CCIE-level competencies in my opinion. Look these up when you need them
• RGMP — Router/port group management protocol?! I passed CCIE v4 and I’ve never even heard of this!
• RSVP QoS, WRR/SRR — RSVP is not often used outside SP topics (e.g., MPLS TE), but forcing a candidate to understand switch QOS was important. The virtual switching image of L2IOU can’t emulate the ASICs for hardware QOS, so dropping this was necessary for the virtual Config section. Model-specific QOS knowledge in switches is also usually very perishable info as models evolve, but all the same understanding how switches do queueing, marking, and other QOS is important for high-end network engineers to understand, in my opinion.

Overall Content Changes

Overall, Cisco appears to be moving more fringe topics over to written and adding modern, mainstream hands-on topics to lab. This is a good move, focusing lab candidates on the stuff that a routing and switching CCIE really does need to be able to do backwards and forwards. There also seems to be more focus on troubleshooting methodology as referenced in the Diagnostic module and the v5 blueprint. The v4 exam didn’t focus much on methodology or process, just results.

Further, I think collapsing IPv4, IPv6, and IP multicast all into the layer 3 topic is a good thing, after all, they are all layer 3 technologies — intermingling v6 is also important as we will increasingly see v6 intermingled in real-world configurations. Reviewing the topic breakdown from the v4 lab and the v5 lab shows consolidation and simplification of the topics:

CCIE v4.0 Lab Topic Breakdown – source: http://bit.ly/1g58YWG

CCIE v5.0 Lab Topic Breakdown – source: http://bit.ly/1bggAO4

Overall, I feel this is a better mix. It seems to focus more on routing/switching/connectivity rather than the “Routing and Services” model of v4. Some may think the VPN technologies belong on the Security track, but it seems clear from the blueprint that these are basic VPN technologies focused around establishing connectivity across untrusted public or semi-public infrastructure, rather than deep security-related configurations. Using router-based VPNs to connect sites is something that frequently falls to a “routing and switching” engineer, not a security specialist, so I think these are appropriate additions to reflect real-world expectations of an R&S CCIE.

The services that remained in the v5 blueprint are features that are really used regularly in enterprise networks: NTP, DHCP, NAT, FHRP, NetFlow, IP SLA — not obscure features like core dump uploads, RMON, RITE, etc. Hopefully other legacy topics like IOS menus, IRDP, DRP, and other legacy baggage will also be dropped. It’s not that any of those services features was fundamentally difficult to learn, but my feeling when studying them was that most of them didn’t have much modern-day real-world applicability, yet I was stuck learning those rather than something more relevant to today’s networks like DMVPN or even something like ScanSafe integration. While I was preparing for the v4 lab, I referred to those topics as “lab parlor tricks.”

Conclusion and Links

From what Cisco has made public so far, I think the changes for the CCIE v5 exam look very positive. They refresh the certification, focus on currently-deployed technologies, and relegate old relics to their place in history. The continuing separation of CCIE skills from specific hardware platforms plays well into the industry trend of NFV and virtual networking appliances, but of course an open question is whether even a v5 CCIE will remain relevant in the New World Order of SDN, OpenFlow, whitebox switches, and the like.

At times like these candidates often get worried about which version to try for. At the end of the day, the delta between v4 and v5 is not immense and most of the study done for v4 is entirely applicable to v5. The topic changes, though, seem to me to be better aligned with the current demands of a senior network engineer who would be pursuing the CCIE and if it were my decision I might well hold out to take v5 so that I could be spending my time studying more of the modern relevant topics and not wasting a ton of brain capacity of some of the features I’m unlikely to see outside of the lab anymore.

Cisco’s documentation lists June 3, 2014 last date of v4 lab exam, providing the same 6 months notice of the change as they always have.

Further links for more information on CCIE V5

https://learningnetwork.cisco.com/docs/DOC-22703

http://www.cisco.com/web/learning/certifications/expert/ccie_rs/docs/ccieRS_examUpdates4-5.pdf

Click to access ccieRS_Lab5.pdf

Additonal Commentary I’ve Found Around the Blogosphere

Analysis from Internetwork Expert’s team: http://blog.ine.com/2013/12/03/ccie-rs-version-5-updates-now-official/

Daniel Dibs’ In-Depth Analysis: http://lostintransit.se/2013/12/04/ccie-rs-v5-my-thoughts/

Tom Hollingsworth’s Take: http://networkingnerd.net/2013/12/05/ccie-version-5-out-with-the-old/

Calming Words for Candidates from IPExpert’s Marko Milivojevic: http://blog.ipexpert.com/2013/12/05/ccie-rs-lab-version-5-don’t-panic