Cisco to HP Procurve

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?

Thanks for any feedback;

Edwin

 

The HP procurves are garbage, zero support from HP and little to no
usefull features.

 

We went down that road. We used HP stuff for a couple of years. We have recently returned to Cisco gear for a couple of reasons.

1. I can find support material anywhere for Cisco gear.
2. Interop with wireless systems
3. Confidence in the product to conform to and in most cases set industry standards.
4. The HP just does not have the feature set needed to meet our requirements
5. HP's performace was not that great in real world production

 

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.

--
Regards

Lothar Hofmann

Lothar Hofmann Mail:
Universitaet Siegen
ZIMT
Hoelderlinstr. 3 Phone: +49 271 740 4760
D - 57068 Siegen Fax: +49 271 740 2523

 

sorry, but thats not true.

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.


hope this helps.

 

If you don't mix catalyst and procurve there should be no problems
whatsoever.

I'm maintaining a net with HP switches and cisco routers/pixes, and had
no problems.

AFAIK HP is better for most users, who need just basic config +
switching (catalyst are said to have some interesting features with new
CatIOSes)

ML

 

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.

regards,
Barry

 

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.

Scott

 

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.