CCIE Pursuit Blog

April 28, 2009

Cisco Documentation: New Configuration Guide Security Categories

Every CCIE candidate should know by now that they’ll want to be intimately familiar with the Cisco Documentation site before attempting the lab exam.  You’ll also want to note that the documentation site is still changing.  Thankfully Cisco denotes the changes with a bright red ‘New!’.

Case in point: I was looking up some CBAC information this morning and found that the 12.4 Security Configuration Guide documentation had been reorganized:

Security and VPN

* Cisco IOS Security Configuration Guide: Secure Connectivity, Release 12.4 New!
* Cisco IOS Security Configuration Guide: Securing the Control Plane, Release 12.4 New!
* Cisco IOS Security Configuration Guide: Securing the Data Plane, Release 12.4 New!
* Cisco IOS Security Configuration Guide: Securing User Services, Release 12.4 New!

It’s a very good idea to check the location of various technologies (even the ones you know cold) on the Cisco Documentation site in the days before you take the lab.  It’s better to spend a few minutes navigating a new structure outside of the lab than in the lab.  🙂

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)

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 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).

December 12, 2008

Lab Tip: Review What You’ve Typed Before Blaming IOS

I was trying to apply an IPv6 address to an interface and have it use EUI-64.  For some reason I was not able to get the ‘eui-64’ option to show up.

I immediately assumed that this was a Dynamips error:

Rack1R4(config-if)#ipv add 2001:CC1E:x:404::/64 ?
X:X:X:X::X/<0-128>  IPv6 prefix

Rack1R4(config-if)#ipv add 2001:CC1E:x:404:: ?
X:X:X:X::X/<0-128>  IPv6 prefix

Rack1R4(config-if)#ipv add 2001:CC1E:x:404::/64 ?
X:X:X:X::X/<0-128>  IPv6 prefix

Rack1R4(config-if)#ipv add 2001:CC1E:x:404::/64
% Incomplete command.

DOH!!!!  That ‘x’ was supposed to be a ‘1’ (x is a variable that you’re supposed to fill in with your rack number).  I was a bit too literal in my task interpretation.  🙂  This was a PEBKAC error and not a Dynamips issue.

But ‘x’ is not a hexadecimal character (0 – 9 and A – F) so why didn’t IOS throw an error?

Rack1R4(config-if)#ipv6 address ?
WORD                General prefix name
X:X:X:X::X          IPv6 link-local address
X:X:X:X::X/<0-128>  IPv6 prefix
autoconfig          Obtain address using autoconfiguration

Ah. IOS thought that I had configured the “general prefix name” and was expecting the address to follow.

I typed the address correctly and all was well:

Rack1R4(config-if)#ipv6 address 2001:CC1E:1:404::/64 eui-6

December 11, 2008

Lab Tip: Check For Redistribution On A Device

Filed under: Cisco,Cisco Certification,IOS,Lab Tips — cciepursuit @ 1:05 pm
Tags: , , , , ,

This can be done by many methods, but prefer to use “show run | i router|redist” to see if there is any redistribution currently on the device.  Since all routing processes include the term “router” and all redistributions include…well “redistribution”, this command will show you which – if any – redistributions are currently configured on a device:

Rack1R6(config)#do sh run | i router|redist
router eigrp 10
router ospf 100
redistribute connected subnets route-map CONN->OSPF

In this case we can see that we are redistributing connected routes into OSPF using a route-map.  Good to know before beginning mutual redistribution.

Rack1R5#sh run | i router|redist
router eigrp 100
router ospf 100

In this case we can see that there is no redistribution currently occurring on this device.

I run through this check any time I am about to configure redistribution.  I also note any redistributions on my lab topography, but it’s always good to “measure twice, cut once” 🙂

Next Page »

Create a free website or blog at