This past Monday I passed the CCIE Data Center Lab Exam in San Jose CA, making me four time Cisco Certified Internetwork Expert (CCIE) #8593 in Routing & Switching, Service Provider, Security, and Data Center, as well as Cisco Certified Design Expert (CCDE) #20130013.  This was my first - and thankfully last - attempt at the DC lab exam, and also my first experience in the San Jose CCIE Lab location.  In this post I’m going to outline my preparation process for CCIE Data Center, as well as to talk about my experience with the actual day of the lab.


The Initial Commitment

When the new CCIE Data Center track was first announced last year, it was a no-brainer that I was going to pursue it.  As I already had 15+ years of experience in Enterprise networking, with a large focus on campus LAN switching, IGP and BGP routing, plus some minor exposure to the Nexus platforms, I thought it would be a cinch.  After all, Nexus is just a fancy Catalyst 6500, right? The major hurdle for the track however was not the technologies, but procuring the equipment.  After debating back and forth for quite a while, Brian Dennis and I decided that INE would hold off on the company Ferraris, and instead invest in the equipment for CCIE Data Center.  One of our deciding factors to invest in the track was the sheer volume of customers at our CCIE Candidate Party at Cisco Live 2012 that kept asking us all night long, “when are you guys going to do Nexus training!”  As they say, ask and you shall receive… or was it if you build it, they will come?

Coincidentally, our initial build plans for DC started in early July 2012, which makes it almost one year to the day from when we committed to the track until when I finally had a chance to take the lab exam.

Originally I had planned to try to get the very first available slot for the DC lab exam, but as always life happened and a few things got in the way, such as the birth of my daughter, as well as a short pit stop along the way to pick up the Cisco Certified Design Expert (CCDE). Anyways, onto my preparation…

Once our equipment build was finalized, which by the way was the most grueling and complicated build of my 15+ year career, Mark Snow and I decided to implement a divide and conquer approach to the blueprint, where we would split the Nexus topics, I would take Storage, he would take Unified Computing System (UCS), and then we’d come back and meet in the middle.  Nexus I assumed would be simple, since I had some experience using it as a basic 10GigE aggregation switch, but none of the advanced DC specific topics (e.g. vPC, FabricPath, OTV, FCoE, etc.)  In hindsight, yes Nexus is just a glorified Cat6k, however there are caveats, caveats, and more caveats galore.  Did I mention Nexus has a lot of caveats?

Recommended Reading or: How I Learned to Stop Worrying and Love the Documentation

Since a lot of the DC specific technologies are so new, there’s not many traditional books that are out there that can help you, unlike something like OSPF that is over 20 years old.  With Nexus the topics are so cutting edge, the NX-OS software team is literally pushing out hotfixes and new features as we speak.  Therefore the only main resource that is available for reading about a lot of these technologies is the Cisco Documentation.  I can already hear the collective groan from the audience about reading the documentation, but I can’t stress this enough, you must read the Nexus documentation if you are serious about these technologies and about passing the CCIE DC Lab Exam.

To give you an idea, this is what my Chrome bookmarks toolbar still looks like today.


Personally the way I did this was to download every single configuration guide for Nexus 7K, 5K, and 2K in PDF format, and then load them on my iPad.  Starting with Nexus 7K I worked from basic system administration up to interfaces, layer 2 switching, layer 3 routing, SAN switching, etc.  Don’t count on having access to the PDF versions of the documentation in the actual lab exam, but for preparation purposes these are much more convenient than clicking through every section of the documentation in HTML format.

Each configuration guide can be downloaded as a single complete PDF.


Note that for MDS you don’t need to read through as much, since the SAN switching syntax is essentially the same between the Nexus 7K, 5K, and MDS, as they all run NX-OS.  The sections of MDS documentation that I did read end-to-end however are the Cisco MDS 9000 Family NX-OS Interfaces Configuration Guide and the Cisco MDS 9000 Family NX-OS IP Services Configuration Guide.  Both of these sections are key, as some topics such as FC Trunking and Port Channeling work differently in MDS than they do in Nexus, and then the IP Storage features such as FCIP and iSCSI are unique to MDS and are not supported in Nexus.

Another key point about the documentation for Data Center, just like for other CCIE tracks and other technologies in general, is that once you know how to use the documentation and where things are located you don’t need to worry about the default values for features, or other inane details about syntax.  For example there was a discussion recently on the CCIE DC Facebook group about how to create a mnemonic device (e.g. All People Seem To Need Data Processing / Please Do Not Throw Sausage Pizza Away) in order to remember in which features higher values are better and in which features lower values are better, e.g. LACP system-priority, vPC role priority, FabricPath root tree priority, etc.  I responded, who cares?  Why waste time remembering default values that likely will change between versions anyways?  Instead, your time would be better spent making sure that you know the manual navigation path for all features that you will be tested on in the exam.

Lower is higher and higher is lower… makes perfect sense, right?


Another point to consider is that in the actual Lab Exam, access to the documentation web pages is not very fast.  I’m assuming this is due to the strict content filtering that all the pages have to go through before they show up on your desktop.  Regardless as to the reason, if you need to use the documentation in the exam and you don’t already know exactly where the page you want is located, you’re gonna have a bad time.

Additionally, don’t limit your reading of the documentation to just the configuration guides.  There are a number of other very useful portions of the documentation that you should read – again, end-to-end, there are no shortcuts here – such as the white papers, design guides, and troubleshooting guides.

The Nexus 7000 White Papers are an essential read.


This is especially true since some of the verification and troubleshooting syntax for Nexus is just out of this world.  I swear whoever works on the actual syntax parser for the NX-OS software team must get paid based on the number of characters that the commands contain.  Did you say that your Fibre Channel over Ethernet isn’t working to your Nexus 2232PP Fabric Extenders that have multiple parent Nexus 5548UP switches paired in Enhanced Virtual Port Channel?  I hope you remember how to troubleshoot them with the command show system internal dcbx info interface ethernet 101/1/1!  Err… how about we just know where to find it in the FCoE troubleshooting guide instead then.

The troubleshooting guides are an often overlooked section of the documentation.


The real point of using the documentation is as follows: you must understand, in detail, the design caveats and hardware caveats that the Nexus, MDS, and UCS platforms have as they relate to the DC technologies.

Pictured above, some light reading on the Design Considerations for Classical Ethernet Integration of the Cisco Nexus 7000 M1 and F1 Modules


Recommended Books

Beyond the documentation, there are a select few regular books that I used during my studies.  The vast majority of them are either available on the Safari Online site, or in the case of the IBM Redbooks, free in PDF form direct from IBM’s website.  These books, in no particular order are:

Cisco Live 365

For those of you that have never heard of Cisco Live 365 before, you’re welcome. ;)  This is where all the video recordings and PDFs of slide decks are from the different Cisco Live (i.e. Cisco Networkers) conventions that have occurred in the past few years, from multiple locations.  A lot of these sessions are used to talk about the introduction of new products, e.g. the new Nexus 7700 that was just announced at Cisco Live 2013 Orlando, while others are technical deep-dives into topics.  In the case of CCIE Data Center there are a lot of really good presentations that I would recommend looking at during your preparation.  You don’t need to have physically attended Cisco Live in the past to get access, just sign up for an account for free and you can search all the content.  The Data Center sessions generally start with “BRKDCT” (Breakout Data Center Technologies), so that’s a good place to start your search.  Notable ones that I personally thought are worth looking at are in no particular order as follows:

  • BRKDCT-2204 - Nexus 7000/5000/2000/1000v Deployment Case Studies
  • BRKDCT-2237 - Versatile architecture of using Nexus 7000 with F1 and M-series I/O modules to deliver FEX, FabricPath edge and Multihop FCoE all at the same time
  • BRKCRS-3145 - Troubleshooting Cisco Nexus 5000 / 2000 Series Switches
  • BRKDCT-2048 - Deploying Virtual Port Channel in NXOS
  • BRKCRS-3146 - Advanced VPC operation and troubleshooting
  • BRKDCT-2081 - Cisco FabricPath Technology and Design
  • BRKDCT-2202 - FabricPath Migration Use Case
  • BRKDCT-1044 - FCoE for the IP Network Engineer
  • BRKSAN-2047 - FCoE - Design, Operations and Management Best Practices
  • BRKCOM-2002 - UCS Supported Storage Architectures and Best Practices with Storage
  • BRKVIR-3013 - Deploying and Troubleshooting the Nexus 1000v virtual switch
  • BRKRST-2930 - Implementing QoS with Nexus and NX-OS
  • BRKCOM-2005 - UCS and Nexus Fabric and VM's - Extending FEX direct to VM's in UCS and Nexus 5500
  • BRKCOM-2003 - UCS Networking - Deep Dive

INE’s Videos, Workbooks, & Classes

Now in my personal case, when I am learning a new technology, I know that I have truly absorbed and understood the topics when I can explain it to someone else in a clear and concise manner, hence my day job, author and instructor at INE.  From the culmination of reading these books, reading the documentation, and testing essentially every feature that the platforms have to offer, Mark Snow and I developed INE’s Nexus, Storage, and UCS classes, as well as the associated workbook labs and the live Bootcamp classes for these technologies.

As I’ve done many write-ups before on these offerings, and without getting too much into a sales pitch, you can find more information here about INE’s CCIE Data Center Video Series, here about INE’s CCIE Data Center Workbook, here about our CCIE Data Center 10-Day Bootcamp, and here about our CCIE Data Center Rack Rentals.  Note that we are currently adding more capacity to rack rentals and adding more Bootcamp classes to the schedule, both of which I’ll be posting separate announcements about shortly.

Read, Test, Rinse, and Repeat

While learning and developing the content for Data Center I followed the same methodology that Brian Dennis and I have been personally using and have been teaching for the past 10 years (yes, I can’t believe it’s been that long).  This methodology is essentially a four step process of learning and testing incrementally.  This is also the same methodology that has helped Brian Dennis obtain five CCIEs, and for me to obtain four CCIEs and the CCDE, so trust me when I say that it works.

The methodology is a basic four step process as follows:

  • Gain a basic understanding of the technologies
  • Gain basic hands-on experience to reinforce and expand your understanding
  • Gain an expert level of understanding
  • Gain an expert level of hands-on experience

It might seem self-explanatory that you need to start at the bottom and work your way up, i.e. A then B then C then D, however over the years we’ve seen so many CCIE candidates try to shortcut this process and try to go from A directly to D.  Traditionally these are the candidates that end up taking the lab exam 5, 6, 7 times before passing, essentially trying to brute force their way through the lab.  Believe it or not, we have had customers in the past that have attempted the CCIE Lab Exam in the same track 10 or more times before passing.  Coincidentally, these are also usually the customers that don’t want to hear that they don’t know something or that their methodology is wrong. Go figure.

Pictured above, how to make a hobby out of visiting building C at Cisco’s San Jose campus.


At least for me personally, obtaining a CCIE is more about the journey than it is the destination.  I feel that I would have cheated myself coming out of the process without truly being an expert at the technologies covered, so I made sure to really take the time and be meticulous about going through everything.

Pictured above, how to astound the engineers at the technical interview for your new job after getting your CCIE.


The CCIE Data Center Written Exam

Before scheduling the Lab Exam, I of course had to tackle the necessary evil that is the CCIE Data Center Written Exam. In my opinion this exam should be renamed the “how many stupid facts can I memorize about the Nexus and UCS platforms exam.”  I didn’t pass the DC written exam on my first attempt, or on my second attempt.  I’m not going to say exactly how many times I took the the DC written exam, but let’s just say that it’s somewhere more than two and somewhere less than infinity, and that I likely have seen every question in the test pool multiple times.

For those of you have passed this exam on your first try, more power to you.  With me on the other hand I try not to memorize any facts that I can quickly look up instead. While whoever wrote the CCIE DC Written Exam may think it's important that the UCS B420 M3 Blade Server has a Matrox G200e video controller with integrated 2D graphics core with hardware acceleration and supports all display resolutions up to 1920 x 1200 x 16 bpp resolution at 60 Hz with a 24-bit color depth for all resolutions less than 1600x1200 and up to 256 MB video memory, I do not, but I digress.

Scheduling the CCIE Data Center Lab Exam

One of the biggest hurdles in obtaining the CCIE DC that I had not initially planned for was the availability, or lack thereof, of lab dates open for scheduling.  I’m not normally one to complain about this, because when I took the CCIE R&S Lab Exam back in January 2002 I believe that I scheduled the date somewhere around July of 2001. Back then it was the norm to have a 6 month wait for dates, so when you went to the lab you had better be really prepared for it, otherwise you had a long 6 months ahead of you afterwards trying to think of what you did wrong.  With Data Center though, this was a completely different ballgame.

By the time I got around to being ready to schedule a date, there was literally not a single date open on the schedule for any location.  Mark Snow had even scheduled a lab date in Brussels Belgium, and was going to fly from Los Angeles in order to take the lab because that was literally his only option.  Luckily right around that time the CCIE Program added  new dates on the schedule, and he was able to move his lab attempt to San Jose, where he ended up passing.

Anyways once these new dates were added to the schedule I knew that I had to act fast, or risk having to wait until 2015 (not really, but that’s what it felt like).  Unfortunately the date that I took was only a week after Cisco Live 2013 Orlando, so I couldn’t help but feel while we were partying it up at the conference I should have been at home studying instead.  Also I would have much preferred to go to RTP over San Jose, since RTP is much closer to Chicago and I’m much more familiar with the area.  In hindsight SJC was probably a better choice anyways, since I have lots of friends in RTP which means there would have been more distractions.

Traveling To San Jose

I scheduled my exam purposely on a Monday, which meant that I could get to San Jose either Friday or Saturday and then leisurely spend the rest of the weekend doing some last minute review and relaxing in the hotel without any distractions.  This is the first time I’ve done it this way, and if you have the option to this is the approach that I would recommend.

Having had all my attempts in RTP in the past I was never worried about travel time, since it’s only about two hours from Chicago.  Normally I would fly in the day before the lab in the afternoon, and then immediately go to the airport after the exam to fly home.  Worst case scenario I could drive from to Chicago to RTP, which I actually have done in the past.  I remember one time when teaching a class at Cisco’s RTP office I left the campus at about 5:30 on a Friday, drove to RDU and parked my car, bought a ticket at the desk, and still had time to make a 6:15 Southwest flight back to Chicago.  I could only dream that Chicago O’Hare or Midway was as delay-free as RDU.

SJC on the other hand doesn’t have as many flights to Chicago, so I wanted to play it safe and arrive more than one day early.  Luckily I did plan it this way, otherwise with the Asiana Flight 214 incident at SFO this past weekend I might not be writing this post at all right now; the moral or the story being that if you have the option to travel an extra day early before the exam, take that option.

For the hotel I stayed at the Hyatt Regency Santa Clara, which was nice.  They have a nice outdoor pool area that I spent some time relaxing with my laptop at.  It’s fairly close to the Cisco campus, being about a 5 – 10 minute cab ride to the office in the morning, and then after the lab I walked back to the hotel which took about a half an hour or so.  If you’re familiar with the area it’s directly next to the Techmart and the Santa Clara Convention Center.

The Day of the Lab

San Jose’s lab starts at 8:15am, so I scheduled a cab from the hotel at 7:20am.  I figured this way even if the cab didn’t show up I’d still have time to walk over to the office.  Admittedly I did arrive much too early to the office, but it’s always better to be early than late.  If you’ve ever had a class with Brian Dennis you’ve probably heard the same joke he’s been telling for the last 10 years: “I’ve been both early for the CCIE Lab Exam and I’ve been late for the CCIE Lab Exam.  The preferred method is to be early.”

Since it was only about 7:30am when I got there I walked around the campus for a while just to try to calm my nerves.  Ultimately I checked in with the receptionist, and made some small talk with some of the other candidates.  I was hoping to go incognito for the day, but immediately the first guy I said hi to said “aren’t you Brian McGahan from INE?”  Oh well… that's the price of being nerd famous.

The proctor Tong Ma came out to the lobby around 8:15am or so to collect us all and check IDs, and then did his spiel about the logistics of the lab location (e.g. where the bathroom was, the breakroom, lunch time, etc.).  8:30am was our official start time, so I sharpened my colored pencils, sat down at my terminal, logged in, and prepared for the fun.

Immediately all around me I heard the other candidates furiously pounding away on their keyboards.  This is what I like to call the “panic approach”. I on the other hand started with a different approach that had already worked for me three times in the past.  I took my first sheet of scratch paper, and started a quick drawing of the diagram I was presented with.  This was my first lab attempt using the new lab delivery system where everything is electronic, but regardless in past attempts you couldn’t draw on their diagrams anyways.

One point of drawing out the diagram for myself was to help me learn the topology, but more importantly so that I could take quick notes as to which technologies would need to be configured in which portions of the network, e.g. which devices were running vPC, FabricPath, OTV, FCoE, etc.

The next step was to read through the exam, to see what technologies were actually being tested on, and to plan my order of attack on how I was going to build the network.  One thing that I have found with my past CCIE tracks is that the order that they give you the questions in isn’t necessarily always the best order that you actually want to configure things.  After all they’re only grading the result at the end of the day, not the actual steps that you used to get there.

Once I had a basic understanding of what was covered, and had taken some notes on my diagram as to which features went where, I took my two other pieces of scratch paper (there were 3 total but you can always ask for more if you need), and drew out my two tables that I use to track my work.  For those of you that have attended a live class with me in the past or watched any videos I’ve done on lab strategy you may be familiar with this, but for those of you that haven’t seen this there’s basically two tables that I use to track my work during the day.  The first of which I use to track which sections that I have configured, how comfortable I am with the answer I gave, and which sections I skipped.  Throughout the day this helps me to know what sections I need to go back to at a later time.  Also at the end of the day this is the sheet I use to go back and check everything with a fine tooth comb.  The end result looks something similar to the picture below, but this one is just something I made up now it’s not from any real lab.

The way I read this at the end of the day is that all the tasks with a Check mark I’m 100% confident that the solution is correct.  Tasks with a ? mean that I configured something, but I’m not 100% if it’s correct or that I answered the question the way that they wanted.  Anything that is blank, like section 2.3 that means that I completely skipped that task, and that I’ll come back to it at a later time.  Once I’m done with all the tasks, I then circle back around to the tasks that I completely skipped to see if I can answer them, then revisit the ones with a ? that I wasn’t 100% sure about.  Finally the “2nd” column is for my double checking, where I start all the way at the beginning of the lab and re-read each question, re-interpret it, verify my answer, and if satisfied check it off again and continue.  In the case of the DC Lab Exam I ended up with two tasks with a question mark and one task with a blank at the end of the day.  In other words by my count there was one task I definitely was getting wrong, two tasks I had completed but wasn’t sure if I interpreted properly exactly what they wanted, and all other tasks I was 100% confident were correct.

The second of these scratch paper tables was to track my timing.  After all if they gave you a week to configure the lab, most candidates would probably pass.  With the 8 hour time limit ticking down though, not so much.  This is why it’s not only important to track your progress throughout the day to see which sections you’re confident about your answer, but also how long it’s taking you to configure them.  The end result of this table looks something like this:

The “Time” column represents the hour of the day.  The lab starts around 8 and ends around 5.  Between 8am and 9am, I got zero points.  The rest of the values in the table are made up, I don’t remember what the point values of the sections in my attempt were, but the first row is actually true.  From 8:30am to 9am I did not configure a single section, and I did not gain a single point.  Why?  Because I spent that half hour drawing the topology, reading through the tasks, and planning my attack.  While most people take the “panic approach” and immediately begin configuring the lab blind, I knew that even though it would cost me time up front to draw and read, it would save me time in the long run.  This did actually save time in the long run, because I finished about 95% of the exam by 2:30pm, which gave me a very relaxed two and half hours at the end of the day to double, triple, and quadruple check my work.

Getting back to the table above, between 9am and 10am, I completed – and was confident with the answers of – sections that were worth 2, 2, 3, 2, 4, 2, and 2 points.  Basically each time I completed a task and it had a check mark in the other table, I wrote the point value down here.  Each time I completed a section I also checked the clock on the wall to make sure I was writing the point value in the correct row.  The logic of using this table is simple:  the exam is broken down into sections totaling 100 points.  Excluding your lunch break, you get 8 hours to configure the lab.  This means at an absolute minimum you need to be averaging 10 points per hour in order to hit your goal of 80 points.  Now ultimately the totals on the right should be consistently be reading above 10 points for the early portion of the day, because you don’t want to configure exactly 80 points worth of sections with zero time left over at the end of the day to check your work.  In this situation it’s very likely that you’re failing the exam.  Instead you want to be consistently be hitting 14 points, 16 points, etc. especially early in the day, because then it makes you more relaxed that you’re not as rushed for time.  Remember that in the CCIE Lab Exam your biggest enemy is stress – well other than simply not knowing the technologies, that’s kind of an issue too – so whatever you can do to help calm yourself down during the day, do it.

For me personally constantly tracking my timing is one of those methods that helps to relax me.  When I hit about 1pm/2pm that day, I looked at my sheets that were tracking my work, sat back and said to myself “there’s no possible way you’re not passing this exam.” Now of course I didn’t really know for a fact that I was passing, ultimately only the score report can tell you that, but based on my point counts and how much time I had left to go back and double check I knew that I was golden.  This brings us to my next point, which is that “golden moment”.

The Golden Moment

Every CCIE Track and its associated CCIE Lab Exam has what has been commonly referred to as the “golden moment”.  This is basically the point in the exam that if you can reach, and you have everything working, your chances of passing are very high, i.e. you’re “golden”.  In the case of CCIE R&S it’s having full IP reachability everywhere.  In Security it’s when all your LAN to LAN and Remote Access VPNs work; in Service Provider it’s when you can ping between all your L2VPN and L3VPN sites; in Voice it’s when you can make all your phones ring, etc.  In the case of CCIE Data Center, the golden moment is undoubtedly marked by one point: can you get your UCS blades to boot from the SAN.

Pictured above, the Zen of Buddha passing over me when I knew that I had reached the golden moment.


The CCIE Data Center Lab Exam is very unique in my opinion based on the fact that essentially all tasks are cumulative and somehow interrelated in the exam.  For example in the case of CCIE R&S, you could theoretically skip complete sections, such as IPv6, Multicast, QoS, etc. and still pass the exam, as long as you can gain enough points from all the other sections.  For Data Center though, this is not the case.  All tasks in the exam essentially are getting you to work towards the golden moment, which is to actually get your servers to boot their OS.  All the technologies are so highly interrelated that the DC lab exam is a delicate house of cards. If one minor task is wrong, you’ve essentially bought yourself a $100 rack rental and a $1400 lunch for the day.

For example let’s take a theoretical CCIE DC lab scenario, and look at how the most minor of mistakes can snowball, and cause you to have a very bad day. Suppose we have two Data Center sites, “DC-A” and “DC-B”.  In DC-A we have our UCS B series blade servers, while in DC-B we have our Fibre Channel SAN.  Our ultimate goal is to get the blades in DC-A to boot from the SAN in DC-B. DC-A and DC-B have a Data Center Interconnect (DCI) provider between them that runs both IPv4 Unicast and IPv4 Multicast routing, and it’s up to us to configure everything so that it functions properly.  On one our our edge Nexus 7Ks though we forgot to enable jumbo MTU on the link to the DCI.  Minor problem, right?  Wrong, we just failed the exam! But why?

The UCS blade server was trying to boot to the Fibre Channel SAN.  Fibre Channel doesn’t natively run over the DCI though because it’s a routed IP network.  To fix this we first sent the FC traffic to our MDS 9200 switches.  The MDS switches in DC-A and DC-B then encapsulated the Fibre Channel into a Fibre Channel over IP (FCIP) tunnel between each other.  Additionally the MDSes were in the same IP subnet and VLAN in both DC-A and DC-B, so their FCIP traffic had to go over an Overlay Transport Virtualization (OTV) tunnel across the DCI.  The OTV tunnel was up and working.  The FCIP tunnel was up and working.  Both the UCS blade and the FC SAN successfully FLOGI’d into the Fibre Channel Fabric.  All of our Fibre Channel Zoning was configured properly.  The UCS blade server’s Service Profile associated properly.  We clicked the “Boot Server” button, connected to the KVM console of the blade, crossed our fingers, and got this:

Pictured above, someone having a very bad day in the CCIE Data Center Lab Exam.


No!  It didn’t boot the VMware ESXi instance!  This means that our Nexus 1000v didn’t come up either! I just lost 22 points and failed the exam!  Why did the CCIE Lab Exam Gods hate me!

Pictured above, 2274 bytes > 1500 bytes


Our OTV tunnel is actually Ethernet over MPLS over GRE over IP, or what is sometimes referred to as a Fancy GRE Tunnel. Our SAN traffic is SCSI over Fibre Channel over TCP over IP.  FCIP frames can go up to about 2300 bytes in size, but our default Ethernet MTU was 1500 bytes.  OTV doesn’t support fragmentation, and sets the DF bit in its header.  This means that since we forgot to type the single command mtu 9216 on the edge switch connected to the DCI, our SCSI over Fibre Channel over TCP over IP over Ethernet over MPLS over GRE over IP was dropped, and we had to do the walk of shame out of building C in San Jose as we knew the CCIE Lab Exam had defeated us that day.

This of course is just one of a thousand different possible examples of how the house of cards that is the Data Center Lab Exam fits together, but you get the idea.  Luckily for me however, when I clicked the “Boot Server” button in UCSM this week, the results were closer to the output below.

Pictured above, someone doing the happy dance in the CCIE DC Lab Exam.


In Conclusion

For those of you still reading I hope that you found this post both helpful and informative.  If you’re still on the fence about pursuing the CCIE Data Center Track I would definitely say that it’s worth it.  If you told me 12 years ago when I got out of server support that I’d be back in the server support market today I’d never have believed it, but without throwing around too many buzzwords like public/private cloud etc. this Data Center space is clearly here to stay, and will only continue to grow.  Especially with how rapidly the market has been changing within the past few years with virtualization and an entire plethora of new technologies and design philosophies, it’s more important than ever to try to differentiate your skill set in the market.

Thanks for all the well wishes, and good luck in your studies!


Brian Dennis and I attended Cisco Live! - Networkers this week, and both enjoyed the privilege of sitting down to talk privately with Yusuf Bhaiji (Program Manager over the entire CCIE program) and Ben Ng (Program Manager over the CCIE Voice track) for roughly 45 minutes. It was quite an enjoyable and spirited talk, and I believe it benefited both sides - our side to gain a better understanding of why some of the choices have been made, and theirs possibly to see things a bit more 'through the eyes of the typical hard-studying student'. I would like to take a moment to jot down some of the highlights from our conversation, and then unpack them in a bit more detail, so that you may benefit from the open conversation.


I'll jot down some very simple, high-level topics that were discussed during our conversation, and then unpack them in more detail in the following section.

  • Upcoming changes to every CCIE Lab Exam
    • Protecting the integrity of the CCIE certification
    • Robust, matured results-based grading engine
    • Heuristic logic embedded into task wording
    • Accuracy and detail of lab score reports
    • Cisco's CCIE Lab Delivery System and virtualization for mobile labs
    • No re-reads
  • CCIE Voice
    • Next blueprint version expectation
    • Topics for current and next blueprint versions
  • CCIE Data Center
    • CCIE Storage grows up
  • Reason behind Cisco.com CCIE Statistics web page being removed

Let's Unpack This a Bit More

Firstly, if I could sum up our entire conversation into one, clear theme, it would be "Protecting the Integrity of the CCIE Program". Indeed, both Yusuf and Ben clearly stated that central theme was the primary guiding principle behind every meeting they have regarding any aspect of the program, every planning session for the future of the program, and every decision made to add, remove and/or change anything in any of the tracks.

The main focus is to ensure that candidates who are attempting the lab exams are what Cisco is certifying them as: Experts. To ensure that no one is able to memorize any aspect of the exam, and to make sure that those of us that are teaching these potential candidates about the technologies involved, are in fact teaching our students everything they need to know about a given group of technologies necessary to become a true expert - something INE has always worked incredibly hard to do. This focus (and the changes it will affect) implicitly deals with the problems that have arisen in the past with a small minority of people who dishonestly try just to memorize parts of the exam, as well as companies who blatantly cater to that small minority by attempting to gain access to a given exam and publish entire exams, or even parts of them.

Now, this has always been a driving focus for the program, however they realized that while some of their efforts in the past to this end have been successful, that many also may not have succeeded in the manor in which they had intended for them to. Case in point: Core Knowledge/Open-Ended Questions (and their complete removal from all tracks). Another attempt at this from long ago -and still in place but soon to possibly change- was the 'detailed score report' (or shall I say 'lack' of detail in the score report). More on that last bit in a moment.

Upcoming Changes to Every Lab

So, onto the specifics of how they plan to accomplish this. With no definites given as to exactly how or when the implementation of any of these initiatives would be implemented, some things were quite frank and very clearly stated. They talked about how their lab grading engine has been in use for some time now, and has reached quite a mature level with it's results-based scoring (both terms of it's accuracy as well as it's modularity). Now would be remiss if I didn't take a quick aside to say when I mention that it has reached a high level of accuracy, some might immediately jump to the conclusion that it wasn't accurate before, and that might have been the reason for their failed attempt. Just to quell those fears, a (human) proctor has always, and will continue to look over and verify a candidate's lab and scripted grading results before issuing the final grade. Now with the fact that the engine grades based on results-based testing (and not on any specific commands input into the configuration), as well as the key point that it is extremely modular (due to it's structured XML nature), any given task can be tested in the same way, however worded in 10-15 different ways on different iterations of any given lab exam. This leads naturally to the ability for them to have upwards of 25 or 50 labs in rotation at any given time for any given CCIE track and blueprint, which makes it nearly imposible for anyone to actually memorize any/all of the questions or versions of lab exams. Thus making those that pass, truly validated as experts. They spoke of a sort-of heuristic logic woven into all of the task wording to accomplish this. Also talked a lot about was how troubleshooting was one of the best things that they added (added 'back' I should say, since it used to be there in the 2-day exam). So look for that to not only continue, but permeate its way through more exams in more ways. No mention was specifically made as to whether any other track outside of R/S would go to the same sort of segregated TS section that it utilizes - so it may happen, it may not. Just have to wait and see.

They have been developing towards this goal for some time now, they know exactly how they will carry it out (however to disseminate that specific knowledge would be completely counter-intuitive to the very idea of integrity protection - so anyone telling you they 'know' how it's being done clearly doesn't know what they are talking about). They mentioned that it will be occurring soon, though when exactly won't ever be known or disclosed, and it won't be necessary to 'announce' it per-se, since it won't require the upgrade/change of any hardware/software or technology-specific topics.

All of what we've talked about up till this point, this obviously doesn't negatively impact any of our readers here, as you all are true learners, true knowledge-seekers - those who wish to not only know, but to truly understand (to paraphrase Einstein, if I may). However, it may have some positive implications that you have not yet considered. Aside from the obvious fact that it preserves the integrity of the prestigious certification that you have (and continue to) worked so diligently towards achieving, another possible benefit from this is that since the CCIE program has/will-have this new ability to have so many exams in rotation (and thus exponentially-if-not-entirely reducing the possibility of memorization of tasks), they can relax a bit on their very ambiguous failed score reports. For those of you who are not yet aware, while some candidates pass on their first attempt, most do not. In fact the average (very loose average) is roughly 2-3 attempts at any given CCIE lab before a 'Pass' is awarded, and you only receive a broken down score report if you fail - if you pass you simply receive a 'PASS' (and frankly, you don't care that you didn't receive a report). Now they didn't state for certain that this would in fact occur (more detailed reports), but they did indicate that it was being discussed internally as a strong possibility - since the grading engine obviously reports back in extreme detail - although he (Yusuf) said it would never include specifically which tasks you got right vs wrong. However, he did also mention that the purpose of the CCIE Program is not to train candidates or provide feedback - it is to test them. It is the responsibility of us, the CCIE training providers, to not only teach, but pre-test and provide accurate feedback to students before they make the actual journey to the Lab and truly become candidates for admission into the prestigious certification that is the CCIE. That by the way, is something that INE is committed to, and indeed already provides more than adequate resources for CCIE R/S, and will soon be adding for the CCIE Voice as well (more on that later).

Another one of the initiatives of the program is to make it much more widely accesible to everyone, everywhere. This was the impetus behind the original idea of having the lab able to be taken from any Prometric/Vue testing center. But Vue wasn't really ready to handle the stringent requirements, and thus the attempt didn't ultimately succeed. Then came the CCIE Mobile Testing Labs. Those worked. Well. Really well in fact. And now the push is to make every single track able to be tested in that same mobile fashion. However, there are a few challenges to overcome first, before that can become a reality. Take CCIE Voice for instance - in order for the Voice lab to become truly mobile, everything has to be ported to Cisco's CCIE Lab Delivery System (where everything: the tasks, the desktop for CLI/GUI, etc. are all completely virtualized). This means the phones themselves as well. Softphones won't do. They don't behave at all like hardware phones. So they are working on creating a completely virtualized hardware-like phone, that behaves exactly like a hardware phone (but doesn't remotely control one). When they get that completed, then you will begin to see the Voice lab become available in the mobile testing centers (along with every other lab once their similar challenges are met).

One last thing I asked Yusuf about regarding specifically the CCIE Voice lab exam, was why they hadn't yet allowed for re-reads (the ability that, if you fail an exam but think you should have passed, you can pay $300 USD to have your lab re-graded manually). He mentioned that since the overall percentage since they began offering that option was so extremely low of those who request a re-read actually results in a grade being overturned (we're talking like 1 out of every 5,000), not to mention that that number has dropped even more with results-based scripted grading, that the focus was not to add more of that unnecessary burden on the already taxed proctors, but to reduce it. So while he didn't provide any guidance on when (if ever) they will completely eliminate that practice from the other tracks (R/S, Sec, SP), he did say that the focus is on removing that option from those tracks vs. adding that option to other tracks (Voice, WiFi, Storage).

CCIE Voice

There was a very interesting breakout session this year entitled "CCIE Voice: Cryptography in Cisco Unified Communications", which inevitably led to the question by participants: "If this class is prefaced by the title 'CCIE Voice', does this mean that Cryptography/Security is going to begin being tested in the lab exam?". The answer to this when asked by the attendee and then later in a bit more detail by me was answered with the basic answer of (and I'll paraphrase): "This has been tested in the written exam for some time now, however there is absolutely nothing stopping us from testing this in the lab today with version 7 of the various UC platform servers, and obviously no problem testing it moving forward to UC version 8 (or 9, etc), as even more security has been added to the new version of UC platforms".

Of course, in the main CCIE Voice 8-hour Technical Seminar, the question was asked by some participants (as well as by me in more detail later in private) when we might anticipate the Voice lab being updated to UC platform version 8.x (or beyond, if FCS'd for better than 6 months by time of announcement), to which Ben gave no real guidance publicly, yet in private alluded to (reverting back to our previous mention in this blog post) the desire to virtualize the hardware phones and deliver the exam with the new virtual Lab Delivery System, so that they could support the mobile labs.

Now of course 8.x has been in production for well over a year now in many networks around the globe, but 9.x doesn't FCS (First Customer Ship) until April '12, meaning that they could possibly update the lab to UC platform version 8 anytime (with a standard 6-month pre-announcement of course), but to update to version 9 would mean that they couldn't even announce a new lab based on that version until Oct '12, with it going live around Apr '13 at the earliest. I have no idea at all which they will end up doing, and from talking with Ben, he made it seem like they hadn't reached an internal decision yet either. In fact it probably will largely depend on how quickly they get that virtualized hardware-like phone put into production in all reality.

Either way, it doesn't really matter. INE has you covered. The major new things in CUCM ver 8.x that can be tested are the following:

  • Call Control Discovery over the new Services Advertisement Framework (CCD / SAF) with RSVP SIP Preconditions
  • Extension Mobility Cross Cluster (EMCC)
  • SIP Normalization using the Lua scripting language

They can't really test the Intercompany Media Engine (IME) - it's just not technically possible. EMCC is easy, and within the day of them announcing this being tested I'll have a minimum 2-hour video ready. I already have over 4 hours recorded on every aspect of CCD over SAF and another half hour of the RSVP with SIP Preconditions in our new CCNP Voice product (which should be posted to our CDN in about a week). SIP Normalization with Lua -- eewww -- let's hope they don't test you on it - but either way, we'll have a video for you the week they announce it.

There are way too many small new features in UC 9.x to list here, -- I'll do a post covering those in the not-too-distant future, but needless to say, it won't be hard to add content to what we have to cover it. The best news is that everything you are studying today, is 100% completely relevant to any new version of the lab that could be announced, whenever they decide to do so -- so don't loose an moment of sleep over a possible upgrade -- you'll be 98% ready anyhow.

As for the possible testing of Cryptography/Security, I will be adding labs to our Volume II Workbook here in the upcoming month, with at least one of which will specifically address this topic. Our racks will allow you to test those features related to security to coincide with the release of that lab.

CCIE Data Center

Now, onto Data Center. Data Center was easily, hands-down, the single largest topic discussed at this year's Cisco Live! event. Not to mention that VMware timed the announcement of version 5 of their suite of virtualization products (including vSphere, vCenter Site Recovery Manager, vSphere Storage Appliance, and vCenter Heartbeat Center) to be exactly 1 hour prior to (and thus ending with the beginning of) John Chamber's Keynote address at Cisco Live!.

But here's how everything relates to the CCIE program. It was very clear that the CCIE Storage is going to become the CCIE Data Center. In fact, aside from that being very clearly stated, the breakout this year was entitled: "Cisco Data Center/Storage Certification". It was stated that the following would be what comprised the new CCIE DC.

Written exam will include (this is their wording copied verbatim):


  • Revised Smaller version of the existing SAN Track blueprint
    • MDS device operation, Advanced FC Features, SAN extension & switch Interop
    • SAN Management will be integrated in the new overall DC management
  • In addition to new topics to include:
    • Basic Data Center L3 topology
    • Data Center Access Layer deployment
      • L2, vPC, Fabric Multipathing, QoS
      • Virtualization
      • Unified I/O, FCoE , DCBX
    • Unified Computing System (UCS)
    • Load Balancing techniques and algorithms
    • Branch WAN Acceleration
    • Data Center Management

Lab exam will look like this (this is their wording copied verbatim):

  • MDS will remain in the lab as well as 3rd party FC switches
  • We will consider adding DC solutions and technologies that can be deployed on the following Cisco Products:
    • MDS SAN Switches
    • Nexus 7000, 5000 and 2000
    • Cisco Unified Computing Systems (UCS)
    • Application Control Engine (ACE)
    • Global Site Selector (GSS) in case of DR scenario
    • Wide Area Application Services (WAAS)
    • Data Center Management for both LAN & SAN
    • Virtualization with Nexus 1000v

Of all those things that can be tested, the most obvious ones that would almost have to be included are the Nexus line of DC switches and the UCS blade servers, complete with Fabric Interconnects and Virtual Interface Cards. So those are the things that INE will begin immediately to record video-based lessons on, adding them to our All Access Pass. Guidance wasn't provided on exactly when this track might go into live testing, though sources tell us that we may be less than 12 months away from it going live. Watch this blog for announcements soon on when you might expect the first of those Nexus and UCS training videos. Storage wasn't big. Data Center is already huge. The CCIE Data Center is going to be as well.


I mentioned above two things that I forgot to include, so I will add them in here.

First off I mentioned that we will be adding graded mock labs to the Voice track. Please email me directly if you would be interested in participating in a graded mock lab. It would involve using a dedicated rack for 8.5 hours (8 hours for config and .5 for lunch, just like the real lab) with basic minimal access to the proctor (myself) for basic question clarification, but no real assistance (again, just like the real lab).

Second thing was the reasoning behind the removal of the CCIE stats page from cisco.com. This might sound like a strange reason - I thought so, but after listening to Yusuf talk a bit more about it, it did make good sense in the end. The reason was completely centered around the fact that when one updates his/her cisco.com testing profile with the proper home mailing address, and most importantly home country, and then takes and passes any CCIE exam, his/her CCIE number is forever associated with that country. The problem was, people didn't always stay in that country. They sometimes moved, as is a reasonable assumption. However, the CCIE stats page wasn't designed as a synchronous page that would do a real-time DB lookup each time it was loaded, and so it would always report X number of CCIEs in X country. Yusuf used himself as an example. He's from Pakistan, and so his CCIE was basically 'registered' there (at least so far as that stats page went). Problem is, he moved to Australia for a number of years, but according to that stats page, his CCIE was still in Pakistan. Then he moved to Dubai in the UAE. CCIE? Still in Pakistan. So why should any of that matter? Well, to you and me - it might not. However, when a Cisco Partner in Pakistan (just continuing our example of Yusuf) is told by their Channels team: "You must have 4 CCIEs to become a Gold Partner" (or CCDE's, they count now too for that metric), and maybe the parter reports back: "But there aren't enough CCIEs in Pakistan to accomplish that!", the Cisco Channels team would just pull up that stats page, point to it and show the Partner and say: "Yes there are, see here?" (Again, Pakistan is just an example country, I have no idea how many CCIE/CCDEs there are there, so please don't think I'm being partial for/against that or any other country in any way - nothing is implied). It actually became a very, very big issue with Channels and Partner certifications. And Cisco is a large organization. If any of you have worked for one, you know that a team like the CCIE program has nothing to do with web page programming - that's a completely different part of the business. And to get something changed there requires a requisition to be submitted, go through various levels of approval, and finally implementation. And believe it or not, it took about 4 months for that process to occur, and by the time the implementation of it was being carried out (the removal of that page off of cisco.com), it truly just happened to coincide with a period just following a CCIE R/S change that was resulting in less people passing the lab at that specific point in time. Yusuf stated that it couldn't have been worse timing, however it truly was purely coincidental. He also mentioned that - yes, for a period of time after any type of a change to any lab track, there is always a fall-off in the number of CCIEs awarded for that track, but then it always picks back up. This is perfectly natural for any type of change for a number of reasons. 1) People stop booking a given lab en-masse right after a new version is announced - their basically afraid of what they don't know (aren't we all to some degree?). 2) If you sit a brand new lab version, and have no idea what to expect, you might be thrown for a bit of a loop, and therefore loose a bit of time you would expect to be productive during that lab attempt. By the way, this doesn't have to be. Take a bootcamp course from veterans of the lab such as Brian & Brian (and possibly counting myself as a veteran at this point, I guess I'm getting up there in years :-), my first lab attempt was in '02, so I'm going on 10 years next year .... wow -- although Brian Dennis has his 15 year anniversary coming up in just a few months!), and anyway, you'll be prepared no matter what they throw at you, and there will be no need for you to be counted in with the stats of people that 'don't know what to expect after a new version change'. Anyway, he finally mentioned that while Cisco doesn't (and won't) publish the exact statistics of CCIE Pass/Fail, if you look at the overall average number of passing scores over the life of any blueprint version, those numbers have always been, and will continue to keep trending upward.


Well, that's about all I can think of at the moment. I just finished a long flight from Las Vegas to Minneapolis sitting next to Louie Anderson, and to be honest, I'm not sure how I got any writing done. That guy's funny. I need to see him next time I hit the strip.



So many students that pass on a first, or subsequent, attempt of the lab exam emerge to profess the importance of a complete "mastery" of the documentation that is available during the lab exam.

I wanted to bring together in one place here on the blog, three blog links that are designed to assist you in this regard. Enjoy these free training resources!

First, watch this hour-long, complimentary session from the Open Lecture Series on Mastering the DOC-CD:

Click here to watch the video.

Second, it is time to practice what you learned in this interactive DOC-CD exercise:

Click here for the DOC-CD Interactive Video.

Finally, this blog post points out some very useful DOC-CD locations that students have really enjoyed:

Click here for the blog post.


CCIE instructors see the question time and time again - are we penalized for “over-configuration” in the CCIE lab exam? The answer - “not typically”. Let us walk through some examples to see exactly what we are talking about here.

First of all, I encourage students to ask two questions when they are about to “over-configure” something. Question 1 - can this additional configuration I am about to make actually gain me points (might Cisco be grading for it)? Question 2 - can this additional configuration I am about to make actually hurt me (cause point loss)? If the answers are a resounding YES and NO, then it is definitely a configuration you should consider making.

A simple example would be setting a Layer 2 switch port for a VLAN with:

<span>switchport access vlan 100</span>


switchport mode access
switchport access vlan 100

Might Cisco be grading for the specific configuration of DTP mode OFF on the port, perhaps. So the answer to the first question is YES. Notice, on the other hand, this configuration should not cost us points in any way, so the answer to the second question is NO. We see that these questions lead us to the conclusion...if it can only help us and not hurt us - GO FOR IT!

While many times we are not penalized for over-configuration, remember that we are always looking for the simple, time-saving, straightforward solution to the task at hand. I have seen ridiculous amounts of silly over-configuration from students that do not understand this principle. One example that comes to mind is the student that is asked to iBGP peer between R1, R2, and R3 using AS 100. The student then takes it upon himself to configure peer groups, loopback peerings, and router-IDs. All of this is for “good measure” and absolutely none of it was required and gained the student any points! In fact, when asking the second question about the over-configuration causing point-loss, the answer here might be...”yes, it can cause point loss because I am wasting so much time!”

Let us also remember that the key to solving the CCIE lab exam comes down to reading very carefully and following explicit instructions versus implicit instructions that exist in the task. Often times we discover additional configuration steps that we should take due to implied requirements.

I discuss this issue in greater detail in the following blog post:



Hang around our CCIE Forums in the IEOC for any amount of time and you will inevitably see students discussing Core Versus Non-Core tasks in their practice CCIE lab exams.

I wanted to spend a moment here with you on the blog in order to provide exactly what these terms mean to me for my lab strategy.

Folks, for me, it is this simple. If a task has other tasks that might depend on it, I consider this a core task. If the task cannot impact other points in the lab exam, it is a non-core task. It is that simple.

Let us take a look at an example of each now:

1. Layer 2

1.3 Configure the WAN connection between R6 and BB2 per the diagram. Ensure CHAP authentication is used between the devices per the diagram.

3 points

This is a “classic” example of a core task. Notice that if we were to skip or not adequately complete this task, it can cause points to be lost in the IGP and EGP sections, as well as other things like Security and QoS.

Here is an example of a classic non-core task:

1. Layer 2

1.6 Configure ports Fa0/5 and Fa0/6 for PortFast operation and ensure these ports errordisable should a BPDU arrive.

2 points

As we examine this task, we notice that Fa0/5 and Fa0/6 are not actually connected to anything. Yes, this is  a non-core task that has no other points that might possibly depend upon it.

One of the most frustrating things for me to see when I am proctoring our Mock Lab Workshop is when a student will spend a very lengthy period of time trying to solve some silly non-core task. They never do actually solve it and get the points, but they do waste 45 minutes of valuable lab time!

I like to use a Skipped Task Tracker for non-core items that I am just going to skip on my first pass through the lab. Sure, if it is non-core and I can make the configuration easily right off the top of my head, I will probably do it on the first pass. But if it is going to be tricky, or require some DOC-CD research, the Skipped Task Tracker is where it might end up.

Would I ever record a Core task on the Skipped Task Tracker? Well, that is a great question. I would if there was some issue that I still need to address in getting full points for the task. Perhaps I “cheated” and did not get the connectivity the exact way they wanted. Here I will not this on the Skipped Task Tracker and I will know I need to return and give that cheat some attention.

It is interesting that some entire sections in your lab exam will be non-core, but inside those sections you can divide them up into core and non-core. Multicast is a great example. There may be points in the multicast section on building the infrastructure, and if you fail to achieve those points, you fail to achieve the other multicast points.

So as I am working as smartly as humanly possible for me during a lab exam, note that I am constantly weighting tasks based on the simple core versus non-core criteria.


INE wants to thank IEOC member Ray Aragon (NET_OG) for his awesome contributions to our Cisco forums. Thanks so much Ray and enjoy 100 complimentary GradedLabs Rack Rental Tokens.

Ray's IEOC Avatar!

I am sure many of you would love to know more about Ray - here it is:

Ray Aragon is an SE in the Networking World and after 10 Plus years working with State/Local government and Major Carriers around the world he decided to get his CCIE using INE products as his primary study aide. Here were some facts Ray shared with me:

• I think I try to be helpful to others, and identify “pitfalls” and my “ahhh-haa” moments

• I like it when I run into a stumbling block and there is already a good discussion on IEOC

• Much thanks to Routing and Switching (networking)...

◦ I lived in London for two years

◦ I lived in Stockholm for two years

◦ I met my wife in Chile

◦ I have travelled to over 25 countries from Egypt to Indonesia

◦ I have over 1 Million Airplane miles flown

• I have an immense respect for anyone that has put in the time to become a CCIE in any track; it demonstrates a commitment that only after my pursuit I can appreciate.

• My Top 10 favorite cities: Madrid/Rome/London/Santiago, Chile/Rio de Janeiro/Santa Barbara/Miami/Lima/Cancun/Mexico City D.F


As a CCIE instructor, this type of question is one that I see (in IEOC) or hear (in class) often. To help directly address this question, I have maintained a document I call the Expanded Blueprint for many years now. I was quite flattered to see the CCIE team at Cisco publish their own version and name it the Expansion Blueprint. :-)

I made sure to correlate their’s against my own and ensure that I did not miss anything. In fact, what I learned quickly was the fact that they had some very glaring omissions of topic areas that were on the original Lab Blueprint. I would hope they have since corrected that.

But what I want to discuss in this blog post is the fact that regardless of which blueprint document you are relying upon in your studies, Cisco does make it very clear that it is their Certification-given right to test anything they deem appropriate from the 12.4T IOS code (in the case of the routers in the exam). Hmmmm, wait a minute! So they can test anything that the routers or switches can do!?!?!? This will certainly go a long way in dashing the hopes of many feint of heart candidates.

Before you get excessively upset about this fact, just be sure to use some common sense. My Expanded Blueprint is certainly going to cover the overwhelming majority of exam topics. Moreover, I will go so far as to say, since you do not require to pass this exam (either section) with a perfect score, knowledge of the Expanded Blueprint topics is indeed enough to pass. Whew!

I believe that one of the reasons Cisco likes to make this disclaimer (they can test anything), is the fact that they often like to challenge students on new features of protocols or services. This is one of the reasons that I like students to incorporate the New Features section of the DOC-CD in their studies. For more information on using the DOC-CD, you might want to check out my free vSeminar on the topic.

Another perfectly valid reason for Cisco making this statement is the case where a proctor wants to compose a juicy new task and they simply do not want to have to worry about whether or not it is on the blueprint, their expansion version or otherwise. They believe, correctly, that if the feature is contained within the context sensitive help, and/or the documentation, then it is certainly reasonable that a CCIE-level candidate should be able to achieve the points. Buy again, note we are talking about minor router and switch capabilities here and not a dramatically vast topic area.

I would recommend the use of common sense when contemplating your scope of studies. Sure the official, original, condensed Cisco Lab Blueprint might say “Other Security Features”, but do you really think they are going to test R&S candidates on the GET VPN? No. This is the fun that CCIE Security candidates get to enjoy.

If you ever have questions regarding study scope, be sure to hit our forums, but I am thinking you can answer many of those questions for yourself now as well.

By the way, I would recommend you be very careful about listening to what just anyone has to say on subjects like this. For various reasons, candidates, CCIEs, and even some non-INE instructors I have come across, love to instill fear and doubt in others regarding the CCIE and its pursuit.


Before you start either section of your lab exam (Troubleshooting or Configuration), your proctor is going to remind you to save your configurations often. You might even see this written several times in the lab instructions contained in the new GUI. Why are you being asked to do this?

Well, at the very least, you might have a device that hits a snag and just decides to reboot on you. How rude! It is never fun to lose any amount of configuration when you are pressed for time, as you will be in the certification lab exam. But in the worst case scenario, your entire rack of equipment might power cycle due to a catastrophic failure in the Cisco facility that houses your equipment (real and emulated equipment). This could amount to you failing the exam for sure if you were not consistently saving configurations as you go along.

Here was the habit I developed for saving my configurations as I went along. After making a configuration on a local device and performing whatever necessary verifications, I would then type wr or do wrdepending on the configuration mode. Then, while the device is performing its save, I would leave for my next device in the configuration. Using this method, I was completely confident that everything was always tucked away nicely in the startup configuration and did not fear the unplanned reboot.

Whatever your method of saving configurations will be - be sure you practice, practice, practice it prior to sitting your actual lab.

P.S. The only issue I ever had with my approach was that in production networks, I would often find myself compulsively saving configurations, even when I did not want to. :-(


The following video from Cisco provides us with a tour of the new, "paperless" format of the CCIE R&S Version 4 Lab Exam.

Version 4 Lab Exam Interface

Update: Link corrected, thanks.


If you have spent any time in the R&S forums in the IEOC, you have seen the username ndiayemalick. Malick has achieved Elite status in the forum and is always challenging and helping his peers with his excellent posts.

Thank you so much Malick, and we look forward to celebrating your number soon. We are placing 100 GradedLabs rack rental tokens in your account as a small gesture of our appreciation.

I am sure many are interested in Malick's story...here it is:


My name is Malick Ndiaye as you already know. I was born in Senegal, West Africa. When I was 15, I moved with my family to the US, precisely Columbus, Ohio. Two and half years later, in 2001, I got my High School Diploma. Since I finished high school early (January 2001 instead of June 2001) and got all the credits I need to graduate, I started preparing my MCSE. At that time, it was a very hot certification to have, but I never finished it.

Soon after high school, I had a choice to make, going to college or going for IT certifications. I always liked networking and fixing computers. Even as a kid, people used to come and get me at home to fix their computers and printers.  At that time, college was a very long road (4 years) for me. With the support of my dad, who also had to approve, I decided to go back home and learn networking. Since Senegal is a French speaking country, it was hard for me to find the right course taught by the right people. Since I left the country 3 years ago, I almost forgot all my French believe it or not because I did not speak it for so long.

In 2002, I was able to find a networking academy in Ghana that was run by one of my dad's friend .When he offered to take me, I did not even hesitate. I went to Ghana. The CCNA was 8 months long but I did it in 4 months and I got my CCNA. What a great feeling it was. I went back home and decided to go straight for the CCNP. With that in mind, I came back to the US bought me 3 routers and 2 switches and went back home.  I started my CCNP in November 2002 and finished it in July 2003, 8 months to pass the 4 exams.

While I was preparing for my CCNP, I created my company and started for working for myself and I have ever since. I worked with many companies in Africa, accumulated as much experience as I could. My work involved routing, switching, and voice over IP. If there is one thing I have learned during that period it's that experience and hands-on is very important. I learned a lot about VoIP when I was representing Net2Phone in West Africa. I used to sell their devices and unlimited plans to residential customers and businesses to call to the US and Europe unlimited for $30/month. All you need is a DSL connection and I will set you up the same day.

In 2007, I decided to go back to studying. Why? Because knowledge is never enough. It was very hard for me to restart studying. After being so long in the field I lost track of how to study properly. Since I did a lot of design for companies, I decided to go for the design track this track. I went back and got my CCDA then my CCDP.

I did not want to stop there. Why stop in such a good road? In 2008, I decided to go for the CCIE but I did not where to start. I goggled CCIE training and I had two choices, INE and IPExpert. I emailed both of them and guess who replied to me Brain McGahan himself. He put me in touch with sales, they hooked me up with a good discount and I took off for the CCIE. That's one of my best journeys so far in my career. I have learned so much it is just priceless. I passed the written in August 2008. I also bought me a rack just like iNE’s. Anyways I do not plan to top after the R&S, haven’t you seen Petr???

I was even lucky enough to win the first INE scholarship. I won the Bootcamp COD, and since I had the CCIE End-to-End package already, the sales team was kind enough to exchange it for $1000 worth of tokens. Man those guys rock!!!!!! I also took the Advanced Foundation Bootcamp in May 2009. It was an eye opener and I was able to gauge myself during that time.

In August 2009, I attempted the lab even though I knew that I was not ready but I had an opportunity so why not. Come to find out that I came pretty close to passing because the INE labs are way harder than the real lab. But I was not yet an expert so back to deep digging into protocols and IOS features and I have been doing that ever since.

I am heavily preparing for lab and I will make my next attempt in June. Also I am working with ARTP (our FFC) as a consultant to set an Internet Exchange Point (IXP) for Data and Voice in Senegal. Besides that I enjoy working out at the gym and watching movies.

Subscribe to INE Blog Updates