I got a great deal on a couple of used Dell PowerConnect 5324 switches on eBay, and wanted to write down the steps I took to set them up how I liked them.
Adding it to the List
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.
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 uber geeks have such a graveyard), so I dusted it off, plugged it in, fired up Windows XP (!), connected a null-modem cable (which the eBay seller had included) to a 5324, and fired up HyperTerminal (9600 baud, 8 data bits, no start bits, 1 stopbits).
Once connected, the system displayed:
Whenever I purchase “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 (126.96.36.199). 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# config console# interface vlan 1 console(config-if)# ip address 192.168.1.222 /24 console(config-if)# ip default-gateway 192.168.1.1 console(config-if)# exit config(config)# exit console#
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-config 08-May-2011 16:10:51 %COPY-W-TRAP: The copy operation was completed successfully Copy 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 bootvar Images currently available on the FLASH image-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# reload This command will reset the whole system and disconnect your current session. Do you want to continue (y/n)[n]?
I typed Y to reboot the device. When the switch booted back up, I typed:
console> enable console# show version SW version 188.8.131.52 ( 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. 🙂
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# configure console(config)# clock timezone -8 console(config)# clock summer-time recurring first Sun Apr 02:00 last Sun Oct 02:00 zone PDT console(config)# sntp client enable vlan 1 console(config)# clock source sntp console(config)# sntp client poll timer 1024 console(config)# sntp unicast client enable console(config)# sntp unicast client poll console(config)# sntp anycast client enable console(config)# sntp broadcast client enable console(config)# sntp server 184.108.40.206 poll console(config)# sntp server 220.127.116.11 poll console(config)# sntp server 18.104.22.168 poll console(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
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# configure console(config)# username admin password abc123 level 15
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# configure console(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 dsa The 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 rsa Replace Existing RSA Key [y/n]? y The 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# configure console(config)# ip ssh server console(config)# ip https server console(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
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# configure console(config)# management access-list No-Telnet console(config-macl)# deny service telnet console(config-macl)# deny service http console(config-macl)# deny service snmp console(config-macl)# permit service ssh console(config-macl)# permit service https console(config-macl)# exit console(config)# exit
After creating the No-Telnet management access-list, I enabled it with:
console# configure console(config)# management access-class No-Telnet console(config)# exit
To turn off all management access-lists, you can use:
console# configure console(config)# no management access-class console(config)# exit
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 22.214.171.124 poll sntp server 126.96.36.199 poll sntp server 188.8.131.52 poll ip name-server 184.108.40.206 220.127.116.11
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> enable console# copy tftp://192.168.1.137/configfile.cfg startup-config console# reload
The configfile.cfg can be any filename you like.
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.
Thanks go to Neil Brookins for suggesting that the SNTP setup be performed prior to the SSH/HTTPS access steps, as well as some better options on the “crypto certificate” command.