CCIE Pursuit Blog

November 5, 2007

Internetwork Expert Volume III Lab 01: A Drive-by

After wasting most of my weekend adding backbone routers to my existing lab, I decided that I wanted to crack open lab 1 of the Internetwork Expert Volume III lab book.  These are 4-hour mini-labs that concentrate solely on “core tasks” such as switching, IGP, EGP, WAN technologies, and troubleshooting.  Here is IE’s description:

The following scenario is a practice lab exam designed to help you develop your speed and accuracy at configuring Cisco networking devices.  Specifically, this scenario is designed to assist you in your preparation for Cisco Systems’ CCIE Routing and Switching Lab exam.  The goal of this scenario is to configure and verify complete layer 2 and layer 3 reachability as quickly as possible while minimizing the usage of Cisco’s documentation or the context sensitive help.  Ensure to track your time as you progress through each section and compare your results with the specified target time.

I only had a couple of hours left in my study block, so I decided to do the first three sections (troubleshooting, bridging and switching, and WAN technologies) and leave the remaining two sections (IGP and EGP) for another day. 

I did a write erase on all of my lab devices and loaded the provided initial configurations.  I did have to make some minor changes to the provided configurations to match my actual interfaces (replace an e0/0 with an fa0/0 or an s0/0 with an s0/0/0:0 – you get the idea).  The configurations are pretty bareboned, so I got them loaded without any hassle.

Each lab comes with two network maps (one physical and the other with the routing protocol details).  One thing that is not provided is a detailed map of the inter-switch connections.  I know them fairly well and can always turn around and look directly at my stack to verify them, but for this lab I decided to only use the information given to me in the two network maps so it would be similar to the actual CCIE lab environment.  That meant a lot of “show cdp neighbor” statements on the switches to build my own mapping of the inter-switch connections.  IE made this a little more difficult as some of the ports are shut down in the initial configurations.  In order to get an accurate picture of the inter-switch connections, I needed to unshut the interfaces on each switch and then shut them back down again after recording the CDP neighbors.  I’m not sure if this will be necessarily in the actual lab, but it was good practice.

I popped my headphones on and started BT’s “This Binary Universe” (my favorite background music for labbing) on my iPod and dove in.

Troubleshooting

Time alloted: 10 minutes
Time spent: 7 minutes*

I immediately fell on my face.  The first task is troubleshooting.  You are given 10 minutes to find two faults with the initial configurations.  I jumped from device to device and looked for misconfigured IP addresses and ports that were shut down.  There are no routing protocols running in the initial configs, so I figured that this would be a pretty easy task.  I quickly found an interface with an incorrect IP address.  After that I found a number of problems.  There were two layer 3 port-channels that were not built between the switches.  None of the VLANs were configured on the switches so the SVIs were not working.  I had already found more than two issues.  ???

I cracked open the answer key and found out that the bad IP address was one of the errors.  The other error concerned one of the layer 3 port-channels that was not built yet.  I was quite clever and probably would have messed me up, but I had already read the spoiler so it had less of an impact.  I guess that the errors do not necessarily need to be apparent in the initial configurations.  It could be argued that this error could was could be spotted, but you’d need to be a whole lot more observant than I am and I am seriously doubting that the average network engineer would spot it in 10 minutes.  It is something that you would definitely need to fix to complete the lab though!

I marked this up to inexperience with the IE labs and restarted the clock, but added on the time that it took me to diagram the inter-switch topology.  That’s the reason for the asterisk next to my time.  On to the next task!

Bridging and Switching

Time allotted: 40 minutes
Time spent: 27 minutes

This section had four tasks: VLAN assignments, layer 2 Etherchannel, trunking, and layer 3 Etherchannel.  I read the tasks ahead of time and underlined possible pitfalls in each task.  I specifically looked for interdependencies (i.e. a trunking task allowing you to use either dot1q or ISL followed by a later Etherchannel task requiring a native VLAN).  Reading through the tasks I was interested to see that the tasks were pretty specific (needing little to no clarification) and also pretty basic.  I felt pretty good about finishing this section quickly and accurately.

I ran into my first stategy decision early on.  In the first task you are asked to create a number of VLANs (all with names) as well as assign the VLANs to ports on each of the four switches.  It’s pretty obvious that VTP is your friend in this task.  You could configure the VLANs on each switch, but that’s too much time wasted typing and also sets you up to fat-finger something.  The problem is that there are no trunks built between the switches, so VTP is not going to propagate your VLANs to all of the switches until you get them built.  My solution was to configure sw1 as the VTP server and the other three switches as VTP clients (luckily, this was also a specified task, so I could leave them in that state).  I then configured two VLANs on sw1.  Then I jumped out of task 2.1 and directly into tasks 2.2 (layer 2 Etherchannel) and 2.3 (trunking).  Once I had built trunking between the switches and verified that all 3 switches were seeing the 2 VLANs configured on sw1, I would go back to task 2.1 and complete the configuration of the remaining VLANs.

I think that this is a good strategy.  The IE answer guide does not give you strategy tips though.  The answer for task 2.1 shows how to create the VLANs on sw1, assign the VLANs to each port, and set up VTP.  The verification command does show that you should not expect to see the VLANs propagated to switches 2 through 4.  Fair enough.  By reading through the other tasks you can see that trunking will eventually be built so the VLANs should be propagated. 

I did see a couple of errors in the IE answer guide though.  If you were to create all of the VLANs on sw1 and then assign the VLANs to the appropriate switchports on all of the switches, then – because VTP is not working due to no trunking –  the switch would create each VLAN for you.  You’d see something like this:

sw4(config)# interface fa0/15
sw4(config-if)# switchport access vlan 57
% Access VLAN does not exist. Creating vlan 57

The switch would create the VLAN for you, but with a default VLAN name of VLAN0057.  This is not going to match the VLAN name that you’re supposed to use (VLAN_C in this case).  Furthermore, the “show vtp status” verification that the IE answer show for sw2, sw3, and sw4 shows:

Number of existing VLANs           :  5

This will not be the case if you assign the VLANs to the ports on sw2-4.  Even though you won’t have the 12 VLANs configured on sw1 until VTP does its thing, you WILL have 5 + x VLANs; where 5 is the number of default VLANS and x is the number of unique VLANs you assign to the ports.

Finally, since you would have VLANs existing on sw1 with VLAN names and the same VLANs on the other switches with the default VLAN names – what’s going to happen to the VLAN names once VTP does start propagating the VLANs to the client switches?  I’ll lab this when I have access to some switches this weekend.

All of the above is assuming that you haven’t set the VTP mode to “client” on sw2 – 4.  If you did that before assigning the VLANs to the those switches, you would avoid the mess above because the switch would not allow you to configure and VLANs.  Of course, the switch would tell you to piss off if you tried to assign a non-existent VLAN to a port.

Nuff said.  I think that my strategy is the best route.  🙂

In task 2.2 you are asked to configure a two-port port-channel using dot1q trunking and the native default VLAN.  This is easy enough except for two points that are not spelled out for you:

1)  What channel-group number should you use (this layer 2 port-channel is not on the topology map)?
2)  Which port-channel protocol should you use (PAgP, LACP, or on)?

I used channel-group 1 and “on” (“channel-group 1 mode on”).  That’s what IE used for in the answer key as well.  My general rule is to avoid any dynamic protocols unless they are specifically called for.

The “use the default native VLAN” part of the task is a bit of a red herring.  I generally hate tasks like these because you need to know what items are enabled by default.  In this case, it’s pretty easy because dot1q uses the default native VLAN by….well…default.  🙂

The next task (2.3) involved setting up some very simple trunks.  The tasks specify that you use dot1q trunks.  The only thing unclear is whether you should use dynamic trunking.  See “avoid any dynamic protocols unless they are specifically called for” above.  At this point, I had trunking built to across all four switches.  I jumped back to task 2.1 and completed the VLAN configuration and assignment.  I verified that each switch had learned all of the VLANs via VTP. 

The last task was the only one to trip me up a bit.  It involved creating layer 3 Etherchannels.  I knew that you need to configure these in a specific order, but I could not remember the order.  I hit the DOC and pulled up the configuration guide.  I was able to quickly find the document for configuring layer 3 etherchannels.  This is also the step where I would have discovered the second troubleshooting error.  I followed the DOC and had my layer 3 Etherchannels up and running, except that one of the channels (between sw2 and sw3) kept bouncing.  I still don’t know why.  I wrote the configs and reloaded sw2 and sw3.  The problem went away.

One other point about this task.  This was the first “verbiage” issue I came across.  The task asks that you use “all remaining directly connected inter-switch links” for the layer 3 Etherchannels.  The time that I spent drawing the inter-switch topology paid off handsomely in this task.

I was done with the Bridging and Switching section 13 minutes early.  Whoot!!!

WAN Technologies

Time Allotted: 20 minutes
Time Spent: 32 minutes

I need to get my butt to a meeting.  I will finish this post tonight. 

Advertisements

1 Comment »

  1. You most certainly can add a port to a non-existent VLAN on a client mode switch, and it will not tell you to “piss off.” After you establish the trunks VTP will propagate the VLAN data including the VLAN names.

    Comment by OJ — November 5, 2007 @ 3:34 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: