development/network
SNMP | Simple Network Management Protocol
아이짱구
2008. 7. 8. 14:20
인터넷의 효시인 ARPANET은 1969년 미국 국방부에서 원격 호스트간의 데이터 통신을 위해 만들어졌다. 그리고 여기에 각국 대학의 컴퓨터들이 연결되고 TCP/IP가 ARPANET의 표준 프로토콜로 채택되면서 급속히 발전하였다. 현재 인터넷은 약 4천만대의 컴퓨터가 인터넷에 연결되어 있을 정도로 규모가 커졌으며, 일반인에게도 중요한 생활요소로 자리잡았다. 이처럼 규모가 커짐에 따라, 인터넷을 효과적으로 관리하기 위한 체제의 필요성이 대두되었다. 이같은 필요성을 만족시키기 위한 대안으로 등장한 것이 SNMP이다.
노정민 한국항공대학교 항공통신정보공학과 대학
hmask@esc.cl.hangkong.ac.kr
인터넷의 관리체제는 IETF(Internet Engineering Task Force)에 의해 이루어지고 있다. 여기서는 네트워크 관리를 위한 관리 구조, 관리 정보의 구조, 관리 프로토콜 등에 대한 표준화 작업을 한다. 현재 널리 사용되고 있는 SNMP도 IETF에 의해서 제정된 인터넷 관리 프로토콜이다.
SNMP에 의한 인터넷 관리체제의 발전
SNMP는 1988년 초안(draft)으로 상정되어 1990년 인터넷 관리 프로토콜의 표준으로 제정되었다.
그 후 대부분의 워크스테이션과 브리지, 라우터, 스위치, 허브 등의 네트워크 장비에 SNMP 에이전트가 장착되었고, 시스템과 여러 응용 프로그램에도 이들을 SNMP 상에서 관리할 수 있도록 하는 MIB들이 정의되었다.
현재의 SNMP는 SNMPv2 등을 거쳐 SNMPv3로 기능이 확장되고 있으며, 관리 영역도 RMON(Remote MONi toring) MIB 등을 통해 확장되고 있는 추세이다.
인터넷 관리체제의 기원
● ICMP(Internet Control Message Protocol)
1970년대 말부터 사용된 프로토콜로 네트워크 상에서의 여러 가지 문제점들에 대한 피드백(feed-back)을 제공하기 위해 사용되었다. 라우터나 호스트들 사이에 제어 메시지(echo/echo-reply)를 전달한다. 현재 ping, traceroute 등을 통해 널리 사용되고 있다.
● SGMP(Simple Gateway Monitoring Protocol)
게이트웨이를 모니터링하기 위해 사용되었던 프로토콜로 1987년 채택되었다.
● HEMS(High-Level Entity Management System)
호스트를 모니터링 하는데 사용했던 HMP(Host Monitoring Protocol)를 네트워크 관리에 맞게 발 전시킨 프로토콜이다.
● SNMP(Simple Network Management Protocol)
SGMP를 발전시킨 모델로 주로 TCP/IP 네트워크를 관리하는데 사용되는 단순한 형태의 프로토콜이다. 처음엔 가장 광범위한 네트워크 관리체제인 OSI 관리체제(CMOT)로 가기 위한 중간 단계의 과도기적 운영 방안으로 제안되었지만, 현재 가장 널리 사용되고 있다.
● CMOT(CMIP over TCP/IP)
OSI 관리체제인 CMIP를 TCP/IP 위에서 동작하도록 만든 것. SNMP를 대체할 목적으로 제안되었지만, 너무 복잡한 구조로 인해 현재는 SNMP에 밀려 사양길에 접어들었다.
SNMP 관리체제의 구조
SNMP에 의한 관리 구조는 에이전트와 매니저로 되어 있다. 여기서 MIB(Management Information Base)란 네트워크 요소들이 유지하는 정보를 말하는 것으로 에이전트들은 네트워크 노드에서 그 노드에 대한 정보를 유지하고 있다. 매니저는 전체 네트워크에 대한 MIB 명세서를 가지고 각각의 에이전트가 관리하는 MIB를 수집해서 관리한다.
SNMP 관리 프로토콜의 구조
SNMP는 TCP/IP 스택 중에 응용프로그램 계층(Application Layer)에 해당되는 프로토콜로 전송 계층에서는 UDP를 사용하며 161, 162 두 개의 포트를 통해 메시지를 주고받는다.
SNMP 메시지 종류
에이전트와 매니저 사이에 전달되는 정보의 완성된 형태를 메시지라고 한다. 매니저가 에이전트에 질의를 하면 에이전트는 그림 3과 같이 이에 대한 응답을 되돌리는 형식으로 정보를 주고받는데, 이를 위해 총 다섯 개의 메시지 종류를 정의하고 있다.
SNMP MIB
SNMP에서 사용되는 MIB들은 계층별로 전송속도, 오류율, 송수신 프레임 수, IP 주소 등의 관리대상 항목들을 유지하고 있다.
리스트 1: RFC1155-SMI DEFINITIONS
---------------------------------------------------------------
RFC1155-SMI DEFINITIONS ::= BEGIN
EXPORTS -- EVERYTHING
internet, directory, mgmt,
experimental, private,
enterprises, OBJECT-TYPE,
ObjectName, ObjectSyntax,
SimpleSyntax,
ApplicationSyntax,
NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks,
Opaque;
-- the path to the root
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
---------------------------------------------------------------
SMI(RFC1155)
SMI는 SNMP MIB들을 정의하기 위한 일반적인 구조이다. MIB 객체들은 ASN.1 문법에 따라 정의되는데 각각의 객체들은 각각 이름과 표기 문법, 다른 시스템으로의 전송을 위한 인코딩 규칙 등을 가지고 있다.
이들은 서로 고유한 객체 식별자에 의해 구분된다. SNMP MIB에서 사용되는 객체들은 RFC1155에 ISO의 표준안에 따라 정의되어 있다. 참고로 리스트 1에서 EXPO RT는 SMI에서 정의한 디렉토리와 여러 가지 데이터형(type)을 다른 SNMP MIB에서 가져다 사용할 수 있도록 개방시켜주는 역할을 한다. 다른 MIB에서는 SMI에서 EXPORTS로 열린 데이터형을 IMPORTS 구문을 통해 가져와 사용할 수 있다.
OBJECT IDENTIFIER
O-ID(OBJECT IDENTIFIER)는 MIB 내에서 관리 객체를 유일하게 지정하는 식별자로 객체가 구성하는 트리(tree)에 따라 할당되는 일종의 디렉토리다.
O-ID는 계층 구조이므로 항상 자신의 이름과 번호를 가지고 있으며 자신의 부모를 가지고 있다. O-ID는 가장 상위 계층부터 dotted decimal(.)을 사용해 표현하는데 다음의 예와 같이 숫자나 이름을 모두 사용할 수 있다.
mgmt의 경우
mgmt : iso.org.dod.internet.mgmt
mgmt : 1.3.6.1.2
RFC1155에서 정의한 O-ID를 살펴보면 최상위인 root에 iso가 있으며, 그 하위로 org(Organization)와 dod(Depart ment of Defense) 밑에 internet을 정의하고 있다. intern et 하위의 노드들은 표 3과 같다.
리스트 2 : 데이터형
---------------------------------------------------------------
ApplicationSyntax ::=
CHOICE {
address NetworkAddress,
counter Counter,
gauge Gauge,
ticks TimeTicks,
arbitrary Opaque
-- other application-wide types,
as they are
-- defined, will be added here
}
-- application-wide types
NetworkAddress ::=
CHOICE {
internet IpAddress
}
IpAddress ::= [APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
Counter ::= [APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
Gauge ::= [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
TimeTicks ::= [APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value,
IMPLICIT OCTET STRING --
"double-wrapped"
---------------------------------------------------------------
데이터형(type)
RFC1155에서는 O-ID와 함께 MIB의 객체를 정의하기 위한 여러 가지 데이터형들을 정의하고 있다(리스트 2). 여러 형태들은 CHOICE를 통해 한가지로 사용된다. 데이터형의 종류는 표 4와 같다.
Concise MIB(RFC1212)
SMI마다 구조가 다른 가장 큰 이유는 MACRO형의 구조가 각각 다르기 때문이다. 보통 데이터형과 값을 묶어서 MACRO형을 만들기 때문에 SNMP에서 관리하는 실제 객체의 구조는 대부분 MACRO형으로 정의한다. RFC-1212에서는 SNMP에서 사용하는 객체의 구조인 ‘OBJECT-TYPE’에 관해 정의하고 있다(리스트 3). OBJECT-TYPE은 MIB에서 관리하는 객체의 구조로 크게 문법(SYNTAX), 사용권한(ACCESS), 상태(STATUS), 값(VALUE) 등으로 이루어진다(표 5). STATUS에 따른 옵션 사항은 표 6과 같다.
리스트 3 : OBJECT-TYPE
---------------------------------------------------------------
IMPORTS
ObjectName FROM RFC1155-SMI
DisplayString FROM RFC1158-MIB;
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= -- must conform to
RFC1155’s ObjectSyntax
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE
ObjectName)
Access ::= "read-only" | "read-
write" | "write-only" | "not-
accessible"
Status ::= "mandatory" |
"optional" | "obsolete" |
"deprecated"
DescrPart ::= "DESCRIPTION"
value (description
DisplayString) | empty
ReferPart ::= "REFERENCE"
value (reference Display
String) | empty
IndexPart ::= "INDEX"
"{" IndexTypes "}" | empty
IndexTypes ::= IndexType |
IndexTypes "," IndexType
IndexType ::= value
(indexobject ObjectName) |
type (indextype)
-- if indexobject, use
the SYNTAX
-- value of the
correspondent
-- OBJECT-TYPE invocation
-- otherwise use named
SMI type
-- must conform to Index
Syntax below
DefValPart ::= "DEFVAL"
"{" value (defvalue
ObjectSyntax) "}" | empty
END
---------------------------------------------------------------
MIB-II(RFC1213)
MIB-II는 SNMP 프로토콜이 만들어진 이후 첫 번째로 나온 MIB로 TCP/IP 프로토콜 상에서 관리되어야 하는 객체들에 관해 정의하고 있다. 현재는 여러 가지 MIB들이 나와있지만, 보통 네트워크 장비들이 SNMP를 지원한다고 써있으면 대부분 이 MIB-II에 정의된 객체를 관리한다고 봐도 무방할 정도로 가장 대중적으로 사용되는 MIB이다. MIB의 기본 구조는 리스트 4와 같다. 리스트 4에서는 먼저 IMPORTS 구문을 통해 RFC1155에 정의된 mgmt O-ID와 여러가지 데이터형을 가져오고 RFC-1212에서 OBJECT-TYPE 매크로를 가져온다.
새롭게 OCTET STRING형을 기초로 DisplayString과 PhysAddress형이 추가 되었으며 ‘mib-2’O-ID가 mgmt 밑에 정의되었다(리스트 5).
MIB-II에서 정의된 모든 객체는 mib-2 밑에 위치하는데 전부 10개의 그룹이 정의되어 있다. 각 그룹이 하는 역할은 표 7과 같다. 각 그룹들은 다시 그룹 특성에 맞는 객체로 나뉘어진다. 각각의 객체는 RFC-1212에 정의되어 있는‘OBJECT-TYPE’형으로 구성되며, 에이전트에 의해 인스턴스화되면 실제 값을 가지게 된다. 이를 가리켜 ‘leaf no de’로 부르기도 한다.
여러 가지 그룹 중에서 system 그룹에 대해서 살펴보면, 이는 관리하는 시스템의 일반적인 정보를 제공하는 그룹으로서, system 그룹에서 관리하는 정보는 다음 그림 5와 같이 일곱 개의 객체에 나뉘어져 있다. system 그룹의 객체들이 하는 역할은 표 8과 같다.
system 그룹에 속한 객체중 하나인 ‘sysDescr’객체에 관해 MIB-II 에서 정의한 예를 살펴보면 리스트 6과 같다. ‘sysDescr’이 에이전트에 의해 인스턴스화되었을 때 가지는 값의 예를 살펴보자.
SNMP MIB 브라우저를 사용하여 system 그룹의 ‘sys Descr’을 선택하면 우측 상단의 객체설명 창에 ‘sysDescr’에 대한 정의 내용을 볼 수 있고, SNMP 에이전트의 IP 주소를 질의를 보내면 실제 되돌아오는 값을 우측 하단 창을 통해 확인할 수 있다(그림 6).
리스트 4 : MIB 기본 구조
---------------------------------------------------------------
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress,
Counter, Gauge,TimeTicks FROM
RFC1155-SMI
OBJECT-TYPE FROM RFC-1212;
mib-2 OBJECT IDENTIFIER ::=
{ mgmt 1 } -- MIB-II (same prefix as MIB-I)
-- textual conventions
DisplayString ::= OCTET STRING
-- This data type is used to model
textual information taken from the NVT
ASCII
-- character set.
PhysAddress ::= OCTET STRING
-- This data type is used to model media
addresses.
-- For example, an ethernet address
would be represented as a string of 6
octets.
---------------------------------------------------------------
리스트 5 : mib-2 O-ID
---------------------------------------------------------------
system OBJECT IDENTIFIER ::= { mib-2 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::
= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
---------------------------------------------------------------
SNMP 메시지 형식
SNMP 메시지 형식은 인코딩 되어 네트워크를 통해 전송될 때의 패킷 형태이다.
메시지 전체의 구조(RFC1157)
SNMP 메시지의 전체적인 구조는 리스트 7과 같이 RFC1157에 정의되어 있다. 메시지는 version, community, data의 세 가지 요소를 SEQUENCE로 묶은 형태를 취하고 있다. 여기서 version은 SNMP의 버전을 의미하며, community는 매니저와 에이전트간의 메시지 인증 방법을, data는 실제 알맹이 데이터를 의미한다.
SNMP의 보안 방법
여러 가지 정보를 안전하게 관리하기 위해서는 컴퓨터 시스템과 네트워크에 보안이 보장되어야 한다. SNMP는 인증과 접근 방침을 정하는 낮은 단계의 보안을 제공한다(이 부분은 SNMPv3에서 크게 향상되었다).
● community
인증, 접근 방침, proxy의 특성을 정의하는 하나의 에이전트와 여러 매니저 사이의 관계이며 각 에이전트를 기준으로 정의된다. 한 에이전트는 여러 community를 가질 수 있으나 각각의 이름은 그 에이전트 내에서 유일하며 다른 에이전트가 같은 이름의 community를 가질 수는 있다. 또한 community의 이름은 패스워드의 역할을 하므로 매니저로부터의 모든 메시지는 이 이름을 포함해야 한다. 그림 7은 에이전트가 GET과 SET 동작에 대해 서로 다른 community를 가지고 있는 예이다. 관례적으로 모두에게 공개하는 MIB 객체나, 동작에 대해서는‘public’community를 사용하고, SET과 같은 쓰기 동작이나 private한 MIB에 대해서 비밀의 comunity를 적용하는 것이 일반적이다.
● access policy
각각의 community마다 MIB에 대한 각각 다른 형태의 권한으로 접근을 제어한다. 이러한 접근 제어의 방법은 SNMP MIB에 의한 관점(관리 객체들의 집합으로 각 community마다 다른 SNMP MIB 관점을 가질 수 있음)에 의한 방법과 SNMP 접근 모드(각 community에 대한 접근 모드로 READ-ONLY나 READ-WRITE 중 한 값을 취할 수 있음)에 의한 방법으로 나뉠 수 있으며 이 둘에 대한 비교는 표 9와 같다.
● proxy 서비스
proxy는 SNMP나 TCP/IP를 지원하지 않는 관리 대상을 위한 에이전트를 말하는 것으로 proxy는 자신이 대신하는 관리 대상에 대한 SNMP 접근 방침이나 인증 서비스를 제공하기도 한다.
PDU(Protocol Data Unit)의 구성
SNMP 메시지의 알맹이라 할 수 있는 PDU는 리스트 8과 같이 CHOICE를 사용하여 다섯 개의 메시지 종류 중에 하나를 선택하도록 되어 있다. 하나의 PDU는 리스트 9와 같이 객체의 O-ID와 value를 SEQUENCE로 묶은 형태로 되어 있다. 이를 하나로 묶어서 전체의 SNMP 메시지를 살펴보면 그림 8과 같다. 참고로 PDU의 필드 내용은 표 10과 같다. 프로토콜 분석기를 사용하여 실제 SNMP 패킷을 잡아보면 그림 9와 같다(IP 주소 203.253.145.59의 매니저에
서 203.253.145.5의 에이전트로 request와 response를 받은 경우). 여기서 variable-binding을 자세히 살펴보면 이 메시지의 O-ID는 1.3.6.1.2.1.1 임을 알 수 있다. 이는 sysDescr의 O-ID이며 request이기 때문에 value 영역엔 NULL이 삽입되었다.
리스트 6 : sysDescr
---------------------------------------------------------------
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity.
This value should include the full
name and version
identification of the system’s hardware
type, software operating-system, and
networking software. It is mandatory
that this only contain printable ASCII
characters."
::= { system 1 }
---------------------------------------------------------------
Trap 메시지
트랩은 특별한 이벤트나 사고가 발생했을 경우 에이전트가 자의적으로 판단하여 매니저에게 알리는 메시지이다. 트랩 PDU는 enterprise, agent-addr 등 여러 구성 요소들이 SEQUENCE로 합쳐진 형태이다. 각 항목의 내용은 표 11과 같다. 그리고 일반적인 트랩의 종류는 표 12와 같다. 실제 발생한 트랩의 예를 살펴보자. 그림 10은 ‘e-watch’내의 있는 트랩 매니저를 사용하여 IP 주소 203.253.145.68의 SNMP 에이전트에서 Specific형의 트랩 메시지를 발생시킨 경우다. specific형은 viriable binding 부분에 특정한 O-ID가 따라옴을 알 수 있다.
리스트 7 : SNMP 메시지 구조
---------------------------------------------------------------
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, Network
Address, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::= SEQUENCE {
version INTEGER { version-1(0)
}, -- version-1 for this RFC
community OCTET STRING,
-- community name
data -- e.g., PDUs if trivial
ANY -- authentication
is being used
}
---------------------------------------------------------------
참고
그림 6에서 예로든 MIB 브라우저 화면은 프로토콜 분석기인 ‘e-watch’내에 포함되어 있는 SNMP MIB 브라우저를 사용한 것으로 http://ewatch.hangkong.ac.kr에서 ‘e-watch’를 다운받을 수 있다. 다른 그룹의 내용들도 system 그룹과 같은 형식을 취하므로 직접 MIB 브라우저를 사용하여 각각의 내용을 확인하기 바란다.
마치며
이번 호에는 SNMP의 관리 방식과, MIB, 메시지 형태, 윈도우 98에서의 응용 등을 살펴보았다. 다음 호에는 리눅스와 윈도우NT 등의 멀티유저 운영체계에서의 SNMP 활용 방법을 살펴보겠다.
리스트 8 : PDU
---------------------------------------------------------------
PDUs ::= CHOICE {
get-request GetRequest-PDU,
get-next-request GetNextRequest-PDU,
get-response GetResponse-PDU,
set-request SetRequest-PDU,
trap Trap-PDU
}
---------------------------------------------------------------
리스트 9 : PDU
---------------------------------------------------------------
PDU ::= SEQUENCE {
request-id INTEGER,
error-status
INTEGER { noError(0), tooBig(1),
noSuchName(2), badValue(3), readOnly(4),
genErr(5) },
error-index INTEGER,
variable-bindings VarBindList
}
VarBind ::= SEQUENCE {
name ObjectName,
value ObjectSyntax
}
VarBindList ::= SEQUENCE OF
VarBind
---------------------------------------------------------------
리스트 10 : Trap 메시지
---------------------------------------------------------------
Trap-PDU ::= IMPLICIT SEQUENCE {
enterprise OBJECT IDENTIFIER,
-- type of object generating
-- trap, see sysObjectID in [5]
agent-addr NetworkAddress,
-- address of object generating trap
generic-trap INTEGER { coldStart(0),
warmStart(1), linkDown(2), linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
}, -- generic trap type
specific-trap INTEGER,
-- if generic-trap is not
enterpriseSpecific
time-stamp TimeTicks,
-- time elapsed between the last
(re)initialization of the network entity and
-- the generation of the trap
variable-bindings VarBindList -
- "interesting" information
}
---------------------------------------------------------------
윈도우 98에서 SNMP 활용
보통 에이전트와 매니저 툴은 관리하려는 장치의 특성에 맞게 제작되기 때문에 고가이며 접하기도 힘들다. 윈도우 98에는 고급화된 기능의 SNMP는 지원하지 않지만 RFC 1213 MIB-II를 지원하는 에이전트를 기본적으로 제공하므로 SNMP MIB 브라우저와 이 에이전트를 이용하면 기본적인 SNMP 모델을 구현할 수 있다. 또한 프로토콜 분석기를 사용하여 SNMP 메시지 사례별로 패킷을 검사해보면 더 큰 SNMP 모델의 구현도 쉽게 할 수 있을 것이다. 윈도우98의 SNMP 에이전트를 사용하는 방법은 다음과 같다.
① 제어판의 네트워크 항목에서 ‘서비스 추가’를 선택하고 윈도우98 CD를 삽입한다(그림 11).
② 서비스화면에 SNMP 서비스가 나오지 않으면 ‘디스크 있음’을 선택한다.
③ 윈도우98 정품 CD의 ‘tools\reskit\netadmin\snmp’ 디렉토리를 살펴보면 SNMP 에이전트 프로그램을 추가할 수 있다(그림 12).
노정민 한국항공대학교 항공통신정보공학과 대학
hmask@esc.cl.hangkong.ac.kr
인터넷의 관리체제는 IETF(Internet Engineering Task Force)에 의해 이루어지고 있다. 여기서는 네트워크 관리를 위한 관리 구조, 관리 정보의 구조, 관리 프로토콜 등에 대한 표준화 작업을 한다. 현재 널리 사용되고 있는 SNMP도 IETF에 의해서 제정된 인터넷 관리 프로토콜이다.
SNMP에 의한 인터넷 관리체제의 발전
SNMP는 1988년 초안(draft)으로 상정되어 1990년 인터넷 관리 프로토콜의 표준으로 제정되었다.
그 후 대부분의 워크스테이션과 브리지, 라우터, 스위치, 허브 등의 네트워크 장비에 SNMP 에이전트가 장착되었고, 시스템과 여러 응용 프로그램에도 이들을 SNMP 상에서 관리할 수 있도록 하는 MIB들이 정의되었다.
현재의 SNMP는 SNMPv2 등을 거쳐 SNMPv3로 기능이 확장되고 있으며, 관리 영역도 RMON(Remote MONi toring) MIB 등을 통해 확장되고 있는 추세이다.
인터넷 관리체제의 기원
● ICMP(Internet Control Message Protocol)
1970년대 말부터 사용된 프로토콜로 네트워크 상에서의 여러 가지 문제점들에 대한 피드백(feed-back)을 제공하기 위해 사용되었다. 라우터나 호스트들 사이에 제어 메시지(echo/echo-reply)를 전달한다. 현재 ping, traceroute 등을 통해 널리 사용되고 있다.
● SGMP(Simple Gateway Monitoring Protocol)
게이트웨이를 모니터링하기 위해 사용되었던 프로토콜로 1987년 채택되었다.
● HEMS(High-Level Entity Management System)
호스트를 모니터링 하는데 사용했던 HMP(Host Monitoring Protocol)를 네트워크 관리에 맞게 발 전시킨 프로토콜이다.
● SNMP(Simple Network Management Protocol)
SGMP를 발전시킨 모델로 주로 TCP/IP 네트워크를 관리하는데 사용되는 단순한 형태의 프로토콜이다. 처음엔 가장 광범위한 네트워크 관리체제인 OSI 관리체제(CMOT)로 가기 위한 중간 단계의 과도기적 운영 방안으로 제안되었지만, 현재 가장 널리 사용되고 있다.
● CMOT(CMIP over TCP/IP)
OSI 관리체제인 CMIP를 TCP/IP 위에서 동작하도록 만든 것. SNMP를 대체할 목적으로 제안되었지만, 너무 복잡한 구조로 인해 현재는 SNMP에 밀려 사양길에 접어들었다.
SNMP 관리체제의 구조
SNMP에 의한 관리 구조는 에이전트와 매니저로 되어 있다. 여기서 MIB(Management Information Base)란 네트워크 요소들이 유지하는 정보를 말하는 것으로 에이전트들은 네트워크 노드에서 그 노드에 대한 정보를 유지하고 있다. 매니저는 전체 네트워크에 대한 MIB 명세서를 가지고 각각의 에이전트가 관리하는 MIB를 수집해서 관리한다.
SNMP 관리 프로토콜의 구조
SNMP는 TCP/IP 스택 중에 응용프로그램 계층(Application Layer)에 해당되는 프로토콜로 전송 계층에서는 UDP를 사용하며 161, 162 두 개의 포트를 통해 메시지를 주고받는다.
SNMP 메시지 종류
에이전트와 매니저 사이에 전달되는 정보의 완성된 형태를 메시지라고 한다. 매니저가 에이전트에 질의를 하면 에이전트는 그림 3과 같이 이에 대한 응답을 되돌리는 형식으로 정보를 주고받는데, 이를 위해 총 다섯 개의 메시지 종류를 정의하고 있다.
SNMP MIB
SNMP에서 사용되는 MIB들은 계층별로 전송속도, 오류율, 송수신 프레임 수, IP 주소 등의 관리대상 항목들을 유지하고 있다.
리스트 1: RFC1155-SMI DEFINITIONS
---------------------------------------------------------------
RFC1155-SMI DEFINITIONS ::= BEGIN
EXPORTS -- EVERYTHING
internet, directory, mgmt,
experimental, private,
enterprises, OBJECT-TYPE,
ObjectName, ObjectSyntax,
SimpleSyntax,
ApplicationSyntax,
NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks,
Opaque;
-- the path to the root
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
---------------------------------------------------------------
SMI(RFC1155)
SMI는 SNMP MIB들을 정의하기 위한 일반적인 구조이다. MIB 객체들은 ASN.1 문법에 따라 정의되는데 각각의 객체들은 각각 이름과 표기 문법, 다른 시스템으로의 전송을 위한 인코딩 규칙 등을 가지고 있다.
이들은 서로 고유한 객체 식별자에 의해 구분된다. SNMP MIB에서 사용되는 객체들은 RFC1155에 ISO의 표준안에 따라 정의되어 있다. 참고로 리스트 1에서 EXPO RT는 SMI에서 정의한 디렉토리와 여러 가지 데이터형(type)을 다른 SNMP MIB에서 가져다 사용할 수 있도록 개방시켜주는 역할을 한다. 다른 MIB에서는 SMI에서 EXPORTS로 열린 데이터형을 IMPORTS 구문을 통해 가져와 사용할 수 있다.
OBJECT IDENTIFIER
O-ID(OBJECT IDENTIFIER)는 MIB 내에서 관리 객체를 유일하게 지정하는 식별자로 객체가 구성하는 트리(tree)에 따라 할당되는 일종의 디렉토리다.
O-ID는 계층 구조이므로 항상 자신의 이름과 번호를 가지고 있으며 자신의 부모를 가지고 있다. O-ID는 가장 상위 계층부터 dotted decimal(.)을 사용해 표현하는데 다음의 예와 같이 숫자나 이름을 모두 사용할 수 있다.
mgmt의 경우
mgmt : iso.org.dod.internet.mgmt
mgmt : 1.3.6.1.2
RFC1155에서 정의한 O-ID를 살펴보면 최상위인 root에 iso가 있으며, 그 하위로 org(Organization)와 dod(Depart ment of Defense) 밑에 internet을 정의하고 있다. intern et 하위의 노드들은 표 3과 같다.
리스트 2 : 데이터형
---------------------------------------------------------------
ApplicationSyntax ::=
CHOICE {
address NetworkAddress,
counter Counter,
gauge Gauge,
ticks TimeTicks,
arbitrary Opaque
-- other application-wide types,
as they are
-- defined, will be added here
}
-- application-wide types
NetworkAddress ::=
CHOICE {
internet IpAddress
}
IpAddress ::= [APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
Counter ::= [APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
Gauge ::= [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
TimeTicks ::= [APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value,
IMPLICIT OCTET STRING --
"double-wrapped"
---------------------------------------------------------------
데이터형(type)
RFC1155에서는 O-ID와 함께 MIB의 객체를 정의하기 위한 여러 가지 데이터형들을 정의하고 있다(리스트 2). 여러 형태들은 CHOICE를 통해 한가지로 사용된다. 데이터형의 종류는 표 4와 같다.
Concise MIB(RFC1212)
SMI마다 구조가 다른 가장 큰 이유는 MACRO형의 구조가 각각 다르기 때문이다. 보통 데이터형과 값을 묶어서 MACRO형을 만들기 때문에 SNMP에서 관리하는 실제 객체의 구조는 대부분 MACRO형으로 정의한다. RFC-1212에서는 SNMP에서 사용하는 객체의 구조인 ‘OBJECT-TYPE’에 관해 정의하고 있다(리스트 3). OBJECT-TYPE은 MIB에서 관리하는 객체의 구조로 크게 문법(SYNTAX), 사용권한(ACCESS), 상태(STATUS), 값(VALUE) 등으로 이루어진다(표 5). STATUS에 따른 옵션 사항은 표 6과 같다.
리스트 3 : OBJECT-TYPE
---------------------------------------------------------------
IMPORTS
ObjectName FROM RFC1155-SMI
DisplayString FROM RFC1158-MIB;
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= -- must conform to
RFC1155’s ObjectSyntax
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE
ObjectName)
Access ::= "read-only" | "read-
write" | "write-only" | "not-
accessible"
Status ::= "mandatory" |
"optional" | "obsolete" |
"deprecated"
DescrPart ::= "DESCRIPTION"
value (description
DisplayString) | empty
ReferPart ::= "REFERENCE"
value (reference Display
String) | empty
IndexPart ::= "INDEX"
"{" IndexTypes "}" | empty
IndexTypes ::= IndexType |
IndexTypes "," IndexType
IndexType ::= value
(indexobject ObjectName) |
type (indextype)
-- if indexobject, use
the SYNTAX
-- value of the
correspondent
-- OBJECT-TYPE invocation
-- otherwise use named
SMI type
-- must conform to Index
Syntax below
DefValPart ::= "DEFVAL"
"{" value (defvalue
ObjectSyntax) "}" | empty
END
---------------------------------------------------------------
MIB-II(RFC1213)
MIB-II는 SNMP 프로토콜이 만들어진 이후 첫 번째로 나온 MIB로 TCP/IP 프로토콜 상에서 관리되어야 하는 객체들에 관해 정의하고 있다. 현재는 여러 가지 MIB들이 나와있지만, 보통 네트워크 장비들이 SNMP를 지원한다고 써있으면 대부분 이 MIB-II에 정의된 객체를 관리한다고 봐도 무방할 정도로 가장 대중적으로 사용되는 MIB이다. MIB의 기본 구조는 리스트 4와 같다. 리스트 4에서는 먼저 IMPORTS 구문을 통해 RFC1155에 정의된 mgmt O-ID와 여러가지 데이터형을 가져오고 RFC-1212에서 OBJECT-TYPE 매크로를 가져온다.
새롭게 OCTET STRING형을 기초로 DisplayString과 PhysAddress형이 추가 되었으며 ‘mib-2’O-ID가 mgmt 밑에 정의되었다(리스트 5).
MIB-II에서 정의된 모든 객체는 mib-2 밑에 위치하는데 전부 10개의 그룹이 정의되어 있다. 각 그룹이 하는 역할은 표 7과 같다. 각 그룹들은 다시 그룹 특성에 맞는 객체로 나뉘어진다. 각각의 객체는 RFC-1212에 정의되어 있는‘OBJECT-TYPE’형으로 구성되며, 에이전트에 의해 인스턴스화되면 실제 값을 가지게 된다. 이를 가리켜 ‘leaf no de’로 부르기도 한다.
여러 가지 그룹 중에서 system 그룹에 대해서 살펴보면, 이는 관리하는 시스템의 일반적인 정보를 제공하는 그룹으로서, system 그룹에서 관리하는 정보는 다음 그림 5와 같이 일곱 개의 객체에 나뉘어져 있다. system 그룹의 객체들이 하는 역할은 표 8과 같다.
system 그룹에 속한 객체중 하나인 ‘sysDescr’객체에 관해 MIB-II 에서 정의한 예를 살펴보면 리스트 6과 같다. ‘sysDescr’이 에이전트에 의해 인스턴스화되었을 때 가지는 값의 예를 살펴보자.
SNMP MIB 브라우저를 사용하여 system 그룹의 ‘sys Descr’을 선택하면 우측 상단의 객체설명 창에 ‘sysDescr’에 대한 정의 내용을 볼 수 있고, SNMP 에이전트의 IP 주소를 질의를 보내면 실제 되돌아오는 값을 우측 하단 창을 통해 확인할 수 있다(그림 6).
리스트 4 : MIB 기본 구조
---------------------------------------------------------------
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress,
Counter, Gauge,TimeTicks FROM
RFC1155-SMI
OBJECT-TYPE FROM RFC-1212;
mib-2 OBJECT IDENTIFIER ::=
{ mgmt 1 } -- MIB-II (same prefix as MIB-I)
-- textual conventions
DisplayString ::= OCTET STRING
-- This data type is used to model
textual information taken from the NVT
ASCII
-- character set.
PhysAddress ::= OCTET STRING
-- This data type is used to model media
addresses.
-- For example, an ethernet address
would be represented as a string of 6
octets.
---------------------------------------------------------------
리스트 5 : mib-2 O-ID
---------------------------------------------------------------
system OBJECT IDENTIFIER ::= { mib-2 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::
= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
---------------------------------------------------------------
SNMP 메시지 형식
SNMP 메시지 형식은 인코딩 되어 네트워크를 통해 전송될 때의 패킷 형태이다.
메시지 전체의 구조(RFC1157)
SNMP 메시지의 전체적인 구조는 리스트 7과 같이 RFC1157에 정의되어 있다. 메시지는 version, community, data의 세 가지 요소를 SEQUENCE로 묶은 형태를 취하고 있다. 여기서 version은 SNMP의 버전을 의미하며, community는 매니저와 에이전트간의 메시지 인증 방법을, data는 실제 알맹이 데이터를 의미한다.
SNMP의 보안 방법
여러 가지 정보를 안전하게 관리하기 위해서는 컴퓨터 시스템과 네트워크에 보안이 보장되어야 한다. SNMP는 인증과 접근 방침을 정하는 낮은 단계의 보안을 제공한다(이 부분은 SNMPv3에서 크게 향상되었다).
● community
인증, 접근 방침, proxy의 특성을 정의하는 하나의 에이전트와 여러 매니저 사이의 관계이며 각 에이전트를 기준으로 정의된다. 한 에이전트는 여러 community를 가질 수 있으나 각각의 이름은 그 에이전트 내에서 유일하며 다른 에이전트가 같은 이름의 community를 가질 수는 있다. 또한 community의 이름은 패스워드의 역할을 하므로 매니저로부터의 모든 메시지는 이 이름을 포함해야 한다. 그림 7은 에이전트가 GET과 SET 동작에 대해 서로 다른 community를 가지고 있는 예이다. 관례적으로 모두에게 공개하는 MIB 객체나, 동작에 대해서는‘public’community를 사용하고, SET과 같은 쓰기 동작이나 private한 MIB에 대해서 비밀의 comunity를 적용하는 것이 일반적이다.
● access policy
각각의 community마다 MIB에 대한 각각 다른 형태의 권한으로 접근을 제어한다. 이러한 접근 제어의 방법은 SNMP MIB에 의한 관점(관리 객체들의 집합으로 각 community마다 다른 SNMP MIB 관점을 가질 수 있음)에 의한 방법과 SNMP 접근 모드(각 community에 대한 접근 모드로 READ-ONLY나 READ-WRITE 중 한 값을 취할 수 있음)에 의한 방법으로 나뉠 수 있으며 이 둘에 대한 비교는 표 9와 같다.
● proxy 서비스
proxy는 SNMP나 TCP/IP를 지원하지 않는 관리 대상을 위한 에이전트를 말하는 것으로 proxy는 자신이 대신하는 관리 대상에 대한 SNMP 접근 방침이나 인증 서비스를 제공하기도 한다.
PDU(Protocol Data Unit)의 구성
SNMP 메시지의 알맹이라 할 수 있는 PDU는 리스트 8과 같이 CHOICE를 사용하여 다섯 개의 메시지 종류 중에 하나를 선택하도록 되어 있다. 하나의 PDU는 리스트 9와 같이 객체의 O-ID와 value를 SEQUENCE로 묶은 형태로 되어 있다. 이를 하나로 묶어서 전체의 SNMP 메시지를 살펴보면 그림 8과 같다. 참고로 PDU의 필드 내용은 표 10과 같다. 프로토콜 분석기를 사용하여 실제 SNMP 패킷을 잡아보면 그림 9와 같다(IP 주소 203.253.145.59의 매니저에
서 203.253.145.5의 에이전트로 request와 response를 받은 경우). 여기서 variable-binding을 자세히 살펴보면 이 메시지의 O-ID는 1.3.6.1.2.1.1 임을 알 수 있다. 이는 sysDescr의 O-ID이며 request이기 때문에 value 영역엔 NULL이 삽입되었다.
리스트 6 : sysDescr
---------------------------------------------------------------
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity.
This value should include the full
name and version
identification of the system’s hardware
type, software operating-system, and
networking software. It is mandatory
that this only contain printable ASCII
characters."
::= { system 1 }
---------------------------------------------------------------
Trap 메시지
트랩은 특별한 이벤트나 사고가 발생했을 경우 에이전트가 자의적으로 판단하여 매니저에게 알리는 메시지이다. 트랩 PDU는 enterprise, agent-addr 등 여러 구성 요소들이 SEQUENCE로 합쳐진 형태이다. 각 항목의 내용은 표 11과 같다. 그리고 일반적인 트랩의 종류는 표 12와 같다. 실제 발생한 트랩의 예를 살펴보자. 그림 10은 ‘e-watch’내의 있는 트랩 매니저를 사용하여 IP 주소 203.253.145.68의 SNMP 에이전트에서 Specific형의 트랩 메시지를 발생시킨 경우다. specific형은 viriable binding 부분에 특정한 O-ID가 따라옴을 알 수 있다.
리스트 7 : SNMP 메시지 구조
---------------------------------------------------------------
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, Network
Address, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::= SEQUENCE {
version INTEGER { version-1(0)
}, -- version-1 for this RFC
community OCTET STRING,
-- community name
data -- e.g., PDUs if trivial
ANY -- authentication
is being used
}
---------------------------------------------------------------
참고
그림 6에서 예로든 MIB 브라우저 화면은 프로토콜 분석기인 ‘e-watch’내에 포함되어 있는 SNMP MIB 브라우저를 사용한 것으로 http://ewatch.hangkong.ac.kr에서 ‘e-watch’를 다운받을 수 있다. 다른 그룹의 내용들도 system 그룹과 같은 형식을 취하므로 직접 MIB 브라우저를 사용하여 각각의 내용을 확인하기 바란다.
마치며
이번 호에는 SNMP의 관리 방식과, MIB, 메시지 형태, 윈도우 98에서의 응용 등을 살펴보았다. 다음 호에는 리눅스와 윈도우NT 등의 멀티유저 운영체계에서의 SNMP 활용 방법을 살펴보겠다.
리스트 8 : PDU
---------------------------------------------------------------
PDUs ::= CHOICE {
get-request GetRequest-PDU,
get-next-request GetNextRequest-PDU,
get-response GetResponse-PDU,
set-request SetRequest-PDU,
trap Trap-PDU
}
---------------------------------------------------------------
리스트 9 : PDU
---------------------------------------------------------------
PDU ::= SEQUENCE {
request-id INTEGER,
error-status
INTEGER { noError(0), tooBig(1),
noSuchName(2), badValue(3), readOnly(4),
genErr(5) },
error-index INTEGER,
variable-bindings VarBindList
}
VarBind ::= SEQUENCE {
name ObjectName,
value ObjectSyntax
}
VarBindList ::= SEQUENCE OF
VarBind
---------------------------------------------------------------
리스트 10 : Trap 메시지
---------------------------------------------------------------
Trap-PDU ::= IMPLICIT SEQUENCE {
enterprise OBJECT IDENTIFIER,
-- type of object generating
-- trap, see sysObjectID in [5]
agent-addr NetworkAddress,
-- address of object generating trap
generic-trap INTEGER { coldStart(0),
warmStart(1), linkDown(2), linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
}, -- generic trap type
specific-trap INTEGER,
-- if generic-trap is not
enterpriseSpecific
time-stamp TimeTicks,
-- time elapsed between the last
(re)initialization of the network entity and
-- the generation of the trap
variable-bindings VarBindList -
- "interesting" information
}
---------------------------------------------------------------
윈도우 98에서 SNMP 활용
보통 에이전트와 매니저 툴은 관리하려는 장치의 특성에 맞게 제작되기 때문에 고가이며 접하기도 힘들다. 윈도우 98에는 고급화된 기능의 SNMP는 지원하지 않지만 RFC 1213 MIB-II를 지원하는 에이전트를 기본적으로 제공하므로 SNMP MIB 브라우저와 이 에이전트를 이용하면 기본적인 SNMP 모델을 구현할 수 있다. 또한 프로토콜 분석기를 사용하여 SNMP 메시지 사례별로 패킷을 검사해보면 더 큰 SNMP 모델의 구현도 쉽게 할 수 있을 것이다. 윈도우98의 SNMP 에이전트를 사용하는 방법은 다음과 같다.
① 제어판의 네트워크 항목에서 ‘서비스 추가’를 선택하고 윈도우98 CD를 삽입한다(그림 11).
② 서비스화면에 SNMP 서비스가 나오지 않으면 ‘디스크 있음’을 선택한다.
③ 윈도우98 정품 CD의 ‘tools\reskit\netadmin\snmp’ 디렉토리를 살펴보면 SNMP 에이전트 프로그램을 추가할 수 있다(그림 12).