Procurve 1800s

[Alan Sielbeck]

Matt,

I really appreciate you looking into this. Sorry for the long delay in responding - yesterday I could not get logged in to the HP forums.

The testing I have done has been file copy and program usage. In all cases, running the dual trunk between switches, servers plugged into switch 1, clients on switch 2 (through 6 in our case) any / all 100 mb clients experienced slowdowns. This also was the case if running through a 10/100 switch / hub downstream (off switch 2).

Do you think it could be something wonky with our firmware version? I will get the version information tomorrow and see if a.) an update exists for the 1800 and b.) if this may explain our dis-similar results.

All 10/100 clients have reported a big boost in speed this week, I'd just like to be able to run without flow control. Thanks again for all your support. I will let you know what I find tomorrow.

Alan S.

[Matt Hobbs]

Hi Alan,

Although I couldn't see the issue, I'm still perplexed about it. I have a few remaining ideas which I'd like to test tomorrow.

1. Firmware versions, today I tested with an 1800-8G and an 1800-24G, I did have an updated firmware version from HP on one of them for a separate issue (there are no updates on the website though so you need to contact HP support to get this). The firmware versions didn't seem to make any difference but it would be still good to note what versions you're running.

2. Since you only have the 24-port versions I thought maybe I should be testing with 24-port switches only. What ports are you using as uplinks?

3. I need to check how fast the DL 380 that I was using can really transfer data, going gig-to-gig I was only getting about 230Mbit which may not be enough to overwhelm the switch when going to a 100Mbit device.

4. Back to flow-control, I have a feeling that maybe the switch can receive it's flow control settings from the client when auto-negotiating with a 100Mbit client. e.g, if the client has flow control enabled and is set to Auto, the switch will automatically enable flow-control on its port.

This could explain why you need to also enable flow control on the trunk which would give you end-to-end flow control, finally back to the server which would also be told to pause it's frames. It also explains why you do not need to enable flow control when the 100Mbit is connected directly to same switch as the server.

I've found a few OIDs in the RFC that seem to hint at this so I'll check this theory out tomorrow.

One question for you is that on the 100Mbit client NICs, do you know what their flow control is currently set to?

[Alan Sielbeck]

Matt,

I'm using ports 23 and 24 on Sw #1 to 23 and 24 on Sw #2. Ports 21 and 22 of Sw #1 to 23 and 24 on Sw #3. So on and so forth. Trunking is set T1 = Sw #1 to Sw #2, T2 = Sw #1 to Sw #3. So on and so forth.

As far as overwhelming the switch, I would think that almost anything about the 100 Mb should kill it. I was seeing link utilization peaking at 5% with no flow control, averaging 1% - 2%.

I'm betting you may be right on the flow control being negotiated, thus explaining not needing to set it. I am not sure of the settings for flow control, but I will check tomorrow. I'll also report the firmware.

Alan S.

[Matt Hobbs]

Alan,

I tried working some more on my auto-negotitation flow-control theory this morning but seem to have hit a brick wall as it turns out the 1800 does not reply to the OID's in RFC2665.mib that I was hoping to probe it for.

However, I did test the theory on a 3400 - but it seemed to go against what I was hoping. If flow-control was disabled on the switch port it stayed disabled no matter what the client was set to. There is a chance that the 3400 is not adhering to the standard but I'd say that's a long show and I'm probably not deciphering the RFC properly.

I'd still like to be able to reproduce the issue so if there is anything you can do on your side, possibly trying iperf or FTP transfers instead, that will make it easier for me to reproduce in a lab environment it would be appreciated.

[Jordan D]

I have a similar issue with a customer being worked out at the NSC as I type. The issue here was very slow file transfers coming from a server. A workstation could copy a 50 meg file to the server in about 6-10 seconds. Pulling down the same size file happened to take somewhere around 10 minutes.

As this moment, the only time the engineer was able to reproduce the slow file transfers from the server to the users was when one side of the link was at auto and the other was forced.

He did determine when forcing both the switch port and the workstation to 100FDx, the problem seemed to vanish.

[Alan Sielbeck]

I will try to test with an FTP client tonight. The symptoms were seen loading database information for software used with one company on the network. Prior to implementing flow control on the trunks, the 100 Mb clients were seeing avg. report response times of 25-30 seconds. This was for a basic report. With flow control enabled, they are getting 2 - 3 sec MAX refreshes.

I checked the switches for Hardware version / Software version.

Hardware: R01
Software: PB.02.03

Just verified that all switches are running the same software version and hardware version.

[Alan Sielbeck]

Jordan,

Were your problems occurring when the server was on switch 1, and a client was on a different switch? My problems went away completely if I put a 100 Mb client on the same switch as the server. Once I had the client on a different switch, the problem presented itself.

[Victor Baidez]

We are in the same situation, exactly than you.

We have 6 1800 24-G J9028B, servers are in switch 1, from switch 1 to 2,3,4,5 and 6 we have a uplinks from Switch 1 ports 20 to 24.

S= Switch
P= Port

S1P20 <-> S2P24
S1P21 <-> S3P24
S1P22 <-> S4P24
S1P23 <-> S5P24
S1P24 <-> S6P24

When connect any 100FDX pc on SWITCH2 or 3,4,5,6, in autosensing mode or forced, from this pc network its extremely slowed, 40MB = 6min. GB users do not have any problem.

I tried to increase bandwitch creating a trunk to test with 2 ports

S1P1 <--> S4P1
S1P20 <--> S4P24

But The result is the same slow performance 40MB 6min.

Net Traficc its very light in our network.

¿Anyone can helpme?

Information of switchs

Procurve 1800 24-G J9028B
Number of Ports 24
Hardware Version R01
Software Version PB.03.02

Thanks in advance and sorry for mi poor english ;)

[Gary Gemmell]

You need to disable jumbo frames.

Had exact same problem but solved my updating all switches to same firmware and turning off jumbo frames.

Everything hinges around this as these switches dont seem to like jumbo frames and cant handle the bandwidth.

Buy cheap pay twice was my grans motto and it always seems to hold true.

Buy quality and you will never or very rarely ever have to go through wasted hours days and nights fixing the minutae.

Ill stick with Cisco 3550 from now on - never ever had these problems with Cisco gear.

And yes IOS is an outdated system i hear a lot of people ragging on this but proof of the pudding is in the eating - Cisco stuff is rock solid and as long as you are good with IOS you should rarely encounter wasted time like this!!!