CCIE Pursuit Blog

August 11, 2007

show interface [interface] counters etherchannel

Filed under: Cisco,Cisco Certification,Cool Commands,Switching,Tech Tips — cciepursuit @ 3:09 pm

I was mucking with etherchannel today and discovered a cool command that I was not aware of: show interface [interface] counters etherchannel.

You can run this command on your port-channel interface:

sw4#sh int po1 count ether

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1                23863            15           229             0
Fa0/19           1899894           835         18864             0
Fa0/20           1903864           835         18862             5
Fa0/21           1945733           835         19307             5

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1                 3653            15            14             0
Fa0/19            181124           834           533             5
Fa0/20            171050           834           494             0
Fa0/21            169510           834           469             0

If you run it on one of the bundled links, you’ll get an error message:

sw4#sh int fa0/19 count ether
Etherchannel not enabled on this interface

Clearing the counters for this command takes  a bit of work.  If you clear the counters on the port-channel interface, it will not clear the counters on the individual bundled links:

sw4#clear count po1
Clear “show interface” counters on this interface [confirm]
sw4#
*Mar  1 02:20:57: %CLEAR-5-COUNTERS: Clear counter on interface Port-channel1 by console
sw4#sh int po1 count eth

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1                 1504             3            13             0 <-cleared
Fa0/19           1900270           838         18865             0
Fa0/20           1904240           838         18863             5
Fa0/21           1959175           838         19447             5

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1                    0             0             0             0 <-cleared
Fa0/19            181500           837           534             5
Fa0/20            171426           837           495             0
Fa0/21            169886           837           470             0

You can clear each bundled link on its own:

sw4#clear count fa0/19
*Mar  1 02:25:35: %CLEAR-5-COUNTERS: Clear counter on interface FastEthernet0/19 by console
sw4#sh int po1 count eth

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1               136047            87          1311             0
Fa0/19                94             1             0             0 <-cleared
Fa0/20           1909733           866         18877             5
Fa0/21           2082732           866         20717             5

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1                16479            84            42             0
Fa0/19                 0             0             0             0 <-cleared
Fa0/20            176919           865           509             0
Fa0/21            175379           865           484             0

You can clear both the port-channel and the bundled links’ counters all at once with “clear counters”.  Personally, I very rarely use that command.  I feel that it’s like dropping a nuke on a mosquito.  Sure you clear the counters that you want cleared, but you also destroy a ton of historical data by wiping out the all of the counters.  I hate trying to troubleshoot an issue after another engineer has run this command.  But if you must use it 🙂

sw4#clear count
Clear “show interface” counters on all interfaces [confirm]
*Mar  1 03:40:48: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
sw4#sh int po1 count eth

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1                 1222             0            13             0
Fa0/19                 0             0             0             0
Fa0/20                 0             0             0             0
Fa0/21              1222             0            13             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1                    0             0             0             0
Fa0/19                 0             0             0             0
Fa0/20                94             1             0             0
Fa0/21                94             1             0             0

You can use this command to illustrate the method that the switch is using to “load balance” over the etherchannel links:

First, let’s create an SVI on each side of the Etherchannel
sw4(config)#vlan 100
sw4(config-vlan)#int vlan 100
sw4(config-if)#ip address 100.0.0.4 255.255.255.0

sw3(config)#vlan 100
sw3(config-vlan)#int vlan 100
sw3(config-if)#ip address 100.0.0.3 255.255.255.0

Let’s clear etherchannel counters, then ping the hell out of the 100.0.0.3 address:
sw4#sh int po1 count eth

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1                 3760             0            40             0
Fa0/19               188             2             0             0
Fa0/20                94             1             0             0
Fa0/21              5828             1            61             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1                  282             3             0             0
Fa0/19               188             2             0             0
Fa0/20               188             2             0             0
Fa0/21                94             1             0             0

sw4#ping 100.0.0.3 re 10000 si 1500
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
—–output truncated—–
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 1/2/28 ms

Now let’s look at the etherchannel counters:
sw4#sh int po1 count eth

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
Po1             15512981         10018           323             0
Fa0/19          15481343         10008             3             0 <-note
Fa0/20              1249             7             3             0
Fa0/21             32739             7           338             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
Po1             15483747         10021             9             0
Fa0/19          15481343         10008             3             0 <-note
Fa0/20              1343             8             3             0
Fa0/21              1249             7             3             0

So why did one interface handle all of the pings?  Let’s use another nifty little command to find out:

sw4#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-mac):
Non-IP: Source MAC address
  IPv4: Source MAC address
  IPv6: Source IP address

sw4#sh arp | i 100.0.0.4
Internet  100.0.0.4               –   000a.8a1c.c400  ARPA   Vlan100

We are “load balancing” based on the source mac-address.  The ping is sourced by 100.0.0.4 and the source-mac address will not change, so all of our pings took the same route.  This is good to know for the real world as well.  Depending on the traffic source, that 8-gig etherchannel you set up to the server may only be giving you 1 gig of possible bandwidth.  🙂


Cisco Documentation:

show interfaces counters

July 20, 2007

Recovering Cisco Encrypted Passwords

Filed under: Cisco,Cool Commands,Tech Tips — cciepursuit @ 3:55 pm

Here a cool tip from the Group Study list.  If you need to recover a Cisco “service password-encryption” password (not a secret password) AND you don’t have access to a type 7 password decrypter – you can use the following method to decrypt the password:

r1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r1(config)#username ivan pass cisco
r1(config)#service password-encryption
r1(config)#^Z
r1#sh run | i ivan
username ivan password 7 01100F175804
r1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r1(config)#key chain REVERSE_ENG
r1(config-keychain)#key 1
r1(config-keychain-key)#key-string 7 01100F175804
r1(config-keychain-key)#^Z
r1#
r1#sh key chain REVERSE_ENG
Key-chain REVERSE_ENG:
    key 1 — text “cisco”
        accept lifetime (always valid) – (always valid) [valid now]
        send lifetime (always valid) – (always valid) [valid now]

July 17, 2007

Must Use Command: Filtering output with the “section” command

Filed under: Cool Commands,IOS,Lab Tips,Tech Tips — cciepursuit @ 12:28 pm

Every once in a great while, an IOS command (or command option) comes along that completely changes the way that you work.  For me, the latest one of these command is the “section” option.  A co-worker of mine first pointed out this filtering option about 6 months ago.  Ever since then I have been using it daily.

You need to be running fairly recent code to use this filtering option(12.3(2)T ).  The Cisco documention on this option is a little light on details:

In many cases, it is useful to filter the output of a show command to match a specific expression. Filtering provides some control over the type and amount of information displayed by the system. The show section command provides enhanced filtering capabilities by matching lines in the show command output containing specific expressions as well as matching any entries associated with those expressions. Filtering is especially useful, for example, when displaying large configuration files using the show running-configuration command or the show interfaces command.

I’ve found that Ivan Pepelnjak’s explanation is much better:

A section starts with a line with no leading blank and includes all lines following it until the start of the next section. The section filter is commonly used to filter router configuration printouts, but can also be used for any other show command.

However you want to describe it, the command is pure gold.  My favorite use of this filtering option is when I want to see the configuration for a given routing protocol’s process statement.  In the past you could issue the “show run | begin eigrp” in order to see the output, but that meant an entire screen of output and – since the search ended with the first instance of “eigrp” it encountered in the running-configuration –  you would sometimes stop your search at an interface level command.  Using “sh run | section eigrp” is much cleaner and returns results similar to the “show run interface sx/x” command.

Let’s see only the BGP process from the running-configuation:
r1#sh run | sec bgp
router bgp 12
 no synchronization
 bgp log-neighbor-changes
 network 137.1.200.0 mask 255.255.255.0
 neighbor 137.1.200.2 remote-as 12
 no auto-summary

r1#

How beautiful is that?!! <wipes tears from eyes>

Sometimes you get a little bit of weirdness in your output:

r1#sh run | sec rip
 description -> VLAN11 137.1.1.0/24
 description ->r2 FR dlci 102

router rip
 network 137.1.0.0
 no auto-summary
r1#

I’m assuming that the descriptions were included because of the “rip” in the word “description”.

Another great use is to pull protocol-specific output from the “show ip protocols” output.  On this router we are running a slew of different routing protocols:

r1#sh ip protocols summary
Index Process Name
0     connected
1     static
5     bgp 12
2     rip
4     eigrp 100
3     ospf 100

If we want to see detailed OSPF information, we would need to either use the “show ip protocols” command and then scroll through screens of information:

r1#sh ip protocols
Routing Protocol is “bgp 12”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled
  Automatic route summarization is disabled
  Neighbor(s):
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    137.1.200.2
  Maximum path: 1
  Routing Information Sources:
    Gateway         Distance      Last Update
    137.1.200.2          200      00:10:08
  Distance: external 20 internal 200 local 200

Routing Protocol is “rip”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 26 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       1     1 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/0             1     1 2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    137.1.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    137.1.200.2          120      00:00:05
  Distance: (default is 120)

Routing Protocol is “eigrp 100”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 100
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    137.1.1.0/24
    137.1.200.0/24
  Routing Information Sources:
    Gateway         Distance      Last Update
    137.1.200.2           90      00:17:48
  Distance: internal 90 external 170

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 137.1.200.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    137.1.1.0 0.0.0.255 area 0
    137.1.200.0 0.0.0.255 area 0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.16.2.1           110      00:18:04
  Distance: (default is 110)

Yuck!!!  Or we could issue the “show ip protocols | b ospf” command.  This would be fine in this case as OSPF is the last protocol listed, but if we did “sh ip prot | b rip” we would still end up with a screen’s worth of information.  BUT if we use our good friend “section” then we can pull only the details that we want:

All I want is the OSPF-specific information:
r1#sh ip prot | sec 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 137.1.200.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    137.1.1.0 0.0.0.255 area 0
    137.1.200.0 0.0.0.255 area 0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.16.2.1           110      00:19:00
  Distance: (default is 110)
r1#

SWEET!!!

Another great use is to pull interface configuration details.  This is a better option than “show run interface Serialx/x” in those cases where you want to see the running-configuration for ALL Serial interfaces instead of just a single Serial interface.  In this case you need to be aware that the section option IS case-sensitive:

No output because “serial” does not begin with a capital “S”:
r1#sh run | sec serial
r1#

Here’s the correct form:
r1#sh run | sec Serial
interface Serial0/0
 description ->r2 FR dlci 102
 ip address 137.1.200.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-point
 frame-relay map ip 137.1.200.2 102 broadcast
 no frame-relay inverse-arp
 frame-relay lmi-type cisco
interface Serial0/1
 no ip address
 shutdown
r1#

One more advantage that this command has over the “show run interface Serialx/x” command is that you can use the “section” option to filter on a single interface and it will return all of the subinterfaces configured under that interface as well.  How cool is that?!

Cool….use this to get your physical and subint configs:

Remember: use an uppercase “S” and no space:
r1#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.1 multipoint
 ip address 10.0.0.1 255.0.0.0
 frame-relay map ip 10.0.0.2 102 broadcast

Once you start using this command you will wonder how you ever lived without it.  You’ll undoubtedly find many more uses than the ones I have listed here.  Just keep in mind that you will need to be running pretty recent code for IOS to understand this command.


Cisco Documentation:show <command> section

show ip route [network] [network mask] longer-prefixes

Filed under: Cool Commands,IOS — cciepursuit @ 11:46 am

Here’s a strange variation of the “show ip route” command that I stumbled across the other day: “show ip route [network] [network mask] longer-prefixes”.  The Cisco documentation is pretty brief:

(Optional) Specifies that only routes matching the ip-address and mask pair should be displayed.

I’m not sure how this is different than the “show ip route [network] [network mask]” command.  Here’s the output that I got when playing with this command:

The 10.2.0.0/16 route is in the routing table (advertised in via RIP).  If I try to do a “show ip route” on the /8 network, I get the following:
r1#sh ip route 10.2.0.0 255.0.0.0
% Subnet not in table

Here’s the output that I get with the “longer-prefixes” option:
r1#sh ip route 10.2.0.0 255.0.0.0 longer-prefixes
—some output truncated—

Gateway of last resort is not set

     10.0.0.0/16 is subnetted, 2 subnets
R       10.2.0.0 [120/1] via 12.0.0.2, 00:00:06, Serial0/0
C       10.1.0.0 is directly connected, FastEthernet0/0

The output makes sense if the “longer-prefixes” option is meant to display all 10.2.0.0 routes with prefixes of 8 or longer (/8 – /32).  The Cisco documentation looks like it is referring to the “show ip route [network] [network mask]” rather than the same command with the “longer-prefixes” option.

Well…it looks like I misinterpreted what this command does.  If you look a little further into the documentation, you’ll find an explanation of the “longer-prefixes” option as well as an example:

The following is sample output using the longer-prefixes keyword. When the longer-prefixes keyword is included, the address and mask pair becomes the prefix, and any address that matches that prefix is displayed. Therefore, multiple addresses are displayed.

In the following example, the logical AND operation is performed on the source address 10.0.0.0 and the mask 10.0.0.0, resulting in 10.0.0.0. Each destination in the routing table is also logically ANDed with the mask and compared to that result of 10.0.0.0. Any destinations that fall into that range are displayed in the output.

Router# show ip route 10.0.0.0 10.0.0.0 longer-prefixes

—some output truncated—

Gateway of last resort is not set

S 10.134.0.0 is directly connected, Ethernet0
S 10.10.0.0 is directly connected, Ethernet0
S 10.129.0.0 is directly connected, Ethernet0
S 10.128.0.0 is directly connected, Ethernet0
S 10.49.246.0 is directly connected, Ethernet0
S 10.160.97.0 is directly connected, Ethernet0
S 10.153.88.0 is directly connected, Ethernet0

In my first example “sh ip route 10.2.0.0 255.0.0.0”, the result of the logical AND would be 10:

00001010 <- 10
11111111 <- 255
________ <-logical AND
00001010 <- 10

So it makes sense that all of the 10.x.x.x networks were shown.


Cisco Documentation:show ip route

July 14, 2007

My Last Warm-Reboot Post – I Promise!

Filed under: Cool Commands,IOS,Tech Tips — cciepursuit @ 7:58 am

I didn’t know that my investigating the warm-reboot command would spawn a trilogy of posts, but I ran across something interesting in my second post and wanted to investigate it further here.  I changed the warm-reboot count from 5 (default) to 1 and was surprised to see that I had to perform a standard reboot to enable the warm-reboot functionality (this is the default behavior when you first initialize warm-reboot) even though warm-reboot was already enabled on the router.  I posted my (poorly formulated) hypothesis:

Let’s change strategies and repeat the above, but this time let’s set the warm-reboot count to 1 and then reload twice:

r2(config)#warm-reboot count 1
Warm reboot will be possible after the next power cycle or reload.

Interesting.  Although warm-reboot was already configured, changing the count value requires that you do a standard reload first (this was not the case when we changed the uptime value).  [NOTE: I actually changed the count and the uptime because I let the uptime be set to the default of 5 minutes (from the previous setting of 120 minutes).  The reason for the standard reload could be due to the change in the count OR because I changed both the count and the uptime.]  It does not clear the historical warm-reboot statistics though.

Since the router told me that I needed to do a standard reload to (re)enable warm-reboot, I did just that.  BUT if I had tried to do a “reload warm” I would have uncovered the “secret” of why the router was trying to reset warm-reboot:

r2#reload warm
Not possible to warm reload.
Reason: Too Many warm reboots have taken place

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 1
Uptime after which warm reboot is safe in case of a crash is 120 (min)

Statistics:

0 warm reboots due to crashes and 1 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

Mystery solved!  Since I had already done 1 warm reboot and then set the maximum warm reboot to 1, I had effectively disabled warm-reboot!  I did not notice this before, because I did a conventional reload instead of requesting a warm reboot.  As you can see, my hypothesis about simply changing the count or changing the count and the uptime at the same time was completely wrong.  The warm-reboot function was “reset” only when I configured the count to be equal to the currently recorded number of warm-reboots (1):

r2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r2(config)#warm count 1 up 120
Warm reboot will be possible after the next power cycle or reload.
r2(config)#warm count 5 up 120
r2(config)#warm count 1
Warm reboot will be possible after the next power cycle or reload.
r2(config)#warm count 5
r2(config)#warm count 6
r2(config)#warm count 4
r2(config)#warm count 3
r2(config)#warm count 2
r2(config)#warm count 1
Warm reboot will be possible after the next power cycle or reload.

One last bit of of warm-reboot information.  If you do a conventional reboot, you will lose your historical warm-reboot statistics:

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 50
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 2 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

“Conventional” reload instead of warm-reboot:
r2#reload
Proceed with reload? [confirm]

*Jul 14 16:12:37: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 50
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 0 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage 


Okay.  That’s all for the warm-reboot command.  I think that I’ve mined that sucker for all it’s worth.  :-)Here are links to the other two posts as well as the Cisco documentation link and the Cisco IOS Hints and Tips entry where I initially learned about this feature:

Happiness Is A Warm Reload

Warm-Reboot Count and Uptime Values

Warm reload

warm-reboot (12.4 documentation)

Warm-Reboot Count and Uptime Values

Filed under: Cool Commands,IOS,Tech Tips — cciepursuit @ 7:35 am

I just recently discovered the “warm-reboot” function.  Upon discovering something new I like to try to “break” it.  In this case I wanted to try to disable the warm-reboot function by exceeding the count and/or uptime values.  Here’s a quick recap of why those values are important (courtesy of Cisco IOS Hints and Tips):

“Of course, the IOS code (depending on platform’s memory management capabilities) or saved data could get corrupted, therefore the warm reload cannot be used continuously (and the router falls back to traditional reload if the router crashes before a specified time interval).”

Let’s test that and see if we can cause the router to bypass the warm-boot.  We should be able to do that by setting the warm-reboot uptime option to a large value and then requesting two consecutive reloads.

Step 1: Maximize the uptime value:
r2(config)#warm-reboot count 5 uptime ?
  <0-120>  Time in minutes, default 5

r2(config)#warm-reboot count 5 uptime 120

Step 2: Reload.  This should be a warm-reboot:
r2#reload warm
Proceed with reload? [confirm]

*Jul 14 12:07:41: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 14 12:08:18: %SYS-6-BOOTTIME: Time taken to reboot after reload =   35 seconds

Step 3: Reload again.  This should NOT be a warm-reboot as the router has not been up for the required 120 minutes:
r2#reload warm
Proceed with reload? [confirm]

*Jul 14 12:09:32: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 14 12:10:08: %SYS-6-BOOTTIME: Time taken to reboot after reload =   35 seconds

Hmmmm….that’s odd.  This was a warm-reboot.

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 120 (min)

Statistics:

0 warm reboots due to crashes and 2 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

Actually it’s NOT odd.  I didn’t understand the uptime parameter properly.  The uptime only comes into play with CRASHES and not warm reboot requests.

Let’s change strategies and repeat the above, but this time let’s set the warm-reboot count to 1 and then reload twice:

r2(config)#warm-reboot count 1
Warm reboot will be possible after the next power cycle or reload.

Interesting.  Although warm-reboot was already configured, changing the count value requires that you do a standard reload first (this was not the case when we changed the uptime value).  [NOTE: I actually changed the count and the uptime because I let the uptime be set to the default of 5 minutes (from the previous setting of 120 minutes).  The reason for the standard reload could be due to the change in the count OR because I changed both the count and the uptime.]  It does not clear the historical warm-reboot statistics though:

***Update – Wrong! Wrong! Wrong!  This behavior is explained here. ***

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 1
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 2 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

Reload 1 (standard):
r2#reload
Proceed with reload? [confirm]

*Jul 14 12:16:35: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

r2#sh log | i %SYS-6-BOOTTIME
*Jul 14 12:18:09: %SYS-6-BOOTTIME: Time taken to reboot after reload =   94 seconds

Interesting.  The warm-reboot statistics are reset now:

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 1
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 0 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

Reload 2 (warm):
r2#reload warm
Proceed with reload? [confirm]

*Jul 14 12:54:24: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 14 12:55:00: %SYS-6-BOOTTIME: Time taken to reboot after reload =   35 seconds

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 1
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 1 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

Reload 3 (should not allow warm-reboot):
r2#reload warm
Not possible to warm reload.
Reason: Too Many warm reboots have taken place

Mission accomplished.  🙂

It looks like the downside to the warm-reboot command is that you can only use the “reload warm” command as many times as is configured with the warm-reboot count variable.  This is so you don’t corrupt your data.  If you find that you’ve used your allotment of warm-reboots, just increase the count:

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 1
Uptime after which warm reboot is safe in case of a crash is 5 (min)

Statistics:

0 warm reboots due to crashes and 1 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

r2#reload warm
Not possible to warm reload.
Reason: Too Many warm reboots have taken place

r2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r2(config)#warm count ?
  <1-50>  Default 5

r2(config)#warm count 50
r2(config)#^Z
r2#wr
Building configuration…

*Jul 14 13:23:42: %SYS-5-CONFIG_I: Configured from console by console[OK]

r2#sh warm | i reboot count
Maximum warm reboot count is 50
r2#reload warm
Proceed with reload? [confirm]
*Jul 14 13:13:08: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

Happiness Is A Warm Reload

Filed under: Cool Commands,IOS,Tech Tips — cciepursuit @ 6:03 am

I was checking out the Cisco IOS Hints and Tricks  (an outstanding blog) and ran across a posting about the “warm-reboot” feature.  As always, go and read the entire entry as it is very well written.  Here’s the skinny on the warm-reboot:

“The theory behind warm reload is simple: the router saves initial data (as stored in IOS image) in a separate memory region and reuses saved data together with IOS code already residing in RAM to restart IOS. Of course, the IOS code (depending on platform’s memory management capabilities) or saved data could get corrupted, therefore the warm reload cannot be used continuously (and the router falls back to traditional reload if the router crashes before a specified time interval).

Warm reload is configured with the warm-reboot count number uptime minutes configuration commands. After it has been configured, a router reload (or power-up) is needed to initialize the saved data region. When the warm reboot is operational (as verified with the show warm-reboot command), you can use reload warm command to start it.”

I jumped on my rack to test this out.  The first router that I tried it on was a 2651XM running 12.4(10) code.  It seems that this command is not available for this router model:

r1#sh ver
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10), RELEASE SOFTWARE (fc1)

System image file is “flash:c2600-adventerprisek9-mz.124-10.bin”

Cisco 2651XM (MPC860P) processor (revision 3.1) with 253952K/8192K bytes of memory.

r1#show w?
whoami  wlccp  wrr-queue

Since this command has been around since 12.3(2), this could just be a case of the model not supporting the command or the memory not being sufficient/capable of supporting the feature. 

I decided to try my 2821 and found that it did support the feature:

r2#sh ver
Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(11)T

System image file is “flash:c2800nm-adventerprisek9-mz.124-11.T2.bin”

Cisco 2821 (revision 53.51) with 249856K/12288K bytes of memory.

r2#sh warm-reboot
Warm Reboot is not enabled

First, let’s reload the router and see how long it takes to recover:

r2#reload
Proceed with reload? [confirm]
*Jul 13 22:28:41: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 22:30:10: %SYS-6-BOOTTIME: Time taken to reboot after reload =   90 seconds

It takes 90 seconds for the router to recover from a conventional reload.  Okay, let’s config this pig:

By default, the warm-reboot option is not enabled:
r2#sh warm-reboot
Warm Reboot is not enabled

Here are the options for the command:
r2(config)#warm-reboot ?
  count   Set max number of continuous warm reboots
  uptime  Set the uptime after which warm reboot is safe in case of a crash
  <cr>

r2(config)#warm-reboot count ?
  <1-50>  Default 5

r2(config)#warm-reboot count 5 uptime ?
  <0-120>  Time in minutes, default 5

Let’s keep the default count, but make the uptime 1 minute:
r2(config)#warm-reboot count 5 uptime 1
Warm reboot will be possible after the next power cycle or reload.

r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)

Warm reboot can take place only after the next power cycle or reload.

The router warns you that you’re going to need to reload once before the warm-reload feature is implemented.  This is good to know.  You could push this config out to a bunch of routers only to be disappointed when they don’t recover quickly on their first reload after the configuration is written.  You’ll either need to reload the router after the configuration is written to ensure that the warm-reboot feature is in effect, or just allow the router one mulligan.

Let’s reload the router (this should be a “cold” reload and should take about 90 sec to restore):
r2#reload
Proceed with reload? [confirm]

*Jul 13 22:39:34: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 22:41:09: %SYS-6-BOOTTIME: Time taken to reboot after reload =   94 seconds
Okay, let’s verify that the warm-reboot is configured and then go ahead and do a warm-reload:
r2#show warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)

Statistics:

0 warm reboots due to crashes and 0 warm reboots due to requests have taken
place since the last cold reboot
3149 KB taken up by warm reboot storage

Notice the “warm” option for reloads now:
r2#reload ?
  /noverify  Don’t verify file signature before reload.
  /verify    Verify file signature before reload.
  LINE       Reason for reload
  at         Reload at a specific time/date
  cancel     Cancel pending reload
  in         Reload after a time interval
  warm       Reload should be warm
  <cr>

r2#reload warm ?
  LINE  Reason for reload
  at    Reload at a specific time/date
  file  Image file to load
  in    Reload after a time interval
  <cr>
r2#reload warm
Proceed with reload? [confirm]

After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 23:08:33: %SYS-6-BOOTTIME: Time taken to reboot after reload =   35 seconds

NICE!!!  This shaved nearly a minute off of the reload time.

I like the statistics as well:
r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)

Statistics:

0 warm reboots due to crashes and 1 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage

While the statistics are nice, they do get blown away if the router is power-cycled. 

This is a feature that is pretty useful for production networks.  Every engineer knows that waiting 60 seconds for a router to restore after a reload can feel like an eternity.  This command should be able to shave some significant time as well as give you some additional information concerning reloads and crashes.


Cisco Documentation:warm-reboot

July 7, 2007

CDP Timers Plus Another Use For The “Default” Command

Filed under: Cool Commands,IOS — cciepursuit @ 4:17 pm

I was doing some ODR routing labs today and started mucking about with CDP timers (ODR uses CDP for advertisements).  This is important to note in case you get a task that requires you to change the convergence time of an ODR learned route.  CDP timers are changed at the global level.  The default values are 60 seconds for advertisements with a 180 second holddown time.

How to change CDP timers (must change timer(send) and holdtime separately):
sw4(config)#cdp ?
  advertise-v2  CDP sends version-2 advertisements
  holdtime      Specify the holdtime (in sec) to be sent in packets
  run           Enable CDP
  timer         Specify the rate at which CDP packets are sent       (in sec)

sw4(config)#cdp timer ?
  <5-254>  Rate at which CDP packets are sent (in  sec)

sw4(config)#cdp timer 5
sw4(config)#do sh cdp
Global CDP information:
        Sending CDP packets every 5 seconds
        Sending a holdtime value of 180 seconds
        Sending CDPv2 advertisements is  enabled

sw4(config)#cdp hold 15
Global CDP information:
        Sending CDP packets every 5 seconds
        Sending a holdtime value of 15 seconds
        Sending CDPv2 advertisements is  enabled

Here’s some weirdness: you can configure the holdtime to be less than the update timer:

sw4(config)#cdp timer 30
sw4(config)#cdp hold 10
sw4(config)#do sh cdp
Global CDP information:
        Sending CDP packets every 30 seconds
        Sending a holdtime value of 10 seconds
        Sending CDPv2 advertisements is  enabled

To set the CDP timers back to the defaults, you could manually set the “timer” value to 60 seconds and the “holdtime” value to 180 seconds, but let’s use the “default” command to return the timers:

sw4(config)#default cdp timer
sw4(config)#do sh cdp
Global CDP information:
        Sending CDP packets every 60 seconds
        Sending a holdtime value of 15 seconds
        Sending CDPv2 advertisements is  enabled
sw4(config)#default cdp hold
sw4(config)#do sh cdp
Global CDP information:
        Sending CDP packets every 60 seconds
        Sending a holdtime value of 180 seconds
        Sending CDPv2 advertisements is  enabled

Sweet!  I love the “default” command.


Cisco Documention:cdp timercdp holdtime

July 6, 2007

“clear frame-relay counters” = Hidden 12.4 Command?

Filed under: Cool Commands,IOS — cciepursuit @ 4:31 pm

This is an odd little command in that I could not find it in the 12.4 Command Reference, yet it is available for that code version:

r1#sh ver
Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(8b), RELEASE SOFTWARE (fc2)

r1#clear frame-relay counter ?
  interface  Frame Relay Interface
  <cr>

This is a command that I rarely use, but it does come in handy every once in a while.  Say that you are troubleshooting Frame-Relay (“show frame-relay pvc”, “show frame-relay lmi”, etc.) and you need to clear the counters.  You can clear the counters on the physical interface and that will clear the Frame-Relay counters as well:

Initial Output:
r1#sh int s0/0/0
Serial0/0/0 is up, line protocol is up
—–some output truncated—–
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of “show interface” counters 01:08:30
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/250 (size/max)
  30 second input rate 4000 bits/sec, 7 packets/sec
  30 second output rate 4000 bits/sec, 7 packets/sec
     25924 packets input, 4730477 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     23237 packets output, 2541206 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

r1#sh frame pvc

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.102

  input pkts 22349         output pkts 20024        in bytes 4142379
  out bytes 2243557        dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  5 minute input rate 1000 bits/sec, 5 packets/sec
  5 minute output rate 2000 bits/sec, 5 packets/sec
  Shaping adapts to BECN
  pvc create time 15:48:07, last time pvc status changed 15:46:57

r1#sh frame lmi

LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 414              Num Status msgs Rcvd 414
  Num Update Status Rcvd 0              Num Status Timeouts 0
  Last Full Status Req 00:00:01         Last Full Status Rcvd 00:00:01

After “clear counters s0/0/0” command:
r1#clear count s0/0/0
Clear “show interface” counters on this interface [confirm]
r1#sh int s0/0/0
Serial0/0/0 is up, line protocol is up
—–some output truncated—–
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of “show interface” counters 00:00:03
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/250 (size/max)
  30 second input rate 4000 bits/sec, 6 packets/sec
  30 second output rate 6000 bits/sec, 6 packets/sec
     29 packets input, 1348 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     29 packets output, 3012 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

r1#sh frame pvc

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.102

  input pkts 61            output pkts 56           in bytes 3356
  out bytes 5825           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  5 minute input rate 1000 bits/sec, 2 packets/sec
  5 minute output rate 2000 bits/sec, 2 packets/sec
  Shaping adapts to BECN
  pvc create time 15:48:56, last time pvc status changed 15:47:46

r1#sh frame lmi

LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 40               Num Status msgs Rcvd 40
  Num Update Status Rcvd 0              Num Status Timeouts 0
  Last Full Status Req 00:00:10         Last Full Status Rcvd 00:00:10

You can see that the physical interface counters (s0/0/0) have been cleared as well as the Frame-Relay counters.  Let’s say that we want to clear the Frame-Relay counters, but we want to retain the historical information on the physical interface.  We can try to clear the counters on the subinterface, but IOS won’t play along:

r1#clear counters s0/0/0.102
% subinterface Serial0/0/0.102 has no support for counters

Here’s where the “clear frame-relay counters” command comes to the rescue:

After “clear frame count int s0/0/0.102” command:
r1#sh int s0/0/0
Serial0/0/0 is up, line protocol is up
—–some output truncated—–
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of “show interface” counters 00:06:20
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/250 (size/max)
  30 second input rate 4000 bits/sec, 7 packets/sec
  30 second output rate 3000 bits/sec, 6 packets/sec
     3751 packets input, 755170 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3267 packets output, 364486 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

r1#sh frame lmi

LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 40               Num Status msgs Rcvd 40
  Num Update Status Rcvd 0              Num Status Timeouts 0
  Last Full Status Req 00:00:10         Last Full Status Rcvd 00:00:10

r1#sh frame pvc

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.102

  input pkts 130           output pkts 120          in bytes 10421
  out bytes 9840           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  5 minute input rate 2000 bits/sec, 3 packets/sec
  5 minute output rate 2000 bits/sec, 3 packets/sec
  Shaping adapts to BECN
  pvc create time 15:55:15, last time pvc status changed 15:54:06

So the “clear frame-relay counters” command will not clear the counters on the physical interface and it will not clear the LMI counters, but it will clear the “show frame-relay pvc” counters.

This command has a pretty limited use, but it does come in handy when you want to reset the Frame-Relay specific counters without wiping out the historical data on the physical interface’s counters.  I always find it better to clear only the least amount of counters during troubleshooting, so that you don’t erase some information that you may need to reference later to complete your troubleshooting.


Cisco Documentation:

Cisco IOS Master Commands List, Release 12.4 (command not listed)

Get Your Verbose Ethernet Stats Right Here

Filed under: Cool Commands,IOS,Switching — cciepursuit @ 2:11 pm

I stumbled across this command a couple of weeks ago “show controller ethernet-controller”.  This will give you a wealth of information about an Ethernet port:

sw1#show controller ethernet-controller fa1/0/1

     Transmit FastEthernet1/0/1               Receive
   4077220072 Bytes                       2097409522 Bytes
     14524440 Unicast frames                12968597 Unicast frames
     31786595 Multicast frames                466592 Multicast frames
     10505841 Broadcast frames                 36612 Broadcast frames
            0 Too old frames              2058851530 Unicast bytes
            0 Deferred frames               31922321 Multicast bytes
            0 MTU exceeded frames            5212803 Broadcast bytes
            0 1 collision frames                   0 Alignment errors
            0 2 collision frames                   0 FCS errors
            0 3 collision frames                   0 Oversize frames
            0 4 collision frames                   0 Undersize frames
            0 5 collision frames                   0 Collision fragments
            0 6 collision frames
            0 7 collision frames             2533081 Minimum size frames
            0 8 collision frames             4714955 65 to 127 byte frames
            0 9 collision frames             5824957 128 to 255 byte frames
            0 10 collision frames             161994 256 to 511 byte frames
            0 11 collision frames             112968 512 to 1023 byte frames
            0 12 collision frames             123846 1024 to 1518 byte frames
            0 13 collision frames                  0 Overrun frames
            0 14 collision frames                  0 Pause frames
            0 15 collision frames
            0 Excessive collisions                 0 Symbol error frames
            0 Late collisions                      0 Invalid frames, too large
            0 VLAN discard frames                  0 Valid frames, too large
            0 Excess defer frames                  0 Invalid frames, too small
     18319560 64 byte frames                       0 Valid frames, too small
     24450734 127 byte frames
      7975626 255 byte frames                      0 Too old frames
       632163 511 byte frames                      0 Valid oversize frames
       591242 1023 byte frames                     0 System FCS error frames
      4847551 1518 byte frames                     0 RxPortFifoFull drop frame
            0 Too large frames
            0 Good (1 coll) frames
            0 Good (>1 coll) frames

While I generally like to use the “show interface fax/x status” and “show interface fax/x counter errors” to check Ethernet ports, this command is nice because it breaks the information down for transmit and receive (“show interface fax/x stats” does something similar, but not to the extent of this command).

One caveat: to clear the counters for this command you must use “clear controller ethernet-controller fax/x” rather than “clear counters fax/x”:

sw1#sh int fa1/0/15 stats
FastEthernet1/0/15
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0     641722   47035214
             Route cache          0          0          0          0
                   Total          0          0     641722   47035214

sw1#sh controller ethernet-controller fa1/0/15

     Transmit FastEthernet1/0/15              Receive
    152950109 Bytes                          5137184 Bytes
       220909 Unicast frames                   31752 Unicast frames
      1400530 Multicast frames                  9087 Multicast frames
       512320 Broadcast frames                     6 Broadcast frames
—-output truncated———–

sw1#clear counters fa1/0/15
Clear “show interface” counters on this interface [confirm]

This works for the interface stats but not the controller ethernet-controller counters:
sw1#sh int fa1/0/15 stats
FastEthernet1/0/15
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          9        608
             Route cache          0          0          0          0
                   Total          0          0          9        608
sw1#sh controller ethernet-controller fa1/0/15

     Transmit FastEthernet1/0/15              Receive
    152965336 Bytes                          5137471 Bytes
       220917 Unicast frames                   31753 Unicast frames
      1400657 Multicast frames                  9088 Multicast frames
       512386 Broadcast frames                     6 Broadcast frames
—-output truncated———–

sw1#clear controllers ethernet-controller fa1/0/15Now the counters are cleared:
sw1#sh controller ethernet-controller fa1/0/15

     Transmit FastEthernet1/0/15              Receive
         2263 Bytes                                0 Bytes
            0 Unicast frames                       0 Unicast frames
           19 Multicast frames                     0 Multicast frames
           10 Broadcast frames                     0 Broadcast frames
—-output truncated———–


Cisco Documentation:show controller ethernet-controller (3550)

show controller ethernet-controller (3560)

« Previous PageNext Page »

Blog at WordPress.com.