Initial thoughts on the HP A5500-EI switch

Background

I first came across HP's A5500 switches when i started looking at configuring VRRP and distributed trunking to provide routing redundancy for the core of a client's campus network using two ProCurve 5400 switches. I found that i could get a new pair of A5500s for around the same price as the software license upgrade on the 5400s (multicast routing, distributed trunking, and OSPF cost extra), and they came with a much broader range of features. HP's IRF is far preferable to VRRP and distributed trunking from the perspective of administrative complexity, since the IRF stack appears as a single switch to hosts and other switches.

The 5400 is a chassis-based switch, and replacing it with the stackable 5500 would not normally be ideal for a core switch setup, but we had very low port density and bandwidth requirements in our core, so two 24-port 5500s were sufficient. The 5400s were moved to the distribution layer along with a pair of 2824s used primarily as copper-to-fibre converters. Each distribution switch has four 1 Gbps links to the core (two to each switch) as an LACP trunk, as does each of our four VMware ESX servers.

I've been using ProCurve networking for about 9 years, working with it directly as a network admin for the past 5. Most of my networking experience has been with E series switches, so i will write mostly from the perspective of a ProCurve user. I've learned about these swiches mostly from reading the manuals and testing features as we migrated our core from standalone 5400s to an IRF stack of 5500s, but Wayne Jewell at Layer127 also provided some helpful assistance with ACLs and OSPF.

This review will probably degenerate into note form before too long, since i've been sitting on a draft of this post for far too long already, and i want to get it out the door. :-)

Packaging and hardware

The information in this review is based on A5500-EI switches running Comware 5.2, revision 2208. The switches were shipped on firmware 2202; finding, downloading, and upgrading the firmware to 2208 (via Xmodem over the console cable) was an easy and straightforward process. (Cisco, take note!) After i set up the IRF stack, the second switch automatically downloaded the firmware from the first switch, installed it, and rebooted as an IRF stack member.

The switches are branded H3C rather than HP. I assume this will change as they do new manufacturing runs. Hardware quality of the units themselves seems excellent - they continue HP's excellent track record with the ProCurve platform, and have inherited its lifetime warranty.

Perplexingly, port numbering on the switches starts from the bottom left rather than the top left, which is rather disconcerting to those of us expecting a traditional layout. I assume this is due to the switch's Chinese heritage. I've intentionally designed the port configuration on our stack to minimise the risk of errors related to this, but i'm pretty sure it will cause operational problems sooner or later. Let's hope that HP produces region-specific versions of these switches which allow customers to choose top-to-bottom port numbering.

Main features

Features i've tried (in alphabetical order):

  • ACLs
  • DHCP relay
  • IRF
  • LACP (bridge aggregation)
  • NTP
  • OSPF
  • PIM (dense mode)
  • RIP
  • UDP helpers

All of the above work as expected and without hiccup. When i first connected the IRF stack as the network core, it was a disappointingly quiet maintenance window; there were no major problems to deal with.

One perplexing issue which hasn't been resolved yet on our 5500s is that 20% of ping packets to any IP interface on the switches are lost. There have been no issues with performance of the switching and routing, so it seems to be just a management plane issue. (See further comments on CLI responsiveness below.)

User interface

All of my access to the 5500 has been at the CLI via console cable or ssh session. I haven't bothered configuring the web interface, nor looking at HP's IMC management software (which i hear is excellent). Most of the rest of this review will relate to CLI features.

Command syntax

Much of the Comware command syntax seems to use alternative vocabulary from the command sets on most other switches and routers as a deliberate technique to make it seem different from Cisco. However, this difference seems to be only skin-deep, and most of the commands follow an almost identical structure to Cisco. (This is particularly evident in interface context.) I don't have enough experience with 3Com equipment to comment on whether this was the case with earlier Comware releases or is a feature of only the post-Huawei switches.

'display this' is an extremely useful command when you're configuring anything which has its own context (e.g. OSPF). It gives you immediate feedback on what you've just configured, without introducing noise or requiring pipes.

'hotkey' is a way to create shortcuts for common commands. I've defined:

  • Ctrl-O as 'display ip rout | exclude InLoop0' (mnemonic: 'rOutes')
  • Ctrl-T as 'display this' (mnemonic: 'This')
  • Ctrl-U as 'return' (mnemonic: 'Up one level')

'command-alias' is great for making things a little more familiar. Examples of common commands which might be aliased are:

  • show - display
  • no - undo
  • exit - quit
  • end - return

The default output of many diagnostic commands (e.g. 'display vlan') is unneccessarily verbose by default. I much prefer the ProVision approach, which gives brief tabular data by default and requires additional parameters to extract details.

Interacting with the CLI

Having access to basic pipe facilities ('| begin/include/exclude') seems like a minor issue, but after using it for a few days, going back to switches without this feature becomes increasingly frustrating. (I understand this has also been added on recent 5400 firmware versions.) I long for a real 'less' command which can page forwards and backwards in command output. (I hear Cisco has a real 'grep' command on their latest IOS; hopefully this is a sign of better things to come.)

The 5500 doesn't seem to detect terminal length like the 5400 does. The 5400 detects changes in terminal size even during the same session, whereas the 5500 seems fixed at 25 lines.

Ctrl-C doesn't cancel command input, only running commands (well, some of them - it doesn't work with 'display ntp-service trace'). One has to substitute Ctrl-E followed by Ctrl-X or Ctrl-A followed by Ctrl-Y instead. Ctrl-A is a pain for me to use because i'm usually connected either through minicom or GNU screen. I long for a real bash shell (which supports vi editing mode) on a switch.

Note to self: investigate Vyatta and Arista on this point.

The 5500 is somewhat more sluggish to respond to commands at CLI than the 5400, both when connected via the console cable, and when using ssh over gigabit Ethernet. This may be due to a relatively low-powered CPU being used for management, but that would explain poor ssh keystroke latency without explaining the same experience over a 115,200 baud console cable. Most of HP's low-end ProCurve switches (e.g. 2824, 2610) are more responsive than the 5500.

The 5500 CLI also requires that the backspace character be set to Ctrl-H instead of the usual delete, and i could find no way to change it in the CLI (i.e. there's no equivalent to stty on Linux/Unix). This is more troublesome for those of us who routinely switch between Comware and ProVision switches. A facility in the CLIs to allow a consistent backspace setting to be used would be highly desirable. (Alternatively, they could just allow both Ctrl-H and DEL on both platforms and then everyone could forget about it. I suspect this is what ProVision already does.)

VLAN setup

Configuration of ports and VLANs is the most Cisco-styled part of the CLI and is much harder with Comware than ProVision. I personally think that dealing with port modes is the most cumbersome part of configuration on all of the non-ProCurve switches i've worked with, and i very much hope HP retrofits the VLAN parts of the ProVision CLI to these switches.

Changing a hybrid port to a trunk port (or vice versa) requires setting it to an access port first. I can't conceive of any technical reason for this being exposed in the CLI; if it is a technical requirement, it should be done automatically by the underlying OS.

On that note, is anyone out there using hybrid ports in a production environment? I can think of only one reason for using them (protocol-based VLANs), and i can't see why anyone would want to use that for anything more than a fun experiment.

ProVision has 'show run vlan' on recent firmwares, which shows only the VLAN definition parts of the config. There seems to be no equivalent on Comware, even though there are similar parameters for other subsystems (e.g. 'display current-configuration configuration acl-adv').

VLAN descriptions can only be 32 characters long - this is not enough to give a useful description. Note that this is not the (short) display name, which is set separately.

ACLs

ACLs use negated rather than conventional netmasks - this seems rather counter-intuitive to those of us who have worked mostly with host-based firewalls, but once you are familiar with it, it isn't too hard. Anyone who has worked a lot with OSPF on Cisco devices should find it no problem.

Non-contiguous netmasks may be used with ACLs, which is a useful feature if you use a standard numbering system for gateway addresses, server IP ranges, and the like.

The 'hardware-count' feature is disabled by default on all ACL entries. Since the switch automatically reverts to software counting for any ACLs which do not support hardware counting (e.g. SNMP access to the management plane), i cannot conceive of a reason why it should not be enabled in all cases.

Documentation

The H3C documentation will be unfamiliar to people who are expecting ProCurve's rigidly-defined format, but it is mostly of a high standard. It wastes a lot of space repeating how to get to the required view for most commands and shows some signs of backtranslation into English (also present in the CLI), but i have only encountered only one error so far (the documentation of 'display interface brief' as 'display brief interface'), which was corrected in a subsequent version of the document. HP networking's documentation site seems to lag behind the current firmware version; i found the documents updated for 2208 on H3C.com months before they appeared on HP.com.

HP networking have produced a resource which has made my conversion from ProVision to Comware much more straightforward: the HP Networking and Cisco CLI Reference Guide, which can be found at HP Networking's training resources page. This document compares the Comware, ProVision, and IOS versions of many common commands, focusing on practical day-to-day differences and providing lots of examples. It is an indispensable reference for network engineers switching between these platforms, and has even been a useful resource in helping me become more familiar with Cisco's CLI.

The Future

After working with Comware for a few months, i have come to appreciate its feature-richness compared with ProVision. I have really enjoyed learning the Comware platform, and it is understandable that HP have been strongly focusing on it since the 3Com acquisition. I've only really begun to scratch the surface of their security features, which would be really useful at the access layer. I expect that i'll be recommending these switches to clients a lot more than ProVision-based ones in the future.

IRF supports a ring topology with up to 9 switches on the 5500s, so before long we'll probably aim to upgrade our campus backbone fibre ring to 10 Gbps with 5500 switches at each point on the ring, providing complete switching and routing redundancy.

Comments

Another perspective