I recently received an email from a reader stating that they really liked the IPMI and remote KVM features of the Supermicro boards that I use for my ESXi hosts, but was running out of ports on the network switch used for home lab networking. After discussing the use case of shared ports, I figured it would be worth documenting the process here.

A shared port is one used for multiple purposes – in this scenario, it means selecting an on-board NIC to act as the IPMI endpoint in addition to being an uplink for ESXi. It is opposite of the dedicated port setting, which uses a dedicated IPMI port on the motherboard and can, in a home lab scenario, be overkill and consume more network ports than may be desired.

To begin, I’ll assume that you’ve already consoled into the server and have configured the IPMI interface with an IP address. As a reminder, the default Supermicro username and password is the word ADMIN in all caps. Once you’re signed in, the menu options will be slightly different based on the motherboard’s IPMI version, but you’ll want to head to the Network Settings section. For me, that’s under the Configuration > Network Settings path.

VLAN Tagging

From here, you can define the IPv4 and IPv6 network addresses, along with the VLAN and interface mode. Because we’re going to share the port with ESXi data traffic, it’s a safe assumption that the port will be tagged with VLAN traffic. You have a few options at this point, with the primary list being:

Tag the IPMI VLAN on your switchport and input the VLAN ID into the Supermicro network settings page
Make the IPMI VLAN a native VLAN on the switchport, and disable VLAN tagging for IPMI on your Supermicro
Share the IPMI VLAN with something else that the ESXi host is using, such as management, if you’re using a switch that can only provide a small number of VLAN IDs

I use a separate VLAN ID for IPMI and tag the VLAN on my switchport. This follows a more typical data center configuration, but in a home lab scenario, you can cut corners if your budget doesn’t allow this. I know that a few switches out there are limited to some artificially small number of VLAN IDs, so you may be forced to share the VLAN ID with something else. Just make sure that the option you choose is also ready to be configured on the switchport, and don’t push any changes to your switch until you’ve made the changes on the Supermicro first. Otherwise you’ll lose network access to IPMI. 🙂

Interface Mode

The final piece of the puzzle is the interface mode: dedicate, shared, and failover.

Dedicate – the IPMI port is used exclusively for out of band access
Share – the on-board NIC’s first port is used exclusively for out of band access
Failover – try to use the IPMI port, and if it is not connected, fail over to the on-board NIC port

Both the Share and Failover options are design candidates for folks wanting to share the on-board NIC port with IPMI access. In many cases, the Failover option is default, but a new Supermicro owner will plug in a cable into the IPMI port thinking that it’s a requirement. If you’re already configured for Failover, you can continue using this option and just unplug the cable sitting in the IPMI port. The server will detect that the IPMI port is disconnected, as shown above, and float over to the on-board NIC port.

Once this last change is made, save the configuration changes to the Supermicro and update your network switch configuration appropriately. If you’re changing the VLAN ID or tagging method, you’ll lose access to the IPMI interface until you also update the network switch configuration to allow traffic to flow.

DNS A Record

The final little nugget of wisdom that I’ll pass along is to use a DNS A record for your IPMI address. It makes those quick I need to get into my server! moments a snap. I was taught to use a -r suffix to the original hostname in DNS. Thus, esx0.glacier.local for the ESXi management interface would be esx0-r.glacier.local for the IPMI interface.