evilrouters.net

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 HP’s Advanced Traffic Management Guide:

“BPDU protection is a security feature designed to protect the active STP topology by preventing spoofed BPDU packets from entering the STP domain. In a typical implementation, BPDU protection would be applied to edge ports connected to end user devices that do not run STP. If STP BPDU packets are received on a protected port, the feature will disable that port and alert the network manager …”

In short, we want to enable BPDU protection on any “edge ports”, or ports that are connected to end user devices (PCs, printers, etc.) — any device that should not be sending out STP BPDU’s. Without BPDU protection, a malicious (or ignorant) user could plug a switch into our network and alter the spanning tree topology. That’s a bad thing.

With BPDU protection, we can a port automatically disabled if it receives an STP BPDU. Under normal circumstances, this should never happen. Enabling this feature does two things:

• helps protect your network, and
• keeps you, the network guy (or gal), informed about what is happening.

Let’s assume a user brings in their own switch from home. They unplug their PC from the wall, plug into their own switch, then plug their switch into the data jack in the wall. As soon as their switch sends out a BPDU, our switch will receive it and immediately disable the port. If you do not configure your switch to automatically re-enable the port after a specified period of time (I don’t), their data jack is effectively dead. It cannot be used again without the intervention of the network guy. When they can no longer work and must come to you for assistance, you’ll have a good idea of what they did and can promptly break their fingers educate them on why they should never do that.

On HP ProCurve switches, we enable BPDU protection with the “spanning-tree <port> bpdu-protection” command. You can do this individually per port (you can specify ranges) or do it like I do:

SWITCH(config)# spanning-tree all bpdu-protection

This, in my opinion, is the best way. This will enable BPDU protection on EVERY port. Then, you selectively disable it on your uplink ports:

SWITCH(config)# no spanning-tree a24 bpdu-protection

The default BPDU protection timeout is set to 0. This is the amount of time, in seconds, after which the switch will re-enable a port that has been disabled due to receiving an “illegal” BPDU. A value of 0 means “never”, and is the value that I prefer. This ensures that “network guy intervention” is required to break the user’s fingers re-enable the port.

Let’s take a look at what happens. In this example, I have BPDU protection enabled on port A2 (all ports except for A24, actually), as can be verified here:

SWITCH# sh spanning-tree bpdu-protection

 Status and Counters - STP Port(s) BPDU Protection Information

 BPDU Protection Timeout (sec) : 0                     
 BPDU Protected Ports : A1-A23,B1-B24,C1-C24,D1-D24,E1-E24,F1-F24,G1-G24,H1-H2...

So, having verified that BPDU protection is enabled on port A2, what happens when we plug another switch into that port? You obviously can’t see me plug in the cable, but here’s what we get in our logs:

SWITCH# sh logging
 Keys:   W=Warning   I=Information
         M=Major     D=Debug E=Error
----  Event Log listing: Events Since Boot  ----
I 03/12/09 00:02:41 00435 ports: port A2 is Blocked by STP
I 03/12/09 00:02:41 00840 stp: port A2 disabled - BPDU received on protected
            port.
I 03/12/09 00:02:41 00898 ports: BPDU protect(5) has disabled port A2 for 0
            seconds
I 03/12/09 00:02:41 00077 ports: port A2 is now off-line
----  Bottom of Log : Events Listed = 99  ----

Our switch will, when the port comes “up”, wait briefly and just listen. It will wait to see if it receives a BPDU (“Blocked by STP”) and, as soon as it does, notes this in the system log and immediately disables the port.

SWITCH# sh spanning-tree bpdu-protection a2

 Status and Counters - STP BPDU Protection Information

 BPDU Protection Timeout (sec) : 0                     
 BPDU Protected Ports : A1-A23,B1-B24,C1-C24,D1-D24,E1-E24,F1-F24,G1-G24,H1-H2..
.

  Port  Type      Protection State      Errant BPDUs
  ----- --------- ---------- ---------- ------------
  A2    100/1000T Yes        BpduError  1

The “sh spanning-tree bpdu-protection a2″ command shows us that port A2 is in “BpduError” state and has received a total of one “errant BPDUs”. Now, let’s assume we’ve unplugged the switch and plugged a PC back in. How do we get the port functional again? Easy:

SWITCH# conf
SWITCH(config)# interface a2
SWITCH(eth-A2)# enable
SWITCH(eth-A2)# end

That’s all there is to it! BPDU protection is simple to implement (assuming you know what connects where) and can add a bit of protection to your network. Turn it on!

new security features are being added to many enterprise switches. the availability of those features varies based on what vendor’s equipment you’re using (as well as the firmware) and each vendor offers similar features but call them by different names.

this table illustrates a few:

…thanks to informationweek