Scope note: this page covers the protocols themselves: how TFTP and FTP work on the wire, when to pick each. For the Cisco-side
copy … tftp:/copy … flash:commands,boot system, and the flash / nvram / system: file-systems, see the companion topic → Cisco IOS File System.
Mental model
Cisco devices need to move files: pushing a config to a TFTP server for backup, pulling a new IOS image from an FTP server, receiving a firmware upgrade. Both TFTP and FTP have been around since the 1980s, and they’re both still on the exam because IOS still uses them under copy.
Rule of thumb: if the file is small and the network is trusted, use TFTP. If the file is large, use FTP. If the network is untrusted, use SCP or SFTP: FTP sends credentials in clear text. (SCP/SFTP are outside CCNA v1.1 scope but are topic 4.2 on CCNA v2.0, from February 3, 2027.)
TFTP vs FTP at a glance
| Feature | TFTP | FTP |
|---|---|---|
| Transport | UDP/69 | TCP/21 (control) + TCP/20 (data, active) |
| Auth | None | Username + password (plaintext) |
| Directory listing | No | Yes (ls, dir) |
| File size | Ideally < 32 MB (older impls capped at 32 MB) | Multi-GB |
| Reliability | ACK per data block (512 B lock-step) | TCP handles it |
| Encryption | No | No (SFTP/FTPS add it) |
| Firewall friendliness | Single UDP port: easy | Two ports, plus active vs passive mode complexity |
| Typical use | Router configs, small IOS images, PXE boot, VoIP phone TFTP option 150 | Larger IOS images, backups when auth is required |
TFTP in a Cisco lab (the CCNA path)
You’ll almost always set up a TFTP server on a management workstation (Windows: Tftpd64 / SolarWinds TFTP; Linux: tftpd-hpa; Cisco Packet Tracer (Networking Academy): built into the server object) and then:
R1# copy running-config tftp:
Address or name of remote host []? 10.0.99.5
Destination filename [R1-confg]?
!!
4128 bytes copied in 0.512 secs
Reverse direction: pull a config or IOS image:
R1# copy tftp: flash:
Address or name of remote host []? 10.0.99.5
Source filename []? c2900-universalk9-mz.SPA.158-3.M2.bin
Destination filename [c2900-universalk9-mz.SPA.158-3.M2.bin]?
Accessing tftp://10.0.99.5/... !!!!!!!!
[OK - 33591768 bytes]
Every ! is one successfully-ACKed 512-byte block. A . means a retransmit: a small handful is normal, a wall of dots means you’re losing packets and should investigate the path.
FTP in a Cisco lab
FTP needs credentials. Set them globally so copy can pick them up:
R1(config)# ip ftp username admin
R1(config)# ip ftp password Sup3rS3cret
Then:
R1# copy ftp: flash:
Address or name of remote host []? 10.0.99.5
Source filename []? images/c2900-universalk9-mz.SPA.158-3.M2.bin
Destination filename [c2900-universalk9-mz.SPA.158-3.M2.bin]?
Loading images/c2900-universalk9-mz.SPA.158-3.M2.bin ...
[OK - 33591768 bytes]
Real IOS also supports SCP (ip scp server enable): outside CCNA v1.1 scope, in scope for CCNA v2.0 (topic 4.2), and the go-to for anything production.
The “which mode” FTP quirk (worth knowing)
FTP has two data-channel modes:
- Active: server initiates the data connection back to the client on client-chosen port. Firewalls hate this; NAT and stateful firewalls need FTP inspection to punch the hole.
- Passive (PASV): client initiates BOTH connections. Firewall-friendly, default on modern clients.
IOS’s copy ftp: uses passive by default. Nothing to configure, but if your topic asks “why doesn’t active FTP work through NAT?” the answer is the server’s inbound data connection can’t traverse the client-side NAT without FTP inspection.
PXE boot + TFTP: the DHCP option 66/150 pattern
TFTP is what boots diskless devices (thin clients, VoIP phones, network appliances). The device DHCP-requests an IP, and the DHCP server hands back:
- Option 66: the TFTP server name or IP (ISC
next-serversets the related BOOTP siaddr field) - Option 67 (
filename): which file to fetch - Option 150 (Cisco-specific): TFTP server list for Cisco IP phones
See the DHCP topic for the option syntax.
The #1 mistake
Using TFTP over a routed WAN. TFTP has no encryption, no meaningful auth, and its lock-step ACK model tanks throughput once round-trip time exceeds a few ms. It’s great LAN-side (management network, direct connection), a bad choice across a firewall or over VPN. Reach for FTP (or SCP) when the path isn’t a single L2 hop.
Verify a transfer went well
R1# dir flash:
Directory of flash:/
1 -rw- 33591768 Aug 9 2026 08:14:22 c2900-universalk9-mz.SPA.158-3.M2.bin
2 -rw- 2072 Mar 1 1993 00:05:12 cpconfig-2960.cfg
3 -rw- 856 Mar 1 1993 00:05:15 config.text
256000000 bytes total (162385920 bytes free)
R1# verify /md5 flash:c2900-universalk9-mz.SPA.158-3.M2.bin
..........................
verify /md5 (flash:c2900-universalk9-mz.SPA.158-3.M2.bin) = 6b3f95f2d0a4c7b1e9f3d8a2c5e6f9b1
Compare the MD5 against the value Cisco published for the image. If they don’t match, the image is corrupt or a middleman changed it. Never boot system an unverified image.