CCNA online course

Trivial File Transfer Protocol (TFTP) for CCNA

Learn how TFTP uses UDP port 69, transfer identifiers, RRQ and WRQ packets, Cisco IOS configuration and image transfers, security limitations, and troubleshooting.

Trivial File Transfer Protocol (TFTP) is a lightweight application-layer protocol for transferring files between hosts on an IP network. CCNA students commonly encounter it when backing up Cisco configurations, copying IOS images, or provisioning devices.

TFTP is intentionally simple. It supports basic file uploads and downloads, but it is not a general remote file-management system. It has no normal directory browsing, remote delete, rename, or interactive administration features. Unlike FTP, standard TFTP provides no user authentication and no encryption.

What TFTP Does

TFTP uses a client-server model. A client requests either a download from a server or an upload to a server. The server reads from or writes to a permitted directory, and the transfer ends when the final data block is received.

  • Read Request (RRQ): The client asks to download a named file from the server.
  • Write Request (WRQ): The client asks to upload a named file to the server.
  • DATA: Carries a numbered block of file contents.
  • ACK: Confirms receipt of a request or data block.
  • ERROR: Reports a problem such as a missing file or denied access.

FTP has substantially more features, including authentication, directory operations, and a richer command model. TFTP trades those features for a small implementation that is useful in controlled provisioning and device-management workflows.

TFTP Transport, Ports, and Transfer Identifiers

TFTP uses UDP, a connectionless transport protocol, rather than TCP. The initial client request is sent to the server's well-known UDP port 69.

Port 69 normally handles only the initial RRQ or WRQ. After receiving that request, the server selects a temporary Transfer Identifier (TID), typically an ephemeral UDP port. The rest of that transfer uses the client and server TIDs. This separates individual transfers and avoids sending all data through port 69.

A firewall rule that allows only UDP 69 may therefore be insufficient. The firewall must also permit the return traffic and the dynamically selected UDP transfer ports, usually through suitable stateful inspection or a correctly designed range of permitted ports. NAT devices and firewalls must understand or properly track the TFTP exchange.

Basic TFTP Operation

TFTP normally transfers data in lockstep. The sender transmits one DATA block and waits for an ACK before sending the next block. Because UDP does not provide reliable delivery, a sender retransmits after a timeout when the expected response is missing.

Traditional TFTP uses data blocks of up to 512 bytes. The final data block is smaller than the negotiated block size. If the file size is an exact multiple of the block size, TFTP signals completion with a zero-length final DATA block.

For a download, the exchange is conceptually:

  1. The client sends an RRQ to UDP 69 with the filename and transfer mode.
  2. The server responds from its selected TID with DATA block 1.
  3. The client sends ACK block 1.
  4. The server sends the next DATA block, and the process repeats.
  5. The transfer ends when the client acknowledges the final short or zero-length block.

For an upload, the client sends a WRQ to UDP 69. The server acknowledges the request, commonly with ACK block 0, and the client begins sending DATA block 1. Each block is acknowledged before the next one is sent.

TFTP Packet Types and Roles

Packet type — Purpose — Typical direction — Key fields

RRQ — Request a download — Client to server port 69 — Filename and mode

WRQ — Request an upload — Client to server port 69 — Filename and mode

DATA — Carry file contents — Sender to receiver — Block number and data

ACK — Confirm a request or block — Receiver to sender — Block number

ERROR — Report a failure — Either endpoint — Error code and message

OACK — Confirm negotiated options — Server to client — Requested options and values

Transfer Modes and Options

Octet mode, also called binary mode, transfers bytes without text conversion. It is normally used for Cisco IOS images, firmware, configuration-related binary files, and any file for which every byte must remain unchanged.

netascii is a text-oriented mode that can perform standardized line-ending conversion. It may be appropriate for some text files, but it should not be used for IOS images or arbitrary binary data.

TFTP also historically defined a mail mode. It is not a practical modern choice and is rarely supported or used.

The original simple behavior used 512-byte blocks. Option negotiation can extend that behavior. Common options include a larger block size and a timeout value. A client may request options, the server may return an OACK, and the client acknowledges the option response before normal data transfer continues. Actual support depends on the TFTP implementation.

Security Limitations

Standard TFTP has no user authentication and does not encrypt filenames, contents, or transfer metadata. Anyone who can reach an exposed service may be able to request files, attempt uploads, or learn information from error responses, depending on server policy.

  • Unauthorized reads can expose configurations, credentials, topology information, or firmware.
  • Unauthorized writes can replace configurations or install a malicious IOS image.
  • Unauthenticated traffic can be spoofed or redirected.
  • Files transferred across an untrusted network can be observed or modified.

Use TFTP only on a trusted management network or an isolated provisioning environment. Compensating controls include management-plane isolation, dedicated VLANs, ACLs, host firewalls, restricted server directories, strict file and directory permissions, client-address restrictions, and integrity verification with a trusted checksum or hash.

For production transfers, prefer an authenticated and encrypted method supported by the device and policy, such as SCP, SFTP, HTTPS, or another secure management protocol.

Common Uses

  • Network boot and provisioning: TFTP can deliver boot files in controlled PXE-related environments when the surrounding boot design requires it.
  • Configuration backup and restore: Network devices can upload configuration files to a server or retrieve them during recovery.
  • IOS image management: Administrators can copy an IOS image from flash to a server for backup or copy a server-hosted image into flash for an upgrade.
  • Firmware and configuration distribution: Controlled environments may use TFTP to distribute files to devices with limited transfer support.

Protocol selection depends on device support, security policy, the trust level of the transfer network, and operational requirements. TFTP can be suitable for an isolated lab or recovery process while SCP or SFTP is more appropriate for a production configuration backup.

Cisco IOS TFTP Workflows

A Cisco IOS device can act as a TFTP client when it has IP reachability to a TFTP server. Before transferring anything, verify the management path, source interface, server address, filename, permissions, available storage, and image compatibility.

Pre-transfer checks

show ip interface brief
show ip route
ping <tftp-server-ip>
dir flash:
  • Confirm the relevant interface is up and has the expected IP address.
  • Confirm routing and VLAN membership provide a path to the server.
  • Use the appropriate source interface when the platform or topology requires one.
  • Confirm the exact filename and TFTP root directory.
  • For an IOS image, check platform, feature set, release compatibility, and flash capacity.

Back up running and startup configurations

copy running-config tftp:
copy startup-config tftp:

IOS prompts for the TFTP server address and destination filename. A running-configuration backup reflects the active configuration; a startup-configuration backup reflects the configuration saved for the next boot. Treat both files as sensitive because TFTP does not protect them in transit.

Restore configuration content

copy tftp: running-config
copy tftp: startup-config

Copying a file into running-config generally merges commands into the active configuration; it does not necessarily replace every existing command. Validate the file first, plan rollback, and use out-of-band access or a maintenance window because routing, interface, or management commands may change.

Copying into startup-config prepares the configuration for a later boot. A reload is normally required before it becomes the running configuration. Confirm that the file belongs to the correct platform and topology.

Back up an IOS image from flash

dir flash:
copy flash: tftp:

Select the known IOS image in flash, provide the TFTP server address, and specify a destination filename. Check server storage and verify that the copy completed successfully.

Copy an IOS image into flash

dir flash:
copy tftp: flash:
verify /md5 flash:<image-filename>
show boot

Check free flash space before the transfer. Afterward, validate the file listing, use the checksum method supported by the device and trusted image source, review boot variables, and plan the reload. Do not reload merely because the copy command completed; an incomplete, corrupt, or incompatible image can prevent normal boot.

Using the Cisco device as a TFTP server

Some IOS platforms can serve explicitly named files from flash through the built-in TFTP server feature:

tftp-server flash:<filename>

Syntax and options vary by platform and IOS release. Serve only necessary files and restrict access with management-plane controls and ACLs. Do not expose this service to untrusted networks.

Cisco TFTP Copy Directions

Transfer goal — Source — Destination — Primary verification

Configuration backup — Running-config or startup-config — TFTP server — Confirm filename, server receipt, and file permissions

Configuration restore — TFTP server — Running-config or startup-config — Review contents and validate operational impact

IOS image backup — Flash — TFTP server — Confirm image filename, size, and server storage

IOS image download to flash — TFTP server — Flash — Check free space, checksum, boot setting, and reload plan

TFTP Compared with FTP and Secure Alternatives

Protocol — Transport — Authentication — Encryption — Remote file-management features — Typical network-device use

TFTP — UDP — None in standard protocol — None — Basic read and write only — Lab recovery, provisioning, and legacy device transfers

FTP — TCP — Username and password commonly available — None in standard FTP — Directory listings and file-management commands — Legacy managed transfers where encryption is handled separately

SCP — TCP through SSH — SSH authentication — Yes — Secure copy with limited management semantics — Secure device configuration and image transfers

SFTP — TCP through SSH — SSH authentication — Yes — Richer remote file operations — Secure administration and file management

FTP is more capable than TFTP but standard FTP still does not encrypt the transfer. SCP and SFTP provide authentication and encryption through SSH. Use the method that the device supports and that satisfies the security policy; do not select TFTP solely because it is simple.

Verification and Troubleshooting

Start with Layer 3 reachability before diagnosing TFTP. Confirm interface state, addressing, VLAN membership, routing, and a successful ping where permitted. Then confirm that the server process is listening on the intended address, the requested file exists beneath the permitted TFTP root, and server logs show the client request.

Common TFTP Errors and Likely Causes

Symptom or error — Likely cause — Validation step — Corrective action

Timeout — No reachability, stopped server, UDP 69 filtering, wrong address or source interface — Ping, inspect routes and interfaces, confirm listening service — Correct routing, server operation, ACLs, or firewall rules

File not found — Wrong filename, root directory, case mismatch, or absent file — Check exact name, directory, permissions, and logs — Place the file in the permitted directory or correct the request

Access violation — Writes disabled, directory restriction, permissions, or client policy — Review server write policy and host controls — Permit only the intended operation and client

Disk or flash full — Insufficient server or device storage — Check server capacity or dir flash: — Remove safe files, select suitable storage, or use another destination

Incorrect source interface — Device chooses an address not allowed by routing or server policy — Inspect interfaces, routes, and source behavior — Configure or select the correct management path where supported

Transfer stalls after starting — TID port blocked, NAT or inspection failure, or packet loss — Capture packets and inspect interface errors — Fix TFTP-aware firewall handling, UDP return rules, NAT, or link quality

Understanding a TFTP Packet Capture

In a capture, first identify the RRQ or WRQ sent to server UDP port 69. The server's response should use a different UDP source port: its TID. Subsequent DATA and ACK packets should use that transfer flow rather than repeatedly targeting port 69. If the initial request is visible but the first DATA packet or later ACKs are missing, inspect firewall, ACL, NAT, and stateful-inspection behavior.

Repeated DATA or ACK packets usually indicate a lost packet or response and therefore a timeout-driven retransmission. A transfer that always fails immediately points more often to reachability, server availability, or UDP 69 filtering; a transfer that begins and then stalls points more often to the negotiated TID path or packet loss.

IOS-specific Image Recovery Checks

When an image transfer is part of recovery or upgrade, also inspect flash contents and capacity, the exact image filename, platform compatibility, boot variables, and relevant configuration-register or boot settings. Use platform documentation for recovery-specific commands. Preserve console or out-of-band access before changing boot settings or scheduling a reload.

Practical Scenarios

Downloading a configuration file

A client sends an RRQ for edge-config.txt to the server's UDP 69. The server selects a TID and sends DATA block 1 from that temporary port. The client acknowledges block 1, receives the next block, and continues until it acknowledges the final short block. The client should use the correct text or binary mode for the file and must be able to receive the server's TID traffic.

Uploading a Cisco configuration backup

On a trusted management subnet, verify reachability and then run copy running-config tftp: or copy startup-config tftp:. Supply the server address and a meaningful destination filename. Confirm that the server received the file and protect it as sensitive operational data.

Backing up an IOS image

Use dir flash: to identify the known image, verify server reachability and storage, and run copy flash: tftp:. Confirm the copied filename and size, then verify its integrity using an available checksum process.

Upgrading from a TFTP-hosted image

Confirm flash capacity, image compatibility, server reachability, and the exact filename. Use copy tftp: flash:, verify the resulting file, review show boot, and schedule a reload with console or out-of-band access. Keep a compatible fallback image when platform storage permits.

Troubleshooting a firewall timeout

A request may successfully reach UDP 69 while the server's subsequent DATA packets come from a dynamically selected TID. If the firewall permits only UDP 69, the request can appear to work but the transfer then stalls. A packet capture showing the initial port 69 exchange followed by blocked TID traffic confirms this pattern.

Choosing a safer method

TFTP may be acceptable for an isolated lab image-recovery exercise. For a production configuration transfer, choose SCP, SFTP, HTTPS, or another supported authenticated and encrypted method instead.

Exam-Relevant Notes

  • TFTP uses UDP, not TCP.
  • UDP port 69 is used for the initial RRQ or WRQ.
  • The rest of a transfer uses server- and client-selected TIDs, commonly ephemeral UDP ports.
  • RRQ means download; WRQ means upload.
  • TFTP uses DATA and ACK packets and retransmits after timeouts because UDP itself is unreliable.
  • Traditional DATA blocks contain up to 512 bytes; an exact multiple requires a zero-length final block.
  • Octet mode is the normal choice for IOS images and other binary files.
  • Standard TFTP has no authentication or encryption.
  • Allowing UDP 69 alone may not allow a complete transfer.