- play_arrow 概要
- play_arrow 今すぐ始めてみませんか
- play_arrow コンフィギュレーション ステートメントを使用したデバイスの設定
- play_arrow 運用コマンドを使用したデバイスの監視
- play_arrow 設定ステートメントと運用コマンド
設定の管理
show | compare | display xml コマンド出力
compare | display xmlフィルターは候補コンフィギュレーションを現在のコミットされたコンフィギュレーションと比較し、XMLでその2つのコンフィギュレーションの差異を表示します。コンフィギュレーションを比較するには、運用もしくはコンフィギュレーションのモードで、パイプ（|）記号のcompare | display xml後にを入力します。
運用モードでの例
user@host> show configuration | compare | display xml
コンフィギュレーションモードでの例
[edit]
user@host# show | compare | display xml
例えばのような、フィルcompareターのすぐ前に特定のコンフィギュレーション階層を入力できますshow configuration system syslog | compare | display xml。コンフィギュレーションモードでは、コマンドが適用される階層に移動できます。
比較フィルター機能との差異は、XMLで出力されます。タconfigurationグが出力を開始します。変更に関するコンテキストは、比較のルートと相対的な階層名タグで確立されます。要素変更の場合、変更の生じたタグで、operation属性が出力されます。この属性は、create、delete、または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グ内でコンフィギュレーションにより定義されていることを示しています。
[edit interfaces ge-0/0/0] user@host>show configuration | compare[edit interfaces ge-0/0/0] + unit 1 { + family inet { + address 2.2.2.2/32; + } + } [edit interfaces ge-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>ge-0/0/0</name> <unit nc:operation="create"> <name>1</name> <family> <inet> <address> <name>2.2.2.2/32</name> </address> </inet> </family> </unit> </interface> </interfaces> </configuration>
ステートメントを削除（運用を削除）
以下の例では、コンフィギュレーション階層での複雑でないステートメントの削除を表示しています。経由のタグは、削除に関するコンテキストを提供systemしています。operation="delete"属性は、servicesステートメントが削除されたことを示しています。、servicesステートメントに後続するコンフィギュレーションは削除されましたが、出力はされていません。
[edit system] user@host>show configuration | compare[edit system] - services { - ftp; - } [edit system] user@host#show | compare | display xml<configuration> <system> <services operation="delete"/> </system> </configuration>
以下の例では、ge-0/0/0インターフェイスからユニット1の削除を表示しています。unitステートメントに後続するコンフィギュレーションは削除されましたが、出力はされていません。
[edit interfaces ge-0/0/0] user@host>show configuration | compare[edit interfaces ge-0/0/0] - unit 1 { - family inet { - address 2.2.2.2/32; - } - } [edit interfaces ge-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>ge-0/0/0</name> <unit nc:operation="delete"> <name>1</name> </unit> </interface> </interfaces> </configuration>
以下の例では、apply-groupsコンフィギュレーションの削除を表示しています。削除されたグループは、出力で表示されていません。
[edit] user@host#delete apply-groups[edit] user@host>show configuration | compare[edit] - apply-groups [ g1 g2 g3 ]; [edit] user@host#show | compare | display xml<configuration> <apply-groups operation="delete"/> </configuration>
ステートメントを変更（運用を削除して作成）
以下の例では、階層でのステートメントの変更を表示しています。経由のタグは、変更に関するコンテキストを提供systemしています。operation="delete"属性は、host-nameステートメントが削除されたことを示しています。、host-nameステートメントに続くコンフィギュレーションは削除されましたが、これは出力で表示されていません。属operation="create"性は、ステートhost-nameメントがすでに作成され、タhost-nameグ内でコンフィギュレーションにより定義されていることを示しています。
[edit system] user@host>show configuration | compare[edit system] - host-name router1; + host-name router2; [edit system] user@host#show | compare | display xml<configuration> <system> <host-name nc:operation="delete"/> <host-name nc:operation="create">router2</host-name> </system> </configuration>
メタデータを変更（非アクティブな属性と運用）
以下の例では、階層でのステートメントの非アクティブ化を表示しています。経由のタグは、変更に関するコンテキストを提供systemしています。inactive="inactive"属性は、syslogステートメントが無効にされたことを示しています。
[edit system] user@host>show configuration | compare[edit system] ! inactive: syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <syslog inactive="inactive"/> </system> </configuration>
以下の例では、非アクティブなステートsyslogメントの追加を表示しています。operation="create"属性は、syslogステートメントがすでに作成され、syslogタグ内でコンフィギュレーションにより定義されていることを示しています。inactive="inactive"属性は、syslogステートメントが無効にされたことを示しています。
[edit system] user@host>show configuration | compare[edit system] + inactive: syslog { + file foo { + any any; + } + } [edit system] user@host#show | compare | display xml<configuration> <system> <syslog nc:operation="create" inactive="inactive"> <file> <name>foo</name> <contents> <name>any</name> <any/> </contents> </file> </syslog> </system> </configuration>
アノテーションを追加（タグにコメントし、運用を作成）
以下の例では、ステートメントへのコメントの追加を表示しています。syslog経由のタグは、アノテーションに関するコンテキストを提供しています。タjunos:commentグに対する属operation="create"性は、コメントが階[edit system syslog]層に追加されたことを示しています。
[edit system] user@host>show configuration | compare[edit system] + /* my-comments-simple */ syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <junos:comment nc:operation="create">/* my-comments-simple */</junos:comment> <syslog/> </system> </configuration>
以下の例では、ステートメントへのコメントの追加を表示しています。syslog経由のタグは、アノテーションに関するコンテキストを提供しています。junos:commentタグに対するoperation="create"属性は、syslogタグ内でのステートメント出力に対して、コメントが[edit system syslog]階層に追加されたことを示しています。
[edit system syslog] user@host>show configuration | compare+ /* my-comments-ele */ file f1 { ... } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <junos:comment nc:operation="create">/* my-comments-elem */</junos:comment> <file> <name>f1</name> </file> </syslog> </system> </configuration>
アノテーションを変更（タグにコメントし、運用を削除して作成）
以下の例では、ステートメントに対するコメントの変更を表示しています。system経由のタグは、アノテーションに関するコンテキストを提供しています。
タ
junos:commentグに対する属operation="delete"性は、ステートsyslogメントで、コメントが階[edit system]層から削除されたことを示しています。タ
junos:commentグに対する属operation="create"性は、ステートsyslogメントに対して、コメントが階[edit system]層に追加されたことを示しています。
[edit system] user@host>show configuration | compare- /* my-comments-1 */ + /* my-comments-2 */ syslog { ... } [edit system] user@host#show | compare | display xml<configuration> <system> <junos:comment nc:operation="delete"/> <junos:comment nc:operation="create">/* my-comments-2 */</junos:comment> <syslog/> </system> </configuration>
コンテナー内にステートメントを追加（運用を作成し、属性を挿入、入力）
以下の例では、階[edit system syslog]層でのステートfileメントの追加を表示しています。syslog経由のタグは、追加に関するコンテキストを提供しています。
fileタグに対するoperation="create"属性は、fileステートメントが追加されたことを示しています。属
yang:insert="after"性は、属yang:key="[name='file-1']"性によって示された位置の後にファイルが追加されたことを示しています。ファイル-1値は、既存の
fileステートメント内での位置を表し、そこでは1つが最初のファイルです。この例では、最初のファイルの後に新しい
fileステートメントが追加されました。
[edit system syslog] user@host>show configuration | compare[edit system syslog] file file-1 { ... } + file file-2 { + any any; + } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <file nc:operation="create" yang:insert="after" yang:key="[name='file-1']"> <name>file-2</name> <contents> <name>any</name> <any/> </contents> </file> </syslog> </system> </configuration>
コンテナー内で順序を変更（運用を統合、属性を挿入、入力）
以下の例では、階[edit system syslog]層でのステートfileメントの順序の変更を表示しています。経由のタグは、変更に関するコンテキストを提供syslogしています。
タ
fileグに対する属operation="merge"性は、既存のステートfileメントが移動されたことを示しています。属
yang:insert="after"性は、そのファイルが、属yang:key="[name='file-1']"性によって示された位置のファイルの後に移動されたことを示しています。ファイル-1値は、既存の
fileステートメント内での位置を表し、そこでは1つが最初のファイルです。タ
nameグでの値、ファイル-3は、既存のファイルステートメント内の位置を表しています。この例では、3番目の位置にある
fileステートメントは、最初のファイルの後に移動されました。
[edit system syslog] user@host>show configuration | compare[edit system syslog] file f1 { ... } ! file f3 { ... } [edit system syslog] user@host#show | compare | display xml<configuration> <system> <syslog> <file nc:operation="merge" yang:insert="after" yang:key="[name='file-1']"> <name>file-3</name> </file> </syslog> </system> </configuration>
直近にコミットされた設定に戻る
直近のコミットされた設定に戻し、アクティブにせずに設定モードに読み込むには、rollback 設定モード コマンドを使用します。
[edit]
user@host# rollback
load complete
ロールバックする設定を有効にするには、 コマcommitンドを使用します。
[edit] user@host#rollbackload complete [edit] user@host#commit
前回コミットした設定に戻す
このトピックでは、最近コミットされた設定よりも以前の設定に戻す方法について説明します。
以前の設定に戻す例
以前のコンフィグレーションに戻るには、rollbackコマンドにコンフィグレーション番号（0～49）を含めます。最も新しく保存されたコンフィギュレーションは 0 番（システムが戻るデフォルト コンフィギュレーション）、最も古いコンフィギュレーションは 49 番です。
例：
[edit]
user@host# rollback number
load complete
過去の設定を表示する例
過去のコンフィグレーションを表示するには、rollback ?コマンドを使用します。ロールバック番号、日付、時刻、変更をコミットしたユーザー名、コミット方法などが含まれます。
例：
[edit]
user@host# rollback ?
Possible completions:
<[Enter]> Execute this command
<number> Numeric argument
0 2018-02-27 12:52:10 PST by abc via cli
1 2018-02-26 14:47:42 PST by def via cli
2 2018-02-14 21:55:45 PST by ghi via cli
3 2018-02-10 16:11:30 PST by jkl via cli
4 2018-02-10 16:02:35 PST by mno via cli
5 2018-03-16 15:10:41 PST by pqr via cli
6 2018-03-16 14:54:21 PST by stu via cli
7 2018-03-16 14:51:38 PST by vwx via cli
8 2018-03-16 14:43:29 PST by yzz via cli
9 2018-03-16 14:15:37 PST by abc via cli
10 2018-03-16 14:13:57 PST by def via cli
11 2018-03-16 12:57:19 PST by root via other
12 2018-03-16 10:45:23 PST by root via other
13 2018-03-16 10:08:13 PST by root via other
14 2018-03-16 01:20:56 PST by root via other
15 2018-03-16 00:40:37 PST by ghi via cli
16 2018-03-16 00:39:29 PST by jkl via cli
17 2018-03-16 00:32:36 PST by mno via cli
18 2018-03-16 00:31:17 PST by pqr via cli
19 2018-03-15 19:59:00 PST by stu via cli
20 2018-03-15 19:53:39 PST by vwx via cli
21 2018-03-15 18:07:19 PST by yzz via cli
22 2018-03-15 17:59:03 PST by abc via cli
23 2018-03-15 15:05:14 PST by def via cli
24 2018-03-15 15:04:51 PST by ghi via cli
25 2018-03-15 15:03:42 PST by jkl via cli
26 2018-03-15 15:01:52 PST by mno via cli
27 2018-03-15 14:58:34 PST by pqr via cli
28 2018-03-15 13:09:37 PST by root via other
29 2018-03-12 11:01:20 PST by stu via cli
30 2018-03-12 10:57:35 PST by vwx via cli
31 2018-03-11 10:25:07 PST by yzz via cli
32 2018-03-10 23:40:58 PST by abc via cli
33 2018-03-10 23:40:38 PST by def via cli
34 2018-03-10 23:14:27 PST by ghi via cli
35 2018-03-10 23:10:16 PST by jkl via cli
36 2018-03-10 23:01:51 PST by mno via cli
37 2018-03-10 22:49:57 PST by pqr via cli
38 2018-03-10 22:24:07 PST by stu via cli
39 2018-03-10 22:20:14 PST by vwx via cli
40 2018-03-10 22:16:56 PST by yzz via cli
41 2018-03-10 22:16:41 PST by abc via cli
42 2018-03-10 20:44:00 PST by def via cli
43 2018-03-10 20:43:29 PST by ghi via cli
44 2018-03-10 20:39:14 PST by jkl via cli
45 2018-03-10 20:31:30 PST by root via other
46 2018-03-10 18:57:01 PST by mno via cli
47 2018-03-10 18:56:18 PST by pqr via cli
48 2018-03-10 18:47:49 PST by stu via cli
49 2018-03-10 18:47:34 PST by vw via cli
| Pipe through a command
[edit]
設定バージョンの比較について
設定モードでのみ、設定を変更した場合、候補の設定を以前のバージョンと比較することができます。バージョンを比較するには、 compare コマンドを使用して設定を表示します。compare コマンドは、候補コンフィギュレーションを現在のコミットされたコンフィギュレーションまたはコンフィギュレーション・ファイルと比較します。このコマンドは、2 つの設定の違いも表示します。
コンフィギュレーションを比較するには、パイプの後に compare コマンドを指定します。
[edit]
user@host# show | compare (filename| rollback n)
filenameは、構成ファイルへのフルパスです。ファイルは適切な形式である必要があります。ステートメントの階層。nは、以前にコミットされた構成のリストへのインデックスです。最後に保存された設定は数0で、最も古い保存設定は番号 49です。引数を指定しない場合、システムは候補コンフィギュレーションをアクティブなコンフィギュレーション ファイル(/config/juniper.conf)と比較します。
比較出力では、以下のステートメントのプレフィックスに以下の記号が含まれています。
候補構成の場合のみ: プラス記号 (+)。
比較ファイルのみ: マイナス記号 (-)。
変更;1 つのブランク・スペース ()。
次の例は、さまざまな変更を示し、その後に候補コンフィギュレーションとアクティブなコンフィギュレーションの比較を示します。この例では、 [edit protocols bgp] 階層レベルで行われた変更のみを示しています。
[edit] user@host#edit protocols bgp[edit protocols bgp] user@host#showgroup my-group { type internal; hold-time 60; advertise-inactive; allow 10.1.1.1/8; } group fred { type external; peer-as 33333; allow 10.2.2.2/8; } group test-peers { type external; allow 10.3.3.3/8; } [edit protocols bgp] user@host#set group my-group hold-time 90[edit protocols bgp] user@host#delete group my-group advertise-inactive[edit protocols bgp] user@host#set group fred advertise-inactive[edit protocols bgp] user@host#delete group test-peers[edit protocols bgp] user@host#show | compare[edit protocols bgp group my-group] -hold-time 60; +hold-time 90; -advertise-inactive; [edit protocols bgp group fred] +advertise-inactive; [edit protocols bgp] -group test-peers { -type external; -allow 10.3.3.3/8; } [edit protocols bgp] user@host#showgroup my-group { type internal; hold-time 90; allow 10.1.1.1/8; } group fred { type external; advertise-inactive; peer-as 3333; allow 10.2.2.2/8; }
設定リビジョン識別子の使用
すべてのコミットには、設定リビジョン識別子（CRI）が関連付けられます。CRIは、ロールバックインデックスとは異なり、新しい設定がコミットされた場合に変更されない一意の文字列です。
コミットされた設定のCRIは固定されているため、ロールバックインデックスを使用する場合と比べてメリットがあります。ネットワーク管理システム（NMS）では、特定のコミット向けにCRIをキャッシュできます。後日、NMSでデバイス上の現在の設定にあるCRIとキャッシュされた値を比較することで、例えばメンテナンスウィンドウ中などに、他のシステムデバイスによってアウトオブバンド管理が変更されていないかなどを検出することができます。
さらに、Junos OSおよびJunos OS Evolvedリリース20.4R1以降、以下へのコミットされた設定に関連付けられたCRIを使用できるようになりました。
設定を表示する。
2つの設定を比較する。
設定を戻す。
その設定に関連付けられた現在のロールバックインデックスを取得する。
各コミットに関連付けられているCRIを表示するには、show system commit include-configuration-revisionコマンドを使用してください。これにより、各コミットに対するシステムコミットの履歴とCRIが表示されます。
user@host> show system commit include-configuration-revision 0 2020-08-02 00:42:58 IST by user via cli re0-1596309177-4 1 2020-08-02 00:42:53 IST by user via cli re0-1596309173-3 2 2020-08-02 00:42:50 IST by user via cli re0-1596309170-2 3 2020-08-02 00:42:40 IST by user via other re0-1596309160-1
または、show system rollback number configuration-revisionコマンドを発行することで、特定のロールバック番号のCRIを表示することもできます。
user@host> show system rollback 0 configuration-revision The corresponding configuration revision is: re0-1596309177-4
特定のコミット用のCRI文字列が利用できるようになったら、show system configuration revision cri-stringコマンドでその設定を表示することができます。
user@host> show system configuration revision re0-1596309177-4
両方のCRIでcompareオプションを使用することで、2つの設定を比較できます。
user@host> show system configuration revision compare re0-1596309177-4 re0-1596309173-3
rollback-number cri-stringオプションを含むことで、特定のCRIのロールバック番号を表示することもできます。
user@host> show system configuration revision rollback-number re0-1596309160-1 The corresponding rollback number is: 3
さらに、設定モードでは、ロールバックインデックスではなくCRIを指定することで、設定をロールバックさせることができます。
[edit] user@host# rollback revision re0-1596309160-1 load complete [edit] user@host# commit
コンフィグレーションのファイル保存
デバイスの設定をファイルに保存することで、任意のプレーン テキスト エディターで編集することができます。現在の設定を ASCII ファイルに保存することができます。この場合、コミットされていない変更も含めて、現在の設定のまま保存されます。複数のユーザーが設定を変更する場合、すべてのユーザーによる変更が保存されます。
ソフトウェアの設定変更を ASCII ファイルに保存するには、saveコンフィギュレーション モード コマンドを使用します。
[edit]
user@host# save filename
[edit]
user@host#
現在のレベルのステートメント階層（およびそれ以下）の内容が、それを含むステートメント階層とともに保存されます。これにより、ステートメント階層を完全に指定しながら、コンフィギュレーションの一部を保存することができます。
デフォルトでは、設定はフラッシュド ライブにあるホーム ディレクトリのファイルに保存されます。
このコマンドを階層内の任意の場所（トップレベルを除く）から発行すると、ファイルの先頭に自動的にreplaceタグが含まれます。タreplaceグを使用すると、ファイルから設定を読み込む方法を制御することができます。
例：
user@host>file show /var/home/user/myconfreplace: protocols { bgp { disable; group int { type internal; } } isis { disable; interface all { level 1 disable; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; ... } }
現在の設定ファイルの圧縮について
デフォルトでは、現在の運用設定ファイルは圧縮されており、/configファイル システムjuniper.conf.gz内のファイルに格納されている。運用中のコンフィギュレーションファイルは、過去 3 回のコミットされたバージョンとともに保存されます。大規模なネットワークを使用している場合、現在の設定ファイルが/configファイルシステムの使用可能な領域を超えてしまうことがあります。現在の設定ファイルを圧縮することで、ファイル システムに収まるようになり、通常、ファイル サイズを 90％ 削減することができます。現在の運用設定ファイルのサイズが 3 メガバイト（MB）に達した時点で、圧縮することをお勧めします。
現在の設定ファイルを圧縮すると、設定ファイル名が変更されます。/configファイル システム内のファイルのサイズを確認するには、file list /config detail コマンドを実行します。
設定ファイルを圧縮して（これはデフォルトです）、必要なディスク容量を最小にすることをお勧めします。
現在の設定ファイルを圧縮したい場合は、
[edit system]階層にcompress-configuration-filesステートメントを入れます。content_copy zoom_out_map[edit system] compress-configuration-files;
compression-configuration-files文が含まれるように現在の設定ファイルをコミットします。現在の設定ファイルを圧縮するために、再度設定をコミットします。content_copy zoom_out_map[edit system] user@host#
set compress-configuration-filesuser@host#commitcommit complete現在の運用設定ファイルを圧縮しない場合は、
[edit system]階層にno-compress-configuration-filesステートメントを記述します。content_copy zoom_out_map[edit system] no-compression-configuration-files;
no-compress-configuration-files文が含まれるように現在の設定ファイルをコミットします。現在の設定ファイルを解凍するために、再度設定をコミットしてください。content_copy zoom_out_map[edit system] user@host#
set no-compress-configuration-filesuser@host#commitcommit complete
システム ストレージの空き容量
問題点
説明
デバイスのシステム ファイルの保存領域が一杯になりました。スイッチを再起動しても問題は解決しません。
ファイル保存領域が一杯になった後、デバイス上で通常の操作を行うと、次のようなエラー メッセージが表示されます。
user@host%cliuser@host>configure/var: write failed, filesystem is full
ソリューション
システム ファイルを削除して、デバイスのファイル ストレージをクリーンアップします。
システム ファイルのクリーンアップ（削除）依頼を発行する。
content_copy zoom_out_mapuser@host>
request system storage cleanup削除するファイルの一覧が表示されます。
content_copy zoom_out_mapList of files to delete: Size Date Name 11B Jul 26 20:55 /var/jail/tmp/alarmd.ts 124B Aug 4 18:05 /var/log/default-log-messages.0.gz 1301B Jul 26 20:42 /var/log/install.0.gz 387B Jun 3 14:37 /var/log/install.1.gz 4920B Aug 4 18:05 /var/log/messages.0.gz 20.0K Jul 26 21:00 /var/log/messages.1.gz 16.3K Jun 25 13:45 /var/log/messages.2.gz 804B Aug 4 18:05 /var/log/security.0.gz 16.8K Aug 3 11:15 /var/log/security.1.gz 487B Aug 4 18:04 /var/log/wtmp.0.gz 855B Jul 29 22:54 /var/log/wtmp.1.gz 920B Jun 30 16:32 /var/log/wtmp.2.gz 94B Jun 3 14:36 /var/log/wtmp.3.gz 353.2K Jun 3 14:37 /var/sw/pkg/jloader-qfx-11.2I20110303_1117_dc-builder.tgz 124.0K Jun 3 14:30 /var/tmp/gres-tp/env.dat 0B Apr 14 16:20 /var/tmp/gres-tp/lock 0B Apr 14 17:37 /var/tmp/if-rtsdb/env.lck 12.0K Jul 26 20:55 /var/tmp/if-rtsdb/env.mem 2688.0K Jul 26 20:55 /var/tmp/if-rtsdb/shm_usr1.mem 132.0K Jul 26 20:55 /var/tmp/if-rtsdb/shm_usr2.mem 2048.0K Jul 26 20:55 /var/tmp/if-rtsdb/trace.mem 155B Jul 26 20:55 /var/tmp/krt_gencfg_filter.txt 0B Jul 26 20:55 /var/tmp/rtsdb/if-rtsdb 1400.6K Aug 3 10:13 /var/tmp/sfid.core.0.gz 1398.9K Aug 3 17:01 /var/tmp/sfid.core.1.gz Delete these files ? [yes,no] (no)を選択すると、ファイルが削除
yesされます。デバイスを再起動します。
定期的にシステム ファイルのストレージをクリーンアップする要求を出すことをお勧めします。システムファイルの保存領域をクリーンアップすることで、デバイスのパフォーマンスを最適化することができます。
CLI でファイルをクリーンアップします。
CLI のコマrequest system storage cleanupンドを使って、ログファイルを回転させたり、デバイス上の不要なファイルを削除することができますストレージの空き容量が少なくなってきたら、ファイルクリーンアップの手順で、削除可能なファイルを迅速に識別します。
ファイルのクリーンアップ手順では、以下の作業を行います:
ログファイルを回転します。現在のログファイルにすべての情報を保管し、古いアーカイブを削除して、新しいログファイルを作成します。
その
/var/logのログファイルを削除します。現在書き込まれていないファイルを削除します。その一時ファイルを削除します。
/var/tmp2日以内にアクセスされていないファイルを削除しますそののすべてのクラッシュファイルを削除します。
/var/crashエラー発生時にデバイスが書き込まれたコアファイルを削除します/var/sw/pkgにあるすべてのソフトウェアイメージ（*.tgzファイル）を削除します。ソフトウェアのアップグレード時に、このディレクトリにコピーされたソフトウェアイメージを削除します。
CLI でログファイルを回転させたり、不要なファイルを削除するには、次の手順に従います。
そのコマrequest system storage cleanup dry-runンドを発行すると、安全に削除できるファイルのリストを確認できます。dry-run アクションでは、コマrequest system storage cleanupンドを発行してファイルを削除する前に、リストを確認できます。
SRX シリーズファイアウォールでは、その/var階層は（ルートパーティションではなく）別のパーティションでホストされます容量不足のために、オペレーティングシステムのインストールに失敗した場合は、次の手順に従います。
そのコマ
request system storage cleanupンドを使用して、一時ファイルを削除しますルートパーティションと
/var階層下の両方で、ユーザーが作成したファイルを削除します
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。
show | compare | display xmlコマンドは、XML出力での<configuration>タグを除外します。