200-301 · IP Services · Updated August 3, 2026

TFTP and FTP on IOS: Backing Up Configs and Upgrading Images

TFTP runs over UDP port 69 with no authentication and no encryption, which makes it fine for pulling a configuration or a small image across a trusted management segment and unsuitable for anything else. FTP runs over TCP, using port 21 for control and port 20 for data in active mode, requires a username and password, and handles large image files far more reliably across a WAN. An image upgrade is the same copy command either way, followed by two steps people skip: verifying the file’s hash before trusting it, and saving the configuration so the boot statement survives the reload.

Choosing the transfer protocol

	TFTP	FTP	SCP
Transport and ports	UDP 69	TCP 21 control, TCP 20 data (active mode)	TCP 22, inside SSH
Authentication	None	Username and password	SSH credentials
Confidentiality	None, clear text	None, clear text including the password	Encrypted
Reliability mechanism	Lock-step acknowledgement per block	TCP windowing and retransmission	TCP inside SSH
Practical file size	Historically capped near 32 MB without extensions	No practical limit	No practical limit
Directory listing	Not supported	Supported	Supported
Best fit	Small files on a trusted management VLAN	Large images over a managed link	Anything crossing untrusted ground

FTP credentials are configured globally before the transfer so the copy does not prompt for them:

R1(config)# ip ftp username netops
R1(config)# ip ftp password 0 <password>

The 0 in that second line marks the value as unencrypted, the weakest of the IOS password types, so anyone reading the configuration reads the FTP password with it.

SCP is the option to reach for whenever the path is not fully trusted, since it authenticates and encrypts inside SSH. The device can also act as an SCP server with ip scp server enable, which lets a workstation push files to it.

Backing up and restoring configuration

The backup runs from privileged EXEC mode and prompts for the destination:

R1# copy running-config tftp:
Address or name of remote host []? 10.10.10.5
Destination filename [r1-confg]? r1-2026-08-03.cfg
!!
2145 bytes copied in 1.284 secs (1670 bytes/sec)

Restoring is where the exam plants a distinction that matters operationally. copy tftp: running-config merges the downloaded file into what is already running. Commands in the file are added or overwrite matching lines, but anything present on the device and absent from the file survives, so this does not return the device to a known state. copy tftp: startup-config replaces the contents of NVRAM outright, and a reload then brings the device up on exactly the saved file.

copy running-config startup-config, or its shorter alias write memory, saves the current configuration into NVRAM. Everything about boot behavior downstream depends on that command having been run.

Checking flash before a transfer

A transfer that runs out of space partway leaves a truncated file that is useless and still occupying the space. Check first:

R1# show flash:
-#- --length-- -----date/time------ path
  1  521633808 Aug 03 2026 09:12:44 +00:00 isr4300-universalk9.17.06.05.SPA.bin
  2       3096 Jul 28 2026 14:02:10 +00:00 vlan.dat

3117191168 bytes available (521637888 bytes used)

dir flash: produces the same information in a different layout. What you need is free space for the new image alongside the one being retained, not instead of it. Deleting the running image to make room removes the only thing that can rescue a failed upgrade, and if the new file turns out to be corrupt you are left with a device that has no bootable software. Free space is a question answered before the copy, not after it.

Copying the image

R1# copy tftp: flash:
Address or name of remote host []? 10.10.10.5
Source filename []? isr4300-universalk9.17.09.04a.SPA.bin
Destination filename [isr4300-universalk9.17.09.04a.SPA.bin]?
Accessing tftp://10.10.10.5/isr4300-universalk9.17.09.04a.SPA.bin...
Loading isr4300-universalk9.17.09.04a.SPA.bin from 10.10.10.5 (via GigabitEthernet0/0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 543821824 bytes]

The argument order is source then destination, so copy tftp: flash: pulls a file onto the device and copy flash: tftp: pushes one off it. Reversing them is a common configuration-mode slip, though both are valid commands, so IOS will happily do the wrong one. The copy command runs from privileged EXEC, not from global configuration; if the prompt reads R1(config)# you are in the wrong place, which the IOS CLI modes article covers in full.

Verifying the image

R1# verify /md5 flash:isr4300-universalk9.17.09.04a.SPA.bin
....................................................
verify /md5 (flash:isr4300-universalk9.17.09.04a.SPA.bin) = 3d9f2a71c04e58b6a19c7f0d2e8b4a55

The device computes a hash over the file as it now sits in flash. Comparing that value against the hash the vendor published on its download page tells you one thing precisely: the file on the device is byte-for-byte identical to the file the vendor released, so the transfer neither corrupted nor truncated it. Passing the expected value as an argument makes IOS do the comparison and report Verified or a failure.

Being clear about what a match does not prove keeps you out of the distractors:

It says nothing about licensing or platform suitability. A perfectly intact image built for a different platform still refuses to boot, and the device answers that question at startup rather than at hash time.
It says nothing about free space. Space governs whether the copy could finish, and that check belongs before the transfer.
It says nothing about how the bytes travelled. An image pulled over unauthenticated TFTP produces the same clean hash as one pulled over SCP. The hash is an integrity check on the stored result, not evidence of a protected channel.

Verify before pointing a boot statement at the file, while there is still time to fetch it again over a maintenance window that has not started.

Boot statements and NVRAM

R1(config)# boot system flash:isr4300-universalk9.17.09.04a.SPA.bin
R1(config)# boot system flash:isr4300-universalk9.17.06.05.SPA.bin

Two behaviors here catch people out.

Multiple statements form an ordered list, not an override. The device tries the first file. If that file is missing, truncated, or unusable, it falls through to the second. Naming the new image first and leaving the previous one listed after it is deliberate design: a bad upgrade falls back to known-good software instead of dropping to the bootstrap monitor.

Boot statements are read from the startup configuration, not the running configuration. The bootstrap executes before a running configuration exists, so the only thing it can consult is what was written to NVRAM. Type these two lines, then reload without saving, and the device boots using whatever instructions were already stored in NVRAM. The new lines are discarded along with the rest of the unsaved running configuration, the upgrade appears to have done nothing, and the version string after the reload is unchanged. Save first:

R1# copy running-config startup-config
R1# reload

Verify the intent before reloading with show bootvar (or show boot on some platforms), which prints the boot list and the configuration register. show version reports the running image and the register after the fact.

The configuration register itself is 0x2102 in normal operation: boot from flash and use the saved configuration. Setting it to 0x2142 makes the device ignore the startup configuration at boot, which is the password recovery procedure that console access makes possible. It has no place in an upgrade, and applying it to a remote branch router brings the device back with no configuration and no reachability.

Upgrade sequence

Record the current state: show version and show flash:.
Confirm free space for the new image while retaining the current one.
Back up the running configuration to a server so the device can be rebuilt if the chassis does not return.
Copy the image into flash.
Run verify /md5 and compare against the vendor-published hash.
Add boot system for the new image, then a second statement for the old one as a fallback.
Save with copy running-config startup-config.
Reload, then confirm with show version.

Three items that look plausible but do not belong: erasing the existing image before the transfer, setting the configuration register to 0x2142, and clearing ARP or MAC address tables, which are rebuilt automatically within seconds of a reload.

How the 200-301 exam tests this

What a hash match proves. The stem describes comparing verify /md5 output against a published value and asks what has been confirmed. The answer is file integrity against the vendor’s copy. The traps are licensing, platform compatibility, sufficient free space, and encrypted transport.
The unsaved reload. Boot statements are entered and the device is reloaded without saving. The device boots from whatever NVRAM already held, because the bootstrap reads only the startup configuration. Distractors claim the running configuration takes effect immediately or that the last statement entered wins.
Change-record checklists. Multi-select items ask which pre-reload checks belong on the list. Free space, an off-box configuration backup, and hash verification are correct. Erasing the old image, setting 0x2142, and clearing address tables are the wrong three.
Protocol selection. A scenario gives a constraint such as authentication being required, or a large file crossing a WAN, or an untrusted path. TFTP has no authentication, FTP has clear-text credentials over TCP, and SCP is the encrypted answer.
Merge versus replace. Restoring with copy tftp: running-config merges and does not remove leftover commands; restoring to startup-config and reloading gives the clean result.

File transfer competes for attention with NTP, DHCP, DNS, SNMP, syslog, and QoS, so recognizing which of the many small topics packed into IP services you have already covered keeps this one from swallowing more time than its share. A pass through practice questions spanning the whole services domain shows quickly which of them still needs work.

Quick reference

TFTP: UDP 69, no authentication, no encryption, no directory listing.
FTP: TCP 21 control and TCP 20 data in active mode, username and password in clear text.
SCP over TCP 22 is the authenticated and encrypted option.
copy running-config tftp: backs up; copy tftp: startup-config plus a reload restores cleanly, while copy tftp: running-config only merges.
show flash: or dir flash: reports free space; keep room for both images.
copy tftp: flash: reads source first, destination second, from privileged EXEC.
verify /md5 flash:<file> proves the stored file matches the vendor’s, and proves nothing about licensing, space, or transport security.
boot system statements are an ordered fallback list read from NVRAM at startup.
Save with copy running-config startup-config before reload, or the boot statements are discarded.
Register 0x2102 is normal; 0x2142 ignores the startup configuration and belongs only to password recovery.