evilrouters.net

Here’s a fine example of that wonderful HP ProCurve engineering and quality control I’ve grown intimately familiar with:

The following problems were resolved in release K.13.71.

…

IP Communication (PR_0000044004) – Switches running software versions K.13.65 - K.13.68 may experience a resource leak in ICMP that eventually causes loss of IP communication with the following symptoms.

• The switch will stop routing traffic for hosts for which it provides gateway services.
• All dynamic routing protocols stop functioning. The switch will stop sending routing protocol packets, and will not process incoming routing protocol packets sent from its neighbors.
• In-band network management stops functioning. The switch will become inaccessible via Telnet, SSH, WEB, and TFTP.
• Console management may become very sluggish and may appear to be non-responsive.
• Output from the CLI command show ip route will be corrupted.
• A reboot is required to clear up the symptoms.

BUT AT LEAST WE SAVED SOME MONEY!

(Note: Yes, I have been bit by this bug.)

Apparently I need to stop “following” a couple folks on Twitter, namely @procurve. Because of my past experiences, I tend to not care much for HP ProCurve equipment and so sometimes the things posted by @procurve irk me, just a little.

One example was on August 28th, when @procurve “re-tweeted” this:

Now, in terms of functionality, the ProCurve 5406zl switch does not even come anywhere near a Cisco 7206VXR. They are in two completely different categories, as far as I am concerned. I made the remark that “they couldn’t have been doing much with that 7206vxr if they were able to replace it w/ a 5406zl”. Anyone who is familiar with both devices would, I’m positive, agree with me. Nonetheless, nice try at patting yourself on the back, HP.

So it’s little instances like this that annoy the shit out of me, considering the not-so-great experiences I’ve had with ProCurve in the last year or so. Today, @procurve posted this:

I, of course, wanted to hear what they had to say, so I clicked. Read the blog post, “Cost effective networking — The choice is yours”, if you’d like. I won’t post the whole thing here, but reading it will help you to understand my response.

If you did click that link, you won’t see my comments posted. As far as I can tell, my posted was never allowed to be displayed on that page. I’m glad I kept a copy before I submitted it. Here’s what I wrote:

Actually, the choice isn’t mine, unfortunately. I’m a “technical” guy, i.e. one who has to implement, configure, and maintain ProCurve equipment. You guys do well at catering to the beancounters, though, I’ll give you that.

If the choice were mine, I wouldn’t have had a couple truckloads of 5400s come through the loading dock. It would have been Cisco or Juniper gear instead — you know, equipment that actually has some of the features I need.

Your switches are okay at layer 2, they work great there. But for those of us who need some of these advanced features, you’re just not there. First chance I get, I’m ripping out every piece of ProCurve gear I have that’s running at layer 3 and they’ll be replaced with an “incredibly inflexible and limiting solution”.

I don’t think I said anything that was untrue. I got a bunch of new 5400zl switches (22 of them, if memory serves) and, to be quite honest, I’m not impressed. I did think it was ironic that a nearly eight-year-old “HP” ProCurve 9300 switch (which wasn’t actually an “HP” at all) had features I needed that the brand spankin’ new 5400s don’t have (route maps and policy based routing, for example). When a 9300 was yanked and replaced with a 5406zl, it was then necessary to move that functionality off to — you guessed it — a Cisco device.

To HP’s credit, as I mentioned above, their switches are fine — as long as you stick to layer 2. Unfortunately, I’m using them at layer 3 as well, and am amazed by some of the issues that this gear has. There have been numerous, repeated, and documented issues with OSPF ECMP. There was a bug where scp’ing a config file over (roughly) 4200 bytes in size would cause the switch to reset itself to factory defaults and, of course, a case I myself opened last December that still hasn’t been resolved (more on that in a minute).

Anyway, my comments never got to see the light of day on HP’s blog. Even so, “imtechchris” was nice enough to reply to me. He chose not to argue my points, though, and instead decided to attack my technical skills. Here’s his reply, in its entirety (just in case it disappears from the blog):

Now with regard to this statement I made:

First chance I get, I’m ripping out every piece of ProCurve gear I have that’s running at layer 3 and they’ll be replaced with an “incredibly inflexible and limiting solution”.

I was actually quoting their article and pointing to the fact that, if or when I have the chance, I’ll yank out that ProCurve gear and replace it with either Cisco or Juniper, which their original article alluded to as “incredibly inflexible and limiting solutions”. Apparently Chris couldn’t grok that. He chose to end his reply with “If anything is clear it’s that you don’t really know how to configure these switches and you don’t want to bother learning because it’s not Cisco or Juniper.”

I’ll argue each of those points with you. After about six years of dealing with this garbage (I’m referring to the ProCurves, Chris), I think I’ve got a little bit of an understanding of how they work. I’ve managed to keep a multi-site network with hundreds and hundreds of nodes running for the last several years. I took one HP certification test, the “Accredited Integration Specialist” exam (without studing, of course), which was a complete joke (it took all of 20 minutes to complete, and I scored 100% on it — I have the score report somewhere around here if anyone thinks I’m bullshitting). I never bothered to pursue any further HP certifications. Regardless, I’d argue that I do, in fact, “know how to configure these switches”.

Now, as far as me not wanting to bother learning because it’s Cisco or Juniper, well, you’re almost right. More specifically, I “don’t want to bother” because I’ve had repeated bad experiences. It is my job to manage this gear, however, and regardless of vendor, I will, to the best of my ability, keep our network up and running — that’s what I’m paid to do. Would I be a helluva lot happier about it if it were Cisco or Juniper gear? FUCK YES.

Last point: I was going to mention and provide details (with a screenshot, of course) of the case I opened w/ ProCurve support last December (22-Dec-2008, if memory serves), but the “Support Case Manager – Enterprise edition” is apparently having some issues. When I enter in the case ID to view the details, it takes forever and finally gives me a “Could not access case” error message. The issue in this case, by the way, was replicated by at least two others who read this web site and e-mailed me privately. Apparently HP told them two different things, including telling one that the issue he was experiencing (CPU utilization at 99%) was “by design”. I still have not heard of a fix, even after an HP guy came and spent the day with me documenting everything we could find related to the issue (thanks for lunch, Richard).

So, HP, fix my issues, quit shipping stupid bugs in what is supposed to be production-level code, and get some support and maybe then my opinion of you might improve.

Oh, and please, no calls or e-mails from my sales guys this time.

UPDATE: I finally got to the case details:

Looks like they closed the case on me on August 7th, even though the last message I got from an HP engineer reads:

Just a quick status update on this issue. Our lab has been very busy with some hot issues recently and hasn’t yet got around to reproduction testing yet. I hope to have a more definitive answer for you by the end of next week.

That was on July 10th, and was the last thing I heard about this issue. There is no “solution” or “fix” mentioned in the case details, either. Thanks again, HP, way to suck.

And people wonder why I hate HP…

This is probably the shortest video I’ve ever made, but the task is really simple — configuring the Simple Network Time Protocol (SNTP) on an HP ProCurve switch.

For reference, here’s the “sntp” commands available in the software:

ProCurve Switch 2610-48(config)# sntp ?
 broadcast             Operate in broadcast mode
 <30-720>              The amount of time between updates of the system clock 
                       via SNTP
 server                Configure SNTP servers to poll time from.
 unicast               Operate in unicast mode
 <cr>

…and, of course, “timesync” takes an argument too…

ProCurve Switch 2610-48(config)# timesync ?
 sntp                  Set the time protocol to SNTP
 timep                 Set the time protocol to the TIME protocol

Pretty simple, huh? Here’s the video:

Nothing earth-shattering here, but back in February, I posted “Upgrading ProCurve firmware via TFTP”. Since that time, I’ve started posting video demos of some of the things I write about, so I thought I’d make up a quick one for this task as well. I happen to have a 5412zl switch sitting here next to me that I just powered up for the first time, and I know from the search terms people use to reach my site that this is one of the most popular HP-related posts, so perhaps seeing this in action will help understand it as well.

The first thing you’ll want to do is head over to ProCurve’s “Software for switches” page and grab the appropriate software for your switch. At the time of this writing, K.13.63 is the latest available on the web site, however I grabbed K.13.68 from HP’s FTP server. Unzip the file that you download, read the release notes, and copy the software over to your TFTP server.

After that, it’s just a matter of following the steps in the previous post.

Here’s an update in action (note that this switch shipped with K.12.57 and all software versions after K.13.61 include a BootROM update, so we’ll our switch reboot automatically in the middle of the update. Also, by default, the switch use DHCP will acquire an IP address on VLAN 1, so we don’t have to configure one (though it’s always a good idea, of course).

Note that this whole process takes quite a bit longer than shown in the video. When I was done recording, the video came in at 08:19 long. By removing a lot of the “waiting”, I was able to get it down to the 02:42 that you see here.

From eWeek’s article entitled “Cisco, HP Clash over Networking Equipment Pricing”:

HP is looking to focus the debate around its networking equipment competition with Cisco around price.

Since they can’t compete on quality, that only makes sense.

Soderlund also said that HP ProCurve is looking to expand into the enterprise. HP ProCurve has a traditionally strong presence at the edge of the network, but HP is looking to move closer to the enterprise.

Unfortunately, I let HP “move closer”. I wish I hadn’t. They’re fine at the edge, but don’t let them “move closer” than that.

About this time last year, we spent six figures for new gear for one of our buildings. If I had been able to get Cisco gear for the same price as the HP gear (as the article seems to allude to), well, you know…

Personally, I can’t wait to get my hands on a Juniper EX4200. We have a “shovel ready” building construction project and $20 million. While purchasing gear for the new building is still a little ways off, I feel it is my duty as an employee to properly evaluate all the options and make the best recommendation I can.

That reminds me, I need to call the Juniper Sales Manager…