Just over 5 months since I bought them, and 2 months since my last blog post it appears, I have finally got around to configuring the APC AP7920 PDUs I reset in April.

Switch port configuration

I started, as would seem logical, by configuring the network ports they were plugged into onto the management VLAN (vlan 10, in the lab) from the default VLAN (vlan 1):

lab-switch(config)#interface range gigabitEthernet 1/0/7-8
lab-switch(config-if)#switchport pvid 10
lab-switch(config-if)#switchport general allowed vlan 10 untagged
lab-switch(config-if)#no switchport general allowed vlan 1
lab-switch(config-if)#exit
lab-switch(config)#interface gigabitEthernet 1/0/7
lab-switch(config-if)#description pdu-1
lab-switch(config-if)#exit
lab-switch(config)#interface gigabitEthernet 1/0/8
lab-switch(config-if)#description pdu-2
lab-switch(config-if)#exit

DHCP server fun and games

I rather naïvely thought that they would just DHCP at this point, however (after some head-scratching, having seen the DHCP traffic offering them an IP address) I discovered that, by default, these APC PDUs will not accept a DHCP response without a “magic APC cookie” in the Vendor Specific Information option (option 43). sigh

Initially I added an if to the management network that matched the vendor-class-identifier (APC in this case) and set the cookie, however I was also already setting a vendor specific option (option 138) to enable my wireless-access-points to find their “Omada” controller so I adopted a more generic solution I found online.

Adding this class to isc-dhcpd’s configuration allows matching different vendors as subclasses later on:

class "vendor-class" {
    match option vendor-class-identifier;
}

For the APC PDUs, the relevant bits of the configuration are:

option apc-vendor-cookie code 43 = string;

#...

subnet 192.168.10.0 netmask 255.255.255.0 {
    #...

    # I placed this inside the management subnet stanza, as a double check they will only accept IPs on that subnet.
    subclass "vendor-class" "APC" {
        option apc-vendor-cookie 01:04:31:41:50:43;
    }
}

Armed with the new class stanza, I applied the same for the TP-Link wireless access points (also on the management subnet):

option capwap code 138 = ip-address;

#...

subnet 192.168.10.0 netmask 255.255.255.0 {
    #...
    subclass "vendor-class" "TP-LINK" { {
        option capwap omada.home.entek.org.uk;
    }
}

In order to figure out the correct class for the TP-Link devices, I used this tcpdump command to dump all DHCP traffic with the MAC addresses of the wireless access points (as I only have 4, it was not a long list) - enp3s0.10 being the interface of this system on the management VLAN:

tcpdump -i enp3s0.10 '(port 67 or 68) and (ether host aa:aa:aa:aa:aa:aa or bb:bb:bb:bb:bb:bb or cc:cc:cc:cc:cc:cc or dd:dd:dd:dd:dd:dd)' -e -n -vv

I did update my SaltStack states and pillar information to make these configuration changes to DHCP but I shall leave that as an exercise to the reader (since it’s very late here, now).

Configure the PDUs

Once they were able to DHCP, I could finally login and configure the PDUs. I used telnet and the default credentials (apc/apc - to be changed later).

The Menu options to set the PDUs names are:

  • 3 - System
  • 2 - Identification
  • 1 - Name
  • (enter name - PDU-1 or PDU-2)
  • 4 - Accept Changes

To power-cycle a node:

  • 1 - Device Manager
  • 2 - Outlet Management
  • 1 - Outlet Control/Configuration
  • (select outlet number)
  • 1 - Control Outlet
  • 3 - Immediate Reboot

To configure an outlet:

  • 1 - Device Manager
  • 2 - Outlet Management
  • 1 - Outlet Control/Configuration
  • (select outlet number)
  • 2 - Configure Outlet
  • 1 - Outlet Name
  • (enter name)
  • 5 - Accept Changes