My friend Nick Russo just took the SPv4 lab and passed it. This is his story.
On 8 March 2016, I passed Cisco’s CCIE Service Provider version 4 lab exam. It was my second attempt. I realize there is little information on the Internet about this test because it is still rather new. This blog post will detail my personal strategy for passing the CCIE SPv4 lab exam. Most CCIEs and CCDEs agree that a smart strategy is a critical part of passing any Cisco expert-level lab; many folks are technically proficient but need to remain organized to be effective.
Note: the views expressed in this blog post are mine alone and do not necessarily represent the views of Cisco. No correlation between my comments and Cisco’s recommendation study strategies should be made. Also note that no technical exam content is discussed here in accordance with Cisco’s CCIE NDA. Comments fishing for such information will be deleted.
First, the new blueprint has 3 sections: Troubleshooting (TSHOOT), Diagnostic (DIAG), and Configuration (CONFIG). The CCIE SPv4 program explains these topics in detail within the new blueprint so that is not discussed again here. Since each section is slightly different, one should have 3 different strategies, one to address the challenges of each. After my first failure, I realized it was mostly due to poor strategy during the DIAG and CONFIG sections, not due to a lack of technical knowledge. In order to keep this blog simple to read, I use the following decision points for each section:
1. Whether to draw diagrams or not
2. Whether to perform tasks in sequence or not
3. Level of verification to perform at the end
Before beginning, here are some general strategy tips that apply to all sections and the exam in general.
1. Documentation access is generally fast, but sometimes a hyperlink click can take upwards of 10 seconds to load. It feels like a lifetime. I would recommend opening a browser with 2 tabs at the beginning of each section. Bring up the main page for the IOS XE 3.13S and IOS XR 5.2 configuration guides. Minimize the window so you have quick access should you need it. Documentation is available for all 3 sections of the test. You can use Control+F to search the page for text, but you cannot use the search function to find what you need. I personally spent one hour each night during the week leading up to the test finding my way around the documentation. During the attempt I passed, I used it once, and it was helpful.
2. Track your points. I used to hate this advice but it’s a sound strategy. I can recall some very easy high-point questions which I solved in 5 minutes, and others that took 45 with a ton of configuration. Had I been better at identifying those things during my first attempt, I would have passed. Below is a quick hand-drawn sketch of my personal tracking system. I realize this is not a new invention. 3 columns exist: Task ID, points, and notes. The notes section, in my opinion, is written in the format of “problems/requirements -> proposed solution(s)”. For example, if the task suggests needing a dynamic, scalable, and high performance method to drop ingress traffic at ASBRs to prevent DoS attacks, you might write something like I did below for Task 2.2. Green check marks mean you answered the question and performed a cursory verification. Red circle means “come back to it later”. Green strike-through means you’ve double-verified it at the end of the lab and you are certain you won the points. Red strike-through means you definitely have not answered it and will be awarded no points. You may have a red circle and a green checkmark, implying that you skipped a question but then answered it later. Track your points for all sections.
3. Use notepad like it’s your best friend, because it is. I created a file called scratch.txt and saved it to my desktop. I leave it open at all times to prepare configurations. Some people prefer to have multiple text files for different functions, but I just like a general scratch pad. At the end of the exam, my scratch.txt was a few thousand lines long (lots of copy/paste for preparation). Insert comments in your file to help with indexing. For example, you can search on the string “task 4.1” and it’ll take you to your configurations you prepared. Having one big file makes this easier rather than having a bunch of files open, trying to remember where task 4.1 was configured. You can copy this into an IOS-XR router, including the comment, and it will work.
! task 4.1 conf t router isis 42 net 00.0000.0000.0042.00 is-type level-2 commit end
4. Master IOS-XR RPL. Don’t view it as just an alternate syntax for a route-map; it can do much more. Although CCIE SP isn’t really targeting advanced IOS-XR features per-se, knowing RPL is critical to implementing real-life SP architectures with IOS-XR. Learn the details of parameterization and nesting as this will be a huge timer saver. I also recommend creating three basic RPLs on every IOS-XR router running BGP. You will find that, generally speaking, you will have a common need to do three things. I used these extensively in my studies.
a. Pass all routes
route-policy RPL_PASS pass end-policy
b. Match routes against a prefix-set
route-policy RPL_IF_DEST_PASS($PS) if destination in $PS then pass endif end-policy
c. Match routes against a community-set
route-policy RPL_IF_COM_PASS($CS) if community matches-any $CS then pass endif end-policy
Now that you have these basic RPLs, you can very easily create several custom RPLs using these as your foundation. For example, a customer BGP neighbor policy can set local-preference for all routes marked with community 100:77 to 77. The implicit-deny at the end of the basic RPL ensures that only passed routes will have their local-preferences adjusted. Of course, this means that all other routes are denied; if this isn’t desirable, you may need more RPLs. These RPLs are also handy for basic community or prefix matching for redistribution to/from/between IGPs.
community-set CS_100_77 100:77 end-set route-policy RPL_BGP_IPV4_R3_IN apply RPL_IF_COM_PASS(CS_100_77) set local-preference 77 end-policy
5. Master IOS-XR apply-groups. These are huge time-savers if used intelligently. I personally like to define them for IS-IS and RSVP links. Below is a simple RSVP example; this ensures that all links have some bandwidth assigned to them, and all you need to do is add interfaces under RSVP. A similar construct could be handy for coloring MPLS-TE links with affinity values. For as RSVP example, migrating to a DS-TE network can be simplified when changing all bandwidths to BC0/BC1 syntax becomes effectively one change.
group RSVP_LINK rsvp interface ‘Gig.*’ ! Change the command below and all interfaces will update bandwidth 100000 end-group rsvp apply-group RSVP_LINK interface GigabitEthernet0/0/0/0 interface GigabitEthernet0/0/0/1
Below is an IS-IS example. This reduces a lot per-interface configuration that no longer needs to be replicated many times. I did not use apply-groups on my first attempt but I did on my second, and I am comfortable saying that they helped me pass.
group ISIS_LINK router isis ‘100’ interface ‘Gig.*’ point-to-point hello-padding disable address-family ipv4 unicast mpls ldp sync tag 10 fast-reroute per-prefix end-group router isis 100 apply-group ISIS_LINK interface GigabitEthernet0/0/0/0 interface GigabitEthernet0/0/0/1
Next, I will discuss the three sections of the exam. They are broken down below:
1. Troubleshooting: You will be presented with a sizable network with a number of unrelated trouble tickets to resolve. The tickets are close-ended and very directive. While creative solutions COULD be used to solve any problem, I would recommend only solving the problem and nothing more. If the command tells you to match some show command output, don’t waste your time testing reachability. Tickets may range from a single fault on a single device to multiple faults on multiple devices. Pay attention to the point value associated with the question to gauge its difficulty. Since TSHOOT tickets are supposed to totally independent from one another, I would recommend doing them in sequence. If you get stuck, move on, but remember that hopping around too much isn’t valuable. Since the topology is presented before you with a simple “click on router, get CLI” access mechanism, do not spend time drawing a diagram. It is possible (but unlikely) to solve one ticket and subsequently break another, so I recommend allocating about 5 minutes at the end of TSHOOT to do a very quick check of your correctly answered tickets. This check should be a single show/traceroute/ping command to verify the solution still works. You can leave the TSHOOT section early if you are fast; in both of my lab attempts, I finished in about 90 minutes. The extra time is carried into CONFIG … trust me, you will need it!
a. Do not draw a diagram.
b. Perform tasks in sequence; no need to read the whole section first.
c. Perform a cursory verification at the end.
2. Diagnostics: This is probably the scariest part of the test since it’s relatively new to both RS and SP tracks. TSHOOT existed on RSv4 so there is some experience with that mindset (I took and passed RSv4 as well). The diagnostic section is testing your ability to differentiate between important and unimportant pieces of information. You will be presented with emails, device configurations, logs, and show command outputs. You need to find the problem, and in some cases, suggest a solution. Because the GUI is a little different for DIAG, I strongly recommend taking a moment to draw diagrams for the topologies presented in this section. I did not do this for my first attempt and it made things very difficult for me. As you shuffle back and forth between artifacts, you’ll want to keep the diagram handy. Spend no more than 5 minutes total on all diagrams; no need to include details like interface enumerations or IP addresses. A general diagram for reference is good enough; routers, hostnames, and links are sufficient. DIAG questions are independent from one another like TSHOOT, so sequence isn’t terribly important. As such, I recommend moving sequentially through this section as well. Since there is no CLI access, detailed verification is not possible, but you can move back and forth through the tickets at will. At the end of the section (5 minutes left), quickly skim each question to ensure you at least answered all questions. You cannot end the DIAG section early so if you manage to finish with spare time, I would recommend a deeper scrub of the configuration files to verify that your solution makes sense. There is more information than a human can possibly process in an hour, which is exactly what DIAG is trying to test.
a. Draw rudimentary diagrams before beginning for all sections (5 minutes maximum).
b. Perform tasks in sequence; no need to read the whole section first.
c. Just make sure you answered all the questions at the end. If you have more time, be sure to use it with some extra verification by scrubbing the artifacts.
3. Configuration: The classic CCIE lab exam, this is where all tasks are very open-ended and it’s your job to implement appropriate solutions within a larger network design. The network is sizable like TSHOOT and the GUI works the same way. This is very nice from a consistency standpoint. One thing I really liked about SPv4 is that the questions were more open-ended than I originally anticipated. You really can do whatever you want; I took some off-the-wall creative liberties on both attempts … and did well both times. This helped boost my confidence, even after a failure, because I knew that the graders weren’t looking for “the” solution. Any valid solution qualifies, and you often have many choices. That being said, always try to implement the simplest solution that is dynamic and isolated (meaning, it doesn’t affect other things). READ THE WHOLE EXAM FIRST. This is the oldest advice you’ll ever get from a CCIE and its still true here. You may implement a design that solves 80% of your problems, but creates some new problems that end up costing you time later. I made this mistake during my first attempt. Like TSHOOT, the diagram is presented before you and I do not recommend drawing it. It would take at least 15 minutes to draw an accurate and detailed diagram (then the time to verify it), which isn’t worth the time. I tend to group tasks together based on their function rather than their sequence in the lab. For example, if Task 2.3 tells you to do some MPLS-TE using RSVP, then task 5.2 asks you to deploy TE-FRR across many devices, it would make sense to configure some of those things together. You already need to enable TE on all interfaces explicitly (in IOS and IOS-XE), so why not enable BFD-based RSVP hello signaling as well? You are already in the TE mindset, so creating some backup tunnels at the same time is a natural efficiency to leverage. The same is true for configuring IGP (early) and securing it with authentication (later); doing it all at once isn’t much harder and helps you grab points quickly. If you see that PIM-based multicast VPN is required towards the end, you might as well enable PIM while you are turning on MPLS-TE at the link-level. Note that these specific examples are not based on real exam questions; they are for illustration only. I wish I could take my own advice on this next piece of advice, but detailed verification is critical. I simply ran out of time (even with the extra 30 minutes carried over from TSHOOT) on both attempts. I managed to set aside 30 minutes at the end for verification which allowed me to perform a not-deep-enough verification, but I did catch some minor errors. Ideally, you should allocate a full hour for it. I don’t know the exact passing score, but I had a number in my mind, and I was just a little bit above that number at the one-hour-remaining mark. I knew I needed more points to build a buffer to compensate for incorrectly answered questions, hence the abbreviated verification process.
a. Do not draw a diagram.
b. Read the whole lab first and perform tasks in the most efficient/sensible sequence.
c. Perform a detailed verification to the best of your ability (one hour minimum).
Please comment if this was helpful (or not) for all your SPv4 candidates out there. The new blueprint is extensive, but trust me, Cisco has added this new content because it is valued in the SP industry.