Add Switch to Dell support account

The first thing I did was add the Dell Service Code for each PowerConnect 5324 into my Dell support account. This allows me to quickly access a wealth of information about them. For example, I learned that one unit was shipped new in May 2006, and the other in November 2006. I was also able to access user guides, support updates, and software. If you don’t have a Dell support account, you can skip this step. However, it’s free, and extremely helpful if you have any Dell hardware with Service Tags, so I highly recommend it.

Getting Connected

The obvious first connection to make with a switch is to plug in an Ethernet cable. So that’s what i did first. But I didn’t just want to blow network traffic through this switch, I wanted to be able to manage it remotely, since that’s the whole idea behind a smart switch!

The Dell PowerConnect 5324 can be managed via a serial null-modem connection, SNMP, telnet, SSH, HTTP, and/or HTTPS. However, for obvious security reasons, the default on a unit that has been reset to factory settings (as these had) can only configured via a terminal connection, which requires a physical connection from a PC to the device via a null-modem cable (that’s different than a serial cable). My problem was that none of my current desktops or laptops have a serial port (and I couldn’t find my USB to serial adapter). However, I remembered an old Dell Inspiron 7000 laptop in my tech graveyard in the basement (all geeks have such a graveyard), so I dusted it off, plugged it in, fired up Windows XP (!), connected a null-modem cable to a 5324, and fired up HyperTerminal or PuTTY (9600 baud, 8 data bits, no start bits, 1 stopbits).

Once connected, the system displayed:

console>

Firmware Update

Whenever I get “vintage” devices that are this old, my first admin task is to see whether any updated firmware exists. Dell’s site showed a much newer version available, so I downloaded the latest one (2.0.1.4). The download also contained an updated version of the boot software (v1.0.2.02) which I would also need to install at the same time.

The quickest way to install the firmware on the PowerConnect 5324 is via TFTP, so I SSH’d from my laptop to an old Dell 2450 running CentOS that I keep running in the basement for situations like this. The tftp-server package was already installed on my CentOS box, so I simply downloaded the new firmware’s zip file into the /tftpboot directory with wget, then unzipped it.

The 5324 was already connected via Ethernet cable to the local network, but I needed to configure some network settings on the device before I could connect to the TFTP server to access the updated firmware files. I entered the following commands via the terminal:

console> enable
console# configconsole# interface vlan 1console(config-if)# ip address 192.168.1.253 /24console(config-if)# ip default-gateway 192.168.1.254console(config-if)# exitconfig(config)# exitconsole#

Those commands set the IP of the switch as 192.168.1.222 and gave it the same default gateway as the other devices on the network. And because I wanted the switch to have the same IP the next time it booted, I copied the current (running) configuration to the startup configuration with this command:

console# copy running-config startup-config
with the output:

08-May-2011 16:10:47 %COPY-I-FILECPY: Files Copy - source URL running-config destination URL flash://startup-config08-May-2011 16:10:51 %COPY-W-TRAP: The copy operation was completed successfullyCopy succeeded
Now I was ready to download the firmware file to the image location on the device with:

console# copy tftp://192.168.1.137/PowerConnect_5324-2014.ros image
This took about a minute, during which the console displayed (!!) until the download was complete.

Next, I downloaded the new boot software to the boot location on the device with:

console# copy tftp://192.168.1.137/PowerConnect_5324_boot-10202.rfb boot
This took about 12 seconds, and also filled the screen with exclamation points.

The 5324 actually has two boot image locations available, so to see which was was currently in use, I did:

console# show bootvarImages currently available on the FLASHimage-1 active (selected for next boot)image-2 not active
New software is always downloaded to the non-active image, so I needed to tell the device to boot that image from now on, so that it can access the newer software. I did this with:

console# boot system image-2
and then restarted the device with:

console# reloadThis command will reset the whole system and disconnect your currentsession. Do you want to continue (y/n)[n]?
I typed Y to reboot the device. When the switch booted back up, I typed:

console> enableconsole# show versionSW version 2.0.1.4 ( date 01-Aug-2010 time 17:00:12 )Boot version 1.0.2.02 ( date 23-Jul-2006 time 16:45:47 )HW version 00.00.02
I was pretty stoked that a device from way back in 2006 had firmware that was last updated in late 2010 🙂

Enabling SNTP

Before doing anything else, enable SNTP on the device so it will sync with remote time servers, and have an accurate date before generating any certificates (used later). I typed the following:

console# configureconsole(config)# clock timezone -8console(config)# clock summer-time recurring first Sun Apr 02:00 last Sun Oct 02:00 zone PDTconsole(config)# sntp client enable vlan 1console(config)# clock source sntpconsole(config)# sntp client poll timer 1024console(config)# sntp unicast client enableconsole(config)# sntp unicast client pollconsole(config)# sntp anycast client enableconsole(config)# sntp broadcast client enableconsole(config)# sntp server 24.56.178.140 pollconsole(config)# sntp server 131.107.13.100 pollconsole(config)# sntp server 192.43.244.18 pollconsole(config)# exit
In order, those commands set the correct timezone, daylight savings time settings, enable the SNTP client for the switch’s VLAN, and then list a few public NTP servers to poll.
You can check to make sure the date and time are being properly set with:

console# show clock

Enabling Remote Management via SSH and HTTPS Access (and maybe SNMP)

Because my plan is to eventually have this switch in a production environment, I wanted to enable the most secure remote management methods available on the device, then deactivate any non-secure methods. The first step to enabling any sort of remove access is to create a username and password for an administrative user. I did this with:

console# configureconsole(config)# username admin password dell level 15
console(config)# snmp-server community private rw
console(config)# snmp-server community public ro
Of course, you can choose any username and password combo you like, but the level 15 is important, because only level 15 users have full admin capabilities.

Important: Creating a level 15 user automatically enables the two less secure remote management options on the unit: telnet and http. After enabling their more secure counterparts, I’ll show how I disabled these two methods in the next step.

But first, I needed to build some keys. This took a fair amount of trial and error to figure out, since the available documentation is actually incorrect on how to do this, and the search engines weren’t any help either (most referred to commands that probably worked on the older firmware, but that were apparently replaced on the newer firmware).

The documentation says that including a certificate number in the “crypto certificate” command is optional, and that if you don’t include it, it will just use certificate 1 as the default. Unfortunately, the documentation is wrong. Here’s what happens if you type the example from Dell’s documentation:

console# configureconsole(config)# crypto certificate generate key-generate% Unrecognized command
Instead, I needed to enter the certificate number explicitly:

console(config)# crypto certificate 1 generate key-generate 2048 duration 1825
Generating RSA private key, 2048 bit long modulus
This command worked, and it took just a few minutes to build the key (don’t panic if the console seems unresponsive for a while). Once the console returned, I did:

console(config)# crypto key generate dsaThe SSH service is generating a private DSA key.This may take a few minutes, depending on the key size................................
This also took a few minutes. Then i did:

console(config)# crypto key generate rsaReplace Existing RSA Key [y/n]? yThe SSH service is generating a private RSA key.This may take a few minutes, depending on the key size.
As shown above, I responded “yes” when prompted to overwrite the existing key.
Once the proper keys were generated, I enabled SSH and HTTPS with:

console# configureconsole(config)# ip ssh serverconsole(config)# ip https serverconsole(config)# exit
I was then able to connect to the 5324 using SSH and https://ipaddress/. As with all configuration changes, these ones enabled the SSH server and HTTPS server for the “running” configuration only, but because I wanted this change to persist on a reboot, I needed to copy the running configuration to the startup configuration with:

console# copy running-config startup-config

Disabling Remote Management via Telnet and HTTP (and maybe SNMP)

The only way to disable the two default (and less secure) remote access methods is to create what’s called a Management Access-List. I created one called “No-Telnet” and then used deny and permit directives to tell the 5324 which methods were allowed, like this:

console# configureconsole(config)# management access-list No-Telnetconsole(config-macl)# deny service telnetconsole(config-macl)# deny service httpconsole(config-macl)# deny service snmpconsole(config-macl)# permit service sshconsole(config-macl)# permit service httpsconsole(config-macl)# exitconsole(config)# exit
After creating the No-Telnet management access-list, I enabled it with:

console# configureconsole(config)# management access-class No-Telnetconsole(config)# exit
To turn off all management access-lists, you can use:

console# configureconsole(config)# no management access-classconsole(config)# exit

Configuration File

The 5324’s CLI and the web interface both allow upload and download of configuration files. When setting up multiple switches with similar setups, you can upload a text file through your web browser or use the web interface to pull a config file from a TFTP server. The config file is simply a text file with one command per line. Mine looks like this:

interface vlan 1
ip address 192.168.1.222 255.255.255.0
exit
ip default-gateway 192.168.1.1
hostname DELL_5324
line console
exec-timeout 60
exit
line ssh
exec-timeout 60
exit
management access-list No-Telnet
deny service telnet
deny service http
deny service snmp
permit service ssh
permit service https
exit
management access-class No-Telnet
username admin password f69ab5av2d1d16158x29ffd35551e0fx level 15 encrypted
ip ssh server
ip https server
ip https port 1234
ip https exec-timeout 60
clock timezone -8
clock summer-time recurring first Sun Apr 02:00 last Sun Oct 02:00 zone PDT
sntp client enable vlan 1
clock source sntp
sntp client poll timer 1024
sntp unicast client enable
sntp unicast client poll
sntp server 24.56.178.140 poll
sntp server 131.107.13.100 poll
sntp server 192.43.244.18 poll
ip name-server 8.8.8.8 8.8.4.4

I like to use a text editor to create a configuration file directly the TFTP server, then use the following commands to upload the config file as the startup configuration, and then restart the switch to run the new configuration:

console> enableconsole# copy tftp://192.168.1.137/configfile.cfg startup-configconsole# reload
The configfile.cfg can be any filename you like.

More Reading

Here are some references and useful links when configuring the Dell PowerConnect 5324 switch:

• Dell PowerConnect 5324 Manuals – HTML and PDF versions of the user guide, addendum, CLI guide, and release notes.
• Management ACL Section of CLI Guide – useful for managing access-lists.
• Inter-VLAN Rounting with Linux and PowerConnect 5324 – Great blog post on routing multiple VLANs through a single Linux router using a 5324.