네트워크 관리: SNMP, NETCONF, YANG
2025-06-14
📡 네트워크 관리
네트워크 관리란
네트워크 관리(Network Management)는 복잡한 네트워크 시스템의 안정적이고 효율적인 운영을 위해 필수적인 활동들을 포괄하는 개념이다. 하나의 네트워크, 즉 자율 시스템(Autonomous System)은 수천 개의 상호작용하는 하드웨어와 소프트웨어 구성요소들로 이루어져 있고 실시간으로 연결되어 동작한다.
네트워크 관리는 장비 설정을 넘어 하드웨어, 소프트웨어, 그리고 이를 다루는 인간 요소까지 통합해 조정하는 것을 포함한다. 여기에는 네트워크 구성요소의 배포와 통합, 모니터링, 테스트, 폴링(polling), 구성 변경, 상태 분석, 성능 평가, 문제 제어 등이 포함되고, 그 목적은 실시간 운영의 안정성과 성능 목표, 그리고 적절한 품질(QoS)을 일정한 비용 내에서 만족시키는 데 있다. 즉 네트워크 관리는 단순한 기술적 작업이 아니라, 복잡한 시스템을 효과적으로 운영하고 최적화하기 위한 전반적인 전략과 실행의 총합이라고 할 수 있다.
네트워크 관리 컴포넌트
네트워크 관리는 여러 구성요소들이 유기적으로 작동하는 구조로 이루어져 있다. 다 같이 네트워크 장비의 상태를 모니터링하고 제어하며, 문제를 감지하고 성능을 유지하는 역할을 수행한다. 중심에는 일반적으로 네트워크 운영 애플리케이션이 실행되는 Managing Server 시스템이 있고, 네트워크 관리자가 이 서버를 통해 네트워크를 관찰하고 조작한다. 전체 네트워크의 중앙 관제소 역할을 해 장비에 대한 명령 전송이나 데이터 수집을 담당한다.
각 Managed Device는 관리 대상이 되는 네트워크 장비로, 스위치, 라우터, 방화벽, 서버 등이 해당된다. 장비들은 하드웨어 및 소프트웨어 구성요소를 갖춰 구성 가능하고 관찰 가능한 상태여야 한다. 장비 내부에는 Agent가 동작하고 있는데, 이 에이전트는 장비의 상태 데이터를 수집하고, 명령에 따라 설정을 변경하거나 통계를 보고하는 역할을 한다.
중간에는 Network Management Protocol이 존재해 Managing Server와 각 Managed Device의 Agent 간에 정보를 주고받는 통신 수단이 된다. 이 프로토콜은 서버가 장비의 상태를 쿼리하거나 설정을 변경하는 데 사용된다. 반대로 장비 측에서는 이벤트나 상태 변경이 발생했을 때 서버에게 알려주는 데도 활용된다. 대표적인 프로토콜로는 SNMP(Simple Network Management Protocol)가 있다.
마지막으로 중요한 요소는 Data이다. 장비의 상태 정보(state), 구성 정보(configuration), 운영 데이터(operational data), 그리고 다양한 통계(statistics)가 여기에 해당한다. 이 데이터들은 네트워크 성능을 분석하거나, 문제를 진단하거나, 정책을 조정하는 데 사용한다.
네트워크 운영자가 네트워크를 관리하는 방식은 시대에 따라 진화해왔으며, 각 방식은 추상화 수준, 자동화 범위, 그리고 관리 단위에 있어 차이를 보인다. 가장 기본적인 접근 방식은 CLI(Command Line Interface)를 이용하는 것이다. 이 방식에서는 운영자가 각 장비에 직접 접속(ex, SSH를 통해)해 명령어를 입력하거나 스크립트를 실행해 장비 설정을 변경한다. 이렇게 하면 조금 더 세밀하게 제어를 할 수 있겠지만, 네트워크 규모가 커질수록 실수할 확률이 높아진다.
다음으로 널리 사용되는 방식은 SNMP(Simple Network Management Protocol) 기반의 관리다. 여기서는 운영자가 장비에 저장된 관리 정보(MIB, Management Information Base)를 쿼리하거나 수정해 상태를 파악하고 설정을 제어한다. SNMP는 자동화가 가능하고, 여러 장비에서 공통적으로 적용할 수 있는 규격화된 구조를 제공하지만, 구성 변경보다는 상태 모니터링 중심에 초점이 맞춰져 있다.
조금 더 발전한 방식은 NETCONF/YANG이다. NETCONF는 장비 간에 구조화된 설정 데이터를 교환하고, 설정 변경 작업을 트랜잭션 단위로 안전하게 수행할 수 있는 프로토콜이다. 이와 함께 사용되는 YANG은 네트워크 장비의 구성 데이터를 모델링할 수 있는 데이터 모델링 언어로, 전체 네트워크를 추상화된 형태로 관리할 수 있게 해준다. 이 조합은 여러 장비를 동시에 일관되게 구성하는 데 효과적이고, 네트워크 전체를 통합적으로 관리해 자동화할 수 있는 기반이 된다.
📡 SNMP Protocol
SNMP는 MIB(Management Information Base)에 저장된 정보를 기반으로 동작하는데, 크게 두 가지 방식으로 정보를 전달하고 명령을 수행할 수 있다.
첫 번째는 request/response 모드이다. 이 방식에서는 관리 서버나 컨트롤러가 SNMP 요청(request)을 보냄으로써 장비의 특정 정보를 쿼리하거나 설정 값을 변경하고자 한다. 장비에 설치된 에이전트는 이 요청을 받아 해당 MIB 데이터를 읽거나 갱신한 뒤, 응답(response) 메시지를 통해 결과를 다시 서버에 전달한다. 이 방식은 중앙에서 명시적으로 데이터를 요청하는 구조로, 관리자가 필요한 시점에 장비 상태를 수동으로 확인하거나 설정을 적용하는 데 적합하다.
두 번째는 trap 모드이다. 이 경우에는 관리 서버가 먼저 요청을 보내지 않더라도, 장비의 에이전트가 자체적으로 이벤트나 이상 상황을 감지했을 때 trap 메시지로 서버에 즉시 알린다. 예를 들어 포트 장애, 재부팅, 과부하 등의 상황이 발생하면 에이전트는 trap 메시지를 전송해 네트워크 운영자가 빠르게 대응할 수 있도록 돕는다. 이 모드는 능동적으로 알림을 주기 때문에 실시간 모니터링이나 장애 탐지에 유용하다.
SNMP 메시지 타입, 포맷
SNMP 프로토콜은 네트워크 장비의 상태를 조회하거나 설정하고, 이벤트를 통지하기 위해 다양한 메시지 타입을 정의하고 있다. 각 메시지 타입은 네트워크 관리자와 장비 간의 통신 목적에 따라 구분된다.
GetRequest는 관리자가 특정 MIB 항목의 값을 요청할 때 사용하는 메시지로, 가장 기본적인 데이터 조회 방식이다. GetNextRequest는 리스트 형태로 구성된 MIB 항목에서 다음 항목의 값을 가져올 때 사용되며, 반복 처리를 통해 전체 테이블을 순차적으로 탐색할 수 있게 해준다. GetBulkRequest는 한 번의 요청으로 다수의 데이터를 블록 단위로 받아올 수 있도록 설계된 메시지로, 특히 많은 데이터를 빠르게 수집해야 하는 경우에 효율적이다. 이 세 가지는 모두 manager-to-agent 방향으로 작동하고, ‘데이터를 달라’는 의미의 질의 요청이다.
SetRequest는 관리자가 MIB 항목의 값을 변경하고자 할 때 사용하는 메시지로, 역시 manager-to-agent 방향이다. 이를 통해 네트워크 장비의 구성을 원격으로 조정할 수 있지만, 보안상의 이유로 많은 환경에서는 설정 기능이 제한되거나 비활성화되어 있는 경우도 많다.
Response는 agent-to-manager 방향으로 전송되는 메시지이며, 위에서 설명한 Get 또는 Set 요청에 대한 응답으로 사용된다. 요청한 데이터 값을 반환하거나, 설정 결과에 대한 상태 정보를 포함한다.
Trap 메시지는 관리자가 요청하지 않아도, 에이전트가 자체적으로 이상 상황이나 이벤트 발생 시 관리자에게 알리는 데 사용된다. 예를 들어 장비가 다운되거나 포트 오류가 발생했을 때, Trap 메시지를 통해 즉각적인 알림이 가능하다.
SNMP 프로토콜의 메시지는 PDU(Protocol Data Unit) 형식으로 구성되며, 메시지 유형에 따라 세부 구조가 달라진다. 크게 보면 요청/설정 계열 메시지와 Trap 메시지로 나눌 수 있으며, 각 메시지 유형은 고유의 PDU 구조를 갖는다.
Get/Set 관련 메시지(PDU type 0–3)는 GetRequest, GetNextRequest, GetBulkRequest, SetRequest에 해당한다.
- 우선
PDU type필드는 메시지의 유형을 식별하는 데 사용되며, 0~3 사이의 값으로 각각의 요청 종류를 구분한다. Request ID는 해당 요청을 고유하게 식별하기 위한 값으로, 응답 메시지가 어떤 요청에 대한 것인지를 매칭하는 데 사용된다.Error Status필드는 요청 처리 중 발생한 오류 상태를 나타내며, 예를 들어 값 없음, 접근 불가, 잘못된 타입 등의 오류를 식별할 수 있다.Error Index는 오류가 발생한 변수의 순서를 명시한다. 그 다음에는 여러 개의 변수 이름(name)과 값(value) 쌍이 나열되며, 이는 가져오거나 설정하려는 MIB 항목들을 나타낸다.
Trap 메시지(PDU type 4)는 에이전트가 예외적 상황을 관리자에게 알릴 때 사용하는 구조이다. 이 메시지에는 Enterprise 필드가 포함되어 Trap을 발생시킨 장비 또는 시스템을 나타낸다.
Agent Address는 Trap을 전송한 장비의 IP 주소이다.Trap Type은 발생한 이벤트의 일반적 유형을 나타내고,Specific Code는 그 유형 내에서 보다 세부적인 사건을 식별한다.Time Stamp는 Trap이 발생한 시점까지의 시간 경과를 나타내며,Name-Value쌍을 통해 해당 이벤트와 관련된 MIB 항목의 값들이 첨부된다.
SNMP Protocol: MIB 예시
SNMP에서 핵심적인 역할을 수행하는 구성 요소 중 하나는 MIB(Management Information Base)로, 이는 관리 대상 장비의 운영 정보 및 일부 구성 데이터를 체계적으로 저장하고 표현하는 데이터베이스 구조다. 각 장비에는 자체적인 MIB 모듈이 존재하고 다양한 변수들이 정의되어 있다. 이러한 변수들은 SNMP 프로토콜을 통해 외부에서 조회하거나 설정할 수 있고 네트워크의 상태를 파악해 문제를 진단할 수 있다.
MIB는 RFC를 통해 정의된 표준 모듈이 400개 이상 존재하며, 이 외에도 장비 제조사들이 자체적으로 확장한 벤더 특화 MIB 모듈도 많이 존재한다. 각 MIB 변수는 고유한 객체 식별자(Object ID, OID)를 갖고 있고 OID를 통해 계층적으로 식별된다. 데이터를 정의할 때에는 SMI(Structure of Management Information)라는 데이터 정의 언어를 사용해 변수의 타입, 구조, 계층 관계 등을 명세한다.
| Object ID | Name | Type | Comments |
|---|---|---|---|
| 1.3.6.1.2.1.7.1 | UDPInDatagrams | 32-bit counter | 수신된 총 UDP 데이터그램 수 |
| 1.3.6.1.2.1.7.2 | UDPNoPorts | 32-bit counter | 포트에 연결된 애플리케이션이 없어 전달 실패한 데이터그램 수 |
| 1.3.6.1.2.1.7.3 | UDInErrors | 32-bit counter | 그 외 다른 이유로 실패한 데이터그램 수 |
| 1.3.6.1.2.1.7.4 | UDPOutDatagrams | 32-bit counter | 전송된 총 UDP 데이터그램 수 |
| 1.3.6.1.2.1.7.5 | udpTable | SEQUENCE | 현재 사용 중인 각 포트에 대한 하나의 엔트리 포함 |
📡 NETCONF
NETCONF(Network Configuration Protocol)는 네트워크 전체의 장비를 능동적으로 관리하고 구성하기 위해 만들어진 표준 프로토콜이다. 관리 서버와 각 네트워크 장비 사이에서 동작하며, 단순한 상태 조회를 넘어서 설정 변경, 활성화, 갱신 작업까지 직접 수행할 수 있다는 점에서 기존의 SNMP보다 훨씬 강력하다.
NETCONF의 주요 기능으로는 다음과 같은 작업들이 있다. 여러 장비에 걸친 설정 값을 조회하거나 수정할 수 있고, 구성된 설정을 실제로 활성화하는 작업도 가능하다. 또한 장비의 운영 데이터와 통계를 조회할 수 있으며, 특정 이벤트 발생 시 장비로부터 알림을 받아볼 수도 있다. 특히, 여러 장비에 대한 설정 변경을 원자적(atomic)으로 커밋할 수 있다는 점은 대규모 네트워크 운영에서 큰 강점이다. 예를 들어, 여러 장비의 설정을 동시에 변경한 뒤 일부에서 문제가 발생하더라도 전체 변경 내용을 자동으로 되돌릴 수 있어 일관성과 안정성이 보장된다.
기술적으로 NETCONF는 RPC(Remote Procedure Call) 패러다임을 따르기 때문에, 명령과 응답이 명확한 요청-응답 구조로 교환된다. 모든 메시지는 XML 형식으로 인코딩되어 복잡한 설정 데이터도 구조적으로 표현하고 해석할 수 있게 된다. 또한 NETCONF는 TLS와 같은 암호화된 전송 프로토콜 위에서 동작하므로, 장비 간 또는 관리자와 장비 간의 통신이 보안성과 신뢰성을 갖춘 채 이루어진다.
NETCONF는 네트워크 장비와 관리 서버 간의 안전하고 체계적인 설정 관리를 위해 세션 기반 구조로 동작한다. 세션이 시작될 때, 양쪽은 먼저
그 이후에는
작업이 끝나고 더 이상 통신이 필요 없게 되면,
NETCONF 대표적인 연산들
| NETCONF Operation | Description |
|---|---|
| 특정 구성(configuration) 데이터를 가져옴 (ex. running, candidate) | |
| 구성 정보 + 운영 상태 정보 모두 조회 (예: 인터페이스 상태 등) | |
| 장비의 설정 값을 수정함 (수정, 삭제, 추가 등) | |
| 구성 데이터 저장소(datastore)를 잠그거나 잠금 해제함 | |
| 장비의 이벤트를 실시간으로 구독/수신함 |
NETCONF RPC 메시지 예시
<rpc message-id="101" xmlns="..">
<edit-config>
<target><running/></target>
<config>
<top xmlns="http://example.com/schema/...">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>
| 줄 번호 | 코드 | 설명 |
|---|---|---|
| 01 | <xml version="1.0" encoding="UTF-8"?> | 표준 XML 선언 |
| 02–03 | NETCONF RPC 메시지이고, 고유 ID가 101이라는 뜻 | |
| 04 | 설정을 바꾸겠다는 뜻의 NETCONF 명령 | |
| 05–06 | running 구성(실시간 적용 중인 설정)을 수정하겠다는 뜻 | |
| 08 | 실제 설정 데이터를 담는 영역 | |
| 09 | 이 설정이 어떤 스키마(YANG 모델)를 따르는지 명시 | |
| 10 | 인터페이스 설정 블록 시작 | |
| 11 | 대상 인터페이스 이름 | |
| 12 | 설정할 MTU 값 | |
| 13–14 | 블록 종료 | |
| 15 | 설정 영역 종료 | |
| 16 | 명령 종료 | |
| 17 | 전체 RPC 메시지 종료 |
📡 YANG
YANG은 NETCONF 메시지에 포함되는 데이터의 구조와 의미를 정의하는 모델링 언어, 형식 뿐 아니라 값의 제약 조건까지 기술함으로써 설정의 정확성과 일관성 보장
YANG은 NETCONF와 함께 사용되는 데이터 모델링 언어로, 네트워크 장비의 구성과 운영 데이터를 구조적으로 정의하기 위해 만들어졌다. 이 언어는 NETCONF가 주고받는 데이터의 구조, 문법, 의미를 명확하게 기술하고 다양한 내장 데이터 타입을 제공해 장비의 기능과 데이터를 체계적으로 표현할 수 있게 해준다. 이런 점에서 YANG은 SNMP의 SMI와 비슷한 역할을 하지만 비교적 확장성이 뛰어나다.
YANG으로 작성된 모델은 XML 문서로 변환될 수 있다. 이를 통해 장비의 기능이나 설정 가능한 항목들을 기계가 이해할 수 있는 형태로 표현할 수 있으며, NETCONF 연산에 필요한 데이터 형식과 제약 조건을 명확히 정의해준다. 이 덕분에 각 장비가 어떤 구성을 지원하는지 네트워크 관리자가 정확히 파악하고 제어할 수 있다.
무엇보다 YANG은 단순한 데이터 구조 정의를 넘어 데이터 간의 제약 조건까지 함께 표현할 수 있다. 예를 들어 어떤 값이 설정되었을 때 다른 필드도 반드시 채워져야 한다거나, 특정 값이 허용된 범위 안에 있어야 하는 식의 논리를 명시할 수 있다. NETCONF로 전달되는 설정이 논리적으로 일관되고, 장비 간의 호환성과 정책 요구사항을 만족하도록 강제할 수 있다.