October, 2008

It pays to read the entire lab…

This is just a quick entry.

One of the great things about the workbooks is that they stress: read the entire lab.

The whole point is that if you adopt the top down approach to configuring one task, then moving onto the next, you may find that there are some tasks that should be done BEFORE others, otherwise they may cause a headache.

Case in point is highlighted in IPexperts workbooks (Volume 1 Section 3) whereby you are asked to make sure switches should not exchange vlan info over any trunk.

Now the only vtp mode that will not originate vtp advertisements is vtp mode transparent.

However you are next asked that if a vlan is not being used locally, then the switches should signal any downstream/upstream switch to stop sending info.

Now the above should “scream” vtp pruning.

If you followed the top down method of configuring the vtp transparent mode and then vtp pruning, you have a problem.

The problem: You cannot configure vtp pruning on a switch that is vtp mode transparent.

So this would mean having to change the vtp mode from transparent to server & then enable pruning & then change back to transparent.

However, as seen in the workbook this introduces its own issues.

So the key here is to:

  1. Read ahead, see what tasks influence others
  2. Make use of notepad as much as possible – amongst other benefits it may help to prevent applying some config before you should apply other stuff that should come 1st.

Tagging the Native VLAN

You may be asked in the lab to ensure that ALL frames are encapsulated/tagged with the VLAN id, & to NOT use the Cisco proprietry method.

Now Cisco proprietary = ISL, so we need to use 802.1q.

By default, 802.1q sends frames on the native vlan as untagged.

First ensure that 802.1q trunk encapsulation is running on the trunk, either by:

i) Statically setting it (config-if)#switchport trunk encapsulation dot1q)

ii) Dynamically negotiating 802.1q (NB, if trunking 2 3550s together, by default 802.1q trunking will be automatically negotiated).

The command to allow for the tagging of the native vlan is:

Switch (config)# vlan dot1q tag native

Should you have trouble remembering the syntax for this command, oftentimes the Command Reference can come to our aid via the use of keywords.

In the above line, I’d say the most appropriate keyword to use is: native

Lets head over to the 3560 Command Reference: Catalyst 3560 Switch Command Reference, Rel. 12.2(46)SE

Now click on Index, press ctrl & F (find on this page), and type native.

This will send you to: IEEE 802.1Q trunk ports and native VLANs 2-756

Clicking on this link will take you directly to the command in question!

So try experimenting with different keywords to get a feel for what kinds of words cound as “keywords”.

This may come into its own when you are in the lab (or even in the day job) and you have a requirement that you don’t know the command for, but you have a keyword for which you can search on.

Hope this helps!

My odyssey

Yes my friends, just when you thought the no of blogs with ccie <word to mean journey> (i.e ccie pursuit/journey/trek) had been exhausted along pops up another!

I had to dust the cobwebs off my trusted online thesaurus to come up with my website name.

(It is now starting to regather dust…maybe Ill use it again in 10 yrs time).

Speaking of decades, it took Odysseus ten years to reach Ithaca after the ten-year Trojan War.

I’m hoping that it wont take me 10 yrs to get my 1st CCIE :) (touch wood!)

Anyway, just to let you guys know where Im currently at, I’ve been through Day 1 of the IPexpert VoD (Scott Morris in 720p) & made some notes, and have started going through the IPexpert Vol1 workbooks, mainly focusing on Bridging & Switching, PPP & Frame Relay.

Scotts VoD are simply awesome, he is able to explain concepts pretty concisely and injects a fair amount of humour into them (wondering if Scott did the comedy circuit b4 deciding on the cisco/juniper path :) )

From what Ive seen on the IPexpert workbooks as well, I have no hesitation in recommending them.

The questions are worded in such a way as to make you think about what is being asked.

A point is also made about reading through the section as you may run into “problems” by doing the “answer q1, then q2 etc” way of doing things.

The IPexpert BLS was great value when I purchased it (1/2 price promotion), so if you follow ipexpert on twitter /facebook etc you will know that the promotion is runnin until end of this month.

Now Cauew (Cisco Network Engineer) has been doing a sterling job with his notes on the VoDs thus far and I thoroughly recommend you check his blog out at http://cauew.blogspot.com/

Needless to say I wont be creating copies of what Caeuw has done (lol ill try not to!) but if I find any other info that are worthy of blogging on Ill certainly post them up, along with my adventures with the workbooks.

Now, I have been wrong on…”a few” *cough* occasions when telling colleagues how certain things work (these ppl know who they are lol) but if I know Im wrong about something, I’ll certainly dig deeper and come back with what I know to be a correct answer.

So, please please correct me if there is anything at all that I post that is incorrect (although Ill certainly try to keep any errors to a minimum).