구성 파일 로드하기
디바이스의 구성 파일을 로드하면 네트워크 내의 여러 디바이스에서 공통적일 수 있는 구성 파일의 일부를 로드하는 데 도움이 됩니다.
파일 또는 터미널에서 구성 로드하기 예제
주니퍼 네트웍스 디바이스에 대한 구성 데이터가 들어 있는 파일을 생성하여 로컬 디바이스에 복사한 다음 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 옵션은 JSON(JavaScript Object Notation) 형식의 구성 데이터 로드를 지원합니다. JSON 형식을 사용하는 구성 데이터 로드 시 명령에서 json 옵션을 지정해야 합니다. 순서가 지정되지 않은 목록 항목, 즉 목록 키가 반드시 목록 항목의 첫 번째 요소일 필요는 없는 목록 항목을 포함하는 JSON 구성 데이터를 로드하려면 순서 없는 목록 항목을 포함하는 JSON 구성 데이터 로드를 참조하십시오.
패치 파일로 구성의 일부를 변경하려면 patch 옵션을 지정합니다. load patch 작업은 구성 변경을 포함하는 파일 또는 터미널 입력을 로드합니다. 먼저 구성 변경 사항이 이미 있는 디바이스에서 show | compare 명령을 입력하여 두 구성 간의 차이를 출력합니다. 그런 다음 또 다른 디바이스에서 차이점을 로드할 수 있습니다. load patch 명령어의 장점은 대상 디바이스에 로드하기 전에 서로 다른 계층 수준의 스니펫을 텍스트 파일로 복사하지 않아도 된다는 것입니다. 여러 디바이스를 동일한 옵션으로 구성하는 경우 이 방법을 사용하면 유용한 시간 절약이 될 수 있습니다. 예를 들어, router1에 라우팅 정책을 구성하고 router2, router3 및 router4에 정책 구성을 복제한다고 가정합니다. 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 명령의 출력을 클립보드에 복사하여 계층 수준을 포함해야 합니다. router2, router3 및 router4에서 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 유틸리티를 사용할 수 있습니다.
공통 기준 환경에서 작업하는 경우 secret 특성이 변경될 때마다 시스템 로그 메시지가 생성됩니다(예: 암호 변경 또는 RADIUS 공유 암호 변경). 이러한 변경 사항은 다음과 같은 구성 로드 작업 중에 기록됩니다.
load merge load replace load override load update
주니퍼 네트웍스 디바이스에서 문자 인코딩 작동 방법
Junos OS 구성 데이터 및 운영 명령 출력은 7비트 ASCII 문자 세트 외부에 있는 비 ASCII 문자를 포함할 수 있습니다. 특정 형식 또는 특정 세션 유형으로 운영이나 구성 데이터를 표시할 때, 소프트웨어는 이러한 문자를 이스케이프하고 인코딩합니다. 소프트웨어는 동일한 UTF-8 소수점 문자 참조를 사용하여 문자를 이스케이프하거나 인코딩합니다.
CLI는 텍스트, 세트 또는 JSON 형식으로 생성된 구성 데이터에 비 ASCII 문자를 표시하려 합니다. 또한 CLI는 텍스트 형식으로 생성된 명령 출력에서 이러한 문자를 표시하려 합니다. 예외 사례에서 CLI는 대신 UTF-8 소수점 문자 참조를 표시합니다. (예외 사례에는 XML 형식의 구성 데이터와 XML 또는 JSON 형식의 명령 출력이 포함됩니다.) NETCONF 및 Junos XML 프로토콜 세션에서 비 ASCII 문자를 포함하는 구성 데이터 또는 명령 출력을 요구하는 경우 유사한 결과를 볼 수 있습니다. 이런 경우, 서버는 모든 형식에서 이러한 문자에 동일한 UTF-8 소수점 문자 참조를 반환합니다.
예를 들어 틸드(ñ)를 가진 라틴어 소문자 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 소수점 문자 참조 ñ으로 매핑합니다. 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 소수점 문자 참조를 사용하여 비 ASCII 문자를 불러올 수 있습니다.
문 및 식별자 지정
이 주제는 CLI 컨테이너 문과 리프 문에 대한 세부 정보를 제공하여, ASCII 구성 파일을 생성할 때 어떻게 지정해야 하는지 알 수 있습니다. 또한 정확한 형식으로 데이터를 입력했는지 확인하기 위해 CLI가 어떻게 유형 확인을 수행하는지 설명합니다.
문 지정
문은 중괄호({ })를 사용하거나 사용하지 않는 두 가지 방법 중 하나로 표시합니다:
-
중괄호에 하나 이상의 낮은 수준의 문이 포함된 문 이름과 식별자:
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은(는) 여러 값을 수용하는 키워드입니다. 중괄호는 값 집합을 지정할 때 필요합니다. 그러나 단 하나의 값을 지정할 때는 선택 사항입니다.
다음 예는 문과 식별자가 구성이 지정되는 방법을 보여줍니다:
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 so-0/0/0 { # which contains an interface named "so-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 so-0/0/1; # Another instance of "interface," named so-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; [...] } -
일부 반복되는 식별자의 경우, 모든 문에 하나의 중괄호 집합을 사용할 수 있습니다:
statement-name { identifier-name value1; identifier-name value2; }
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:
|
파일에서 구성 불러오기 정보
다음 예는 파일에서 구성을 불러오는 프로세스를 보여줍니다.
구성 파일 업로드
로컬 시스템에서 구성 파일을 만들고, 파일을 디바이스에 복사한 다음, 파일을 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
}
]
}
}
}
}순서가 지정되지 않은 목록 항목, 즉 목록 키가 반드시 첫 번째 요소일 필요는 없는 목록 항목을 포함하는 JSON 구성 데이터를 로드하는 데 있어 Junos는 아래의 두 가지 옵션을 제공합니다.
-
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