Monday 11 May 2015

Troubleshooting Switchport and Interface Problem (Cont.)

Bad or damaged cable
Always check the cable for marginal damage or failure. A cable can be just good enough to connect at the physical layer, but it corrupts packets as a result of subtle damage to the wiring or connectors. Check or swap the copper or fiber cable. Swap the GBIC (if removable) for fiber connections. Rule out any bad patch panel connections or media convertors between source and destination. Try the cable in another port or interface if one is available and see if the problem continues.

Auto negotiation and NIC Card Issues
Problems sometimes occur between Cisco switches and certain third-party NIC cards. By default, Catalyst switch ports and interfaces are set to autonegotiate. It is common for devices like laptops or other devices to be set to autonegotiate as well, yet sometimes autonegotation issues occur.
In order to troubleshoot autonegotiation problems it is often recommended to try hardcoding both sides. If neither autonegotiation or hardcoding seem to work, there can be a problem with the firmware or software on your NIC card. Upgrade the NIC card driver to the latest version available on the web site of the manufacture to resolve this.

Spanning Tree Loops

Spanning Tree Protocol (STP) loops can cause serious performance issues that masquerade as port or interface problems. In this situation, your bandwidth is used by the same frames over and over again, which leaves little room for legitimate traffic.
The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop.
The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop. Refer to Spanning-Tree Protocol Enhancements using Loop Guard and BPDU Skew Detection Features for more information on the loop guard feature.
This document covers reasons that STP can fail, what information to look for to identify the source of the problem, and what kind of design minimizes STP risks.
Loops can also be caused by a uni-directional link. For more information, refer to the UDLD: One-Way link problems section of this document.

UDLD: One-Way Link

A unidirectional link is a link where traffic goes out one way, but no traffic is received coming back. The switch does not know that the link coming back is bad (the port thinks the link is up and working).
A broken fiber cable or other cabling/port issues can cause this one-way only communication. These partially functional links can cause problems such as STP loops when the switches involved do not know that the link is partially broken. UDLD can put a port in errdisable state when it detects a unidirectional link. The command udld aggressive-mode can be configured on switches that run CatOS and Cisco IOS (check release notes for command availability) for point-to-point connections between switches where malfunctioning links cannot be tolerated. The use of this feature can help you identify difficult to find unidirectional link problems

Deferred Frames (Out-Lost or Out-Discard)

If you have a large number of deferred frames, or Out-Discard (also referred to as Out-Lost on some platforms), it means that the switch's output buffers have filled up and the switch had to drop these packets. This can be a sign that this segment is run at an inferior speed and/or duplex, or there is too much traffic that goes through this port.
For CatOS, use the show mac command for the module and port or the entire module to look at out-discards:
MAC Dely-Exced MTU-Exced In-Discard Out-Discard
-------- ---------- ---------- ---------- -----------
2/1 0 - 0 10175888
2/2 0 - 0 9471889
2/3 0 - 0 9095371
2/4 0 - 0 8918785
!--- The show mac command run on mod 2 at different intervals shows
!--- the out-discard counter incrementing.
For Cisco IOS, use the show interfaces counters error command.
Router#sho interfaces counters error
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Fa7/47 0 0 0 0 0 0
Fa7/48 0 0 0 0 0 2871800
Fa8/1 0 0 0 0 0 2874203
Fa8/2 103 0 0 103 0 2878032
Fa8/3 147 0 0 185 0 0
Fa8/4 100 0 0 141 0 2876405
Fa8/5 0 0 0 0 0 2873671
Fa8/6 0 0 0 0 0 2
Fa8/7 0 0 0 0 0 0
!--- The show interfaces counters errors command shows certain interfaces
!--- incrementing large amounts of OutDiscards while others run clean.
Investigate these common causes of output buffer failures:
Inferior Speed/Duplex for the Amount of Traffic
Your network can send too many packets through this port for the port to handle at its current speed/duplex setting. This can happen where you have multiple high-speed ports flowing to a single (usually slower) port. You can move the device that hangs off this port to faster media. For example, if the port is 10 Mbps, move this device to a 100 Mbps or Gigabit port. You can change the topology to route frames differently.
Congestion Issues: Segment Too Busy
If the segment is shared, other devices on this segment can transmit so much that the switch has no opportunity to transmit. Avoid daisy-chained hubs whenever possible. Congestion can lead to packet loss. Packet loss causes retransmissions at the transport layer which in turn causes users to experience latency at the application level. You can upgrade10Mbps links to 100Mbps or Gigabit Ethernet links when possible. You can remove some devices from crowded segments to other less populated segments. Make congestion avoidance a priority on your network.
Applications
At times the traffic transmission characteristics of the applications used can lead to output buffer problems. NFS file transfers that come from a Gigabit attached server that uses user datagram protocol (UDP) with a 32K window size is one example of an application setting that can bring out this type of problem. If you have checked or tried the other suggestions in this document (checked speed/duplex, no physical errors on the link, all the traffic is normal valid traffic, and so on), then reducing the unit size that is sent by the application can help alleviate this problem.

Software Problems

If you see behavior that can only be considered "strange," you can isolate the behavior to a specific box, and you have looked at everything suggested so far, this can indicate software or hardware problems. It is usually easier to upgrade the software than it is to upgrade hardware. Change the software first.
For CatOS, use the show version command to verify the current software version and free flash memory for the upgrade.
Switch> (enable) sh ver
WS-C6006 Software, Version NmpSW: 6.3(3)
Copyright (c) 1995-2001 by Cisco Systems
NMP S/W compiled on Oct 29 2001, 16:50:33
System Bootstrap Version: 5.3(1)
PS1 Module: WS-CAC-1300W Serial #: SON04201377
Hardware Version: 2.0 Model: WS-C6006 Serial #: TBA04251336
Mod Port Model Serial # Versions
PS2 Module: WS-CAC-1300W Serial #: SON04201383
1 2 WS-X6K-SUP1A-2GE SAD041901PP Hw : 3.6
--- ---- ------------------- ----------- --------------------------------------
Sw : 6.3(3)
Fw : 5.3(1) Fw1: 5.4(2)
!--- Output truncated.
Sw1: 6.3(3) WS-F6K-PFC SAD041803S3 Hw : 2.0
DRAM FLASH NVRAM
Module Total Used Free Total Used Free Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- -----
1 65408K 47274K 18134K 16384K 14009K 2375K 512K 308K 204K
!--- Typical CatOS show version output.
!--- Verify free memory before upgrading.
Uptime is 32 days, 4 hours, 44 minutes
Console> (enable)
For Cisco IOS, use the show version command to verify the current software version along with the dir flash: or dir bootflash: (dependent upon the platform) command to verify the available flash memory for the upgrade:
Router#sh ver
Cisco Internetwork Operating System Software
IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(13)EW, EA
RLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac
Compiled Fri 20-Dec-02 13:52 by eaarmas
Copyright (c) 1986-2002 by cisco Systems, Inc. Image text-base: 0x00000000, data-base: 0x00E638AC ROM: 12.1(12r)EW
System returned to ROM by redundancy reset
Dagobah Revision 71, Swamp Revision 24 trunk-4500 uptime is 2 weeks, 2 days, 6 hours, 27 minutes
!--- Typical Cisco IOS show version output.
System image file is "bootflash:cat4000-is-mz.121-13.EW.bin"
Router#dir bootflash:
Directory of bootflash:/
1 -rw- 8620144 Mar 22 2002 08:26:21 cat4000-is-mz.121-13.EW.bin
61341696 bytes total (52721424 bytes free)
!--- Verify available flash memory on switch running Cisco IOS.
Router
How to Upgrade Software
For information on upgrading software for Catalyst switches, choose your platform under LAN & ATM Switches and look at the Software Configuration > Software Upgrade and Working With Configuration Files section.
Hardware Software Incompatibility
There can be a situation where the software is not compatible with the hardware. This happens when new hardware comes out and requires special support from the software. For more information on software compatibility, use the Software Advisor tool.
Software Bugs
The operating system can have a bug. If you load a newer software version, it can often fix this. You can search known software bugs with the Software Bug Toolkit.
Corrupt Images
An image can have become corrupted or is missing. For information in regard to the recovery from corrupted images, choose your platform under LAN & ATM Switches and look at the Troubleshooting > Recovery from Corrupted or Missing Software section.

Hardware Problems

Check the results of show module for Catalyst 6000 and 4000 series switches that run CatOS or Cisco IOS.
Switch> (enable) sh mod
Mod Slot Ports Module-Type Model Sub
Status
--- ---- ----- ------------------------- ------------------- -----------
1 1 2 1000BaseX Supervisor WS-X6K-S2U-MSFC2 yes ok
3 3 8 1000BaseX Ethernet WS-X6408A-GBIC no faulty
15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no ok
5 5 48 10/100BaseTX Ethernet WS-X6348-RJ-45 no faulty
!--- Status of "faulty" indicates a possible hardware problem.
!--- This could be a line card problem, but since two mods are effected,
!--- perhaps there's a problem with the supervisor.
!--- Use the reset command (CatOS) or hw-module{mod}reset command (Cisco IOS),
!--- or try physically reseating the modules and the supervisor.
!--- Also, try moving the supervisor to slot 2.
Check the results of the POST results from the switch to see if there were any failures indicated for any part of the switch. Failures of any test of a module or port show an 'F' in the test results.
For CatOS, use the show test command to see all test results. In order to see test results per module, use the show test {mod} command:
Switch> (enable) sh test 3
Diagnostic mode: complete (mode at next reset: minimal)
!--- The diaglevel is set to complete which is a longer but more thorough test.
!--- The command to do this for CatOS is set test diaglevel complete.
Module 3 : 16-port 1000BaseX EthernetLine Card Status for Module 3 : PASS
Port Status : Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
. . . . . . . . . . . . . . . .
----------------------------------------------------- GBIC Status : Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Line Card Diag Status for Module 3 (. = Pass, F = Fail, N = N/A)
----------------------------------------------------- . . . . . N . . . . . . . . N N
Loopback Status [Reported by Module 1] :
Ports 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
-----------------------------------------------------
F F F F F F F F F F F F F F F F
!--- The failed loopback tests mean the ports are currently unusable.
!--- Use the reset {mod} command or, if necessary, physically reseat the
!--- module to try and fix this problem.
!--- If these steps fail, open a case with Cisco Technical Support.
For Cisco IOS, on modular switches like the Cat6000 and 4000, use the command show diagnostics. In order to see POST results per module, use the show diagnostics module {mod} command.
ecsj-6506-d2#sh diagnostic module 3
Current Online Diagnostic Level = Minimal
!--- The diagnostic level is set to minimal which is a shorter,
!--- but also less thorough test result.
!--- You may wish to configure diagnostic level complete to get more test results.
Online Diagnostic Result for Module 3 : MINOR ERROR
Online Diagnostic Level when Line Card came up = Minimal
Test Results: (. = Pass, F = Fail, U = Unknown)
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
1 . TestLoopback :
----------------------------------------------------------------------------
. . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means
!--- Use the hw-module{mod}reset command or, if necessary, physically reseat the
!--- these ports are currently unusable.
!--- module to try and fix this problem.
!--- If these steps fail, open a case with Cisco Technical Support.
Note: For Catalyst 3750, 3550, 2970 , 2950/2955, and 2900/3500XL Series switches use the show post command, which indicates a simple pass or fail for the hw status. Use the LEDs on these switches to help you understand the POST results.
For further information on troubleshooting hardware problems on Catalyst switches that run CatOS and Cisco IOS, go to the LAN and ATM Switches support pages, choose your platform and look at the Troubleshooting > Hardware section.
For possible issues related to Field Notices.

Input Errors on a Layer 3 Interface Connected to a Layer 2 Switchport

By default, all layer 2 ports are in dynamic desirable mode, so the layer 2 port tries to form a trunk link and sends out DTP packets to the remote device. When a layer 3 interface is connected to a layer 2 switchport, it is not able to interpret these frames, which results in Input errors, WrongEncap errors, and Input queue drops.
In order to resolve this, change the mode of the switch port to static access or trunk as per your requirement.
Switch2(config)#int fa1/0/12
Switch2(config-if)#switchport mode access
or
Switch2(config)#int fa1/0/12
Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk

Rapidly Incrementing Rx-No-Pkt-Buff Counter and Input Errors

The Rx-No-Pkt-Buff counter can increase on ports when it has blades, such as WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, and WS-X4548-GB-RJ45V. Also some packet drop incrementation is normal and is the result of bursting traffic.
These types of errors increase rapidly, especially when the traffic that passes through that link is high or when it has devices such as servers connected to that interface. This high load of traffic oversubscribes the ports, which exhausts the input buffers and causes the Rx-No-Pkt-Buff counter and input errors to increase rapidly.
If a packet cannot be completely received because the switch is out of packet buffers, this counter is incremented once for every dropped packet. This counter indicates the internal state of the Switching ASICs on the Supervisor and does not necessarily indicate an error condition.
Pause Frames
When the receive part (Rx) of the port has its Rx FIFO queue filled and reaches the high water mark, the transmit part (Tx) of the port starts to generate pause frames with an interval value mentioned in it. The remote device is expected to stop / reduce the transmission of packets for the interval time mentioned in the pause frame.
If the Rx is able to clear the Rx queue or reach low water mark within this interval, Tx sends out a special pause frame that mentions the interval as zero (0x0). This enables the remote device to start to transmit packets.
If the Rx still works on the queue, once the interval time expires, the Tx sends a new pause frame again with a new interval value.
If Rx-No-Pkt-Buff is zero or does not increment and the TxPauseFrames counter increments, it indicates that our switch generates pause frames and the remote end obeys, hence Rx FIFO queue depletes.
If Rx-No-Pkt-Buff increments and TxPauseFrames also increments, it means that the remote end disregards the pause frames (does not support flow control) and continues to send traffic despite the pause frames. In order to overcome this situation, manually configure the speed and duplex, as well as disable the flow control, if required.
These types of errors on the interface are related to a traffic problem with the ports oversubscribed. The WS-X4448-GB-RJ45, WS-X4548-GB-RJ45, and WS-X4548-GB-RJ45V switching modules have 48 oversubscribed ports in six groups of eight ports each:
  • Ports 1, 2, 3, 4, 5, 6, 7, 8
  • Ports 9, 10, 11, 12, 13, 14, 15, 16
  • Ports 17, 18, 19, 20, 21, 22, 23, 24
  • Ports 25, 26, 27, 28, 29, 30, 31, 32
  • Ports 33, 34, 35, 36, 37, 38, 39, 40
  • Ports 41, 42, 43, 44, 45, 46, 47, 48
The eight ports within each group use common circuitry that effectively multiplexes the group into a single, nonblocking, full-duplex Gigabit Ethernet connection to the internal switch fabric. For each group of eight ports, the frames that are received are buffered and sent to the common Gigabit Ethernet link to the internal switch fabric. If the amount of data received for a port begins to exceed buffer capacity, flow control sends pause frames to the remote port to temporarily stop traffic and prevent frame loss.
If the frames received on any group exceeds the bandwidth of 1 Gbps, the device starts to drop the frames. These drops are not obvious as they are dropped at the internal ASIC rather than the actual interfaces. This can lead to slow throughput of packets across the device.
The Rx-No-Pkt-Buff does not depend on the total traffic rate. It depends on the amount of the packets that are stored in the Rx FIFO buffer of the module ASIC. The size of this buffer is only 16 KB. It is counted with short bursty traffic flows when some packets fill this buffer. Thus, Rx-No-Pkt-Buff on each port can be counted when the total traffic rate of this ASIC port group exceeds 1 Gbps, since WS-X4548-GB-RJ45 is 8:1 oversubscribed module.
When you have devices that need to carry a large amount of traffic through that interface, consider the use of one port of each group so that the common circuitry that shares a single group is not affected by this amount of traffic. When the Gigabit Ethernet switching module is not fully utilized, you can connect balancing port connections across port groupings to maximize available bandwidth. For example, with the WS-X4448-GB-RJ45 10/100/1000 switching module, you can connect ports from different groups, such as ports 4, 12, 20, or 30 (in any order), before you connect ports from the same group, such as ports 1, 2, 3, 4, 5, 6, 7, and 8.
If this does not solve the issue, you need to consider a module without any oversubscription of ports.

Understand Unknown Protocol Drops

Unknown protocol drops is a counter on the interface. It is caused by protocols that are not understood by the router/switch.
This example of the show running-config interface command shows the unknown protocol drops on the Gigabit Ethernet 0/1 interface.
Switch#sh run int Gig 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
reliability 255/255, txload 1/255, rxload 1/255 Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Last input 00:00:05, output 00:00:03, output hang never Last clearing of "show interface" counters 16:47:42 Queueing strategy: fifo
3031 packets input, 488320 bytes, 0 no buffer
Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
0 input packets with dribble condition detected
Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 63107 multicast, 0 pause input
2015 unknown protocol drops
7062 packets output, 756368 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets
4762 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Unknown protocol drops are normally dropped because the interface where these packets are received is not configured for this type of protocol, or it can be any protocol that the router does not recognize.
For example, if you have two routers connected and you disable CDP on one router interface, this results in unknown protocol drops on that interface. The CDP packets are no longer recognized, and they are dropped.

Trunking between a Switch and a Router

Trunk links between a switch and a router can make the switchport go down. Trunk can come up after you disable and enable the switchport, but eventually the switchport can go down again.
In order to resolve this issue, complete these steps:
  1. Make sure Cisco Discovery Protocol (CDP) runs between the switch and router and both can see each other.
  2. Disable the Keepalives on the interface of the router.
  3. Reconfigure the trunk encapsulation on both devices.
When the keepalives are disabled, the CDP enables link to operate normally.

Connectivity Issues due to Oversubscription

When you use either the WS-X6548-GE-TX or WS-X6148-GE-TX modules, there is a possibility that individual port utilization can lead to connectivity problems or packet loss on the surrounding interfaces. 

Subinterfaces in SPA Modules

In SPA modules, after you create a subinterface with 802.1Q, the same VLAN is not usable on the switch. Once you have encapsulation dot1q on a subinterface, you can no longer use that VLAN in the system because the 6500 or 7600 internally allocates the VLAN and makes that subinterface its only member.
In order to resolve this issue, create trunk ports instead of subinterfaces. That way, the VLAN can be seen in all interfaces.

Troubleshooting rxTotalDrops

If all other counters are zero, and the only error counter that reports errors is rxTotalDrops, the most likely cause is that the Spanning Tree blocks one or more VLANs on the uplink port, so the Color Blocking Logic (CBL) drops.
6509> (enable) show counters 1/2
64 bit counters
0 rxHCTotalPkts = 32513986812
1 txHCTotalPkts = 29657802587
3 txHCUnicastPkts = 29498347453
2 rxHCUnicastPkts = 18033363526 4 rxHCMulticastPkts = 13469995420
7 txHCBroadcastPkts = 137735782
5 txHCMulticastPkts = 21719352 6 rxHCBroadcastPkts = 757199011 8 rxHCOctets = 25149393527621
12 rxTxHCPkts128to255Octets = 16915931224
9 txHCOctets = 23336028193116 10 rxTxHCPkts64Octets = 387871 11 rxTxHCPkts65to127Octets = 13704213656 13 rxTxHCPkts256to511Octets = 1068961475
18 rxHCDropEvents = 0
14 rxTxHCpkts512to1023Octets = 1945427146 15 rxTxHCpkts1024to1518Octets = 11340361825 16 txHCTrunkFrames = 29657506751 17 rxHCTrunkFrames = 32513986812 32 bit counters
5 txCollisions = 0
0 rxCRCAlignErrors = 0 1 rxUndersizedPkts = 0 2 rxOversizedPkts = 0 3 rxFragmentPkts = 0 4 rxJabbers = 0 6 ifInErrors = 0
13 linkChange = 1
7 ifOutErrors = 0 8 ifInDiscards = 0 9 ifInUnknownProtos = 0 10 ifOutDiscards = 98 11 txDelayExceededDiscards = 0 12 txCRC = 0 14 wrongEncapFrames = 0
7 dot3StatsExcessiveCollisions = 0
0 dot3StatsAlignmentErrors = 0 1 dot3StatsFCSErrors = 0 2 dot3StatsSingleColFrames = 0 3 dot3StatsMultiColFrames = 0 4 dot3StatsSQETestErrors = 0 5 dot3StatsDeferredTransmisions = 0 6 dot3StatsLateCollisions = 0 8 dot3StatsInternalMacTransmitErrors = 0
0 rxTotalDrops = 253428855
9 dot3StatsCarrierSenseErrors = 0 10 dot3StatsFrameTooLongs = 0 11 dot3StatsInternalMacReceiveErrors = 0 12 dot3StatsSymbolErrors = 0 0 txPause = 0 1 rxPause = 0
1 rxFIFOFull = 0
Last-Time-Cleared
2 rxBadCode = 0 --------------------------
6509> (enable)
Sat Oct 27 2007, 08:24:35
When the port blocks VLANs on one side, but the remote side forwards on those VLANs, the interface increments the rxTotalDrops counters.
Compare the VLANs allowed in the trunk on both sides of the link. Also verify the spanning tree state for these allowed VLANs on both sides. BPDUs are still sent on actively configured VLAN, so switch A sends BPDUs on all configured and forwarding ports, but switch B drops them since it does not have those VLANs configured. In other words, switch B gets packets for VLANs for which it is not configured, so it simply drops them. These are not really errors but simple misconfiguration.
ifOutDiscards usually occur when the transmit (Tx) buffer gets full (maybe due to oversubscription) and then starts dropping the packets.

Troubleshoot Output Drops

Typically, the output drops will occur if QoS is configured and it is not providing enough bandwidth to certain class of packets. It also occurs when we are hitting oversubscription.
For example, here you see a high amount of output drops on the interface GigabitEthernet 8/9 on a Catalyst 6500 Series Switch:
Switch#show interface GigabitEthernet8/9
GigabitEthernet8/9 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0013.8051.5950 (bia 0013.8051.5950)
Description: Connection To Bedok_Core_R1 Ge0/1
reliability 255/255, txload 18/255, rxload 23/255
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, Encapsulation ARPA, loopback not set
input flow-control is off, output flow-control is off
Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX Clock mode is auto
Last clearing of "show interface" counters never
ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:28, output 00:00:10, output hang never
Input queue: 0/2000/3/0 (size/max/drops/flushes); Total output drops: 95523364
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 94024000 bits/sec, 25386 packets/sec
5 minute output rate 71532000 bits/sec, 24672 packets/sec
781388046974 packets input, 406568909591669 bytes, 0 no buffer
Received 274483017 broadcasts (257355557 multicasts)
3 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored
0 runts, 0 giants, 0 throttles 0 watchdog, 0 multicast, 0 pause input
749074165531 packets output, 324748855514195 bytes, 0 underruns
0 input packets with dribble condition detected 0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
In order to analyze the problem, collect the output of these commands:
  • show fabric utilization det
  • show fabric errors
  • show platform hardware capacity
  • show catalyst 6000 traffic-meter
  • show platform hardware capacity rewrite-engine drop

Last Input Never from the Output of Show interface Command

This example of the show interface command shows the Last input never on the TenGigabitEthernet1/15 interface.
Switch#show interface TenGigabitEthernet1/15
TenGigabitEthernet1/15 is up, line protocol is up (connected)
Hardware is C6k 10000Mb 802.3, address is 0025.84f0.ab16 (bia 0025.84f0.ab16)
Description: lsnbuprod1 solaris
reliability 255/255, txload 1/255, rxload 1/255
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
Full-duplex, 10Gb/s
Encapsulation ARPA, loopback not set Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
input flow-control is off, output flow-control is off
Last input never, output 00:00:17, output hang never
Last clearing of "show interface" counters 2d22h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo Output queue: 0/40 (size/max)
5 minute output rate 46000 bits/sec, 32 packets/sec
5 minute input rate 0 bits/sec, 0 packets/sec
0 runts, 0 giants, 0 throttles
52499121 packets input, 3402971275 bytes, 0 no buffer Received 919 broadcasts (0 multicasts)
0 input packets with dribble condition detected
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input
0 babbles, 0 late collision, 0 deferred
118762062 packets output, 172364893339 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
0 lost carrier, 0 no carrier, 0 PAUSE output
This shows the number of hours, minutes, and seconds since the last packet was successfully received by an interface and processed locally on the router. This is useful to know when a dead interface has failed. This counter is updated only when packets are process switched, not when packets are fast switched.

No comments:

Post a Comment