Switches, Hubs, and Modems
1747989 Members
4749 Online
108756 Solutions
New Discussion юеВ

Procurve 2650 Fighting with Catalyst 5000

 
SOLVED
Go to solution
Larry Patterson_3
New Member

Procurve 2650 Fighting with Catalyst 5000

We recently moved almost all of our users from a catalyst 5000 onto a procurve 2650. The 2650 is linked to the 5000 and set to auto. The 5000 was set to 100 mbps and full duplex. However the procurve status read 100 mb half duplex. When attempting to force the 2650 to 100 full a loss of link occurs. When both are set to auto they appear to work ok but my wan support insists that the procurve must have a firmware update or crossover cable needed for this to be set correctly which he insists is one side set to auto and the other side forced. Suggestion anyone?
7 REPLIES 7
SCOOTER
Esteemed Contributor

Re: Procurve 2650 Fighting with Catalyst 5000

Check out the following link:

http://www.hp.com/rnd/support/faqs/sw_408.htm#question2

So if you set one device to auto and force one to 100Fdx the auto-side will automaticly set itself to 100Hdx and then you have a missmatch with linkdrops.

Kind regards,
SCOOTER
Ron Kinner
Honored Contributor
Solution

Re: Procurve 2650 Fighting with Catalyst 5000

The 2650 automatically decides whether it has a straight cable or a crossover and adjusts its connectivity to make it work BUT it only does this in AUTO. IF you change it to 100 FULL then you will need to use a Crossover cable instead of the Straight cable you are probably using now.

Your WAN support is wrong. Auto will never set up to Full if the other side is not Auto. The RFC does not allow it to do that so it will automatically choose Half duplex if the other side is set to Full. I think it is a stupid idea but that is the way it is.

Ron
Larry Patterson_3
New Member

Re: Procurve 2650 Fighting with Catalyst 5000

Thanks Guys

Shane_33
Frequent Advisor

Re: Procurve 2650 Fighting with Catalyst 5000

It's actually not stupid.

This "feature" was put in because we live in a world where hubs still exist. As hubs are half duplex only, the RFC needed to support a link connection with a hub if it does not respond to "auto" duplex negotiation (which it can't). So the fallback was set to half duplex.

The standard for auto duplex detection requires both switch ends to be set to auto. If you hard code one end, you need to hard code the other too, otherwise the switch will assume it is talking to a hub.

It makes perfect sense when you think about it.

Keep in mind, auto speed detection and auto duplex detection are two different things. That is why the link comes up at 100 mbps (as the auto speed worked), but not the duplex.

Not sure why hardcoding both ends to 100 Full Duplex causes a link loss, but I can only gather this is more the (now) unsupported 5000, as the 2650 works fine with 4500's and 6500's.

Regards,
Shane.
Larry Patterson_3
New Member

Re: Procurve 2650 Fighting with Catalyst 5000

Forgot to add guys that the link between the 2 devices does periodically drop. The procurve of which I can view does not show any errors or problems. However, the alerts are set on medium (as of this notice they have been turned up to high). The Cisco catalyst 5000 I can not view because my wan support is stingy with the password. Any help is appreciated... thanks
Larry Patterson_3
New Member

Re: Procurve 2650 Fighting with Catalyst 5000

Situation resolved.... As it turns out the problem was a "trunking issue". The port on the catalyst was not set up to see the vlan where the gateway resides. Trunking I don't understand as I've not had a need for that yet however am looking for any and everything to read on the subject now. Any reading material is appreciated.
LP
Ron Kinner
Honored Contributor

Re: Procurve 2650 Fighting with Catalyst 5000

Larry,

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008012ecf3.shtml

is a good place to start with Trunking info.


Shane,

I could understand the reasoning if the autonegotiate didn't know what the other side was. What annoys me is the display on my switch where it tells me that the other end is set to FULL but it is going to set itself to HALF anyway. I think the RFC is a bit outdated. Nowadays it is easy to tell what the other side is set to so why not allow autonegotiate to be just a tad bit smarter and save us all a lot of trouble.


Ron