Archive for June, 2009

CCIE Routing & Switching Techtorial

Yeah, ok, so I’m a day late.. Deal with it!

I’m sitting here in the wonderful world of Cisco Live (aka Networkers) 2009 in San Francisco! Today is the first day of Techtorial and Labtorial sessions. I’ve been spending my time harassing various speakers and Cisco folks along the way, but generally having fun!

Today is the CCIE Routing & Switching Techtorial. l dropped in to see what all was new and exciting with the upcoming changes in the blueprint! We started off talking about the basic stuff that we all already know. The exam (both lab and written) is changing on October 18, 2009! The written exam for v4 will be in beta in August. So those who are looking for an inexpensive recert, watch for this! ($50!)

We also spent some time with the ideas about how CCIE exams are developed. At least the revised process therein. As I had spelled out in an editorial I did for Cisco Learning Network a while back (https://cisco.hosted.jivesoftware.com/docs/DOC-4888), the CCIE team is spending more time by analyzing job tasks and getting real-world input to figure out where the certification should be heading. It’s good to see this reiterated, but should also tell us that interesting changes may be forthcoming for ALL CCIE tracks, not just R&S!

Another good highlight was Maurilio Gorito (CCIE Program Manager for Routing & Switching) talking about test philosophy. “The routing and switching exam tests your ability to apply configuration knowledge, troubleshooting skills and skills to adapt to new situations. It is not a design test, nor is it always a test of ‘best practices’ for use in the field.”

We spent some time talking about the Core Knowledge questions as well, and it was resolved WITHOUT A DOUBT that these questions are currently worth 21 points and the rest of the lab is worth 79 points! Of course, there will be changes when it comes to the addition of Troubleshooting when the v4 blueprint becomes active, and no details were given about points then! (Still under construction?)

Going through the ethernet and frame-relay sections was tedious, but nothing has changed here. IGPs were relatively the same as well. There were a couple examples and interesting diagrams that were worthwhile, but this presentation was geared towards those getting started towards the CCIE, not those who already had it!

The vast majority of the day was dedicated to Ethernet, Frame-Relay, IGP routing protocols, IPv6 and BGP… At the end (when the caffeine was starting to wear off) were the newer topics like MPLS and MPLS-VPNs!

Most of the stuff was straightforward. Some new acronyms were thrown out, mostly to scare people! According to the blueprint, candidates are to be responsible for basic MPLS architecture, LDP interactions, VPNv4 address families as well as IPv4 unicast vrf address families.

In addition, it was clarified that candidates will be responsible for both Layer2 and Layer3 VPNs inside MPLS. But, before the panic ensues, there will be basic pseudowire connectivity (AToM or L2TPv3 are fair game) of ethernet to ethernet links. So we do not need to worry about L2 interworking. We also don’t need to worry about VPLS or H-VPLS due to IOS functionality!

Then we jumped back to old topics for IP Multicast! There was no mention about IPv6 multicast even though it’s on the v4 blueprint. Go figure.

The interesting part came in when talking about troubleshooting… There was a total of 6 slides about it. Not incredibly insightful, but at least there was discussion about the thought-process for troubleshooting generically! That just means we’ll have to stay tuned a little while longer for how best to approach these things (see future blog articles!).

You will be given a series of diagrams (overall network, IPv4 routing, BGP routing, IPv6 routing, or whatever’s appropriate for your lab) to set the stage for troubleshooting. Then you will be given a series of “Incidents”. A simple example given had to do with one router not being able to ping another router’s IPv6 address.

With that you would have to look at your diagram and start looking at router configurations or other show commands in order to further define the actual, underlying problem and then start determining solutions. The success of the troubleshooting section would rely (in this incident) on the two routers being able to ping each other from the interfaces specified.

The same kinds of rules apply in this as to the rest of the lab. No static routes, no default routes, no policy-based routing…. Unless otherwise specified!

One very interesting thing that was noted (good thing I waited because Monday’s session got this!) is that you “may” need to be aware of frame-relay switch configuration within the v4 blueprint. The pre-configured/backbone frame-relay switch will no longer be part of the standard rack configuration.

This turned out to be a session that wasn’t geared as a bridge to v4. It wasn’t geared to those well on their way of studying. It was set as an introduction and a little bit of tossed information about the thought-process for different tasks and what they ask versus what they expect.

All in all, things should be “interesting” with the v4 blueprint. The breadth of knowledge can be staggering, but on the other hand, we get to train everyone to be consultants!

57 people attended.

Now, this is posted about 1:15am, so I’m sure you can guess what all else has been going on. I was in the CCDE Techtorial today, so perhaps I’ll write that one up in the morning when my head clears!

Popularity: -0% [?]