CCDE Practice Exam Offering

I am breaking from my normal technology writing to unveil a new CCDE Practical practice exam opportunity.

What Is It?

This CCDE practice exam offering is intended to replicate the style and difficulty of an individual scenario presented during the CCDE Practical Exam (352-011).  Each scenario begins with a multi-page overview document, followed by up to 25 technical questions and additional documents.  The questions are in the style of actual CCDE Practical exam questions, similar to those found in the CCDE Practical Demo on Cisco Learning Network.  I am limiting this offering to a small number of candidates for this initial attempt.

What Is It Not?

This is not an actual graded exam.  It did not come from Cisco, and was not used during a real CCDE exam.  This exam was also not built using the Adobe Flash engine.  It is delivered via PDF.  The question styles and the technical difficulty of the questions closely follows the actual exam, but none of these questions will be found on an actual exam.  In other words, no NDAs were violated during the construction of these exams.

What Will You Receive?

Two days before the scheduled Webex session you will receive an email with two attachments.  The first is an overview of the CCDE Practical Exam.  It describes the exam environment, the structure of the exam and the types of questions you will receive during the exam.  You will also receive guidance on how to complete the practice exam.  For example, this exam is intended to be closed book.

The second attachment is the practice exam scenario, in PDF format.  At the current time, there are four different practice exams available, each consisting of approximately twenty questions.  Two of the exams are Enterprise-based, and two are focused on a Service Provider network.  All CCDE candidates registering for a specific practice exam session will receive the same exam.  The exam is intended to take 60 to 90 minutes to complete. 

The last item you will receive is a login id/password for the three hour exam review session.  The date and time of the session is clearly listed on the Eventbrite registration page.  Due to my schedule, I will be unable to offer multiple review sessions for the same exam.  Please be certain to clear your schedule for the duration of the review session.  If an illness or unforeseen emergency prevents an individual from attending the review session we will make an effort to schedule a second session, but I cannot guarantee my availability.  During the review session we will work our way through the exam and I will show you where to find the information to correctly answer each question.  This review session is intended to be highly interactive.  Candidate questions are encouraged and expected… I want you to challenge my answers and assumptions.

Pricing and Registration

A single practice exam is priced at $695 (US Currency).  A pair of practice exams is priced at $995.  Due to limited timing before the next CCDE Practical offering (scheduled for Friday, November 12th), I will only be able to offer two practice exams at this time.  To appeal to the widest audience, I have chosen one Enterprise exam and one Service Provider-based exam for this offering.  The Enterprise exam will be distributed to registered candidates on Tuesday, November 2nd and reviewed on Thursday, November 4th from 9am to noon (Eastern US Time Zone).  The Service Provider exam will be distributed to registered candidates on Friday, November 5th and reviewed on Tuesday, November 9th from 9am to noon (Eastern US Time Zone).

The Practice Exam Registration pages can be found at the following links:

Single Enterprise Exam

Single Service Provider Exam

Both Practice CCDE Exams

Why Am I Doing This?

The number one complaint I’ve heard about the CCDE program is the lack of practice opportunities for the practical exam.  Cisco did a great service to the candidates by publishing a sample exam on Cisco Learning Network.  Without it I would have struggled greatly with the format of the exam. But Cisco’s demo exam does not even begin to represent the amount of reading or the depth of the technical questions on the actual test.  My practice exam offering replicates the actual exam’s technical depth and ambiguity.  Those candidates who have already sat for the practical exam know what I mean by this!  :)

I have taught several week-long CCDE Practical courses for a well-known Cisco Learning Solutions Partner.  They have been very rewarding experiences for me, and based on the feedback, for the students too.  While I fully intend to continue teaching that course, I also want to offer a resource for candidates who cannot take a week-long break from their normal lives to prepare for this certification program.  If you have recently taken the full week training offering, you are already familiar with the two exams included in this specific offering.  They have been updated based on the students’ feedback and comments.

Additional Information

I am limiting these events to a small number of participants.  It isn’t clear to me how many candidates I can include in a single WebEx session while maintaining the interactive nature of the event.  I may increase the enrollment for future offerings, depending on how well this initial attempt goes.

If you have any questions about this opportunity, please email me at jeremy@filliben.com, or post a comment to this post.

A Comparison of Current Spanning-Tree Elimination Strategies

As I mentioned in the last post, I attended the Net Tech Field Day event hosted by Gestalt IT in September. My focus in attending was on Data Center switching technologies. Of particular interest to me was the methods by which each vendor is attempting to eliminate spanning-tree from the data center. While I have been keeping my eye on TRILL and 802.1aq, I am more interested in how vendors are solving this issue today.
All of the current solutions can be described as Multi-Chassis Link Aggregation (MLAG) methods. Cisco has three solutions available for this purpose. The 3750 and 2975 switches perform chassis aggregation via proprietary stacking cables. This stacking feature allows a network engineer to create a single switch out of multiple physical devices. All devices in a stack are managed via a single control plane. Cisco’s 6500 series switches have a similar feature, called Virtual Switching System or VSS, which uses standard 10gb interfaces to achieve the same result. At the current time, VSS is limited to aggregating two chassis, but Cisco’s goal is to extend this to more devices. On the Nexus 7k and 5k platforms, the virtual Port-Channel (vPC) feature allows two physical devices to be logically paired together to present a common switching platform to connected devices. The important difference between vPC and the Stacking/VSS methods is that the control planes of the vPC devices are separate.
Juniper and HP both described their visions of a single control plane for the data center. Juniper went into great detail about their stacking technology (called Virtual Chassis) for fixed-configuration switches, as well as their standard Ethernet-based method for interconnecting modular switches. HP was less technical in their presentation. By my best guess, they have a VSS-style Ethernet interconnection method.
Force10’s VirtualScale technology combines the control planes of two or more switches to offer MLAG. The connections between the switches are standard 1 or 10gb links.
According to Arista Networks, their MLAG solution can pair two switches into a single logical switch. It isn’t clear from the documentation whether this feature combines the two control planes or keeps them separate. The configuration documentation is behind a paywall :(
Here’s a table of the vendors and where their solutions reside:

	Proprietary Stacking	1/10gb Stacking	Separated Control Planes
Arista Networks		X
Cisco Systems	X	X	X
Force10		X
Hewlett-Packard	?	X (I think)
Juniper	X (I think)	X

My Thoughts

I am not yet comfortable with combining control planes in a data center environment. I much prefer Cisco’s vPC method of spanning-tree elimination over the stacking and VSS methods. There are several factors that contribute the this point of view. First, I was bitten by a VSS bug about 18 months ago. I suppose I should chalk that up to being an early adopter, but I guess I hold a grudge :)
Second, the shared-fate aspect of a single control plane makes me uncomfortable. When I strive to eliminate single points of failure in the data center, I look for the following items:

1. Single-Attached Servers – If a server owner chooses to take this risk, I am not responsible for the impact of a switch or cable failure.
2. Port-Channel Diversity – I work to ensure that single-device to single-device port-channels are built using separate modules on chassis-based switches. I also attempt to diversify the cable paths. For example, I’ll run one cable of a port-channel up the left side of a rack, and the diverse cable up the right side. If the opportunity presents itself, I’ll utilize a mix of copper and fiber in a single port-channel for an extra level of comfort, although I’ll admit that this is excessive in typical Data Centers.
3. Power Diversity for Paired Switches – When two switches are configured as a pair (for example, when individual servers are connected to both switches), I ensure that they are powered by different PDUs, or are at least on different UPSs. if separate UPSs are unavailable, it is preferable not to have the second switch on a UPS at all. To look at it another way, I’d rather have a single switch up for 30 minutes, versus a pair of switches up for 15 minutes. While I haven’t implemented this idea in my data centers, I am intrigued by it as a method for reducing the load on our Data Center UPSs. (The same goes for servers performing duplicate functions, if sysadmins are still reading this).
4. Control-Plane Diversity – If a single reload command can take down my entire data center (even momentarily), I don’t quite have diversity. I’ve heard the “Operator error is the cause of most IT downtime” mantra often enough for it to have sunk in, at least a bit. If the reload command doesn’t concern you, think about how a simple configuration error would no longer be isolated to a single switch.

I’ll stop the list here, but there are probably many others I haven’t listed. Feel free to mention your favorites in the comments and I’ll add them here with appropriate credit.