Monthly Archives: February 2010

LAN Switching: Read it, or else.

I finished the STP chapter in the CCIE exam cert guide, and was almost disappointed. I have a hard time believing anyone could expect to be fully prepared for the written exam after reading that chapter. I would highly recommend that anyone taking the written give a strong look at the LAN Switching book from cisco press, Chapters 6 and 7, which both cover STP and Advanced STP. This book is FANTASTIC as far as STP theory goes. Blows the others out of the water. Granted, the config examples are done in CatOS, but ignore those..use the BCMSN book for configuration, LAN Switching for theory, and the CCIE exam cert guide for review!

I knocked out chapter 6 of LAN Switching, and part of chapter 7. Once I finish Chapter 7, I’m going to read up on a lot of MSTP, and do some STP labs in the next few days. I’d say that I’ll call STP “done” in about 3-5 days, after which it’ll be onto some IP Addressing review, and then EIGRP. If I can maintain this pace, I think I might be able to bump up my written date, which would give me more time to prep for the lab. We’ll see! Stay posted, I may put some STP notes up tomorrow..

STP: Root port selection

While doing my reading on Spanning-tree and my INE Vol I labs, I kept referencing back to the book for the tie-breaker criteria for root port selection, and decided I’d post it.

In our scenario, we have two switches, SW4, and SW1, which are directly connected with three fast ethernet links. Here’s how STP would select the root port by the book, then we’ll go over what actually happens, and see how we can influence it.


Root port selection (tie breakers)

  1. Lowest sending bridge ID
  2. Lowest STP port cost
  3. Lowest port-priority
  4. Lowest interface number


Lowest Sending Bridge ID

Now, in our scenario, the sending bridge is naturally going to have the same BID, because we have 3 links all to the same switch. Remember, the BID is the priority of the bridge (32768 + VLAN ID if system-id extension is enabled), and the MAC address. That being said, regardless, this won’t matter if the links are all to the same switch…

Lowest STP Port cost

This is referring to the outbound port cost. Remember, STP port cost is associated with an interface, NOT the link itself. So, SW4′s interface is 19 by default, which means, all three interfaces tie.

Lowest port-priority

This one confuses people. If we configure a low port priority on SW4..it will NOT influence root port selection. Why? Well, BPDU’s are being sent TO us from SW1, listing the port priorities. You can verify this by debugging and seeing that the port priorities for all three ports are included in incoming BPDU’s.

Lowest interface number

Sad, but true, this is the best we can do! It ends up selecting f0/13, instead of f0/14, or f0/15.


How we can influence root port selection on redundant links

  • Adjust the STP port cost (outgoing, remember that) on SW4
  • Adjust the port priority on SW1′s links to SW4

At the end of the day, because of the order tiebreakers occur, cost will always override the priority. It makes sense, cost is locally configured, priority is configured on the designated port for that segment. It should be noted, however, that if there is say, a ring topology with 4 switches (such as the INE topology), and you have two links, to two different switches, the process is the same, but root path cost comes into play.

Anyway..off to bed..got some solid labbing done tonight.



Keeping track of it all: ip access-list log-update threshold

I’ve been doing some great studying lately. Here’s my progress:

-Read up to page 85 on the CCIE Exam Cert Guide (4th edition)

-Read 10-20 pages of the BCMSN book, used it to review on some layer 2 topics that the exam cert guide didn’t go into to much detail with

-Did up to page 40′ish on the INE Volume I labs. I’ve been taking my time to make sure I have the verification commands down, and know that I’m “good” at certain technologies. This is especially important to me, since switching is doubtedly a core topic..everything else would break without it!


ip access-list log-update threshold X

I stumbled onto this command thanks to the INE ATC. By default, when you add the “log” keyword to an access-list entry, it will log the first hit, and subsequent identical hits will be logged at 5 minute intervals. Great for the real world (sometimes), not so great for the lab. I find it helpful to know one-for-one, that I have a packet passing through that meets that particular ACL. By entering this command, and putting a “1″ where the X is, it will log hits 1-for-1. Pretty helpful I think.


Anyway, back to studying. I’m now entering the world of STP, so if you don’t hear from me, send help ASAP I’ll be fine.



Plan of action

Yesterday I watched one of the CoD videos from INE (EIGRP), did some EIGRP labs from Vol I (INE also), and read some OSPF. I quickly realized I needed to focus on one area at a time, not skip around anymore. That being said, I’ve developed a simple, but hopefully effective, plan of action. It goes as such:

  1. Pick a technology/area to focus on (ie: Switching)
  2. Read the chapter from the CCIE exam cert guide
  3. Do corresponding InternetworkExpert Volume I labs
  4. Re-read if necessary, read supplemental material (ie: LAN Switching from Cisco Press)
  5. Run through INE labs again and play with ‘custom’ scenarios, to make sure I have the configuration side down
  6. Skim over the section as needed to stay sharp on certain topics

That’s the general idea, which will repeat for every chapter basically. I’ve read most of TCP/IP Vol I, and will probably go back to it once I get to OSPF, but for now, I want to focus, so since switching is at the beginning nof the CCIE cert guide..and a core area, I will be focusing on that for a while.

Tonight’s progress: I’ve read 40+ pages tonight (still reading) from the CCIE Exam cert guide (4th edition). Nothing really has caught me as being “new”, but I’m moving forward and trying to remember little details that could catch me on the written. In the end, though, I’m just trying hard to keep my momentum. I have a tendency to get hung up on something, or get distracted. I need to make sure I take the written for what it is, a test. I need to pass it, and lab, lab, lab. I want to know these technologies, but I also want to be functional, and I can’t get to a CCIE-level of configuration until I pass this written, which is exactly what I intend on doing. Back to reading..if I get any further I may throw up another post later.

IEWB Vol I/EIGRP labs

I finally got to give the rack a test drive! It performed well! Anyways, I only had time to run through some EIGRP labs from IEWB Vol I. I finished about half of that section, they were pretty basic. I still tried to take my time and verify everything before testing it out, so I’d have my show commands down. Since I don’t get to work with Cisco on a daily basis, it’s really important that I get (in my opinion) more exposure to things like this than other candidates with more day-to-day experience. It’s funny that I was doing this stuff a lot only 2 yrs ago, but so much has been lost in the meantime. That being said, I feel like I’m doing well. I already can’t wait to get further into the more difficult stuff. I work tomorrow, which means I’ll be doing some more reading of TCP/IP Vol I. It’s rough, because I just received the CCIE Exam cert guide, 4th edition..and the EIGRP section there is nothing compared to TCP/IP Vol I. The OSPF section in TCP/IP Vol I is like 150+ pages! In the exam cert guide it’s a handful it seems! It’s still better to know a little more, but I do have a deadline for the written, so I’ve got to keep trucking. Anyway, tomorrow I’ll work on some more OSPF reading. I think I will probably do a flyby as far as the reading goes, that way I can deep-dive as I do my labs..it’s kind of rough to read a lot of in depth, detailed information without doing ANY hands on. At least now I can lab at home :)


“Final” pic..

Got the cabling done. In this picture the term server is missing since I had to return it to CiscoKits so they can send a “new” one, and therefore the Octal cabling isn’t shown, but the rack is pretty much in it’s “final” shape. It should be noted, I’ve moved things around just a little bit since this picture (not very noticeably though). I’ve gone back to verifying my IOS versions are straight before I start configuring the backbone routers. My frame switch is 100% configured and all PVC’s operational, but I’ve got 6 routers to upgrade the IOS on, (3) 2500′s, and (3) 2600′s. The 2600′s currently are running 124-5 IOS, so that’s not that bad, but I’d like to run the exact same IOS as INE, which is Adventerprisek9, 124-10a. The 2500′s need to be upgraded, since they’re running 11.X (forgot exactly what they were running, I’ve already upgraded one, but have two left to do)…they don’t support IPv6 with the older version, so that’s definitely a must. Anyway, I’m hoping that I’ll finish all of the IOS upgrades tonight and be able to start labbing tomorrow.

Troubleshooting your frame switch

After spending way too much time troubleshooting my frame switch, I figured my advice could help others. In my case, I had a very, VERY weird issue with my frame switch, which essentially manifested itself in the form of one-way communciation between the devices connected to it. The interfaces would come up for 30 seconds, and drop. The frame switch never saw them up. The configs were right..they were dead on. Tried switching to PPP, or HDLC encapsulation..nothing. Swapped cables…nothing. Swapped ports..nothing. Even moved modules on the routers to check for a bad slot..nothing. In the end, after several reboots, the problem disappeared. Anyways, here’s some areas to check..


  • Check your frame switch config first. It should essentially be the following:

interface Serial3                                                               
description **INTERFACE TO R3 S1/0**                                           
no ip address                                                                  
encapsulation frame-relay                                                      
serial restart-delay 0                                                         
clockrate 64000                                                                
frame-relay lmi-type cisco    // Not necessarily required, but I like to do it just to know what’s going on. You can also disable frame-relay inverse-arp to be safe.                                                    
frame-relay intf-type dce                                                      
frame-relay route 301 interface Serial1 103                                    
frame-relay route 304 interface Serial4 403

Most people’s problem are going to come from the frame-relay route statement. Here’s how it breaks down:

frame-relay route <INCOMING DLCI> <OUTGOING INTERFACE> <OUTGOING DLCI>

So here’s the logic..think of it like you are the INTERFACE. So, for example, I would say “I am Serial3, and I’m connected to R3. If I receive any data on incoming DLCI 304, send it out interface Serial4 via DLCI 403. This would look like:

frame-relay route 304 interface Serial4 403

Now, as far as the router config on the other end..you just need a couple of things, the frame encap, IP, no shut, and that’s about it..if you’re getting a down/down, you need to check elsewhere.


Getting your cables straight:

  • The FR switch should be the DCE for both layer 1 and layer 2. Your DB-60 DTE/DCE cables are labeled which end is DCE, and which is DTE. Make sure your DCE is inserted on the frame relay switch end..and inserted properly. It’s pretty easy to insert the cable upside down, but it won’t get a good connection, so be sure to check this.
  • If you still have no luck, swap serial cables..if you have the same results, try a different port (on both ends)
  • If you decide to switch interfaces on the frame switch, remove your old config on the old interface. If you do a “show frame pvc”, you’ll see two entries for that same DLCI, which could cause issues. Better safe than sorry.
  • Finally, if you’re at a complete loss, unplug all other cables going into the frame switch, and blow out all config, and go one at a time. It’s best to keep it simple. Once you’ve verified your config is good to go on one interface, then you can duplicate that config on the other interfaces.


Best of luck. Hoped to have help a little. Just my $.02 after configuring my frame switch.


Cables, cables, and more cables

I’ve spent the last few days getting the rack all wired up and the terminal server working. It looks like I have an issue with my terminal server (2511) not working on some of my TTY lines. I have contacted CiscoKits, which is sending a return mailing address label to me, so I can ship the unit back for inspection. Hopefully they find the same issue and it can be resolved. Kind of sucks, that postpones me using the 2511- which is a pain in the butt for larger labs, but that’s OK. For the tech labs, I’ll mostly need only a couple of routers anyway, so I can deal with moving the console cable in the meantime.

Anyway, I’m getting all of the CAT5 cable made. I’m making it all myself, to save money, and to have the cables at the proper lengths. Nothing annoys me more than seeing a rack with 20 ft of extra CAT5 when that’s not necessary. I kind of understand on serial cables..mine are longer than they need to be also, but let’s at least do a LITTLE cable management people. That being said, there’s gotta be a limit, because if you’re anything like me, you move cables around sometimes, and try new things, which is great. We’re not building a permanent rack here, it’s for training purposes- but using that as a reason to not use cable management is kind of a cop out! That aside, to some extent, I expect CCIE racks to be kind of messy, that’s part of the game..just not overly messy ;)


Back to making the CAT5. I haven’t gotten much studying done since I’ve been busy getting the rack up in order to do IEWB Vol I again. I will surely post more once I make some process whether it be on the rack or my personal studies for the written.


Gear arrived!

The remaining “big” order just arrived this evening, which contained the entire lab minus modules/cables and the 3640′s I already had. I had the rack area somewhat neat, but now I’ve got a stack of routers/switches on the floor in front of it, from when I was screwing the mounts on to each one.


As it stands, I’m waiting on the following:

  • Several modules
  • New crimpers/CAT5 tester
  • USB to serial cable
  • (12) Serial cables

Not too bad overall. It’s a little frustrating to be missing out on the USB to serial..I can’t even console directly in to ANYTHING without that! So what I have here folks, is essentially a large, expensive space heater..in FLORIDA..not what I was going for..

Anyway, I guess I’m just anxious to get everything up and running. Doing all of this reading lately on TCP/IP Vol I makes me anxious to actually lab the stuff I’m reading, so I guess that’s the source of my frustration right now. Oh well, what can you do..but hit the books in the meantime. My hunger to learn more is insatiable it seems! Until next time..go study!

Chapter 7: EIGRP- done!

Finished Chapter 7 on EIGRP from TCP/IP Vol I. I went back and re-read a little bit of it since by the end of it I was fuzzy on some details. Mostly things like the four components of EIGRP (Protocol-dependent modules, DUAL, Neighbor discovery/recovery, and Reliable Transport Protocol, by the way..and no, I didn’t look it up), or the various specifics of the IP Internal/external TLV’s. It’s all pretty simple, but with all the different protocols it’s easy to get little things like those mixed up. Once I finish the next chapter (and largest of the book at 150 pages or so), I’ll probably go back and re-read the highlights of the EIGRP and OSPF chapters. I’d really like to lab some of the stuff up on EIGRP but I’m still waiting on my gear. In the meantime I’ll keep reading.

I’m essentially trying to start from scratch as far as I’m concerned, to make sure I know everything that will be tested on the RIGHT way, not just through memorization (which I’m guilty of doing for some topics). Hopefully by hitting those topics again I’ll have a deeper understanding of WHY and not just the WHAT.