設定の管理
ショー |比較する |表示 xml コマンド出力
- ステートメントを追加(運用作成)
- ステートメントを削除(運用を削除)
- ステートメントを変更(オペレーションを削除して作成)
- メタデータを変更(非アクティブな属性と運用)
- アノテーションを追加(タグにコメントし、運用を作成)
- アノテーションを変更(タグにコメントし、運用を削除して作成)
- コンテナー内にステートメントを追加(運用を作成し、属性を挿入して入力)
- コンテナー内での順序を変更(運用を統合、属性を挿入、入力)
ステートメントを追加(運用作成)
以下の例では、ユニット0へのIPv4アドレス2.2.2.2の追加を表示しています。
name までのタグは、追加に関するコンテキストを提供します。operation="create"属性は、unit ステートメントが作成され、unit タグ内でコンフィギュレーションにより定義されていることを示します。
[edit interfaces et-0/0/0] user@host>show configuration | compare[edit interfaces et-0/0/0] + unit 0 { + family inet { + address 2.2.2.2/32; + } + } [edit interfaces et-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>et-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>
以下の例では、 et-0/0/0 インターフェイスからユニット0の削除を表示しています。 unit ステートメントに後続するコンフィギュレーションは削除されましたが、出力はされていません。
[edit interfaces et-0/0/0] user@host>show configuration | compare[edit interfaces et-0/0/0] - unit 0 { - family inet { - address 2.2.2.2/32; - } - } [edit interfaces et-0/0/0] user@host#show | compare | display xml<configuration> <interfaces> <interface> <name>et-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タグの値 file-3 は、既存の file ステートメント内の位置を表します。 -
この例では、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ステートメントを入れます。[edit system] compress-configuration-files;
-
現在の設定ファイルをコミットして、
compression-configuration-files文を含めます。現在の設定ファイルを圧縮するために、再度設定をコミットします。[edit system] user@host#
set compress-configuration-filesuser@host#commitcommit complete -
現在の運用設定ファイルを圧縮しない場合は、
[edit system]階層レベルにno-compress-configuration-filesステートメントを含めます。[edit system] no-compression-configuration-files;
-
現在の設定ファイルをコミットして、
no-compress-configuration-files文を含めます。現在の設定ファイルを解凍するために、再度設定をコミットしてください。[edit system] user@host#
set no-compress-configuration-filesuser@host#commitcommit complete
システム ストレージの空き容量
問題
形容
デバイスのシステム ファイルの保存領域が一杯になりました。スイッチを再起動しても問題は解決しません。
ファイル保存領域が一杯になった後、デバイス上で通常の操作を行うと、次のようなエラー メッセージが表示されます。
user@host%cliuser@host>configure/var: write failed, filesystem is full
解決
システム ファイルを削除して、デバイスのファイル ストレージをクリーンアップします。
-
システム ファイルのクリーンアップ(削除)依頼を発行する。
user@host>
request system storage cleanup削除するファイルの一覧が表示されます。
List 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/tmp内の一時ファイルを削除します] - 2 日以内にアクセスされていないファイルを削除します。 -
/var/crash内のすべてのクラッシュファイルを削除します—エラー発生時にデバイスが書き込まれたコアファイルを削除します。 -
[
/var/sw/pkg内のすべてのソフトウェア イメージ(*.tgzファイル)を削除します。ソフトウェアのアップグレード時に、このディレクトリにコピーされたソフトウェア イメージを削除します。
CLI でログファイルを回転させたり、不要なファイルを削除するには、次の手順に従います。
request system storage cleanup dry-run コマンドを発行すると、安全に削除できるファイルのリストを確認できます。dry-run アクションでは、request system storage cleanup コマンドを発行してファイルを削除する前に、リストを確認できます。