In a single cluster deployment, the cluster must have at least one proxy TFTP server. You can add another proxy TFTP server to the cluster for redundancy. The second proxy TFTP server is added in option 150 for IPv4. For IPv6, you add the second proxy TFTP server to TFTP Server Addresses sub-option type 1 in the DHCP scope.

In a multiple cluster deployment, you can specify up to three remote proxy TFTP servers as peer clusters of the primary proxy TFTP server. This is useful if you want to configure only one proxy TFTP server for many DHCP scopes, or have only one DHCP scope. The primary proxy TFTP server provides the configuration files for all phones and devices in the network.

You must create a peer relationship between each remote proxy TFTP server and the primary proxy TFTP server.

Tip

When you configure peer relationships between the remote proxy TFTP servers in your network, keep the relationships hierarchical. Ensure that the peer proxy TFTP servers on the remote clusters do not point to each other to avoid possible looping. For example, if the primary node A has a peer relationship with nodes B and C. You should not create a peer relationship between nodes B and C. If you do, then you have created a loop.

We recommend that you enable IPv4 phones and gateways to use the DHCP custom option 150 to discover the TFTP server IP address. Using option 150, gateways and phones discover the TFTP server IP address. For more information, see the documentation that came with your device.

In an IPv6 network, we recommend that you use the Cisco vendor-specific DHCPv6 information to pass the TFTP server IPv6 address to the endpoint. With this method, you configure the TFTP server IP address as the option value.

If you have some endpoints that use IPv4 and some that use IPv6, we recommend that you use DHCP custom option 150 for IPv4 and use the TFTP Server Addresses sub-option type 1, a Cisco vendor-specific information option, for IPv6. If the endpoint obtains an IPv6 address and sends a request to the TFTP server while the TFTP server is using IPv4 to process requests, the TFTP server does not receive the request because the TFTP server is not listening for the request on the IPv6 stack. In this case, the endpoint cannot register with Cisco Unified Communications Manager.

There are alternative methods that you could use for your IPv4 and IPv6 devices to discover the IP address of the TFTP server. For example, you could use DHCP option 066 or CiscoCM1 for your IPv4 devices. For your IPv6 devices, other methods include using TFTP Service sub-option type 2 or configuring the IP address of the TFTP server on the endpoint. These alternative methods are not recommended. Consult your Cisco service provider before using any alternative methods.

SCCP phones, SIP phones and gateways, request a configuration file when they initialize. An updated configuration file gets sent to the endpoint whenever you change the device configuration.

The configuration file contains information such as a prioritized list of Unified Communications Manager nodes, the TCP ports used to connect to those nodes, as well other executables. For some endpoints, the configuration file also contains locale information and URLs for phone buttons, such as: messages, directories, services, and information. Configuration files for gateways contain all the configuration information that the device requires.

Cisco Proxy TFTP servers handle both signed and unsigned requests and run in either nonsecure mode or mixed mode. The Proxy TFTP Server searches the local file system or database when a phone requests for a file and if not found, sends a request to remote clusters. When the phone requests the server for a common file with names such as ringlist.xml.sgn, locale file, and so on, the server sends a local copy of the file instead of the file itself from the home cluster of the phone.

When receiving files from Proxy TFTP, the phone rejects the file due to a signature verification failure because the file has the signature of the proxy server which doesn't match the Initial Trust List (ITL) of the phone. To resolve this issue, you can either disable Security By Default (SBD) for the Phone or import Proxy TFTP's callmanager certificate to new (remote/home) clusters phone-sast-trust. Then the phones can reachout to Trust Verification Service (TVS) and trust the Proxy TFTP certificats. Bulk certificate exchange is needed if EMCC is enabled on the deployment

To disable Security by Default, see "Update ITL File for Cisco Unified IP Phones" section the Security Guide for Cisco Unified Communications Manager.

Proxy TFTP in Mixed Mode

TFTP servers on remote clusters that are running in mixed mode must have the primary Proxy TFTP server certificates added to their Cisco Certificate Trust List (CTL) file. Otherwise, endpoints that are registered to a cluster where security is enabled will be unable to download the files that they need. To achieve this update CTL file after performing bulk import-export of certificates.

For more information, see "Bulk Certificate Export" section in the Security Guide for Cisco Unified Communications Manager when migrating IP phones between clusters to perform the bulk certificate export.

Moving Phones Between Clusters in Proxy TFTP Environment

When moving phones from one Remote Cluster to another in a Proxy TFTP environment, perform the following:

1. Add Phone details to Remote Cluster B (destination cluster).

2. Delete Phone details from Remote Cluster A (source cluster).

   Note	The phone's configuration in the Proxy TFTP takes 30 minutes to expire. To avoid any file not found response, you can restart Proxy Cluster's TFTP services.

3. Reset Phones to download configuration files from Remote Cluster B and register to Remote Cluster B.