3750's - Throughput Issue.

[mtevans]

I have a throughput issue on 3750's that I cannot find a reason for.

Here are the models and SW versions:

Switch Ports Model SW Version SW Image

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

1 28 WS-C3750G-24TS 12.2(20)SE C3750-I5-M

* 2 52 WS-C3750-48TS 12.2(20)SE C3750-I5-M

3 52 WS-C3750-48P 12.2(20)SE C3750-I5-M

I am encountering slow response between servers in one vlan and SOME clients in another vlan.

If I place a "SLOW CLIENT" in the same VLAN as the server (Same ports/cabling etc) the throughput problem goes away.

The intervlan routing takes place withing the stack itself and not externally.

I can find no reason for this behavior, CPU/Memory are well within limits.

I have been reading IOS release notes but can find no mention of this. I see no other people on this forum having similar issues.

Does anyone have any thoughts ?

[glen.grant]

If you have double checked the client and switchport settings to make sure they match exactly then I'm not sure . It could be something like this , at least soemthing to check.

CSCed30201 Bug Details

Headline Temporary Packet loss maybe exhibited by the switch - stack cable

Product IOS

Feature OTHERS Components Duplicate of

Severity 2 Severity help Status Resolved Status help

First Found-in Version none All affected versions First Fixed-in Version Version help

Release Notes

SYMPTOMS / CONDITIONS

Cisco has found occasional intermittent contact on the 3750 product

stacking cable when using the "Fox" labled speciified cables. The location

below shows a photograph of the label showing the word "Fox" printed on the

label.

Sjc-fs1\WG-D\DSBU-Escalation\Published\Bugs\CSCed30201\3750_Bad_Stacking_Cable_Label.doc

WORKAROUND:

These "Fox" labeled cables should be replaced. Contact Cisco's TAC and

request a cable only replacement.

No problem exists with the 3750 switch itself and should NOT be replaced.

The customer should be advised that the "Fox" labeled cable should be

destroyed so that the customer will not accidentally place the defective

cable back in service at some later time.

BACKGROUND:

Failures were found in Cisco's DSBU lab that cause an intermittency resulting

in reduced traffic speed.

Failure analysis was completed by the cable / receptical vendor. The failure

indicated a substandard design, with an out of tolerance tongue in the plug and

potential misalignment in the receptical. This vendor has been disqualified

at this time.

[mtevans]

Unfortunately that particular stack of 3750's does not have a "FOX" cable. The switchport settings are good.

It is a very strange problem that has my users annoyed. On some ports it takes less than a second to open a 8MB Access DB file when the host is in the same subnet as the server, and greater than 10 seconds when in a different subnet.

There are no access lists, physical errors, CPU or Memory issues that I can find.

Thanks for that information however - that was new on me, I am having the rest of the network scoured as we speak.

[Darren Ramsey]

If you are running mls qos.then could be CSCeg29704. I have seen this before.

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

Release Notes

After enabling QOS on 3750 and 3560 switches, certain application (mostly bursty

and TCP based) experience significant performance degradation due to unexpected

packet drops on some of the egress queues.

This is due to initial default egress queue threshold settings

(when qos enabled) not optimized for this type of traffic pattern.

This initial default queue threshold settings (when qos enabled)

thus need to be changed to accommodate these traffic.

Workaround:

Tune the egress queue thresholds parameters to

allocate more to the affected queues.

Specifically, egress queue 2 thresholds need to have the following settings:

Thresholds1 = 200

Thresholds2 = 200

Reserved = 50

Maximum = 400

e.g.

mls qos queue-set output 1 threshold 2 200 200 50 400

mls qos queue-set output 2 threshold 2 200 200 50 400

[mtevans]

We do have mls qos turned on the switch.

This is the output of the "show mls qos queue-set" command:

Queueset: 1

Queue : 1 2 3 4

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

buffers : 25 25 25 25

threshold1: 100 50 100 100

threshold2: 100 50 100 100

reserved : 50 100 50 50

maximum : 400 400 400 400

Queueset: 2

Queue : 1 2 3 4

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

buffers : 25 25 25 25

threshold1: 100 50 100 100

threshold2: 100 50 100 100

reserved : 50 100 50 50

maximum : 400 400 400 400

Is it clear that we are running into this problem by the output above ?

[pciaccio]

Has this issue been resolved?? If not the issue may not be the switch but the type of data the clients and servers are sending(multicast). Can this be an application issue that requires a certain parameter in the interfaces turned on. Can you provide a configuration of the switch??