ソフトウェア管理の運用

マニュアルの変更履歴


(注)  


リリース 21.24 よりも前に導入された機能については、詳細な改訂履歴は示していません。


改訂の詳細

リリース

ソフトウェアリリースの N-4 下位互換性のためにサポートを拡張。

21.26

ソフトウェアリリースの N-3 下位互換性のためにサポートを拡張。

21.25

ソフトウェアリリースの N-2 下位互換性のためにサポートを拡張。

21.24.1

最初の導入。

21.24 より前

概要

CUPS は、コントロールプレーン(CP)およびユーザープレーン(UP)でのソフトウェアリリースの下位互換性をサポートしています。この機能により、1 つ前のリリース(N-1)、2 つ前のリリース(N-2)、3 つ前のリリース(N-3)、4 つ前のリリース(N-4)の間で、ソフトウェアをシームレスにアップグレードまたはダウングレードできます。この機能には、次のサポートが含まれます。

  • ICSR モードの 2 つの CP におけるソフトウェアリリースの N-1/N-2/N-3 /N-4 互換性:CP 1:1 冗長性シナリオで、CP をバージョン間でシームレスにアップグレードできます。

  • ICSR モードの 2 つの UP におけるソフトウェアリリースの N-1/N-2/N-3 /N-4 互換性:UP 1:1 冗長性シナリオで、UP をバージョン間でシームレスにアップグレードできます。

  • CP と UP 間のソフトウェアリリースの N-1/N-2/N-3/N-4 互換性:関連付けられた CP または UP をバージョン間でシームレスにアップグレードできます。

  • マルチ Sx を使用した CP と UP 間のソフトウェアリリースの N-1/N-2/N-3/N-4 互換性:マルチ Sx シナリオで、関連付けられた CP または UP をバージョン間でシームレスにアップグレードできます。


重要


ソフトウェアバージョンをアップグレードまたはダウングレードする前に、シスコのアカウント担当者に連絡して、手順に関するサポートを受けてください。


CP と UP 間のバージョン交換

CP と UP がペアになると、バージョンまたはリリース情報が交換されます。リリース情報は、アクティブとスタンバイの間で交換されるハートビートメッセージを介して、CP がスタンバイ CP とペアになったり、UP がスタンバイ UP とペアになったりする場合(1:1 冗長シナリオ)にも交換されます。

互換性のないリリースがペアリングされると、アラーム(SNMP トラップ)が発生します。詳細については、「SNMP トラップ」の項を参照してください。

リリース情報の交換中にピアバージョンを示すために、関連付け要求およびハートビート要求メッセージに次の新しい IE が含まれています。

情報要素

P

条件/コメント

IE の長さ

IE ID

ピアバージョン

O

ピア GR/PFCP バージョンと StarOS バージョンを指定するために使用されます。

4 バイト

245

ビット
オクテット 8 7 6 5 4 3 2 1
1 ~ 2 ピアバージョン IE タイプ = 245(10 進数)
3 ~ 4 長さ = n バイト
5 ~ 8 ピア GR/PFCP バージョン
9 ~ 12 StarOS GR バージョン
13 ~ 13 StarOS バージョン文字列長
可変長 StarOS バージョン文字列値

SNMP トラップ

互換性のないリリースとのペアリングが行われると、次の SNMP トラップが発生します。

SNMP トラップ 説明
SRPPeerUnsupportedVersion 上位バージョンのアクティブ/スタンバイ CP/UP は、ピアのバージョンが N-4 よりも下位の場合に SNMP トラップを発生させます。
SRPPeerUnsupportedVersionClear 上位バージョンのアクティブ/スタンバイ CP/UP は、SNMP トラップを発生させて SRPPeerUnsupportedVersion をクリアします。
SxPeerUnsupportedVersion 上位バージョンの CP/UP は、ピアのバージョンが N-4 よりも下位の場合に SNMP トラップを発生させます。
SxPeerUnsupportedVersionClear 上位バージョンの CP/UP は、SNMP トラップを発生させて SxPeerUnsupportedVersion をクリアします。

制限事項

この機能には次の既知の制限事項があります。

  • ピアバージョンがサポートされている N-4 バージョンよりも低いと判断された場合、関連付けとペアリングが許可されますが、同じ機能の側面は保証されません。


    注意    


    互換性のないバージョンからはアップグレードしないでください。アップグレードパスや手順については、シスコのアカウント担当者にお問い合わせください。


    SNMP トラップは、StarOS バージョンに関しては最新バージョンのノードによって発生します。詳細については、この章の「SNMP トラップ」の項を参照してください。

  • リリース 21.24.1 以降、RCM はチェックポイントに依存せず、将来の UP リリースのサポートを可能にします。現在、RCM は N-4 互換性をサポートしておらず、N-1 互換性のみをサポートしています。

CP および UP のアップグレードまたはダウングレード

次のメンテナンス操作手順(MOP)では、コントロールプレーンとユーザープレーンを以前のリリース(N-1)/(N-2)/(N-3)/(N-4)から最新の N リリースにアップグレードするか、または逆にダウングレードするために必要な手順の概要を示します。


重要


ソフトウェアバージョンをアップグレードまたはダウングレードする前に、シスコのアカウント担当者に連絡して、手順に関するサポートを受けてください。


アップグレードオプションは次のとおりです。

  • [Only CP Upgrade]:CP のみをアップグレードし、UP はそのままにする必要がある場合。

  • [Only UP Upgrade]:UP のみをアップグレードし、CP はそのままにする必要がある場合。

  • [Both CP and UP Upgrade]:CP と UP の両方をアップグレードする必要がある場合。この場合、最初に CP をアップグレードしてから UP をアップグレードするか、その逆を行います。

正常性チェック

シャーシのアップグレード、ダウングレード、またはリロードの各操作の後に、次の正常性チェックを実行します。

  1. アクティブシャーシのサービス冗長性プロトコル(SRP)情報を確認して、SRP スイッチオーバー中の問題を回避し、SRP スイッチオーバーの前にプロアクティブな分析の実施が必要かどうかを判断します。次の CLI コマンドを使用します。

    • srp validate-configuration srp validate-switchover

    • show srp info

    次に、出力例を示します。

    Peer Configuration Validation: Complete
    Last Peer Configuration Error: None
    Last Peer Configuration Event: Wed Mar 18 15:34:02 2019  (1602 seconds ago)
    Last Validate Switchover Status: None
    Connection State: Connected

    次のパラメータを確認します。

    • Peer Configuration Validation: Complete:[In Progress] と表示されている場合は、15 秒ほど待ってから show srp info を再度実行する必要があります。

    • Last Peer Configuration Error: None:[Peer Checksum Validation Failure] と表示された場合は、アクティブシャーシとスタンバイシャーシ間で設定に相違があり、修正が必要であることを示しています。

    • Last Validate Switchover Status: None:出力に [None] と表示される必要があります。また、srp validate-configuration および srp validate-switchover CLI コマンドがトリガーされると、出力は [Remote Chassis - Ready for Switchover (XX seconds before)] になります。

    • Connection State: Connected:出力に [Connected] と表示される必要があります。

  2. アクティブシャーシとスタンバイシャーシの両方のサブスクライバ数を確認します。

    セッションが起動したら、アクティブシャーシで show subscribers summary | grep Total CLI コマンドを実行します。次に、出力例を示します。

    show subscribers summary | grep Total 
       Total Subscribers:  100

    スタンバイシャーシで、show srp checkpoint statistics | grep allocated CLI コマンドを実行します。次に、出力例を示します。

    show srp checkpoint statistics | grep allocated 
       Current pre-allocated calls:  100
  3. show license information CLI コマンドを実行して、ライセンスのステータスを確認します。ステータスは [Expired] ではなく、[Good (Redundant)] である必要があります。

  4. show session recovery status verbose CLI コマンドを実行して、セッション リカバリ ステータスを確認します。次に、出力例を示します。

    Session Recovery Status:
      Overall Status        : Ready For Recovery
      Last Status Update    : 7 seconds ago
    
                  ----sessmgr---  ----aaamgr----  demux
     cpu state    active standby  active standby  active  status
    1/0  Active     8      1        8      1        17     Good
  5. show srp checkpoint statistics | grep Sessmgrs CLI コマンドを実行して、スタンバイシャーシのすべての SessMgr が [Standby-Connected] 状態であることを確認します。次に、出力例を示します。

    Number of Sessmgrs:        1
    Sessmgrs in Active-Connected state:  0
    Sessmgrs in Standby-Connected state: 8
    Sessmgrs in Pending-Active state:    0
  6. すべてのカードのステータスを確認して、[Active] 状態か [Standby] 状態かを確認します。次に、出力例を示します。

    show card table
    
    Slot          Card Type              Oper State  SPOF  Attach
    ----------- ------------------------ ----------- ----- ------
    1: VC        5-Port Virtual Card     Active        -
  7. show task resources | grep -v good CLI コマンドを実行します。出力には SessMgr とセッションの合計数のみが表示される必要があります。

  8. show crash list CLI コマンドを実行して、新しいクラッシュがあったかどうかを確認します。

  9. show service all CLI コマンドを実行して、状態が [Initialized] ではなく [Started] と表示されていることを確認します。

ビルドアップグレード

Backup Configuration

  1. 現在の設定をバックアップし、現在の設定を保存します。バックアップは、ダウングレード時に使用されます。ダウングレードには、現在までのすべての機能と設定が含まれている可能性があります。

  2. 変更またはアップグレードを実行する前に、アクティブシャーシとスタンバイシャーシの両方で show support details を収集します。

  3. ヘルスチェックを実行します。

アップグレード手順

  1. 両方のノードでシャーシのヘルスチェックを実行します。

  2. スタンバイ状態のセカンダリシャーシ(ICSR)で、起動優先順位を N ビルドに変更します。

  3. 最新の 21.xx.xx ビルドにリロードします。

  4. スタンバイシャーシで新しい設定の変更を行います(たとえば、新しい CLI、ライセンス、または設定の変更)。

  5. リロードされたシャーシでヘルスチェックを実行します。クラッシュやエラーを確認します。

スイッチオーバーの実行

  1. 両方のシャーシで SRP をアクティブからスタンバイに切り替える前に、以下の点を確認します。

    1. アクティブシャーシ:show subscriber summary | grep Total

    2. スタンバイシャーシ:show srp checkpoint statistics | grep allocated


      (注)  


      カウントは両方で同じである必要があります。
    3. アクティブおよびスタンバイシャーシ:show sx peer

      次に例を示します。

      |||||  Sx Service                                               No of
      |||||  ID                                                                Restart
      |||||  |                                               Recovery              |    Current    Max        Peer
      vvvvv  v     Group Name    Node ID         Peer ID     Timestamp             v    Sessions   Sessions   State   
      ----- ---- ----------------- ------------------------- ------------------- ------ --------- --------- -------- 
      CAAXD  22    CPGROUP21   209.165.200.225   50331649    2021-03-17:02:33:55    0        0          0      NONE     
      
      Total Peers:    1
      

      (注)  


      ピアの状態はアクティブであり、関連付けられている必要があります。ピア ID は両方のシャーシで一致する必要があります。
    4. スタンバイシャーシ:show srp checkpoint statistics | grep Sessmgrs


      (注)  


      「Number of Sessmgrs」は「Sessmgrs in Standby-Connected state」と同じである必要があります。
    5. アクティブシャーシ:

      1. srp validate-configuration :この CLI コマンドは、アクティブシャーシから設定検証チェックを開始するコマンドです。エラーがない場合、この CLI コマンドの出力は空白になります。

      2. srp validate-switchover :アクティブシャーシとスタンバイシャーシの両方で計画した SRP スイッチオーバーの準備ができていることを検証します。スイッチオーバーの準備ができている場合、この CLI コマンドの出力は空白になります。

      3. show srp info | grep "Last Validate Switchover Status" :この CLI コマンドの出力は次のようになります。

        Last Validate Switchover Status: Remote Chassis - Ready for Switchover
      4. show srp info debug :アクティブシャーシとスタンバイシャーシの出力は同じである必要があります。

  2. アクティブシャーシ:srp initiate-switchover

    1. 両方のノードでシャーシのヘルスチェックを実行します。また、「スイッチオーバーの実行」の項のステップ 1a とステップ 1c を確認します。5% の差が生じる場合があります。

    2. 新しいセッションは新しいアクティブシャーシで処理されるため、コールテストを実行します。

    3. 「アップグレード手順」の項のステップ 2 からステップ 5 で説明されているように、古いアクティブシャーシをアップグレードします。

CP のアップグレード

ここでは、CP のみを対象にアップグレード手順を説明します。

  1. 正常性チェックの項の説明に従って、両方の CP ノードで正常性チェック手順を実行します。

  2. ビルドアップグレードの項の説明に従って、スタンバイ CP でアップグレードを実行します。


    (注)  


    CP と UP のコンテキスト名が異なる場合は、アップグレードされた CP で debug pgw pfd-mgmt CLI コマンドを実行してからアクティブにします。


  3. 両方のシャーシで正常性チェックを実行し、アップグレードされたシャーシに CP スイッチオーバーを実行します。

  4. 新しいシャーシが新しいセッションを取得していること、新しいクラッシュがないこと、またはエラーシナリオによるセッションのドロップがないことを確認します。CP と UP の両方で正常性チェックを実行します。

  5. ビルドアップグレードの項の説明に従って、新しいスタンバイ CP をアップグレードします。

UP のアップグレード

ここでは、UP のみを対象にアップグレード手順を説明します。

  1. 正常性チェックの項の説明に従って、両方の UP ノードで正常性チェック手順を実行します。

  2. ビルドアップグレードの項の説明に従って、スタンバイ UP でアップグレードを実行します。

  3. アップグレードされたスタンバイシャーシで「sx-peer configuration」を実行します。

  4. 両方の UP ノードで正常性チェックを実行してから、UP スイッチオーバーを実行します。

  5. ビルドアップグレードの項の説明に従って、新しいスタンバイ UP をアップグレードします。

CP および UP のアップグレード

ここでは、最初に CP をアップグレードしてから UP をアップグレードする手順、またはその逆の手順について説明します。

CP を最初にアップグレードする場合

  1. 正常性チェックの項の説明に従って、CP と UP の両方で正常性チェック手順を実行します。

  2. ビルドアップグレードの項の説明に従って、スタンバイ CP でアップグレードを実行します。


    (注)  


    CP と UP のコンテキスト名が異なる場合は、アップグレードされた CP で debug pgw pfd-mgmt CLI コマンドを実行してからアクティブにします。


  3. ビルドアップグレードの項の説明に従って、スタンバイ UP でアップグレードを実行します。

  4. スタンバイ CP と UP の両方を N ビルドにアップグレードします。

  5. 両方のシャーシで正常性チェックを実行し、アップグレードされたシャーシへの CP スイッチオーバーを実行します。

  6. 新しいシャーシが新しいセッションを取得していること、新しいクラッシュがないこと、またはエラーシナリオによるセッションのドロップがないことを確認します。

  7. 両方の UP ノードで正常性チェックを実行してから、UP スイッチオーバーを実行します。

  8. 新しくアクティブになった UP で正常性チェックを実行します。コールのドロップがなく、データが新しいシャーシを通過していることを確認します。

  9. ビルドアップグレードの項の説明に従って、新しいスタンバイ CP と UP をアップグレードします。

UP を最初にアップグレードする場合

  1. CP と UP の両方で正常性チェックとビルド転送手順を実行します。

  2. ビルドアップグレードの項の説明に従って、スタンバイ UP でアップグレードを実行します。

  3. アップグレードされたスタンバイシャーシで「sx-peer configuration」を実行します。

  4. 両方の UP ノードで正常性チェックを実行してから、UP スイッチオーバーを実行します。

  5. ビルドアップグレードの項の説明に従って、新しいスタンバイ UP でアップグレードを実行します。

  6. ビルドアップグレードの項の説明に従って、スタンバイ CP でアップグレードを実行します。

  7. 両方の CP ノードで正常性チェックを実行してから、CP スイッチオーバーを実行します。


    (注)  


    CP と UP のコンテキスト名が異なる場合は、CP で debug pgw pfd-mgmt CLI コマンドを実行します。


  8. 新しいスタンバイ CP シャーシをアップグレードします。正常性チェックを実行します。

  9. アクティブ UP とスタンバイ UP の両方で正常性チェックを実行します。

  10. すべてが想定どおりに機能している場合は、最初にスタンバイ CP で設定の変更を行います。次に、アクティブ CP で同様の変更を行い、push config-to-up all CLI コマンドを実行します。新しい変更内容は、新しいアクティブ UP にプッシュされます。

ダウングレード手順

ダウングレード:CP と UP の両方

アップグレードの一環として CP で新しい設定や設定変更が必要な場合は、まず UP のアップグレード手順に従います。

  1. CP と UP の両方で正常性チェックを実行します。

  2. スタンバイ UP でブートの優先順位を N-1/N-2/N-3/N-4 ビルドに変更します。スタンバイ UP をリロードします。

  3. ダウングレードされたスタンバイ UP で「sx-peer configuration」を実行します。

  4. 両方の UP ノードで正常性チェックを実行してから、UP スイッチオーバーを実行します。

  5. 新しいスタンバイ UP でステップ 1 ~ 3 を実行します。

  6. スタンバイ CP でブートの優先順位を N-1/N-2/N-3/N-4 ビルドに変更します。スタンバイ CP をリロードします。


    (注)  


    CP と UP のコンテキスト名が異なる場合は、CP で debug pgw pfd-mgmt.. CLI コマンドを実行します。
  7. ビルドアップグレードの「バックアップの設定」の項に記載されているステップ 1 で保存した設定をロードします。

  8. 両方の CP ノードで正常性チェックを実行してから、CP スイッチオーバーを実行します。

  9. ステップ 6 と 7 を実行して古いアクティブノードをダウングレードします。

  10. アクティブ CP で、push config-to-up all CLI コマンドを実行して、設定の変更が UP にプッシュされるようにします。

ダウングレード:CP のみ

ダウングレード:CP と UP の両方 」の項に記載されているステップ 6 ~ 10 を実行します。

ダウングレード:UP のみ

ダウングレード:CP と UP の両方 」の項に記載されているステップ 1 ~ 5 を実行します。