設定ファイルの読み込み
デバイス上の設定ファイルの読み込みは、ネットワーク内の多くのデバイスに共通する設定ファイルの部分を読み込むのに役立ちます。
ファイルやターミナルから設定を読み込む場合の例
ジュニパーネットワークスデバイスの設定データを含むファイルを作成し、そのファイルをローカルデバイスにコピーしてから、そのファイルをCLIに読み込むことができます。ファイルを読み込んだ後、それをコミットしてデバイス上で設定を有効にするか、CLIを使用して設定を対話的に編集し、後で設定をコミットすることができます。
また、ターミナルで入力しながらコンフィギュレーションを作成し、そのコンフィギュレーションを読み込むことも可能です。ターミナルからコンフィギュレーションを読み込むと、コンフィギュレーションの既存の部分を切り取り、コンフィギュレーション内の他の場所に貼り付ける場合に便利です。
デバイスに配置されている既存のコンフィギュレーション・ファイルを読み込むには、 load コンフィギュレーション・モード・コマンドを使用します。
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) filename <relative> <json>
ターミナルからコンフィギュレーションを読み込むには、次のバージョンの load コンフィギュレーション・モード・コマンドを使用します。Ctrl-dを押すと入力が終了します。
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) terminal <relative> <json>
コンフィギュレーション全体を置き換えるには、階層の任意のレベルで override オプションを指定します。 load override 操作は、現在の候補コンフィギュレーションを読み込んでいるファイルに完全に置き換えます。したがって、完全なコンフィギュレーションを保存した場合は、このオプションを使用します。
override操作は、現在の候補コンフィギュレーションを破棄し、そのコンフィギュレーションをfilename または端末で入力したコンフィギュレーションに読み込みます。overrideオプションを使用して設定をコミットすると、すべてのシステム プロセスが設定を再解析します。
コンフィギュレーションの一部を置き換えるには、 replace オプションを指定します。 load replace 操作は、読み込んだファイルに追加した replace: タグを検索します。そして、この操作は、タグの後に指定されたもので、候補となるコンフィギュレーションのこれらの部分を置き換えます。これは、変更される内容をより正確に制御したい場合に便利です。この操作を行うには、端末で入力するファイルまたは設定に replace: タグを含める必要があります。ソフトウェアは、 replace: タグを検索し、同じ名前の既存のステートメントがあれば削除し、受信した設定に置き換えます。同じ名前のステートメントが存在しない場合、 replace 操作は、 replace: タグでマークされたステートメントを設定に追加します。
overrideまたはmerge操作で、replace:タグを含むファイルまたはタイプテキストを指定した場合、replace:タグは無視されます。このシナリオでは、overrideまたはmerge操作が優先され、実行されます。
replace操作を実行していて、指定したファイルにreplace:タグがない場合、replace操作はmerge操作として実行されます。また、入力したテキストにreplace:タグがない場合、replace操作はmerge操作としても実行されます。この情報は、自動化されたスクリプトを実行していて、スクリプトがreplace操作またはmerge操作のどちらを実行する必要があるかを事前に知ることができない場合に役立ちます。スクリプトは、どちらの場合にも対応できるようにreplace操作を使用できます。
load merge操作は、保存されたファイルまたは端末のコンフィギュレーションを既存の候補コンフィギュレーションにマージします。この情報は、新しいコンフィギュレーション・セクションを追加する場合に便利です。例えば、以前はBGP設定がなかった[edit protocols]階層レベルにBGP設定を追加するとします。load merge操作を使用して、受信したコンフィギュレーションを既存の候補コンフィギュレーションと結合できます。既存の設定と受信設定に矛盾するステートメントが含まれている場合、受信設定のステートメントが既存の設定のステートメントを上書きします。
コンフィギュレーションの変更があった部分のみを置き換えるには、階層の任意のレベルで update オプションを指定します。 load update 操作は、候補コンフィギュレーションと新しいコンフィギュレーションデータを比較します。この操作は、候補となるコンフィギュレーションのうち、新しいコンフィギュレーションと異なる部分のみを変更します。この操作は、例えば、既存のBGP設定があり、読み込むファイルが何らかの形でそれを変更する場合に使用します。
merge、override、およびupdateオプションは、JavaScript Object Notation(JSON)形式での設定データの読み込みをサポートしています。JSON形式を使用して設定データを読み込む場合、コマンドでjsonオプションを指定する必要があります。順序指定されていないリストエントリ、つまり、リストキーが必ずしもリストエントリの最初の要素ではない場合のリストエントリを含むJSON設定データを読み込むには、順序指定されていないリストエントリを使用したJSON設定データを読み込むを参照してください。
パッチ・ファイルでコンフィギュレーションの一部を変更する場合は、 patch オプションを指定します。 load patch 操作は、設定変更を含むファイルまたは端末入力を読み込みます。まず、すでにコンフィギュレーションが変更されているデバイスにおいて、 show | compare コマンドを入力して2つのコンフィギュレーションの差分を出力します。その後、差分を別のデバイスに読み込むことができます。 load patch コマンドの利点は、ターゲット デバイスに読み込む前に、異なる階層レベルのスニペットをテキスト ファイルにコピーする手間を省くことができることです。これは、複数のデバイスを同じオプションで設定する場合に、時間を節約するのに有効かもしれません。例えば、ルータ1でルーティングポリシーを設定し、ルータ2、ルータ3、およびルータ4にポリシー設定を複製するとします。 load patch 操作を使用できます。
この例では、まず show | compare コマンドを実行します。
例:
user@router1# show | compare rollback 3
[edit protocols ospf]
+ export default-static;
- export static-default
[edit policy-options]
+ policy-statement default-static {
+ from protocol static;
+ then accept;
+ }
この例に引き続き、 show | compare コマンドの出力をクリップボードにコピーし、階層レベルが含まれていることを確認します。ルータ2、ルータ3、およびルータ4では、 load patch terminal を入力し、出力を貼り付けます。その後、Enterキーを押し、Ctrl-dキーを押して操作を終了します。パッチ入力で既存のステートメントと異なる値が指定された場合、パッチ入力は既存のステートメントを上書きします。
完全な階層レベルを指定せずに merge、 replace、 set、または update オプションを使用するには、 relative オプションを指定します。このオプションは、コンフィギュレーション階層内の現在の編集ポイントから相対的に受信したコンフィギュレーションを読み込みます。
例:
[edit system]
user@host# show static-host-mapping
bob sysid 987.654.321ab
[edit system]
user@host# load replace terminal relative
[Type ^D at a new line to end input]
replace: static-host-mapping {
bob sysid 0123.456.789bc;
}
load complete
[edit system]
user@host# show static-host-mapping
bob sysid 0123.456.789bc;
set設定モードコマンドを含む設定を読み込むには、setオプションを指定します。このオプションは、ファイルまたはターミナルから保存されたコンフィギュレーション・インストラクションを一行ずつ実行します。インストラクションには、set、edit、exit、topなど、任意のコンフィギュレーション・モード・コマンドを含めることができます。
他のネットワーク・システムからローカル・ルーターにコンフィギュレーション・ファイルをコピーするには、 CLIエクスプローラで説明されているように、SSHユーティリティとTelnetユーティリティを使用できます。
Common Criteria環境で作業している場合、 secret 属性が変更されるたびに(例えば、パスワードの変更やRADIUS共有シークレットの変更など)システムログメッセージが作成されます。これらの変更は、以下のコンフィギュレーションの読み込み操作時にログに記録されます:
load merge load replace load override load update
ジュニパーネットワークスデバイスでの文字エンコードの仕組み
Junos OS Evolved の設定データや運用コマンドの出力には、7 ビットの ASCII 文字セットの範囲外である非 ASCII 文字が含まれている場合があります。操作データや設定データを特定の形式で表示する場合や、特定のセッション内で表示する場合、ソフトウェアはこれらの文字をエスケープおよびエンコードします。このソフトウェアは、同等の UTF-8 10 進文字参照を使用して、文字をエスケープまたはエンコードします。
CLI は、テキスト、セット、または JSON 形式で作成された設定データ内の非 ASCII 文字を表示しようとします。また、CLI は、テキスト形式で生成されるコマンド出力に、これらの文字を表示しようとします。例外的なケースでは、CLIは代わりにUTF-810進文字参照を表示します。(例外として、XML 形式の設定データおよび XML または JSON 形式のコマンド出力があります)NETCONFおよびJunos XMLプロトコルのセッションで、非ASCII文字を含む設定データやコマンド出力を要求すると、同様の結果になります。この場合、サーバーはすべての形式について、それらの文字に相当する UTF-8 10 進文字参照を返します。
例えば、ラテン語の小文字「n」にチルダ(ñ)を加えた以下のようなユーザーアカウントがデバイスに設定されているとします。
[edit] user@host# set system login user mariap class super-user uid 2007 full-name "Maria Peña"
結果の設定をテキスト形式で表示すると、CLI は対応する文字を印刷します。
[edit] user@host# show system login user mariap full-name "Maria Peña"; uid 2007; class super-user;
結果の設定を CLI で XML 形式で表示すると、ñ 文字は同等の UTF-8 10 進文字参照 ñにマップされます。NETCONFまたはJunos XMLプロトコルセッションで任意の形式で設定を表示しても、同じ結果になります。
[edit]
user@host# show system login user mariap | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<configuration junos:changed-seconds="1494033077" junos:changed-localtime="2017-05-05 18:11:17 PDT">
<system>
<login>
<user>
<name>mariap</name>
<full-name>Maria Peña</full-name>
<uid>2007</uid>
<class>super-user</class>
</user>
</login>
</system>
</configuration>
<cli>
<banner>[edit]</banner>
</cli>
</rpc-reply>
設定データをデバイスにロードする際、同等の UTF-8 10 進文字参照を使用して、非 ASCII 文字をロードできます。
ステートメントと識別子の指定について
このトピックでは、CLIコンテナステートメントとリーフステートメントについて詳しく説明し、ASCII設定ファイルを作成する際にどのように指定しなければならないかを説明します。このトピックでは、入力したデータが正しい形式であることを確認するために、CLIがどのようにタイプ・チェックを行うかについても説明します。
ステートメントの指定
ステートメントは、中括弧({ })で囲むか、囲まないかの2通りの方法で表示されます:
-
ステートメント名と識別子、および中括弧で囲まれた1つまたは複数の下位レベルのステートメント:
statement-name1 identifier-name { statement-name2; additional-statements; } -
ステートメント名、識別子、および単一の識別子:
statement-name identifier-name1 identifier-name2;
statement-nameはステートメントの名前です。identifier-nameは、ステートメントのインスタンスを一意に識別するための名前またはその他の文字列です。識別子は、コンフィギュレーション内でステートメントを複数回指定できる場合に使用します。
ステートメントを指定する場合、ステートメント階層によって、ステートメント名、識別子名、またはその両方を指定する必要があります。
識別子を指定する方法は、次のいずれかです。
-
identifier-name— identifier-name は、ステートメント内でステートメントを複数回指定できる場合にステートメントを一意に識別するために使用されるキーワードです。
-
identifier-name value— identifier-name はキーワードであり、 value は必須オプション変数です。
-
identifier-name [value1 value2 value3
...]— identifier-name は複数の値を受け入れるキーワードです。括弧は、一連の値を指定する場合に必要です。ただし、1つの値のみを指定する場合はオプションです。
以下の例は、コンフィギュレーションでステートメントと識別子がどのように指定されるかを示しています:
protocol { # Top-level statement (statement-name).
ospf { # Statement under "protocol" (statement-name).
area 0.0.0.0 { # OSPF area "0.0.0.0" (statement-name identifier-name),
interface et-0/0/0 { # which contains an interface named "et-0/0/0."
hello-interval 25; # Identifier and value (identifier-name value).
priority 2; # Identifier and value (identifier-name value).
disable; # Flag identifier (identifier-name).
}
interface et-0/0/1; # Another instance of "interface," named et-0/0/1,
} # this instance contains no data, so no braces
} # are displayed.
}
policy-options { # Top-level statement (statement-name).
term term1 { # Statement under "policy-options"
# (statement-name value).
from { # Statement under "term" (statement-name).
route-filter 10.0.0.0/8 orlonger reject; # One identifier ("route-filter") with
route-filter 127.0.0.0/8 orlonger reject; # multiple values.
route-filter 128.0.0.0/16 orlonger reject;
route-filter 149.20.64.0/24 orlonger reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 191.255.0.0/16 orlonger reject;
}
then { # Statement under "term" (statement-name).
next term; # Identifier (identifier-name).
}
}
}
ASCII設定ファイルを作成するときは、ステートメントと識別子を指定します。各ステートメントには優先されたスタイルがあり、CLIはコンフィギュレーションモード show コマンドに応答してコンフィギュレーションを表示する際に、そのスタイルを使用します。ステートメントと識別子は、次のいずれかの方法で指定できます。
-
ステートメントの後に識別子が表示されます。
statement-name identifier-name [...] identifier-name value [...];
-
ステートメントの後に中括弧で囲まれた識別子が続きます:
statement-name { identifier-name; [...] identifier-name value; [...] } -
繰り返しのある識別子の場合、すべてのステートメントに 1 セットの中括弧を使用できます。
statement-name { identifier-name value1; identifier-name value2; }
CLI タイプ チェックの実行
識別子と値を指定すると、CLI はタイプ チェックを実行して、入力したデータが正しい形式であることを確認します。例えば、IPアドレスを指定する必要があるステートメントの場合、CLIは有効なフォーマットでアドレスを入力することを要求します。そうでない場合は、エラーメッセージで何を入力する必要があるかが示されます。CLIがチェックするデータタイプを一覧表示します。CLI設定入力タイプを以下に示します。
| データタイプ |
フォーマット |
使用例 |
|---|---|---|
| 物理インターフェイス名([ |
|
Correct: Incorrect: |
| フルインターフェイス名 |
|
Correct: Incorrect: |
| 完全または短縮されたインターフェイス名([ |
|
Correct: |
| IPアドレス |
|
Correct: Sample translations:
|
| IPアドレス(宛先プレフィックス)とプレフィックス長 |
|
Correct: Sample translations:
|
| 国際標準化機構(ISO)のアドレス |
|
Correct: Sample translations:
|
| OSPFエリア識別子(ID) |
|
Correct: Sample translations:
|
ファイルからの設定の読み込みについて
次の例は、ファイルから設定を読み込むプロセスを示しています。
| 現在の構成: interfaces {
Io0 {
unit 0 {
family inet {
address 127.0.0.1;
}
}
}
et-3/0/0 {
unit 0 {
family inet {
address 204.69.248.181/28;
}
}
}
} |
ファイルの内容: interfaces {
replace:
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
} |
load override ------------> |
新しいコンテンツ: interfaces {
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
} |
| 現在の構成: interfaces {
Io0 {
unit 0 {
family inet {
address 127.0.0.1;
}
}
}
et-3/0/0 {
unit 0 {
family inet {
address 204.69.248.181/28;
}
}
}
} |
ファイルの内容: interfaces {
replace:
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
} |
load replace ------------> |
新しいコンテンツ: interfaces {
Io0 {
unit 0 {
family inet {
address 127.0.0.1;
}
}
}
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
} |
| 現在の構成: interfaces {
Io0 {
unit 0 {
family inet {
address 127.0.0.1;
}
}
}
et-3/0/0 {
unit 0 {
family inet {
address 204.69.248.181/28;
}
}
}
} |
ファイルの内容: interfaces {
replace:
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
} |
load merge ------------> |
新しいコンテンツ: interfaces {
Io0 {
unit 0 {
family inet {
address 127.0.0.1;
}
}
}
et-3/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
address 204.69.248.181/28;
}
}
}
} |
| 現在の構成: interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.6.193/24;
}
}
}
Io0 {
unit 0 {
family inet {
address 127.0.0.1/32;
}
}
}
} |
ファイルの内容: {edit interfaces}
+ et-3/0/0 {
+ unit 0 {
+ family inet {
+ address 10.0.0.1/8;
+ }
+ }
+ } |
load patch ------------> |
新しいコンテンツ: interfaces {
et-0/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.6.193/24;
}
}
}
Io0 {
unit 0 {
family inet {
address 127.0.0.1/32;
}
}
}
} |
の使用
設定ファイルのアップロード
ローカル・システムでコンフィギュレーション・ファイルを作成し、そのファイルをデバイスにコピーしてから、そのファイルをCLIにロードできます。設定ファイルを読み込んだ後、それをコミットして、デバイス上で設定を有効にすることができます。また、CLIを使用して対話的に設定を編集し、後でコミットすることもできます。
ローカルシステムから設定ファイルをアップロードするには:
コンフィギュレーションをコミットする前に、コンフィギュレーション・ステップの結果を表示するには、ユーザー・プロンプトで show コマンドを入力します。
これらの変更をアクティブなコンフィギュレーションにコミットするには、ユーザー・プロンプトで commit コマンドを入力します。また、CLIを使用して対話的に設定を編集し、後でコミットすることもできます。
順序指定されていないリストエントリでJSON設定データを読み込む
Junosスキーマは、特定の設定オブジェクトをリストとして定義します。JSON設定データでは、リストインスタンスは名前と配列のペアとしてエンコードされ、配列要素はJSONオブジェクトです。一般に、JSONエンコードリストエントリーのメンバーの順序は任意です。これは、JSONオブジェクトが基本的に順序指定のないメンバーの集合体だからです。ただし、Junosスキーマでは、リストキーがリストエントリ内で他の兄弟の前にあり、スキーマで指定された順序で表示される必要があります。
たとえば、[edit system login]階層レベルのuserオブジェクトはリストであり、nameは各ユーザーを一意に識別するリストキーです。
list user {
key name;
description "Username";
uses login-user-object;
}
次のサンプル設定データでは、リストキー(name)は各ユーザーの最初の要素です。デフォルトでは、JSON設定データを読み込む際、Junosデバイスはリストキーがリストエントリ内の他の兄弟の前にあり、スキーマで指定された順序で表示される必要があります。
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "operator",
"class" : "operator",
"uid" : 3001
},
{
"name" : "security-admin",
"class" : "super-user",
"uid" : 3002
}
]
}
}
}
}
Junosデバイスには、順序指定されていないリストエントリ、つまりリストキーが必ずしも最初の要素でないリストエントリを含むJSON設定データを読み込むための2つのオプションが用意されています。
-
request system convert-json-configuration動作モードコマンドを使用して、デバイスにデータを読み込む前に、順序指定リストエントリでJSON設定データを生成します。 -
[edit system configuration input format json]階層レベルでreorder-list-keysステートメントを設定します。ステートメントを設定した後、順序指定のないリストエントリでJSON設定データを読み込むことができます。デバイスは読み込み操作中にJunosスキーマで要求されるようにリストキーの順序を変更します。
reorder-list-keysステートメントを設定する際、設定のサイズとリストの数によっては、読み込み操作で設定を解析するのにかなり多くの時間がかかる場合があります。したがって、大きな設定や多くのリストのある設定を行う場合は、reorder-list-keysステートメントではなく、request system convert-json-configurationコマンドを使用することを推奨します。
例えば、user-data.jsonファイルに次のJSON設定が含まれているとします。設定を読み込もうとすると、リストキーnameがそのリストエントリの最初の要素ではないため、デバイスはadmin2の読み込みエラーを生成します。
user@host> file show /var/tmp/user-data.json
{
"configuration" : {
"system" : {
"login" : {
"user" : [
{
"name" : "admin1",
"class" : "super-user",
"uid" : 3003
},
{
"class" : "super-user",
"name" : "admin2",
"uid" : 3004
}
]
}
}
}
}
入力に前のファイルで request system convert-json-configuration コマンドを使用する場合、コマンドは、Junosデバイスが読み込み操作中に解析できるJSON設定データを含む指定された出力ファイルを生成します。
user@host> request system convert-json-configuration /var/tmp/user-data.json output-filename user-data-ordered.json
user@host> file show user-data-ordered.json
{
"configuration":{
"system":{
"login":{
"user":[
{
"name":"admin1",
"class":"super-user",
"uid":3003
},
{
"name":"admin2",
"class":"super-user",
"uid":3004
}
]
}
}
}
}
あるいは、 reorder-list-keys 設定ステートメントを設定することもできます。
user@host# set system configuration input format json reorder-list-keys user@host# commit
ステートメントを設定した後、順序指定のないリストエントリで元のJSON設定ファイルを読み込むことができ、デバイスは設定を解析する際にリストエントリを処理します。
user@host# load merge json /var/tmp/user-data.json load complete