Dell PowerConnect 5324 Setup Tasks 38

This entry was posted in Reference Technology and tagged 5324 CLI Dell HTTPS managed PowerConnect PowerConnect 5324 remote management SNTP ssh switch on by (updated 3337 days ago)

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.

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 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:

console>

We’re in!

Firmware Update

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 (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# 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    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# 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 24.56.178.140 poll
console(config)# sntp server 131.107.13.100 poll
console(config)# sntp server 192.43.244.18 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

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> enable
console# copy tftp://192.168.1.137/configfile.cfg startup-config
console# 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:

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.

More from this site: