cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
21065
Views
10
Helpful
14
Replies

Output drops on 3750X

the-lebowski
Level 4
Level 4

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

14 Replies 14

the-lebowski
Level 4
Level 4

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

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?

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.

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.

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 that most traffic will use queue 3. That is because default COS applied when mls qos is disabled is COS 0. When you enable mls qos, traffic will be assigned default COS 1. Based on this it will be directed to queue 2.

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?

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

How could you identify that the problem is with the buffer?

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"?

rajen.jakhar
Level 1
Level 1

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
    

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.

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.   

Interesting.

Any ideas ?

 

I am also seeing drops in Q3, weight 2 , with no qos enabled.

Review Cisco Networking products for a $25 gift card