Cisco Unified CallManager System Guide, Release 4.2(3)
Cisco TFTP
Downloads: This chapterpdf (PDF - 248.0KB) The complete bookPDF (PDF - 5.08MB) | Feedback

Cisco TFTP

Table Of Contents

Cisco TFTP

TFTP Process Overview

Understanding How Devices Use DHCP and Cisco TFTP

Understanding How Devices Access the TFTP Server

Understanding How Devices Identify the TFTP Server

Configuring a Redundant and Load-Sharing TFTP Server

Centralized TFTP in a Multiple Cluster Environment

Master TFTP Server

Alternate File Locations

Sending Files to the Master TFTP Server

Centralized TFTP with Secure Clusters

Configuration Tips for Centralized TFTP

TFTP Configuration Checklist

Where to Find More Information


Cisco TFTP


The Cisco TFTP service serves files that are consistent with the Trivial File Transfer Protocol (TFTP). Cisco TFTP builds device configuration files and serves embedded component executables and ringer files.

A configuration file contains a prioritized list of Cisco Unified CallManagers for a device (telephones and gateways), the TCP port on which the device connects to those Cisco Unified CallManagers, and an executable load identifier. Configuration files for selected devices contain locale information and URLs for the phone buttons: messages, directories, services, and information. Configuration files for gateways contain all their configuration information.

Configuration files may be in a .cnf format or a .cnf.xml format, depending on the device type and your TFTP service parameter settings. The Build CNF Files parameters speed up the configuration file build process. Build None is the fastest, and Build All is the slowest.

When the Build CNF Files parameter is set to Build All, the TFTP server builds both .cnf.xml and .cnf format configuration files for all devices.

When the Build CNF Files parameter is set to Build None, the TFTP server builds only .cnf.xml files for all devices.

When the Build CNF Files parameter is set to Build Selective, which is the default value, the TFTP server builds .cnf.xml files for all devices and, in addition, builds .cnf files only for a select list of device types that are provided in Table 9-1:

Table 9-1 Devices with Build Selective Build CNF Files 

Device Type
Device Name

MODEL_30SPP

Cisco 30 SP+

MODEL_12SPP

Cisco 12 SP+

MODEL_12SP

Cisco 12 SP

MODEL_12S

Cisco 12 S

MODEL_30VIP

Cisco 30 VIP or DPA

MODEL_IP_CONFERENCE_PHONE

Cisco 7935

MODEL_SCCP_PHONE

SCCP Phone

MODEL_VEGA

Analog Access

MODEL_UONE

Voice Mail Port


This section describes the relationship among Cisco Unified CallManager, TFTP, and Dynamic Configuration Protocol (DHCP), the relationship between devices and the TFTP server, and the centralized TFTP environment. This section contains the following topics:

TFTP Process Overview

Understanding How Devices Use DHCP and Cisco TFTP

Understanding How Devices Access the TFTP Server

Understanding How Devices Identify the TFTP Server

Configuring a Redundant and Load-Sharing TFTP Server

Centralized TFTP in a Multiple Cluster Environment

TFTP Configuration Checklist

Where to Find More Information

TFTP Process Overview

The TFTP server can handle simultaneous file requests. This section describes the file request process.

When a device boots, it queries a DHCP server for its network configuration information. The DHCP server responds with an IP address for the device, a subnet mask, a default gateway, a Domain Name System (DNS) server address, and a TFTP server name or address. (Some devices, such as the Cisco Unified IP Phone model 7960, support up to two TFTP servers. If the primary TFTP server is not reached, such devices attempt to reach the secondary TFTP server.)


Note If DHCP is not enabled on a device, or it is not supported in the network, you must assign it an IP address and configure the TFTP server locally on the device.


The device requests a configuration file from the TFTP server. The TFTP server searches an internal cache, then primary and alternate paths (if specified) for the configuration file. If the TFTP server finds the configuration file, it sends it to the device. If the device receives the Cisco Unified CallManager name, it resolves the name by using DNS and opens a Cisco Unified CallManager connection. If the device does not receive an IP address or name, it uses the default server name.

If the TFTP server cannot find the configuration file, it sends a "file not found" message to the device. After certain amount of failed attempts, the phone may begin the autoregistration process.

Devices that are requesting a configuration file while the TFTP server is rebuilding all configuration files or while processing the maximum number of requests (the Maximum Serving Count parameter default is 200) receive a message from the TFTP server, which causes the device to request the configuration file later.

For a more detailed description of how devices boot, see the "Understanding How Devices Use DHCP and Cisco TFTP" section.

Understanding How Devices Use DHCP and Cisco TFTP

Cisco telephony devices require IP addresses that are assigned manually or by using DHCP. Devices also require access to a TFTP server that contains device loads and device configuration files.

Obtaining an IP Address

If DHCP is enabled on a device, DHCP automatically assigns IP addresses to the device when you connect it to the network. The DHCP server directs the device to a TFTP server (or to a second TFTP server, if available for the device). For example, you can connect multiple Cisco Unified IP Phones anywhere on the IP network, and DHCP automatically assigns IP addresses to them and provides them with the path to the appropriate TFTP server.

If DHCP is not enabled on a device, you must assign it an IP address and configure the TFTP server locally on the device.

The default DHCP setting varies depending on the device:

Cisco Unified IP Phones stay DHCP-enabled by default. If you are not using DHCP, you need to disable DHCP on the phone and manually assign it an IP address.

DHCP remains always enabled for Cisco Access Analog and Cisco Access Digital Gateways.

For Cisco Catalyst 6000 8 Port Voice T1/E1 and Services Modules, the Network Management Processor (NMP) on the Cisco Catalyst 6000 may or may not have DHCP enabled. If DHCP is not enabled, you must configure the IP address through the Cisco CATOS command-line interface on the Cisco Catalyst 6000.

Requesting the Configuration File

After a device obtains an IP address (through DHCP or manual assignment), it requests a configuration file from the TFTP server.

A device requests a configuration file that corresponds to its device name. After a certain number of failed attempts to download its corresponding configuration file, the phone begins the autoregistration process. After the auto-registration process is successful, the phone downloads its new corresponding configuration file. If the autoregistration process is not successful; for example, autoregistration is not enabled, the phone will attempt to register and be rejected by Cisco Unified CallManager.


Note Phones represent the only device type that can auto-register and that have default configuration files. You must manually add all other devices to the Cisco Unified CallManager database.


If a phone has an XML-compatible load, it requests a .cnf.xml format configuration file; otherwise, it requests a .cnf file.

Contacting Cisco Unified CallManager

After obtaining the configuration file from the TFTP server, a device attempts to make a TCP connection to the highest priority Cisco Unified CallManager in the list that is specified in the configuration file. If the device was manually added to the database, Cisco Unified CallManager identifies the device. If auto-registration is enabled in Cisco Unified CallManager, phones that were not manually added to the database attempt to auto-register in the Cisco Unified CallManager database.

Cisco Unified CallManager informs devices that are using .cnf format configuration files of their load ID. Devices that are using .xml format configuration files receive the load ID in the configuration file. If the device load ID differs from the load ID that is currently executing on the device, the device requests the load that is associated with the new load ID from the TFTP server and resets itself. For more information on device loads, see the "Device Support" section.

After a telephone is ready to make a call, it will request an available ringer list from the TFTP server. If the telephone user changes the ring type, the TFTP server sends the new ring type.

Understanding How Devices Access the TFTP Server

You can enable the IP phones and gateways to discover the TFTP server IP address in one or more of the following ways, depending on the device type:

Gateways and phones can use DHCP custom option 150.

Cisco recommends this method. With this method, you configure the TFTP server IP address as the option value.

Gateways and phones can use DHCP option 066.

You may configure either the host name or IP address of the TFTP server as the option value.

You can configure phones with the IP address of the TFTP server. If DHCP is enabled on the phone, you can still configure an alternate TFTP server IP address locally on the phone that will override the TFTP address that was obtained through DHCP. Refer to the phone administration guide that came with the phone for TFTP configuration information.

Gateways and phones also accept the DHCP Optional Server Name (sname) parameter.

The phone or gateway can use the value of Next-Server in the boot processes (siaddr).

Devices save the TFTP server address in nonvolatile memory. If one of the preceding methods was available at least once, but is not currently available, the device uses the address that is saved in memory.

You can configure the TFTP service on a publisher or subscriber server; however, Cisco recommends that you configure TFTP on a publisher server. For small systems, the TFTP server can coexist with Cisco Unified CallManager on the same server. For more information on supported TFTP server configurations, refer to the Cisco Unified Communications SRND Based on Cisco Unified CallManager Release 4.x.

Understanding How Devices Identify the TFTP Server

Phones and gateways have an order of precedence that they use for selecting the address of the TFTP server if they receive conflicting or confusing information from the DHCP server. The basis for the order of precedence depends on the method that is used to specify the TFTP server (method 1 in the following list has the highest precedence):

1. The phone or Catalyst 6000 gateway uses a locally configured TFTP server address.

This address overrides any TFTP address that the DHCP server sends.

2. The phone or gateway queries the DNS name CiscoCM1, and it is resolved.

The phone or gateway always tries to resolve the DNS name CiscoCM1. If this name is resolved, it overrides all information that the DHCP server sends.

You do not need to name the TFTP server CiscoCM1, but you must enter a DNS CName record to associate CiscoCM1 with the address or name of the TFTP server. Cisco does not recommend this option because it does not scale.

3. The phone or gateway uses the value of Next-Server in the boot processes.

The address of the TFTP server traditionally uses this DHCP configuration parameter. When BOOTP servers are configured, this field typically serves as the address of the TFTP server.

This information gets returned in the siaddr (server IP address) field of the DHCP header. Use this option, if available, because some DHCP servers will place their own IP address in this field when it is not configured.

4. The phone or gateway uses the site-specific option 150.

This option resolves the issue that some servers do not allow the Next-Server configuration parameter. Some servers allow access to the Next-Server parameter only when IP addresses are statically assigned.

5. The phone or gateway uses the Optional Server Name parameter.

This DHCP configuration parameter designates the host name of a TFTP server. Currently, you can configure only a host name in this parameter; do not use a dotted decimal IP address.

6. The phone or gateway uses the 066 option, which is the name of the boot server.

Option 066 normally replaces the sname (server name) field when option overloading occurs. This name field can contain a host name or a dotted decimal IP address.

Do not use the 066 option with the 150 option.

The device prefers the IP address over the name that is given by the 066 option if they are sent together. If both a dotted decimal IP address and a 150 option are sent, order of preference depends on the order in which they appear in the option list. The device chooses the last item in the option list because option 066 and option 150 remain mutually exclusive.

Configuring a Redundant and Load-Sharing TFTP Server

You must have one TFTP server configured in a cluster. However, you may want to configure a redundant or load-sharing TFTP server. If a device (phone or gateway) gets no response from the first TFTP server or if the server is busy and returns a "Process Allocation Exceeded" message (and if a redundant TFTP server is configured), the device will try to connect to the second TFTP server. The second TFTP server is configured in option 150 in the DHCP scope.

If the TFTP servers that are in the middle of rebuilding all configuration files return a "Disk Full" message to the requesting device, the device will not attempt to use the second TFTP server; instead, it will wait and retry the first TFTP server from which it received the "Disk Full" message.

Refer to the Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x for more information on TFTP server configuration recommendations.

Centralized TFTP in a Multiple Cluster Environment

A Centralized TFTP server supports multiple clusters within one large campus environment. The Centralized TFTP server design allows phones to be moved within a campus. It also supports a mixed OS multicluster environment.

Devices that are registered and configured in any cluster can be directed to a single TFTP server (Centralized TFTP server) that will then serve files to those devices. The following sections describe how the Centralized TFTP server works in a Cisco Unified CallManager multicluster environment:

Master TFTP Server

Alternate File Locations

Sending Files to the Master TFTP Server

Centralized TFTP with Secure Clusters

Configuration Tips for Centralized TFTP

Master TFTP Server

You can configure a single TFTP server to build the configuration files for devices in its cluster to serve all security, firmware, and configuration files to those devices. This single server, a Master TFTP Server, serves files from all other Cisco Unified CallManager clusters. The TFTP server in the other clusters, which are considered off-cluster TFTP servers, will build files only for devices that are configured for that particular cluster. All endpoint requests get sent to the Master TFTP Server, either by hard coding or by DHCP configuration at the endpoint.

The Master TFTP Server queries off-cluster TFTP servers if the requested file is not found locally. When the Master TFTP Server receives a file request, it looks first in its local caches and hard disk for the requested file. If the file does not exist there, then the Master TFTP Server will request the file from the off-cluster TFTP servers in sequential order. The request will eventually time out if the response is not received within a set time.

Alternate File Locations

To enable Centralized TFTP, you must configure the parameters for the Alternate File Locations only on the Master TFTP Server. You can specify up to 10 Alternate File Locations by using the TFTP service parameter window. For more information on service parameters, refer to the "Service Parameters Configuration" in the Cisco Unified CallManager Administration Guide.

You can use either of the following syntax examples:

host://<IP of the off-cluster TFTP server> (for example, host://10.10.134.24)

HOST://<IP of the off-cluster TFTP server> (for example, HOST://10.10.134.24)

If network DNS resolution is also supported, you can also use one of the following syntax examples:

host://<name of the off-cluster TFTP server> (for example, HOST://cluster2-tftp)

HOST://<name of the off-cluster TFTP server> (for example, HOST://cluster3-tftp)

You must use the format of the preceding syntaxes.

Sending Files to the Master TFTP Server

When an off-cluster TFTP server receives a request from the Master TFTP Server, it searches for the file and, if found, sends the requested file back to the Master TFTP Server by using HTTP. The Master TFTP Server then uses TFTP to send the requested file to the device that originally requested the file. Should the off-cluster TFTP server not have the requested file, it will respond to the Master TFTP Server with "File Not Found" (HTTP Error 404). The Master TFTP Server continues the process with the next off-cluster TFTP server until either the file is located or no remaining options exist.

When the off-cluster server is busy, it sends "HTTP Error 503" to the Master TFTP Server, so it should try the request again later. This message will also get sent to the endpoint device that made the original request.

Centralized TFTP with Secure Clusters

All off-cluster servers that are operating in secure mode must add the Master TFTP Server or servers IP address to the cluster's CTL file. (Without this updated CTL file, phones that register to a cluster where security is enabled and that attempt to download their configuration files will fail.) After the CTL file is updated, reboot the servers, so they can participate in the secure Centralized TFTP environment.

To update the CTL file for the TFTP servers, download the CTL Client plug-in by using Application > Install Plugins from Cisco Unified CallManager Administration. For more information about the CTL client and how to configure TFTP for security, refer to the Cisco Unified CallManager Security Guide.

Configuration Tips for Centralized TFTP

The following list comprises tips to remember when you are configuring a centralized TFTP environment:

Only the Master TFTP Server gets configured with alternate file locations.

Off-cluster TFTP servers must have no alternate file locations configured.

You can configure 1 to 10 Alternate File Locations in the Cisco TFTP Service Parameters Configuration window. If Alternate File Location 1 contains an empty parameter value, TFTP will stop searching for alternate servers. For example, if Alternate File Locations 2 through 10 are configured, Location 1 is empty, and TFTP is searching for servers, it will not search Alternate File Locations 2 through 10.

If autoregistration is enabled in the Cisco Unified CallManager cluster where the Master TFTP Server resides, phones that are configured in the Cisco Unified CallManager cluster where the off-cluster TFTP server phones reside may inadvertently get configured in the same Cisco Unified CallManager cluster where the Master TFTP Server resides. This scenario could occur when an Off-cluster TFTP Server may be busy rebuilding its configuration files at the same time that a phone requests its configuration file.

TFTP Configuration Checklist

Table 9-2 lists the steps that are needed to configure the Cisco TFTP service.

Table 9-2 TFTP Configuration Checklist

Configuration Steps
Procedures and Related Topics

Step 1 

Activate and start the TFTP service on at least one server in the cluster.

Cisco Unified CallManager Serviceability Administration Guide

Step 2 

Configure the appropriate service parameters, including the Alternate File Location parameters, if appropriate.

Service Parameters Configuration, Cisco Unified CallManager Administration Guide

Step 3 

If security is required in a noncentralized TFTP environment, configure the CTL file for all servers in the cluster. If security is required in a centralized TFTP environment, configure the CTL file for all servers in the cluster in addition to the Master TFTP Server.

Cisco Unified CallManager Security Guide

Step 4 

If you change a non-configuration file such as RingList.xml, restart the TFTP service by using Control Center in Serviceability.

Cisco Unified CallManager Serviceability Administration Guide

Where to Find More Information

Related Topic

Service Parameters Configuration, Cisco Unified CallManager Administration Guide

Additional Cisco Documentation

Cisco Unified Communications SRND Based on Cisco Unified CallManager Release 4.x