Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

設定の管理

show | compare | display xml コマンド出力

compare | display xmlフィルターは候補コンフィギュレーションを現在のコミットされたコンフィギュレーションと比較し、XMLでその2つのコンフィギュレーションの差異を表示します。コンフィギュレーションを比較するには、運用もしくはコンフィギュレーションのモードで、パイプ(|)記号のcompare | display xml後にを入力します。

運用モードでの例

コンフィギュレーションモードでの例

例えばのような、フィルcompareターのすぐ前に特定のコンフィギュレーション階層を入力できますshow configuration system syslog | compare | display xml。コンフィギュレーションモードでは、コマンドが適用される階層に移動できます。

比較フィルター機能との差異は、XMLで出力されます。タconfigurationグが出力を開始します。変更に関するコンテキストは、比較のルートと相対的な階層名タグで確立されます。要素変更の場合、変更の生じたタグで、operation属性が出力されます。この属性は、createdelete、またはmergeの値を持っています。メタデータの変更の場合、そのメタデータ名が特定されます。例えば、ステートメントが非アクティブと区分された場合、属inactive="inactive"性と値が出力されます。nc名前空間は、オペレーティングシステム名前空間ではなく、NETCONF名前空間においての属性の存在を示す必要がある場合に使用されます。

注:

Junos OSリリース16.2R2以降、比較が差異を返還しない場合、もしくは、比較が非ネイティブデータの差異(例えばOpenConfigデータモデルと関連するコンフィギュレーションデータなど)だけを返還する場合、show | compare | display xmlコマンドは、XML出力での<configuration>タグを除外します。

以下のセクションでは、特定のタイプのコンフィギュレーションに対して生成されるXMLについて説明します。比較のために、対応するテキスト変更が表示されています。

ステートメントを追加(運用作成)

以下の例では、ユニット1へのIPv4アドレス2.2.2.2の追加を表示しています。

name経由のタグは、追加に関するコンテキストを提供しています。属operation="create"性は、ステートunitメントがすでに作成され、タunitグ内でコンフィギュレーションにより定義されていることを示しています。

ステートメントを削除(運用を削除)

以下の例では、コンフィギュレーション階層での複雑でないステートメントの削除を表示しています。経由のタグは、削除に関するコンテキストを提供systemしています。operation="delete"属性は、servicesステートメントが削除されたことを示しています。、servicesステートメントに後続するコンフィギュレーションは削除されましたが、出力はされていません。

以下の例では、ge-0/0/0インターフェイスからユニット1の削除を表示しています。unitステートメントに後続するコンフィギュレーションは削除されましたが、出力はされていません。

以下の例では、apply-groupsコンフィギュレーションの削除を表示しています。削除されたグループは、出力で表示されていません。

ステートメントを変更(運用を削除して作成)

以下の例では、階層でのステートメントの変更を表示しています。経由のタグは、変更に関するコンテキストを提供systemしています。operation="delete"属性は、host-nameステートメントが削除されたことを示しています。、host-nameステートメントに続くコンフィギュレーションは削除されましたが、これは出力で表示されていません。属operation="create"性は、ステートhost-nameメントがすでに作成され、タhost-nameグ内でコンフィギュレーションにより定義されていることを示しています。

メタデータを変更(非アクティブな属性と運用)

以下の例では、階層でのステートメントの非アクティブ化を表示しています。経由のタグは、変更に関するコンテキストを提供systemしています。inactive="inactive"属性は、syslogステートメントが無効にされたことを示しています。

以下の例では、非アクティブなステートsyslogメントの追加を表示しています。operation="create"属性は、syslogステートメントがすでに作成され、syslogタグ内でコンフィギュレーションにより定義されていることを示しています。inactive="inactive"属性は、syslogステートメントが無効にされたことを示しています。

アノテーションを追加(タグにコメントし、運用を作成)

以下の例では、ステートメントへのコメントの追加を表示しています。syslog経由のタグは、アノテーションに関するコンテキストを提供しています。タjunos:commentグに対する属operation="create"性は、コメントが階[edit system syslog]層に追加されたことを示しています。

以下の例では、ステートメントへのコメントの追加を表示しています。syslog経由のタグは、アノテーションに関するコンテキストを提供しています。junos:commentタグに対するoperation="create"属性は、syslogタグ内でのステートメント出力に対して、コメントが[edit system syslog]階層に追加されたことを示しています。

アノテーションを変更(タグにコメントし、運用を削除して作成)

以下の例では、ステートメントに対するコメントの変更を表示しています。system経由のタグは、アノテーションに関するコンテキストを提供しています。

  • junos:commentグに対する属operation="delete"性は、ステートsyslogメントで、コメントが階[edit system]層から削除されたことを示しています。

  • junos:commentグに対する属operation="create"性は、ステートsyslogメントに対して、コメントが階[edit system]層に追加されたことを示しています。

コンテナー内にステートメントを追加(運用を作成し、属性を挿入、入力)

以下の例では、階[edit system syslog]層でのステートfileメントの追加を表示しています。syslog経由のタグは、追加に関するコンテキストを提供しています。

  • fileタグに対するoperation="create"属性は、fileステートメントが追加されたことを示しています。

  • yang:insert="after"性は、属yang:key="[name='file-1']"性によって示された位置の後にファイルが追加されたことを示しています。

  • ファイル-1値は、既存のfileステートメント内での位置を表し、そこでは1つが最初のファイルです。

  • この例では、最初のファイルの後に新しいfileステートメントが追加されました。

コンテナー内で順序を変更(運用を統合、属性を挿入、入力)

以下の例では、階[edit system syslog]層でのステートfileメントの順序の変更を表示しています。経由のタグは、変更に関するコンテキストを提供syslogしています。

  • fileグに対する属operation="merge"性は、既存のステートfileメントが移動されたことを示しています。

  • yang:insert="after"性は、そのファイルが、属yang:key="[name='file-1']"性によって示された位置のファイルの後に移動されたことを示しています。

  • ファイル-1値は、既存のfileステートメント内での位置を表し、そこでは1つが最初のファイルです。

  • nameグでの値、ファイル-3は、既存のファイルステートメント内の位置を表しています。

  • この例では、3番目の位置にあるfileステートメントは、最初のファイルの後に移動されました。

直近にコミットされた設定に戻る

直近のコミットされた設定に戻し、アクティブにせずに設定モードに読み込むには、rollback 設定モード コマンドを使用します。

ロールバックする設定を有効にするには、 コマcommitンドを使用します。

前回コミットした設定に戻す

このトピックでは、最近コミットされた設定よりも以前の設定に戻す方法について説明します。

以前の設定に戻す例

以前のコンフィグレーションに戻るには、rollbackコマンドにコンフィグレーション番号(0~49)を含めます。最も新しく保存されたコンフィギュレーションは 0 番(システムが戻るデフォルト コンフィギュレーション)、最も古いコンフィギュレーションは 49 番です。

例:

過去の設定を表示する例

過去のコンフィグレーションを表示するには、rollback ?コマンドを使用します。ロールバック番号、日付、時刻、変更をコミットしたユーザー名、コミット方法などが含まれます。

例:

設定バージョンの比較について

設定モードでのみ、設定に変更を加えた場合、候補コンフィギュレーションを以前のバージョンと比較することができます。バージョンを比較するには、 コマンドを compare 使用して設定を表示します。コマンドは compare 、候補コンフィギュレーションを現在のコミットされたコンフィギュレーションまたはコンフィギュレーション・ファイルと比較します。このコマンドは、2 つのコンフィギュレーションの違いも表示します。

設定を比較するには、パイプの後に compare コマンドを指定します。

  • filename は、設定ファイルへのフルパスです。ファイルの形式は適切でなければなりません。ステートメントの階層です。

  • n は、以前にコミットされた構成のリストに含まれているインデックスです。最後に保存されたコンフィギュレーションは番号 0 で、最も古いコンフィギュレーションは番号 49 です。引数を指定しない場合、システムは候補コンフィギュレーションをアクティブなコンフィギュレーション・ファイル()と比較します。/config/juniper.conf

比較出力では、次のステートメントのプレフィックスに以下のシンボルが含まれています。

  • 候補コンフィギュレーションのみで: 正符号(+)です。

  • 比較ファイルのみ: マイナス記号(-)です。

  • 変更;1 つのブランク・スペース ()。

次の例では、さまざまな変更を示し、続いて候補コンフィギュレーションとアクティブなコンフィギュレーションの比較を行います。この例では、 階層レベルで [edit protocols bgp] 行われた変更のみを表示しています。

コンフィグレーションのファイル保存

デバイスの設定をファイルに保存することで、任意のプレーン テキスト エディターで編集することができます。現在の設定を ASCII ファイルに保存することができます。この場合、コミットされていない変更も含めて、現在の設定のまま保存されます。複数のユーザーが設定を変更する場合、すべてのユーザーによる変更が保存されます。

ソフトウェアの設定変更を ASCII ファイルに保存するには、saveコンフィギュレーション モード コマンドを使用します。

現在のレベルのステートメント階層(およびそれ以下)の内容が、それを含むステートメント階層とともに保存されます。これにより、ステートメント階層を完全に指定しながら、コンフィギュレーションの一部を保存することができます。

デフォルトでは、設定はフラッシュド ライブにあるホーム ディレクトリのファイルに保存されます。

このコマンドを階層内の任意の場所(トップレベルを除く)から発行すると、ファイルの先頭に自動的にreplaceタグが含まれます。タreplaceグを使用すると、ファイルから設定を読み込む方法を制御することができます。

例:

現在の設定ファイルの圧縮について

デフォルトでは、現在の運用設定ファイルは圧縮されており、/configファイル システムjuniper.conf.gz内のファイルに格納されている。運用中のコンフィギュレーションファイルは、過去 3 回のコミットされたバージョンとともに保存されます。大規模なネットワークを使用している場合、現在の設定ファイルが/configファイルシステムの使用可能な領域を超えてしまうことがあります。現在の設定ファイルを圧縮することで、ファイル システムに収まるようになり、通常、ファイル サイズを 90% 削減することができます。現在の運用設定ファイルのサイズが 3 メガバイト(MB)に達した時点で、圧縮することをお勧めします。

現在の設定ファイルを圧縮すると、設定ファイル名が変更されます。/configファイル システム内のファイルのサイズを確認するには、file list /config detail コマンドを実行します。

注:

設定ファイルを圧縮して(これはデフォルトです)、必要なディスク容量を最小にすることをお勧めします。

  • 現在の設定ファイルを圧縮したい場合は、[edit system]階層にcompress-configuration-filesステートメントを入れます。

  • compression-configuration-files文が含まれるように現在の設定ファイルをコミットします。現在の設定ファイルを圧縮するために、再度設定をコミットします。

  • 現在の運用設定ファイルを圧縮しない場合は、[edit system]階層にno-compress-configuration-filesステートメントを記述します。

  • no-compress-configuration-files文が含まれるように現在の設定ファイルをコミットします。現在の設定ファイルを解凍するために、再度設定をコミットしてください。

システム ストレージの空き容量

問題点

説明

デバイスのシステム ファイルの保存領域が一杯になりました。スイッチを再起動しても問題は解決しません。

ファイル保存領域が一杯になった後、デバイス上で通常の操作を行うと、次のようなエラー メッセージが表示されます。

ソリューション

システム ファイルを削除して、デバイスのファイル ストレージをクリーンアップします。

  1. システム ファイルのクリーンアップ(削除)依頼を発行する。

    削除するファイルの一覧が表示されます。

  2. を選択すると、ファイルが削除yesされます。

  3. デバイスを再起動します。

ベストプラクティス: ベスト プラクティス

定期的にシステム ファイルのストレージをクリーンアップする要求を出すことをお勧めします。システムファイルの保存領域をクリーンアップすることで、デバイスのパフォーマンスを最適化することができます。

CLI でファイルをクリーンアップします。

CLI のコマrequest system storage cleanupンドを使って、ログファイルを回転させたり、デバイス上の不要なファイルを削除することができますストレージの空き容量が少なくなってきたら、ファイルクリーンアップの手順で、削除可能なファイルを迅速に識別します。

ファイルのクリーンアップ手順では、以下の作業を行います:

  • ログファイルを回転します。現在のログファイルにすべての情報を保管し、古いアーカイブを削除して、新しいログファイルを作成します。

  • その/var/logのログファイルを削除します。現在書き込まれていないファイルを削除します。

  • その一時ファイルを削除します。/var/tmp2日以内にアクセスされていないファイルを削除します

  • そののすべてのクラッシュファイルを削除します。/var/crashエラー発生時にデバイスが書き込まれたコアファイルを削除します

  • /var/sw/pkgにあるすべてのソフトウェアイメージ(*.tgzファイル)を削除します。ソフトウェアのアップグレード時に、このディレクトリにコピーされたソフトウェアイメージを削除します。

CLI でログファイルを回転させたり、不要なファイルを削除するには、次の手順に従います。

  1. CLI で動作モードに入ります。
  2. ログファイルを回転させ、安全に削除できるファイルを識別します。

    デバイスがログファイルを回転させ、削除可能なファイルを表示します。

  3. プロンプトでyesを入力すると、ファイルが削除されます。
注:

そのコマrequest system storage cleanup dry-runンドを発行すると、安全に削除できるファイルのリストを確認できます。dry-run アクションでは、コマrequest system storage cleanupンドを発行してファイルを削除する前に、リストを確認できます。

注:

SRX シリーズ デバイスでは、その/var階層は(ルートパーティションではなく)別のパーティションでホストされます容量不足のために、オペレーティングシステムのインストールに失敗した場合は、次の手順に従います。

  • そのコマrequest system storage cleanupンドを使用して、一時ファイルを削除します

  • ルートパーティションと/var階層下の両方で、ユーザーが作成したファイルを削除します

リリース履歴テーブル
リリース
説明
16.2R2
Junos OSリリース16.2R2以降、比較が差異を返還しない場合、もしくは、比較が非ネイティブデータの差異(例えばOpenConfigデータモデルと関連するコンフィギュレーションデータなど)だけを返還する場合、show | compare | display xmlコマンドは、XML出力での<configuration>タグを除外します。