Foundational configuration on legacy Cisco Catalyst 2950/3550: factory reset, initial setup, VLANs, port security, and SPAN.
These next two labs demonstrate foundational switch configurations using legacy Cisco Catalyst models (2950 & 3550). While the hardware is dated, the focus is on building an understanding of core network principles like VLANs, port security, trunking, and STP, which remain critical in modern networking environments.
In this lab environment, I'm using a serial DB-9 to console port cable to connect the Cisco Catalyst switches to a Windows machine, managing them with PuTTY.
Here in the PuTTY interface, I'm opening a management session with the switch via Serial connection COM1:
Performing a factory reset on a Cisco Catalyst 2950 switch to reconfigure it from scratch.
To start, I'm going to carry out the following steps on the Cisco Catalyst 2950 to enter ROMMON mode:
switch:
prompt appear in your console session (PuTTY).This procedure interrupts the normal boot process and forces the switch into the boot loader environment (ROMMON):
Once the switch is in ROMMON mode, I'm going to run the following commands to initiate the factory reset.
flash_init Initializes the flash file system (access/modify files)
del flash:config.text Deletes the startup configuration file
del flash:vlan.dat Deletes the VLAN database file
Enter the boot command to complete the factory reset.
The IOS (Internetwork Operating System) image is loaded from flash. The switch then initializes the flash file system again after loading IOS, preparing to access saved files (e.g., configs, logs, VLAN database).
Here the switch is in the final phase of booting up after issuing boot—completing the Cisco IOS process after a factory reset.
System info is displayed and the system is waiting for the prompt.
From here, the switch will prompt for configurations to set it up from scratch.
After the factory reset, the switch enters the System Configuration Dialog (setup wizard). Below I set the hostname to MT0.
Setting the enable secret password (used for privileged EXEC mode, MT0#
). It’s stored encrypted in the config.
In this example I enter no for SNMP network management (often used in production).
Interface summary output:
Specify a Switched Virtual Interface (SVI)—typically VLAN 1—for management. This gives the switch a Layer 3 address for remote management (Telnet/SSH/SNMP) and testing via ping.
Optional legacy feature allowing one switch to manage others using CDP. Modern environments typically use centralized tools.
Here I enable it and specify a cluster name:
After the wizard, preview the configuration before saving to NVRAM.
I choose option 2 to save to NVRAM (startup-config) and exit to the prompt.
You may see “line protocol on vlan1 is down”—that’s normal if no active ports are in VLAN 1 yet.
After saving and rebooting, press RETURN to reach the prompt (>
), followed by the hostname.
From User EXEC (>
), type enable to enter Privileged EXEC (#
).
At MT0#
, run configure terminal (or conf t) to enter global config.
Change hostname to switch1:
Set a Message of the Day banner (useful for legal/compliance messaging):
Require a password on the console line to prevent unauthorized physical access.
We’ve now secured console/VTY access, assigned a management IP on VLAN 1, and set a default gateway.
Configure Fa0/40–48 as access ports in VLAN 20, add descriptions, and enable spanning-tree portfast.
Exit config mode, then write memory to save the running config.
Create VLAN 10 (Lab-1) and VLAN 20 (Lab-2). VLANs segment the switch into multiple logical networks on shared hardware.
Use interface range to assign ports to VLAN 10/20, add descriptions, and write memory.
Use show vlan brief to confirm VLAN membership.
Configure fa0/30 to allow a single MAC (sticky), shutting down on violation—useful for edge-port hardening.
Verify with:
show port-security interface fa0/30
Note: Secure-down can simply mean nothing is plugged into the port. When a device connects and a MAC is learned, this changes to Secure-up. Unauthorized devices trigger shutdown and increment violations.
Monitoring traffic can support security analysis, troubleshooting, and protocol visibility.
Here I configure a basic SPAN session to mirror traffic from a range of source ports to a destination port.
Note: In this demonstration, SPAN is configured on ports within VLAN 1 for simplicity. It’s independent from the earlier VLAN 10/20 example.
Mirror traffic from Fa0/2–Fa0/8 (sources) to Fa0/9 (destination). Capture with Wireshark on the destination.
Verify that session 1 is monitoring the intended source/destination interfaces:
Two Windows PCs are connected to Fa0/2 (192.168.1.104) and Fa0/5 (192.168.1.124). A third Windows PC on Fa0/9 runs Wireshark to collect mirrored traffic.