Hour 726: My CCIE v5 lab experience

This morning I got my lab results and it looks like I’m not quite there yet. I failed the exam. It was close, but it wasn’t good enough. In this post, I will be going over my first CCIE R&S lab experience and what led to my failure.

Sunday morning I traveled to Toronto for my first lab attempt. My hotel was right in front of the Cisco testing center so I wasn’t too worried about getting there late the next morning. From the moment I stepped in that hotel, I knew something was shady. A bunch of people were smoking in front of the “Prohibited to smoke within 9 meters” sign, the elevator was half broken and my rooms phone wouldn’t dial-out. Oh well, I guess it was good enough for the money I paid. I went to bed pretty late that night as I wanted to be able to sleep without waking up from nerves. I set up my alarm for 7:45AM. Unfortunately, I was awoken at 6:15 AM by the hotels fire alarm. I woke up in panic and started getting dressed. By the time I was out the door, the alarm stopped. Needless to say, I didn’t go back to sleep after that.

I arrived at the testing center 30 minutes before the starting time. There was already another candidate there. He was also going for the CCIE R&S. There was only 4 CCIE candidates that day at the testing center. Three of them were R&S and one was SP. The proctor explained the rules and said we would start in 10 minutes. I was pretty annoyed as my chair wouldn’t stay in the upwards position. I know this sounds stupid but sitting for 8 hours in an uncomfortable chair makes a big difference.

I encountered my first problem before the exam even started. I turned on the screen at the Proctor’s signal and I was greeted with the message “Windows is now shutting down…”. The same happened to one of the other CCIE candidate beside me. Once the computer started, the screen resolution was set to 800X600. It took the proctor 7 minutes to fix it, restart my computer and get me logged in. This is when I started the TSHOOT section.

The TSHOOT section had many 2 pointers questions and only a couple of 4 pointers. The first question was really easy but for some reason the switch wasn’t behaving as expected. I knew what the problem might be from the symptoms I was getting but the interface where the problem should have been at was not showing any signs of misconfiguration like the other show commands were telling me. I spent around 10 minutes on this ticket and decided to reload the switch and come back to it later. When I came back to this problem later on I noticed that the “show run interface x/x” had a different output than the global “show run” command. Very weird… I entered the proper configuration commands at the interface level and verified with the “show run” instead of “show run interface x/x”. I could now establish reachability as requested by the ticket.

The rest of TSHOOT was fairly hard, several faults and the topology was complex and misleading at times. I will be honest, I probably spent half of my time trying to understand the topology and how all the technologies interacted with each other. At the end of the TSHOOT, I had fixed all faults but because of lack of time I didn’t fix it the way Cisco wanted me to. Let me explain. There are several ways you can fix a problem in TSHOOT but not all of them are the right one. For example, if there’s an ACL blocking a certain protocol you can either:

  1. Remove the access-group on interface
  2. Add a “Permit any any” on the ACL
  3. Modify the ACL to make the protocol and its dependencies work

Obviously the way Cisco wants you to fix it is to ” Modify the ACL to make the protocol and its dependencies work”. Due to lack of time, I couldn’t fix the tickets like Cisco wanted me to. At the time, I thought the way I did it would be good enough but now I know it wasn’t.

Diagnostic was pretty easy. There was a lot to read but as soon as I had finished reading the trouble tickets I had a good idea of what the problem was. I have nothing else to say about this section, I passed it and any CCNP should be able to do the same.

The configuration section was very long and the topology was very large. I understood all the core stuff but it became clear that I might run out of time if I didn’t go fast. We stopped for lunch and at that point I had completed half of the L3 connectivity parts. For lunch we had 2 slices of Pizza. I wasn’t really hungry but damn that was the most expensive 2 slices of Pizza I’ve ever had.

After lunch, I finished all the other parts of CONFIG except for one. I couldn’t understand what was the problem for the entire exam. I probably spent 30-45 minutes on this problem trying to figure it out. This part was critical as it was breaking 3 other sections of the exam. Now that I got my lab results, I know I failed because of this. I will have to lab it up to reproduce the problem but at this point I’m thinking there was a bug with the SP device that I didn’t have control over and it probably needed to be reloaded.

I believe I encountered several bugs during the exam (probably due to IOU memory problems) and had to reload the devices to fix them. Also, access to devices was very slow. I had to click and wait up to 15 seconds for the console to pop up. The DOC-CD was slow and sent me to “This page cannot be found” several times.

My overall impression of this exam was that the topologies were complex and sometimes misleading, the devices were buggy and the access was slow. I also think that the combination of all the events that happened to me that day made the exam harder than it actually was.

Next attempt will be in February/March at RTP I think… I will have to check but I’m taking a break for the next few days to re-focus on what I have to work on. I am really grateful for everyone that encouraged me and sent me hopeful wishes.

Thanks again to all my followers for your support, I will be posting new technology blogs soon and a review on all the material I’ve gone through.

Hour 710: One Week before the CCIE R&S v5 Lab exam

I would first like to apologize to all readers for not posting any blogs in almost 2 months. I have recently accepted a position as a Sr. Network Administrator at a HFT firm and I been extremely busy there as well as studying for the lab exam.

As some of you may know, I have the CCIE lab scheduled for next Monday, Dec 8th 2014 and this will be my last post before my attempt. Here is the list of all the material I have gone through since I started my CCIE journey about a year and a half ago.

Theory:

Routing TCP/IP Vol1-2

Cisco QoS, Exam certification guide

CCIE Routing and Switching version 4

MPLS Fundamental

Developing IP Multicast Networks Vol I

Internet Routing Architecture

DOC-CD

 

Lab Practice:

IPexpert CCIE R&S Lab v4 Workbook 1-3 (not all Workbook 3)

IPexpert CCIE R&S Lab v5 Workbook 2 Lab 1-2

INE CCIE R&S v5 Technology Workbook

INE CCIE R&S v5 Lab Workbook 1 – 2

Cisco 360 Labs 1-10

Pass or fail next week, I will be doing a review of each book/vendor material and how useful they were for the v5 Lab exam. Keep you guys posted!

CCIE

Hour 560: Solving redistribution loops

Route redistribution is a very important topic that every CCIE candidate should master before attempting their lab. In some scenarios when dealing with redistribution, one or multiple routing loops can occur. In the CCIE R&S lab, if a routing loop is possible then you can be almost certain that there will be one, so you better know how to deal with them. This post is meant to help people understand, identify and remove these loops from the network.

First, let’s start by breaking down the different kind of loops that you will see and the best tools to identify them.

Data-plane loops

This kind of loop is the easiest one to identify and can be seen when you have data constantly looping in your network until TTL expires. This can be for known or unknown traffic. “Known traffic” will be the traffic that you have a prefix in the RIB for and “Unknown traffic” will be for the traffic that only matches a default route. The best tool to identify these kind of loops is the traceroute or ping command. Sending ICMP packets to these prefixes will always fail and traceroute will clearly show a pattern of where the traffic is looping.

Control-plane loops

Control-plane loops are when you have routing information looping in the network. These are the most devious kind of loops because sending ICMP packets will not always help you to identify them. The reason for this is that the routing prefixes will sometimes be in a constant race to enter and be removed from the RIB between two protocols. The tool to identify these is actually running a “debug ip routing” on the redistribution routers. In a stable and loop-free environment, this debug command will be almost completely silent. However, if you are having control-plane loop problems, you will several debug messages indicating that routes being added and withdrawn from the RIB.

When can a routing loop occur?

Continue reading

Hour 505: Quick update, DMVPN’s and MPLS VPN’s

Quick update*

Writing blogs is very time consuming. I have probably spent over 100 hours putting together this website and I don’t include these hours in my  study count. Also, I have a 2 week bootcamp with IPexpert coming up in October and shortly after, I will be going for my first CCIE R&S lab attempt in Toronto. What i’m trying to say is that I might write one or two blogs before the exam but not more. I think I have covered pretty much everything in the blueprint of the CCIE except for MPLS VPN’s and DMVPN’s. These topics are covered in several books and blogs and I don’t feel the need to go over them again. I have a friend that is also studying for the CCIE R&S that gives a great overview of these. Check out his blog at https://fredrikjj.wordpress.com

Before I go, I want you guys to know that the CCIE is not about how smart you are. I know tons of people who are super smart and fail this exam. The CCIE is about heart. It’s about how much you are willing to push your limits. Check out this video.

 

 

Hour 475: GRE recursive routing

It’s been almost a year since I have been out of the military and I thought it would be a good idea to dedicate a blog to them. More specifically I want to do a technical blog on a type of problem I sometimes encountered while working there; GRE recursive routing. Any enterprise that runs tunneling protocols like GRE/IPSEC or VTI’s will most likely encounter these type of problems at one point or another.

First, I want to separate this post in two cases; Case A and Case B. They are different scenarios but their root causes are both the same.

Case A: Recursive Routing due to less specific route

Topo_VPN

In case A, we have a topology where R2 and R3 are VPN devices and R1 and R4 are routers running a GRE tunnel between each other sharing routing information through an IGP. Continue reading

Hour 465: Single-Rate Policers and Dual-Rate Three-color Policer

In class based policing there are three main classification methods used to manage traffic: the single-rate two-color policer, the single-rate three-color policer and the dual-rate three-color policer. It took me sometime to understand how these work as they are in my opinion, advanced QoS concepts. This being said, let’s do a quick review on the QoS traffic terminology and how the Token bucket concept works before we show how these different policers function.

**Please note that I am not going to go over the fundamentals of QoS. I will only do a quick overview of the terminologies that you should already know like the Tc, Bc and Be.

In a Cisco router, the IOS divides a single second into multiple sub-second intervals. Each of these intervals is called a Tc. In traffic shaping, a router can send a burst of traffic equal to the commited burst (Bc) during each of these intervals. Now in the Token bucket scenario, imagine a bucket and Tokens. Each token equates to 1 bit of information that can be sent into the bucket. The size of the Token bucket is defined by the commited burst value (Bc). There are two actions that can happen; either Tokens are replenished or Tokens are consumed. At the beginning of each Tc interval, the Token bucket will be replenished with Tokens equal to the value of the Bc. If the Token bucket is full or there is not enough room for all the replenished Tokens then some or all of the Tokens spill out. This is where the concept of the excess burst (Be) comes into play. In a scenario where there is an excess burst (Be) defined, these spilled tokens are not discarded and can be re-used. Continue reading

Hour 440: BGP Conditional Route Injection

BGP Conditional Route injection and Conditional Route advertisement are two of the more advanced BGP features that I have encountered in the CCIE R&S Lab. It is important to understand the difference between both of these. The first will INJECT a route based on a condition and the second will ADVERTISE an already existing route based on another condition. Also, the Conditional Route Injection feature is much more dangerous and complex to configure than the Conditional Advertisement one. Today, I will be presenting you a Case on why and how to configure BGP Conditional Route Injection.

Case A:

topo

Let’s pretend you are a customer that has a dual-homed ISP connection. You are currently receiving an aggregated route of 10.0.0.0/16 from both of these. You want to be able to route using BGP to the 10.0.0.0/24 and 10.0.1.0/24 prefixes through ISP1 and 10.0.3.0/24 aswell as 10.0.4.0/24 through ISP2. This would be pretty easy if you would have control over the ISP1 and ISP2 routers as you could ask them to unsupress these networks and receive them without having to change any configuration on your side. Unfortunately, the process of going through the ISP’s and asking them to change configurations takes too long and you need this done today. We will be using the Conditional Route Injection to be able to accomplish this. The configuration can be done in 5 steps: Continue reading