設定の管理
ショー |比較 |display 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は、既存のファイルステートメント内の位置を表しています。 -
この例では、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 コマンドを発行してファイルを削除する前に、リストを確認できます。