CCIE Pursuit Blog

April 3, 2009

Lab Tip: Sometimes IOS is a Lying Whore!!!

One of the cardinal rules of labbing (and production work) is that you verify what you’ve configured soon after you configure it.  I was doing a lab today in which I needed to use an ip accounting-list to limit IP Accounting to a specific subnet (

Here’s what I entered:

Rack1R1(config)#ip accounting-list

Here’s how it showed up in the configuration:

Rack1R1(config)#do sh run | i ip accounting-list
ip accounting-list

Luckily: a) I looked at my configuration shortly after I entered it, and b) I’ve seen this ‘error’ before.  I must have used a network mask when IOS expected wildcard bits.  I usually screw up access-lists the same way.

Access-lists expect wildcard bits:

Rack1R1(config)#access-list 99 permit ?
A.B.C.D  Wildcard bits
log      Log matches against this entry

Rack1R1(config)#access-list 99 permit

IP addresses expect a network mask:

Rack1R1(config-if)#ip address ?
A.B.C.D  IP subnet mask

Rack1R1(config-if)#ip address

I must have boned up the configuration of the accounting-list by not paying attention to IOS help or just plugging in a network mask because I presumed that was what the command required.  Which is odd because I don’t use ‘ip acounting-list’ that often so I should have been using IOS help.  That’s when I discovered that IOS was fucking with me:

Rack1R1(config)#ip accounting-list ?
A.B.C.D  IP address mask

WTF?  A quick trip to the Cisco documentation showed that IOS was lying to me:

ip accounting-list

wildcard – Wildcard bits to be applied to the ip-address argument.

This could be an error in the IOS code (12.3(14)T7).  Either way I would have lost points on the lab if I had not verified my configuration.  As I stated earlier, it’s a very good idea to get into the habit of double-checking your configurations.  99.9% of the time the error will be yours, but one in a great while IOS will stab you in the back.  🙂

March 3, 2009

Lab Tip: Be Careful When Matching Metric Ranges

I was working on a lab task yesterday which asked you to filter all EIGRP routes on a router with a metric between 500,000 and 750,000.  This can be achieved with a distribution-list using a route-map.

You’ll want to make sure that you’re careful when you’re using the metric range option.

RSRack1R3(config-route-map)#match metric 500000 ?
+-              deviation option to match metric in a range
<1-4294967295>  Metric value

At first blush, I assumed that I could simply specify ‘match metric 500000 + 250000’.  BUT if you look closely you’ll see that the option is ‘+-” and NOT “+” or “-”

If you try to use “-” (in this example ‘match metric 750000 – 250000’) IOS will alert you to this:

RSRack1R3(config-route-map)#match metric 750000 – 250000
% Invalid input detected at ‘^’ marker.

The + option will look like it took and you’ll assume that you’ve match the range 500000 – 750000

RSRack1R3(config-route-map)#match metric 500000 + 250000

But you’ve actually matched the metric range of 250000 – 750000:

RSRack1R3(config-route-map)#do sh run | i match metric
match metric 500000 +- 250000

The “?” is your friend:

RSRack1R3(config-route-map)#match metric 500000 +- ?
<1-4294967295>  deviation value, 500 +- 10 creates the range 490 – 510

To configure the example, you need to halve your deviation value(250,000/2 = 125,000) and then add that value to your lowest value (500,000 + 125,000 = 625,000):

RSRack1R3(config-route-map)#match metric 625000 +- 125000

It’s little things like this that can turn those easy points into lost points. 😦  It’s a good idea to know how to quickly find the command reference for commands like this to clarify the usage, especially if it’s a command that you are unfamiliar with or haven’t used much. Plus the command reference will often contain an example that will help you avoid mistakes like this.  🙂

match metric (IP)

February 9, 2009

GroupStudy: First Feedback On New CCIE Lab Open-Ended Questions

Jason on Groupstudy recently passed his CCIE lab in RTP.  He is the first candidate that I have read about who has given feedback on the new open-ended question portion of the (Routing and Switching) lab:

I was actually trying to avoid talking about the Open Ended question, because I don’t know what the NDA even allows me to discuss or not discuss about them and even though I just had them I still don’t know much about how they are used in the testing process.  I will say that personally the questions were not difficult, but I’m sure that there’s is a very huge pool of them so in my opinion there’s no telling what a person may get.  I still don’t even know how they’re graded or how that grade, if it exists, affects your overall lab results.  Maybe they’re being vague about things on purpose…I don’t know.  They are, just as their name implies, open-ended. No multiple choice…no interviews…just questions that you read and provide a typed response to.  I agree with Cisco’s statement, that CCIE candidates *should *be able to answer them without much difficulty, but what if someone just so happens to get the handful of questions that they hadn’t prepared for as much as they should have even though they may have spent a year or more studying / testing / labbing?   I’m sure something needs to be done if there are integrity problems with the lab material, but I just don’t know that these open ended questions is the solution they’re looking for.

You will NOT be able to reference the Cisco documentation during the open-ended question portion of the lab.  Since Jason passed his lab (congratulation by the way) he did not receive a scoring report (well…the best type of scoring report, the one that just says ‘Pass’):

No, there are no references allowed for the questions.   They never clarified about the points or weights for the questions.  They really didn’t provide any information about that part of it at all.  I wish I knew. Although the questions are “open-ended”, everyone should be prepared to answer very specific questions.  I think that’s about all I can say.

Another candidate’s comment indicated that you needn’t worry about composing an essay response for each question:

Don’t stress about the questions. They are short answer questions for one question I answered with 2 words.

I encourage you to read the entire thread but here are the major points about the new questions:

  • You’re given the questions at your workstation and you answer them on your PC (not an oral interview).
  • You can ask the proctor for clarification on the questions.
  • You are given up to 30 minutes to answer the questions, but as soon as you finish them you can begin the lab.
  • You are not granted additional time for these questions.  If it takes you the maximum 30 minutes to complete them, then you will only have 7.5 hours for your lab.

Hopefully this clears up some of the confusion and angst about this new addition to the lab.

February 3, 2009

GroupStudy: Great CCIE Study Strategy

This recent posting to the GroupStudy mailing list contains a lot of great suggestions for CCIE candidates who are crafting/refining their study strategy:

1st) Do practice labs! It’s that easy, do as many as you can from a reputable vendor. I’m not here to prop one vendor over another…just find 1 (more if possible) that has a proven track record and do their labs. *The key is not so much the material but how you study it! Do the labs just like you’re are going to do the real lab! Meaning…in the real lab you don’t get to see the questions or the topology before hand, you don’t get to go to a proctor guide or google when you get stuck, you have 8 hours. So, when you have a lab manual, schedule your 8 to 10 hours, don’t look at any of the material before hand…then just sit there for 8 hours straight, beating your head against the wall, using only the doc cd. When you start, don’t touch a router until you have read through the whole lab, written down your “blue print” and point values and have a plan for the lab. Then go at it, if you get stuck or stumped, don’t look up the answer! Track your points and save your configs (maybe a show ip route or ip bgp or what ever is relevant as well) to your PC for grading yourself later.

When you have finished (either right after if you’re that impatient) or the next day go through the lab and grade it, be honest with yourself, and find out what you missed, then study it, learn it and understand it. (Those are your “off” days). Then, schedule your next Lab session and do it again!

At first you’ll get owned, feel like crap and wonder what in the hell you are doing. Probably will take you more than 10 hours to get through the labs, but do it all. After the first 5 to 10 you’ll get to where you can finish them in 8 hours, hopefully even sooner after 15 or 20 (the assumption is the labs get progressively harder but you are getting even faster). *part of completing a lab, is going back through the questions and verifying each task…without fail you will find at least one thing you did wrong or missed…that means you need to calculate that into your 8 hours. Get in the habit though

2nd) Once you have done 5 or 10 labs, if you are in a position, do a graded mock lab or… 7. See how you do. I wouldn’t worry so much about the score or “explanations” after the fact, but more of “did I come up with A solution for every section?” “Did I finish it in time?” “How was my time management?” “How well did I think on my feet?” (While I did not pass one of my mock labs, I always completed them, came up with solutions and learned how important it is to notice the little details) Use the mock labs to evaluate your testing strategy.

In all I did over 30 full labs (including my mock labs)…so sitting down for 8 hours in the real lab was nothing for me, I had been doing it 2 to 3 times a week for months. That kind of experience is crucial for success in the real lab. What’s more, I finish my lab (had a solution in place for each question) in 5 and a half hours and was able to spend the next 2 hours going back over each question. I easily earned between 15 to 25 points that way. Having that extra time allowed me to re-read scenarios, pick up on key-words, verify syntax et…You need to be able to get through the lab quickly…if you have done 20+ “labs” all ready, the real lab isn’t nearly as daunting in terms of time or manageability.

The point is this, you can’t do practice labs one way and think that you’ll do the real lab another. The real lab should be 2nd nature in terms of your initial read through and assessment, your time management and troubleshooting of individual scenarios, and your re-read and verification at the end.

I hope this has been helpful. Doing simple math 8 hours X 2 or 3 times a week = a lot of time and that doesn’t include the “off” days where you need to “grade” your self, study weak areas, practice configs, and browse the doc cd. It’s a huge investment of time, but if you’re going to do it, do it right and don’t “cheat” yourself.

January 19, 2009

Lab Tip: Finding Port Numbers For Common Protocols

I stumbled across a couple of very cool resources for finding the ports of common protocols during the CCIE lab.  The first comes from GroupStudy and is a link to the Addresses, Protocols, and Ports section of the ASA 5580 configuration guide:

You’ll probably want to practice finding this page in the DOCCD.

You can get there via:

Firewall Appliances
Cisco ASA 5500 Series Adaptive Security Appliances
Configuration Guides
Cisco ASA 5580 Adaptive Security Appliance Command Line Configuration Guide, Version 8.1
Addresses, Protocols, and Ports

This page has a very good list of the TCP and UDP port numbers for a multitude of different protocols.

If you want a quick and dirty port list, then this tip from CCIE2Be (I found it via is a great choice.

I had a filtering task that said to allow H323 Traffic to a specific vlan. Well…what ports does H323 use? I could not find it on the DocCD but I remembered a show command that will let us know:

r1#sh ip nbar port-map h323


port-map h323                     udp 1300 1718 1719 1720 11720
port-map h323                     tcp 1300 1718 1719 1720 11000 – 11999

Some other examples:

r6# sh ip nbar port-map sip
port-map sip                      udp 5060
port-map sip                      tcp 5060

r6#sh ip nbar port-map skinny
port-map skinny                   tcp 2000 2001 2002

r6# sh ip nbar port-map snmp
port-map snmp                     udp 161 162
port-map snmp                     tcp 161 162

r6# sh ip nbar port-map bgp
port-map bgp                      udp 179
port-map bgp                      tcp 179

r6#sh ip nbar port-map rip
port-map rip                      udp 520

show ip nbar port-map


December 28, 2008

Lab Tip: Start Your Troubleshooting With The Basics

I was racking my brains (what little I have…as you’ll soon see) as to why I couldn’t get my EIGRP adjacencies to come up.  Everything was fine up until I configured rotating keys:

key chain KEY_ROTATION
 key 10
  accept-lifetime 00:00:00 Jan 1 2008 00:15:00 Jan 1 2030
  send-lifetime 00:00:00 Jan 1 2008 00:05:00 Dec 31 2030
 key 20
  accept-lifetime 00:00:00 Jan 1 2030 infinite
  send-lifetime 00:00:00 Jan 1 2030 infinite

I removed and re-added the keys.  I made sure that the clocks on the routers were all set to the same time.  I shut/no shut interfaces.  I added and removed the ‘ip authentication’ commands on the interfaces.  I checked for spaces after the key chain name.  I even took out key 20 so that there was only one key.  Nothing worked.  WTF?!?  This shouldn’t be so difficult.

Then I finally ran a simple verification command that I should have run much, much earlier:

R2#sh key chain KEY_ROTATION
   * key 10 — text “(unset)”
        accept lifetime (00:00:00 UTC Jan 1 2008) – (00:15:00 UTC Jan 1 2030) [valid now]
        send lifetime (00:00:00 UTC Jan 1 2008) – (00:05:00 UTC Dec 31 2030) [valid now]
  * key 20 — text “(unset)”
        accept lifetime (00:00:00 UTC Jan 1 2030) – (infinite)
        send lifetime (00:00:00 UTC Jan 1 2030) – (infinite)

Notice the “(unset)” bit?  Yup.  I forgot to CONFIGURE THE PASSWORD!!!!  I was concentrating so hard on getting the accept and send lifetimes correct that I forgot to configure the most important bit.

The reason that I’m advertising my idiocy to the world is because it’s important in the lab (and in ‘real life’) to make sure that you verify the basics before you start ripping apart configurations and pulling out your hair.  I seriously wasted about 20 minutes on this mess.  In the lab I would have been under much, much more stress and those 20 minutes (besides being about 5% of my total available lab time) could easily have stretched out longer…or I could have moved on and lost some “easy” points.  😦

December 26, 2008

Lab Tip: Finding The ifIndex of an Interface

Often times you’ll run across a task where you know how to do the configuration, but you have no idea how to find a piece of necessary information.  I hit a task like that recently:

The RESTRICTED view should include the branch “ifEntry.*.n”, where n is the ifIndex of R6’s serial interface.

This was part of a larger SNMP task.  I had no problem completing the task except that I had no idea how to find the ifIndex of an interface.

Luckily, a quick trip to the Interwebs provided an answer:

The CLI command show snmp mib ifmib ifindex allows you to view the SNMP Interface Index Identification numbers assigned to interfaces and subinterfaces. An NMS is not required.

Once snmp-server enable traps (or informs) is configured, this command will work to list all ifindex values, or to show the value for a particular interface.

Darrell A. Escola
B.Sc. Information Technology

You can find the documentation here.

As stated, if snmp-server traps (or informs) are not enabled, then this command will not provide output:

r6#show snmp mib ifmib ifindex
%SNMP agent not enabled

You can enable traps with this command:

r6(config)#snmp-server enable ?
informs Enable SNMP Informs
traps Enable SNMP Traps

But this will fill your configuration with a ton of snmp-server traps statements:

r6(config)#do sh run | i snmp|trap
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps vrrp
snmp-server enable traps ds1
snmp-server enable traps tty
snmp-server enable traps eigrp
snmp-server enable traps casa
snmp-server enable traps xgcp
snmp-server enable traps bulkstat collection transfer
snmp-server enable traps isdn call-information
snmp-server enable traps isdn layer2
snmp-server enable traps isdn chan-not-avail
snmp-server enable traps isdn ietf
snmp-server enable traps icsudsu
—output truncated—

Simply disabling the traps removes them from the configuration, but also leaves the SNMP agent enabled (you can also achieve this by configuring and then removing an SMTP community string):

r6(config)#no snmp-server enable traps
% This command also disables previously enabled shamlink config error traps.
r6(config)#do sh run | i snmp|trap
r6(config)#do show snmp mib ifmib ifindex
Null0: Ifindex = 7
Serial0/0: Ifindex = 1
FastEthernet1/0: Ifindex = 5
FastEthernet2/0: Ifindex = 6
Serial0/1: Ifindex = 2
Serial0/2: Ifindex = 3
Serial0/3: Ifindex = 4

Now we that know what the Ifindex value is we can finish our configuration.

December 24, 2008

Lab Tip: Absolute vs Delta

If you’ve ever come across a RMON task in a practice lab, you probably find that the hardest part of the configuration is determining whether the value being measured is a delta (change over time) or an absolute value.  You could get the configuration completely correct except that you chose the wrong measurement option (I’ve done it plenty of times).

A recent email on the GroupStudy list defined the difference between these two modes very succinctly and very well:

Delta : For values that always increase
Absolute : For values that can increase or decrease

CPU utilization can go up or down (0% to 100%) so it would be an absolute value.  Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value.  We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.

One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained.  If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’.  For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared).  This is either a poorly written task…or more likely you should use ‘delta’.

*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach  certain value (say 1 million) but that’s a pretty strange/ineffective alarm.

December 22, 2008

Lab Tip: Choosing The Correct Banner

Banners!!!!  Arg.  Cisco IOS lets you present different messages depending on which method is being used to access the device.  Without spending time searching the Cisco Documentation (and often after searching the documentation) it’s hard to determine which banner type should be used to fulfill a certain task.  You’ll see task like this:

A banner message should be displayed to all users that telnet into the router that says “Stay out of my router haXors!!!”

Here are our banner choices:

Rack1R5(config)#banner ?
LINE            c banner-text c, where ‘c’ is a delimiting character
exec Set EXEC process creation banner
incoming Set incoming terminal line banner
login Set login banner
motd Set Message of the Day banner
prompt-timeout Set Message for login authentication timeout
slip-ppp Set Message for SLIP/PPP

[Note: This is not a comprehensive list as there are banners like ‘aaa authentication banner’, but these are the ones you’re likely to use for the Routing and Switching lab (although ‘slip-ppp’ is unlikely)]

So which one to use?

Configure them all and see which ones appear:

Rack1R5(config)#banner #no option#
Rack1R5(config)#banner exec #exec#
Rack1R5(config)#banner incoming #incoming#
Rack1R5(config)#banner login #login#
Rack1R5(config)#banner motd #motd#
Rack1R5(config)#banner prompt-timeout #prompt-timeout#
Rack1R5(config)#banner slip-ppp #slip-ppp#

Now telnet into the router:

Trying … Open

User Access Verification


We can see that both the motd and login banners are displayed before logging into the router (and the ‘exec’ banner after successfully logging in), with the MOTD being displayed first.  [Note: r5 has ‘login’ configured under the vty lines in this example]  At this point the task becomes an “Ask the proctor” task to determine if you should used the MOTD or the ‘login’ banner.  🙂

If we remove the ‘login’ option from R5’s vty line then we do not see the ‘login’ banner displayed:

Rack1R5(config)#do sh run | sec line vt
line vty 0 4
password cisco
Rack1R5(config)#line vty 0 4
Rack1R5(config-line)#no login

Trying … Open

But now we see the MOTD and the ‘exec’ (because we are automatically in ‘exec’  mode (user exec mode in this case)) banners when we telnet to the device.

Read more about configuring banners at Enabling Terminal Banners

December 16, 2008

Lab Tip: A Use For The Useless Tc Command

CCIE candidates who have spent any time playing with Frame Relay Traffic Shaping know that the ‘frame tc’ command is worthless and that you need to set the Tc by altering the Bc and/or CIR.  But I did discover a use for this command.

Say you get a task like this:

“Use the lowest interval (Tc) available”

If you have this value memorized, then you’re golden.  But if you don’t then you might spend some of your valuable lab time searching the documentation for this value….OR you could turn to the ‘frame tc’ command for help:

Rack1R3(config)#map-class frame TEST
Rack1R3(config-map-class)#frame tc ?
<10-10000>  Tc, milliseconds

Ah.  We can see that the lowest interval available is 10 milliseconds.  The maximum is the insanely high 10,000 milliseconds (10 seconds).

Next Page »

Blog at