Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

NETCONF 요청 및 구성 변경에서 NETCONF 구성 응답 태그 요소 사용

NETCONF 서버는 각 구성 요청에 대한 응답을 및 <configuration> 태그 요소로 <rpc-reply> 묶습니다. 태그 요소 내에 <configuration> 각 구성 응답을 묶는 것은 서버가 해당 응답 유형(예<chassis-inventory>: 섀시 정보에 대한 태그 요소 또는 <interface-information> 인터페이스 정보를 위한 태그 요소)에 각 다른 작동 응답을 묶는 방식과 대조됩니다.

태그 요소 내 <configuration> 의 Junos XML 태그 요소는 항상 계층의 상위 수준에서 더 깊은 수준으로 정렬되는 구성 계층 수준, 구성 객체 및 객체 특성을 나타냅니다. 클라이언트 애플리케이션이 구성을 로드하면 구성 정보를 반환할 때 NETCONF 서버가 사용하는 것과 동일한 순서로 동일한 태그 요소를 방출할 수 있습니다. 이러한 일관된 표현은 구성 정보를 보다 간단하게 처리할 수 있게 합니다. 예를 들어 클라이언트 애플리케이션은 현재 구성을 요청하고, NETCONF 서버의 응답을 로컬 메모리 버퍼에 저장하고, 버퍼 데이터에 변경을 하거나, 변환을 적용하고, 변경된 구성을 후보 구성에 대한 변경으로 제출할 수 있습니다. 변경된 구성은 NETCONF 서버의 응답을 기반으로 하기 때문에 정확히 정확한 것이 확실합니다.

마찬가지로 클라이언트 애플리케이션이 구성 요소(계층 수준 또는 구성 객체)에 대한 정보를 요청할 때 NETCONF 서버가 이에 대응하여 반환할 것과 동일한 태그 요소를 사용합니다. 요소를 나타내기 위해 클라이언트 애플리케이션은 구성 계층 상단(태그 요소로 표시)에서 요청된 요소까지 태그 요소의 <configuration> 전체 스트림을 보냅니다. 수준 또는 개체를 나타내는 가장 안쪽에 있는 태그 요소는 비어 있거나 식별자 태그 요소만 포함합니다. NETCONF 서버의 응답에는 동일한 상위 태그 요소 스트림이 포함되지만 요청된 구성 요소의 태그 요소에는 요소의 특성 또는 하위 수준을 나타내는 모든 태그 요소가 포함됩니다. 자세한 내용은 NETCONF를 사용하여 구성 데이터 요청을 참조하십시오.

XML 및 NETCONF XML 관리 프로토콜 규칙 개요에 설명된 바와 같이 NETCONF 서버와 클라이언트 애플리케이션에서 방출되는 태그 스트림은 공백 사용 시 다를 수 있습니다.