CCIE Pursuit Blog

November 29, 2007

Cisco IOS Hints and Tricks: BGP fast session deactivation

Ivan Pepelnjak has a nice summary of the BGP command “fast session deactivation” over at his always excellent Cisco IOS Hints and Tricks blog.  Here’s an excerpt:

We all know that BGP is meant to converge slowly … well, the MPLS/VPN service providers tend to disagree, as their users are not used to minute-long convergence times. One of the major components of slow BGP convergence is the time it takes a router to discover that a neighbor has disappeared. Traditionally, the BGP keepalive packets were sent every minute and it took up to three minutes to discover that a neighbor is down. Of course you could fine-tune those times with the neighbor timers configuration command, but the reduced timers resulted in increased TCP traffic and consequently increased CPU load, which could reach tens of percents if the timers were set to a few seconds and the router had lots of BGP neighbors.

The neighbor loss detection has improved dramatically in 12.3T and 12.0S with the introduction of the fast session deactivation, where a BGP session is dropped as soon as the route to the BGP neighbor is lost.

 I’ll lab this up this feature this weekend, but in the meantime surf over and read Ivan’s overview.

November 27, 2007

Bitbucket Gets His Number!!!

Bitbucket passed the Routing and Switching lab.  He’s no longer pursuing the CCIE – he has conquered that beast.  Surf on over and give him some love.

CCIE Nightmares

The CCIE lab has officially invaded my psyche.  Over the last week, I’ve dreamt about the CCIE lab twice.  When I was learning a foreign language (first German, then French – both of which I suck at) I was told that it was a turning point when you started to dream in another language.  Hopefully dreaming about the CCIE lab is a good harbinger, but my guess is that stress is finally kicking in and making my unconscious fuck with me.

Dream 1 – I have flown to San Jose and am in the midst of the lab.  I’m doing well and am happy with my progress.  We break for lunch.  My wife and I go out to get something to eat.  I completely forget about the lab and lose track of time.  By the time I get back to the lab there is only about an hour left.  I start to hammer away at the CLI but the clock keeps winding down.

Dream 2 – I take the CCIE lab and fail.  I am relating how difficult this lab is to my family when my sister (the non-technical, neo-Luddite with a Literature degree) starts to brag about how she recently passed the lab.  I am flabbergasted and ask to see proof.  She shows me a certificate from Cisco with a CCIE number of 1.  She says that she did so well on the lab that they gave her a special number.  My head explodes. [Okay, the exploding head bit didn’t happen – but it should have.]

Sigmund Freud would tell me that the increase amount of time that I am spending on my studies coupled with the overwhelming nature of the exam is inducing these dreams.  Either that or I want to bone my mom.  Whichever.  🙂

If my brain thinks that I’m going to put up with these nightmares, it has another thing coming.  I have two bottles of Maker’s Mark and a shitload of ice cubes as well as cable TV.  A dozen or so ounces of whiskey and a couple hours of Reality TV will kill enough brain cells to show my brain that I mean business.  🙂

Practice Lab Strategy

I’ve come up with a rudimentary practice lab strategy. The Internetwork Expert Volume II workbook contains 20 practice labs each labeled with a difficulty label with a maximum value of 10. The lab with the lowest rated difficulty level has a rating of 5 (it is the only lab with a 5 rating). IE has stated that the actual CCIE lab has a average difficulty level of 7 (it could be as low as a 6 or as high as an 8).

The table below shows the difficulty level for each lab:

Lab Difficulty








































The breakdown by difficultly level is as follows:

05 – Lab 01
06 – Labs 02, 03, 04, 05
07 – Labs 06, 12, 18
08 – Labs 08, 09, 10, 16, 17, 20
09 – Labs 07, 11, 13, 15
10 – Labs 14, 19

My plan (subject to revision) is to work through all but two of the labs at each level (except level 5 of course) at my own pace. That is, I will do the lab but will not attempt to time myself or grade the lab. I will also allow myself to use the solution guide should I get stuck (I will try to minimize this by using the DOC). I will also do each of these labs at least twice and assign myself study items by recognizing the technologies that I totally stink at. Let’s call these “learning labs.”

The remaining two labs (per difficulty level) will be treated as mock labs. I will do each of these labs in a simulated lab environment. That means sitting the allowing myself 8 hours with a 30 minute break to complete the lab. That also means that I will only allow myself to access the DOC – no looking at the answer key if I get stuck. I will also grade these labs afterwards to try to get an idea of what score I would get had this been the actual lab. Let’s call these “simulated labs.”

I’ll do one simulated exam once I complete all of the learning labs at the next level. For instance, once I complete all but two labs at level 7, then I will do one of the simulated labs at level 6. I will save the remaining simulated lab (at each difficulty level) until the end of my studies and do them in a short period of time.

For instance, I will do labs 1, 2, 3, and 6 as learning labs. Then I will do lab 4 as a simulated lab. After that I’ll do labs 8, 9, 10, and 16. Then I’ll do lab 12 as a simulated lab. And so on…

I’m hoping to tackle one learning lab per weekend going forward. I’ll spend the rest of the week working on my week areas. I’ll also be mixing in some of the Volume III labs to work on speed and accuracy on the core tasks.

This plan seems workable and will give me some goals and direction.

Routing TCP/IP Volume III In The Works?

Well, maybe not.  Jeff Doyle has an interesting post up about the back history of his Routing TCP/IP books as well as his idea for a possible third volume in the series. He also has an open call for ideas for the third volume, so definitely go and drop him a comment if you have any ideas.  I would welcome an MPLS volume, but then again I would read anything that Doyle or Odom write.

When Cisco Press approached me in 1996 or so about writing a book, they were a pretty new operation and they left it to me to choose the topic. So I chose the plum, “Routing TCP/IP,” which originally was supposed to be one volume. Halfway through the project my editor and I both realized we couldn’t squeeze everything I wanted to cover in a single book so it evolved into two volumes.

And those two volumes have been a cornerstone of my career.

To this day, and no matter what country I’m in, I encounter people who tell me how much those two books have helped them in their careers or in gaining their CCIEs. Engineers will even bring their copy of the book to meetings or to events at which I’m speaking, and ask me to sign it. I’m always delighted to do so, and endlessly pleased that so many people find my books useful – although my kids find it hilarious that anyone would want my autograph on anything.

Given the success of these two volumes I had a conversation last year with Brett Bartow, the Executive Editor at Cisco Press, about doing a Volume III. Brett is interested in the concept, but not in my idea for a topic: I wanted to do the volume on MPLS. To me that’s the logical next step in the series and a topic I particularly enjoy. But Brett tells me it wouldn’t sell; the market is saturated with MPLS books. A quick scan of just the Cisco Press titles, and I reluctantly must agree with him.

So I thought I would open the question up to you: What topic or topics would you like to see in a “Routing TCP/IP, Volume III”? Post your suggestions as a response to this blog or e-mail to me privately.

I’m looking forward to hearing from you!

November 26, 2007

More Memory Makes Dynamips Happy

I finally dropped a gig stick of RAM in my laptop (it was at 512 megs) and fired up Dynamips.  What a difference!!!  I’m able to run more device instances and they run much faster.  I’m going to swap out the 512 meg stick for another gig stick this weekend.  Since I’ll be doing a lot of technology specific labs this week, I’ll probably be doing most of them in Dynamips.

LFU 9: Beware The Implied OSPF Process!!!

I ran into an interesting issue on the Internetwork Expert Volume II lab 2 this weekend.  I noticed that I had a rogue OSPF process showing up on one of my switches (3560).  I had configured OSPF process 100, but not OSPF process 17 (17 wasthe area that the sw1 OSPF interfaces were in):

sw1#sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
3     rip
4     ospf 17   <-where did this come from?
*** IP Routing is NSF aware ***

sw1#sh ip proto | b ospf
Routing Protocol is “ospf 100”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID
  It is an autonomous system boundary router
  Redistributing External Routes from,
    rip, includes subnets in redistribution
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks: area 17
  Routing Information Sources:
    Gateway         Distance      Last Update            110      00:18:43            110      00:18:43            110      01:44:44            110      01:44:44
  Distance: (default is 110)

There was no other OSPF process configure.  I thought that maybe I accidentally configured “router os 17” at some point, but when I looked at the configuration all that was there was OSPF 100.  I thought that there must be some bug in the switch IOS.  The phantom OSPF process was showing up in the “show ip protocol summary” output but not in the “show ip protocol” output.  I reloaded the switch just in case.

That didn’t solve the issue.  I looked through the configuration and found the issue…under the RIP process!  This solves the mystery of the “ospf 17”:

sw1#sh run | b router rip
router rip
 version 2
 redistribute ospf 17 metric 1   <-whoops!  
 offset-list EVEN in 16 Vlan783
 no auto-summary

This explains my route redistribution issue as well!  I must have typed in the area number instead of the correct OSPF process (100) when redistributing OSPF into RIP.  This is the type of fat-finger issue that can make you fail your lab.  I banged my head on my desk and corrected the process ID.

sw1#sh run | b router rip
router rip
 version 2
 redistribute ospf 100 metric 1    
 offset-list EVEN in 16 Vlan783
 no auto-summary

Strange, IOS must assume the existence (or imminent existence) of a routing process if you reference it in a redistribution statement.  What’s even stranger is that even after I removed (changed) the reference…it still showed up:

sw1#sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
3     rip
4     ospf 17
*** IP Routing is NSF aware ***

WTF?  Was I being haunted by an undead OSPF process?  I verified that there was nothing left in the configuration that referred to OSPF process 17:

sw1#sh run | i 17
 ip address
interface FastEthernet0/17
 area 17 authentication
 network area 17

So the process was not configured and there was no longer any reference to it, so why was it still showing up?

sw1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw1(config)#no router ospf 17
sw1(config)#do sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
3     rip
*** IP Routing is NSF aware ***

Lesson learned: if you reference an OSPD process that does not exist (in RIP at least) then the router assumes that this process is actually running.  You’ll need to explicitly remove the process (“no router ospf x”) in order to remove it from the “show ip protocol summary” output.

Fresh Batch Of CCIE Blogs

I recently predicted that I would soon be posting another batch of CCIE blogs.  Listed below are the newest blogs to join the growing list of CCIE blogs.  I have also created a page with a list of all of the blogs that I have posted about so far.

NetworkGremlins (Saving the internet, one packet at a time…) – This blog is authored by Greg Oberfield, a network engineer working for a “(very) large phone company” in the Chicago area.  Greg is currently working towards the Service Provider CCIE and it looks like he’s using Internetwork Expert materials along with a sweet Dynamips setup:

…the new server for Dynamips should be arriving shortly.  It’s a 1U, Intel Core 2 quad-core machine with 4GB of memory and hardware RAID1.  That should be more than sufficient for everything I want to pound into it from a processor perspective.

He has recently set up a lab with a combination of Dynamips and real equipment.  If you’re working on the SP track or you are trying to integrate Dynamips with live equipment, then this blog is going to be a good resource.

Routereflector’s Weblog– This is a pretty new blog (first entry 07 November).  Routereflector is scheduled to take the Routing and Switching lab in April and is using the Internetwork Expert End-To-End program as study material.  He also has put together his own lab.  The blog has a lot of daily updates with a lot of good information (especially for those using the IE labs).  Routereflector’s reason for blogging is similar to mine:

This blog will hopefully be of use to other aspiring CCIE’s.  I’ve found that writing this blog helps focus my studies, it also makes me feel guilty when I don’t want to revise as I won’t have anything to write on the blog. 

CCIE Lab Preparation  – I came across this blog in September, but forgot to put it in the last CCIE Blog posting.  This blogger is set to take the Routing and Switching lab in February in Brussels.  He is currently working through the Internetwork Expert Volume II labs.  He has a nice page that has links to topics in the DOCHe recently changed his practice lab strategy:

For the next month or so I am going to change my approach to the workbook labs. Instead of trying to finish a complete lab within 8-12 hours my aim is to complete the core sections instead and work on my understanding and speed.

I will definitely be hitting this site quite a bit as I follow in his footsteps through the Volume II labs.

Turgon’s Blog at– While not technically a blog, Turgon is documenting his progress towards the CCIE Routing and Switching lab in a forum at  He’s been posting there since May of this year, so there’s a lot of good information.  Here’s some background on Turgon:

I passed the CCNA in October 1999 and took the CCIE written in 2001. I have followed groupstudy for many years since then and did a lot of prepartion for the lab in 2002. However my commitments at work and the commuting I was doing rendered it unrealistic for me to continue my preparations so I wound them down in 2003 and concentrated on my work. I have been doing network design for a number of years and I’m now ramping up to complete my lab prep and do that first CCIE lab attempt in Brussels later this year. I finished my written exam in April so it’s full steam ahead now, evenings and weekends preparing.

It looks like he is using IPexpert’s workbook.  The forum format is interesting because there seems to be quite a bit of feedback from other forum posters.

As I stated earlier, these blogs as well as the others I have written about are now collected on a single page.  I will also add these blogs to my blogroll in the near future.

Status Update: 19 – 25 November

This week I had a lot of time off due to the Thanksgiving holiday.  I ended up putting in about 45 hours of study.  Most of that was spent on the rack.  I went through the IE Volume I IPv6 labs as well as another run through Volume III lab 1 and my first attempt at a full-scale practice lab (Volume II lab 2).

I’ll post more about lab 2 later.  In short, I came away with mixed feelings.  I feel pretty good about my command of the basic technologies.  I did very well on the layer 2 and Frame Relay sections.  I did good on the IGPs.  But then I completely lost it on route redistribution again.  This was very disappointing after I spent so much time studying that topic last week.  I also made enough small mistakes to ensure my failure.  I’m hoping to minimize those in the future.  Finally, I am getting more comfortable with the DOC, but am still far from being at the level I need to be at in order to attempt the lab.  All in all, the experience was a push – I am encouraged by my general knowledge but disappointed with my ability in a few core competencies.

Here are my goals from last week: 

Study IPv6.  Review PPP.  Attempt Volume II lab 2.

I did quite a bit of IPv6 reading and labbing.  While I’m still not at an expert level, I was able to successfully complete the (abeit pretty easy) IPv6 task in the IE practice lab.  I did NOT review PPP and that bit me in the ass on the practice lab.  I dug up my old BCRAN material and will definitely review PPP.  I did attempt lab 2 (see above).

Goals for this week:  Do a lot of review on specific topics from Volume II lab 2.  Redo lab 2 with an emphasis on developing a lab strategy.  Review route redistribution (again).

Days Until Lab: 188
Readiness (1 to 10): 2
Lab Hours This Week 35
Study Hours This Week (estimate): 10

November 25, 2007

Blog Housekeeping

As you may have noticed, I changed the look of the blog.  I threw on a different theme so that I could use more screen space.  It looks a little goofy if you “Restore Down” (is that really the official Microsoft term?) the screen, but otherwise I don’t see any problems with the new theme (other than it ate my byline).  I also disabled the “Snap” link preview because I don’t see much use in getting a preview of a website and it would also sometimes become a pain in the ass to click on a link because the preview would pop up in the way.

I am eventually going to mirror this blog at, but that project is pretty low on my list of things to do.

Next Page »

Blog at