CCIE Pursuit Blog

December 31, 2008

Would You Like That Abbreviated Or Spelled Out?

Filed under: Cisco,Cisco Certification,IOS,OT: Humor — cciepursuit @ 8:00 am
Tags: , , , , ,

My 3560 is so nice.  It gives me the option of debugging EIGRP based on the AS number OR the Autonomous System number.  :-)

SW2#debug ip eigrp ?
<1-65535>      AS number
<1-65535>      Autonomous System
neighbor       IP-EIGRP neighbor debugging
notifications  IP-EIGRP event notifications
summary        IP-EIGRP summary route processing
vrf            Select a VPN Routing/Forwarding instance
<cr>

SW2#sh ver | i IOS|image
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)
System image file is “flash:c3560-ipservicesk9-mz.122-25.SEE2/c3560-ipservicesk9-mz.122-25.SEE2.bin”

December 30, 2008

Secrets Of The EIGRP Offset-List Command

The following post is loooooong and of no interest to 99.9999999999% of the world.  I was going over EIGRP commands and had a problem with an EIGRP offset-list not altering the EIGRP metric the way that it should have.  In the process of playing with this command I think that I’ve found the method that this command uses to alter the EIGRP metric of a route.

I did warn you that this was only interesting to a handful of geeks.

Here’s the network topology.  Really basic:

r1————r2

r1 and r2 are connected by a single serial link (s0/0 on both devices).  Both routers running EIGRP on all interfaces.  There are 3 loopbacks being advertised on each device.

r1#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        27       0/15          91           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r1#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.2 Se0/0 13 00:01:47   27   200  0  3

r1#sh ip route ei
D    222.222.222.0/24 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0
22.0.0.0/24 is subnetted, 1 subnets
D       22.22.22.0 [90/2297856] via 10.1.12.2, 00:01:55, Serial0/0

r2#sh ip ei int
IP-EIGRP interfaces for process 100

Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0 1 0/0        34       0/15         147           0
Lo0                0        0/0         0       0/10           0           0
Lo1                0        0/0         0       0/10           0           0
Lo2                0        0/0         0       0/10           0           0

r2#sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   10.1.12.1 Se0/0 13 00:02:15   34   204  0  3

r2#sh ip route ei

1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
111.0.0.0/24 is subnetted, 1 subnets
D       111.111.111.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0
11.0.0.0/24 is subnetted, 1 subnets
D       11.11.11.0 [90/2297856] via 10.1.12.1, 00:02:19, Serial0/0

Okay to start with let’s see the routing information for net 1.1.1.0/24 on r2:

r2#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2297856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:03:17 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:03:17 ago, via Serial0/0
Route metric is 2297856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

On r2 let’s add 100 to the EIGRP metrics of all EIGRP routes advertised in s0/0 from r1:
[NOTE: access-list 0 selects all networks]

r2(config)#router ei 100
r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 00:15:01.055: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2297956, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:08 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:08 ago, via Serial0/0
Route metric is 2297956, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Interesting…we’ve added 100 to the EIGRP metric as expected.  The ‘total delay’ has also increased by 3 microseconds (not expected).  It seems that the EIGRP offset-list alters the EIGRP variable in order to change the overall EIGRP metric.  EIGRP uses this easy to remember :-) equation to calculate its metric:

If k5 equals 0, the composite EIGRP metric is computed according to the following formula:
metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay]

If k5 does not equal zero, an additional operation is performed:
metric = metric * [k5/(reliability + k4)]

This led me to wonder what would happen if we took delay out of the EIGRP equation.  We can do that by setting the EIGRP K-Value for delay to 0 and just leaving bandwidth K-Value (we’ll need to do this on both routers):

r1(config)#  router ei 100
r1(config-router)#  metric weights 0 1 0 0 0 0

r2(config)#router ei 100
r2(config-router)#metric weights 0 1 0 0 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0

Let’s see our metric before applying the offset-list:

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:32 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:32 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Okay, let’s reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:04:44.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 1657856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:10 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:10 ago, via Serial0/0
Route metric is 1657856, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

BOOYAH!  The offset-list is supposed to increase the EIGRP metric by 100.  We can see that the metric did NOT change (still 1657856), BUT the total delay increased by 3 microseconds.  It looks like we’ve discovered the mechanism used by the EIGRP offset-list to change the EIGRP metric.  We’ve also discovered that setting the delay K-Value to zero “breaks” the offset-list function.

One last experiment.  Let’s see if the offset-list is intelligent enough to handle a delay K-Value of more than 1:

r1(config-router)#metric weights 0 1 0 4 0 0

r2(config-router)#metric weights 0 1 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=1, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 4217856, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:01:09 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:01:09 ago, via Serial0/0
Route metric is 4217856, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:11:56.439: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 4218256, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:07 ago, via Serial0/0
Route metric is 4218256, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Weird.  I would have thought that this would have worked as we have our default K-Values but have just increased the weight of delay 4 times.  We can see that the delay was once again increased by 3 microseconds, but the overall metric was unaffected.  Weird.

Thank you to reader Rich for pointing out that 4217856 and 4218256 are NOT the same value.  :-)  The EIGRP metric increased by 400 instead of the 100 that we specified in the offset-list.  That’s because the K-Value for delay is set to 4 times the default.

Hmmm…one more experiment.  Let’s set the delay K-Value back to 1 but make it the only variable used for the EIGRP metric:

r1(config-router)#metric weights 0 0 0 1 0 0

r2(config-router)#metric weights 0 0 0 1 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 640000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:33 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:33 ago, via Serial0/0
Route metric is 640000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Let’s reapply the offset-list and see what happens:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:22:54.319: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 640100, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 640100, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

It worked.  So we don’t need to have the bandwidth K-Value “turned on” for the offset-list to work.

Last experiment…I promise.  Let’s set the delay K-Value to 4 and set the other K-Values to 0:

r1(config-router)#metric weights 0 0 0 4 0 0

r2(config-router)#metric weights 0 0 0 4 0 0
r2(config-router)#no offset-list 0 in 100 s0/0

r2(config-router)#do sh ip proto | i EIGRP metric weight
EIGRP metric weight K1=0, K2=0, K3=4, K4=0, K5=0

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2560000, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:14 ago, via Serial0/0
Route metric is 2560000, traffic share count is 1
Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Reapply the offset-list:

r2(config-router)#offset-list 0 in 100 s0/0

*Mar  1 03:33:52.279: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Serial0/0) is resync: route configuration changed

r2(config-router)#do sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via “eigrp 100″, distance 90, metric 2560400, type internal
Redistributing via eigrp 100
Last update from 10.1.12.1 on Serial0/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.1.12.1, from 10.1.12.1, 00:00:06 ago, via Serial0/0
Route metric is 2560400, traffic share count is 1
Total delay is 25003 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Ah hah!  The metric changed by 400 instead of 100 (as we had configured it to be offset).  I think that this is pretty good evidence that the EIGRP offset-list only alters the EIGRP delay variable and is only accurate when that K-Value is set to 1.

I don’t think that this will affect you in real life (who’s changing K-Values and using offset-lists with EIGRP?) but it could possibly come up in a lab.  I could forsee a task that has you change the K-Values and then another task that has you altering EIGRP metrics (probably for some evil unequal-cost load-balancing task).  At least now you’ll know why your perfectly executed offset-list solution has failed.  :-)

December 29, 2008

I Love The Nightlife, I Got To Boogie

Filed under: OT: Humor — cciepursuit @ 4:57 pm
Tags:

Sometimes search AI is not so intelligent…or I secretly harbor a desire for mirrored balls, crap music, and cocaine  :-)

No matches found for “Cisco Systems”
Did you mean: disco systems

Studio 54(00) maybe?

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-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
MCSE, MCDBA, MCSD

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 23, 2008

Question Of The Day: 23 December, 2008

Your boss wants the following information displayed whenever someone connects to router r1 via telnet:

“This device belongs to cciepursuit.com  It is most likely poorly protected and congfigured.  Hack away!!!”

Telnet users must login to r1 with a username of ‘TELNET’ password of ‘CISCO’.  Your boss then wants the following message displayed:

“Congratulations on hacking into r1.cciepursuit.com via line X!!!” where X = the line number that the user is connected to r1 on.

Furthermore he wants users logging into r1 via the console line to automatically be in privileged exec mode and to only see the line:

“Congratulations on hacking into r1.cciepursuit.com via line X!!!” where X = the line number that the user is connected to r1 on.

Just to make your life extra difficult, he is considering changing the domain name from ‘cciepursuit.com’ to ‘cciepursuitsucks.net’ as well are renaming all of the devices in the format of ‘RouterX’.  He wants your configuration to dynamically adapt to these stupid changes.

————

Previous Question of the Day:

Given the following output:

R1#show backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             waiting to revert (292 more seconds)

Which of the following is configured on R1?

A)
interface Serial1/0.1
backup delay 60 300
backup interface Serial1/1

B)
interface Serial1/0.1
backup delay 300 0
backup interface Serial1/1

C)
interface Serial1/1
backup delay 60 300
backup interface Serial1/1

D)
interface Serial1/1
backup delay 300 0
backup interface Serial1

Answer %
A 56%
B 26%
C 6%
D 9%

The answer:

A)
interface Serial1/0.1
backup delay 60 300
backup interface Serial1/1

From the output of the ‘show backup’ command we can see that the primary interface is Serial1/0.1 and the secondary(backup) interface is Serial1/1.  When configuring the ‘backup interface’ command, you configure the secondary interface under the primary interface.  We can throw out answers B and C at this point.

The output of the ‘show backup’ command shows the status as ‘waiting to revert (292 more seconds)’.  From this information we can tell that there has been a ‘backup delay’ value configured.

The sucky thing about the ‘backup delay’ command is that the IOS help is pretty worthless.  You need to know that the first value that you configure is the delay between the time that the primary interface goes down and the secondary interface comes up.  The second value is just the opposite: the delay between the time that the secondary interface goes down and the interface comes up.  Cisco refers to these values as the enable-delay-period and the disable-delay-period :

backup delay {enable-delay-period | never} {disable-delay-period | never}
no backup delay {enable-delay-period | never} {disable-delay-period | never}

Syntax Description
enable-delay-period – Number of seconds that elapse after the primary line goes down before the Cisco IOS software activates the secondary line.
disable-delay-period – Number of seconds that elapse after the primary line comes up before the Cisco IOS software deactivates the secondary line.
never – Secondary line is never activated or deactivated.

The default values are 0.  You can also chose a value of never…for whatever reason.

R1(config)#int s1/0.1
R1(config-subif)#backup ?
active     Configure an interface as an active backup
delay      Delays before backup line up or down transitions
interface  Configure an interface as a backup

R1(config-subif)#backup delay ?
<0-4294967294>  Seconds

R1(config-subif)#backup delay 60 ?
<0-4294967294>  Seconds

R1(config-subif)#backup delay 60 300 ?
<cr>

R1(config-subif)#backup delay 60 300

In our example we know that the disable-delay-period must be greater than 292 seconds.  The enable-delay-period can be anything (other than ‘never’).  This means that our answer must be A (‘backup delay 60 300′).

Here are status values based on the interface states:

Primary interface up:

R1#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             normal operation

Primary interface down (enable-delay-period configured):

R1#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             waiting to backup (57 more seconds)

Primary interface down – secondary interface up:

R1#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             backup mode

Primary interface down (disable-delay-period configured):

R1#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             waiting to revert (289 more seconds

backup interface

backup delay

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:

Rack1R1#telnet 150.1.5.5
Trying 150.1.5.5 … Open
motdlogin

User Access Verification

Password:
exec
Rack1R5>en
Password:
Rack1R5#

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
login
Rack1R5(config)#line vty 0 4
Rack1R5(config-line)#no login

Rack1R1#telnet 150.1.5.5
Trying 150.1.5.5 … Open
motdexec
Rack1R5>

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 18, 2008

Question Of The Day: 18 December, 2008

Given the following output:

R1#show backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial1/0.1         Serial1/1             waiting to revert (292 more seconds)

Which of the following is configured on R1?

A)
interface Serial1/0.1
 backup delay 60 300
 backup interface Serial1/1

B)
interface Serial1/0.1
 backup delay 300 0
 backup interface Serial1/1

C)
interface Serial1/1
 backup delay 60 300
 backup interface Serial1/1

D)
interface Serial1/1
 backup delay 300 0
 backup interface Serial1/1

Last QoD:

Assume that OSPF was configured on the router after any changes were made to the interfaces on R1.

Given the following information:

R1#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            155.1.146.1     YES NVRAM  up                    up
Serial0/1                  155.1.13.1      YES NVRAM  up                    up
Loopback0                  150.1.1.1       YES NVRAM  administratively down down

R1#sh run | sec router ospf
router ospf 100
log-adjacency-changes
network 155.1.13.1 0.0.0.0 area 0

Answer %
155.1.146.1 41%
150.1.1.1 40%
155.1.13.1 18%
0.0.0.0 1%

The answer: 155.1.146.1

The algorithm for selecting the OSPF router-id is basically:

1) If there is an OSPF router-id configured under the routing process use that.
2) If not, then select the highest active loopback* address
3) If no active loopbacks, then choose the highest active interface* address.

*These do not need to running OSPF

In this example there is no router-id configured under the routing process so the router looks for an active loopback.  The loopback is administratively shut down so it goes to the third step and chooses the highest active interface, which in this case is fa0/0’s IP address of 155.1.146.1

R1#sh ip protocol | section 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 155.1.146.1   
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    155.1.13.1 0.0.0.0 area 0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 110)

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 »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 114 other followers