CCIE Lab at a location near you!!

Cisco Certification Testing

April 2010

Register now to take a Cisco CCIE exam being offered during April 2010 at 20 Pearson VUE Professional Test Centers around the world.

Seating is limited and is on a first-come, first-served basis—please register today online or call the Pearson VUE Customer Service line at 877-404-EXAM / 877-404-3926 (Monday–Friday, 7:00 a.m.–7:00 p.m. CT).

Online Registration

If you do not already have a Pearson VUE username and password, you will need to create a web account before continuing. If you have tested before with Pearson VUE and are not sure if you have a username and password, or the one you thought you had does not seem to be working, please call 1-877-404-3926 for immediate assistance (Monday–Friday, 7:00 a.m.–7:00 p.m. CT).

Find your nearest test center to register online:

City	Date		City	Date
Bangalore #45, 3rd Floor, Trade Center	7-Apr		Montreal 7705 17th Avenue	7-Apr
Beijing Rm 1153, New Century Hotel Office Tower	10-Apr		Mumbai Building No.9, 1st Floor	9-Apr
Chicago 200 West Adams Street	8-Apr		Raleigh 8024 Glenwood Ave	8-Apr
Dallas 12801 North Central Expresswat	8-Apr		San Jose 1551 McCarthy Blvd	7-Apr
Delhi 18,Ramnath House	7-Apr		Sao Paolo Rua Helena, 260 – sala 33 – 3º. Andar	8-Apr
Frankfurt 62 Bettinastrasse	9-Apr		Seoul 6th Floor, Kolon Building	13-Apr
Guangzhou Rm.1212, 12/F., Jie Tai Plaza	9-Apr		Shanghai Rm.1001, 10/F., Asia Mansion	9-Apr
Hyderabad	9-Apr		Singapore International Plaza	8-Apr
Istanbul SÜLEYMAN SEBA CAD. NO: 48	8-Apr		Sydney Level 6, 287 Elizabeth Street	13-Apr
London 190 High Holborn	19-Apr		Tokyo 4th Floor, Kojimachi Shimura Building

Ref: http://www.pearsonvue.com/cisco/ccie/

New CCIE SP Track Announced!

Okay, this is a strange turn of events – Steve.

Cisco CCIE SP Operations

The Cisco CCIE SP Operations certification assesses and validates core IP NGN service provider operations expertise. Candidates who pass the CCIE SP Operations certification exams demonstrate skills required of a expert-level (Tier III or Tier IV support) operations engineer to troubleshoot and maintain complex service provider IP NGN core (PE-PE and PE-CE) network infrastructures in both IOS and IOS XR operating environments, plus validate broad theoretical knowledge of operations management processes, frameworks, and network management systems.

CCIE SP Operations Certification benefits:

• Certification helps qualify personnel for customer’s Operations (NOC) Centers
• Provides a credential (certification) that a person holds significant knowledge in SP Operations
• Provides expert level certification to network operations (i.e. NOC) personnel to validate they are qualified to maintain and support Cisco service provider core IP (NGN) Next Generation Networks

Note: CCIE SP Operations Written Exam is scheduled for release in the second quarter of 2010.  The practical exam is scheduled for release in the third quarter of 2010.  To prepare for the written exam review the CCIE SP Operations

Prerequisites

Strong technical skills are assumed at the expert level, and CCIE candidates are encouraged to use Cisco authorized training to fill any gaps, before attempting certification. CCNA and CCNP focus on developing a solid foundation and are strongly recommended as a path to CCIE, but are not mandatory prerequisites.

Required Steps to Attain Certification

Candidates must first pass a written qualification exam and then the corresponding practical exam.

You are expected to have an in-depth understanding of the topics in the exam topics and are strongly encouraged to have three to five years of job experience before attempting certification. You can review the exam preparation materials included on this page for more information.

Ref: https://learningnetwork.cisco.com/community/certifications/ccie_sp_operations

OT: CCIE gone wrong?

Last Sunday, Terry Childs, a network administrator employed by the City of San Francisco, was arrested and taken into custody, charged with four counts of computer tampering. He remains in jail, held on US$5 million bail. News reports have depicted a rogue admin taking a network hostage for reasons unknown, but new information from a source close to the situation presents a different picture.

In posts to my blog, I postulated about what might have occurred. Based on the small amount of public information, I guessed that the situation revolved around the network itself, not the data or the servers. A quote from a city official that Cisco was getting involved seemed to back that up, so I assumed that Childs must have locked down the routers and switches that form the FiberWAN network, and nobody but Childs knew the logins. If this were true, then regaining control over those network components would cause some service disruption, but would hardly constitute the “millions of dollars in damages” that city representatives feared, according to news reports.

Apparently, I wasn’t far off the mark. In response to one of by blog posts, a source with direct knowledge of the City of San Francisco’s IT infrastructure and of Childs himself offered to tell me everything he knew about the situation, under condition that he remain anonymous. I agreed, and within an hour, a long e-mail arrived in my in box, painting a very detailed picture of the events. Based on this information, the case of Terry Childs appears to be much more — and much less — than previously reported.

A Man and His Network

It seems that Terry Childs is a very intelligent man. According to my source, Childs holds a Cisco Certified Internetwork Expert certification, the highest level of certification offered by Cisco. He has worked in the city’s IT department for five years, and during that time has become simply indispensible.

Although Childs was not the head architect for the city’s FiberWAN network, he is the one, and only one, that built the network, and was tasked with handling most of the implementation, including the acquisition, configuration, and installation of all the routers and switches that comprise the network. According to my source’s e-mail, his purview extended only to the network and had nothing to do with servers, databases, or applications:

“Terry’s area of responsibility was purely network. As far as I know (which admittedly is not very far), he did not work on servers, except maybe VoIP servers, AAA servers, and similar things directly related to the administration of the network. My suspicion is that you are right about how he was “monitoring e-mail”; it was probably via a sniffer, IPS, or possibly a spam-filtering/antivirus appliance. But that’s just conjecture on my part.”

Like many network administrators who work in the rarified air of enterprise network architecture and administration, Childs apparently trusted no one but himself with the details of the network, including routing configuration and login information. Again, from the source’s e-mail:

“The routing configuration of the FiberWAN is extremely complex. Probably more so than it ought to be; I sometimes got the feeling that, in order to maintain more centralized control over the routing structure, [Childs] bent some of the rules of MPLS networks and caused problems for himself in terms of maintaining the routing.

“Because the system was so complex (and also because he didn’t involve any of the other network engineers in his unit), Terry was the only person who fully understood the FiberWAN configuration. Therefore, to prevent inadvertent disruption of this admittedly critical network, he locked everyone else out. I know most of the networking equipment … does use centralized AAA, but I get the impression he may have configured the FiberWAN equipment for local authentication only.”

Childs’ attitude toward other administrators is by no means unusual in the IT industry. This is generally due to the fact that admins who are tasked with constructing and maintaining networks of this size and scope care for them like children, and eventually come to believe that no one else could have the knowledge and skills to touch the delicate configurations that form the heart of the network.

Sole Administrator

A key point made in the e-mail is that Childs’ managers and co-workers all knew that he was the only person with administrative access to the network. In fact, it was apparently known and accepted in many levels of the San Francisco IT department. Again, quoting from the e-mail:

“This is where it gets tricky for the prosecution, IMO, because the localized authentication, with Terry as sole administrator, has been in place for months, if not years. His coworkers knew it (my coworkers and I were told many times by Terry’s coworkers, “If your request has anything to do with the FiberWAN, it’ll have to wait for Terry. He’s the only one with access to those routers”). His managers knew it.

Other network engineers for the other departments of the City knew it. And everyone more or less accepted it.

No one wanted the thing to come crashing down because some other network admin put a static route in there and caused a black hole; on the other hand, some of us did ask ourselves, “What if Terry gets hit by a truck?” If a configuration is known and accepted, is that “tampering”?”

My source appears to believe that Childs’ motivation was the antithesis of tampering, and that Childs did everything possible to maintain the integrity of the network, perhaps to a fault:

“He’s very controlling of his networks — especially the FiberWAN. In an MPLS setup, you have “provider edge” (PE) routers and “customer edge” (CE) routers. He controlled both PE and CE, even though our department was the customer; we were only allowed to connect our routers to his CE routers, so we had to extend our routing tables into his equipment and vice versa, rather than tunneling our routing through the MPLS system.”

Like so many other high-level network administrators, Childs seems to have taken his job extremely seriously, to the point of arrogance and perhaps to the point of burnout.

“Terry was very dedicated to his career as an engineer. He is a CCIE (probably the only one in the City government), and spent much of his free time studying and learning more — the MPLS for the FiberWAN, VoIP some of the departments are rolling out, other new technologies for our 311 and E911 systems, etc. He worked very hard, evenings and weekends in addition to full-time 8-5 work, and rarely took vacations. His classification is “professional,” so he doesn’t earn overtime pay, only comp time — which like many of us he never really had the opportunity to use. He was on standby more or less 24-7-365; whereas in the private sector, in a company of 20,000 or more employees, you’d expect to find multiple engineers rotating that standby status, I’m pretty sure he was always the guy on call.”

This attitude is, again, not uncommon among high-level IT administrators. Neither is the fact that they tend to eschew what they perceive to be unnecessary questioning and bureaucratic “nonsense.”

“Terry also, obviously, had a terrible relationship with his superiors. I should point out that he’s not just a network engineer — he was the lead network engineer for the entire City. His bosses were all managerial rather than technical, and while the other engineers did not actually report to Terry, they did defer to him in any technical matters. Even the network architect left it to Terry to actually figure out implementation. Terry felt that his direct superior was intrusive, incompetent, and obstructive, and that the managers above him had no real idea of what was going on, and were more interested in office politics than in getting anything done.

“[Childs] complained that they spent more time doing paperwork — change requests, documentation, etc. — than actually implementing or fixing anything (a common complaint among engineers, I know). He complained about being overworked (which he was, and which his colleagues are even more now) and that many of his colleagues were incompetent freeloaders (also not entirely without basis).

“You could see him getting red in the face whenever he started talking about his department. And once you were on Terry’s bad side (which thankfully I never was), that’s where you stayed, and you’d get only the most grudging assistance from him from then on. Whether any of his complaints were valid or not, I can’t really say, but I don’t think that’s as relevant as how Terry felt.”

Keys to the Kingdom

If Childs’ sole proprietorship of the FiberWAN network was normal operating procedure, how did the tensions between Childs and his managers come to a head? Why was Childs arrested on Sunday? There have been reports that the city’s newly-hired head of security may have pushed for Childs to open the FiberWAN doors to other admins. My source doesn’t know for sure, but offers some insight:

“I don’t know much about his actions in the last few weeks. It’s been a couple of months, at least, since I’ve even spoken to him, and even then it was probably only in reference to some specific request or ticket. But I can imagine that being the subject of disciplinary action by his supervisors for “performance” issues would be absolutely infuriating to him. I can imagine that his response would be, “How can you say my performance is poor when I’ve been doing what no one else here was willing or able enough to do?”

If Childs was pressured to give up the keys to the network that he had built and cared for so long, would he go so far as to explicitly prevent anyone else from tinkering with his charge?

“I can imagine that [Childs'] response to a demand to open up authentication to the FiberWAN would be, “Why? So you can screw it up and bring the Citynetwork crashing to a halt?” I can even imagine that, under so much pressure, he’d take steps (deleting or hiding config backups, for instance) to make sure he was the only one in control.”

These tales offer significant insight into what may have occurred between Childs and the FiberWAN network hostage situation. Rather than a case of a rogue administrator attempting to cause damage to the network by locking out other administrators, this may be a case of an overprotective admin who believed he was protecting the network — and by extension, the city — from other administrators whom he considered inferior, and perhaps even dangerous. One important fact seems to be in Childs’ favor, if reports that the network has continued to run smoothly since his arrest are true.. My source corroborates this.

“As for the impact of [Childs'] actions to the rest of the City, the mayor’s statement basically has it right. The network is completely up and running. No servers that I’m aware of are affected. No one has had any downtime (yet). But until they get back into those routers, they can’t make any changes. I don’t know yet if Terry’s lockout applies only to the FiberWAN or also to the other routers, firewalls, switches, etc. in the City network.”

“It’s a real shame. The city is losing a good network engineer — probably the best, technically, that they’ve ever had. Ultimately he has no one to blame but himself, but it’s too bad his superiors weren’t better about establishing and enforcing policies about authentication, backups, auditing, cross-training, and separation/rotation of duties.

“You’ll note the papers have referred to the new information security manager. It’s only been a month or so since the City even had an information security policy, and even that is a bare, unmodified template from CCISDA that’s awaiting discussion and alteration by a committee that hasn’t been formed yet. (When I asked Terry if we could get a copy of the City’s network security policy some months ago, he told me, “I’ve been trying to get them to approve one for years. I’ve written ones up and submitted them, but they don’t want to do it, because they don’t want to be held to it.”)”

He also points out that by forcing the issue, the city may have significantly reduced its ability to use and control its own network.

“The one impact they haven’t mentioned is that Terry was one of only two engineers assigned to special projects and to do major routing changes and perimeter firewall configuration. The service level, even after they regain control of the network, is going to be way down, until they can fill his mighty big shoes.”

My source had many good things to say about Childs, but did not shy from negative comments, noting that Childs has a bad temper and can be very defensive.

“As for Terry’s character, I can imagine this happening. He takes great personal and professional pride in his work — to a fault. He can be very defensive if someone suggests there’s something wrong with the way his network is set up, and that’s been a problem for us (as his customer) a couple of times. Terry has a bad temper.

“He’s the sort of person who, while his bile is up, won’t budge an inch — and then will call you a couple of hours later and acknowledge that maybe your suggestion was right, after all, or maybe here’s an even better way to handle things.”

The Inner Sanctum

Later in the e-mail, my source offered some insight into what may be at the core of the issue: Childs was so paranoid about the security of the network that he even refused to write router and switch configs to flash, which would mean that if the device was powered off, all configurations would be lost.

“At one point he was concerned about the security of the FiberWAN routers in remote offices, so he had them set up without saving the config to flash. “If they go down, I’ll get alerted, and connect up to them and reload the config.” Great, except we have power outages all the time in this city, some of those devices aren’t on UPSs, and what happens if you’re on vacation? And what about the 15 to 60 minutes it might take you to connect up and reload? He eventually conceded and (ahem) decided that disabling password recovery was sufficient security.”

If Childs did this with some or all of the switches and routers comprising the FiberWAN network, then password recovery without significant network disruption becomes a bigger problem. Without first-hand knowledge of the state of those routers and switches, there’s no good way to know, unfortunately.

If the details given to me in this e-mail are accurate, it would appear that this case is not nearly what it seemed originally. Perhaps it comes with the pressure and responsibility of the job, or the belief that the network they’ve built is simply too complex for mere mortals to comprehend, but it’s not uncommon for highly skilled network administrators to become overprotective of their networks, or for networks of significant size to become an extension of the person who built them.

It certainly appears that Terry Childs believed San Francisco’s FiberWAN network was his baby, and that by refusing to allow others to access the inner sanctum was in the best interests of the city, the citizens, and perhaps most importantly, himself.

“It’s a real shame. The city is losing a good network engineer — probably the best, technically, that they’ve ever had. Ultimately he has no one to blame but himself, but it’s too bad his superiors weren’t better about establishing and enforcing policies about authentication, backups, auditing, cross-training, and separation/rotation of duties.

“You’ll note the papers have referred to the new information security manager. It’s only been a month or so since the City even had an information security policy, and even that is a bare, unmodified template from CCISDA that’s awaiting discussion and alteration by a committee that hasn’t been formed yet. (When I asked Terry if we could get a copy of the City’s network security policy some months ago, he told me, “I’ve been trying to get them to approve one for years. I’ve written ones up and submitted them, but they don’t want to do it, because they don’t want to be held to it.”)”

He also points out that by forcing the issue, the city may have significantly reduced its ability to use and control its own network.

“The one impact they haven’t mentioned is that Terry was one of only two engineers assigned to special projects and to do major routing changes and perimeter firewall configuration. The service level, even after they regain control of the network, is going to be way down, until they can fill his mighty big shoes.”

My source had many good things to say about Childs, but did not shy from negative comments, noting that Childs has a bad temper and can be very defensive.

“As for Terry’s character, I can imagine this happening. He takes great personal and professional pride in his work — to a fault. He can be very defensive if someone suggests there’s something wrong with the way his network is set up, and that’s been a problem for us (as his customer) a couple of times. Terry has a bad temper.

“He’s the sort of person who, while his bile is up, won’t budge an inch — and then will call you a couple of hours later and acknowledge that maybe your suggestion was right, after all, or maybe here’s an even better way to handle things.”

The Inner Sanctum

Later in the e-mail, my source offered some insight into what may be at the core of the issue: Childs was so paranoid about the security of the network that he even refused to write router and switch configs to flash, which would mean that if the device was powered off, all configurations would be lost.

“At one point he was concerned about the security of the FiberWAN routers in remote offices, so he had them set up without saving the config to flash. “If they go down, I’ll get alerted, and connect up to them and reload the config.” Great, except we have power outages all the time in this city, some of those devices aren’t on UPSs, and what happens if you’re on vacation? And what about the 15 to 60 minutes it might take you to connect up and reload? He eventually conceded and (ahem) decided that disabling password recovery was sufficient security.”

If Childs did this with some or all of the switches and routers comprising the FiberWAN network, then password recovery without significant network disruption becomes a bigger problem. Without first-hand knowledge of the state of those routers and switches, there’s no good way to know, unfortunately.

If the details given to me in this e-mail are accurate, it would appear that this case is not nearly what it seemed originally. Perhaps it comes with the pressure and responsibility of the job, or the belief that the network they’ve built is simply too complex for mere mortals to comprehend, but it’s not uncommon for highly skilled network administrators to become overprotective of their networks, or for networks of significant size to become an extension of the person who built them.

It certainly appears that Terry Childs believed San Francisco’s FiberWAN network was his baby, and that by refusing to allow others to access the inner sanctum was in the best interests of the city, the citizens, and perhaps most importantly, himself.

Ref: http://www.pcworld.com/businesscenter/article/148669-1/the_story_behind_san

Cisco Web Site Confirmation of SP OEQ.

Update to the CCIE Lab Question Format and Scoring

Effective January 4, 2010, CCIE Service Provider lab exams will begin with a brief Core Knowledge section consisting of four questions requiring a short typed response, generally no more than four or five words. Candidates have up to 30 minutes to complete the four questions and may move on to the rest of the exam if they finish early. No access to the Cisco documentation is provided during this part of the exam and candidates may not return to the Core Knowledge questions once they have moved on. Core Knowledge questions cover material from the list of exam topics and well-prepared candidates should be able to answer the questions without difficulty. All candidates must pass the Core Knowledge section in order to achieve CCIE certification.

Ref:  http://www.cisco.com/web/learning/le3/ccie/sp/lab_exam.html

Communications Management

One of the biggest issues I have seen time and again on projects is communications management or lack thereof. The Cisco Announcement or lack of, for the CCIE SP Lab is a prime example again of this. Many candidates have received the official email but there is no notice here => http://www.cisco.com/web/learning/le3/ccie/announcements/index.html

Putting my project manager hat on for a second and this causes confusion. The same can be said for ISP’s. On many occasions tickets would be raised with the ISP, say area office WAN performance issue for example. Ticket gets raised with the Customer Service Desk who subsequently log a ticket with their ISP counter parts, call gets passed onto the ISP line team, their job is looking after the circuits themselves, tail circuits, local loops, etc. They begin to look at the problem, meanwhile the support manager of the customer calls his CRM [Customer Relationship Manager] in the ISP looking for an update. The CRM gets in touch straight away with the lead engineer who knows the customer\site well and gets on the CE\PE’s looking at outputs. He diagnosis a QoS marking that has been completed incorrectly and makes the change required. The customer suddenly sees their backup\AV rollout\file transfer\application\whatever suddenly increase in speed. Case solved or is it? The customer service desk is sometimes unaware that the issue is resolved so they contact their counterparts in the ISP who contact the line team who are still trying to figure out the issue -> confusion.

My Solution? Single points of reference – owners if you will, both on the ISP and Customer Side. They own the call from it’s inception through to resolution and issue RFO [Reason for Outage] reports post call resolution. All communications such as verbals\mails\etc go through them or they are cc’d on them. This eliminates mis-communications\provides ownership\prevents confusion and finally inspires confidence especially on the customers side.

Cisco promote unified communications but perhaps a cohesive announcement of the above change through email\updated web pages and official announcements through the Cisco Learning Network would have been better that the current situation for SP candidates.

SP OEQ Confirmation

OEQ Email

Here we go…..

Core Knowledge Questions Now on All CCIE Labs

Effective January 4, 2010, the CCIE® Service Provider, Storage, and Wireless Lab Exams will add a new type of question format in a section called Core Knowledge. In this new section, candidates will be asked a series of four open-ended questions which require a short written response be entered into the computer–typically several words. The questions will be randomly drawn from a pool of questions on topics eligible for testing. Candidates can review the topics by visiting the CCIE track information on Cisco.com or Cisco Learning Network. No new topics are being added as a result of this change. Candidates will have up to 30 minutes to complete the Core Knowledge section and may not return to it once they have moved on. A passing score on the Core Knowledge section is required to achieve certification. Core Knowledge questions were implemented on Routing and Switching labs in February 2009, Security labs in June 2009, and Voice labs in July 2009, and allow Cisco to maintain strong exam security and ensure only qualified candidates are awarded CCIE certification. Candidates with exam dates January 4, 2010 or later should expect to see the new question format on their lab exam. To find out more information regarding updates to the CCIE Lab and scoring format, please click here to go to the CCIE Q&A section.

Many thanks…

to all of you who have commented here and contacted my by mail – your comments have been great for me and it reminds me that all of us who study at our desks at night seamingly alone are not – that there are like minded people out there doing the same thing. I will be in touch shortly.

Also to two of our fraternity who are taking the SP Lab today and tomorrow – the very best of luck guys and let us know how you got on – we are all here to help and assist. I will relay your feedback in this blog if you so wish – let me know.

Steve.

Do you ever get the feeling….

that some things were not meant to be…

• Basic Configuration – 71%
• Core SP Routing – 73%
• BGP Routing – 75%
• MPLS – 73%
• etc, etc

Very disappointing and frustrating – the frustrating piece is that I had my complete core and MPLS up and running exactly as requested – in hindsight, 18 hours later I would not change anything – everything was up – exchanging information as requested. I had one Cat request which I knew how to do but that method was explicitly not allowed to be used which stumped me hence the dropped points in that section – but the ramifications were enormous as two double-point questions in MPLS VPN relied on that and thus 15 points were dropped 3 in Cat and 12 points [2x6] in MPLS VPN thus scuppering the attempt.

Overall it was a great attempt – my plan worked like a treat – I got through switching\frame-relay\ppp and ISIS within 1 hour, BGP was completed by 2 hours, basic MPLS and MPLS traffic Engineering by 3hrs 15m and I completed two sections of MPLS VPN and 2 Management questions by lunch. Great stuff – everything going really well.

After a nice lunch I completed the 4th part of MPLS VPN - 1st issues arose during the 5th part which relied on an the earlier section with the restriction – I completed all other parts and moved on, crap, another double points section with the same dependency – completed all other work involved in the question and moved on – Multicast up and running but although I completed all sections I could not get Inter-AS communications end-end even though I completed all configuration work as I knew it – putting a dirty solution in worked but not as required so I removed it. Security, QoS and Management\Features all integrated with previous work and I finished the lab with 50 minutes left.

So back to that section that everything relied on and do you know what, I couldn’t get it to work in the 50 minutes - even now the morning after I still cannot think how to get it to work with the restrictions that were put in place – I will have to deep dive the various locations such as IEOC, IPExpert, Cisco Press and Groupstudy to try to see who got this feature before and how they resolved it but that was that for me.

It also looks like an enforced rest anyhow as the next available date is June which I have booked. Just a side note – there were 6 candidates sitting the lab exam – when I was there in February there were 20 that day. Also two days this week Brussels had 0 R&S candidates – Draw your own conclusions with that nugget.

Finally a big thanks to you all for your encouragement and tips – you have been a great inspiration. I intend to return to smaller more technical blog entries from now on as I have more time to reflect and zero in the specifics of a feature rather than general details. It’s also family time for me as they have suffered most in this process and that is the heaviest price to pay, far more so than the financial one.

Steve.

Almost at the finish line!

I labbed for 4 hours this morning completing a lab from last night so latter MPLS VPN, QoS & Multicast. I hit a wall per se and it’s simply called tiredness. I have been on the routers 10 hours\day since Thursday and it takes its toll. Therefore I spent the rest of the afternoon and evening going through blog notes and crib sheets.

There are some great entries out there with both INE & IPExpert outputting top class SP tech-notes. Add these to Ivan Pepelnjak’s blog & MPLS VPN crib sheets, packetlife’s cheat-sheets [always hated that term!], Cisco Learning Network SP Notes and you have a great set of notes maybe 50-75 pages worth that cover the backbone [excuse the pun] of the SP Lab Exam.

Tomorrow is final prep day, some small labbing – going over concepts, reinforce my attack plan, pack the bag for Brussels – its an early flight – 0600 getting in at 0900 local time, a day in the hotel to chill out and get some sleep then report in for the Lab on Thursday morning.

My plan of attack? -> Fly out of the blocks and build up some real speed – I have been speed drilling for the last 2 weeks and its amazing how fast concepts such as MPLS & Multicast in particular can be typed. Obviously due care is required but I am determined to break the back of the MPLS VPN section by lunch time if at all possible. I cannot allow any IOS issues to stall this, there will be a 15 minute max limit placed on each section and I move on regardless. If the issues is core to the lab I move on anyway, perhaps to SP Management or QoS as I have proved that troubleshooting too long and you cannot see the wood for the trees – get away, do something else whilst rebooting the troublesome router should aid that process.

This is my final blog entry prior to the lab so I will be back on Friday with my results – positive or otherwise. Thanks for all the encouragement.

Steve.