ソフトウェア管理の運用

この章では、システム上のソフトウェア管理の運用について説明します。

ローカルファイルシステムの概要

管理入出力（MIO/UMIO）カードは、システムの制御と管理を提供します。

ローカルファイルシステムは、次の 1 つ以上に保存されているファイルで構成されます。

  • /flash：MIO/UMIO の回路基板にあるフラッシュメモリは、システムによって使用されるオペレーティングシステムのソフトウェアイメージ、CLI 設定、およびクラッシュログファイルのデフォルトのストレージメディアです。

  • /usb1：このデバイスは、USB メモリスティックがアクティブな MIO/UMIO の前面パネルに挿入されている場合に使用できます。

  • /hd-raid：これは、ファブリックおよびストレージカード（FSC）によってサポートされ、アクティブな MIO/UMIO を介してアクセスされる、ソリッドステートのハードディスクアレイです。

VPC VM 上のローカルファイルシステムは、次のものに保存されているファイルで構成されます。

  • /flash ハイパーバイザを介して M 上の vHDD-1 として割り当てられたフラッシュメモリは、システムで使用される StarOS イメージ、CLI 設定、およびクラッシュログファイルのデフォルトのストレージメディアです。

  • /hd-raid これは、ハイパーバイザによって CF VM 上で vHDD-2 として割り当てられたストレージ領域です。CDR（課金データレコード）と UDR（使用データレコード）を保存するために使用されます。

ローカルファイルシステムで使用されるファイルタイプ

ローカルファイルシステムには、次のファイルタイプを配置できます。

  • オペレーティング システム ソフトウェアのイメージファイル：このバイナリファイルタイプは .bin 拡張子で識別されます。ファイルは、起動時またはリロード時にシステムによってロードされるオペレーティングシステムです。これは、エンドユーザーが変更できない実行可能な読み取り専用ファイルです。

  • CLI 設定ファイル：このファイルタイプは .cfg 拡張子によって識別されます。これらは、オペレーティングシステムのソフトウェアイメージと連携して動作する CLI コマンドを含むテキストファイルです。これらのファイルによって、提供されるサービス、ハードウェアとソフトウェアの設定、システムによって実行されるその他の機能が決まります。通常、ファイルはエンドユーザーが作成します。ファイルはオンラインでも、オフラインでも変更でき、そのファイルを説明する長いファイル名を使用します。

  • システムファイル：システムでは、.sys 拡張子によって識別されるファイル 1 つのみが使用されます。boot.sys ファイルには、システムの検出方法や、起動スタックからファイルグループ（.bin ファイルと .cfg ファイルのペア）をロードする優先順位を説明するシステム固有の情報が含まれています。

  • クラッシュログの要約：ファイル名の crashlog で識別されるクラッシュログの要約には、システムで発生したソフトウェアまたはハードウェアの障害に関するサマリー情報が含まれています。このファイルは、デバイスの /flash/crsh2/ ディレクトリにあります。CLI を使用してこのファイルの内容を表示することはできますが、ファイルを変更することはできません。

boot.sys ファイルの概要

システムは boot.sys ファイルを使用して、システムが起動時に使用する優先順位付けされた起動スタックパラメータとファイルグループを保存します。このファイルは、外部手段ではなく、システム CLI コマンドを使用してのみ変更できます。起動パラメータには、オペレーティングシステムのイメージファイルを見つけるために必要な次のような情報が含まれています。

  • bootmode：この設定は通常は normal に設定され、システムの起動方法を識別します。

  • network interface configuration：MIO/UMIO カード上の管理 LAN インターフェイスのいずれかを使用している外部ネットワークサーバーからオペレーティングシステムのイメージを取得するようにシステムを設定する場合は、これらのオプションの起動方式の設定を使用します。

  • 起動スタック情報：起動スタックは、オペレーティングシステムのイメージファイルと、ロードする CLI 設定ファイルを指定する、優先順位付けられたファイルグループエントリから構成されます。

システムを初めて起動したときに、通常の起動モードを使用して、/flash ディレクトリからオペレーティングシステムのソフトウェアイメージをロードするように、boot.sys ファイルが設定されます。

ローカルファイルシステムには CLI 設定ファイルが含まれていません。これにより、システムは最初に正常に起動したときに自動的に CLI ベースのクイック セットアップ ウィザードを開始します。クイック セットアップ ウィザードの使用方法の詳細については、「使用する前に」を参照してください。

ローカルファイルシステムの保守

ローカルファイルシステムを構成するデバイスを管理および保守するには、CLI コマンドを使用します。この項で説明されているすべてのコマンドは Exec モードで実行します。特に指定がない限り、これらのコマンドを実行するには、セキュリティ管理者または管理者の権限が必要です。

ファイルシステム管理コマンド

ローカルファイルシステムを管理および構成するには、この項のコマンドを使用します。


重要

次に示すコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

ファイルシステムの同期

ローカルファイルシステムを 2 枚のカードを搭載したシステムのアクティブ MIO/UMIO からスタンバイ MIO/UMIO にミラーリングするためのコマンドがサポートされています。これらのコマンドを使用して、ローカルデバイスのいずれか、またはすべてを同期します。


重要

クラッシュログファイルは、これらのコマンドが実行されても同期されません。

次の Exec モードコマンドは、2 つの MIO/UMIO 間でファイルシステムを同期します。 
[local]host_name# filesystem synchronize [ /flash | /usb1 | all ] [ checkonly ] [ from card_num | to card_num ] [ -noconfirm ]

一致するローカルデバイス上のファイルシステムのみが同期されます。たとえば、アクティブ MIO/UMIO に 2 台のローカルデバイス（/flash と/usb1）が含まれており、スタンバイ MIO/UMIOに 1 台のローカルデバイス（/flash）のみが含まれている場合は、一致するローカルデバイス（/flash）のみで同期が行われます。

次のコマンドは、2 つの MIO/UMIO フラッシュデバイス上のファイルシステムを同期します。 
[local]host_name# filsystem synchronize /flash

ディレクトリの作成

特定のローカルデバイスに新しいディレクトリを作成するには、mkdir コマンドを使用します。このディレクトリは、ローカルファイルシステムにある任意のファイルのパス名の一部として組み込むことができます。 

[local]host_name# mkdir { /flash | /usb1 | /hd-raid } /dir_name

次のコマンドを使用して、configs という名前のディレクトリを作成します。 

[local]host_name# mkdir /flash/configs

ファイルとディレクトリの名前の変更

ファイルの名前を元の名前から別の名前に変更するには、rename コマンドを使用します。必要に応じて同じファイル拡張子を使用し、ファイルタイプが変更されないようにします。 

[local]host_name# rename { /flash | /usb1 | /hd-raid } /src_filename { /flash | /usb1 | /hd-raid } /dst_filename [ -noconfirm ]]

/flash ローカルデバイス上でファイル名 iot_test.cfg を iot_accept.cfg に変更するには、次のコマンドを使用します。 

[local]host_name# rename /flash/iot_test.cfg /flash/iot_accept.cfg -noconfirm

重要

rename コマンドは、同じローカルデバイス内でのみ使用します。ファイル名を変更して、そのファイルを別のローカルデバイスに同時に配置することはできません。名前を変更したファイルを移動するには、copy コマンドを使用する必要があります。

ファイルのコピー

これらの手順は、Exec モードのルートプロンプトを使用していることが前提になります。現在の設定を保存するには、次のコマンドを入力します。 

[local]host_name# copy from_url to_url [-noconfirm]

system.cfg という設定ファルを cfgfiles と呼ばれていたディレクトリから configs_old というディレクトリにコピーするには、次のコマンドを入力します。 

[local]host_name# copy /flash/cfgfiles/system.cfg /flash/configs_old/system_2011.cfg

simple_ip.cfg という設定ファイルを host_name_configs というディレクトリから、administrator というユーザ名でパスワードが secure のアカウントがある IP アドレス 192.168.34.156 の FTP サーバにコピーするには、次のコマンドを使用します。 

[local]host_name# copy /flash/host_name_configs/simple_ip.cfg ftp://administrator:secure@192.168.34.156/host_name_configs/ simple_ip.cfg

init_config.cfg という設定ファイルをホスト名が config_server の TFTP サーバーのルートディレクトリにコピーするには、次のコマンドを入力します。 

[local]host_name# copy /flash/cfgfiles/init_confg.cfg tftp://config_server/init_config.cfg

ファイルの削除

delete コマンドは、指定されたファイルをローカルファイルシステム上の指定された場所から削除します。


重要

このコマンドは、ワイルドカードエントリをサポートしていません。各ファイル名は、全体で指定する必要があります。


注意    

boot.sys ファイルは削除しないでください。削除すると、システムはコマンドを再起動せず、動作不能になります。 

[local]host_name# delete { /flash | /usb1 | /hd-raid }/filename [ -noconfirm ]

次のコマンドは、/flash ディレクトリから est.cfg という名前のファイルを削除します。 

[local]host_name# delete /flash/test.cfg

ディレクトリの削除

rmdir コマンドは、特定のローカルデバイス上の現在のディレクトリを削除します。このディレクトリは、ローカルファイルシステムにある任意のファイルのパス名の一部として組み込むことができます。


重要

削除するディレクトリは、rmdir コマンドを実行する前に空にしておく必要があります。ディレクトリが空でない場合、CLI には「Directory not empty」というメッセージが表示され、実行されません。 

[local]host_name# rmdir url /dir_name

次に、/flash ディレクトリ内の config という名前の空のディレクトリを削除するコマンドを示します。 

[local]host_name# rmdir /flash/configs

ローカルデバイスのフォーマット

format コマンドは、ローカルデバイスの低レベルフォーマットを実行します。この操作は、FAT16 フォーマット方式を使用するようにデバイスをフォーマットします。これは、オペレーティングシステムの適切な読み取り/書き込み機能に必要です。


重要

NTFS や FAT32 などの他の方式を使用してフォーマットされたローカルデバイスは、さまざまなオペレーティングシステム、CLI 設定、およびクラッシュログファイルを保存するために使用される場合があります。ただし、通常使用のために新しいローカルデバイスを MIO/UMIO に配置する場合は、使用する前にシステムを介してデバイスをフォーマットする必要があります。これにより、適切なファイル アロケーション テーブルのフォーマットが使用され、他のオペレーティングシステムで使用されている他のフォーマットとの不一致を防止することができます。


注意    

filesystem format コマンドは、デバイスに保存されているすべてのファイルと情報を削除します。

ローカルファイルシステムで使用するローカルデバイスをフォーマットするには、次のコマンドを入力します。 

[local]host_name# filesystem format { /flash | /usb1 | /hd-raid }

既存の CLI 構成ファイルの適用

既存の CLI 設定ファイルは、ユーティリティ機能（テスト時のすべての統計情報のクリアなど）を提供するために作成されたか、またはテキストエディアを使用してオフラインで作成された .conf ファイルです。既存の設定ファイルはローカルファイルシステムに保存されていることがあり、そのファイルはいつでも実行中のシステムに適用できます。


注意    

現在別の CLI 設定を実行しているシステムに設定ファイルを適用したすると、同じコマンドが適用しようとしている設定ファイルに存在する場合は、類似するコンテキスト、論理インターフェイス、物理ポート、IP アドレス、またはその他の設定済みの項目はすべて上書きされます。適用しようとしているファイルの内容を十分に理解し、現在実行中のコマンドが上書きされた場合はサービスにどのような影響があるかを把握しておく必要があります。また、変更は自動的に保存されないことにも注意してください。

CLI 設定ファイル、または CLI コマンドを含むスクリプトは、Exec モードプロンプトで次のコマンドを入力することによって実行中のシステムに適用できます。 

[local]host_name# configure url [ verbose ]

url は、適用する CLI 設定ファイルの場所を指定します。ローカルファイルまたはリモートファイルを参照する場合があります。

次のコマンドは、 /flash ディレクトリ内の clearcmds という名前の既存の CLI 設定ファイルを適用します。 

[local]host_name# configure /flash/clearcmds.cfg

ローカルファイルシステム上のファイルの表示

この項では、さまざまなファイルを表示する方法について説明します。

ローカルデバイスの内容の表示

任意のローカルデバイスのコンテンツ、使用状況情報、およびファイルシステムディレクトリ構造を表示するには、Exec モードプロンプトで次のコマンドを入力します。

directory { /flash | /usb1 | /hd-raid }

CLI 設定と boot.sys ファイルの表示

ローカルファイルシステムに格納されている CLI 設定ファイルと boot.sys ファイルの内容は、Exec モードのプロンプトで次のコマンドを入力することによって、オフラインで表示できます（OS にロードする必要はありません）。

[local]host_name# show file url { /flash | /usb1 | /hd-raid } filename

ここで、url はファイルの場所のパス名、filename は拡張子を含むファイルの名前を指します。


重要

オペレータレベルのユーザーとインスペクタレベルのユーザーは show file コマンドを実行できますが、 directory コマンドを実行することはできません。

オペレーティングシステムのファイルの検証

.bin 拡張子で識別されるオペレーティングシステムのソフトウェアイメージファイルは、システム上で実行され、ランタイムオペレーティングシステム（OS）を作成する、読み取り不可能かつ編集不可能なファイルです。

新しいオペレーティング システム イメージ ファイルをロードする前に確認することが重要です。これを実現するために、独自のチェックサムアルゴリズムを使用して、プログラムのコンパイル中に .bin ファイル内に保存されているアプリケーションの各部分のチェックサム値を作成します。

この情報は、コンパイル中にファイル内に保存されているチェックサム値に対して実際のファイルを検証するために使用できます。イメージファイルのいずれかの部分が破損した場合（たとえば、ファイルが切り捨てられた場合や、バイナリモードではなく ASCII モードを使用して転送された場合など）、この情報が報告され、ファイルは使用できないと見なされます。

オペレーティングシステムのソフトウェアイメージファイルを検証するには、Exec モードプロンプトで次のコマンドを入力します。 

[local]host_name# show version { /flash | /usb1 | /hd-raid } /[directory]/filename [all]
このコマンドの出力には、次の情報の列が表示されます。

  • バージョン番号

  • 説明

  • 日付

  • 起動イメージ

  • サイズ

  • フラグ

  • プラットフォーム

無効なファイルが見つかった場合、システムは次のようなエラーメッセージを表示します。 

Failure: Image /flash/image_version.bin CRC check failed! 
Failure: /flash/image_version.bin, has a bad magic number

Elastic Services Controller のクラウド初期化サポート

Elastic Services Controller（ESC）が QvPC-DI の制御機能（CF）にアクティブおよびスタンバイで Cinder マルチアタッチボリュームを使用する場合、仮想マシン（VM）オーケストレーション用に呼び出される Openstack API バージョンは 2.60 以上です。この API バージョンでは、ESC はセキュリティ上の理由から、構成ファイルをエンコードして VM に挿入します。VM はエンコードされた構成ファイルを読み取ることができないため、ESC は user_data 圧縮ファイルを使用します。この user_data ファイルには、VM の起動に必要な構成ファイルが含まれています。

起動スタックの設定

起動スタックは、オペレーティングシステムのソフトウェアイメージと CLI 設定ファイルとの関連付けに優先順位を付けたリストで構成されます。これらの関連付けによって、システムの起動時またはリロード/再起動時にロードされるソフトウェアイメージと設定ファイルが決まります。関連付けは複数設定できますが、システムが使用するのは最も高い優先順位を持つ関連付けです。この関連付けの処理中にエラーが発生した場合（いずれかのファイルが見つからないなど）、システムは次に高い優先順位の関連付けを使用しようとします。

VPC-SI プラットフォームと VPC-DI プラットフォームでは、設定されたブート優先順位が最も高い構成ファイルが利用できない場合（ただし、イメージファイルは利用可能）、システムは次に利用可能なブートシステムの優先順位を使用する代わりに、リロード後に設定ウィザードを使用して起動します。優先順位は 1 ～ 100 で、1 が最も高い優先順位です。boot.sys ファイル内に設定できる起動スタックエントリの最大数は 10 です。

起動スタック情報は、boot.sys ファイルの概要で説明されているように、boot.sys ファイルに含まれています。次の項で説明するように、boot.sys ファイルには、起動スタックエントリの他に、システムの起動方式を定義するために必要なすべての設定コマンドが含まれています。

システムの起動方式

ローカル起動方式では、システムにローカルに保存されているソフトウェアイメージと設定ファイルを使用します。システムの起動時または再起動時に、ローカルデバイスのいずれか、または /hd-raid で特定のソフトウェアイメージとそれに付随する設定テキストファイルを調べます。ローカル起動方式を使用している場合は、起動スタックパラメータの設定のみが必要です。

システムは、特定の外部ネットワークサーバーからシステムに存在する設定テキストファイルとペアになっているソフトウェアイメージを取得します。ネットワーク起動を使用する場合は、次を設定する必要があります。

  • 起動スタックパラメータ。これらは使用するファイルとそれらに使用する優先順位を定義します。

  • リモート管理 LAN インターフェイスを定義する起動インターフェイスおよびネットワークパラメータと、外部ネットワークサーバーに到達するために使用する方式

  • 確立するネットワーク通信を可能にするための遅延期間（秒単位）を定義するネットワーク起動遅延時間およびオプションのネームサーバーパラメータと、使用される可能性があるドメインネームサービス（DNS）ネームサーバーの IP アドレス

ネットワーク起動方式を使用するようにシステムを設定する方法の詳細については、を参照してください。 ネットワーク起動設定の要件

現在の起動スタックの表示

boot.sys ファイルに含まれている起動スタックのエントリを表示するには、Exec モードの show boot コマンドを実行します。


重要

show boot コマンドはオペレータレベルのユーザーとインスペクタレベルのユーザーが実行できます。

次に、ローカル起動設定のコマンド出力の例を示します。これらの例では、イメージファイル（オペレーティング システム ソフトウェア）と設定ファイル（CLI コマンド）の両方が、/flash デバイスに配置されていることに注意してください。


重要

StarOS イメージファイル名の形式は「asr5500-image_number.bin」です。

例： 
boot system priority 18 \ 
    image /flash/16-1-builds/asr5500-16.1.3.bin \ 
    config /flash/general_config.cfg 
  
boot system priority 19 \  
    image /flash/16-1-builds/asr5500-16.1.1.bin \ 
    config /flash/general_config_3819.cfg 
  
boot system priority 20 \ 
    image /flash/16-1-builds/asr5500-16.1.0.bin \ 
    config /flash/general_config_3665.cfg

次に、ネットワーク起動とローカル起動を組み合わせた設定の出力の例を示します。この例では、イメージファイル（オペレーティング システム ソフトウェア）は最初の 2 つの起動スタックエントリ（優先順位 18 と 19）により Trivial File Transfer Protocol（TFTP）を使用して外部ネットワークサーバーからロードされますが、すべての設定ファイルが /flash に配置されます。

また、起動スタックの上部にある起動ネットワーク インターフェイスと起動ネットワーク設定のコマンドにも注意してください。これらのコマンドは、使用するリモート管理 LAN インターフェイスと、オペレーティング システム ソフトウェアのイメージファイルをホストする外部ネットワークサーバーとの通信に関する方法を定義します。 
boot networkconfig static ip address mio1 192.168.1.150 netmask 255.255.255.0 
boot delay 15 
boot system priority 18 image tftp://192.168.1.161/tftpboot/image_version.bin \config /flash/general_config.cfg 
boot system priority 19 image tftp://192.168.1.161/tftpboot/image_version.bin \config /flash/general_config.cfg 
boot system priority 20 image /flash/image_version.bin \config /flash/general_config.cfg
初期起動時にロードされた起動イメージの優先順位を確認するには、次のように入力します。 
show boot initial-config
次に、出力例を示します。 
[local]host_name# show boot initial-config 
Initial (boot time) configuration: 
      image tftp://192.168.1.161/tftpboot/image_version.bin \ 
       config /flash/config_name.cfg 
      priority 1

新しい起動スタックエントリの追加


重要

この手順を実行する前に、boot.sys ファイルに 10 未満のエントリがあり、より高い優先順位のエントリが使用可能であることを確認します（つまり、少なくとも起動スタックに優先順位 1 のエントリがないことを確認します）。詳細については、「現在の起動スタックの表示」を参照してください。

優先順位 1 が使用されている場合は、既存のエントリの番号を付け直して、少なくともその優先順位が使用可能であることを確認する必要があります。boot.sys ファイルに含めることができる起動スタックエントリの最大数は 10 です。起動スタックにすでに 10 個のエントリがある場合は、これらのエントリのうち少なくとも 1 つを削除する必要があります（通常は優先順位が最も低いエントリ）。また、必要に応じて、他のエントリの一部またはすべての番号を再割り当てしてから続行します。詳細については、起動スタックエントリの削除 を参照してください。

この手順では、新しい起動スタックエントリを boot.sys ファイルに追加する方法について説明します。Exec モードのプロンプトが表示されていることを確認し、次のコマンドを入力します。 
configure 
 boot system priority number image image_url config cfg_url
次のコマンドは、起動優先順位 3 を使用して、新しい起動スタックエントリを作成します。 
boot system priority 3 image /flash/image_filename.bin config /flash/config_name.cfg

重要

boot.sys ファイルに保存された起動スタックの変更は、システムが再起動されるまで実行されません。

次のコマンドを使用して、MIO/UMIO 上のローカルファイルシステムを同期します。

次のコマンドを使用して、CF VM 上のローカルファイルシステムを同期します。 

filesystem synchronize all

起動スタックエントリの削除

この手順では、boot.sys ファイルから個々の起動スタックエントリを削除する方法について説明します。Exec モードのプロンプトが表示されていることを確認し、次のコマンドを入力します。

configure 
   no boot system priority number

number は、起動スタックエントリに使用される起動の優先順位を指定します。このコマンドは、起動スタックから特定のエントリを削除して、 boot.sys ファイルが上書きされるようにします。

ネットワーク起動設定の要件

起動インターフェイスの設定

起動インターフェイスのパラメータは、ネットワークの起動方式を使用しているときにシステムが管理ネットワークとの通信に使用する MIO/UMIO 管理 LAN インターフェイスを定義します。

この手順では、ネットワークサーバーとの信頼性の高い通信を確保するための起動インターフェイスを設定する方法について説明します。Exec モードのプロンプトが表示されていることを確認します。

手順

ステップ 1

次のコマンドを入力してグローバル構成モードを開始します。 

[local]host_name# configure
次のプロンプトが表示されます。 
[local]host_name(config)#

ステップ 2

次のコマンドを入力します。 

[local]host_name(config)#boot interface { local-eth1 | local-eth2 } medium { auto | speed { 10 | 100 | 1000 } duplex { full | half } } media { rj45 | sfp }

上記のコマンドの詳細については、『Command Line Interface Reference』の「Global Configuration Mode Commands」の章を参照してください。

ネットワークの起動にはポート 1 を使用します。

速度が手動で設定されている場合は、デュプレックスモードも設定する必要があります。さらに、ネットワークサーバー設定で速度とデュプレックスの設定がサポートされていることを確認する必要があります。

MIO/UMIO/ 用のネットワーク速度は 1000で固定されています。

イーサネット ネットワーキングのルールによって、自動ネゴシエーション用に設定されているデバイスのインターフェイスは、完全二重をサポートするように手動で設定されたデバイスと通信する場合に、最初のデバイスが 2 番目のデバイスの手動で設定された速度に対してネゴシエートし、半二重モードでのみ通信します。

MIO/UMIO のポート 1 のメディアは、rj45 に固定されています。

ステップ 3

「設定の確認と保存」の章の説明に従って、設定を保存します。

起動ネットワークの設定

起動ネットワーク パラメータは、オペレーティングシステムのソフトウェアイメージファイルをホストする外部ネットワークサーバーに到達するために使用される MIO/UMIO インターフェイスのプロトコルと IP アドレスの情報を定義します。起動ネットワークパラメータを設定するには、Exec モードのプロンプトで操作していることを確認します。

手順

ステップ 1

次のコマンドを入力してグローバル構成モードを開始します。 

[local]host_name(config)#configure
次のプロンプトが表示されます。 
[local]host_name(config)#

ステップ 2

次のコマンドを入力します。 

[local]host_name(config)# boot networkconfig { dhcp | { { dhcp-static-fallback | static } ip address mio5 ip_address5 [ mio6 ip_address6 ] netmask subnet_mask [ gateway gw_ip_address ] } }

上記のコマンドの詳細については、『Command Line Interface Reference』の「Global Configuration Mode Commands」の章を参照してください。

次に、209.165.200.237 のスロット 5 の MIO/UMIO のスタティックフォールバック IP アドレスとクラス C ネットマスクとともに DHCP を使用して通信するように起動ネットワークを設定するコマンドを示します。 
[local]host_name(config)# boot networkconfig dhcp-static-fallback ip address mio5 209.165.200.237 netmask 255.255.255.224
次に、スロット 5 の MIO/UMIO にスタティック IP アドレスを使用し、IP アドレスが 209.165.200.238 のゲートウェイを介して外部ネットワークサーバーにアクセスする例を示します。 
[local]host_name(config)# boot networkconfig static ip address mio5 209.165.200.237 netmask 255.255.255.224 gateway 209.165.200.238

ステップ 3

「設定の確認と保存」の章の説明に従って、設定を保存します。

ブートネットワークの遅延時間の設定

ネットワークから起動するシステムに対して、オプションの遅延時間を秒単位で設定できます。このパラメータの目的は、スパニングツリープロトコル（STP）を使用して、指定された IP アドレスへのネットワークルートを決定するスイッチなどの外部デバイスの時間を許可することです。

ブートネットワークの遅延を設定するには、グローバル構成モードのプロンプトから次のコマンドを入力します。
[local]host_name(config)# boot delay time

ここでは、time は外部ネットワークサーバーへの接続を試行するまでの 1 ～ 300 秒の整数です。ネットワークで STP を使用している場合、一般的な遅延時間は 30 秒で十分す。


重要

「設定の確認と保存」の章の説明に従って、設定を保存します。

起動ネームサーバーの管理

起動ネームサーバーのアドレスを設定するには、グローバル構成モードのプロンプトから次のコマンドを入力します。
[local]host_name(config)# boot nameserver ip_address

ここで、ip_address は、IPv4 ドット付き 10 進表記で入力された DNS サーバーの IP アドレスです。


重要

「設定の確認と保存」の章の説明に従って、設定を保存します。

オペレーティング システム ソフトウェアのアップグレード

この項では、StarOS バイナリイメージのアップグレード手順を手動で実行する方法について説明します。自動 bin アップグレード手順については、自動化された StarOS Bin のアップグレードの項を参照してください。

StarOS ソフトウェアのアップグレード手順を開始する前に、「前提条件」の項で説明されている条件が満たされていることを確認してください。


注意    

VPC の展開解除/再展開は、bin アップグレード後はサポートされません。VPC を非アクティブにすると、アップグレードした StarOS の bin イメージが削除されます。

StarOS ソフトウェアを手動でアップグレードするには、次の手順を実行します。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得

  2. OS リリースバージョンとビルド番号の識別

  3. サポートサイトからソフトウェアイメージをダウンロード

  4. Zookeeper データベースの確認

  5. ESC データベースの確認

  6. /flash デバイスの空き領域の確認

  7. StarOS イメージを /flash に転送

  8. 実行構成の保存

  9. ファイルシステムの同期

  10. システムの再起動

前提条件

CF と SF の VNFC を含む StarOS ソフトウェアのアップグレードを実行する前に、次の前提条件が満たされているかどうかを確認します。

  • AutoDeploy、AutoVNF、ESC、UEM、および CF VM のログインクレデンシャルと IP アドレスが必要です。OpenStack 設定の管理権限を持っている必要があります。

  • OpenStack のステータスを確認します。Ansible の出力がすべて引き渡される必要があります。

    cd /home/stack/ 
source stackrc 
cd /home/stack/ansible/ 
ansible-playbook -i inventory openstack_verify.yml

  • AutoVNF/ESC/EM/VNF VM の正常性が AutoIT の UltraM 正常性ログを通じて正常であるかどうかを確認します。いずれかの VM が正常でない場合は、対応する VM の正常性を回復するための必要なアクションを実行します。

  • 新しい StarOS バイナリイメージファイル（手動アップグレードの場合）または新しい StarOS CF QCOW2 イメージ（自動アップグレードの場合） が必要です。

  • ESC、UEM、および CF の間に保留中のトランザクションがないことを確認します。

  • 元の StarOS bin ファイルのバックアップを必ず実行します。


    （注）  

    自動 bin アップグレードではバックアップを実行する必要ありません。これは、アップグレード RPC によって自動的に処理されるためです。

AutoVNF、CF、ESC、および UEM の VIP アドレスの取得

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

AutoVNF、CF、ESC、および UEM VM の VIP アドレスの収集

  1. デフォルトのユーザーである ubuntu として AutoDeploy VM にログオンします。 

    ssh ubuntu@<ad_vm_address>

  2. ルートユーザーに切り替えます。 

    sudo -i

  3. ConfD CLI を入力します。

    confd_cli -u admin -C

  4. プロンプトが表示されたら、管理者ユーザーのログイン情報を入力します。

  5. AutoVNF、ESC、UEM、および CF VM の VIP アドレスを収集します。

    show vnfr

    出力例：

    
vnfr autoit-f-autovnf

 vnfd     f-autovnf

 vnf-type usp-uas

 state    deployed

 external-connection-point avf

  virtual-link-ref    management

  ip-address          192.168.100.26

  floating-ip-address 10.225.202.94

vnfr sj-autovnf-esc

 vnfd     esc

 vnf-type esc

 state    deployed

 external-connection-point esc

  virtual-link-ref management

  ip-address       192.168.100.22

vnfr sj-autovnf-vpc

 vnfd     vpc

 vnf-type ugp

 state    alive

 external-connection-point cf

  virtual-link-ref management

  ip-address       192.168.100.38

 external-connection-point em

  virtual-link-ref management

  ip-address       192.168.100.21

OS リリースバージョンとビルド番号の識別

オペレーティングシステムは、CLI から発行されたコマンドを使用して、サービスを提供し、事前定義された機能を実行するように設定できます。

オペレーティングシステムのソフトウェアは、単一のバイナリファイル（ファイル拡張子 .bin）として提供され、システム全体の単一インスタンスとしてロードされます。

  • イメージファイル名は、プラットフォームタイプとリリース番号を指定するサフィックスで識別されます。たとえば、asr5500-release_number. bin というようになります。たとえば、 asr5500-16.1.0.bin というようになります。

starfile イメージは、リリース前に REL キーで署名する必要があります。展開可能なイメージは、「.bin.SPA」拡張子を持つ REL キーを使用して署名されます。「A」は、署名キーのリビジョンレベルを示します。たとえば、asr5500-20.0.0.bin.SPA というようになります。署名キーが侵害されると、新しいキーが作成され、リビジョンレベルが「B」に増加します。

信頼できるイメージが導入されました。信頼できるビルドと通常のビルドの違いは、非セキュアなプログラムである ftpd、telnet および tcpdump がないことと、セキュリティオプション用の staros.conf ファイルが追加されていることです。信頼できるイメージは、プラットフォーム名に「_T」が存在することによって識別できます。たとえば、asr5500_T-20.0.0.bin.SPA というようになります。

StarOS ソフトウェアのバージョンとビルド情報を確認するには、次のようにします。

  1. アップグレードする VNF にログオンします。

  2. StarOS コマンド ライン インターフェイスで次の Exec モードのコマンドを入力します。

    show version

    出力例：

    Active Software:

  Image Version:             21.9.0.69918

  Image Build Number:        69918

  Image Description:         Deployment_Build

  Image Date:                Sun Jul 22 12:08:55 EDT 2018

  Boot Image:                /flash/staros.bin

  Source Commit ID:          94797337b6c1691541ea0dd86f2f29b0f2c3630c

  3. StarOS ビルドリリースに関する追加情報を表示するには、次の Exec モードのコマンドを実行します。

    show build

サポートサイトからソフトウェアイメージをダウンロード

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

シスコのサポートサイトとダウンロードファシリティへのアクセスは、ユーザー名とパスワードで制御されています。サイトにアクセスして StarOS のイメージをダウンロードするには、アクティブなカスタマーアカウントが必要です。

/flash デバイスにアップロードできるネットワークの場所または物理デバイス（USB スティック）に、ソフトウェアイメージをダウンロードします。詳細についてはシスコの担当者または Cisco TAC にお問い合わせください。

UGP ベースの VNF の場合、次の手順を実行して、新しい bin ファイルを AutoVNF または OSPD VM にダウンロードします。

  1. 対応する VNF の AutoVNF にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. 新しい StarOS qvpc-di バイナリファイルを AutoVNF/OSPD にダウンロードするためのディレクトリを作成します。

    cd /home/ubuntu/ 
    mkdir StarOSBinUpgrade

  3. Cisco のサポートサイトから新しい StarOS qvpc-di バイナリファイルをダウンロードし、StarOSBinUpgrade ディレクトリにファイルをコピーします。 

    cd StarOSBinUpgrade

    次のコマンドを使用して、ディレクトリに新しい bin ファイルが含まれているかどうかを確認します。

    ls -lrt /home/ubuntu/StarOSBinUpgrade

    出力例：

    total 172560

-r--r--r-- 1 ubuntu ubuntu 176698880 Jul 24 23:29 qvpc-di-21.9.0.69932.bin

Zookeeper データベースの確認

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

zookeeper データベースを確認するには、次のようにします。

  1. フローティング IP を使用して AutoVNF にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で取得した VIP アドレスを使用して、UEM VM にログオンします。

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.21

  3. ルートユーザーになります。 

    sudo -i

  4. Zookeeper データベース接続の UEM オーケストレーション IP アドレスを収集します。

    #ifconfig 
    
eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 

             inet addr:209.165.200.240  Bcast: 209.165.200.255  Mask: 255.255.255.224

  5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin ディレクトリに移動します。

  6. UEM Zookeeper データベースにアクセスするには、コマンドラインから次のスクリプトを実行します。 

    zkCli.sh -server ip_addr:port_num

    次に例を示します。

    zkCli.sh -server 209.165.200.240:2181

  7. zookeeper データベースを確認し、UEM VM と CF VM の間に保留中の要求がないことを確認します。

    ls /request

    出力例：

    []

<Ctrl+D to exit Zookeeper shell>

ESC データベースの確認

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

ESC データベースを確認するには、次のようにします。

  1. フローティング IP を使用して AutoVNF にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で取得した VIP アドレスを使用して ESC VM にログオンします。

    ssh admin@<vip-addr>

    コマンドの例：

    ssh admin@192.168.100.22

  3. ESC データベースを確認して、保留中のトランザクションがないことを確認します。

    sudo /opt/cisco/esc/pgsql/bin/psql -U esc -p 7878 -h localhost -c 'select * from esc_schema.workitem'; 
    
config_id | request_id | mo_type | config_action | config_state 
-----------+------------+---------+---------------+--------------
(0 rows)

  4. トランザクションの詳細を確認するには、次のコマンドを実行します。

    escadm ip_trans

    出力例：

    Number of in-progress transaction events = 0

/flash デバイスの空き領域の確認

新しい StarOS イメージファイルに対応するために、/フラッシュデバイスに十分な空き領域があることを確認します。

フラッシュディレクトリで使用可能な領域を確認するには、次のようにします。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得で取得した VIP アドレスを使用して CF VM にログオンします。

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. 次の Exec モードコマンドを入力します。

    [local]host_name# directory /flash
    次に、表示されるディレクトリ情報のタイプの例を示します。 
    -rwxrwxr-x    1  root     root         7334 May    5 17:29 asr-config.cfg 
-rwxrwxr-x    1  root     root         399 Jun    7 18:32 system.cfg 
-rwxrwxr-x    1  root     root         10667 May 14 16:24 testconfig.cfg 
-rwxrwxr-x    1  root     root         10667 Jun    1 11:21 testconfig_4.cfg 
-rwxrwxr-x    1  root     root         5926 Apr    7 16:27  tworpcontext.cfg 
-rwxrwxr-x    1  root     root         15534 Aug    4 13:31 test_vlan.cfg 
-rwxrwxr-x    1  root     root         2482 Nov 18 11:09 gateway2.cfg 
-rwxrwxr-x    1  root     root         159106048 Dec 31  2011 image_filename 
1136352  /flash 
Filesystem           1k-blocks      Used Available Use% Mounted on 
/var/run/storage/flash/part1 3115468   1136352  30018336   4% /mnt/user/.auto/onboard/flash
    ディスプレイの最後の行にある「Available」ブロックに注意してください。ディレクトリ情報を表示した後、CLI はルートに戻り、次のプロンプトが表示されます。 
    [local]host_name#

StarOS イメージを /flash に転送

次のいずれかの方法を使用して、新しいオペレーティングシステムのイメージファイルを MIO/UMIO VPC-DI アクティブ CF または VPC-SI 上の /flash ディレクトリに転送します。

  • 次のコマンドを入力して、MIO/UMIO に接続されているネットワークの場所またはローカルデバイスからファイルをコピーします。 
    [local]host_name# copy from_url to_url [ -noconfirm ]

  • システムへのアクセス権を持つ FTP クライアントを使用して、ファイルを /flash デバイスに転送します。


    重要
    ファイル転送プロトコル（FTP）を使用してオペレーティングシステムのソフトウェアイメージファイルを転送する場合は、バイナリモードを使用してファイルを転送するように FTP クライアントを設定する必要があります。バイナリ転送モードを使用しないと、転送されたオペレーティング システム イメージファイルが使用できなくなります。FTP はサポートされていません。

  • システムへのアクセス権を持つ SFTP クライアントを使用して、ファイルを /flash デバイスに転送します。

UGP ベースの VNF の場合は、次の手順に従って、新しい StarOS bin をアクティブ CF にコピーします。

  1. 新しい bin ファイルがダウンロードされた AutoVNF または OSPD VM にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. 新しい bin ファイルがシスコのサポートサイトからダウンロードされたディレクトリに移動します。

    cd /home/ubuntu/StarOSBinUpgrade/ && ls -lrt

    出力例：

    total 172560

-r--r--r-- 1 ubuntu ubuntu 176698880 Jul 24 23:29 qvpc-di-21.9.0.69932.bin

  3. SFTP から CF VM へ。

    次に例を示します。

    sftp ubuntu@192.168.100.38

  4. sftp ディレクトリに移動します。 

    #sftp>pwd 
    Remote working directory: / 
    #sftp>ls 
    hd-raid sftp 
    #sftp>cd sftp

  5. 新しいバイナリファイルを sftp ディレクトリにアップロードします。 

    #sftp>put image_filename.bin

    出力例：

    #sftp>put qvpc-di-21.9.0.69932.bin 
    Uploading qvpc-di-21.9.0.69932.bin to /.auto/onboard/flash/sftp/qvpc-di-21.9.0.69932.bin
qvpc-di-21.9.0.69932.bin                             100%  169MB 168.5MB/s   00:01

  6. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で取得した VIP アドレスを使用して CF VM にログオンします。

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  7. 新しい bin を sftp から flash ディレクトリにコピーします。 

    copy /flash/sftp/image_filename.bin /flash/updated.bin

    出力例：

    #copy /flash/sftp/qvpc-di-21.9.0.69932.bin /flash/updated.bin

**************************************************************

Transferred 176698880 bytes in 2.718 seconds (63486.9 KB/sec)

  8. sftp ディレクトリから新しい bin を削除します。 

    delete /flash/sftp/image_filename.bin

    出力例：

    delete /flash/sftp/qvpc-di-21.9.0.69932.bin 
Are you sure? [Yes|No]: yes
File /flash/sftp/qvpc-di-21.9.0.69932.bin removed

  9. 次の Exec モードのコマンドを実行して、イメージファイルが /flash デバイスに正常に転送されたことを確認します。 

    [local]host_name# directory /flash

    表示された出力にイメージファイル名が表示されます。

  10. 次のコマンドを実行して、ビルド情報を確認します。

    show version /flash/image_filename.bin

現在の設定ファイルのコピーの保存

新しいソフトウェアリリースにアップグレードする前に、現在の設定ファイルを /flash デバイスとシャーシ外の場所（外部メモリデバイスやネットワーク URL）にコピーして名前を変更する必要があります。この名前が変更されたコピーが、アップグレード中に問題が発生した場合に使用できるフォールバック用のロードが可能な設定ファイルとなります。

リリース 20.0 からのダウングレード

PBKDF2（パスワードベースのキー派生関数バージョン 2）を使用し、入力されたデータ、ソルト、および反復回数に基づいて、特定の長さのキーを取得するようになりました。ローカルユーザーアカウントのパスワードは、ランダムに生成されたソルトと多くの反復回数を備えた PBKDF2 方式を使用してハッシュされ、パスワードストレージの保護が強化されます。

MD5 ハッシュアルゴリズムを使用するようにローカルユーザーデータベースをダウングレードするには、セキュリティ管理者が Exec モードの downgrade local-user database コマンドを実行する必要があります。StarOS は確認のプロンプトを表示し、パスワードを再入力するようセキュリティ管理者に要求します。ダウングレードコマンドを実行する前に、ユーザーは入力したパスワードで再認証されます。確認後、パスワードは適切な古いまたは弱い暗号化アルゴリズムを使用してハッシュされ、データベースに保存されて、以前のバージョンの StarOS がセキュリティ管理者を認証できるようになります。

ダウングレードプロセスでは、PBKDF2 でハッシュされたパスワードは MD5 形式に変換されません。ダウングレードプロセスでは、（/flash ディレクトリから）データベースが再度読み込まれ、古い形式でデータベースが再構築されてからディスクに書き込まれます。PBKDF2 でハッシュされたパスワードは MD5 ハッシュアルゴリズムに変換できず、以前の StarOS リリースでは PBKDF2 暗号化アルゴリズムを解析できないため、StarOS は PBKDF2 アルゴリズムを介して暗号化されたすべてのユーザーを一時停止します。MD5 アルゴリズム（「弱いハッシュ」フラグ）を介して暗号化されたユーザーは、ログイン情報を使用してログインを続行できます。システムが以前の StarOS リリースで起動した後、一時停止されたユーザーは show local-user [verbose] コマンドの出力で確認できます。

一時停止されたユーザーを再アクティブ化するには、セキュリティ管理者が次の手順を実行します。

  • Exec モードの password change local-user username コマンドを使用して、一時停止されたユーザーの一時パスワードを設定します。

  • 構成モードの no suspend local-user username コマンドを使用して、ユーザーの一時停止フラグをリセットします。

オフラインソフトウェアのアップグレード

オフラインソフトウェアのアップグレードは、バージョン番号に関係なく、任意のバージョンのオペレーティングシステムのソフトウェアから、任意のバージョンにアップグレードするすべてのシステムに対して実行できます。このプロセスは、システムが現在のセッションをサポートしている間に多くのステップを実行できますが、このプロセスの最後のステップでは、実際にソフトウェアのアップグレードを適用するために再起動する必要があるので、オフラインと見なされます。

この手順では、CLI セッションが確立されており、新しいオペレーティングシステムのイメージファイルをローカルファイルシステムに配置していることを前提としています。開始するには、Exec モードのプロンプトが表示されていることを確認してください。
[local]host_name#

オフラインソフトウェアのアップグレードを実行するには：

  1. 新規コールポリシーの設定

  2. Day バナーのメッセージの設定

  3. 現在の CLI 構成ファイルのバックアップ

  4. 実行構成の保存

  5. 新しい起動スタックエントリの作成

  6. ファイルシステムの同期

  7. システムの再起動

新規コールポリシーの設定

サービス要件を満たすために、Exec モードから新規コールポリシーを設定します。このポリシーを有効にすると、アップグレードプロセスが完了したシステムのリロードを予測して、新規コールがリダイレクトまたは拒否されます。これにより、アップグレードが完了したシステムのリロードによって発生するサブスクライバへのサービスの中断時間が短縮されます。


重要

新規コールポリシーは、サービス単位で作成されます。シャーシで複数のサービスを実行している場合は、複数の新規コールポリシーを設定できます。

新規コールポリシーのシンタックスについては、以下を参照してください。 
[local]host_name# newcall policy { asngw-service | asnpc-service | sgsn-service } { all | name service_name } reject 
[local]host_name# newcall policy { fa-service | lns-service | mipv6ha-service } { all | name service_name } reject 
[local]host_name# newcall policy { ha-service | pdsn-service | pdsnclosedrp-service  } { all | name service_name } { redirect target_ip_address [ weight  weight_num ] [ target_ipaddress2 [ weight weight_num ] ... target_ip_address16 [ weight weight_num ] | reject } 
[local]host_name# newcall policy ggsn-service { apn name apn_name | all | name service_name } reject 
[local]host_name# newcall policy hnbgw-service { all | name service_name } reject 
[local]host_name# newcall policy { pcc-af-service | pcc-policy-service } { all | name service_name } reject 
[local]host_name# newcall policy {pcc-af-service | pcc-policy-service } { all | name service_name } reject 
[local]host_name# newcall policy mme-service { all | name service_name } reject

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

Day バナーのメッセージの設定

オプション：グローバル構成モードのプロンプトから次のコマンドを入力して、システムを再起動されることを他の管理ユーザーに通知する「Message of the Day」バナーを設定します。
[local]host_name(config)# banner motd "banner_text"

banner_text は、表示するメッセージで、最大 2048 文字の英数字を使用できます。Banner_text は、引用符で始める引用符で終わる（" "）必要があることに注意してください。CLI バナー情報の入力の詳細については、『CLI Reference』を参照してください。バナーは、管理ユーザーが CLI にログインしたときに表示されます。

現在の CLI 構成ファイルのバックアップ

次のコマンドを入力して、現在の CLI 構成ファイルをバックアップします。
[local]host_name# copy from_url to_url [ -noconfirm ]

これにより、現在の起動スタックエントリで定義されているオペレーティングシステムにリンクされている CLI 構成ファイルのミラーイメージが作成されます。

次のコマンド例では、/flash デバイスにある general.cfg というファイルのバックアップコピーを、general_3652.cfg というファイルに作成します。
[local]host_name# copy /flash/general.cfg /flash/general_3652.cfg

実行構成の保存

シャーシを再起動する前に、現在実行中のアップグレード済みの設定を保存します。


重要

StarOS バイナリイメージの自動アップグレードの場合は、次の手順の 1 ～ 3 のみを実行します。

起動設定を保存するには、次を実行します。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で以前に取得した VIP アドレスを使用して VNF にログオンします。 

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. オプションです。Exec モードで次のコマンドを実行します。 

    chassis key value 1234 
    Save config before reload chassis, EVEN IF the same old key value is used.
Old config scripts will become invalid after reload.

    重要

    この手順は任意であり、シャーシキーが設定されていない場合にのみ必要になります。

  3. フラッシュディレクトリに起動設定を保存します。

    save configuration /flash/system.cfg 
    Warning: About to overwrite boot configuration file
Are you sure? [Yes|No]: yes

    これにより、新しい bin イメージを使用するように起動設定が更新されます。

    次のコマンドを使用して起動設定を確認します。

    # show boot 
 
Monday May 21 20:39:57 UTC 2018

boot system priority 8 \
    image /flash/sftp/production.YYYYY.qvpc-di.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 9 \
    image /flash/staros.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 10 \
    image /flash/staros.bin \
    config /flash/system.cfg

  4. 構成モードを開始し、新しい StarOS bin ファイルの起動優先順位を変更します。

    #config 
    #boot system priority 1 image /flash/updated.bin config /flash/system.cfg 
    #end

  5. 新しい起動優先順位を確認します。

    #show boot 
    
boot system priority 1 \

    image /flash/updated.bin \

    config /flash/system.cfg

boot system priority 10 \

    image /flash/staros.bin \

    config /flash/system.cfg

  6. フラッシュディレクトリに起動設定と新しい bin が含まれているかどうかを確認します。

    dir /flash 
    total 320376
-rw-rw-r-- 1 root root 134 May 3 10:11 boot.sys
-rw-rw-r-- 1 root root 3920672 May 11 19:49 crashlog2
drwxrwxr-x 2 root root 4096 May 11 19:49 crsh2
-rw-rw-r-- 1 root root 156 May 11 19:49 module.sys
drwxrwxr-x 3 root root 4096 May 11 19:49 patch
drwxrwxr-x 2 root root 4096 May 11 19:49 persistdump
-rw-rw-r-- 1 root root 79 May 11 19:49 restart_file_cntr.txt
drwxrwxr-x 3 root root 4096 May 11 20:07 sftp
-rw-rw-r-- 1 root root 160871936 May 3 10:11 staros.bin
-rw-rw-r-- 1 root root 5199 May 11 19:57 system.cfg
-rw-rw-r-- 1 root root 163227136 May 11 20:07 updated.bin
320476 /flash
Filesystem 1K-blocks Used Available Use% Mounted on
/var/run/storage/boot1/part2
4112620 320476 3792144 8% /mnt/user/.auto/onboard/flash

新しい起動スタックエントリの作成

次のグローバル構成コマンドを入力して、新しいオペレーティングシステムイのメージファイルと現在使用されている CLI 設定ファイルで構成される新しいファイルグループの新しい起動スタックエントリを作成します。 
[local]host_name(config)# boot system priority number image image_url /flash filename config cfg_url /flash/filename

<N-1> 方式を使用して、このエントリに次に高い優先順位を割り当てます。この場合、優先順位番号は、現在の最高の優先順位よりも 1 つ小さい値を割り当てます。


重要

Exec モードの show boot コマンドを実行して、boot.sys ファイルに 10 未満のエントリがあることと、高い優先順位のエントリが使用可能である（最小で起動スタックに優先順位 1 のエントリがない）ことを確認します。

優先順位 1 が使用されている場合は、既存のエントリの数字を再割り当てし、少なくともその優先順位 1 を使用できるようにします。

boot.sys ファイルに含めることができる起動スタックエントリの最大数は 10 です。起動スタックにすでに 10 個のエントリがある場合は、これらのエントリのうち少なくとも 1 つを削除する必要があります（通常は優先順位が最も低いエントリ）。また、必要に応じて、他のエントリの一部またはすべての番号を再割り当てしてから続行します。起動スタックエントリを削除するには、no boot system priority コマンドを使用します。 
[local]host_name# configure 
[local]host_name(config)# no boot system priority number
新しい起動スタックエントリを boot.sys.sys ファイルに追加するには、次のコマンドを入力します。 
[local]host_name# configure 
[local]host_name(config)# boot system priority number image image_url config cfg_url

boot system priority コマンドの使用方法については、新しい起動スタックエントリの追加を参照してください 。

システムの再起動

システム（VNF）を再起動するには、次のようにします。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で以前に取得した VIP アドレスを使用して VNF にログオンします。 

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. 次の Exec モードコマンドを入力します。

    [local]host_name# reload [-noconfirm]

    システムが再起動すると、以前に設定した新しい起動スタックエントリを使用して、新しいオペレーティングシステムのソフトウェアイメージとそれに対応する CLI 構成ファイルがロードされます。

  3. PDSN のオプション：アップグレード中に IP プール共有プロトコルを使用している場合は、『PDSN Administration Guide』の「Configuring IPSP Before the Software Upgrade」を参照してください。

  4. リロードが完了したら、VNF にログオンして、目的の StarOS バージョンでロードされていること、およびすべてのカードが起動していること、および予想どおりにアクティブ状態またはスタンバイ状態になっていることを確認します。

    show version

    出力例：

    Active Software:
  Image Version:                  21.9.0.69977
  Image Build Number:             69977
  Image Description:              Build
  Image Date:                     Mon Jul 30 06:48:34 EDT 2018
  Boot Image:                     /flash/updated.bin
  Source Commit ID:               abde005a31c93734c89444b8aec2b6bb2d2e794d
 
    show card table

    出力例：

    
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Active         No
 2: CFC      Control Function Virtual Card           Standby        -
 3: FC       4-Port Service Function Virtual Card    Standby        -
 4: FC       4-Port Service Function Virtual Card    Standby        -
 5: FC       4-Port Service Function Virtual Card    Standby        -
 6: FC       4-Port Service Function Virtual Card    Standby        -
 7: FC       4-Port Service Function Virtual Card    Standby        -
 8: FC       4-Port Service Function Virtual Card    Standby        -
 9: FC       4-Port Service Function Virtual Card    Standby        -
10: FC       4-Port Service Function Virtual Card    Standby        -

  5. 次の Exec モードコマンドを実行して、実行中の StarOS ビルドリリースに関する追加情報を表示します。 

    show build

  6. オプションです。CF および SF VNFC の動作状態を確認します。


    （注）  

    このステップは、CF および SF VNFC をアップグレードする場合にのみ該当します。

    1. 「Zookeeper データベースの確認」と「ESC データベースの確認」の項の手順を繰り返します。

    2. フローティング IP を使用して UEM にログオンするか、または UEM VIP を使用して AutoVNF から UEM にログオンします。 

      ssh ubuntu@<vip-addr>

      コマンドの例：

      ssh ubuntu@192.168.100.21

    3. ルートユーザーになります。 

      sudo -i

    4. Zookeeper データベース接続の UEM オーケストレーション IP アドレスを収集します。

      #ifconfig

eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 

          inet addr:209.165.200.225  Bcast:209.165.200.255  Mask:255.255.255.224

    5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin ディレクトリに移動します。

    6. UEM Zookeeper データベースにアクセスするには、Zookeeper ツールを実行します。

      zkCli.sh -server <vip-addr>:port_num

      コマンドの例：

      zkCli.sh -server 209.165.200.225:2181

      UEM と CF の間に未処理の要求がないことを確認してください。

    7. 次のコマンドを使用して、各 CF および SF の「状態」：「alive」を確認します。

      get /oper/vnfs/vnf_name/vdus/vdu_name/cf1 
      get /oper/vnfs/vnf_name/vdus/vdu_name/cf2 
      get /oper/vnfs/vnf_name/vdus/vdu_name/sf1 
      get /oper/vnfs/vnf_name/vdus/vdu_name/sf2

      コマンドの例：

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf1 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf2 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf1 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf2

    8. コンソール出力で Alive 状態を確認します。

      
zk: localhost:2181(CONNECTED) 2] get /oper/vdus/control-function/BOOT_generic_di-chassis_CF1_1
{"id":"BOOT_generic_di-chassis_CF1_1","state":"alive","vnfcId":"cf-vnfc-di-chassis","uuid":"c4",
"host":"tb5-ultram-osd-compute-2.localdomain","vimId":"523b921c-7266-4fd5-90bb-5157cffc6951",
"cpts":[{"cpid":"di_intf1","state":"alive","subnet":"6102e9b5-8555-41f5-8cdc-0b47d30a6f7a",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL1-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"19539aea-edbf-4acf-a57c-af5627d859ea","ip_address":"192.168.10.3",
"mac_address":"fa:16:3e:19:80:ed","network":"0d72f553-5a9c-4904-b3ea-83371a806e23"},
{"cpid":"di_intf2","state":"alive","nicid":1,"subnet":"30002d02-761d-4ccb-8a9e-d6188cdf54a3",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL2-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"ff1da1e1-ecf3-477d-98b7-398c3c77fc8d","ip_address":"192.168.11.13",
"mac_address":"fa:16:3e:89:88:23","network":"9f109c0a-b1e7-4d90-a746-5de4ab8ef536"},
{"cpid":"orch","state":"alive","nicid":2,"subnet":"729e9dd2-3c75-43eb-988a-769016f2f44c",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-ORCH-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"81370948-f686-4812-820c-20ec5d3d3cdd","ip_address":"172.168.11.17","mac_address":"fa:16:3e:1d:0b:56",
"network":"9a286170-e393-4ba5-abce-147a45fb337a"},{"cpid":"mgmt","state":"alive","nicid":3,
"subnet":"9778a11b-1714-4e84-bbc2-86c84b111e8e","netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-MGMT-CAT",
"vnfc":"cf-vnfc-di-chassis","port_id":"6130cbb4-3dd8-4822-af90-50dac98f2f0d",
"ip_address":"172.168.10.17","mac_address":"fa:16:3e:42:92:47","network":"e278b524-e9a9-48c1-a45b-956a8c3ea583"}],
"monitor":true,"vduId":"control-function"}
cZxid = 0x100000051
ctime = Fri May 18 19:04:40 UTC 2018
mZxid = 0x10000024a
mtime = Mon May 21 17:48:19 UTC 2018
pZxid = 0x100000051
cversion = 0
dataVersion = 12
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 1625
numChildren = 0

      （注）  

      CTRL+D を使用して、zookeeper CLI を終了することができます。

    9. UEM VM からルートユーザーとして、ncs_cli にログオンし、デバイスのライブステータスを確認します。 

      ~$ sudo -i 
      ncs_cli -C -u admin 
      # show devices device device_name live-status

      コマンド出力に、各カードの正しい「状態」と「カード状態」が反映されていることを確認します。

      出力例：

      # show devices device tb1-autovnf1_vpc-vpc-core-cf-nc live-status 
      <snip>

      VNFC の参照

      現在の状態

      VNFC インスタンス ID

      VDU の参照

      カードタイプ

      カード スロット ID

      コア数

      CPU 使用率

      ディスク容量

      開始時刻

      稼働時間

      NOVA 起動 CMD

      ID

      日時

      状態から

      状態へ

      cf1

      -

      cf1

      cf

      control-function

      1

      -

      -

      -

      -

      -

      -

      cf2

      -

      cf2

      cf

      control-function

      2

      -

      -

      -

      -

      -

      -

      sf1

      -

      sf1

      sf

      session-function

      3

      -

      -

      -

      -

      -

      -

      sf2

      -

      sf2

      sf

      session-function

      4

      -

      -

      -

      -

      -

      -

      		 
      
live-status vnfd sj-autovnf-vpc-abc

 version            6.0

 vnfm vim-tenant-name abc

 vnfm tenant-name abc

 vnfm ipaddr     192.168.100.22

 vnfm port       830

 vnfm username   ubuntu

 vnfm password   "$4$+HLzhFFzHq66nqtTsc00CfiODYHqlUSVmkn1tRe1f84byNakWEa9sJ8sY/
cwfFME3aG0UaBC\nvvNNAMkuXQI9Ksfu5IiQQ9ViWbbHwl6IEFQ="

 virtual-link vl-di-internal1

  auto-vnf-connection-ref di-internal1

 virtual-link vl-management

  auto-vnf-connection-ref management

 virtual-link vl-orchestration

  auto-vnf-connection-ref orchestration

 virtual-link vl-abc-vpc-svc

  auto-vnf-connection-ref sj-autovnf-abc-vpc-svc

 vdu cf

  ssh-keygen         false

  vm-image           076c887a-a12c-4a0b-b4d6-b2d213f64b9e

  lifecycle-event-initialization staros_config.txt

   source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_config.txt

  lifecycle-event-initialization staros_param.cfg

   source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_param.cfg

  ned cisco-staros-nc

   user        "$4$+HLzsE1kLJOeuoFWyOsmBWY2LHjOi2WtJdKy/OIux7YHhsNY/
O8hnA9/WwWuFD5trHrW3ZHs\nLo4TfiAKqYwxdNKqFYyoTxH2hrLJV5DgwmE="

   password    "$4$+HLzsXtCHJ2vsYZD5s0RGtBRY/dHDU1mgHJX7wCt3o1DMtQZqpBLDcNSJumC7n5rnkVxwI1s\
ncJYeCOFLrqpLHXm3xtXyMdtT7WVzvRMtdao="

   netconf

   port-number 830

  card-type          control-function

  usp-auto-vnf-id    sj-autovnf-vpc-abc-cf

  vnfc cf-vnfc-ugp

<snip>

実行構成の保存

シャーシを再起動する前に、現在実行中のアップグレード済みの設定を保存します。


重要

StarOS バイナリイメージの自動アップグレードの場合は、次の手順の 1 ～ 3 のみを実行します。

起動設定を保存するには、次を実行します。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で以前に取得した VIP アドレスを使用して VNF にログオンします。 

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. オプションです。Exec モードで次のコマンドを実行します。 

    chassis key value 1234 
    Save config before reload chassis, EVEN IF the same old key value is used.
Old config scripts will become invalid after reload.

    重要

    この手順は任意であり、シャーシキーが設定されていない場合にのみ必要になります。

  3. フラッシュディレクトリに起動設定を保存します。

    save configuration /flash/system.cfg 
    Warning: About to overwrite boot configuration file
Are you sure? [Yes|No]: yes

    これにより、新しい bin イメージを使用するように起動設定が更新されます。

    次のコマンドを使用して起動設定を確認します。

    # show boot 
 
Monday May 21 20:39:57 UTC 2018

boot system priority 8 \
    image /flash/sftp/production.YYYYY.qvpc-di.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 9 \
    image /flash/staros.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 10 \
    image /flash/staros.bin \
    config /flash/system.cfg

  4. 構成モードを開始し、新しい StarOS bin ファイルの起動優先順位を変更します。

    #config 
    #boot system priority 1 image /flash/updated.bin config /flash/system.cfg 
    #end

  5. 新しい起動優先順位を確認します。

    #show boot 
    
boot system priority 1 \

    image /flash/updated.bin \

    config /flash/system.cfg

boot system priority 10 \

    image /flash/staros.bin \

    config /flash/system.cfg

  6. フラッシュディレクトリに起動設定と新しい bin が含まれているかどうかを確認します。

    dir /flash 
    total 320376
-rw-rw-r-- 1 root root 134 May 3 10:11 boot.sys
-rw-rw-r-- 1 root root 3920672 May 11 19:49 crashlog2
drwxrwxr-x 2 root root 4096 May 11 19:49 crsh2
-rw-rw-r-- 1 root root 156 May 11 19:49 module.sys
drwxrwxr-x 3 root root 4096 May 11 19:49 patch
drwxrwxr-x 2 root root 4096 May 11 19:49 persistdump
-rw-rw-r-- 1 root root 79 May 11 19:49 restart_file_cntr.txt
drwxrwxr-x 3 root root 4096 May 11 20:07 sftp
-rw-rw-r-- 1 root root 160871936 May 3 10:11 staros.bin
-rw-rw-r-- 1 root root 5199 May 11 19:57 system.cfg
-rw-rw-r-- 1 root root 163227136 May 11 20:07 updated.bin
320476 /flash
Filesystem 1K-blocks Used Available Use% Mounted on
/var/run/storage/boot1/part2
4112620 320476 3792144 8% /mnt/user/.auto/onboard/flash

ファイルシステムの同期

ファイルシステムを同期するには、次の手順を実行します。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得で取得した VIP アドレスを使用して VNF にログオンします。

  2. 次のコマンドを入力して、管理カード上のローカルファイルシステムを同期します。

    [local]host_name# filesystem synchronize all

    出力例：

    Updating /flash/system.cfg

********************************************************************************

Updating /flash/updated.bin

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-bulkstats-config.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-bulkstats-schema-types.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-bulkstats.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-cli-config.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-confd-config.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-config.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-exec.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-kpi.yang

********************************************************************************

Updating /flash/sftp/yang/cisco-staros-notif.yang

********************************************************************************

Updating /flash/boot.sys

********************************************************************************

12 updated on card 2

           /flash/system.cfg

           /flash/updated.bin

           /flash/sftp/yang/cisco-staros-bulkstats-config.yang

           /flash/sftp/yang/cisco-staros-bulkstats-schema-types.yang

           /flash/sftp/yang/cisco-staros-bulkstats.yang

           /flash/sftp/yang/cisco-staros-cli-config.yang

           /flash/sftp/yang/cisco-staros-confd-config.yang

           /flash/sftp/yang/cisco-staros-config.yang

           /flash/sftp/yang/cisco-staros-exec.yang

           /flash/sftp/yang/cisco-staros-kpi.yang

           /flash/sftp/yang/cisco-staros-notif.yang

           /flash/boot.sys

システムの再起動

システム（VNF）を再起動するには、次のようにします。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で以前に取得した VIP アドレスを使用して VNF にログオンします。 

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. 次の Exec モードコマンドを入力します。

    [local]host_name# reload [-noconfirm]

    システムが再起動すると、以前に設定した新しい起動スタックエントリを使用して、新しいオペレーティングシステムのソフトウェアイメージとそれに対応する CLI 構成ファイルがロードされます。

  3. PDSN のオプション：アップグレード中に IP プール共有プロトコルを使用している場合は、『PDSN Administration Guide』の「Configuring IPSP Before the Software Upgrade」を参照してください。

  4. リロードが完了したら、VNF にログオンして、目的の StarOS バージョンでロードされていること、およびすべてのカードが起動していること、および予想どおりにアクティブ状態またはスタンバイ状態になっていることを確認します。

    show version

    出力例：

    Active Software:
  Image Version:                  21.9.0.69977
  Image Build Number:             69977
  Image Description:              Build
  Image Date:                     Mon Jul 30 06:48:34 EDT 2018
  Boot Image:                     /flash/updated.bin
  Source Commit ID:               abde005a31c93734c89444b8aec2b6bb2d2e794d
 
    show card table

    出力例：

    
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Active         No
 2: CFC      Control Function Virtual Card           Standby        -
 3: FC       4-Port Service Function Virtual Card    Standby        -
 4: FC       4-Port Service Function Virtual Card    Standby        -
 5: FC       4-Port Service Function Virtual Card    Standby        -
 6: FC       4-Port Service Function Virtual Card    Standby        -
 7: FC       4-Port Service Function Virtual Card    Standby        -
 8: FC       4-Port Service Function Virtual Card    Standby        -
 9: FC       4-Port Service Function Virtual Card    Standby        -
10: FC       4-Port Service Function Virtual Card    Standby        -

  5. 次の Exec モードコマンドを実行して、実行中の StarOS ビルドリリースに関する追加情報を表示します。 

    show build

  6. オプションです。CF および SF VNFC の動作状態を確認します。


    （注）  

    このステップは、CF および SF VNFC をアップグレードする場合にのみ該当します。

    1. 「Zookeeper データベースの確認」と「ESC データベースの確認」の項の手順を繰り返します。

    2. フローティング IP を使用して UEM にログオンするか、または UEM VIP を使用して AutoVNF から UEM にログオンします。 

      ssh ubuntu@<vip-addr>

      コマンドの例：

      ssh ubuntu@192.168.100.21

    3. ルートユーザーになります。 

      sudo -i

    4. Zookeeper データベース接続の UEM オーケストレーション IP アドレスを収集します。

      #ifconfig

eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 

          inet addr:209.165.200.225  Bcast:209.165.200.255  Mask:255.255.255.224

    5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin ディレクトリに移動します。

    6. UEM Zookeeper データベースにアクセスするには、Zookeeper ツールを実行します。

      zkCli.sh -server <vip-addr>:port_num

      コマンドの例：

      zkCli.sh -server 209.165.200.225:2181

      UEM と CF の間に未処理の要求がないことを確認してください。

    7. 次のコマンドを使用して、各 CF および SF の「状態」：「alive」を確認します。

      get /oper/vnfs/vnf_name/vdus/vdu_name/cf1 
      get /oper/vnfs/vnf_name/vdus/vdu_name/cf2 
      get /oper/vnfs/vnf_name/vdus/vdu_name/sf1 
      get /oper/vnfs/vnf_name/vdus/vdu_name/sf2

      コマンドの例：

      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf1 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-cf1/cf2 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf1 
      get /oper/vnfs/tb1-autovnf1_vpc-vpc-core/vdus/vdu-sf1/sf2

    8. コンソール出力で Alive 状態を確認します。

      
zk: localhost:2181(CONNECTED) 2] get /oper/vdus/control-function/BOOT_generic_di-chassis_CF1_1
{"id":"BOOT_generic_di-chassis_CF1_1","state":"alive","vnfcId":"cf-vnfc-di-chassis","uuid":"c4",
"host":"tb5-ultram-osd-compute-2.localdomain","vimId":"523b921c-7266-4fd5-90bb-5157cffc6951",
"cpts":[{"cpid":"di_intf1","state":"alive","subnet":"6102e9b5-8555-41f5-8cdc-0b47d30a6f7a",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL1-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"19539aea-edbf-4acf-a57c-af5627d859ea","ip_address":"192.168.10.3",
"mac_address":"fa:16:3e:19:80:ed","network":"0d72f553-5a9c-4904-b3ea-83371a806e23"},
{"cpid":"di_intf2","state":"alive","nicid":1,"subnet":"30002d02-761d-4ccb-8a9e-d6188cdf54a3",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-DI-INTERNAL2-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"ff1da1e1-ecf3-477d-98b7-398c3c77fc8d","ip_address":"192.168.11.13",
"mac_address":"fa:16:3e:89:88:23","network":"9f109c0a-b1e7-4d90-a746-5de4ab8ef536"},
{"cpid":"orch","state":"alive","nicid":2,"subnet":"729e9dd2-3c75-43eb-988a-769016f2f44c",
"netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-ORCH-CAT","vnfc":"cf-vnfc-di-chassis",
"port_id":"81370948-f686-4812-820c-20ec5d3d3cdd","ip_address":"172.168.11.17","mac_address":"fa:16:3e:1d:0b:56",
"network":"9a286170-e393-4ba5-abce-147a45fb337a"},{"cpid":"mgmt","state":"alive","nicid":3,
"subnet":"9778a11b-1714-4e84-bbc2-86c84b111e8e","netmask":"255.255.255.0","dhcp":true,"vl":"vl-vnf1-UAS-MGMT-CAT",
"vnfc":"cf-vnfc-di-chassis","port_id":"6130cbb4-3dd8-4822-af90-50dac98f2f0d",
"ip_address":"172.168.10.17","mac_address":"fa:16:3e:42:92:47","network":"e278b524-e9a9-48c1-a45b-956a8c3ea583"}],
"monitor":true,"vduId":"control-function"}
cZxid = 0x100000051
ctime = Fri May 18 19:04:40 UTC 2018
mZxid = 0x10000024a
mtime = Mon May 21 17:48:19 UTC 2018
pZxid = 0x100000051
cversion = 0
dataVersion = 12
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 1625
numChildren = 0

      （注）  

      CTRL+D を使用して、zookeeper CLI を終了することができます。

    9. UEM VM からルートユーザーとして、ncs_cli にログオンし、デバイスのライブステータスを確認します。 

      ~$ sudo -i 
      ncs_cli -C -u admin 
      # show devices device device_name live-status

      コマンド出力に、各カードの正しい「状態」と「カード状態」が反映されていることを確認します。

      出力例：

      # show devices device tb1-autovnf1_vpc-vpc-core-cf-nc live-status 
      <snip>

      VNFC の参照

      現在の状態

      VNFC インスタンス ID

      VDU の参照

      カードタイプ

      カード スロット ID

      コア数

      CPU 使用率

      ディスク容量

      開始時刻

      稼働時間

      NOVA 起動 CMD

      ID

      日時

      状態から

      状態へ

      cf1

      -

      cf1

      cf

      control-function

      1

      -

      -

      -

      -

      -

      -

      cf2

      -

      cf2

      cf

      control-function

      2

      -

      -

      -

      -

      -

      -

      sf1

      -

      sf1

      sf

      session-function

      3

      -

      -

      -

      -

      -

      -

      sf2

      -

      sf2

      sf

      session-function

      4

      -

      -

      -

      -

      -

      -

      		 
      
live-status vnfd sj-autovnf-vpc-abc

 version            6.0

 vnfm vim-tenant-name abc

 vnfm tenant-name abc

 vnfm ipaddr     192.168.100.22

 vnfm port       830

 vnfm username   ubuntu

 vnfm password   "$4$+HLzhFFzHq66nqtTsc00CfiODYHqlUSVmkn1tRe1f84byNakWEa9sJ8sY/
cwfFME3aG0UaBC\nvvNNAMkuXQI9Ksfu5IiQQ9ViWbbHwl6IEFQ="

 virtual-link vl-di-internal1

  auto-vnf-connection-ref di-internal1

 virtual-link vl-management

  auto-vnf-connection-ref management

 virtual-link vl-orchestration

  auto-vnf-connection-ref orchestration

 virtual-link vl-abc-vpc-svc

  auto-vnf-connection-ref sj-autovnf-abc-vpc-svc

 vdu cf

  ssh-keygen         false

  vm-image           076c887a-a12c-4a0b-b4d6-b2d213f64b9e

  lifecycle-event-initialization staros_config.txt

   source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_config.txt

  lifecycle-event-initialization staros_param.cfg

   source-url http://192.168.100.9:5000/config/sj-autovnf-vpc-abc/cf/staros_param.cfg

  ned cisco-staros-nc

   user        "$4$+HLzsE1kLJOeuoFWyOsmBWY2LHjOi2WtJdKy/OIux7YHhsNY/
O8hnA9/WwWuFD5trHrW3ZHs\nLo4TfiAKqYwxdNKqFYyoTxH2hrLJV5DgwmE="

   password    "$4$+HLzsXtCHJ2vsYZD5s0RGtBRY/dHDU1mgHJX7wCt3o1DMtQZqpBLDcNSJumC7n5rnkVxwI1s\
ncJYeCOFLrqpLHXm3xtXyMdtT7WVzvRMtdao="

   netconf

   port-number 830

  card-type          control-function

  usp-auto-vnf-id    sj-autovnf-vpc-abc-cf

  vnfc cf-vnfc-ugp

<snip>

以前のソフトウェアイメージの復元

何らかの理由でアップグレードを元に戻す必要がある場合は、次の場合を除き、アップグレードを再度実行します。

  • アップグレード ソフトウェア イメージと設定ファイルの場所を指定します。

次に

  • 元のソフトウェアイメージと設定ファイルの場所を指定します。

ICSR シャーシのアップグレード

プライマリおよびバックアップの ICSR シャーシをアップグレードする手順については、「シャーシ間セッションリカバリ」を参照してください。基本的にこの手順では、それぞれがスタンバイモードになっているときにオフライン方式を使用して、プライマリシャーシとスタンバイシャーシをアップグレードする必要があります。

自動化された StarOS Bin のアップグレード

ここでは、自動 StarOS bin のアップグレード手順について説明します。手動の bin アップグレード手順については、オペレーティング システム ソフトウェアのアップグレード の項を参照してください。

StarOS ソフトウェアのアップグレード手順を開始する前に、「前提条件」の項で説明されている条件が満たされていることを確認してください。

StarOS ソフトウェアアップグレードを自動化するには、次のようにします。

  1. StarOS CF QCOW2 イメージのダウンロード

  2. Zookeeper データベースの確認

  3. ESC データベースの確認

  4. /flash デバイスの空き領域の確認

  5. 実行構成の保存

  6. StarOS アップグレードの開始

前提条件

CF と SF の VNFC を含む StarOS ソフトウェアのアップグレードを実行する前に、次の前提条件が満たされているかどうかを確認します。

  • AutoDeploy、AutoVNF、ESC、UEM、および CF VM のログインクレデンシャルと IP アドレスが必要です。OpenStack 設定の管理権限を持っている必要があります。

  • OpenStack のステータスを確認します。Ansible の出力がすべて引き渡される必要があります。

    cd /home/stack/ 
source stackrc 
cd /home/stack/ansible/ 
ansible-playbook -i inventory openstack_verify.yml

  • AutoVNF/ESC/EM/VNF VM の正常性が AutoIT の UltraM 正常性ログを通じて正常であるかどうかを確認します。いずれかの VM が正常でない場合は、対応する VM の正常性を回復するための必要なアクションを実行します。

  • 新しい StarOS バイナリイメージファイル（手動アップグレードの場合）または新しい StarOS CF QCOW2 イメージ（自動アップグレードの場合） が必要です。

  • ESC、UEM、および CF の間に保留中のトランザクションがないことを確認します。

  • 元の StarOS bin ファイルのバックアップを必ず実行します。


    （注）  

    自動 bin アップグレードではバックアップを実行する必要ありません。これは、アップグレード RPC によって自動的に処理されるためです。

StarOS CF QCOW2 イメージのダウンロード

この項では、CF VNFC のアップグレードのみに適用される手順について説明します。

シスコのサポートサイトとダウンロードファシリティへのアクセスは、ユーザー名とパスワードで制御されています。サイトにアクセスして StarOS のイメージをダウンロードするには、アクティブなカスタマーアカウントが必要です。

UGP の展開に必要なイメージファイルは、RPM バンドルの一部として配布されます。バンドルは、usp-ugp-bundle-<version>.x86_64.rpm と呼ばれ、USP ISO イメージの一部として配布されています。

UGP ベースの VNF の場合、次の手順を実行して、新しい StarOS バイナリイメージファイルを AutoVNF または OSPD VM にダウンロードします。

  1. シスコのサポートサイトから必要なリリースの USP ISO バンドルをダウンロードします。

  2. USP ISO から UGP イメージファイルを抽出します。UGP RPM バンドルには、qvpc-di-<version>.qcow2.tgz が含まれています。 

    rpm2cpio /var/usp-iso/repo/usp-ugp-bundle-<version>-1.x86_64.rpm | cpio –idmv ./opt/cisco/usp/bundles/ugp-bundle/qvpc-di-<version>.qcow2.tgz

  3. イメージが抽出されたことを確認します。

    ls -l ./opt/cisco/usp/bundles/ugp-bundle/qvpc-di-<version>.qcow2.tgz

  4. CF qcow2 イメージを抽出します。

    tar –zxvf qvpc-di-<version>.qcow2.tgz qvpc-di-cf-<version>.qcow2

Zookeeper データベースの確認

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

zookeeper データベースを確認するには、次のようにします。

  1. フローティング IP を使用して AutoVNF にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で取得した VIP アドレスを使用して、UEM VM にログオンします。

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.21

  3. ルートユーザーになります。 

    sudo -i

  4. Zookeeper データベース接続の UEM オーケストレーション IP アドレスを収集します。

    #ifconfig 
    
eth0      Link encap:Ethernet  HWaddr fa:16:3e:71:1d:08 

             inet addr:209.165.200.240  Bcast: 209.165.200.255  Mask: 255.255.255.224

  5. Navigate to the /opt/cisco/usp/packages/zookeeper/<current>/bin ディレクトリに移動します。

  6. UEM Zookeeper データベースにアクセスするには、コマンドラインから次のスクリプトを実行します。 

    zkCli.sh -server ip_addr:port_num

    次に例を示します。

    zkCli.sh -server 209.165.200.240:2181

  7. zookeeper データベースを確認し、UEM VM と CF VM の間に保留中の要求がないことを確認します。

    ls /request

    出力例：

    []

<Ctrl+D to exit Zookeeper shell>

ESC データベースの確認

この項では、CF および SF VNFC のアップグレードにのみ適用される手順について説明します。

ESC データベースを確認するには、次のようにします。

  1. フローティング IP を使用して AutoVNF にログオンします。

    ssh ubuntu@<ad_vm_address>

    コマンドの例：

    ssh ubuntu@10.225.202.94

  2. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で取得した VIP アドレスを使用して ESC VM にログオンします。

    ssh admin@<vip-addr>

    コマンドの例：

    ssh admin@192.168.100.22

  3. ESC データベースを確認して、保留中のトランザクションがないことを確認します。

    sudo /opt/cisco/esc/pgsql/bin/psql -U esc -p 7878 -h localhost -c 'select * from esc_schema.workitem'; 
    
config_id | request_id | mo_type | config_action | config_state 
-----------+------------+---------+---------------+--------------
(0 rows)

  4. トランザクションの詳細を確認するには、次のコマンドを実行します。

    escadm ip_trans

    出力例：

    Number of in-progress transaction events = 0

/flash デバイスの空き領域の確認

新しい StarOS イメージファイルに対応するために、/フラッシュデバイスに十分な空き領域があることを確認します。

フラッシュディレクトリで使用可能な領域を確認するには、次のようにします。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得で取得した VIP アドレスを使用して CF VM にログオンします。

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. 次の Exec モードコマンドを入力します。

    [local]host_name# directory /flash
    次に、表示されるディレクトリ情報のタイプの例を示します。 
    -rwxrwxr-x    1  root     root         7334 May    5 17:29 asr-config.cfg 
-rwxrwxr-x    1  root     root         399 Jun    7 18:32 system.cfg 
-rwxrwxr-x    1  root     root         10667 May 14 16:24 testconfig.cfg 
-rwxrwxr-x    1  root     root         10667 Jun    1 11:21 testconfig_4.cfg 
-rwxrwxr-x    1  root     root         5926 Apr    7 16:27  tworpcontext.cfg 
-rwxrwxr-x    1  root     root         15534 Aug    4 13:31 test_vlan.cfg 
-rwxrwxr-x    1  root     root         2482 Nov 18 11:09 gateway2.cfg 
-rwxrwxr-x    1  root     root         159106048 Dec 31  2011 image_filename 
1136352  /flash 
Filesystem           1k-blocks      Used Available Use% Mounted on 
/var/run/storage/flash/part1 3115468   1136352  30018336   4% /mnt/user/.auto/onboard/flash
    ディスプレイの最後の行にある「Available」ブロックに注意してください。ディレクトリ情報を表示した後、CLI はルートに戻り、次のプロンプトが表示されます。 
    [local]host_name#

実行構成の保存

シャーシを再起動する前に、現在実行中のアップグレード済みの設定を保存します。


重要

StarOS バイナリイメージの自動アップグレードの場合は、次の手順の 1 ～ 3 のみを実行します。

起動設定を保存するには、次を実行します。

  1. AutoVNF、CF、ESC、および UEM の VIP アドレスの取得 で以前に取得した VIP アドレスを使用して VNF にログオンします。 

    ssh ubuntu@<vip-addr>

    コマンドの例：

    ssh ubuntu@192.168.100.38

  2. オプションです。Exec モードで次のコマンドを実行します。 

    chassis key value 1234 
    Save config before reload chassis, EVEN IF the same old key value is used.
Old config scripts will become invalid after reload.

    重要

    この手順は任意であり、シャーシキーが設定されていない場合にのみ必要になります。

  3. フラッシュディレクトリに起動設定を保存します。

    save configuration /flash/system.cfg 
    Warning: About to overwrite boot configuration file
Are you sure? [Yes|No]: yes

    これにより、新しい bin イメージを使用するように起動設定が更新されます。

    次のコマンドを使用して起動設定を確認します。

    # show boot 
 
Monday May 21 20:39:57 UTC 2018

boot system priority 8 \
    image /flash/sftp/production.YYYYY.qvpc-di.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 9 \
    image /flash/staros.bin \
    config /flash/sftp/tb5_vnf1_dayN.cfg

boot system priority 10 \
    image /flash/staros.bin \
    config /flash/system.cfg

  4. 構成モードを開始し、新しい StarOS bin ファイルの起動優先順位を変更します。

    #config 
    #boot system priority 1 image /flash/updated.bin config /flash/system.cfg 
    #end

  5. 新しい起動優先順位を確認します。

    #show boot 
    
boot system priority 1 \

    image /flash/updated.bin \

    config /flash/system.cfg

boot system priority 10 \

    image /flash/staros.bin \

    config /flash/system.cfg

  6. フラッシュディレクトリに起動設定と新しい bin が含まれているかどうかを確認します。

    dir /flash 
    total 320376
-rw-rw-r-- 1 root root 134 May 3 10:11 boot.sys
-rw-rw-r-- 1 root root 3920672 May 11 19:49 crashlog2
drwxrwxr-x 2 root root 4096 May 11 19:49 crsh2
-rw-rw-r-- 1 root root 156 May 11 19:49 module.sys
drwxrwxr-x 3 root root 4096 May 11 19:49 patch
drwxrwxr-x 2 root root 4096 May 11 19:49 persistdump
-rw-rw-r-- 1 root root 79 May 11 19:49 restart_file_cntr.txt
drwxrwxr-x 3 root root 4096 May 11 20:07 sftp
-rw-rw-r-- 1 root root 160871936 May 3 10:11 staros.bin
-rw-rw-r-- 1 root root 5199 May 11 19:57 system.cfg
-rw-rw-r-- 1 root root 163227136 May 11 20:07 updated.bin
320476 /flash
Filesystem 1K-blocks Used Available Use% Mounted on
/var/run/storage/boot1/part2
4112620 320476 3792144 8% /mnt/user/.auto/onboard/flash

StarOS アップグレードの開始

StarOS のアップグレードは、ConfD CLI または NETCONF API から実行された RPC によって自動化されます。

CLI 経由

CLI を使用してアップグレードを実行するには、ConfD CLI 管理者ユーザーとして AutoVNF にログオンし、次のコマンドを実行します。

vnfm-staros-bin-upgrade nsd-id <nsd_id> qcow-url <qcow_url> [ vnfid <vnfid> ]

注：

  • <nsd_id> は、ネットワークサービス記述子（NSD）の名前です。

  • <qcow_url>は、インストール ISO イメージからの StarOS CF QCOW ファイルへの完全修飾パスです。通常、ファイルの名前は qvpc-di-cf.qcow2 または qvpc-di-cf_T.qcow2 です。

  • <vnfid> は、アップグレードする StarOS VNF のオプション ID です。つまり、UEM に認識されている VPC VNF ID を表します。


    （注）  

    この ID は UEM から取得する必要があります。

    この ID が指定されていない場合は、展開内のすべての StarOS VNF がアップグレードされます。この ID を取得するには 、マスター UEM の ncs_cli で show running vnfdservice:vnfd を実行します。

  • アップグレードは完了するまで数分かかる場合があります。トランザクションステータスに、操作が成功したかどうかが示されます。進行状況または障害をモニターするには、/var/log/upstart/ ディレクトリの autovnf.log を確認します。

NETCONF API 経由

操作：nsd:vnfm-staros-bin-upgrade

名前空間：xmlns:nsd="http://www.cisco.com/usp/nfv/usp-nsds"

パラメータ：

パラメータ名

必須

タイプ

説明

nsd-id

必須

文字列

NSD 名

qcow-url

必須

文字列

qcow ファイルへのパス

vnfid

オプション

文字列

アップグレードする StarOS デバイスの ID

注：

  • <nsd-id> は、ネットワークサービス記述子（NSD）の名前です。

  • <qcow-url>は、インストール ISO イメージからの StarOS CF qcow ファイルへの完全修飾パスです。通常、ファイルの名前は qvpc-di-cf.qcow2 または qvpc-di-cf_T.qcow2 です。

  • <vnfid> は、UEM 上の StarOS VNF の識別子です。この ID はオプションです。指定しない場合は、展開内のすべての StarOS VNF がアップグレードされます。


    （注）  

    この ID は UEM から取得する必要があります。

  • アップグレードは完了するまで数分かかる場合があります。トランザクションステータスに、操作が成功したかどうかが示されます。進行状況または障害をモニターするには、/var/log/upstart/ ディレクトリの autovnf.log を確認します。

ダイナミックソフトウェア更新の実施

StarOS では、プラグインのランタイムロードが可能です。すべての StarOS ビルドには、「デフォルト」のベースラインプラグインが備わっています。

この機能は、現在、アプリケーションの検出と制御（ADC）の機能によって P2P アプリケーションをフィルタ処理するために使用される検出ロジックを動的に更新するために使用されています。

パッチの適用は、StarOS リリースの増分更新としてプラグインをインストールするために使用されるプロセスです。互換性のある複数の同時製品リリースに対して、1 つのプラグインが提供されることがあります。プラグインは、インターネットや他の手段（USB スティック、CD など）を介して、圧縮された配布キットの形式で配布されます。

プラグインは、既存の StarOS ソフトウェアコンポーネントの増分更新を実行する機能的なソフトウェアエンティティです。プラグインには、実行時に動的にロード可能な特性があり、システムを再起動する必要はありません。プラグインには、名前と 1 つ以上のバージョンがあります。すべてのプラグイン名は、製品リリースのシステムで認識されています。

動的なソフトウェア アップデート プロセスの詳細については、『ADC Administration Guide』を参照してください。

ダイナミックソフトウェア更新の実施

この項では、StarOS を更新してシステムをリロードすることなく、プラグインを段階的に更新するために使用できる動的ソフトウェア更新（DSU）プロセスについて説明します。

概要

StarOS では、プラグインのランタイムロードが可能です。すべての StarOS ビルドには、「デフォルト」のベースラインプラグインが備わっています。

現在、この機能は P2P アプリケーションをフィルタ処理するために使用される検出ロジックを動的に更新するために使用されています。

パッチの適用は、StarOS リリースの増分更新としてプラグインをインストールするために使用されるプロセスです。互換性のある複数の同時製品リリースに対して、1 つのプラグインが提供されることがあります。プラグインは、インターネットや他の手段（USB スティック、CD など）を介して、圧縮された配布キットの形式で配布されます。

プラグインは、既存の StarOS ソフトウェアコンポーネントの増分更新を実行する機能的なソフトウェアエンティティです。プラグインには、実行時に動的にロード可能な特性があり、システムを再起動する必要はありません。プラグインには、名前と 1 つ以上のバージョンがあります。すべてのプラグイン名は、製品リリースのシステムで認識されています。

プラグインモジュールはプラグインバージョンの特定のインスタンスであり、実行中のインサービスシステムに追加できる 1 つ以上のファイルから構成されています。このモジュールには、特定のコンポーネントの増分更新の情報または指示が含まれています。通常、これは 1 つのファイルになります。

バージョン優先順位リスト（VPL）は、特定のプラグインに関連付けられているモジュールバージョンのリンクリストです。各プラグインには VPL が 1 つあります。リストは、管理者によって割り当てられた優先順位番号の昇順でソートされます。更新時には、最も低い優先順位番号が最初に試行されます。そのバージョンが成功しなかった場合は、次に高い優先順位番号を持つ VPL のバージョンが試行されます。このリストは、正常なバージョンが見つかるまで繰り返して試行されます。また、VPL は CLI コマンドを介して、以前のバージョン（より大きい優先順位番号）への手動ロールバックもサポートしています。

ダイナミック ソフトウェア プロセスの基本的なシーケンスは次のとおりです。

パッチキットのダウンロード

Exec モードの patch plugin コマンドは、特定のプラグインを対象としたパッチを実行中のシステムにコピーします。

プラグインキットには、圧縮プラグインファイル（拡張子 .tgz）と証明書ファイル（拡張子 .cert）が含まれています。コマンド構文は次のとおりです。
patch plugin name [ http | ftp | sftp ]://host/directory/file certificate  [ http | ftp | sftp ]://host/directory/file
次に例を示します。
[local]asr5k# patch plugin p2p http://192.168.1.2/tmp/patch_libp2p-1.17.4343.tgz certificate http://192.168.1.2/tmp/patch_libp2p-1.17.4343.cert 
New patch for plugin p2p available for installation

パッチキットは、システムの/flash/patch/module-name ディレクトリにコピーされます。

パッチキットの開梱

Exec モードの install patch コマンドは、パッチキットを解凍し、そのコンテンツを検証します。このコマンドは、実際にはパケット処理カードの /var/opt ディレクトリにコンテンツを配信しません。

コマンド構文は次のとおりです。
install plugin plugin-name patch-file-name
次に例を示します。
[local]host_name# install patch plugin p2p patch_libp2p-1.17.4343.tgz 
  Install patch file patch_libp2p-1.17.4343.tgz [Yes/No]&quest; 
  Install module p2p version 1.17.4343 successful

新しいプラグインモジュールがインストールされると、コンテンツの信頼性を確保するためにパッチファイルで提供される証明書に対して、パッチファイルがチェックされます。証明書がパッチファイルと一致する場合、コンテンツは /flash/install/plugin-name/contents ディレクトリに展開されます。

コンテンツが抽出されると、プラグインマネージャは、パッチの完全なセットと見なされるファイルのリストを含む patch.bom ファイルを検索します。また、リストされている各ファイルについて、the.bom ファイルには、インストールの最後にコンテンツファイルが存在するように意図された最終的な接続先ディレクトリが含まれています。

bom ファイルにリストされている各ファイルについて、インストール手順によって、指定されたファイルが接続先ディレクトリにコピーされます。これが完了すると、インストール手順は完了です。プライマリ MIO/UMIO/MIO2 は、スタンバイ MIO/UMIO/MIO2 上の /flash パーティションが最新であることを確認する役割を担います。

プラグインの設定

グローバル構成モードの plugin コマンドは、設定するプラグインを指定し、プラグイン構成モードを開始します。プラグイン名は、システム上にコピーし、解凍したプラグインの名前と一致する必要があります。一致しない場合はエラーメッセージが表示されます。

コマンド構文は次のとおりです。
plugin plugin-name 
  module priority number version module_version
次に例を示します。
[local]host_name# configure 
[local]host_name(config)# plugin p2p 
[local]host_name(plugin-p2p)# module priority 1 version 1.17.4343

モジュール優先順位番号（1 ～ 100）が以前の設定で指定されていた場合、その番号が保持されます。ユーザーが明示的にモジュールの優先順位番号を置換または削除しない場合、その番号および関連のバージョンが設定されたままになります。

プラグイン構成モードを使用すると、ユーザーはプラグインに関連付けられた属性値ペア（AVP）に値を入力したり、プラグインのこのバージョンの VPL 内での優先順位を設定できます。

プラグインの読み込み

Exec モードの update module コマンドは、VPL から指定された最も低い優先順位番号を持つモジュールをロードします。

コマンド構文は次のとおりです。
update module plugin-name
次に例を示します。
[local]host_name# update module p2p 
Update to module p2p version 1.17.4343 successful

update module コマンドは、設定された VPL（/flash/module.sys）を取得し、プラグインマネージャ内の内部データ構造にコピーします。VPL は、各カードのロードを試みるモジュールバージョンのシーケンスを決定します。

現在のサブスクライバセッションは最新のプラグインバージョンには更新されません。新しいサブスクライバセッションは、新しく更新されたプラグインバージョンの影響を受けます。

以前のプラグインバージョンへのロールバック

Exec モードの rollback module コマンドは、VPL から次に高い優先順位番号を持つモジュールをロードします。

コマンド構文は次のとおりです。
rollback module plugin-name
次に例を示します。
[local]host_name# rollback module p2p 
Rollback to module p2p version 1.17.4340 successful

現在のサブスクライバセッションは、前のプラグインバージョンの影響を受け続けます。新しいサブスクライバセッションは、新たにダウングレードされたプラグインバージョンの影響を受けます。

DSU show コマンド

ダイナミックソフトウェアの更新プロセスに関連する show コマンドには、show module と show plugin の 2 つがあります。

show moduleコマンドは、内部 VPL の現在のステータスを表示します。コマンド構文は次のとおりです。
show module [plugin-name]
次に例を示します。
[local]asr5# show module p2p 
Module p2p 
Priority version    loaded location                   time         status 
    1    1.17.4343      no  /var/opt/lib    07/04/2012:05:06:59  success 
    2    1.17.4340      yes  /var/opt/lib    03/06/2012:04:05:53  success 
    3    1.17.4335      no  /var/opt/lib    03/05/2012:03:04:35  success 
    4     1.17.4328     no  /var/opt/lib    03/04/2012:02:03:42  failed 
    X    1.17.4289      no  /var/opt/lib    01/12/2012:05:44:22  success

重要

優先順位「X」は、StarOS ビルドに付属している「default」モジュールを識別します。
show plugin コマンドを実行すると、プラグインの現在の設定（AVP とバージョン優先順位）が表示されます。コマンド構文は次のとおりです。
show plugin [plugin-name]
次に例を示します。
[local]host_name# show plugin p2p 
  plugin p2p 
    module priority 1 version 1.17.4343  
    module priority 2 version 1.17.4340  
    module priority 3 version 1.17.4328  
    module priority 4 version 1.17.4340  
    module priority X version 1.17.4289

ライセンスキーの管理

ライセンスキーは、キャパシティ制限（許可されるサブスクライバセッションの数）とシステムで使用可能な機能を定義します。新しいライセンスキーを追加すると、キャパシティを増やしたり、サブスクライバベースが増加したときに新しい機能を追加したりすることができます。

新しいシステムライセンスキー

新しいシステムは、ライセンスキーがインストールされていない状態で納品されます。ほとんどの場合、ライセンスキーは電子形式（通常は電子メール）で渡されます。

ライセンスキーがインストールされていない状態でシステムが起動すると、デフォルトの制限付きのセッション使用ライセンスと機能ライセンス一式がインストールされます。次の Exec モードコマンドは、ライセンス情報を一覧表示します。 
[local]host_name# show license information

重要

ライセンスキーがインストールされていない場合、PDSN、HA、GGSN、および L2TP LNS のセッション使用ライセンスは 10,000 セッションに制限されます。

ASR 5500 のライセンスキーは、シャーシミッドプレーン上の EEPROM に保存されます。MIO/UMIO は、起動時にこの EEPROM にアクセスします。

セッション使用とライセンス使用のライセンス

セッション使用および機能の使用ライセンスは、セッション制限を制御し、システム内の特別な機能を有効にするソフトウェアメカニズムです。これらの電子ライセンスは、システムが電源オンになるか再起動されるたびに、システムソフトウェアの一部としてロードされるシステム構成ファイルに保存されます。

  • セッション使用ライセンスは、システムがサービスタイプごとにサポートできる同時セッション数を制限し、必要に応じて取得されます。これにより、キャリアは利用しているものに対してのみ支払いを行い、サブスクライバベースの増加に応じてキャパシティを簡単に増やすことができます。

  • 機能使用ライセンスは、システム内で特定の機能を有効にし、システムでサポートされているセッションの合計数に基づいて配布されます。

新しいライセンスキーのインストール

新しいライセンスキーをインストールするには、次の手順を使用します。

キーのカットアンドペースト

ライセンスのコピーがある場合は、次の設定を使用して、ライセンスキー部分だけをカットアンドペーストします。

手順

ステップ 1

Exec モードで、次のように入力します。 

configure 
   license key license 
   exit
license はライセンスキー文字列です。ライセンスは、大文字と小文字が区別される 1 ～ 1023 文字の英数字文字列にすることができます。次の例に示すように、ライセンスキーをコピーします（「\ (二重引用符)」を含む）。これは機能ライセンスではありませんのでご注意ください。 
"\ 
VER=1|C1M=000-0000-00|C1S=03290231803|C2M=11-1111-11-1|C2S=\ 
STCB21M82003R80411A4|DOI=0000000000|DOE=00000000|ISS=1|NUM=13459|0000000000000| 
LSP=000000|LSH=000000|LSG=500000|LSL=500000\|FIS=Y|FR4=Y|FPP=Y|FCS=Y|FTC=Y|FMG=Y| 
FCR=Y|FSR=Y|FPM=Y|FID=Y|SIG=MCwCF\Esnq6Bs/ 
XdmyfLe7rHcD4sVP2bzAhQ3IeHDoyyd6388jHsHD99sg36SG267gshssja77 
end

ステップ 2

Exec モードプロンプトで次のコマンドを入力して、入力したライセンスキーが受け入れられたことを確認します。 

[local]host_name# show license key
新しいライセンスキーが表示されます。表示されない場合は、グローバル構成モードに戻り、license key コマンドを使用してキーを再入力します。

重要

 
無効なライセンスは受け入れられません。無効なライセンスキーを設定しようとすると、license key コマンドの出力に障害エラーが表示されます。-force オプションを使用して無効なライセンスキーをインストールすると、ライセンスは 30 日間の猶予期間に入ります。StarOS は、猶予期間中に毎日の syslog エラーメッセージと SNMP トラップを生成します。show license information コマンドの出力には、「License State」が「Not Valid」として示されます。

ステップ 3

次のコマンドを入力して、ライセンスキーが正しい機能を有効にしていることを確認します。 

[local]host_name# show license information
すべてのライセンスキーと、有効になっている新しいセッションのキャパシティまたは機能が表示されます。新しいキーで有効になっている機能またはセッションのキャパシティが正しくない場合は、サービス担当者にお問い合わせください。

ステップ 4

「設定の確認と保存」の章の説明に従って、設定を保存します。

注意    

 

新しいライセンスキー設定を現在の CLI 構成ファイルに保存しないと、システムがリロードされた際に、ライセンスキーによって有効にされた新しい機能が失われます。

ライセンスキーを構成ファイルに追加

ライセンスキーは、新規または既存の構成ファイルに追加できます。


重要

ライセンスキー情報は、CLI 設定の一部として維持されます。キーがインストールまたは更新されるたびに、構成ファイルを再保存する必要があります。

手順

ステップ 1

新しいライセンスキーコマンドをコピーする構成ファイルを開きます。

ステップ 2

例に示すように、「\（二重引用符）」を含むライセンスをコピーします。これは機能ライセンスではありませんのでご注意ください。 

"\ 
VER=1|C1M=000-0000-00|C1S=03290231803|C2M=11-1111-11-1|C2S=\STCB21M82003R80411A4| 
DOI=0000000000|DOE=00000000|ISS=1|NUM=13459|0000000000000|LSP=000000|LSH=000000| 
LSG=500000|LSL=500000\|FIS=Y|FR4=Y|FPP=Y|FCS=Y|FTC=Y|FMG=Y|FCR=Y|FSR=Y|FPM=Y|FID=Y| 
SIG=MCwCF\Esnq6Bs/XdmyfLe7rHcD4sVP2bzAhQ3IeHDoyyd6388jHsHD99sg36SG267gshssja77
end

ステップ 3

ライセンスキーを設定に貼り付けます。

重要

 

構成ファイルの先頭にライセンスキー情報を貼り付けて、システムがコンテキストを設定する前に期待される容量と機能を確保するようにします。

ステップ 4

「設定の確認と保存」の章の説明に従って、設定を保存します。

ライセンスの期限切れの動作

ライセンスの有効期限が切れると、30 日の猶予期間が設定され、ライセンス済みセッション使用および機能使用ライセンスの通常の使用が可能になります。これにより、サービスを中断せずに新しいライセンスを取得できます。

次の Exec モードのコマンドは、猶予期間の有効期限に設定された日付を含むライセンス情報を一覧表示します。
show license information

ライセンスキーの要求

システムのライセンスキーは、シスコのアカウント担当者から入手できます。ライセンスキーを生成するには、特定の情報が必要です。

  • SO または発注書情報

  • 必要なセッションキャパシティ

  • 必要な機能

  • ミッドプレーン（シャーシ）のシリアル番号

ASR 5500 シャーシのシリアル番号を取得するには、Exec モードのプロンプトで show card hardware 5 コマンドを入力します。次の例に示すように、「MEC」の見出しの下の「UDI Serial Number」を確認します。
MEC: 
  Description         : MEC 
  Cisco Part Number   : 73-14501-01 A0 
  UDI Serial Number   : FLM154300D8 
  UDI Product ID      : ASR55-MEC 
  UDI Version ID      : V01

アクティブシャーシとスタンバイシャーシの ICSR ライセンスキーは、各シャーシに一意にコードされます。ライセンスキーは個別に 2 つ必要です。

ライセンス情報の表示

ライセンスの詳細を表示するには、Exec モードで次のコマンドを入力します。

[local]host_name# show license information [ full | key [ full ] ]

ライセンスキーの削除

セッションおよび機能使用ライセンスキーを設定から削除するには、次の手順を実行します。セキュリティ管理者または管理者である必要があります。

configure 
   no license key 
   exit 
show license key

このコマンドの出力には、「No license key installed 」と表示されています。

管理カードの交換とライセンスキー

ライセンスキーは、ASR 5500 シャーシのミッドプレーン EEPROM に保存されます。MIO/UMIO は、これらのライセンスキーを共有します。交換用の MIO/UMIO にメモリカードをスワップする必要はありません。

ローカルユーザー管理アカウントの管理

設定ファイルを介して設定されたコンテキストレベルの管理アカウントとは異なり、ローカルユーザー管理アカウントの情報は、フラッシュメモリ内の別のファイルに保持され、ソフトウェアの共有設定タスク（SCT）によって管理されます。ローカルユーザーアカウントは ANSI T1.276-2003 に準拠するように設計されているため、システムにはこれらのタイプの管理ユーザーアカウントを管理するためのさまざまなメカニズムが備わっています。

詳細については、コンソールの AAA ベースの認証を無効化およびコンソール/VTY 回線でのローカルユーザーログインの制限を参照してください。

ローカルユーザーパスワードのプロパティの設定

ローカルユーザーアカウントのパスワードプロパティはグローバルに設定され、すべてのローカルユーザーアカウントに適用されます。システムでは、次のパスワードプロパティの設定がサポートされています。

  • Complexity：パスワードの複雑さは、ANSI T1.276-2003 に強制的に準拠させることができます。

  • History length：システムで追跡する必要がある以前のパスワードバージョンの数。

  • Maximum age：ユーザーが同じパスワードを使用できる期間。

  • Minimum number of characters to change：リセット時にパスワードで変更する必要がある文字数。

  • Minimum change interval：ユーザーがパスワードを変更できる頻度。

  • Minimum length：有効なパスワードに含める必要がある最小文字数。

  • Expiry warning：パスワードの有効期限の警告間隔（日数）。

  • Auto-generate：パスワードの長さを指定するオプションを使用して、自動的にパスワードを生成します。

上記パラメータそれぞれの詳細については、『Command Line Interface Reference』の「Global Configuration Mode Commands」の章で説明されている local-user password コマンドを参照してください。

ローカルユーザーのアカウント管理プロパティの設定

ローカルユーザーのアカウント管理には、アカウントのロックアウトとユーザーの一時停止が含まれています。

ローカルユーザーアカウントのロックアウト

ローカルユーザーアカウントは、次の理由で管理上ロックすることができます。

  • ログインの失敗：設定された最大ログイン失敗のしきい値に達しました。詳細については、『Command Line Interface Reference』の「Global Configuration Mode Commands」の章で説明されている local-user max-failed-logins コマンドを参照してください。

  • パスワードのエージング：設定された最大パスワードの有効期限に達しました。詳細については、『Command Line Interface Reference』の「Global Configuration Mode Commands」の章で説明されている local-user password コマンドを参照してください。

ロックアウトされたアカウントは、設定されたロックアウト時間に達するまで（『Command Line Interface Reference』の「Global Configuration Mode Commands」の章で説明されている local-user lockout-time コマンドを参照）、またはセキュリティ管理者がロックアウトをクリアするまで（『Command Line Interface Reference』の「Exec Mode Commands」の章で説明されている clear local-user コマンドを参照）、ユーザーはアクセスできません。


重要

ローカルユーザーの管理ユーザーアカウントは、ロックアウトを適用または拒否するように設定できます。詳細については、『Command Line Interface Reference 』の「Global Configuration Mode Commands」の章で説明されている local-user username コマンドを参照してください。

ローカルユーザーアカウントの一時停止

ローカルユーザーアカウントは、次のように一時停止することができます。

configure 
   suspend local-user name
次のように入力して、一時停止を削除できます。
configure 
   no suspend local-user name

ローカルユーザーパスワードの変更

ローカルユーザーの管理ユーザーは、Exec モードで password change コマンドを使用してパスワードを変更できます。ユーザーは、現在のパスワードと新しいパスワードを入力するように求められます。

セキュリティ管理者は、Exec モードで root プロンプトから次のコマンドを入力して、ローカルユーザーのパスワードをリセットできます。
[local]host_name# password change username name

name は、パスワードを変更するローカルユーザーアカウントの名前です。セキュリティ管理者がローカルユーザーのパスワードをリセットすると、ユーザーは次回ログイン時にパスワードを変更するように求められます。

新しいパスワードは、システムに設定されているパスワードプロパティに従う必要があります。