Understanding Interface Statistics on Cat6500

[CoetzerJ]

I have an issue with slow performances on a server in my serverfarm. a 'show interface x/x summary' presents me with an ever increasing value for TRTL: throttle count. I have done some looking around and cannot quite find out what this means/implies. Could this be impacting slow performance on this server.

I have also noticed under a 'show interface' for the servers interface that there is a number of 'PAUSE output' errors?

Any ideas/pointers are welcome.

Thanks in advance.

SFM1#sh int g3/24 summary

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

-------------------------------------------------------------------------

* GigabitEthernet3/24 0 0 0 0 17723000 10036 88310000 14837 0

SFM1#sh int g3/24 summary

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

-------------------------------------------------------------------------

* GigabitEthernet3/24 0 0 0 0 16231000 9826 90305000 14863 0

SFM1#sh int g3/24

GigabitEthernet3/24 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 001e.4a9e.9a57 (bia 001e.4a9e.9a57)

Description: W3MMWTSM01

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 23/255, rxload 4/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT

input flow-control is off, output flow-control is on

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:31, output hang never

Last clearing of "show interface" counters 04:00:44

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 input rate 16084000 bits/sec, 9796 packets/sec

5 minute output rate 90315000 bits/sec, 14849 packets/sec

88633195 packets input, 14523719909 bytes, 0 no buffer

Received 296 broadcasts (0 multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

145342160 packets output, 96743166326 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 44 PAUSE output

0 output buffer failures, 0 output buffers swapped out

[Jon Marshall]

Which modules are you using ?

And which supervisor ?

Jon

[CoetzerJ]

Hi Jon,

The modules in the chassis is as per the below.

Mod Ports Card Type Model

--- ----- -------------------------------------- ------------------

1 24 CEF720 24 port 1000mb SFP WS-X6724-SFP

2 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX

3 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX

4 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX

5 2 Supervisor Engine 720 (Active) WS-SUP720-BASE

6 2 Supervisor Engine 720 (Hot) WS-SUP720-BASE

7 4 CEF720 4 port 10-Gigabit Ethernet WS-X6704-10GE

8 8 Network Analysis Module WS-SVC-NAM-2

9 6 Firewall Module WS-SVC-FWM-1

[Jon Marshall]

Jacques

Okay thought your issue may have been your ethernet modules but as you are using WS-X6748 this is unlikely.

Is the WS-X6748 that the server is connected to fully populated ?

Jon

[CoetzerJ]

This particular module is about 90% connected. I have another blade of the same type in the chassis that is 100% populated and all connected, and we are not experiencing any problems on those servers. The 'show interface summary' for those ports have some, but very low to zero TRTL throttle counts on them.

From the 'show interface' on the port in mention, the PAUSE count errors are only apearing on that specific servers interface. I am not sure if the high count of TRTL errors and the PAUSE errors are related in any way either.

[Giuseppe Larosa]

Hello Jacques,

pause frames are not an error by themselves but a sign that the switch port has difficulties to deal with server traffic and it is sending IEEE pause frames in an attempt to slow down server's sending.

without these output frames sent out you would see ignored packets on the switch interface.

so it is a tradeoff.

Hope to help

Giuseppe