We are a Cisco shop. We have a 6509 which has total redundancy yet has failed twice in 5 years. We have Cisco routers and switches at multiple locations all of North America.
We are considering HP Procurve for our LAN infrastructure. This would replace 6509, 2950, 1900, and other simular model switches. This is because on paper the HP outperforms the Cisco at a much smaller cost. Maybe not all of the feature are there, but everything we need.
Anyone else go this path? All I see from searching is people asking about it, but never following up with the experience they had. What were your results? Would you do it again?
Be very careful if you mix these boxes! Interoparabilty is _not_ garanteed. We had big problems with spanning-tree for hp doesn't know about pvst. So we stayed with Cisco.
I've got more than 30 HP Procurve switches; and got tickets with HP. Got support and resolution; zero problems. About features; you told no usefull features; could you tell me an unuseful feature you find on the hp procurve; i cant find such special features...
I've got some catalyst in my network and you're right...some problems linking them..but nothing without a solution.
You must be careful with spanning tree; but if you keep with latest firmwares with cisco support you wont have any kind of problems.
Saw another problem with procurve and catalyst; sometime i got negotiation errors linking switches configured with autonegotiation...just forced 100Full and the problem go away.
We do have spanning tree. We don't have the latest firmware. So must we remove all STP from our network, or just not use STP links to the HP switches?
We have seen problems with HP servers negotiating 100/FULL but the Cisco Switches 100/HALF when we use the HP Insight agents (not with the Microsoft drivers) so we force the HP servers to 100/FULL on both ends. Is it the same problem with the switches?
well, if you keep this firmware you wont have any kind of problem with STP. When you plan the upgrade of the firmware you will see a warning on the HP site regarding the STP.
about the auto negotiation issue; i've got problems by connecting to catalyst switches and to Allot net enforcers (similar to packeteers). But the solution was the same you used; forcing 100Full link.
Note; sorry before posted with another gmail account
My experience with HP is on the 4000 and 4100 serires switches. They run OK on the edge, but I would never put them any further in then that. I can confirm that the support for these products pretty much sucks. I dont even believe it is 24/7. perhaps they have engineers that support the high end gear that can do more then RMA a device. I believe that one of the most important factors in the decision of your core should be the support that you receive in addtion to the reliablity of the gear itself. Perhaps you should investigate your design as well as the gear you are using.
Does your two failures in five years with full redundancy mean you had two failures and the redundancy worked, or you had two failures because the redundancy didn't work? If your redundancy didn't work than that means your design has flaws in it, and replacing the equipment with HP (or any other manufacturer) won't fix the problem.
I engineered a system using HP Procurves for an ISP who put a system in an apartment complex and everything work very well. I went with HP because the customer couldn't stomach the cost for Cisco because he did not see why he needed to spend a bunch more money for "all the extra features" he didn't need. Everything worked very well and HP was great at replacing the switches when they died on a regular basis. Support was good, but the depth was not what he was used to in dealing with Cisco. Later on, some of the new features that he want to implement, and doing some advanced troubleshooting weren't possible because the features he needed to do them were not available. All in all, the customer was happy because he knew he got what he paid for.
On another note, HP uses Cisco (CGESM) and Nortel (GbE2) switches for their BladeSystem. They do not make a ProCurve based switch for use in the BladeSystem and that should tell you something.
One failure was when a supervisory card ($12,000 US) failed after plugging in a module - and the second redundant one (another $12,000) did not take over supervisory role. The switch failed the bus. Console worked, but no switching. Required a reboot.
Another failure was a blade that failed bringing down the entire switch. We had multiple blades. One blade failing should have only failed that blade.
We had other failures, such as a power supply failure, but I haven't counted those as the redundant power supply kept us online and we replaced the failed supply with another with no downtime. Other simular issues without downtime have occured.
The Cisco offers a lot of features we don't use. We don't do VLan routing. We have just one secondary Vlan. no QoS on the backbone as we are way under subscribed. (QoS done at the edge) We use it mainly as a central switch for our computer room where everything ties together. Departmental switches pluging into this large central switch with no more than 3 switch hops between nodes on the LAN.
I don't like comment that HP switches die on a regular basis. What does that mean? We are a 24/7 shop. I don't want to come in on Christmas at 2am because of a switch failure. The Cisco's rarely fail. We are hoping to have less downtime with the HP backbone switch, and then later departmental switches.
i think that the problem is partly cisco and partly the assumption that "1 switch" can even approach full resilience.
the nearest you can get to full resilience is 2 parallel central switches. ie - 2 chassis in different parts of the building, different power supplies, separate cable runs.
no way would your "full resilient" switch keep going under some of the more severe kinds of fault i have seen over the years: mad painter with wirecutters
6 feet of water in a computer room in a basement cracked backplane power fault which put 2 phases across all PSUs in a comms room (440v here in UK) bomb threat emptied the building and the fire brigade turned off the power
some of these are so bad you really need 2 sites to "fix" the issue - but you get the point.
even here the design gets more complex and you now are susceptible to some system failures such as routing stability due to all the resilient paths.
the other issue is what dual Sups and all the complex in box resilience is doing - what happens is that the comtrol software becomes much more complex and has to deal with lots of rare kinds of problem - that is possible, but the complexity means that it is difficult to do, and even more difficult to test - so bugs are likely.
FWIW i am happy to install dual power, i will distribute core connections across different blades to allow the switch potentially to carry on with a blade failure.
AFAICT dual Sups and similar complexity dont seem to actually improve availability in practice. they may help with some high availability stuff such as in service software upgrades - but that sounds even more risky......
ask the vendor for both calculated and measured MTBFs - and get them to explain how the figures are arrived and whether they exclude some sources (e.g. those counted by 3rd party maintainers).
this at least gives you some numbers to do a comparison on what you can expect.
Depends what you pay for. If you pay for a 24/7 support contract with HP, it can be very good indeed - depending on where you are in the world. Cutting down on support is one of the ways that HP lowers costs.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.