TFTP and FTP file transfer
What TFTP and FTP provide for image and configuration transfers, transport differences, and operational caveats.
TFTP versus FTP
TFTP versus FTP
| Property | TFTP | FTP |
|---|---|---|
| Transport | Starts on UDP 69, then per-transfer IDs | TCP 21 control; data from server TCP20 to a negotiated client port (active) |
| Authentication | None | Username/password (cleartext) |
| Reliability | Application-level ACK per block; no session | TCP-reliable |
| Features | Read/write files only — no listing, no directories | Directory listing, rename, delete |
| Use | IOS images, configs in a controlled LAN | General file transfer where a session protocol fits |
FTP active vs passive: in active mode the data channel originates *from* the server's TCP 20 *to* a negotiated client port — inbound to the client, often blocked by firewalls/NAT. Passive mode has the client open both connections — friendlier to NAT and firewalls. Expect this distinction in troubleshooting scenarios.
Operational use
On Cisco devices the classic transfers are copy running-config tftp: (backup), copy tftp: running-config (restore/merge), and copy tftp: flash: (image staging). TFTP's simplicity makes it perfect for network boot and device configs — and completely unsuitable where authentication or integrity checking matters.
Archive running-config to a TFTP server — Privileged EXEC
Cisco IOS / IOS XE
copy running-config tftp://192.168.99.20/sw1-backup.cfg
show running-config | include logging|archive dir flash: show archive config differences
- The file appears on the server with a sane size.
- Image transfers verify with the published checksum.
copy tftp: running-configMERGES — it does not replace; use startup-config for full replacement.- TFTP has no auth or encryption — only use on a trusted management network.
Read-only verification commands.
- Symptom
- `copy tftp: flash:` retries then aborts
- UDP 69 must reach the server — check reachability first.
- ACLs or NAT between device and server break TFTP's simple exchange (no connection to hide behind).
- Insufficient flash space also aborts — check
dirfirst.
Verify path, permissions and free space — TFTP has almost no error reporting to help you.
Caveats and troubleshooting
Common mistakes
- Expecting TFTP over TCP — it's UDP-only.
- Using TFTP across an untrusted path — no auth, no encryption.
- Assuming
copy tftp: running-configreplaces the config — it merges lines. - Blaming the server when a firewall blocks FTP's second (data) connection — that's the active-mode problem.
Observation: FTP session authenticates, ls/get hang or fail.
- Data channel blocked — classic active-mode vs firewall/NAT issue
- Passive mode needed on this path
- Server data port range unopened
| Check | Indicates |
|---|---|
| Switch client to passive mode | If it works, the inbound data connection was the blocker. |
| Firewall rules for the data channel | Active mode needs server→client TCP 20; passive needs the server's pasv range. |
Correction: Use passive mode or open the required data path.
Directory listing and transfers complete.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
- RFC 1350 — The TFTP Protocol (Revision 2) — reviewed 2026-11-02
- RFC 959 — File Transfer Protocol (FTP) — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.