Proxy TFTP Deployment Overview
Use a proxy Trivial File Transfer Protocol (TFTP) server to provide the configuration files that endpoints in your network need, such as: dial plans, ringer files, and device configuration files. A TFTP server can be installed in any cluster in your deployment and can service requests from endpoints on multiple clusters. The DHCP scope specifies the IP address of the proxy TFTP server to use to get the configuration files.
Redundant and Peer Proxy TFTP Servers
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.
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.
In multi-cluster systems, the proxy TFTP service is able provide TFTP files from multiple clusters via a single primary TFTP server. The proxy TFTP can serve as a single TFTP reference for scenarios where a single subnet or VLAN contains phones from multiple clusters or in any scenario where multiple clusters share the same DHCP TFTP option (150).
The Proxy TFTP service functions as a single-level hierarchy is as illustrated. More complicated multi-level hierarchies are not supported.
In the above illustration, a group of devices contacts the Primary TFTP server for their configuration files. When it receives a request for TFTP from a device, the primary TFTP looks into its own local cache for the configuration file as well as any other remotely configured clusters such as Remote Cluster A, B, C, or N (any other remote clusters configured).
It is possible to configure any number of remote clusters on the primary TFTP server; however, each remote cluster may contain only up to 3 TFTP IP addresses. The recommended design for redundancy is 2 TFTP servers per cluster, and thus 2 IP addresses per remote cluster on the Primary TFTP server for redundancy.
Use Cases and Best Practices
Consider the following scenarios that detail how Proxy TFTP can be used and the best practices for implementation.
The cluster can act as just a proxy TFTP cluster with no other purpose. In this case, the cluster has no relationship with the other clusters, and does not process calls. For this scenario, the Remote Cluster TFTP is manually defined and rollback to pre-8.0 is recommended.
Autoregistration will not work in this scenario.
The cluster is a remote cluster that is also acting as a Proxy TFTP server for remote clusters. The remote cluster is manually defined, and Autoregistration should not be enabled.
TFTP Support for IPv4 and IPv6 Devices
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.
Endpoints and Configuration Files for TFTP Deployments
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.
Security Considerations for Proxy TFTP
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:
Add Phone details to Remote Cluster B (destination cluster).
Delete Phone details from Remote Cluster A (source cluster).
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.
Reset Phones to download configuration files from Remote Cluster B and register to Remote Cluster B.