BlueWolf's Howl

« Back to Basics | Bluewolf's Howl | Divine Comedy »

January 05, 2010

Not a good start -

I finally got myself settled and set aside time to work on some lab configurations. I had already done some leg-work and had found some labs on the Partner E-Learning Connection site. From previous studies, there were some really good labs. Some of the labs could even be used for configuring things other than the lab exercise. So I was eager to start in on some configuring this evening.

Not all labs are the same. It may look like butter and smell like butter, but it tastes like wax shavings.

I started with a QoS lab. It looked really complex and challenging. It was going to be a stretch, but I was going to take a shot at it. At the top of the 'lab' area, there are two links. One link is to download the course files. The other link is to download configuration files. Neither link works. Okay - so maybe it's just this one course.

I tried another course - configuring BGP stuff. It's another interesting scenario - not really like the labs in the Cisco Press Practice Labs book. This is just complex and pretty well laid out. The Cisco Press Practice Labs book looks more like what I would expect to encounter on the real lab:

Advertise this network into EIGRP on each router. Ensure that R3 prefers the route from R2 by manipulating the delay associated with this route. Do not manually adjust the delay associated with the interface by use of the delay command. You are permitted to configure only R2 to influence the delay.

Yeah. That's what I expect. And sometimes I have thought that it was a cockamamie question or configuration. But the more I think about it, the more I realize that as obtuse as some of the questions and instructions might be, they actually really do prepare you for the 'real world.' Consider the case of a configuration or adjustment that would fix or optimize something that simply should be done on RouterX. That's the simplest and best way to configure it. Well, the problem in the real world might be that RouterX belongs to your provider or someone who works for another company. You may not be able to convince (or coerce) them to enter such a configuration on their device. So you have to configure -your- device (which you do have access to) in order to bring about the tweak or fix that you need. It happens. Another real world example is with misconfigurations. Yes, you should know how to configure your devices correctly - but you should also know what it looks like when someone else touched it before you and made some typo or gave some command they didn't completely understand. What are the common ways that other people screw up? Ah - now that's a much larger list than you may think. Stupid has no limits and new stupid is born every minute. The reason it's broken is because someone invented a new brand of stupid. And now it's up to you to find it, fix it and take a bow. After all, you're the expert - right?

So back to the BGP lab. The files for this one downloaded. I had hope. The exercise looked interesting. I click to schedule/reserve the lab. It took 2 minutes to load. Okay - not bad. The lab loaded and the interface looked a bit like the files I just downloaded. However, the topology allows you to click the device to telnet, view the configs (run/start), or reload the router. There was a small link on the left which you can use to download and use the Telnet fix for IE7. Well, I'm using IE8 so I ignored it. I clicked the device and chose telnet. A browser popped up with an error and that was all. I could not get back to where I started. The browser closed and I started back to try again. Now there's no way to connect to the device. I had to end the session. I tried going back to it again. This time the link is now there. I click the link to use the Telnet fix for IE7. After I run the fix, I am told to close all browser windows for the fix to work. I go back to the lab again. [Note: each time I have to log into Cisco through the PEC site, launch PEC, launch the lab, and then schedule another session.] So now I'm sure this is going to work. I schedule my session and it appears with the clickable device. I click Telnet. Nothing happens. Well, at least nothing useful. I get two popup windows which ask me if I'm sure I want to do this... But no telnet. I even tried PuTTY - using the IP address and port provided in the popup. No dice. Nothing but a big, black screen - which times out and closes.

To add insult to injury >> Once you cancel the lab and discard the config (which was nothing since you couldn't get into it), you are sent to a page for a LabOps Survey - which never loads. You see "Please wait .... loading" and if you're lucky, you see your name at the top and no survey questions. Just a large blue blank screen. How rich.

I guess you get what you pay for... and these were free. What a bargain to be working for a Gold Partner!

Of course, all the labs are not like that. But from what I've experienced, anything that says NIL is worth nil. There were some really good labs on there before they moved the site. I guess I need to just search harder. It's a shame because when you read through the scenarios, they sound like really good, tough challenges. I guess the biggest challenge is making the lab work?

Meanwhile, I'm going to chalk tonight up to a loss and break into the Cisco Press Practice Labs scenarios tomorrow on the Dynamips/GNS3 that I was able to get up and running on my 'spare' computer. I'll also give the BGP lab another shot from that machine - it's an old XP box running IE7. Wouldn't that be a kick in the head if it works?

Posted by BlueWolf on January 5, 2010 09:34 PM