CCDE Topic: docs I found useful

CCDE Topic: docs I found useful

Step One: the written (read this even if you already passed!)

I found the written outline to be the most useful preparation not only for the written exam, but also the practical.  I went through all of the topics outlined and made sure I understood exactly what they were trying to get at.  Honestly, there were a number of items I had never heard of, so doing the research felt like I was accomplishing something.  I’ve posted a few of the written items on this blog, like What is the issue with re-marking and OoO packets? and What is fate sharing, and what is its impact?.

If you want to see more about the security portion of the written outline, be sure to check out this post too.

In case you can’t tell, I’m saying that even if you passed the written easily, you probably want to go back & make sure you understand everything that’s covered on the outline.

Step Two: the practical

This is the difficult part, but I’ll try to give a summary of what I found most useful for me.  Of course, you may already be an expert in one of these topics and won’t need to review it (but you probably should anyway).

SRND:

High Availability Campus Network Design–Routed Access Layer using EIGRP or OSPF

Enterprise QoS Solution Reference Network Design

RFCs (in no particular order):

OSPF RFC2328
TCP RFC793
BGP RFC1771
GRE RFC2784
IS-IS RFC1195
BGP/MPLS RFC2547
Multicast RFC1112
DSCP RFC2474

e-Learning:

If you have access to the Partner Education Connection you’re in luck.  If not, your best bet is to check out elementK.  Your company may already have a subscription.  I’m sure there are others with equivalent training, but I’m speaking specifically about the path I took.

I took the online MPLS SE training, reviewed the Multicast training, and reviewed the EIGRP training.

I’ll go into the specific courses in a later post, as well as a book listing & the Cisco Live / Networkers materials I found useful.

CCDE certified, now what?

So it’s been a few weeks since learning that I passed the practical, and other than NOT having to attend the next practical in December, not much has changed. I think the marketplace is still trying to determine the value of this certification, and my feeling is that some employers may think it’s nothing more than a written exam. They’re right, of course, but it is a hard written exam. It remains to be seen just how / when employers will start to recognize the value. I think if the CCDE team published some statistics on the pass/fail rate it might help (along with the level of experience most taking it have), but I’m not holding my breath.

The path I took in studying for this exam made me a much stronger network engineer, and IMO that’s the whole point. Now the question will be whether or not others become stronger engineers in their pursuit of the CCDE.

Some people have emailed me asking how they should prepare for the practical, and I would say the following has been invaluable preparation for me:

1. Get a job where you’re tasked with maintaining & troubleshooting a production network.
2. Never be satisfied when something magically starts working – troubleshoot & solve real-world issues and find the root cause (wireshark is your friend).
3. Visualize how you would change the network to solve systemic problems with the network (and maybe even implement some changes).
4. Work with the applications people to help them understand how the network affects their applications (and vice-versa).
5. Become the ‘buck stops here’ person, meaning that if you cannot solve the issue, nobody can. You need to take ownership of the entire system – don’t pass off issues to the applications people / server people.

In short: you cannot just have book knowledge to pass this exam, you will need real-world experience troubleshooting and designing solutions to solve systemic problems. If you gain this experience, you won’t need the CCDE to prove your level of knowledge, your CV will speak for itself.

My background is in UNIX systems administration, networking, and security. I’ve also worked in several industries including Financial Services, SP, and DoD. I worked in small companies where I was in charge of everything, and large organizations where I was in charge of just one small part of the network. In all cases, I knew not just what I was responsible for, but all (or most) of the applications and systems running within the system. Personally, I believe this experience was key preparation for the CCDE. You need to understand real-world design issues, not just the best practice picked up from reading in a book. You need to never be satisfied with the design either – always look for ways to improve it. This quote from fellow blogger Jeremy Filliben sums it up nicely:

“When I take two eggs out of the carton, I take one from each row. It isn’t more correct, but it makes me feel better.”

Isn’t that the whole point anyway? If you have a passion for this stuff it will show, and you will be rewarded with an infinite number of interesting problems to solve.

Share/Save/Bookmark

CCDE 20090006

Yesterday I received the letter from VUE confirming my pass of the CCDE practical exam: 352-011. I am now CCDE #20090010. At least according to VUE – the Cisco site is still not updated with a number. Correction: the Cisco site was updated with a number (20090006). The results were mailed on 11/13/2009 so it’s taken at least 3 days to update the Cisco system.

Needless to say, I’m thrilled.

I will begin posting some info on my path in the hopes that it will shed some light on the process for others. I will say, it certainly helped that I had the requisite 10 years of industry experience before attempting the practical. It may be possible without this, but the breadth is wide enough, and the depth just deep enough that you can’t really study for this exam.

That being said, I did study for it, and learned quite a bit over the last year and a half of reading & watching VoDs. The reading list is good (and yes, I recommend you read all of them), but there are a few books that should be highlighted:

Definitive MPLS Network Designs
Optimal Routing Design

I’m old enough to remember reading (several times) the precursor to Optimal Routing Design : Advanced IP Network Design, which is not on the reading list, but I recommend with the caveat that not all of the material is relevant anymore.

This gets into one of the most difficult parts of any exam: ignoring or realizing what is no longer relevant.

Anyway, thanks everyone for the congratulations, and keep tuned in for more.

Share/Save/Bookmark

What is the issue with re-marking and OoO packets?

This question, taken from the CCDE Written Outline, taught me something new. Since that’s the purpose of any certification, I welcome these interesting, if somewhat vague, questions.

The main issue with re-marking and Out-of-Order packets can be found in RFC3819: (aka BCP89)

reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC 2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP’s sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers.”

In English, this means that if your Service Provider is doing any sort of re-marking (with a traffic policer, for example) your TCP flows may suffer due to re-ordering within the network. Let’s say your SP provides a subrate Ethernet attachment circuit to you at 10Mbps. You’re permitted to go over this rate but your traffic will be classified as less-than-best-effort (COS=1). You begin transmitting a large PDF via FTP. Once your flow goes over the committed rate, it was remarked to COS=1. Next, those packets are delayed within the core through a shaping mechanism (realizing that in the real world, less-than-best-effort would most likely be policed). Anyhow, the packets are delivered out-of-order due to this shaping policy. Meanwhile, the TCP session established by FTP notices segments are arriving out-of-order and performs the fast retransmit algorithm. This causes your FTP transfer to slow down during the transfer.

Now that we know this, how will it influence our design?

The first and most obvious result would be to configure an outbound shaping policy to match the SP’s subrate Ethernet AC. In general, reordering is not something that we can design for, as once we hand-off the packet to the provider we cannot control the path it takes. Within our own network, we can reduce the number of paths a packet takes by using traffic engineering or reducing the number of equal-cost links. Within Cisco devices, CEF attempts to ensure the same path is taken by using a hash of the socket information. This is one of the reasons equal-cost paths may not show equal utilization.

I failed the CCDE… now what?

I checked the online certifications tracking tool and found out that I have failed my first attempt at the CCDE. What does this mean to me, and what am I going to do about it now?

I’ve already registered to sit for the next practical exam in August (Chicago, IL). This leaves me with roughly 4 months to prepare for the next attempt. While balancing other work obligations that cause me to learn fairly unrelated topics, how will I study and what will I study until then?

I’m going to review the SRND documents posted on CCO. I really haven’t given these a serious chance, with the limited exceptions of the document: Layer 3 Routed Access Layer, and Enterprise QoS. Both documents were useful, and I’m sure there are more useful SRND documents that I need to look at.

I’m going to reread Optimal Routing Design and Definitive MPLS Network Designs.

As everyone knows who has been preparing for this exam – it’s exceedingly difficult to study for, so that’s my tentative plan. I will most likely cram more material in there over the next 4 months, but it’s going to be very difficult as there are several competitive forces for my time. Specifically, summer in San Diego is going to be nice (as usual) and I’m currently supporting a major wireless deployment that has my time solidly booked up.

Regardless, I’m disappointed I didn’t pass the CCDE, but excited to deepen my understanding of network design.

Share/Save/Bookmark

IS-IS, MPLS-TE, and wide metrics

I came across an interesting topic in the book Traffic Engineering with MPLS yesterday. The topic involves migration from narrow to wide metrics. As you know, wide metrics are required to support MPLS TE, so if you have a network that is currently deployed with narrow metrics (the default) you will have to migrate to the wide metric style. You may even have devices that only support narrow metrics, so you’ll have to figure out what to do with them in the meantime – perhaps they won’t be in the path of TE tunnels, so you might not need to replace/upgrade them immediately. Anyway, starting on page 465, the book details two procedures to migrate from narrow to wide metrics:

  1. migrating from narrow to wide metrics in two steps
  2. migrating from narrow to wide metrics in three steps

Why the difference in steps? Well, the first one involves enabling all routers to advertise & accept both styles of metrics, which will increase the size of your LSDB by roughly 2x. The three step program takes longer but does not require the same amount of memory.

Here’s a good link from cisco referenced in the book. Transitioning IS-IS to a New Technology

Share/Save/Bookmark

Took the CCDE Practical Exam Today

14 people in Chicago and 14 people in London took the test today.

First impressions:

1. It’s very, very difficult
2. I don’t think it’s “impossible”

However, I will caveat this with – I don’t really think I have a chance at passing.

In all, I had fun taking it. I’m mostly relieved to have had a chance to finally see what it was all about. I think Cisco has done a good job with this test.

There’s nothing I can say that has not already been posted/said before. If you haven’t gotten a chance, you should check out the demo posted on the Cisco learning network.

Now I wait – 6 to 8 weeks – for the results.

Share/Save/Bookmark