Manually updating network devices with USB sticks introduces massive risk, inconsistency, and is unscalable. Adopting centralized and automated solutions like TFTP, SCP, or configuration management tools like Ansible is crucial for modern network operations.

That Time with the Five USB Sticks: Why ‘Sneakernet’ Is Killing Your Network Ops

It’s 2 AM. The change window is shrinking, and I’m standing in the freezing cold aisle of a data center, juggling a crash cart and a USB stick. The stick has the new Cisco IOS image that’s supposed to fix a critical P1 vulnerability. I plug it in, run the command, and… read error. The file is corrupt. My only other copy is on my laptop in the car, a ten-minute walk away. I saw a Reddit thread the other day about a junior admin planning to update multiple switches using five separate USB sticks, and that memory hit me like a blast from the CRAC unit. I get the impulse. It feels direct, simple, and controllable. But I’m here to tell you, as someone who has lived the consequences, it’s a trap.

The Real Problem Isn’t the USB Stick

Let’s be clear: the problem isn’t the physical piece of plastic and silicon. The problem is the process it represents. We call it “Sneakernet”—physically walking around to update machines one by one. This approach is the antithesis of everything we stand for in DevOps and modern Ops.

• It Doesn’t Scale: Five switches might be manageable. What about fifty? Or five hundred across three different data centers? The manual effort, time, and cost grow linearly with your infrastructure.
• It’s Prone to “Config Drift”: Did you load the exact same image on all five sticks? Are you sure? Did you remember to run verify /md5 flash:new_image.bin on every single device? Manual processes are breeding grounds for inconsistency, which leads to bizarre, hard-to-troubleshoot production issues down the line.
• There’s No Audit Trail: When something goes wrong (and it will), your only record is your memory and maybe a hastily updated ticket. There’s no version-controlled code, no execution log, no proof of what was actually done. You can’t roll back easily, and you can’t prove compliance.

So, let’s put the USB sticks back in the drawer and look at how we solve this for good.

Solution 1: The ‘Get-It-Done-Tonight’ Fix (TFTP/SCP Server)

Okay, you don’t have time to build a whole automation pipeline. The change window is tonight. The bare minimum improvement is to centralize the source of truth. Instead of five USB sticks, you need one server.

Spin up a temporary TFTP (Trivial File Transfer Protocol) or SCP (Secure Copy) server on your laptop or a utility server. Put the IOS image there, and only there. Now, you can console into each switch and pull the file from a single, consistent source.

Example: Copying from a TFTP Server

On the switch CLI:

prod-core-sw01# copy tftp://192.168.1.100/c9300-universalk9.17.09.04a.SPA.bin flash:
Address or name of remote host [192.168.1.100]? 
Source filename [c9300-universalk9.17.09.04a.SPA.bin]? 
Destination filename [c9300-universalk9.17.09.04a.SPA.bin]? 
Accessing tftp://192.168.1.100/c9300-universalk9.17.09.04a.SPA.bin...
Loading c9300-universalk9.17.09.04a.SPA.bin from 192.168.1.100: !!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 123456789 bytes]

Is it hacky? Yes. Is it still manual? Yes. But you’ve eliminated the risk of using different files and can update any switch with network access to your transfer server. It’s a step up from the stone age.

Solution 2: The ‘Sleep-Through-the-Night’ Fix (Ansible)

This is where we start thinking like engineers, not just technicians. It’s time to automate. Ansible is an agentless configuration management tool that is perfect for network devices. You write a “playbook” that defines the steps, and Ansible executes them for you over SSH.

Your playbook becomes your single source of truth. It’s code. You can check it into Git, have it peer-reviewed, and run it against a list of hosts. It’s repeatable, auditable, and scalable.

Example: A Simple Ansible Playbook to Upgrade IOS

---
- name: Upgrade Cisco IOS on Core Switches
  hosts: cisco_switches
  gather_facts: no
  connection: network_cli

  tasks:
    - name: Copy new IOS image to flash
      cisco.ios.ios_command:
        commands:
          - command: "copy scp://user:pass@10.0.0.5/c9300-universalk9.17.09.04a.SPA.bin flash:"

    - name: Verify MD5 hash of the new image
      cisco.ios.ios_command:
        commands:
          - command: "verify /md5 flash:c9300-universalk9.17.09.04a.SPA.bin"
      register: md5_output

    - name: Assert that the hash is correct
      assert:
        that:
          - "'b4d455a561934e0e5e5a2a5301f28b49' in md5_output.stdout[0]"
        fail_msg: "MD5 Hash Mismatch on {{ inventory_hostname }}!"
        success_msg: "MD5 Hash Verified on {{ inventory_hostname }}."

    - name: Set boot variable to new image
      cisco.ios.ios_config:
        lines:
          - no boot system
          - boot system flash:c9300-universalk9.17.09.04a.SPA.bin
      
    - name: Save configuration
      cisco.ios.ios_config:
        save_when: modified

Pro Tip: ALWAYS test your automation against a lab device or non-production environment first. A playbook can roll out a mistake just as fast as it can a fix. Treat your network config like application code.

Solution 3: The ‘Never-Touch-A-Switch-Again’ Fix (Network DevOps & GitOps)

This is the holy grail. Here, you’re not just running a script; you’re building a system. This involves integrating your network automation into a CI/CD pipeline.

Imagine a workflow:

1. A network engineer wants to change a boot variable.
2. They change a YAML file in a Git repository and open a pull request.
3. The PR automatically triggers a pipeline that lints the code, runs the playbook against a virtual lab environment, and runs post-checks.
4. A senior engineer reviews and approves the PR.
5. Merging the PR automatically triggers the Ansible playbook to run against production switches during the next maintenance window.

This approach gives you the ultimate in safety, auditability, and scalability. Tools like Cisco DNA Center, Arista CloudVision, or a well-built custom platform using tools like Ansible, Terraform, and Jenkins/GitLab CI can get you here.

Solution Comparison

Look, we’ve all been that person in the data center at 2 AM. The goal is to make sure you only have to learn that lesson once. Stop running around and start automating. Your future self—the one sleeping soundly during the next upgrade cycle—will thank you.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions