04-19-2011 01:48 PM - edited 03-06-2019 04:42 PM
I have an iSCSI environment setup for vmware with a isolated 3750X with 1gig to the vmware hosts and tengig to my san. On the ports connected to the vmware hosts I see a high number of output drops. On the tengig interface I dont see any output drops, performance and throughput it at times unbearbable and I have yet to pinpoint the problem. I would like to rule out the 1 gig connections. Can someone shed some light on this for me?
ANN-SW-12#show plat port-asic stat drop gigabitEthernet 1/0/44
Interface Gi1/0/44 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 20933
Queue 4
GigabitEthernet1/0/44 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is f866.f2a8.53ac (bia f866.f2a8.53ac)
MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 6/255, rxload 19/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:39:11
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 4951
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 76580000 bits/sec, 7072 packets/sec
5 minute output rate 24362000 bits/sec, 5136 packets/sec
25040010 packets input, 34085138925 bytes, 0 no buffer
Received 4 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
18342916 packets output, 10845523009 bytes, 0 underruns
04-20-2011 07:57 AM
Anyone have any ideas why I might be seeing this problem? Jumbo frames are enabled on the host, switch and SAN.
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi1/0/48 0 0 0 0 0 9525
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Gi1/0/48 0 0 0 0 0 0 0
ANN-SW-12#
Transmit GigabitEthernet1/0/48 Receive
3201239225 Bytes 95201757 Bytes
476297892 Unicast frames 474145701 Unicast frames
2098533 Multicast frames 0 Multicast frames
34967 Broadcast frames 29 Broadcast frames
0 Too old frames 95172847 Unicast bytes
0 Deferred frames 0 Multicast bytes
0 MTU exceeded frames 1856 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 3 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 49 Minimum size frames
0 8 collision frames 100420335 65 to 127 byte frames
0 9 collision frames 1451003 128 to 255 byte frames
0 10 collision frames 774908 256 to 511 byte frames
0 11 collision frames 4213626 512 to 1023 byte frames
0 12 collision frames 2419874 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 3 Invalid frames, too large
0 VLAN discard frames 364865935 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
2983221 64 byte frames 0 Valid frames, too small
396356875 127 byte frames
1117530 255 byte frames 0 Too old frames
374720 511 byte frames 0 Valid oversize frames
479263 1023 byte frames 0 System FCS error frames
351194 1518 byte frames 0 RxPortFifoFull drop frame
76768589 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames
04-20-2011 05:00 PM
Hi ,
please check out the following for detailed QOS drop troubleshooting.
05-31-2013 06:02 AM
Hi,
Have you got flowcontrol enabled on your interfaces? This should help a bit and is a recommendation from most vendors. It should be enabled on your VMware hosts NICs as well.
I am facing the same issues with HyperV, any resolution from your side?
05-31-2013 06:19 AM
No flowcontrol but the problem ended up being the buffers on the 3750X's, they are too small for iSCSI traffic. They couldn't keep up with the demand and would start dropping packets until it could free up some of the buffers. We ended up buying (2) 4948's for our iSCSI backend and haven't had a problem since.
So if you are facing the same issues I would advise ditching the 3750 for iSCSI backend.
07-04-2013 02:32 PM
I am experiencing similar problems with output queue drops on my 3750's dedicated iSCSI and vMotion ports. You said the problem was lack of buffers. Did you try allocating more buffers to the input and output queues that serviced your iSCSI traffic? I'm hoping the buffers can be allocated more strategically than the defaults so the 3750 could handle the load.
07-04-2013 11:57 PM
I have found some interesting info during my troubleshooting. We are using a Dell Equalogic SAN. They have made an architectual reference document where they advise a small QoS config, looking like this:
switch(config)# mls qos
switch(config)# mls qos queue-set output 1 threshold 1 100 100 100 400
switch(config)# mls qos queue-set output 1 threshold 2 3200 100 10 3200
switch(config)# mls qos queue-set output 1 threshold 3 100 100 100 400
switch(config)# mls qos queue-set output 1 threshold 4 100 100 100 400
switch(config)# mls qos queue-set output 1 buffers 4 88 4 4
Basically this is some buffer tuning for output buffers. I have worked through this config very thouroughly and it does seem likely to help. I have found a document which describes a test case which proves that such buffer tuning should improve packet throughput about 25%.
What it does is allocating the highest percentage of buffers (88) to the ouput queue that is most utilized (infact the only queue utilized), int this case queue 2.
You will see if you do a show platform port-asic stats enqueue
Also the max buffer threshold is configured to the highest value of 3200.
I am having a meeting this morning to discuss a test scenario, so I hope to update you soon with some results.
To see if you have the same issues do a sh platform port-asic stats drop
You should also not worry to much about traffic that is landing in other output queues, this is usually CPU traffic from the switch itself, including CDP, STP and HSRP.
Have you already got jumbo frames enabled?
07-05-2013 03:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
The 3750 (and 3560/2960) series, often seem to have inadequate buffer resources when QoS is enabled. If you don't need QoS, often the simple solution is disable it and the switch will optimally use its hardware buffers.
If you do need QoS, and if you find the default settings don't work well for you, you'll need to "tune" the buffer settings. Unfortunately, I don't believe there's a "one size fits all" for setting buffer settings. You very much need to consider your QoS policy and your expected traffic.
For example, I can easily see how Dell's suggested buffer settings would favor (SAN?) queue 2 however what happens to traffic in the other queues?
If these buffer settings were used for a host port to a SAN device, they might be optimal, but likely not for other host ports or NNI. (NB: remember on a 3750X you can have two different QSETs.
You might find this Forums document helpful when trying to optimize 3750 buffering: https://supportforums.cisco.com/docs/DOC-8093
05-19-2017 09:48 AM
How could you identify that the problem is with the buffer?
07-04-2013 04:22 PM
364865935 Valid frames, too large
That is suppose to be "0".
Can you post, in succession, the commands "sh interface Gi1/0/48" and "sh controll util"?
04-01-2016 09:25 PM
Hi all
Same issue I am facing with 3750 switch , I am no using any QOS , QoS is disabled on switch , cpu and memory also Normal , and prot utilization is 40% of gigport , Now I am facing packets drops.Most of traffic is voice traffic .and frame size is normal 1580, I think buffer tunning is not requried when QoS disabled , Please share any Ideia .
TxQueue Drop Statisticsare like ths
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 32933
04-02-2016 02:21 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I believe you can better optimize buffer usage by enabling QoS and then tuning the buffer settings.
06-30-2016 01:55 PM
Another cause of output drops on user interfaces, not what you'd expect: I ran across an issue where I thought I was getting output drops on user ports due to QoS; however, it turns out it was actually due a flapping stack cable between switch 2 and 3. Check "show stack-port summary" and look at the #change to LinkOk" values. The output drops seen with "show mls qos int g3/0/10 statistics" as well as looking at "show platform" commands to look at the asics counters / drops, were showing the drops on g3/0/10 and other user interfaces even though the packets were not making to it the switch because they were dropped when the stack cable from switch 2 to 3 flapped. It must be since the switch stack/IOS knew the packet was destined out port (g3/0/10) that it attributes the drop to that port even though the packet never arrived on the stack port on switch 3. This was seen on 15.0(2)SE8. btw, the issue with the flapping stack cable was due to a canted connection on the stack port; it was screwed down but not making a good connection on one side of the connector.
07-01-2016 03:08 AM
Interesting.
03-18-2020 05:50 AM
Any ideas ?
I am also seeing drops in Q3, weight 2 , with no qos enabled.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide