The Raritan Blog

How to Rapidly Configure Intelligent Rack PDUs

Posted on May 10, 2012 by Henry Hsu  |  Comments (8)

In the course of my consulting engagements with many enterprise clients, over the past few years I have personally configured thousands and thousands of intelligent power strips for network deployment. Since “site services technician” is not part of my job description, you might wonder if perhaps I just have too much free time.

Quite the contrary. Instead, Raritan created a means to configure intelligent power strips (set IP address, change time settings, set unique name, turn on SNMP, etc.)—in real-world environments—very rapidly and very easily. With minimal effort, a single person can configure hundreds of power strips in a single afternoon. The technique is unique and is likely surprising to most clients, so I’d like to take the time in this post to explain its methodology and rationale.

Many of our clients deploy significant quantities of intelligent power strips, in order to enable better energy management and capacity planning. Thus, Raritan is uniquely motivated to help deploy them quickly, because the value of the data provided by intelligent power strips can only be appreciated when the power strips are network-reachable. It pains me to visit facilities that have purchased networked power strips (of any brand), where the data center operators have not actually deployed their connectivity features due to reluctance to expend the tedious effort required to network them. These facilities are missing the tremendous business and operational value that metered pdus deliver.

THE USUAL WAY : Configure Devices with Laptop

An intelligent power strip is just like any other network appliance. And most network appliances are initially configured one of two ways:

  • Connect Laptop to Device via Serial (Console) Cable + Configure via Command-Line. Basically every Cisco switch on earth is configured this way. And of course, power strips can be configured this way.
  • Connect Laptop to Device via Network Cable + Configure via Web Page. If you’ve ever purchased a home WiFi router, this is how you set it up. And again, power strips can be configured this way, as well.

This methodology works fine for a handful of rack power distribution units. It is very straightforward and easy to do. But for any material number of power strips (even as few as 20), it is quickly becomes mind-numbingly boring (and time-consuming) because the process is “one-to-one”. Furthermore, connecting a laptop to each power strip is not at all viable as the quantity of power strips exceeds more than a few dozen: it is simply too slow (at scale).

THE PERCEIVED “SMART” WAY: DHCP plus Auto-detection / Auto-Configuration

If you tell an Engineer or IT/Network Administrator, “I have 100 network devices [power strips] that I’d like to configure and deploy,” she will likely say the following:

  1. Turn on all the devices;
  2. Use DHCP to assign IP addresses to each device;
  3. Run a script [or use management software] to perform mass configuration;

Indeed, in PRINCIPLE, this is the smart way. It scales. It is automated. In fact, Raritan’s own power strips come configured for DHCP out-of-the-box for this very scenario (our PowerIQ management software automatically detects the DHCP-addressed power strips and can bulk-configure them). Virtually all IT appliances of scale (such as HP iLO cards) assume this basic methodology for mass deployment.

But in PRACTICE, this “automated” process is actually prone to significant execution problems in real data center deployments. This is particularly true for new build-outs (when power strips are most likely to be installed); and is difficult to understand unless you have personally participated in the build-out / commissioning stage of a data center before. Indeed:

When new data centers are commissioned, rack power distribution is required FAR earlier than when the out-of-band network infrastructure is reliable.

Therefore, the “smart way” / “automated” way actually takes far longer to execute in real-life situations because it makes the deployment technician reliant upon the network (and network technician).

Specifically, a DHCP + automation script / management appliance methodology requires all of the following pre-conditions:

  1. DHCP servers must be deployed.
  2. Power strip subnets / VLANs must be deployed, and ROUTED.
  3. Every Ethernet patch cable must be in place, and must work!
  4. Every Ethernet port (on the out-of-band network switch) must be provisioned.

For typical IT mass deployments, the above prerequisites are not a problem at all: the network infrastructure will very typically already be deployed before the IT equipment is needed.

But for power equipment, this is simply not true. At BEST, the network infrastructure will be brand-new (and will therefore have a few routing or configuration problems). But more TYPICALLY, the rack power strips are required so early in the data center build, that one cannot in any way assume that the network is deployed fully—or that even the network engineer is onsite!

Therefore, in practical experience, when ANY of the above four conditions are not met—it requires a minimum of a few hours to fix… if not a few days.

In the same few hours that it takes to call the network engineer, ask that a routing problem be solved (or a network port be provisioned, or a bad patch cable be replaced, or DHCP to be turned on in one of the subnets), and wait for the change order to be implemented—you could have already finished configuring all the power strips! If only there was a way…

THE BEST / FASTEST WAY - Power Strip Configures Itself

Having considered (and experienced) all of the above before, the Raritan power team implemented a mechanism in our intelligent rack power strips whereby large amounts of power strips can be configured for the network—extremely rapidly, and without dependence on the network infrastructure.

In short, this diagram explains it all (click to enlarge):

All Raritan power strips whose part number begins with the prefix “PX2” (not just plain “PX”) will react to a correctly-formatted USB flash drive by:

  • Verifying the USB flash drive carries appropriate administrative privileges;
  • Reconfiguring itself with global settings found on the USB flash drive;
  • Applying individual settings found on the USB flash drive [unique IP address, unique name, etc.] by referencing its own serial number on a user-supplied list;

This entire process takes place in about 20 seconds. It is, as Steve Jobs would say, “like magic”.

In a typical data center configuration, simply purchase as many USB flash drives as you have power strips in a row of cabinets. (Better yet, go to a local trade show and collect one USB flash drive at each vendor booth!) Copy the desired settings onto your USB flash drives, and insert them into every powerstrip in a row. By the time you return to the first cabinet, it will already be done configuring itself—and you can simply remove them all and move on to the next row.

Using such a methodology, I can tell you from firsthand experience that 500 power strips can be completely configured (including unique settings on each power strip) for access over the network in about two hours. I literally did this last week.

It would actually take longer to solve a single network anomaly (as required in the “smart” method)—than to completely finish a data center of 500 power strips utilizing this more straightforward approach. And rest assured, in any new data center deployment, at least one network anomaly will exist. Thus, in the very BEST case (if no network issues require troubleshooting in a newly deployed datacenter, which has never happened before in history), this method is no SLOWER than the “smart” way—for 99.9% of data centers on Earth. In most cases, it will be days and days FASTER.

TECHNICAL DETAILS FOR NERDS

 

 

The previous diagram is meant to be illustrative, not literal. For those interested in the precise method and syntax of this capability, please read on (or call your Raritan support representative).

Because I assume only nerds will read the rest of this post, complete sentences end here.

Files Found on the USB Flash Drive—all are plain text

  • fwupdate.cfg - the first file that the power strip references. It MUST be named fwupdate.cfg (the rest of the names below are suggestions per the example syntax). This tells the power strip what to do.
  • config.txt - list of COMMON settings to place on every power strip.
  • devicelist.csv - comma-separated list of all power strips, by serial number, indicating the UNIQUE settings to place on each power strip.
  • log.txt - file where the power strip will indicate errors (if they occur).

IMPORTANT NOTE: IF YOU ATTEMPT TO USE ANY OF THE BELOW EXAMPLES, DELETE ALL ANNOTATIONS FIRST. THEY ARE NOT PART OF THE SYNTAX

fwupdate.cfg - example syntax with annotations.

// I know the administrative username + password of the power strip

// So you can trust me and do whatever this USB flash drive says to do

user=admin

password=raritan

 

// If anything goes wrong in this process, please indicate in a log file.

logfile=log.txt

// Please look at this list of settings and apply all of them on every power strip.

config=config.txt

// Please look at this list individual power strips by serial number,

// and apply individual/unique settings as indicated in the list.

device_list=devicelist.csv

// In the list of individual power strips, look for your own serial

// number in the 1st column… that is how you know what unique settings to apply

match=serial:1

config.txt - example syntax with annotations.

// Give each power strip a unique name.

// These names can be found on the 2nd column of the separate device list file.

pdu.name=${2}

// Turn on the network port, use static IP addressing, with a /24 mask

network.interface=eth0

network.ip_auto_config_proto=static

network.static.netmask=255.255.255.0

// Set the IP address and Subnet (Gateway) for each power strip differently.

// Unique IP address / gateway list is found on the 3rd and 4th columns of the device list file.

network.static.ipaddr=${3}

network.static.gateway=${4}

// Turn on NTP. This is my GMT time offset [below = California]

time.tz_id=6

time.proto._c_=ntp

time.proto.ntp.server_1=192.168.117.1

time.proto.ntp.server_2=192.168.117.2

// Turn on DNS.

network.static.dns_ip_1=17.254.0.50

network.static.dns_ip_2=17.254.0.59

// Turn on SNMPv2 and change from default community strings to my own unique shared passphrase

snmp.agent_enabled=1

snmp.v12c_enabled=1

snmp.v3_enabled=0

snmp.read_community=mySecurePassphrase1234

snmp.write_community=anotherSecurePassphrase5678

// Don’t force the admin user to change her password at first login

users[0].needPasswordChange=0

// Don’t force users to change their passwords every 30 days

security.pw_aging.enabled=0

Please note that there also exists syntax to change the admin username’s password from the factory default (admin/raritan) to a password of your choosing. Please contact Raritan technical support for details—and any other syntax. Also, keep in mind that once your power strips come online, making any other mass configuration change is extremely simple (particularly with Raritan’s PowerIQ management appliance)

devicelist.csv - example syntax, human-readable

SN,Name,StaticIPAddr,SubnetGateway,

PBE1950682,Rack12-PDU-Aside,192.168.50.120,192.168.50.1,

PBE1950241,Rack12-PDU-Bside,192.168.50.121,192.168.50.1,

PBE1950559,Rack13-PDU-Aside,192.168.50.122,192.168.50.1,

PBE1950385,Rack13-PDU-Bside,192.168.50.123,192.168.50.1,

PBE1950558,Rack14-PDU-Aside,192.168.50.124,192.168.50.1,

PBE1950701,Rack14-PDU-Bside,192.168.51.100,192.168.51.1,

PBE1950168,Rack15-PDU-Aside,192.168.51.101,192.168.51.1,

PBE1950541,Rack15-PDU-Bside,192.168.51.102,192.168.51.1,

PBE1950451,Rack16-PDU-Aside,192.168.51.103,192.168.51.1,

PBE1950117,Rack16-PDU-Bside,192.168.51.104,192.168.51.1,

Obviously, these lists are not generated by hand. Instead, use a barcode scanner to scan in serial numbers by rack, and then use Excel macros to generate the other entries according to your needs.

STANDARD DISCLAIMER / OTHER ADVICE

The above is not meant as technical documentation; please review the PX2 product documentation for further details, and contact your local Raritan support representative for assistance.

For any material deployment of Raritan intelligent power strips, your local support representative will be happy to work with you—and simply provide you with a config.txt and fwupdate.cfg file that you can use. That is to say, we’ll do the hard work for you because it’s not actually hard! Just give us a call.

Thanks for reading this extremely long post; I hope you found it helpful.

All Recent Comments

Matt wrote on 05/29/12:

I really like that you have the USB key method.  The simplicity and lack of dependencies make it almost fool-proof.  I can see this being a method of choice for most deployments.  For various reasons, however, I am trying to use the DHCP/Auto-configuration method.  I found that I could not ssh into the PDU using the default admin/raritan password without first “unblocking” the admin user and changing the password.  Of course, this defeats the purpose of auto-config and leaves me with either a manual or usb key method.  Is there a way around this?

Henry Hsu wrote on 08/02/12:

Hi Matt,

Unfortunately, for security reasons there is no way around this. We force the client to change the PDU from the default admin/raritan password upon the first “human” login (SSH or HTTPS is presumed to be human, although of course in your case it isn’t!).

 

There is a way to turn off this feature [disable force password change], but that requires—you guessed it!—a configuration change.

 

One possible option is to write your script such that (pseudo-code):

 

IF (promptsForPasswordChage) {

 

changePasswordToFoo;

doStuff;

changePasswordBackToDefault;

 

} else {

 

doStuff;

 

}

Kyle Brandt wrote on 01/17/13:

It seems like setting time.tz_id=0 (what I expect for UTC/GMT) breaks the time config using this method. When I used that setting, the web interfaces gives an error that says it can not load the time config. When I try to config via the CLI in this state, I am unable to commit any time changes. In other words, when I type apply after a time configuration and doesn’t exit config mode. When I changed time.tz_id to 1 everything seems okay.

Dan Giannetti wrote on 05/10/13:

Henry,

Is there a full list of all commands that can go into the config.txt file?

Henry Hsu wrote on 05/10/13:

Hi Dan,

Besides the ones I placed in this blog, the commands are only [currently] internally-documented, because we are still in the process of making it version-controlled. That is to say, we cannot yet guarantee that the commands will not change with a firmware upgrade, so we are hesitant to publish it publicly.

But it definitely already works now, and in fact Raritan’s internal services team has been using it since 2009. So the best way to do this is to work with either Raritan customer support, or your preferred Raritan contact. If you’d like, I can have someone call you to discuss what configuration options you’d like, and then we’d provide you with a file that you can modify as best fits your needs.

Dan Giannetti wrote on 05/10/13:

Can you have someone contact me. Theres a few specific things im looking to add to the config if possible such as check use static ntp addresses and ignore dhcp ones figuring out the time id for eastern time zone and possibly adding a user that goes onto all our raritans for poweriq to talk to it.

Henry Hsu wrote on 05/10/13:

P.S. In a future firmware release [likely late this year], instead of asking Raritan for the commands you should be able to download them directly from the PDU. That is to say, you:

(a) configure a PDU exactly how you like it;

(b) download the config.txt file;

(c) modify it in a text editor to remove (or make variable) the obvious things like PDU name and IP address, etc.;

(d) throw it on a USB stick and away you go;

Tony wrote on 06/11/13:

Henry,

thanks for this info as it was useful to configure a group of PDU’s very quickly. I had to do a little troubleshooting as it was not working at first. The log reported that no matching PDU was being discovered in the device list. I reformatted the devicelist.cfg and put each value into it’s own column and then it worked perfectly. Originally I had all of the values in 1 column with commas separating them.


Leave a Comment