hpe

Meltdown & Spectre: What about HPE Storage and Citrix NetScaler?

In addition to my shortcut blog post about Meltdown and Spectre with regard of Microsoft Windows, VMware ESXi and vCenter, and HPE ProLiant, I would like to add some additional information about HPE Storage and Citrix NetScaler. When we talk about Meltdown and Spectre, we are talking about three different vulnerabilities: CVE-2017-5715 (branch target injection) CVE-2017-5753 (bounds check bypass) CVE-2017-5754 (rogue data cache load) CVE-2017-5715 and CVE-2017-5753 are known as “Spectre”, CVE-2017-5754 is known as “Meltdown”.

The Meltdown/ Spectre shortcut blogpost for Windows, VMware and HPE

Change History 01-13-2018: Added information regarding VMSA-2018-0004 01-13-2018: HPE has pulled Gen8 and Gen9 system ROMs 01-13-2018: VMware has updated KB52345 due to issues with Intel microcode updates 01-18-2018: Updated VMware section 01-24-2018: Updated HPE section 01-28-2018: Updated Windows Client and Server section 02-08-2018: Updated VMware and HPE section 02-20-2018: Updated HPE section 04-17-2018: Updated HPE section Many blog posts have been written about the two biggest security vulnerabilities discovered so far.

Notes about 802.1x and MAC authentication

Open network ports in offices, waiting rooms and entrance halls make me curious. Sometimes I want to plugin a network cable, just to see if I get an IP address. I know many companies that does not care about network access control. Anybody can plugin any device to the network. When talking with customers about network access control, or port security, I often hear their complains about complexity. It’s too complex to implement, to hard to administrate.

Wrong iovDisableIR setting on ProLiant Gen8 might cause a PSOD

TL;DR: There’s a script at the bottom of the page that fixes the issue. Some days ago, this HPE customer advisory caught my attention: Advisory: (Revision) VMware - HPE ProLiant Gen8 Servers running VMware ESXi 5.5 Patch 10, VMware ESXi 6.0 Patch 4, Or VMware ESXi 6.5 May Experience Purple Screen Of Death (PSOD): LINT1 Motherboard Interrupt And there is also a corrosponding VMware KB article: ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers

Checking the 3PAR Quorum Witness appliance

Two 3PAR StoreServs running in a Peer Persistence setup lost the connection to the Quorum Witness appliance. The appliance is an important part of a 3PAR Peer Persistence setup, because it acts as a tie-breaker in a split-brain scenario. While analyzing this issue, I saw this message in the 3PAR Management Console: Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0 In addition to that, the customer got e-mails that the 3PAR StoreServ arrays lost the connection to the Quorum Witness appliance.

HPE ProLiant PowerShell SDK

Some days ago, my colleague Claudia and I started to work on a new project: A greenfield deployment consisting of some well known building blocks: HPE ProLiant, HPE MSA, HPE Networking (now Aruba) and VMware vSphere. Nothing new for us, because we did this a couple times together. But this led us to the idea, to automate some tasks. Especially the configuration of the HPE ProLiants: Changing BIOS settings and configuring the iLO.

Enable IPv6 SLAAC on HPE OfficeConnect 1920 switches

The HPE OfficeConnect 1920 switch series is designed for SMBs. The switch is perfect for small environments, that require features like VLANs, routing or 802.1x. This switch is smart-managed, so it has “only” a web interface and only a limited CLI. I have two switches in my lab: A 1910-8G and the successor, a 1920-24G. Although the device supports IPv6, it doesn’t support SLAAC (Stateless Address Autoconfiguration) by default. The switch does not send router advertisements (RA).

HPE Data Protector 9.08 is available

3 days ago, on 13th October 2016, HPE has released patch bundle 9,08 for Data Protector 9. A patch bundle isn’t a directly installable version, instead it’s a bundle of patches and enhancements for a specific version of Data Protector, in this case Data Protector 9. Beside fixes for discovered problems, a patch bundle includes also enhancements. There are some enhancements in this patch bundle, that have caught my attention particularly.

I'm routing on the edge...

In my last post (Routed Port vs. Switch Virtual Interface (SVI)), I have mentioned a consequence of using routed ports to interconnect access and core switches: You have to route the traffic on the access switches. Routing on the network access, the edge of the network, is not a question of performance. It is more of a management issue. Depending on the size of your network, and the number of subnets, you have to deal with lots of routes.

Routed Port vs. Switch Virtual Interface (SVI)

Many years ago, networks consisted of repeaters, bridges and router. Switches are the successors of the bridges. A switch is nothing else than a multiport bridge, and a traditional switch doesn’t know how to pass traffic to a different broadcast domains (VLANs). Passing traffic between different broadcast domains, is a job for a router. A router has an IP interface in each broadcast domain, and the IP interface is used by the clients in the broadcast domain as a gateway.