Take the 2-minute tour ×
Network Engineering Stack Exchange is a question and answer site for network engineers. It's 100% free, no registration required.

I have just read Jeremy's question about 2960-S and iSCSI traffic handling, which drove me to ask this question: We all have lots of switches deployed in distinct infrastructures, how can you know that the traffic is treated well?

I usually check CPU, RAM and system logs but didn't think about buffers.

I used show buffers failures and here is an example of the data:

show buffers failures 
Caller       Pool          Size      When
0x1279AE0   Middle           445    3d19h
0x1279AE0   Middle           446    3d19h
0x1279AE0   Middle           444    3d19h

How can I know on which interface this occurred?

Are there other performance metrics that should be reviewed?

share|improve this question
1  
Please provide link to Jeremy's question. –  generalnetworkerror May 23 '13 at 9:34
    
Thanks for adding the link. –  laf May 24 '13 at 8:52
add comment

3 Answers

You've got great replies so far.

Like Lukasz says the buffer setup is a bit complex on the Catalyst switches. There is a pool that you assign buffers from for the 4 egress queues. You can choose to reserve a certain amount of buffers and let the rest sit in a pool and use it as needed. The buffers that are reserved can't be touched by other queues/thresholds.

enter image description here

To see drops on different queues/thresholds use this command:

show platform port-asic stats drop gix/x

enter image description here

share|improve this answer
add comment

That depends on the switch model you have and it's not that easy.

Smaller Catalyst switches in general use at least two forms of buffer - there's usually a interface-lavel buffer, on the smaller Catalyst (2k/3k) visible in 'show buffers' under the section named 'Interface buffer pools:':

Interface buffer pools:
Syslog ED Pool buffers, 600 bytes (total 132, permanent 132):
   100 in free list (132 min, 132 max allowed)
   11151 hits, 0 misses
RxQ1 buffers, 2040 bytes (total 128, permanent 128):
   4 in free list (0 min, 128 max allowed)
   244594209 hits, 4559839 fallbacks
RxQ2 buffers, 2040 bytes (total 128, permanent 128):
   1 in free list (0 min, 128 max allowed)
   202559241 hits, 1582494 fallbacks, 0 trims, 0 created
   1582494 failures (0 no memory)
...

...and there's "public" area, where CPU is using the buffers as they're punted towards it and need servicing. The "Rx"-level buffers are part of the shared buffer to service all interfaces (on either old, legacy switches like 2950 or newest 2960S/3560X/etc) or a subset of interfaces, belonging to specific port ASIC (like 2960 or 3560/3750/3560E/3750E).

On the 4500 and 6500 in particular it gets messy, as there is a number of pools that packet can go through - input interface (ASIC) buffer, the pool at linecard level (on the 6500 at DFC), at the switch-fabric level and at the end the buffer at Supervisor level. They don't have to be physically separate memory pools, but are often mapped in different commands to different names to ease the troubleshooting process (at which step of the packet walk-through was the packet dropped for example).

share|improve this answer
    
Hi Lukasz, thanks for your input; you have broaden my knowledge on this topic, nevertheless here is my scenario: I have several switches in DataCenter (2960 and 3750 family) and lot of traffic passes through. I would like to know if iSCSI traffic is handled well, and if not to "grab some evidence" so I can FWD to management board as reason for upgrading the infrastructure. Then again, how can I pinpoint: "on interface Gi0/21" iSCSI traffic is having "hard time, because of the switch's overall performance..? –  laf May 24 '13 at 8:58
    
Catalyst 2960 and 3750 are not switches positioned to DC, and that's statement from Cisco - go for 4948E/Nexus 5k/2k.Current generation of those switches are built around switch fabric that is not wire-speed in some corner scenarios and buffers are too small to cover for that. ou'll see output drops on the interfaces and input drops on ASICs as Daniel Gib already shown you.There's unfortunately no granularity in the way you can select which traffic was dropped, unless you'll for example mark iSCSI traffic with different DSCP and then show drops in specific queue that transports only this DSCP. –  Łukasz Bromirski May 25 '13 at 7:54
add comment

If you are getting buffer failures, I would use a command like the following:

show interface | i (line protocol|no buffer)

You will need to manually sort through the output a bit, but you are looking for lines were you have more than 0 no buffer errors like this:

FasttEthernet0/24 is up, line protocol is up (connected)
     1557332164 packets input, 3733280910 bytes, 6718 no buffer
share|improve this answer
    
Hi mate, Just checked couple of switches and find no interface with "no buffer" issues. Nevertheless show buffers failures shows another thing: Caller Pool Size When 0x1279AE0 Middle 445 6d20h 0x1279AE0 Middle 446 6d20h What could this mean? As Lukasz said could be the "public CPU buffer" that is having a bad time? –  laf May 24 '13 at 9:02
    
Mainly, I was wandering from the output above, "how bad is it"? Should I be concerned about this, or is it normal for any switch that passes traffic? –  laf May 24 '13 at 9:12
    
@laf, there is another buffer error line on the interface statement and you can use show interface | i (line protocol|buffer) to see both. In my experience, generally it they fall in the no buffer counter. If this still shows nothing, then the interfaces counters have been cleared or the buffer errors are not at an interface level. As to how bad is it, that depends on other factors you haven't posted. A small percentage of errors is not necessarily bad (although it would be good to be zero), for instance in my example there are nearly 7k errors, this makes up about 0.0004% of the traffic. –  YLearn May 24 '13 at 20:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.