NETCONF XML 관리 프로토콜 이해
NETCONF(Network Configuration Protocol)와 NETCONF를 사용하여 네트워크 디바이스를 관리할 때의 이점에 대해 알아보십시오.
NETCONF의 이점
-
NETCONF는 네트워크 디바이스 관리를 위해 특별히 개발된 표준 기반 프로토콜입니다.
-
NETCONF는 인증, 데이터 무결성 및 기밀성을 보장하는 안전한 연결 지향 세션을 사용합니다.
-
NETCONF는 벤더에 구애받지 않으므로 동일한 NETCONF 기본 작업을 사용하여 다른 벤더의 디바이스를 관리할 수 있습니다.
NETCONF XML 관리 프로토콜 개요
NETCONF XML 관리 프로토콜은 네트워크 장치와의 통신 및 관리를 위해 특별히 맞춤화된 표준 기반 프로토콜입니다. NETCONF는 클라이언트/서버 모델과 원격 프로시저 호출(RPC) 기반 통신을 사용합니다. NETCONF 클라이언트는 NETCONF 서버와의 연결 및 NETCONF 세션을 설정하고 디바이스에서 작업을 실행합니다. Junos 디바이스는 NETCONF 서버를 OS에 통합하므로 서버는 프로세스 목록에 별도의 항목으로 표시되지 않습니다.
NETCONF는 RPC 및 구성 데이터에 XML 기반 데이터 인코딩을 사용합니다. NETCONF 프로토콜은 CLI 구성 모드 명령과 동일한 기본 작업을 정의합니다. 관리자가 CLI 구성 모드 명령을 사용하여 이러한 작업을 수행하는 것처럼, 클라이언트 애플리케이션은 프로토콜 작업을 사용하여 구성 데이터(다른 작업 중에서도)를 표시, 편집 및 커밋합니다. NETCONF 세션 내에서 클라이언트 애플리케이션은 Junos OS 운영 모드 명령에 해당하는 RPC를 실행할 수도 있습니다.
개념적으로 NETCONF는 4개의 레이어로 나눌 수 있습니다. 표 1 에는 계층이 설명되어 있습니다.
| NETCONF 계층 | 설명 |
|---|---|
| 운송 |
전송 계층은 다양한 프로토콜을 사용하여 클라이언트와 서버 간의 세션 생성을 용이하게 합니다. |
| 메시지 |
메시지 계층은 RPC 및 알림을 인코딩하기 위한 전송 독립적 프레이밍 메커니즘입니다. 태그에는 다음이 포함됩니다.
|
| 운영 |
작업 계층은 네트워크 디바이스에서 수행할 수 있는 프로토콜 작업을 정의합니다. 이 작업은 기본 프로토콜 작업(예: |
| 내용 |
콘텐츠 레이어에는 XML 형식의 RPC 요청 및 응답 페이로드가 포함되어 있습니다. 이 레이어는 구성 데이터와 알림 데이터를 정의합니다. |
NETCONF 서버와 클라이언트 애플리케이션 간의 통신은 세션 기반입니다. 서버와 클라이언트는 데이터를 교환하기 전에 명시적으로 연결 및 세션을 설정합니다. 전송 계층에 의해 정의된 바와 같이, NETCONF는 필요한 요구 사항을 충족하는 모든 보안 전송 프로토콜을 사용할 수 있습니다. Junos 디바이스는 SSH, 아웃바운드 SSH, TLS 및 아웃바운드 HTTPS를 통한 NETCONF 세션과 아웃바운드 SSH를 통한 NETCONF Call Home 세션을 지원합니다.
각 NETCONF 세션은 서버와 클라이언트가 지원되는 NETCONF 기능을 포함하는 태그를 교환 <hello> 하는 핸드셰이크로 시작됩니다. NETCONF 세션 내에서 클라이언트와 서버는 RPC, RPC 응답 또는 알림을 포함하는 메시지를 교환합니다. NETCONF 운영 계층은 클라이언트 애플리케이션이 디바이스를 관리하는 데 사용할 수 있는 프로토콜 운영을 정의합니다. 콘텐츠 레이어는 RPC에 포함된 인코딩된 매개 변수와 데이터를 설명합니다. NETCONF 및 Junos XML API 개요 에서는 콘텐츠 레이어에 대해 더 자세히 설명합니다. 클라이언트 애플리케이션이 요청을 마친 후 NETCONF 세션 및 연결을 닫습니다.
NETCONF 클라이언트는 NETCONF 서버로 RPC를 전송하여 정보를 요청하거나 운영 명령을 실행하거나 디바이스의 구성을 수정합니다. NETCONF 서버는 RPC를 처리하고 RPC 응답을 클라이언트에 보냅니다. 요청에 따라 RPC는 회신하거나 요청된 정보를 반환하거나 요청된 작업의 성공 또는 실패를 나타냅니다.
NETCONF에 대한 자세한 내용은 다음 RFCS를 참조하십시오.
-
RFC 6241, 네트워크 구성 프로토콜(NETCONF)
-
RFC 6242, 보안 셸(SSH)을 통한 NETCONF 프로토콜 사용
NETCONF 및 Junos XML API 개요
Junos XML API는 Junos OS 구성 명령문 및 운영 모드 명령의 XML 표현입니다. Junos XML API는 Junos OS 구성 계층의 모든 문과 CLI 운영 모드에서 실행하는 많은 명령에 대해 동등한 XML을 정의합니다. Junos XML 대응 항목이 있는 각 운영 모드 명령은 요청 태그 요소와 필요한 경우 응답 태그 요소에 매핑됩니다. Junos XML 요청 태그는 CLI의 해당 운영 모드 명령과 기능이 동일합니다.
NETCONF 클라이언트 애플리케이션은 Junos 디바이스에서 정보를 요청하거나 운영 명령을 실행하거나 구성을 수정할 수 있습니다. 클라이언트 애플리케이션은 NETCONF 및 Junos XML API 태그 요소에서 요청을 인코딩하고 디바이스의 NETCONF 서버로 보냅니다. NETCONF 서버는 요청을 적절한 소프트웨어 모듈로 전달하고 NETCONF 및 Junos XML API 태그 요소로 응답을 인코딩한 다음 결과를 클라이언트 애플리케이션에 반환합니다.
NETCONF 클라이언트가 Junos OS 구성을 수정할 때 RPC 콘텐츠에는 Junos XML 구성 데이터가 포함됩니다. 또한 NETCONF 클라이언트는 적절한 요청 태그를 가진 운영 RPC를 전송하여 운영 명령을 실행하거나 정보를 검색할 수 있습니다. 서버는 해당 응답 태그 요소 안에 포함된 Junos XML API 요소를 사용하여 응답을 반환합니다.
예를 들어, 디바이스의 인터페이스 상태에 대한 정보를 요청하기 위해 클라이언트 애플리케이션은 Junos XML API <get-interface-information/> 요청 태그를 보냅니다.
<rpc>
<get-interface-information/>
</rpc>
NETCONF 서버는 인터페이스 프로세스에서 정보를 수집하여 Junos XML API <interface-information> 응답 태그 요소에 반환합니다.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos"> <interface-information xmlns="http://xml.juniper.net/junos/25.2R1/junos-interface" junos:style="normal"> <physical-interface> <name> ge-0/0/0 </name> <admin-status junos:format="Enabled"> up </admin-status> ... </interface-information> </rpc-reply>
여러 가지 방법으로 Junos XML API 컨텐츠를 확인할 수 있습니다. 주니퍼 네트웍스 XML API 탐색기를 사용하면 Junos XML API 요소를 찾아볼 수 있습니다. 해당 OS 및 릴리스에서 지원되는 구성 요소와 운영 요청 및 응답 태그를 볼 수 있습니다.
또한 Junos 디바이스에서는 CLI의 파이프(|) 연산자를 사용하여 Junos XML API 컨텐츠를 볼 수 있습니다. 예를 들어, 주어진 명령에 대한 운영 요청 태그를 검색하려면 CLI에서 발행 command | display xml rpc 합니다. 다음 예는 명령에 대한 show interfaces 요청 태그가 <get-interface-information>.
user@host> show interfaces | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos">
<rpc>
<get-interface-information>
</get-interface-information>
</rpc>
<cli>
<banner></banner>
</cli>
</rpc-reply>
마찬가지로 XML 형식의 구성 데이터를 검색하려면 명령을 사용합니다.show configuration | display xml
user@host> show configuration system services | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/25.2R1/junos">
<configuration junos:commit-seconds="1747272887" junos:commit-localtime="2025-05-14 18:34:47 PDT" junos:commit-user="admin">
<system>
<services>
<netconf>
<ssh>
</ssh>
</netconf>
<ssh>
<root-login>allow</root-login>
</ssh>
<ftp>
</ftp>
</services>
</system>
</configuration>
<cli>
<banner></banner>
</cli>
</rpc-reply>
NETCONF 및 Junos XML API를 사용하여 Junos 디바이스를 관리할 수 있습니다. NETCONF 서버와 상호 작용할 클라이언트 응용 프로그램을 작성할 수 있습니다. 또한 NETCONF를 사용하여 웹 브라우저 기반 인터페이스와 같은 구성 및 정보 검색 및 표시를 위한 사용자 지정 최종 사용자 인터페이스를 구축할 수 있습니다.
NETCONF 및 Junos XML API 사용의 이점
NETCONF 및 Junos XML API는 지원되는 모든 Junos OS 운영 요청에 대한 모든 옵션과 모든 Junos OS 구성 문의 모든 요소를 완전히 문서화합니다. 태그 이름은 운영 요청 또는 구성 문에서 요소의 기능을 명확하게 나타냅니다.
DTD에서 의미 있는 태그 이름과 구조적 규칙의 조합을 통해 XML 태그가 지정된 데이터 세트의 컨텐츠와 구조를 쉽게 이해할 수 있습니다. NETCONF 및 Junos XML 태그 요소를 사용하면 다음 섹션에서 설명하는 대로 클라이언트 애플리케이션이 디바이스 출력을 쉽게 구문 분석하여 특정 정보를 찾고 표시할 수 있습니다.
디바이스 출력 구문 분석
다음 예제에서는 Junos XML API를 사용하여 디바이스 출력을 쉽게 구문 분석하고 필요한 정보를 추출하는 방법을 보여 줍니다. 이 예에서는 Junos OS를 실행하는 디바이스에서 형식화된 ASCII와 XML 태그가 지정된 출력을 비교합니다. 형식화된 ASCII 출력은 다음과 같습니다.
Physical interface: fxp0, Enabled, Physical link is Up Interface index: 64, SNMP ifIndex: 1
해당 XML 태그가 지정된 버전은 다음과 같습니다.
<physical-interface>
<name>fxp0</name>
<admin-status junos:format="Enabled">up</admin-status>
<oper-status>up</oper-status>
<local-index>64</local-index>
<snmp-index>1</snmp-index>
...
</physical-interface>
클라이언트 애플리케이션이 형식화된 ASCII 출력에서 특정 값을 추출해야 하는 경우 절대적으로 또는 인접한 필드의 레이블 또는 값과 관련하여 표현된 값의 위치에 의존해야 합니다. 클라이언트 애플리케이션이 인터페이스 인덱스를 추출하려고 한다고 가정해 보겠습니다. 정규 표현식 일치 유틸리티를 사용하여 특정 문자열을 찾을 수 있지만 인터페이스 인덱스의 자릿수를 반드시 예측할 수 있는 것은 아닙니다. 클라이언트 애플리케이션은 레이블 뒤의 Interface index: 특정 문자 수를 단순히 읽을 수 없습니다. 대신 레이블과 후속 레이블 사이의 모든 항목을 추출해야 합니다.
, SNMP ifIndex
Junos OS의 최신 버전에서 출력 형식이나 순서가 변경되면 문제가 발생합니다. 예를 들어, 출력 시 인터페이스 색인 번호 뒤에 필드가 Logical index 추가될 수 있습니다.
Physical interface: fxp0, Enabled, Physical link is Up
Interface index: 64, Logical index: 12, SNMP ifIndex: 1
와 Interface index: SNMP ifIndex 레이블로 구분된 인터페이스 인덱스 번호를 추출하는 애플리케이션은 이제 잘못된 결과를 얻습니다. 이 경우 대신 다음 레이블을 수동으로 검색하도록 애플리케이션을 업데이트해야 합니다.
, Logical index
이와는 대조적으로, XML 태그가 지정된 출력의 구조화된 특성으로 인해 클라이언트 응용 프로그램은 시작 <local-index> 태그와 닫기 </local-index> 태그 내의 모든 항목을 추출하여 인터페이스 인덱스를 검색할 수 있습니다. 응용 프로그램은 출력 문자열에서 요소의 위치에 의존할 필요가 없습니다. 따라서 NETCONF 서버는 요소 내에서 임의의 순서로 하위 태그 요소를 내보낼 수 있습니다 <physical-interface> . 새 <logical-index> 요소를 추가해도 응용 프로그램이 요소를 찾고 <local-index> 해당 내용을 추출하는 기능에 영향을 주지 않습니다.
디스플레이 디바이스 출력
XML 태그가 지정된 출력은 다른 표시 형식으로 변환하기도 더 쉽습니다. 예를 들어, 특정 디바이스 구성 요소에 대해 서로 다른 시간에 서로 다른 양의 세부 정보를 표시할 수 있습니다. 디바이스에서 서식이 지정된 ASCII 출력을 반환하면 애플리케이션에 특수 루틴과 데이터 구조를 작성하여 지정된 세부 정보 수준에 필요한 정보를 추출해야 합니다. 이와는 대조적으로, XML 출력의 고유 구조는 디스플레이 프로그램의 자체 구조에 대한 이상적인 기반입니다. 여러 수준의 세부 정보에 대해 동일한 추출 루틴을 사용할 수 있으며, 세부 정보를 덜 표시할 때 필요하지 않은 태그 요소를 무시하기만 하면 됩니다.