単一クラスタの導入では、クラスタは少なくとも 1 つのプロキシ TFTP サーバを備えている必要があります。 冗長性を確保するために、クラスタに別のプロキシ TFTP サーバを追加することができます。 2 台目のプロキシ TFTP サーバは、IPv4 のオプション 150 に追加されます。 IPv6 の場合、第 2 TFTP サーバを、DHCP スコープの TFTP サーバ アドレスサブオプションタイプ 1 に追加します。

複数のクラスタ展開では、最大 3 台のリモートプロキシ TFTP サーバをプライマリプロキシ TFTP サーバのピアクラスタとして指定できます。 これは、複数の DHCP スコープに対して 1 台のプロキシ TFTP サーバだけを設定する場合、または 1 つの DHCP スコープのみを設定する場合に便利です。 プライマリプロキシ TFTP サーバは、ネットワーク内のすべての電話機とデバイスに設定ファイルを提供します。

各リモートプロキシ TFTP サーバとプライマリプロキシ TFTP サーバの間にピア関係を作成する必要があります。

ヒント	ネットワーク内のリモートプロキシ TFTP サーバ間にピア関係を設定する場合は、関係を階層構造にしておきます。 ループの発生を回避するために、リモートクラスタ上のピアプロキシ TFTP サーバが相互にポイントしないようにします。 たとえば、プライマリノード A にノード B と C のピアリレーションシップがあるとします。ノード B と C の間にピア関係を作成しないでください。作成すると、ループが作成されます。

IPv4 の電話機とゲートウェイで DHCP カスタムオプション 150 を使用して、TFTP サーバの IP アドレスを検出することを推奨します。 オプション 150 を使用すると、ゲートウェイと電話機は TFTP サーバの IP アドレスを検出します。 詳細については、デバイスに同梱されているマニュアルを参照してください。

IPv6 ネットワークでは、Cisco ベンダー固有の DHCPv6 情報を使用して、TFTP サーバ IPv6 アドレスをエンドポイントに渡すことを推奨します。 この方式では、TFTP サーバの IP アドレスをオプション値として設定しています。

IPv4 を使用するエンドポイントと IPv6 を使用するエンドポイントがある場合は、IPv4 には DHCP カスタム オプション 150 を、IPv6 には Cisco ベンダー固有情報オプションである TFTP サーバアドレスのサブオプションタイプ 1 を使用することをお勧めします。 TFTP サーバが IPv4 を使用して要求を処理しているときに、エンドポイントが IPv6 アドレスを取得して要求を TFTP サーバに送信した場合、TFTP サーバは IPv6 スタックで要求を受信していないため、その要求を受信しません。 この場合、エンドポイントを Cisco Unified Communications Manager に登録できません。

IPv4 および IPv6 デバイスが TFTP サーバの IP アドレスを検出するために使用できる別の方法があります。 たとえば、IPv4 デバイスに DHCP オプション 066 または CiscoCM1 を使用できます。 IPv6 デバイスの場合、他の方法として、TFTP サービスのサブオプションタイプ 2 を使用する方法と、エンドポイントで TFTP サーバの IP アドレスを設定する方法があります。 これらの代替手段は推奨されません。 代替手段を使用する前に、シスコのサービス プロバイダーに問い合わせてください。

SCCP 電話機、SIP 電話およびゲートウェイは、初期化時に設定ファイルを要求します。 デバイス設定を変更すると、更新された設定ファイルがエンドポイントに送信されます。

設定ファイルには、Unified Communications Managerノードの優先順位リスト、これらのノードに接続するために使用される TCP ポート、さらに他の実行可能ファイルが含まれます。 一部のエンドポイント用の設定ファイルには、電話機のボタン（メッセージ、ディレクトリ、サービス、および情報）用のロケール情報および URL が保存されています。 ゲートウェイ用の設定ファイルには、デバイスが必要とする設定情報がすべて保存されています。

シスコ プロキシ TFTP サーバは、署名付きの要求と署名されていない要求の両方を処理でき、セキュアでないモードと混在モードのいずれでも動作できます。 プロキシ TFTP サーバは、電話機がファイルをリクエストし、見つからない場合は、リモート クラスタにリクエストを送信するときに、ローカル ファイル システムまたはデータベースを検索します。 電話が ringlist.xml.sgn、ロケールファイルなどの名前の共通ファイルをサーバにリクエストすると、サーバは電話のホームクラスタからファイル自体ではなくファイルのローカルコピーを送信します。

プロキシ TFTP からファイルを受信すると、ファイルにプロキシサーバの署名があり、電話の初期信頼リスト（ITL）と一致しないことから、署名の検証に失敗するため、電話はファイルを拒否します。 この問題を解決するには、電話機のセキュリティ デフォルト (SBD) セキュリティを無効にするか、プロキシ TFTP の CallManager 証明書を新しい(リモート/ホーム) クラスタの phone-sast-trust にインポートします。　 その後、電話機は Trust Verification Service (TVS) に到達し、プロキシ TFTP 認証を信頼できます。 導入で EMCC が有効になっている場合は、一括証明書の交換が必要です。

デフォルトでセキュリティを無効にするには、Cisco Unified Communications Manager セキュリティガイドの「Cisco Unified IP Phone の ITL ファイルの更新」セクションを参照してください 。

混在モードのプロキシ TFTP

混在モードで実行されているリモート クラスタ上の TFTP サーバには、シスコ証明書信頼リスト (CTL) ファイルにプライマリ プロキシ TFTP サーバ証明書を追加する必要があります。 そうでない場合、セキュリティが有効になっているクラスタに登録されているエンドポイントは、必要なファイルをダウンロードできなくなります。 証明書の一括インポートエクスポートを実行した後、この更新 CTL ファイルを実現するには。

詳細については、IP 電話をクラスタ間で移行して一括証明書のエクスポートを実行する場合、Cisco Unified Communications Manager セキュリティガイドの「一括証明書のエクスポート」セクションを参照してください。

プロキシ TFTP 環境内のクラスタ間での電話機の移動

プロキシ TFTP 環境のリモート クラスタ間で電話機を移動する場合は、次の手順を実行します。

1. リモート クラスタ B (宛先クラスタ) に電話機の詳細を追加します。

2. リモート クラスタ A (送信元クラスタ) から電話機の詳細を削除します。

   （注）	プロキシTFTPでの電話機の設定は、期限切れになるまで 30 分あります。 ファイルが見つからない応答を避けるために、プロキシ クラスタの TFTP サービスを再起動します。

3. 電話機をリセットしてリモート クラスタ B から設定ファイルをダウンロードし、リモート クラスタ B に登録します。