5400R

Not meant as a complete in depth guide but certainly enough to point you in the right direction here’s my list of the most commonly seen (from my point of view) HPE Aruba (e.g. the 2540, 2930F, 5400R series) fibre optics and their respective part numbers:

The format is effectively <Speed> <Fibre Type> <Maximum Range> – <Part Code>

1Gbit Multi Mode 500m – J4858D

1Gbit Single Mode 10km – J4859D

10Gbit Multi Mode 300m – J9150D

10Gbit Single Mode 10km – J9151E

Data from: https://support.hpe.com/hpesc/public/docDisplay?docId=a00028947en_us

If you have ever seen this post Server Room – The latest you will notice we have a pretty awesome HPE Aruba 5400R zl2 Core Switch; however (at least until now), I’ve been yet to find a really simple guide which shows the best way to reboot the management modules following a firmware update.

So after much research and a live firmware update this morning (last time round I just reloaded both management modules at the same time) I’m going to go with the following plan.

  1. Update the firmware (wait a few minutes for the firmware to copy from the primary to the secondary module – this is automatic)
  2. Reboot the standby module using the boot standby command (and wait a few minutes)
  3. Confirm that the standby module is now running the new firmware with  show redundancy
  4. Failover from the active to the standby module – this caused a few seconds of downtime in my environment
  5. Once the failover is complete the previously active module will now also be running the new firmware

For easy copy and paste see the commands on GitHub below along with the screenshot sequence which shows you how this will look on a switch running the 16.x branch firmware.

If you are running an HPE Aruba (formally ProCurve) switch you may come across cases where your switch (in the example above a 5400R zl2) has multiple IP Addresses/VLANs and you need it to talk to another service (in my case syslog and sFlow receivers) on a set interface.

When this occurs you can use the ip source-interface command (make sure you are in config mode first) to define the IP Address or VLAN that you want the switch to talk out on. In my case VLAN2 which is used as the management network for the network switches (VLAN1 being the default network that switches use if multiple addresses are configured).

Having recently setup OpenVAS (something I will likely blog about in further detail soon) I have found out that the default out of box deployment of Aruba-OS (formally ProCurve) supports a number of insecure SSH Algorithms with messages similar to the ones below logged even when running the latest firmware releases (YA.16.03.0004 on the 2530 series).

SSH Weak Encryption Algorithms Supported
The remote SSH server is configured to allow weak encryption algorithms.

and

SSH Weak MAC Algorithms Supported
The remote SSH server is configured to allow weak MD5 and/or 96-bit MAC algorithms.

To secure the switch simply run the following commands while logged into the switch

config
no ip ssh cipher aes128-cbc
no ip ssh cipher 3des-cbc
no ip ssh cipher aes192-cbc
no ip ssh cipher aes256-cbc
no ip ssh cipher rijndael-cbc@lysator.liu.se
no ip ssh cipher aes128-ctr
no ip ssh cipher aes192-ctr
no ip ssh mac hmac-md5
no ip ssh mac hmac-sha1-96
no ip ssh mac hmac-md5-96
write memory