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 or the network is untrusted, use FTP (or SCP/SFTP — but those are outside CCNA scope).
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 DevNet: pre-loaded on Packet Tracer’s 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 scope but 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 (
next-server) — the TFTP server IP - 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.