Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지 내용
 

NETCONF 세션

Junos 디바이스의 NETCONF 세션을 이해합니다.

NETCONF(Network Configuration Protocol)를 사용하여 네트워크 디바이스를 관리할 수 있습니다. 다음 섹션에서는 Junos 디바이스의 NETCONF 세션에 대한 개요를 제공합니다.

SSH를 사용하여 NETCONF 서버에 연결

NETCONF 서버에 연결하는 가장 일반적인 방법은 SSH를 사용하는 것입니다. NETCONF 클라이언트가 SSH를 사용하여 NETCONF 서버에 연결하기 전에 NETCONF 세션을 위한 SSH 연결 설정에 설명된 요구 사항을 충족해야 합니다. 전제 조건이 충족되면 NETCONF 클라이언트는 다음 방법 중 하나를 사용하여 NETCONF 서버에 연결할 수 있습니다.

SSH 라이브러리 루틴

NETCONF 클라이언트는 SSH 라이브러리 루틴을 사용하여 NETCONF 서버에 SSH 연결을 설정하고, 인증을 제공하며, NETCONF 세션을 위한 SSH 서브시스템 역할을 하는 채널을 생성합니다. 라이브러리 루틴 사용에 대한 지침을 제공하는 것은 이 문서의 범위를 벗어납니다.

ssh 명령

NETCONF 세션을 전용 포트가 있는 SSH 서브시스템으로 설정할 수 있습니다. 또는 기본 SSH 포트를 통해 NETCONF 세션을 설정하고 pseudo-tty 할당을 사용할 수 있습니다. 전용 포트에서 SSH 서브시스템을 사용하면 디바이스가 NETCONF 트래픽을 쉽게 식별하고 필터링할 수 있습니다. 그러나 pseudo-tty 할당과 함께 기본 SSH 포트를 사용하면 예를 들어 작동 명령을 실행할 때 세션에 대한 가시성을 show system users 제공할 수 있습니다.

애플리케이션에는 암호 또는 암호에 대한 NETCONF 서버의 프롬프트를 가로채는 코드가 포함되어야 합니다. 예를 들어 응용 프로그램은 명령과 같은 유틸리티를 expect 사용할 수 있습니다.

  • 기본 NETCONF 포트(830)에서 SSH 서브시스템으로 NETCONF 세션을 설정하기 위해 클라이언트 애플리케이션은 다음 명령을 실행합니다.

    옵션은 -p NETCONF 서버가 수신하는 포트 번호를 정의합니다. 기본 포트를 통해 SSH에 대한 액세스를 활성화한 경우 이 옵션을 생략할 수 있습니다.

    이 -s 옵션은 NETCONF 세션을 SSH 서브시스템으로 설정합니다.

  • 기본 SSH 포트(22)에서 NETCONF 세션을 설정하고 pseudo-tty 할당을 사용하기 위해 클라이언트 애플리케이션은 다음 명령을 실행합니다.

    메모:

    여러 -t 옵션을 사용하면 SSH에 로컬 tty가 없는 경우에도 의사 tty가 강제로 할당됩니다.

NETCONF 세션 시작하기

각 NETCONF 세션은 NETCONF 서버 및 클라이언트 애플리케이션이 지원하는 NETCONF 기능을 지정하는 핸드셰이크로 시작됩니다. 다음 섹션에서는 NETCONF 세션을 시작하는 방법에 대해 설명합니다.

<hello> 태그 요소 교환

NETCONF 서버 및 클라이언트 애플리케이션은 각각 태그 요소를 내보내 <hello> NETCONF 사양에 정의된 작업 또는 기능 중에서 지원하는 작업 또는 기능을 지정합니다. 클라이언트 응용 프로그램은 다른 요소보다 <hello> 먼저 요소를 내보내야 하며 한 번만 내보내야 합니다.

태그는 <hello> 다음 요소를 둘러쌉니다.

  • <capabilities>- 각각 지원되는 기능을 정의하는 요소 목록 <capability> 입니다.

  • <session-id>- 세션에 대한 NETCONF 서버의 UNIX 프로세스 ID(PID).

NETCONF 사양에 정의된 각 기능은 URN(Uniform Resource Name)으로 요소에 표시됩니다 <capability> . 개별 공급업체에서 정의하는 기능은 URI(Uniform Resource Identifier)로 표시되며, 이는 URN 또는 URL일 수 있습니다. NETCONF 서버는 다음 출력과 유사한 요소를 방출 <hello> 합니다.

요소의 URI <hello> 는 지원되는 기능을 나타냅니다. 표 1 에는 몇 가지 공통적인 기능이 나와 있습니다.

표 1: 공통 기능

능력

묘사

urn:ietf:params:netconf:base:1.0

NETCONF 서버는 기본 NETCONF 사양에 정의된 기본 운영 및 요소를 지원합니다.

urn:ietf:params:netconf:base:1.1

NETCONF 세션은 메시지 프레이밍을 위한 청크 프레이밍 메커니즘을 지원하는 RFC 6242를 준수합니다.

urn:ietf:params:netconf:capability:candidate:1.0

NETCONF 서버는 후보 구성에 대한 작업을 지원합니다.

urn:ietf:params:netconf:capability:confirmed-commit:1.0

NETCONF 서버는 확인된 커밋 작업을 지원합니다.

자세한 내용은 NETCONF를 사용하여 확인 후에만 후보 구성 커밋을 참조하십시오

urn:ietf:params:netconf:capability:validate:1.0

NETCONF 서버는 실제로 커밋하지 않고도 구성의 구문적 정확성을 검증하는 검증 작업을 지원합니다.

자세한 내용은 NETCONF를 사용하여 후보 구성 구문 검증을 참조하십시오.

urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file

NETCONF 서버는 파일에 저장된 구성 데이터를 수용합니다. HTTP 또는 FTP를 사용하여 로컬 파일 시스템과 원격 시스템 모두에서 파일을 검색할 수 있습니다.

자세한 내용은 NETCONF 세션에서 구성 데이터 업로드 및 형식 지정을 참조하십시오.

http://xml.juniper.net/netconf/junos/1.0

NETCONF 서버는 다음을 지원합니다.

  • 운영 정보를 요청하고 변경하기 위해 Junos XML API에 정의된 작업.

  • 구성 정보를 요청하거나 변경하기 위한 Junos XML 프로토콜 작업.

NETCONF 클라이언트 애플리케이션은 구성 기능을 위해 네이티브 NETCONF 운영 및 지원되는 Junos XML 프로토콜 확장만 사용해야 합니다. 해당 Junos XML 프로토콜 작업과 NETCONF XML 프로토콜 작업의 의미 체계가 반드시 동일하지는 않으므로 문서화된 지원 확장 이외의 Junos XML 프로토콜 구성 작업을 사용하면 예기치 않은 결과가 발생할 수 있습니다.

http://xml.juniper.net/dmi/system/1.0

NETCONF 서버는 DMI(Device Management Interface) 사양에 정의된 작업을 지원합니다.

기본적으로 NETCONF 서버는 NETCONF 기능 교환에서 지원되는 YANG 모듈을 광고하지 않습니다. 지원되는 YANG 모듈을 광고하려면 계층 수준에서 다음 문 중 하나 이상을 구성해야 합니다.[edit system services netconf hello-message yang-module-capabilities]

  • advertise-custom-yang-modules- 디바이스에 설치된 타사 YANG 모듈을 광고합니다.
  • advertise-native-yang-modules- Junos OS 네이티브 YANG 모듈을 보급합니다.
  • advertise-standard-yang-modules- 디바이스에서 지원하는 표준 YANG 모듈(예: OpenConfig 모듈)을 보급합니다.

NETCONF 사양을 준수하기 위해 클라이언트 애플리케이션은 지원하는 기능을 정의하는 요소도 내보냅니다<hello>. 요소는 포함되지 않습니다.<session-id>

NETCONF 세션은 프레이밍 메커니즘을 사용하여 NETCONF 서버와 클라이언트가 세션 내에서 보내는 메시지를 분리합니다. 기본적으로 Junos 디바이스가 있는 NETCONF 세션은 문자 시퀀스 ]]>]]>을 메시지 구분 기호로 사용합니다. 그러나 RFC 6242 규격 NETCONF 세션을 구성하고 두 피어 모두 기능 교환에서 기능을 광고 :base:1.1 하는 경우, NETCONF 세션은 세션의 나머지 부분에 대해 청크 프레이밍을 사용합니다. 청크 분할 프레이밍은 XML 요소 내의 문자 시퀀스가 메시지 경계로 잘못 해석되지 않도록 하는 표준화된 프레이밍 메커니즘입니다. 자세한 정보는 RFC 준수 NETCONF 세션 구성을 참조하십시오.

클라이언트 애플리케이션이 NETCONF 서버에 요청을 보내면 세션이 계속됩니다. NETCONF 서버는 클라이언트 애플리케이션의 요청에 대한 응답을 제외하고는 세션 초기화 후 어떤 요소도 내보내지 않습니다.

호환성 확인

태그 요소를 교환 <hello> 하면 NETCONF 서버와 클라이언트가 동일한 기능을 지원하는지 확인할 수 있습니다. 또한 클라이언트 애플리케이션이 NETCONF 서버에서 실행되는 Junos OS 버전을 결정하는 것이 좋습니다. 태그를 내보낸 <hello> 후 클라이언트 응용 프로그램은 요청을 내보낼 <get-software-information> 수 있습니다.

NETCONF 서버는 Junos OS 변형에 <software-information> 따라 다른 태그를 포함하는 요소를 반환합니다. Junos OS는 각 소프트웨어 모듈에 <host-name> 대한 및 <product-name> 태그 요소와 <package-information> 요소를 반환합니다. <comment> 요소는 Junos OS 릴리스와 빌드 날짜를 YYYYMMDD 형식으로 지정합니다. 다음 예제에서 릴리스는 8.2 Junos OS 릴리스 8.2에 대한 것이며 빌드 날짜는 20070112(2007년 1월 12일)입니다.

일반적으로 디바이스에서 실행되는 모든 Junos OS 모듈의 버전은 동일합니다(예측 가능한 라우팅 성능을 위해 이 구성을 권장합니다). 따라서 일반적으로 한 모듈의 버전 번호만 확인하면 충분합니다.

클라이언트 응용 프로그램은 버전 또는 기능의 차이를 처리하는 방법을 결정합니다. 완전히 자동화된 성능을 위해 NETCONF 서버와 동일한 기능 및 Junos OS 버전을 지원하는지 여부를 결정하는 코드를 클라이언트 애플리케이션에 포함시키십시오. 차이가 있는 경우 다음 옵션 중 적절한 옵션을 결정하고 해당 응답을 구현합니다.

  • 차이 무시 - 기능 및 Junos OS 버전의 차이를 무시하고 NETCONF 서버를 수용하기 위해 클라이언트 애플리케이션의 동작을 변경하지 않습니다. Junos OS 버전이 다르다고 해서 반드시 서버와 클라이언트가 호환되지 않는 것은 아니므로 이는 종종 유효한 접근 방식입니다. 마찬가지로, 클라이언트 응용 프로그램이 지원하지 않는 기능이 구성 검증 및 커밋 확인과 같이 항상 클라이언트에 의해 시작되는 작업인 경우에도 유효한 접근 방식입니다. 이 경우 클라이언트는 작업을 시작하지 않음으로써 호환성을 유지합니다.

  • NETCONF 서버와 호환되도록 표준 동작 변경 - 예를 들어, 클라이언트 애플리케이션이 이후 버전의 Junos OS를 실행 중인 경우 NETCONF 서버의 Junos OS 버전에서 사용할 수 있는 소프트웨어 기능을 나타내는 NETCONF 및 Junos XML 태그 요소만 내보내도록 선택할 수 있습니다.

  • NETCONF 세션 종료 및 연결 종료—NETCONF 서버의 버전이나 기능을 수용하는 것이 실용적이지 않다고 판단되는 경우 이 옵션을 사용합니다.

NETCONF 서버에 요청 전송

요청을 보내는 방법

NETCONF 서버에 대한 요청을 시작하기 위해 클라이언트 애플리케이션은 다음을 내보냅니다.

  • 오프닝 <rpc> 태그

  • 특정 요청을 나타내는 하나 이상의 태그 요소

  • 닫는 </rpc> 태그

응용 프로그램은 각 요청을 별도의 열기 <rpc> 및 닫 </rpc> 기 태그 쌍으로 묶습니다. 각 요청은 올바르게 정렬된 규격 태그 요소만 포함하여 올바른 형식의 XML 문서를 구성해야 합니다. NETCONF 서버는 태그 스트림의 태그 요소 사이에 발생하는 줄 바꿈 문자, 공백 또는 기타 공백 문자를 무시하지만 태그 요소 내의 공백은 보존합니다.

선택적으로, 클라이언트 응용 프로그램은 각 요청에 대한 여는 <rpc> 태그에 양식 attribute-name="value" 의 특성을 하나 이상 포함할 수 있습니다. NETCONF 서버는 응답을 둘러싸는 여는 <rpc-reply> 태그에서 변경되지 않은 각 속성을 에코합니다.

클라이언트 응용 프로그램은 이 기능을 사용하여 고유 식별자를 할당하는 각 여는 <rpc> 요청 태그에 속성을 포함하여 요청과 응답을 연결할 수 있습니다. NETCONF 서버는 시작 <rpc-reply> 태그의 속성을 에코하므로 응답을 시작 요청에 쉽게 매핑할 수 있습니다. NETCONF 사양은 이 속성의 이름을 message-id 지정합니다.

운영 및 구성 요청은 개념적으로 별도의 클래스에 속하지만, NETCONF 세션은 CLI 운영 및 구성 모드에 해당하는 고유한 모드를 갖지 않습니다. 각 요청 태그 요소는 자체 <rpc> 태그 안에 포함되므로 클라이언트 애플리케이션은 운영 요청과 구성 요청을 자유롭게 번갈아 사용할 수 있습니다. 클라이언트 응용 프로그램은 작업 요청, 구성 정보 요청 및 구성 변경 요청이라는 세 가지 종류의 요청을 만들 수 있습니다.

운영 요청

운영 요청은 디바이스의 상태에 대한 정보 요청입니다. 운영 요청은 Junos OS CLI 운영 모드 명령에 해당합니다. Junos XML API는 여러 CLI 명령에 대한 요청 태그 요소를 정의합니다. 예를 들어, tag 요소는 명령에 해당 show interfaces 하며<get-chassis-inventory>, <get-interface-information> tag 요소는 명령과 show chassis hardware 동일한 정보를 요청합니다.

다음 RPC는 인터페이스 ge-2/3/0에 대한 자세한 정보를 요청합니다.

운영 요청에 대한 자세한 내용은 NETCONF를 사용하여 운영 정보 요청 단원을 참조하십시오.

Junos XML 요청 태그에 대한 자세한 내용은 XML API 탐색기를 참조하십시오.

구성 정보 요청

구성 정보 요청 은 디바이스의 후보 구성, 프라이빗 구성, 임시 구성 또는 커밋된(활성) 구성에 대한 정보 요청입니다. 후보 구성과 커밋된 구성은 후보 구성에 커밋되지 않은 변경 사항이 있을 때 달라집니다.

NETCONF 프로토콜은 <get-config> 구성 정보를 검색하기 위한 작업을 정의합니다. Junos XML API는 구성 계층의 모든 컨테이너 및 리프 문에 대한 태그 요소를 정의합니다.

다음 예는 후보 구성의 [edit system login] 계층 수준에서 정보를 요청합니다.

구성 정보 요청에 대한 자세한 내용은 NETCONF를 사용하여 구성 데이터 요청 단원을 참조하십시오.

사용 가능한 구성 태그 요소에 대한 요약은 XML API 탐색기 를 참조하십시오 .

구성 변경 요청

구성 변경 요청은 구성을 변경하거나 이러한 변경 사항을 커밋하여 Junos OS를 실행하는 디바이스에서 적극적으로 사용하기 위한 요청입니다. NETCONF 프로토콜은 구성 정보를 변경하기 위한 및 <copy-config> 작업을 정의합니다<edit-config>. Junos XML API는 구성 계층의 모든 컨테이너 및 리프 문에 대한 태그 요소를 정의합니다.

다음 예는 후보 구성의 계층 수준에서 호출 admin 되는 [edit system login] 새로운 Junos OS 사용자 계정을 생성합니다.

구성 변경 요청에 대한 자세한 내용은 NETCONF를 사용하여 구성 편집 단원을 참조하십시오.

사용 가능한 구성 태그 요소에 대한 요약은 XML API 탐색기 를 참조하십시오 .

NETCONF 서버 응답 구문 분석

NETCONF 서버 응답 개요

NETCONF 세션에서 클라이언트 애플리케이션은 RPC를 NETCONF 서버로 전송하여 정보를 요청하고 디바이스 구성을 관리합니다. NETCONF 서버는 각 클라이언트 요청에 대한 응답을 별도의 열기 <rpc-reply> 및 닫 </rpc-reply> 기 태그 쌍으로 묶습니다. 각 응답은 올바른 형식의 XML 문서를 구성합니다.

xmlns 여는 <rpc-reply> 태그의 속성은 이름에 접두사가 junos: 없고 다른 값을 가진 속성이 있는 xmlns 하위 컨테이너 태그로 묶이지 않은 묶인 태그 요소에 대한 네임스페이스를 정의합니다.

메모:

디바이스에서 문을 구성하는 rfc-compliant 경우, NETCONF 서버는 접두사에 바인딩 nc 된 NETCONF 네임스페이스를 명시적으로 선언하고 응답에서 모든 NETCONF 태그를 접두사로 한정합니다.

이 xmlns:junos 속성은 접두사로 한정된 동봉된 Junos XML 태그 요소에 대한 기본 네임스페이스를 junos: 정의합니다. release URI의 변수는 NETCONF 서버 디바이스에서 실행 중인 Junos OS 릴리스(예: 20.4R1)를 나타냅니다.

클라이언트 애플리케이션에는 NETCONF 서버에서 오는 응답 태그 요소의 스트림을 구문 분석하기 위한 코드가 포함되어야 하며, 도착하는 대로 처리하거나 응답이 완료될 때까지 저장해야 합니다. NETCONF 서버는 운영 응답, 구성 정보 응답 및 구성 변경 응답의 세 가지 부류의 응답을 반환합니다.

운영 대응

운영 응답 은 스위칭, 라우팅 또는 보안 플랫폼의 상태에 대한 정보 요청에 대한 응답입니다. 이는 CLI 운영 명령의 출력에 해당합니다.

Junos XML API는 정의된 모든 운영 요청 태그 요소에 대한 응답 태그 요소를 정의합니다. 예를 들어, NETCONF 서버는 라는 <interface-information>응답 태그에서 태그가 <get-interface-information> 요청한 정보를 반환합니다. 마찬가지로, 서버는 라는 <chassis-inventory>응답 태그에서 태그가 <get-chassis-inventory> 요청한 정보를 반환합니다.

기본적으로 서버는 XML 형식으로 작업 응답을 반환합니다. 또한 클라이언트 응용 프로그램은 서버가 요소 내에 output 포함된 형식화된 ASCII 또는 JSON 형식으로 응답을 반환하도록 요청할 수 있습니다. 운영 응답의 형식 지정에 대한 자세한 내용은 NETCONF 세션에서 운영 정보 요청에 대한 출력 형식 지정을 참조하십시오.

다음 샘플 운영 응답에는 인터페이스 ge-2/3/0에 대한 정보가 포함됩니다.

속성 및 운영 응답 태그 요소의 콘텐츠에 대한 xmlns 자세한 내용은 NETCONF를 사용하여 운영 정보 요청 단원을 참조하십시오.

구성 정보 응답

구성 정보 응답 은 디바이스의 현재 구성에 대한 정보 요청에 대한 응답입니다. Junos XML API는 구성 계층의 모든 컨테이너 및 리프 문에 대한 태그 요소를 정의합니다.

다음 샘플 응답에는 계층 수준의 구성 데이터가 포함됩니다.[edit system login]

여는 <configuration> 태그의 속성에 대한 자세한 내용은 NETCONF를 사용하여 구성 정보 요청에 대한 소스 지정을 참조하십시오.

구성 변경 응답

구성 변경 응답 은 디바이스 구성의 상태나 내용을 변경하는 요청에 대한 응답입니다. NETCONF 서버는 태그 요소 내에서 태그를 반환 <ok/> 하여 요청의 성공적인 실행을 <rpc-reply> 나타냅니다.

작업이 실패 <rpc-reply> 하면 태그 요소는 대신 실패의 원인을 설명하는 요소를 묶 <rpc-error> 습니다.

NETCONF 및 Junos XML 프로토콜 세션에서 표준 API를 사용하여 응답 태그 요소 구문 분석

NETCONF 또는 Junos XML 프로토콜 세션에서 클라이언트 애플리케이션은 들어오는 XML 태그 요소를 DOM(Document Object Model) 또는 SAX(Simple API for XML)와 같은 표준 API를 기반으로 하는 파서에 공급하여 처리할 수 있습니다. 구문 분석기를 구현하고 사용하는 방법을 설명하는 것은 이 문서의 범위를 벗어납니다.

DOM의 루틴은 들어오는 XML을 수락하고 클라이언트 응용 프로그램의 메모리에 태그 계층 구조를 작성합니다. 기존 계층 구조를 조작하기 위한 DOM 루틴도 있습니다. DOM 구현은 C, C++, Perl 및 Java를 포함한 여러 프로그래밍 언어에서 사용할 수 있습니다. 자세한 내용은 W3C(World Wide Web 컨소시엄)의 DOM(Document Object Model) Level 1 Specification http://www.w3.org/TR/REC-DOM-Level-1/ 을 참조하십시오. 추가 정보는 https://metacpan.org/search?q=dist:XML-DOM+dom 의 CPAN(Comprehensive Perl Archive Network)에서 확인할 수 있습니다.

DOM의 한 가지 잠재적인 단점은 항상 매우 커질 수 있는 태그 요소의 계층 구조를 빌드한다는 것입니다. 클라이언트 응용 프로그램이 한 번에 하나의 하위 계층 구조만 처리해야 하는 경우 SAX를 구현하는 구문 분석기를 대신 사용할 수 있습니다. SAX는 XML을 받아들이고 자체 태그 계층 구조를 구축해야 하는 클라이언트 응용 프로그램에 태그 요소를 직접 공급합니다. 자세한 내용은 공식 SAX 웹 사이트( http://sax.sourceforge.net/ )를 참조하십시오.

NETCONF 세션에서 오류 또는 경고 처리

클라이언트 애플리케이션은 RPC를 NETCONF 서버로 전송하여 정보를 요청하고 디바이스 구성을 관리합니다. NETCONF 서버는 각 클라이언트 요청에 대한 응답을 보냅니다. 서버에서 오류 조건이 발생하면 오류를 설명하는 자식 요소가 포함된 요소를 내보냅니다 <rpc-error> .

요소에는 <rpc-error> 다음과 같은 자식 요소가 포함될 수 있습니다.

  • <bad-element> 오류 또는 경고가 발생했을 때 처리 중이던 명령 또는 구성 명령문을 식별합니다. 구성 문의 경우, <error-path> 은(는) 문의 상위 계층 수준을 지정합니다.

  • <error-message> 자연어 텍스트 문자열의 오류 또는 경고에 대해 설명합니다.

  • <error-path> 오류 또는 경고가 발생한 Junos OS 구성 계층 수준의 경로를 지정합니다.

  • <error-severity> 는 NETCONF 서버가 태그 요소를 반환 <rpc-error> 하도록 한 이벤트의 심각도를 나타냅니다. 가능한 두 가지 값은 error 및 warning입니다.

서버가 다음 작업을 수행하는 동안 오류가 발생할 수 있으며 서버는 각 경우에 다른 하위 태그 요소 조합을 보낼 수 있습니다.

  • 클라이언트 응용 프로그램에서 제출한 작업 요청 처리

  • 클라이언트 응용 프로그램의 요청에 따라 구성 열기, 잠금, 변경, 커밋 또는 닫기

  • 태그 요소에서 <edit-config> 클라이언트 응용 프로그램이 제출한 구성 데이터 구문 분석

클라이언트 응용 프로그램은 언제든지 요소를 받고 처리할 <rpc-error> 준비가 되어 있어야 합니다. 이미 수신되어 현재 요청과 관련된 응답 태그 요소의 정보가 불완전할 수 있습니다. 클라이언트 응용 프로그램에는 정보를 삭제할지 또는 유지할지 여부를 결정하는 논리가 포함될 수 있습니다.

<error-severity> 요소에 값이 error있는 경우 일반적인 응답은 클라이언트 응용 프로그램이 정보를 삭제하고 종료하는 것입니다. <error-severity> 태그 요소에 문제가 덜 심각함을 나타내는 값이 warning있는 경우 일반적인 응답은 클라이언트 응용 프로그램이 경고를 기록하거나 사용자에게 전달하고 서버의 응답을 계속 구문 분석하는 것입니다.

메모:

NETCONF 서버가 특정 동작을 시행하도록 계층 수준에서 명령문을 [edit system services netconf] 구성할 rfc-compliant 경우, NETCONF 서버는 요소와 <ok/> 요소를 모두 <rpc-error> 포함하는 RPC 응답을 반환할 수 없습니다. 작업이 성공했지만 서버 응답에 요소 외에 <ok/> 심각도 수준이 warning인 요소가 하나 이상 <rpc-error> 포함된 경우 경고가 생략됩니다.

참조

후보 구성 잠금 및 잠금 해제

클라이언트 응용 프로그램이 구성 정보를 요청하거나 변경할 때 다음 방법 중 하나를 사용하여 응시자 구성에 액세스할 수 있습니다.

  • 후보 구성을 잠궈 응용 프로그램이 잠금을 해제할 때까지 다른 사용자 또는 응용 프로그램이 공유 구성 데이터베이스를 변경하지 못하도록 합니다. 이는 CLI configure exclusive 명령과 동일합니다.

  • 후보 구성을 잠그지 않고 변경합니다. 이 방법은 다른 응용 프로그램이나 공유 구성 데이터베이스를 동시에 편집하는 사용자가 변경한 내용과 충돌할 가능성이 있으므로 권장하지 않습니다.

애플리케이션이 구성 정보를 요청하기만 하고 변경하지 않는 경우에는 구성을 잠글 필요가 없습니다. 애플리케이션은 즉시 정보 요청을 시작할 수 있습니다. 그러나 반환되는 정보가 세션 중에 변경되지 않는 것이 중요한 경우 구성을 잠그는 것이 적절합니다.

후보 구성 잠금

후보 구성을 잠그면 잠금이 해제될 때까지 다른 사용자나 애플리케이션이 후보 구성을 변경할 수 없습니다. 이는 CLI configure exclusive 명령과 동일합니다. 특히 여러 사용자에게 구성을 변경할 수 있는 권한이 있는 디바이스에서는 변경하기 전에 구성을 잠그는 것이 좋습니다. 커밋 작업은 커밋을 요청하는 사용자 또는 애플리케이션에 의한 변경 사항뿐만 아니라 후보 구성의 모든 변경 사항에 적용됩니다. 여러 사용자 또는 응용 프로그램이 동시에 변경하도록 허용하면 예기치 않은 결과가 발생할 수 있습니다.

응시자 구성을 잠그기 위해 클라이언트 응용 프로그램은 다음과 같이 을(를) 설정하여 <candidate/> 작업을 <target> 실행합니다<lock>.

NETCONF 서버는 태그를 반환 <ok/> 하여 후보를 잠갔음을 확인합니다.

NETCONF 서버가 구성을 잠글 수 없는 경우, 은 <rpc-reply> (는) 대신 실패 이유를 설명하는 요소를 동봉 <rpc-error> 합니다. 실패 원인에는 다음이 포함될 수 있습니다.

  • 다른 사용자 또는 애플리케이션이 이미 후보 구성을 잠갔습니다. 오류 메시지는 사용자 또는 애플리케이션의 NETCONF 세션 식별자를 보고합니다.

  • 후보 구성에는 아직 커밋되지 않은 변경 사항이 이미 포함되어 있습니다.

한 번에 하나의 응용 프로그램만 후보 구성에 대한 잠금을 유지할 수 있습니다. 다른 사용자 및 응용 프로그램은 후보 구성이 잠겨 있는 동안 해당 구성을 읽을 수 있습니다. 잠금은 클라이언트 애플리케이션이 태그 요소를 방출 <unlock> 하여 구성을 잠금 해제하거나 NETCONF 세션이 종료될 때까지 지속됩니다.

클라이언트 애플리케이션이 변경 사항을 커밋하기 전에 후보 구성을 잠금 해제하거나 변경 사항이 커밋되기 전에 NETCONF 세션이 어떤 이유로든 종료되는 경우 변경 사항은 자동으로 삭제됩니다. 후보 및 커밋된 구성은 변경되지 않습니다.

후보 구성 잠금 해제

클라이언트 응용 프로그램이 후보 구성에 대한 잠금을 보유하고 있는 한 다른 응용 프로그램 및 사용자는 후보를 변경할 수 없습니다. 후보 구성의 잠금을 해제하기 위해 클라이언트 응용 프로그램이 작업을 실행합니다 <unlock> .

NETCONF 서버는 태그를 반환하여 후보의 잠금을 <ok/> 해제했는지 확인합니다.

NETCONF 서버가 구성을 잠금 해제할 수 없는 경우, 대신 이 <rpc-reply> (가 <rpc-error> ) 실패 이유를 설명하는 요소를 동봉합니다.

NETCONF 세션 종료

NETCONF 세션에서 다른 사용자 또는 애플리케이션이 이미 잠금을 보유하고 있기 때문에 클라이언트 애플리케이션이 후보 구성을 잠그려는 시도가 실패할 수 있습니다. 이 경우 NETCONF 서버는 기존 잠금을 보유하고 있는 엔티티에 대한 사용자 이름과 프로세스 ID(PID)가 포함된 오류 메시지를 반환합니다.

클라이언트 애플리케이션에 Junos OS maintenance 권한이 있는 경우 작업을 실행하여 잠금을 <kill-session> 보유하는 세션을 종료할 수 있습니다. 요소는 <session-id> 오류 메시지에서 가져온 PID를 지정합니다.

NETCONF 서버는 태그를 반환 <ok/> 하여 다른 세션을 종료했음을 확인합니다.

잠금을 유지하는 사용자 또는 응용 프로그램의 ID 또는 유휴 시간 길이와 같은 요소에 따라 다른 세션을 종료하는 것이 적절한지 여부를 결정하는 논리를 응용 프로그램에 포함하는 것이 좋습니다.

세션이 종료되면 세션을 서비스하는 NETCONF 서버는 세션 중에 커밋되지 않은 모든 변경 사항을 롤백합니다. 확인된 커밋이 보류 중인 경우(변경 사항이 커밋되었지만 아직 확인되지 않은 경우), NETCONF 서버는 확인된 커밋 명령이 실행되기 전의 상태로 구성을 복원합니다.

다음 예제에서는 다른 세션을 종료하는 방법을 보여 줍니다.

NETCONF 세션을 종료하고 연결을 닫습니다

클라이언트 애플리케이션이 요청을 마치면 요소 내에서 빈 <close-session/> 태그를 방출하여 NETCONF 세션을 종료합니다 <rpc> .

NETCONF 서버는 엘리먼트와 <ok/> 태그를 내보냅니다<rpc-reply>.

NETCONF 서버에 대한 연결은 SSH 서브시스템이기 때문에 NETCONF 세션이 종료되면 자동으로 닫힙니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인하세요.

석방
묘사
15.1
Junos OS 릴리스 15.1부터 디바이스에서 문을 구성하는 rfc-compliant 경우, NETCONF 서버는 접두사에 바인딩 nc 된 NETCONF 네임스페이스를 명시적으로 선언하고 응답의 모든 NETCONF 태그를 접두사로 한정합니다.