Cisco 3560/3550 EOL Console Recovery Procedure

If the boot command is successful, you will eventually see either the default Switch> prompt or a configured hostname prompt, indicating a successful recovery:

Press RETURN to get started!
Switch>
 !--- The bootup was successful.

After a successful boot, ensure you verify that the correct boot statement is configured on the switch (we'll cover this in the "Verification" section).

If the boot command fails or you're stuck in a continuous reboot, your only remaining option for recovery on these legacy switches is an Xmodem file transfer, which we'll cover in Step 4.

4. Perform Xmodem File Transfer (Last Resort): If booting from an existing image failed or no valid image was found, your final option for these legacy switches is an Xmodem file transfer. Be aware that this is an extremely slow process, which can take an hour or more even with optimized settings, due to the serial connection bandwidth.

• Acquire the IOS Image: Download the appropriate Cisco IOS .bin file for your specific switch model from the Cisco Software Center (for registered customers).

Important Note on Image Types: Avoid using deprecated CMS (Cluster Management Suite) .tar files for Xmodem recovery. These are typically much larger and primarily designed for web interface features, which are less relevant for basic recovery and will significantly prolong the transfer time. Stick to the smaller .bin image files for efficient recovery.

Before transferring, I recommend verifying you have sufficient free space in Flash memory for the new image. Use dir flash: to check:

switch: dir flash:
Directory of flash:/
!--- Output suppressed.
3132928 bytes available (4608512 bytes used)
!--- This example shows approximately 3 MB of Flash space available for a new image.

If needed, delete any corrupt or old images to free up space. For instance:

switch: delete flash:c2950-i6q4l2-mz.121-12c.EA1.bin
 !--- Use the delete flash:<filename> command to remove a Cisco IOS image.
Are you sure you want to delete “flash:c2950-i6q4l2-mz.121-12c.EA1.bin” (y/n)? y
 !--- Enter y for yes to confirm the deletion.
File “flash:c2950-i6q4l2-mz.121-12c.EA1.bin” deleted
switch:

Now, let's initiate the Xmodem transfer. This example uses HyperTerminal, but the process is identical for modern terminal emulators like PuTTY or TeraTerm.

• On the switch's console, issue the copy xmodem: flash:filename command, replacing filename with the name of your IOS .bin file:

switch: copy xmodem: flash:c2955-i6q4l2-mz.121-13.EA1.bin
Begin the Xmodem or Xmodem-1K transfer now... CCC

• Next, from your terminal emulation program (e.g., PuTTY's serial window or TeraTerm), navigate to Transfer > Send File (or similar menu option).
• In the Send File dialog, select the Xmodem (or Xmodem-1K) protocol. Browse to select the Cisco IOS .bin file you downloaded earlier.
• Click Send to begin the Xmodem transfer.

The transfer will show 'C' characters on the console as it progresses. This process can be lengthy. If it fails, you'll need to restart the entire Xmodem transfer from the copy xmodem: command on the switch.

CCCCCCC……………………………………………………………….
… (extensive C's indicating transfer progress) …
File “xmodem:” successfully copied to “flash:c2955-i6q4l2-mz.121-13.EA1.bin”
switch:
 !--- Upon successful completion, you will return to the switch: prompt.

• Once the transfer is successful, boot the newly copied image:

switch: boot flash:c2955-i6q4l2-mz.121-13.EA1.bin
Loading “flash:c2955-i6q4l2-mz.121-13.EA1/c2955-i6q4l2-mz.121-13.EA1.bin”…###############################
################################################################################
 !--- Output suppressed during the boot process.
Press RETURN to get started!
Switch>
 !--- The bootup was successful.

After booting, remember to verify your boot statements for persistence.

Optimizing Xmodem Transfer Speed

Xmodem transfers, by default, often occur at the slower 9600 baud rate. To significantly reduce the transfer time (from potentially two hours to around one hour or less, depending on image size), you can increase the baud rate. This is especially crucial for larger IOS images.

Here's how to speed up the Xmodem recovery process:

1. Set Switch Baud Rate: At the switch: prompt, configure the baud rate to 115200:

switch: set BAUD 115200
 !--- Your console screen will likely go blank or display garbled characters after this command.

2. Adjust Terminal Emulator Settings: Immediately restart your terminal emulation program (PuTTY, TeraTerm) or open its COM port properties. Change the "Bits per second" or "Baud rate" setting to 115200 to match the switch. Once adjusted, the switch: prompt should reappear correctly.
3. Proceed with Xmodem: Now, you can start the Xmodem recovery process as described in Step 4.
4. Reset Baud Rate: After the Xmodem transfer and successful boot, it's good practice to revert the console baud rate to the default 9600 bps. This ensures future console connections work reliably with standard settings. If set BAUD 9600 doesn't work, you can use the unset BAUD command to return to default:

switch: set BAUD 9600
 !--- If the screen becomes garbled again, adjust your terminal emulator to 9600 bps.
switch: unset BAUD
 !--- This command typically restores the baud rate to its default of 9600 bps.

Verification and Boot Configuration

After successfully booting the switch, it's crucial to verify the running software version and ensure the boot sequence is correctly configured for future restarts.

1. Verify IOS Version: Use the show version command to confirm the currently running Cisco IOS software version.

2955#show version
Cisco Internetwork Operating System Software IOS ™
C2955 Software (C2955-I6Q4L2-M),
Version 12.1(13)EA1, RELEASE SOFTWARE
 !--- This output confirms the current software version.
 !--- Further output is suppressed for brevity.

2. Inspect Flash Contents: Confirm the presence and location of the Cisco IOS image (.bin file) on your switch.

2950#dir flash:
Directory of flash:/
3 -rwx 5 Mar 01 1993 00:12:55 private-config.text
4 -rwx 2905856 Jan 01 1970 03:06:25 c2955-i6q4l2-mz.121-13.EA1.bin
 !--- The Cisco IOS .bin file is directly stored in flash: on Catalyst 2940, 2950, or 2955.
 !--- Output suppressed.

For Catalyst 2970, 3550, 3560, or 3750 switches that might have used a CMS image in the past, the IOS image could be in a dedicated directory:

3550#dir flash:
Directory of flash:/
2  -rwx         976   Mar 01 1993 21:47:00  vlan.dat
4  -rwx           5   Mar 06 1993 23:32:04  private-config.text
6  -rwx        1554   Mar 06 1993 23:32:04  config.text
7  drwx         192   Mar 01 1993 00:14:02  c3550-i5q3l2-mz.121-13.EA1
 !--- The 'd' indicates a directory, which was common for CMS-based images.
 !--- The actual .bin file resides inside this directory.
5  -rwx     3823261   Mar 01 1993 00:46:01  c3550-i5q3l2-mz.121-12c.EA1.bin
 !--- This is another Cisco IOS .bin file directly in Flash.
8  -rwx          33   Mar 01 1993 00:14:06  env_vars
9  -rwx         384   Mar 01 1993 00:14:06  system_env_vars
15998976 bytes total (6168576 bytes free)
 !--- This output is from a Catalyst 3550 switch. Output from Catalyst 2970, 3560, or 3750 may vary slightly.

To view the IOS .bin file within such a directory, use dir flash:directory_name:

3550#dir flash:c3550-i5q3l2-mz.121-13.EA1
Directory of flash:/c3550-i5q3l2-mz.121-13.EA1/
23  drwx         832   Mar 01 1993 00:12:00  html
40  -rwx     3993612   Mar 01 1993 00:14:02  c3550-i5q3l2-mz.121-13.EA1.bin
41  -rwx         252   Mar 01 1993 00:14:02  info
15998976 bytes total (6168576 bytes free)
 !--- This output confirms the .bin file inside the directory.
 !--- Output from Catalyst 2970, 3560, or 3750 may vary slightly.
3550#

3. Verify Boot Statement: Crucially, confirm that the switch is configured to boot from the correct IOS image upon restart. Use the show boot command:

Switch#show boot
BOOT path-list:
 !--- No boot system statement is set in this example.
 !--- Output suppressed.

Note: On these fixed-configuration Catalyst switches, boot statements are not visible in the running configuration (show run). You must use show boot.

If the boot statement is missing or points to an incorrect or outdated image, configure it using the boot system flash:filename command:

2955#configure terminal
2955(config)#boot system flash:c2955-i6q4l2-mz.121-13.EA1.bin
 !--- This sets the boot system statement on a Catalyst 2940, 2950, or 2955.
2955(config)#end
2955#
2955#show boot
BOOT path-list:       flash:c2955-i6q4l2-mz.121-13.EA1.bin
 !--- Output suppressed.

For switches with images stored in directories (like those that might have used CMS), use the boot system flash:directory/filename command:

3550#configure terminal
3550(config)#boot system flash:c3550-i5q3l2-mz.121-13.EA1/c3550i5q3l2-mz.121-13.EA1.bin
 !--- This command configures the boot system statement on a Catalyst 3550 for an image within a directory.
3550(config)#end
3550#
3550#show boot
BOOT path-list: flash:c3550-i5q3l2-mz.121-13.EA1/c3550-i5q3l2-mz.121-13.EA1.bin
 !--- Output suppressed.

Modern Approaches to Network Recovery and Automation

While the manual console recovery outlined above is essential for legacy devices or as a last resort, modern network engineering prioritizes automation, programmatic interfaces, and robust CI/CD pipelines for device provisioning, configuration management, and even disaster recovery. Manual Xmodem transfers are exceptionally slow and error-prone compared to contemporary methods.

For current Cisco (e.g., IOS XE platforms), Juniper, Arista, and other vendor devices, here’s how recovery and management typically work today:

• API-Driven Management: Modern devices expose powerful APIs (NETCONF, RESTCONF, gNMI) for configuration and operational state retrieval. Instead of serial console, recovery can often be initiated remotely via these APIs, potentially through an out-of-band management network.
• Network Automation Tools: Tools like Ansible, Python (with libraries such as Netmiko, NAPALM, Scrapli), and Nornir are used to automate firmware upgrades, configuration rollbacks, and even full device re-provisioning. In a recovery scenario, an Ansible playbook could push a validated configuration and the correct firmware image to a large fleet of switches quickly and consistently.

Example: Ansible playbook snippet for a firmware upgrade on an IOS XE device (concept only):

# Placeholder: Example Ansible Playbook for IOS XE firmware upgrade
---
- name: Upgrade Cisco IOS XE firmware
  hosts: ios_xe_devices
  gather_facts: false
  connection: network_cli
  vars:
    new_ios_image: "flash:cat9k_iosxe.17.09.04.SPA.bin"
  tasks:
    - name: Copy new IOS image to flash
      cisco.ios.ios_command:
        commands:
          - command: "copy tftp: flash:{{ new_ios_image }}"
            prompt: "Destination filename"
            answer: "{{ new_ios_image }}"
      tags: copy_firmware
      # In a real scenario, you'd integrate TFTP server details and error handling.

    - name: Set boot variable to new image
      cisco.ios.ios_config:
        lines:
          - "no boot system"
          - "boot system flash:{{ new_ios_image }}"
        save_when: always
      tags: set_boot_variable

    - name: Reload the device
      cisco.ios.ios_command:
        commands: "reload"
        prompt: "Proceed with reload"
        answer: "yes"
      tags: reload_device
      # Proper checks and waits would be needed in production.

• Infrastructure-as-Code (IaC) and GitOps: Network configurations and desired states are stored in version control systems (like Git). In a recovery event, the validated configuration from Git can be pushed to a replacement or recovered device, ensuring consistency and auditability. Tools like Terraform can also provision and configure network devices as part of a larger infrastructure deployment.
• Dedicated Management Platforms: Cisco DNA Center, Juniper Apstra, and Arista CloudVision provide centralized, intent-based management platforms that can orchestrate device onboarding, configuration, and recovery workflows, significantly reducing manual intervention.

For modern environments, manual console recovery is often considered a last resort, typically reserved for scenarios where network connectivity or automated out-of-band management has completely failed.

The Shift to Intent-Based Networking (IBN) and Observability

Beyond automating individual tasks, the evolution of network management has moved towards Intent-Based Networking (IBN). IBN systems (like Cisco ACI or DNA Center) allow engineers to define the desired network state and policies at a high level. The system then translates this intent into device-specific configurations and continuously verifies that the network adheres to the intent.

In an IBN paradigm, recovery procedures are often automated and integrated into the platform itself. If a device fails or deviates from its intended state, the IBN controller can automatically re-provision it or alert operations teams for immediate, guided intervention, far more efficiently than manual console work.

Coupled with IBN is advanced network observability. Modern networks leverage streaming telemetry (e.g., gRPC Network Management Interface - gNMI), sFlow, IPFIX, and sophisticated analytics platforms to monitor every aspect of network health. AI/ML-powered assurance tools can proactively detect anomalies, predict potential failures, and even suggest remediation steps before an outage occurs, making severe manual recovery scenarios far less common.

Understanding the manual recovery for legacy devices provides critical foundational knowledge, but embracing these modern automation, IaC, IBN, and observability principles is essential for building and maintaining resilient, high-performing networks today.

• About
• Latest Posts

Afroz Ahmad

I'm Afroz, a Network Engineer and CCIE with more than18 years of experience in Computer Networking, Data Centers, Telecom, Internet Services and ISPs. Currently, I work as a Network Designer for a leading ISP equipment vendor. I share my expertise through my blog and courses, aiming to share my knowledge and simplify complex networking concepts for both beginners and experienced professionals.

Latest posts by Afroz Ahmad (see all)

• Best WiFi 7 Routers of 2025- Benchmarked by a Network Engineer - November 30, 2025
• Justifying a $50k or even Higher Annual Switch Upgrade: What Must-Have Features Are We Missing? - November 13, 2025
• Managing Overlapping Private IPs in Multi-Client Site-to-Site VPNs: Best Practices? - November 7, 2025