Search
Duplicate

컴퓨터 네트워크/ 네트워크 관리

네트워크 관리 개요

네트워크 관리란 현재 널리 퍼져 있는 이질적인 네트워크 및 관련 장비들을 효율적으로 연동시켜, 상호 운용성을 높이고 각각의 네트워크 자원들에 대해 적절한 관리 행위를 함으로써 네트워크 사업자들과 사용자들에게 안정적인 네트워크 서비스를 제공하는 것을 의미한다.
(이하 생략)

5대 관리 기능

사용자의 요구사항들을 만족하기 위해 네트워크 관리에서 필요한 기능들을 다음과 같이 5가지 항목으로 나누어볼 수 있다. 이들을 네트워크 관리의 5대 관리 기능이라고 한다.

장애 관리

장애 관리의 목적은 복잡한 네트워크가 원활히 동작하도록 하기 위해 제대로 동작하지 않는 네트워크의 요소들을 찾아내 문제점을 해결하는 것이다.
이는 네트워크의 노드(node)나 링크(link)에 이상이 발생했을 때, 알람을 발생시키거나 분석을 통해 원인을 파악하는 것을 말한다.
장애 관리에서 말하는 장애는 에러와는 다르다. 장애란 네트워크 운영상에 문제가 발생한 것으로 관리자가 이 장애에 대한 대처를 요하는 비정상적인 상태를 말한다.
예컨대 장비간에 연결 회선이 끊어진 경우 어떤 정보도 이 회선을 통해 전송될 수 없지만 회선 주위에 갑작스런 전자기장으로 그때 전송 중인 데이터에 이상이 발생한다면 비트 에러가 발생하게 된다.
이와 같이 비트 에러는 장애라고 보지 않고 회선이 끊어지거나 인터페이스에 이상이 발생하여 통신을 할 수 없을 때 일반적으로 장애로 간주한다.

계정 관리

계정 관리란 시스템에서 소비되는 자원에 관한 모든 정보를 관리하는 것을 말한다. 계정 관리는 자원에 대한 사용자의 접근 권한을 관리하여 네트워크 자원에 접근하려는 사용자가 정당한 사용자인지를 인증 해줌으로써 비 인가자의 네트워크 자원에 대한 오용 및 악용을 미연에 방지할 수 있다.
계정 관리는 이 외에도 몇 가지 기능을 더 수행한다. 네트워크 자원들을 운용하기 위해서는 비용이 부과되는데, 많은 ISP 업체들은 사용자들이 네트워크 자원을 얼마나 많이 사용하였는지를 파악하여 요금청구를 하는 등의 방법으로 관리 비용을 충당할 수 있게 된다.
또한 사용자들이 어떤 자원을 얼마만큼 사용하였는지에 대한 정보를 통해 사용자들이 많이 사용하는 자원을 좀 더 효율적으로 사용할 수 있도록 네트워크 구성을 설계하는데에도 이용하게 된다.

구성 관리

구성 관리는 네트워크 구성요소들 사이의 관계와 상태를 보여준다. 그리고 네트워크 구성은 수시로 변경될 수 있는데, 사용자가 많아지거나 줄어듬으로 인해 네트워크를 재구성하고자 할 때 네트워크 장비의 추가, 삭제, 변경 기능을 통해 네트워크 구성이 빈번하게 변경된다.
이렇게 빈번하게 구성 정보가 바뀌기 떄문에 이들에 대한 기록은 최소한으로 적게 해야 한다. 구성 변경시의 관리 정보는 물리적 구성, 접속 장비, 전송 속도, 사용하고 있는 프로토콜과 주소 체계, 각 장비의 정보 등이 있다.
네트워크 구성을 관리자나 사용자가 해당 네트워크 구성을 한눈에 알아 볼 수 있도록 그래픽하게 나타낸 것을 네트워크 구성도라고 한다. 이와 같은 네트워크 구성도는 항상 최신의 구성도를 관리하고 보존해 두는 것이 구성 관리의 기본이 된다.
구성도에서는 관리자가 보고자 하는 기본적인 관리 정보도 표시하고 있지만, 특별한 이벤트가 발생했을 떄는 관리지가 이 이벤트에 대해 바로 확인할 수 있도록 해줘야 한다.
그리고 구성 관리에서는 관리자가 네트워크 관리를 위해 필요한 기본적인 정보인 장치 이름, IP, 위치, 타입(허브, 라우터, 브리지, 기타 네트워크 요소) 등에 대한 기본적인 정보를 유지하고 있어야 한다.
대부분의 경우 장애 관리를 위해서는 구성 관리 기능을 포함하게 된다.
네트워크 장애가 발생하였을 때 네트워크 관리를 위해 사용되는 SNMP(Simple Network Management Protocol) MIB(Management Information Base)를 재설정함으로써 장애를 복구하거나 네트워크 구성을 재구성함으로써 장애를 해결할 수도 있기 때문이다.

성능 관리

성능 관리란 장기간에 걸쳐 네트워크의 처리율이나 이용도, 응답시간 등의 시스템 성능에 관한 정보를 수집하고 분석하는 것을 말한다. 이러한 정보는 네트워크의 확장 계획이나 유지보수 등을 위해서 사용될 수 있다.
그리고 성능 관리 기능은 네트워크를 운용할 때 병목 변상이 발생한 구간을 확인하고 네트워크 장비의 식나당 작업 부하율을 분석하여 네트워크 재구성 및 계획에 근거 자료로 사용된다.
성능 관리에서는 네트워크 장비간 트래픽 흐름을 관리하고 현재 사용률과 성능에 관련된 분석 결과를 제공한다. 다시 말해 성능 관리를 위해 관리자가 관심 갖는 선로의 이용률이나 네트워크에 과도한 트래픽이 있는지 병목 현상이 발생한 구간이 있는지 응답 시간이 길어지는 지에 대한 정보를 제공한다.

보안 관리

보안 관리는 패스워드나 암호화된 데이터 링크를 유지 부소하고 보안 행위를 기록해 두는 것을 말한다. 보안 관리 기능에서는 클라이언트/서버 환경에서의 패스워드, 제한적인 접속 권한, 보안 로그, 암호화 장치 등에 관련된 정보를 관리한다.
암호화를 위해서는 사전에 암호화 키를 생성하고 분배하는 과정이 필요하며 이 키에 대한 관리도 또한 보안 관리에 포함된다.
보안 관리에서 중요하게 여기는 것은 로그이다. 여기에는 각가지 보안에 관련된 사용자 접근이나 에러에 대한 기록이 있으므로 이를 분석하여 불법적인 침입이나 시스템에 대한 부정행위를 파악할 수 있으며 이에 대한 대비책을 마련할 수 있도록 한다.

네트워크 관리 구조

네트워크 관리 구조에서 중요한 구성 요소는 관리하고자 하는 네트워크 장비를 감시하고 제어하는 네트워크 관리국과 호스트, 게이트웨이, 터미널 서버 등과 같은 네트워크 구성 장비들이 네트워크 관리국으로부터 요청된 정보를 제공해주므로 네트워크 관리 기능을 수행할 수 있도록 하는 에이전트가 있다.
이들 두 구성 요소의 상호 동작을 통해 네트워크 관리를 수행하는데, 이와 같은 기능을 수행하는 시스템을 네트워크 관리 시스템이라고 한다. 그림 11-7은 네트워크 관리 구조를 간단하게 나타내고 있다.

네트워크 관리 시스템 구조

네트워크 관리를 위해서는 관리하고자 하는 네트워크 장비들에 대한 감시와 제어를 수행할 수 있어야 한다. 이와 같은 기능을 제공하기 위해서는 필요한 기능들을 모아둔 것이 네트워크 관리 시스템이다.
다시 말해 네트워크 관리 시스템은 관리자가 에이전트들을 모니터링 할 수 있도록 상태 정보를 보여주거나 이들 장비에 대한 제어를 할 수 있는 사용자 인터페이스를 제공한다.
네트워크 관리를 위해 사용되는 이 소프트웨어는 워크스테이션이나 서버 등의 호스트와 브리지나 라우터 같은 네트워크 장비들에 존재한다.
네트워크 관리 시스템은 하나의 통합된 구조로서 전체 네트워크의 상황을 보여줄 수 있도록 설계되는데, 이 구조에서 에이전트들은 관리국이 이들에 대한 관리를 수행할 수 있도록 필요한 정보를 제공하고, 또한 어떤 에이전트들은 어떤 상황에 대한 상태정보를 통보하기도 한다.
그림 11-8은 네트워크 관리 시스템의 구조를 보여준다. 이 구조에서 각각의 네트워크 장비를 하나의 네트워크 관리 개체(Network Management Entity: NME)로 볼 수 있으며, 여기에는 네트워크 관리를 위해 사용되는 소프트웨어들이 포함되어 있다. 일반적으로 이들 NME를 에이전트라고 한다.
NME가 하는 주요 역할은 다음과 같다.
장비에 들어오고 나가는 트래픽의 통계 저옵를 수집한다.
수집한 통계 정보를 지정된 저장장치에 저장한다.
관리국으로부터의 요청을 처리한다.
관리국에 수집된 통계 정보를 제공한다.
변수 값을 바꾼다.
상태 정보를 제공한다.
특정 정보를 수집할 수 있도록 인위적인 설정을 한다.
장비에 이상 발생 시 관리국에 이를 즉시 알리는 메시지를 보낸다.
그림 11-8에서 보듯이 네트워크 관리 시스템의 구조에서는 네트워크 관리를 수행하는 관리국이 반드시 하나 존재하게 된다. 이 관리국에는 NME 뿐만 아니라 네트워크 관리 응용(Network Management Application: NMA)이라 불리는 소프트웨어를 포함하고 있다.
이 NMA는 네트워크 관리 호스트와 관리자 사이의 인터페이스로 관리자가 네트워크 관리 행위를 할 수 있도록 필요한 기능들을 제공해 준다.
관리자가 네트워크에 퍼져 있는 NME에 대해 정보 요청 명령을 내리면 이 명령을 수행하여 관리자가 원하는 NME에 정보를 요청하여 수신한 정보를 관리자에게 제공하게 된다. 이떄 NMA와 NME 사이에 통신을 위해서 네트워크 관리 프로토콜을 사용한다.
위에서도 살펴 보았듯이 네트워크 관리 구조에서는 관리 기능을 수행하는 관리국과 관리국의 관리를 받는 에이전트 그리고 관리국과 에이전트 사이에 통신을 위해 사용되는 프로토콜 그리고 에이전트의 관리 정보를 담고 있는 MIB 이렇게 4가지 구성요소가 그림 11-9처럼 구성되어 있다.

관리국(Manager)

관리국은 네트워크 관리 센터의 중앙에 위치하며 관리자와 에이전트들 사이의 인터페이스 역할을 수행한다. 관리국은 네트워크 관리를 위한 제반 활동의 중심에 있다.
즉 관리서버는 네트워크 관리를 위해 필요한 정보의 수집, 처리, 분석 그리고 이들 분석 정보를 어떻게 관리자에게 보여줄 것인지를 제어하게 된다.
여기에서 수행하는 기능은 네트워크 운용을 원활히 하기 위해 환경 설정을 초기화 하거나 필요한 제어를 수행하는 것이고 또한 관리자와 에이전트들 간의 상호 의사소통을 돕는다.
관리자가 어떤 에이전트의 정보를 보고자 할 때 이 장비에 실시간으로 정보를 요청하여 보여주거나 관리자가 이 장비의 환경 설정을 바꾸고자 명령을 내렸을 떄, 이 명령을 받아 환경 설정값을 변경할 수 있도록 관리 및 제어가 용이하도록 해준다.
또한 장비가 자신에게 발생한 특별한 이벤트를 알리기 위해 발생시키는 정보를 트랩(Trap)이라고 하는데, 이 트랩 메시지를 받아 관리자에게 전달해 주는 역할도 수행한다.

에이전트(Agent)

에이전트는 관리되는 네트워크 상에 존재하는 네트워크 장비들을 말한다. 에이전트로는 호스트, 라우터, 브리지, 허브, 프린터 또는 모뎀 같은 전산 장비들이 있다.
에이전트들은 에이전트를 구성하는 하드웨어와 이들에 대한 기본 정보 및 이들 하드웨어를 통해서 처리되는 트래픽에 대한 정보를 담고 있는 소프트웨어로 이루어져 있다.
에이전트가 갖는 소프트웨어에는 MIB라는 것이 있는데, 이는 네트워크 구성 정보나 트래픽 처리 등의 정보들을 저장하는 데이터베이스이다.
또한 각 에이전트에는 관리국의 명령과 제어 하에 있는 에이전트와 관리국 사이의 통신을 하기 위한 네트워크 관리 에이전트 프로세스가 존재한다.

MIB(Management Information Base)

MIB는 네트워크 관리의 핵심 요소 중의 하나로서 네트워크를 관리하는데 필요한 모든 정보를 보관하고 있는 저장소이다. 관리되는 네트워크의 모든 자원들은 객체로서 표현이 되며, 이러한 객체들을 모아 놓은 곳이 바로 MIB이다.
TCP/IP나 OSI 환경에서는 각각의 관리하려는 자원을 객체로 표현하고 있는데, MIB는 그러한 객체들의 구조적인 모임을 말한다.

네트워크 관리 프로토콜

네트워크 관리 프로토콜은 관리국이 에이전트의 상태를 물어보는 것을 허용하고 또한 에이전트는 예외적인 사건들을 관리국에 알리기 위해 정의된 절차이다. 네트워크 관리 프로토콜 자체가 네트워크를 관리하는 것이 아니라 네트워크 관리자가 네트워크를 관리할 수 있도록 도구를 제공하는 것이다.
TCP/IP 환경의 초기 네트워크 관리는 ICMP(Internet Control Message Protocol)에서 지원하는 에코(Echo) 명령을 이용하여 장비의 상태나 회선 상태 등을 파악했다. 이는 단순하게 호스트가 동작하고 있는지에 대한 정보나 응답 시간을 측정하는 등의 기능만을 제공했다.
그러나 네트워크를 구성하는 호스트 수가 증가하고 네트워크 구성이 복잡해지면서 새로운 표준화 프로토콜이 필요하게 되었고 이에 따라 88년 초 IAB(Internet Architecture Board)에서는 표준화 작업을 시작하게 되었다.
HEMS(High-level Entity Management System), SGMP(Simple Gateway Monitoring), CMISE/CMIP(Common Management Information Service Element/Protocol) 등 많은 표준들이 연구되었는데, 그 중에서 HEMS는 상당히 진척되었으나 실제 적용 사례가 없었고, CMISE/CMIP는 너무 방대하고 전혀 구현되지 않은 상태였다.
그래서 결국 IAB는 네트워크 관리 표준으로 SNMP를 채택하였다. 이렇게 채택된 SNMP는 구현이 쉽고 간단해 오늘날 가장 일반적인 네트워크 관리 프로토콜이 되었다.

CMISE/CMIP(Common Management Information Service Element/ Protocol)

CMISE/CMIP는 잘 정리되고 훌륭한 개념이지만 지나치게 방대하게 규정되어 있어서 구현하기 쉽지 않고 시스템도 SNMP에 비해 무척 크다. 그래서 쉽게 SNMP를 대체하지 못하고 있다.
그러나 최근 TMN(Telecommunication Management Network) 영역에서는 CMISE/CMIP가 많이 사용되고 있다. 그리고 CMIP를 이용한 각종 개발 도구들이 발표되고 있다.
그림 11-10은 OSI 관리 구조를 보여주고 있다.

CMISE(Common Management Information Service Element)

OSI 시스템 관리에서 기본적인 기능은 관리국과 에이전트가 정보를 교환하는 것이다. 이때 에이전트를 관리하기 위해 정보와 명령을 교환하기 위해서 이용하는 것이 CMISE다.
CMISE는 사용자 응용 프로그램과의 인터페이스 역할을 담당하는 CMIS와 PDU(Protocol Data Unit) 및 관련 절차를 규정한 CMIP로 이루어진다.
CMIS 서비스는 기본적으로 요청 받은 서비스에 대해 응답을 해주는 확인 서비스들과 응답을 하지 않는 비확인 서비스로 나눌 수 있다. 이들 서비스를 3가지 범주로 나눠 살펴보면 다음과 같다.
Association Servcie
이 서비스는 통신을 하기 위해 해당 시스템의 응용 프로그램과의 연결 및 해제를 위해 필요하다. 이는 ACSE(Association Control Service Element)를 이용한다.
Management Notification Service
이 서비스는 에이전트들에 대한 특정 사건을 보고하는데 이용하는 것으로 필요한 속성, 행동 및 작동 절차 등에 대한 내용은 각 에이전트들에 정의되어 있다.
Management Operation Service
시스템 관리를 위해서 관리 객체들에 대한 정보를 주고 받는데 이용된다.

CMIS(Common Management Information Service)

시스템간 연결 및 해제를 위한 서비스인 A-Associate, A-Release, A-Albort가 있고 에이전트에서 관리자에게 에이전트에 발생한 특정 상황을 통지하는 M-Event-Report 서비스가 있다.
M-Event-Report는 SNMP의 트랩(Trap)과 같은 기능을 수행하나 이 메시지를 받은 관리자가 받았다는 확인을 해주어야 한다는 차이가 있다. 그리고 실제로 관리 객체들에 대한 정보를 주고받는 서비스인 Management Operation Services에는 다음과 같은 6가지가 있다.
M-Get
에이전트에게 관리정보를 요청한다.
M-Set
에이전트의 관리정보를 수정하도록 요청한다. 관리객체의 속성값을 바꾸기 위해서 대체, 기존 값에 추가, 기존 값의 제거, 기본값 설정 등의 하나를 반드시 명시해야 하고, 기본동작은 대체로 가정한다.
M-Action
관리객체에 사전에 정의된 특정한 동작을 실행하게 한다. 요청 시는 동작 종류를 반드시 명시해야 한다.
M-Create
객체 클래스의 새로운 사례를 만들기 위해서 사용되는 서비스이다.
M-Delete
에이전트의 하나 이상의 관리 객체를 삭제 시에 이용된다.
M-Cancel-Get
이미 요청된 M-Get을 중지시킬 때 이용되는데, 이를 사용하는 이유는 MIB가 수정도중에 문제가 발생하면 MIB의 일관성을 보증하기가 어렵기 때문이다.
이 서비스가 에이전트에 도달하면 에이전트는 실행 중인 M-Get에 대한 응답으로 취소 에러를 보내고 M-Cancel-Get에 대한 응답을 보낸다.
그 외에 M-Event-Report를 포함한 7가지 서비스 중에서 M-Get, M-Create, M-Delete, M-Cancel-Get은 반드시 응답을 받아야 하는 확인 서비스이고, 나머지는 서비스 요청 시에 확인/비확인을 위한 파라미터를 주어야 한다.
M-Get, M-Set, M-Action, M-Delete는 관리 객체를 선택하는데 많은 이점을 주는 3가지 파라미터, 즉 범위, 여과, 동시성을 가질 수 있다.
1.
범위(Scoping)
아래와 같이 동작의 대상이 되는 관리 객체의 범위를 지정할 수 있다.
기초 관리 객체(Base Management Object)만 지정한다
기초 객체를 0 레벨로 놓고 N번째 레벨의 하위 객체들을 지정한다.
기초 객체부터 N번째 레벨의 하위 객체들까지 포함한다.
기초 객체 이하의 모든 하위 객체들을 포함한다.
2.
여과(Fitering)
위의 범위 안에 드는 객체들 중에서 일정한 속성값을 만족시키는 객체만을 선택할 수 있다. 그 법칙은 아래와 같다.
일치(Equality)
크거나 같다. 작거나 같다.
존재(Present)
객체의 속성이 존재한다.
일부문자열(Substring)
객체 속성값이 주어진 문자열을 포함한다.
Subset of
필터링을 위해 요청하는 모든 멤버들이 객체의 속성에 있다.
Superset of
속성의 모든 멤버들이 필터링을 위해 요청하는 속성에 있다.
Non-null-set intersection
요청하는 멤버들 중에 최소한 하나는 그 속성에 있다.
3.
동기화(Synchronization)
범위에 의해 선택된 관리객체들에 대해 필터링 법칙에 의해 선택이 이루어진다. 그러나 필터링 규칙이 여러가지 적용될 수 있는데, 이에 대한 순서는 정해져 있지 않고 구현에 맡겨놓고 있다.

CMIP(Common Management Information Protocol)

CMIp는 관리정보를 전송하는 절차, 즉 CMISE 사이에 CMIS 서비스를 완성시키기 위해 교환하는 CMIP PDU를 만들고 전송하는 것을 정의해 놓은 것이다.
양단의 CMISE 사용자들이 정보 교환을 위해 시스템을 연결하는데, 이때는 CMIP를 이용하지 않고 ACSE를 이용한다.
관리 서비스를 위해 CMISE는 PDUs를 교환하기 위해 CMIP를 채용한다. 그리고 CMIP는 CMIP PDU 전송을 위해서 ROSE(Remote Operations Service Element)를 이용한다.
CMIP는 CMIS 서비스를 처리하기 위해 11개의 PDU를 정의해 놓았다. ROSE는 몇 가지 결합 군(Association Class)를 정해 놓고 있다. CMIP는 항상 ROSE 3를 이용한다.
그리고 확인 서비스를 위해서는 ROSE 2 또는 3을 이용하고 비확인 서비스를 위해서 ROSE 5를 이용한다.

OSI MIB

OSI MIB의 가장 큰 특징은 객체지향적인 개념을 수용하고 있다는 것이다. OSI MIB는 X.720, X.721, X.722에 잘 정의되어 있다.
특히 X.722에 정의된 GDMO(Guidelines for the Definition of Managed Objects)는 객체들의 클래스, 객체의 행동(behavior), 속성(Attributes) 등을 명시하는 방법을 제공하는 구조화된 기술 언어이다.
X.720 시리즈인 관리정보 모델은 관리개체에 대한 개념, 즉 속성, 관리 객체에 수행될 수 있는 작동의 종류, 관리객체가 발생시킬 수 있는 통지(Notification) 등이 세밀하게 기술되어 있다. 또한 관리객체를 어떻게 이름을 만드는가도 정의되어 있다.
OSI에서 정의한 객체는 행동 및 속성, 통지, 동작 등을 캡슐화하며 그 객체를 상속하여 새로운 객체를 만들 수 있다.
SNMP가 테이블 개념으로 객체를 관리하는데 반해 OSI MIB는 포함(Containment) 개념을 이용한다. 즉 한 각채가 하나 이상의 다른 객체를 포함할 수 있다는 것이다. 물론 객체를 포함하고 있는 객체도 다른 객체의 하위 객체가 될 수 있다. 그러나 한 객체는 하나의 상위 객체에만 포함되어야 한다.

인터넷 관리 구조

SNMP(Simple Network Management Protocol)은 실제적으로 프로토콜 자체, 데이터베이스 정의, 관련된 개념을 포함한 네트워크 관리에 대한 명세서들을 모아 놓은 것을 말한다. SNMP의 개발 배경은 TCP/IP와 더불어 생성되고 발전되었다.
그러나 SNMP 프로토콜의 단순함 때문에 SNMP 개발자들은 OSI의 설비를 갖는 여러 가지 제한으로부터 자유로울 수 있어서 SNMP를 이용한 네트워크 관리 시스템의 개발이 쉬었다. 그래서 SNMP는 일반 사용자가 선택하는 표준화된 관리 프로토콜이 되었다.

기본 개념

SNMP는 TCP/IP의 응용 계층 프로토콜로 디자인 되었고, UDP 상에서 수행되도록 되어 있다. 그림 11-11은 전형적인 SNMP 프로토콜의 구성을 보여준다. 단독으로 동작하는 관리국에서 관리자 프로세스는 관리국의 MIB에 대한 접근을 조절하고 네트워크 관리자에 대한 인터페이스를 제공한다.
SNMP가 비접속 프로토콜인 UDP를 사용하여 메시지를 주고 받기 때문에 SNMP는 관리국과 에이전트 사이에는 어떤 접속도 유지되지 않는다. 다시 말해 각각의 메시지 교환시 관리국과 에이전트 사이에 개별적인 접속이 이뤄지는 것이다.

SNMP(Simple Network Management Protocol)

SNMP는 네트워크 호스트들이 네트워크 관리를 위해 필요한 정보를 주고받기 위해 사용되는데 이 SNMP는 3개의 개별적이며 연관된 RFCs에 의해 정의되었으며 많은 다른 것에 의해 확자오디었다.
다음에서는 SNMP 프로토콜의 동작 과정을 살펴보겠다. 그림 11-12는 SNMP의 프로토콜 동작 과정을 보여준다.
SNMP에서 프로토콜 동작은 3가지의 서비스로 이루어진다. GetRequest, GetNextRequest, GetBulkRequest와 같은 Gets, Set, Trap 메시지로 구성되며 관리국들 간의 통신은 InformRequest를 이용한다.
Gets와 Set은 관리국에서 만들어져 에이전트에서 실해행되며 트랩은 에이전트에서 만들어져 관리국에게 알리게 된다. 그림 11-13은 SNMP 메시지 형태를 보여주고 있다.
구분
Version
관리국과 에이전트 간에 사용 중인 SNMP 버전이다. v1, v2, v3가 있으며 각각의 메시지 포맷은 조금씩 다르다. 만일 관리국과 에이전트 간의 버전이 일치하지 않으면 에러가 발생한다.
Community
관리국과 에이전트 간에 미리 정의된 값으로 이 값이 일치해야 한다. 이것은 아주 간단한 인증을 위한 것이다. 기본적으로 Get에서는 public을 Set에서는 private을 사용한다.
SNMP PDU
SNMP PDU에도 여러 가지 타입이 있으며 Request, Response, Trap 타입들의 PDU 형태가 있다.
여기서 PDU-type은 관리국이 에이전트에게 요구하거나 에이전트로부터 관리국에 결과가 올 때 어떤 요청인지를 알려주기 위한 것으로 Get-Request, Get-Response, Get-Next-Request, Get-Next-Response, Set-Request, Set-Response, Trap 등이 있다. 여기서 Response Type은 error-status와 error-index 필드만 다르다.
request-id
SNMP 요청 패킷 Identifier를 말한다.
variable-binding
관리자 시스템이 얻고자 하는 정보 즉 객체 확인자(Object Identifier)를 말한다. 관리국이 한번에 1개의 객체를 요청하는 것이 아니라 여러 개의 객체를 동시에 요청할 수 있다.
따라서 원하는 객체를 1~N까지 (OID + Value) ... (OID + Value) 형태로 묶어서 요청한다.
error-status
오류발생 원인을 알려주기 위해 사용하며, 요구한 객체 확인자 값의 종류는 noError(0), tooBig(1), noSuchName(2), badValue(3), ReadOnly(4) 등이 있다.
error-index
error-status에 해당하는 값이 없을 때 부가 정보를 알려주기 위해 사용한다.
SNMP 패킷을 주고받을 떄 사용하는 포트(port)는 161번을 사용하며 Trap을 위해 사용하는 포트는 162번을 사용한다. 그림 11-14는 이와 같은 통신 구조를 보여주고 있다.

CMIP와 SNMP의 비교

아래 표에서 보듯이 관리 구조는 객체지향적인 GDMO와 그렇지 않은 SMI에 가장 큰 차이가 있다.
현재 대부분의 장비가 SNMP를 이용하고 있으나, 모든 장비의 통합관리라는 개념의 TMN 하에서는 CMIP가 채태고디고 있고 많은 개발 도구들이 등장하고 있다. MARBIN, IBM, SUN, HP 등에서 개발 도구 및 플랫폼을 지원하고 있다.
광섬유 네트워크에서 셀룰러와 위성을 기반으로 한 무선통신시스템이 등장하고 이들을 함꼐 관리해야 할 필요성 때문에 TMN이 서서히 각광을 받고 있고 이에 따라 CMIP도 관심을 받고 있다.
항목
CMIP
SNMP
스키마
GDMO
SMI
상속성, 동질성
지원함
지원안함
객체 관계성
포함 형태
테이블 형태
객체 이름
구분된 이름
객체 확인자
범위, 필터링
지원함
지원 안함
통신 방식
연결형
비연결형(v2는 연결형 규정)
관리 방식
Event-Driven
Trap-polling
통신 확인
응답 확인 또는 선택
응답 확인 기능 없음
기본 서비스
M-Get, M-Set, M-Delete, M-Create, M-Action, M-Event-Report, M-Cancel-Get
Get, Get-Next, Set, Trap, Get-Response, Get-Bulk(v2), Get-Info-Reo(v2)

MIB(Management Information Base)

네트워크 관리 시스템의 기초는 관리하려는 요소에 관한 정보를 포함하는 데이터베이스를 정의하는데 있다. TCP/IP나 OSI 환경 모두에서 이 데이터베이스를 MIB라고 한다.
각각의 관리하려는 자원은 객체로 표현되며, MIB는 이렇나 객체들의 구조적인 모임이다. 시스템의 각 노드는 각 노드가 관리하려는 자원의 상태를 반영하는 MIB를 생성, 유지한다.
네트워크 관리 시스템은 MIB의 객체 값을 읽음으로써 노드의 자원을 감시하고, 그러한 값들을 변경함으로써 노드의 자원을 제어할 수 있게 된다.

SMI(Structure of Management Information)

RFC 1155에서 제정한 SMI는 MIB이 구성되고 정의될 수 있는 범위 내에서의 일반적인 골격을 정의한다.
SMI는 MIB에서 쓰일 수 있는 데이터의 형태와 MIB의 자원들이 어떻게 나타내어지고 이름 붙여지는지를 정의한다. SMI 배경 철학은 MIB 내에서의 단순성과 확장성이다. 그러므로 MIB는 단지 단순한 형태의 데이텀나을 저장할 수 있다.
SNMP는 표의 항목으로 포함된 스칼라만을 검색할 수 있다. SMI는 복잡한 데이터 구조의 검색이나 생성은 지원하지 않는다. 이러한 철학은 복잡한 데이터 구조를 제공하고, 더욱 풍부한 기능을 지원하기 위한 검색 방법을 제공하는 OSI 관리와는 대조적이다.
1993년 SMI는 SMIv2, RFC 2578-2580로 기능 향상을 하였으나 큰 골격은 유지된 상태이다.
1.
MIB 구조
MIB의 객체 형태는 ASN.1의 객체 확인자이다. 이 객체 확인자는 객체에 이름을 제공한다. 게다가 객체 확인자와 연관된 값들이 계층적이기 때문에 이름을 짓는 규약은 객체 형태의 구조를 구분 지을 수 있어야 한다.
이 값들은 정수의 연속된 나열이며 정의된 객체의 집합은 트리 구조를 갖는다. 객체 확인자 트리의 루트에서 시작하여 첫 단계에 iso, ccitt, joint-iso-ccit 이렇게 3개의 노드가 있으며 iso 노드 아래의 한 서브 트리는 다른 조직용으로 쓰이는데 이들 중의 하나가 Department of Defense(DoD)이다.
RFC 1155는 DoD 밑의 한 서브 트리를 Internet Activities Board(IAB)의 사용을 위해 할당하고 있다.
Internet Object Identifier ::= { iso org(3) dod(6) 1 }
그래서 internet 노드는 1.3.6.1의 객체 확인자의 값을 갖게 된다. 이 값은 트리의 다음 노드 하위 단계에서 노드에 대한 접두어로 사용된다. 보는 바와 같이 SMI 문서는 internet 노드 밑에 4개의 노드를 정의하고 있으며 그림 11-15는 MIB-II의 객체 그룹을 보여주고 있다.
directory
이 서브트리는 나중의 OSI directory(X.500)의 사용을 위해 보존된다.
mgmt
이 서브트리는 IAB 개발 문서에 정의된 객체들 용으로 쓰인다.
experimental
이 서브트리는 internet 실험에 쓰인 객체를 나타내는데 쓰인다.
private
이 서브트리는 개별적인 확장을 위해 정의된 객체를 나타내기 위해 쓰인다.
MIB-I과 MIB-II, RMON1, 2와 같은 여러 가지 버전의 MIB가 존재하며 MIB-II는 MIB-I을 확장한 것이다. 그리고 MIB-II 서브 트리는 완전히 새로운 버전에 의해 확장되거나 대치될 수 있다.
실험적인 MIB는 특정 응용 프로그램에 대해 만들어질 수 있고, 그러한 객체는 실제로 mgmt 서브트리로 이동될 수 있다. 개별적으로 MIB를 확장할 경우에는 private 서브 트리에 추가할 수 있다. private 서브트리에는 enterprises 라는 하나의 서브 트리를 갖고 있다.
서브트리의 이 부분은 판매업자에게 그들의 장치에 대한 관리 수준을 높이고 자신들의 시스템들에 대한 상호작용을 필요로 하는 판매업자나 사용자간의 정보 공유를 허락한다.
internet 노드의 4부분은 강력한 MIB 확장의 기본이 된다. 그러므로 MIB는 관리하려는 객체가 MIB의 표준화된 부분에 맞게 하고, 새로운 제안이나 기술을 수용하도록 변화에 충분히 대응할 수 있는 유연성이 있다.
2.
MIB-II
MIB-II(RFC-1213)는 MIB-I의 두 번째 버전이다. 첫 번째 버전인 MIB-I는 RFC-1156에 정의되어 있다. MIB-II는 몇 개의 객체와 몇 개의 그룹을 더한 MIB-I의 부분 집합이다. MIB-II는 단지 설계자에 필요한 것만 인정하므로, 어떤 객체도 선택적이 될 수는 없다. MIB-II 객체는 아래 그룹으로 나뉜다.
system
시스템에 관한 전체 정보
interfaces
시스템으로부터 서브네트워크에 대한 각각의 인터페이스에 대한 정보
at (address translation; deprecated)
인터넷에서의 주소변환 표에 대해 서술
ip
임의의 서브네트 마스크를 지원하는 IP 경로설정 서브시스템들을 위한 정보
icmp
ICMP의 구현과 실행 연구와 관련된 정보
tcp
지원되는 최대 연결 개수, 연결된 개수, 특정 연결 정보(connection state, local address, local port, remote address 그리고 remote port)
udp
수신된 UDP 데이터그램의 총 개수와 에러 개수에 관한 정보
egp
다양한 메시지 개수와 EGP 이웃에 관련된 정보
transmission
각 시스템에서의 전송 기법과 접근 프로토콜에 관한 정보
snmp
SNMP에 관련된 정보
그룹 조직은 관리하려는 객체의 기능과 관련된 관리하려는 객체를 조직하는 규칙이다. 추가로 어떤 객체가 반드시 구현되어야 하는지 알기 위해 관리하려는 에이전트에 구현에 대한 안내서를 제공한다.

SNMPv2(Simple Network Management Protocol version2)

원래 SNMP는 최소한의 네트워크 관리 능력을 제공하는 임시방편 도구로 개발되어 매우 단순하고 쉽고 빠르게 구현될 수 있다는 장점이 있었으나 관리해야 할 네트워크가 커지면서 성능상의 문제, 대용량 데이터 검색의 문제, 트랩 정보의 확인 불가, 취약한 보안 문제 등의 약점이 존재했다.
이를 보완하기 위해 1992년 secure SNMP, SMP(Simple Management Protocol)가 발표되었다. 이 두 가지 규격을 기초로 하여 특히 보안 부분을 보완한 SNMPv2 규격이 개발되었으나 1996년 새로운 SNMPv2 규격이 발표될 때에는 원래의 제안표준에 있었던 많은 보안과 관련된 부분들이 제거되기도 하였다.
그러므로 SNMPv2에서도 여전히 보안 측면이 강화되지 못했으며, InformRequest 및 Report PDU를 어떻게 수용하는지가 명확하지 않고 성능상의 문제점도 여전히 존재하고 있는 상태이다.
또한 SNMPv2는 SNMPv2p, SNMPv2c, SNMPv2u 등이 존재하여 혼란스럽기도 했다.
따라서 IETF에서는 1996년 6월 회의부터 차세대 인터넷 망관리 프로토콜을 구상하기 시작하였으며 이를 SNMPv3로 명명하여 1998년 1월에 RFC 2271-2275 제안 표준(Proposed Standard) 문서로 발표하게 되었다.

비 집중 네트워크 관리

기존의 중앙에서 네트워크 전체를 관리하는 구조에서는 하나의 호스트가 관리국의 역할을 수행하는 형태였다. 따라서 관리국 호스트 뿐만 아니라 피 관리 객체들은 관리국으로부터 제어와 모니터링을 위해 정보 데이터베이스인 MIB와 NME 소프트웨어를 포함하게 된다.
그러나 네트워크가 방대해지고 트래픽이 증가함에 따라 중앙 집중적인 네트워크 관리 구조는 전체 네트워크를 관리하기에는 관리국에 너무 많은 부하를 주므로 관리국이 제대로 작동하지 않을 수도 있게 되었다.
따라서 중앙 집중적인 네트워크 관리보다는 비집중적이고 분산된 네트워크 관리 구조방식이 더 효율적으로 네트워크 관리를 수행할 수 있게 되었다.
비집중 네트워크 관리 구조에서는 여러 개의 관리국이 존재하게 되는데 이들 각 관리국들은 관리하고자 하는 네트워크 전체 중 일부의 에이전트들을 관리하게 된다. 이들 관리국들은 자신이 관리하는 에이전트에 대한 관리 책임도 가지고 있지만, 이들 관리국은 보다 더 높은 단계의 관리국으로부터의 제어를 받게 된다.
다시 말해 자신이 관리하는 네트워크의 에이전트들에 대해서는 관리국으로 역할을 수행하지만, 상위의 관리국에 제어를 받기 위해 에이전트의 역할도 수행하게 된다.
이러한 구조는 트래픽을 분산시키므로 전체적으로 네트워크 트래픽을 줄일 수 있고 관리국에 집중된 부하 또한 분산 시킬 수 있게 하였다.
비집중 네트워크 관리 구조에서는 관리국들 사이의 상호 협조가 필수적이다. 관리국 대 관리국간의 상호협조를 제공하기 위해 SNMPv2는 Inform-Request 명령과 관리자 대 관리자 MIB를 제공하고 있다.
관리국에서 다른 관리국에 보낼 정보가 있는 경우에 Inform-Request 명령을 사용하여 보내게 된다.
예컨대 물리적인 링크의 다운이나 네트워크에 과도한 트래픽의 집중과 같은 비정상적인 상황들에 대해서 다른 관리국에 Inform-Request 명령을 사용하여 이런 상황을 알릴 수 있다.
이런 자발적 통보는 비집중 네트워크 관리 구조를 구성하는데 중요한 역할을 수행한다.
상위의 관리국은 하위의 관리국에서 관리하는 네트워크에 대한 모든 상황을 알 필요가 없어졌다.
예컨대 상위 관리국의 처리가 필요한 상황이 발생했을 때 하위의 관리국은 상위의 관리국에게 Inform-Request 명령을 사용하여 알릴 수 있다.
또한 SNMPv2에는 관리자 대 관리자 MIB라는 것이 있다. 이 MIB는 자신이 관리하는 네트워크에 어떤 문제가 발생하였을 때 상위 관리국에 통보를 할 것인지를 설정하기 위해 사용되는 테이블을 정의해 놓고 있다.
우에서도 살펴보았듯이 과도한 트래픽의 발생이나 물리적인 링크의 다운과 같은 특별한 이벤트가 발생했을 때, 이를 상위 관리국에 전달되는 통보 안에 어떤 정보가 들어 있는지, 이 통보를 수신할 관리국들의 정보에 대해 정의하고 있다.
이와 같은 구조에서는 미리 정의된 사건이 발생했을 때만 상위의 관리국에 통보하고, 하위의 관리국은 하부의 관리국 및 에이전트들에 대한 관리를 수행하는 분산 네트워크 관리 체계를 구성하는 것이 쉽다는 장점이 있다.

대량 데이터 전송

SNMPv1에서는 한 번의 요청에 제한된 데이터량 만을 교환할 수 있기 때문에 에이전트나 관리국에서는 필요한 정보를 얻기 위해 여러 번 요청을 발생시켰고, 이로 인해 네트워크에 트래픽을 가중시켜 결과적으로 네트워크 상의 심각한 병목현상을 발생시키게 된다.
이를 개선하기 위해 한번에 많은 메시지를 교환할 수 있도록 SNMPv2에서는 GetBulk라는 새로운 명령을 추가하였다.

보안

SNMPv2에서는 보안에 대한 사용자 요구조건을 만족하기 위해 다음 세 가지 기능인 인증(authentication), 암호화(secrecy), 접근 제어(access control) 개념을 수용하고 있다.
1.
인증
SNMPv1에서는 어떤 사용자든 SNMP를 이용하여 에이전트로부터 정보를 얻어올 수 있었는데, 이런 문제를 해결하기 위해 인증이라는 보안 기능을 추가하고 있는데, 인증은 에이전트가 인증도니 관리자로부터 온 명령에 대해서만 응답하도록 정당한 관리자인지를 확인하는 것이고, 또한 전송 중에 메시지의 변경이 있었는지를 확인할 수 있게 해준다.
이러한 인증 기능이 가능하기 위해 통신을 하기 원하는 두 관리자와 에이전트가 사전에 비밀키를 분배하여 가지고 있어야 한다. 관리자는 이 비밀키는 사용하여 메시지를 인증하기 위한 인증 코드를 계산하여 메시지의 뒤에 붙여서 에이전트에 전송하고, 이 인증 코드를 포함하는 메시지를 수신한 에이전트는 같은 비밀키를 사용하여 메시지에 대한 인증 코드를 계산하게 된다.
2.
암호화
암호화 기능은 제 3자가 관리자와 에이전트 사이에 메시지 교환에 대한 도청을 하지 못하도록 메시지 자체를 암호화하여 보냄으로써 제 3자가 전혀 알아볼 수 없도록 하는 것이다.
이를 위해 관리자와 에이전트는 사전에 비밀키를 분배하여 가지고 있어야 하고, 이들 사이의 모든 메시지는 DES(Data Encryption Standard)를 사용하여 암호화하여 전송하게 된다.
3.
접근 제어
접근 제어는 피 관리 객체, 즉 에이전트가 관리자에 따라 서로 다른 접근 권한을 제공하는 것을 말한다. 접근 제어는 에이전트가 관리자로부터 어떤 명령을 수신하느냐에 따라 다르게 적용될 수도 있고, 관리자가 접근하고자 하는 에이전트 MIB의 특정 부분에 적용할 수도 있다.
접근 제어를 위해서는 각 관리자마다 에이전트에서 사용할 접근 제어 정책을 미리 수립하여야 하고, 인증된 관리자들의 접근에 대한 정보를 테이블로 구성하여 에이전트가 이를 갖고 있어야 한다.

SNMPv3(Simple Network Management Protocol version3)

SNMPv2는 보안 기능들 중에서 인증과 프라이버시 기능이 부족했기 때문에 SNMPv3라는 말로 통틀어서 일컫는 일련의 RFC 문서들은 이런 결점들을 보강하고 있다.
정보들은 관리국과 에이전트 사이에서 SNMP 메시지 형태로 교환된다. 보안과 관련된 처리는 메시지 레벨에서 발생한다. 예컨대 SNMPv3는 메시지 헤더 내에 필드들을 이용하는 사용자 보안 모델을 지정한다.
SNMP 메시지의 페이로드(Payload)는 SNMPv1 혹은 SNMPv2 PDU가 된다. 일반적으로 PDU는 관리 행위의 종류와 그 관리 행위와 관련된 변수명들의 리스트를 지정한다.
SNMPv3 워킹 그룹에서 만들어낸 RFC 문서들은 전체적인 아키텍쳐와 특정한 메시지 구조들과 보안 특징들에 대하여 기술하지만 새로운 SNMP PDU 형식을 정의하지는 않는다.
따라서 기존의 SNMPv1 혹은 SNMPv2 PDU 형식이 새로운 아키텍쳐 내에서도 사용되어야만 한다. 다시 말해 SNMPv3는 SNMPv2에 보안과 인증 기능을 더한 것이다.