Odd Performance Issues on 3750 Stack

[GRANT3779]

I have come across a strange issue on one of our Stacks. Stack details below. The 48 port switches are only 100Mbps capable and the 24 port switches are 1Gbps capable.

1   WS-C3750G-24PS     12.2(55)SE9           C3750-IPBASEK9-M
2   WS-C3750-48P       12.2(55)SE9           C3750-IPBASEK9-M
3   WS-C3750V2-48PS    12.2(55)SE9           C3750-IPBASEK9-M
 4 WS-C3750X-24P      12.2(55)SE9           C3750E-IPBASEK9-M

There are some access switches

It's been noticed that when servers (running some applications) are plugged into any of the 1G ports on the stack then access to them is very slow fro user PCs. User PCs are plugged into 100Mbps ports on same stack.
if the server is moved to one of the 100Mbps ports within the same stack then everything works fine.  The ports involved negotiate full duplex. It's strange as everything is within the same stack.

Has anyone come across anything similar to this? Have tried moving the Server to multiple GIG ports to test and always the same.

If however we move the user PC to one of the GIg ports as well, then everything works OK. Possible Stack Cable issue? Any ideas at all? Just seems odd as it's all the same stack.

[Joseph W. Doherty]

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

I'm wondering when user PC is FE and server is Gig, whether the latter is just overrunning the former causing a high drop rate.  (Do interface drops increment on the FE interface?)

When both hosts are FE or Gig there wouldn't be the chance to overrun the destination port.

PS:

If you do see drops incrementing, is QoS enabled?

[GRANT3779]

Hi Joesph,

Could be onto something. Looking at the 100Mbps ports - all are showing a high number of Output drops.

QOS is configured on this stack, for Voice.

Thanks

[Joseph W. Doherty]

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

Ah, well if you're using default buffer settings, that's often the norm on a 2960/3560/3750 switch.  Boosting the tail drop settings can often mitigate.

[GRANT3779]

We are actually using specific QOS settings advised by an external consultant (Not Auto QOS). This was more for the voice I believe.

Are there any obvious config areas I can check to see exactly where the issue lies? I'm no QOS expert by any means. Only just started reading my nice thick "End to End Qos" book

[Joseph W. Doherty]

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

You could further identify what queue and threshold is having the drops.  Use the command sh mls qos interface statistics and look for the output queues dropped: section.

You could also post your QoS related statements.  (Try the command sh conf | in qos|mls|queue)

[GRANT3779]

Hello Joseph,

I have attached a file with these details. Does anything stand out from these?

Thanks

[Joseph W. Doherty]

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

One thing that stands out, the buffer assignments don't allow for any common pool buffers so the WTDs above 100% would be ineffective.

Most of your drops are in Q2, WTD 1, which has one of the lower WTD settings.

How were your QoS settings determined?

[GRANT3779]

Afternoon,

These were determined to be best practice for real time voice. No other applications / traffic classes were taken into consideration when designing the QOS.

[Joseph W. Doherty]

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

Ok then, then it's back to the drawing board.  ;)

An incorrect (or incomplete) QoS configuration can make for issues.