Everything You Should Know About Supermicro IPMI

Everything You Should Know About Supermicro IPMI



For all our our Virtual Server nodes (not our Cloud range), Legacy Reseller / Shared nodes, Customer Dedicated Servers and Internal Servers we run Supermicro motherboards. We’ve been using them for years and have solid experience with the varying release  variations and types of boards Supermicro offer.

One of the greatest features that Supermicro added to it’s motherboard range was the remote access / remote kvm feature called IPMI. IPMI is a standard used for providing remote web based access to the server. This access can include power / restart functionality, kvm console functionality and a statistics about the motherboard (temperatures, voltages).

This feature is a great plus for anyone operating equipment in a Data Center as often tasks like re-installing an OS, troubleshooting an OS fault, and a range of other tasks can now be completed without leaving the office.

In this post I will run through why we often love IPMI, but also why sometimes it can be a little frustrating to use.

The core reasons we love IPMI can be summed up in a few points,

  • Less visits to the data center! This saves costs in travel, staff time and means tasks can be completed from the office, home etc.
  • Self-Service becomes achievable. Customers can be given a limited or full access to the IPMI Web Interface, which allows them to access console, perform reboots and so forth themselves. This reduces Support Tickets and gives the Customer flexibility. A win for everyone.
  • IPMI saves lives, during faults. When a server has a problem, for example a file system has corrupted, we can remotely diagnose the issue, and remotely resolve the issue. Not every issue can be fixed remotely, but with IPMI we have a few more tricks up our sleeve before having to send a technician to the Data Center.

However while there are some great positives as listed above we frequently run into a range of issues with the IPMI feature on the Supermicro boards. These include,

  • Security is a common issue reported on various mailing lists and forums among other users of the Supermicro boards. Often Supermicro are quite slow to release patches to address security faults. For some of the older boards sometimes patches were not even made. This can open up the IPMI interface to exploit attempts if it is facing a public accessible location.
  • Configuration of IPMI can prove frustrating as in some cases with situations where we have had to clear the networking config through BIOS, and then re-configure to activate the web interface. Sometimes multiple times on the same motherboard.
  • Networking on the IPMI can be very sensitive, for example in some cases if we unplug the IPMI management port on the motherboard to say move switch ports or even change the cable, often after plugging the cable back in, the IPMI network will not return. We have to shut the server down, and start it back up again. This can sometimes not be achievable on customer facing systems.
  • Patching process sometimes fails to reload the Web Interface. At one point 6 months ago, we patched almost all IPMI interfaces, this can be done either via the WebUI or CMD Line through a tool on the OS on the server. For the first 20 – 30 nodes we used the web interface to install the patch, however during the patching process, often after it had completed, the web interface would not return. A reboot of the node, or often a complete re-configure of network is required to restore the IPMI web interface. We soon found using the IPMI Linux cmdline tool to patch was easier to deal with when issues arose.

Now, please do not let the above issues bother you, we only have the above issues in possibly 1 out of 20 – 30 motherboards. However when you are running a fleet of a 1000 servers for example you can imagine this can prove frustrating.

In my opinion the positives far out weight the negatives, as IPMI has helped us provide a better support to our customers and has improved our teams ability to respond to faults. Which is a big win! Bugs will always be around, it’s how you manage and handle them that makes the difference.

I have a few tips to ensure your Supermicro IPMI configurations are easy to manage and deal with,

  1. When possible have the IPMI Web Interface on a private network (not facing the internet).
  2. Always patch IPMI to the latest firmware release.
  3. Always patch the underlying motherboard BIOS to the latest release.
  4. Always disable the default user account and any guest / anonymous user accounts
  5. Create a custom admin login that is not the default “ADMIN”.
  6. Document and know how to use the varying Supermicro IPMI cmd line utilities, just in case!

I hope that the above has given people some insight into the world of IPMI when using Supermicro motherboards. I would love to hear from anyone who wishes to share their experience with the Supermicro IPMI implementation.



Categories

  • Why the emphasis on putting the web server on a private network. Aren’t the vulnerabilities in the port 623 access? Other than the default password, I haven’t actually seen claims that the web interface on port 443 is vulnerable. However, I don’t see any way to turn off port 623 other than turning off the IPMI. I tried reassigning it to port 0, but the UI caught that.

  • Given the likely hood of further exploits (the ones we don’t know about) we thought it wise to put IPMI on a restricted network. This is only ideal for situations where customers do not need to access it, however if you can reduce the risk, then why not.

  • Pingback: Repost: Everything You Should Know About Supermicro IPMI | #blogging-at-work()