{"id":226,"date":"2017-04-28T13:52:53","date_gmt":"2017-04-28T13:52:53","guid":{"rendered":"http:\/\/www.web-workers.ch\/?p=226"},"modified":"2017-04-28T13:52:53","modified_gmt":"2017-04-28T13:52:53","slug":"how-to-setup-dell-powerconnect-5324","status":"publish","type":"post","link":"https:\/\/www.web-workers.ch\/index.php\/2017\/04\/28\/how-to-setup-dell-powerconnect-5324\/","title":{"rendered":"How to setup Dell PowerConnect 5324"},"content":{"rendered":"

Add Switch to Dell support account<\/h1>\n

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\u2019t have a Dell support account, you can skip this step. However, it\u2019s free, and extremely helpful if you have any Dell hardware with Service Tags, so I highly recommend it.<\/p>\n

Getting Connected<\/h1>\n

The obvious first connection to make with a switch is to plug in an\u00a0Ethernet\u00a0cable. So that\u2019s what i did first. But I didn\u2019t just want to blow network traffic through this switch, I wanted to be able to manage it remotely, since that\u2019s the whole idea behind a smart switch!<\/p>\n

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<\/a> (that\u2019s different than a serial cable). My problem was that none of my current desktops or laptops have<\/em> a serial port (and I couldn\u2019t 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).<\/p>\n

Once connected, the system displayed:<\/p>\n

console><\/code><\/p>\n

Firmware Update<\/h1>\n

Whenever I get \u201cvintage\u201d devices that are this old, my first admin task is to see whether any updated firmware exists. Dell\u2019s site showed a much newer version available, so I downloaded the latest one (2.0.1.4<\/a>). 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.<\/p>\n

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

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:<\/p>\n

console> enable
\n<\/code>console# config<\/code>console# interface vlan 1<\/code>console(config-if)# ip address 192.168.1.253 \/24<\/code>console(config-if)# ip default-gateway 192.168.1.254<\/code>console(config-if)# exit<\/code>config(config)# exit<\/code>console#<\/code><\/p>\n

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:<\/p>\n

console# copy running-config startup-config<\/code>
\nwith the output:<\/p>\n

08-May-2011 16:10:47 %COPY-I-FILECPY: Files Copy - source URL running-config destination URL flash:\/\/startup-config<\/code>08-May-2011 16:10:51 %COPY-W-TRAP: The copy operation was completed successfully<\/code>Copy succeeded<\/code>
\nNow I was ready to download the firmware file to the image<\/strong> location on the device with:<\/p>\n

console# copy tftp:\/\/192.168.1.137\/PowerConnect_5324-2014.ros image<\/code>
\nThis took about a minute, during which the console displayed (!!) until the download was complete.<\/p>\n

Next, I downloaded the new boot software to the boot<\/strong> location on the device with:<\/p>\n

console# copy tftp:\/\/192.168.1.137\/PowerConnect_5324_boot-10202.rfb boot<\/code>
\nThis took about 12 seconds, and also filled the screen with exclamation points.<\/p>\n

The 5324 actually has two boot image locations available, so to see which was was currently in use, I did:<\/p>\n

console# show bootvar<\/code>Images currently available on the FLASH<\/code>image-1 active (selected for next boot)<\/code>image-2 not active<\/code>
\nNew 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:<\/p>\n

console# boot system image-2<\/code>
\nand then restarted the device with:<\/p>\n

console# reload<\/code>This command will reset the whole system and disconnect your current<\/code>session. Do you want to continue (y\/n)[n]?<\/code>
\nI typed Y to reboot the device. When the switch booted back up, I typed:<\/p>\n

console> enable<\/code>console# show version<\/code>SW version 2.0.1.4 ( date 01-Aug-2010 time 17:00:12 )<\/code>Boot version 1.0.2.02 ( date 23-Jul-2006 time 16:45:47 )<\/code>HW version 00.00.02<\/code>
\nI was pretty stoked that a device from way back in 2006 had firmware that was last updated in late 2010 \ud83d\ude42<\/p>\n

Enabling SNTP<\/h1>\n

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:<\/p>\n

console# configure<\/code>console(config)# clock timezone -8<\/code>console(config)# clock summer-time recurring first Sun Apr 02:00 last Sun Oct 02:00 zone PDT<\/code>console(config)# sntp client enable vlan 1<\/code>console(config)# clock source sntp<\/code>console(config)# sntp client poll timer 1024<\/code>console(config)# sntp unicast client enable<\/code>console(config)# sntp unicast client poll<\/code>console(config)# sntp anycast client enable<\/code>console(config)# sntp broadcast client enable<\/code>console(config)# sntp server 24.56.178.140 poll<\/code>console(config)# sntp server 131.107.13.100 poll<\/code>console(config)# sntp server 192.43.244.18 poll<\/code>console(config)# exit<\/code>
\nIn order, those commands set the correct timezone, daylight savings time settings, enable the SNTP client for the switch\u2019s VLAN, and then list a few public NTP servers to poll.
\nYou can check to make sure the date and time are being properly set with:<\/p>\n

console# show clock<\/code><\/p>\n

Enabling Remote Management via SSH and HTTPS Access (and maybe SNMP)<\/h1>\n

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:<\/p>\n

console# configure<\/code>console(config)# username admin password dell level 15
\nconsole(config)# snmp-server community private rw
\nconsole(config)# snmp-server community public ro<\/code>
\nOf 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.<\/p>\n

Important<\/strong>: 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\u2019ll show how I disabled these two methods in the next step.<\/p>\n

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\u2019t any help either (most referred to commands that probably worked on the older firmware, but that were apparently replaced on the newer firmware).<\/p>\n

The documentation says that including a certificate number in the \u201ccrypto certificate\u201d command is optional, and that if you don\u2019t include it, it will just use certificate 1 as the default. Unfortunately, the documentation is wrong. Here\u2019s what happens if you type the example from Dell\u2019s documentation:<\/p>\n

console# configure<\/code>console(config)# crypto certificate generate key-generate<\/code>% Unrecognized command<\/code>
\nInstead, I needed to enter the certificate number explicitly:<\/p>\n

console(config)# crypto certificate 1 generate key-generate 2048 duration 1825
\nGenerating RSA private key, 2048 bit long modulus<\/code>
\nThis command worked, and it took just a few minutes to build the key (don\u2019t panic if the console seems unresponsive for a while). Once the console returned, I did:<\/p>\n

console(config)# crypto key generate dsa<\/code>The SSH service is generating a private DSA key.<\/code>This may take a few minutes, depending on the key size.<\/code>...............................<\/code>
\nThis also took a few minutes.\u00a0Then i did:<\/p>\n

console(config)# crypto key generate rsa<\/code>Replace Existing RSA Key [y\/n]? y<\/code>The SSH service is generating a private RSA key.<\/code>This may take a few minutes, depending on the key size.<\/code>
\nAs shown above, I responded \u201cyes\u201d when prompted to overwrite the existing key.
\nOnce the proper keys were generated, I enabled SSH and HTTPS with:<\/p>\n

console# configure<\/code>console(config)# ip ssh server<\/code>console(config)# ip https server<\/code>console(config)# exit<\/code>
\nI 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 \u201crunning\u201d 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:<\/p>\n

console# copy running-config startup-config<\/code><\/p>\n

Disabling Remote Management via Telnet and HTTP (and maybe SNMP)<\/h1>\n

The only way to disable the two default (and less secure) remote access methods is to create what\u2019s called a Management Access-List. I created one called \u201cNo-Telnet\u201d and then used deny and permit directives to tell the 5324 which methods were allowed, like this:<\/p>\n

console# configure<\/code>console(config)# management access-list No-Telnet<\/code>console(config-macl)# deny service telnet<\/code>console(config-macl)# deny service http<\/code>console(config-macl)# deny service snmp<\/code>console(config-macl)# permit service ssh<\/code>console(config-macl)# permit service https<\/code>console(config-macl)# exit<\/code>console(config)# exit<\/code>
\nAfter creating the No-Telnet management access-list, I enabled it with:<\/p>\n

console# configure<\/code>console(config)# management access-class No-Telnet<\/code>console(config)# exit<\/code>
\nTo turn off all management access-lists, you can use:<\/p>\n

console# configure<\/code>console(config)# no management access-class<\/code>console(config)# exit<\/code><\/p>\n

Configuration File<\/h1>\n

The 5324\u2019s 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:<\/p>\n

interface vlan 1
\nip address 192.168.1.222 255.255.255.0
\nexit
\nip default-gateway 192.168.1.1
\nhostname DELL_5324
\nline console
\nexec-timeout 60
\nexit
\nline ssh
\nexec-timeout 60
\nexit
\nmanagement access-list No-Telnet
\ndeny service telnet
\ndeny service http
\ndeny service snmp
\npermit service ssh
\npermit service https
\nexit
\nmanagement access-class No-Telnet
\nusername admin password f69ab5av2d1d16158x29ffd35551e0fx level 15 encrypted
\nip ssh server
\nip https server
\nip https port 1234
\nip https exec-timeout 60
\nclock timezone -8
\nclock summer-time recurring first Sun Apr 02:00 last Sun Oct 02:00 zone PDT
\nsntp client enable vlan 1
\nclock source sntp
\nsntp client poll timer 1024
\nsntp unicast client enable
\nsntp unicast client poll
\nsntp server 24.56.178.140 poll
\nsntp server 131.107.13.100 poll
\nsntp server 192.43.244.18 poll
\nip name-server 8.8.8.8 8.8.4.4<\/p><\/blockquote>\n

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:<\/p>\n

console> enable<\/code>console# copy tftp:\/\/192.168.1.137\/configfile.cfg startup-config<\/code>console# reload<\/code>
\nThe configfile.cfg can be any filename you like.<\/p>\n

More Reading<\/h1>\n

Here are some references and useful links when configuring the Dell PowerConnect 5324 switch:<\/p>\n