S N M P (Simple Network Management System) -정 진성-

CONTENTS MIB의 정의 MIB의 구조 MIB의 OID MIB OBJECT SNMP MESSAGE FORMAT SNMP기반의 TCP /IP 관리 프로토콜 SNMP의 기능 SNMP 메시지 타입의 종류 MIB의 정의 MIB의 구조 MIB의 OID MIB OBJECT SNMP MESSAGE FORMAT SNMP V1 / V2

SNMP의 정의 SNMP(Simple Network Management Protocol) - 단순 망 관리 프로토콜(한국어 사전적인 번역) - 네트워크 장비를 관리 감시하기 위한 목적으로 TCP/IP 상에 정의된 응용 계층 표준 프로토콜 SNMP는 네트워크 관리자가 네트워크 성능을 관리하고 네트워크 문제점을 찾아 수정하는데 도움을 준다. = 시스템이나 네트워크 관리자가 원격에서 네트워크 장비를 모니터링하고 환경 설정 등의 운영을 할 수 있게 도움을 준다. SNMP를 지원하는 서버에 관리자가 질의를 해 자료를 받아갈 수 있고, 반대로 어떤 값은 설정을 요청할 수도 있다. 현재 SNMP의 종류는 SNMP 버전 1, SNMP 버전 2, SNMP 버전 3의 세 가지 버전이 있다. 버전 3에서는 이전의 접속 주소와 커뮤니티 판별에 의존하던 인증방법 대신 계정과 암호로 인증하는 방식을 도입하였다.

SNMP의 활용 네트워크 구성관리(Network Configuration Management) 네트워크상의 호스트들이 어떤 구조를 이루고 있는지 지도를 그리는 게 가능하다. 성능관리 (Performance Management) 각 네트워크 세그먼트간 네트워크 사용량, 에러 량, 처리속도, 응답시간 등 성능 분석에 필요한 통계정보를 얻어낼 수 있다. 장비관리 (Fault Management) SNMP의 주목적이 네트워크관리 이기는 하지만 SNMP특유의 유연한 확장 성을 이용하여서 시스템정보(CPU, MEMORY, DISK 사용량)의 정보를 얻어올 수 있도록 많은 부분이 확장되었다. 이 정보는 네트워크문제를 해결하는데 큰도움을 준다. 예를 들어 특정 세그먼트의 네트워크 사용량이 갑자기 급증했는데, 특정 호스트의 CPU사용 율까지 갑자기 증가했다면, 우리는 해당 호스트에서 문제가 발생했을 것 이란 걸 유추해낼 수 있을 것이다. 보안관리 (Security Management) 정보의 제어 및 보호 기능, 최근 버전인 SNMP3는 특히 정보보호를 위한 기능이 향상되었다.

SNMP의 출연 배경 ● SNMP의 출현 배경 SNMP를 표준으로 채택 Ping을 통해 ICMP를 이용. 88년 초 IAB에서 표준화 작업 시작 기존 : 초기 네트워크 환경에서는 관리는 주로 PING과 같은 ICMP를 사용 이는 단순하게 상대방 HOST가 작동하고 있는 지에 대한 정보나 응답시간을 측정하는 등의 기능만을 제공 현재 : 폭발적인 네트워크의 구성이 복잡성으로 인한 새로운 네트워크의 프로토콜이 필요 이에 따라. 88년초 IAB(Internet Architecture Board)에서는 표준화 작업을 시작 이때까지 연구가 진행됐던 HEMS(Highlevel Entity Management System), SGMP(Simple Gateway Monitoring), CMIP/CMIS(Common Management Information Protocol/Service)중에서 SGMP를 발전시킨 SNMP로 채택 결국 IAB는 SNMP를 채택하면서 몇가지 결정을 내렸다. ① 기본적으로 관리 프로토콜로 SNMP를 채택 ② IAB와 업체들은 ISO CMIP/CMIS를 기반으로 한 망관리 시스템을 개발/발전시킨다. ③ SNMP와 관련된 작업은 IETF가 책임지고, 이전의 연구 작업결과를 적극 수용한다

SNMP기반의 TCP /IP 관리 프로토콜 TCP/IP 관리 구조는 네트워크 상에 관리 에이전트(SNMP agent)가 탑재되어 있고 중앙의 관리국(Management Station)이 이런 에이전트로부터 각 네트워크 장비의 관리 정보를 모니터링 함으로써 이루어진다. 이때 각 관리 에이전트와 관리국간의 네트워크 관리 정보를 전송하기 위해 사용되는 네트워크 관리 프로토콜이 SNMP이다 TCP/IP에서 사용되는 네트워크 관리 형태는 다음의 주요 요소가 있다. ▶ 관리국(Management Station) ▶ 관리 에이전트 (Managed Agent) ▶ 관리 정보 베이스(MIB : Management Information Base) ▶ 네트워크 관리 프로토콜(SNMP : Simple Network Management Protocol)

SNMP기반의 TCP /IP 관리 프로토콜

SNMP기반의 TCP /IP 관리 프로토콜 관리국(Management Station) 관리 에이전트(Managed Agent) 관리국이란 쉽게 말해서 우리가 일반적으로 NMS서버라 부르는 스테이션을 말한다. 관리국은 최소한 다음의 사항을 가지고 있어야 한다. Ⅰ. 데이터 분석, 에러복구 등의 관리 어플리케이션들의 집합 Ⅱ. 네트워크 관리자가 네트워크를 감시하고 조정할 수 있게 하는 인터페이스 Ⅲ. 네트워크 관리자의 요구 즉, 네트워크상의 대상 요소를 실제로 감시하고 조정할 수 있도록 바꾸어 줄 수 있는 기능 Ⅳ. 모든 네트워크상의 관리되어 질 수 있는 개체(Agent)들의 MIB으로부터 뽑아낸 데이터 베이스 정보 관리 에이전트(Managed Agent) 일반적으로 SNMP 에이전트라고도 부르며 호스트 컴퓨터나 브리지, 라우터, 허브와 같은 장비로 관리국에 의해서 관리되어 질 수 있는 장비 피관리 에이전트는 독자적으로 장비 자신의 트래픽을 모니터링하고 그 통계 정보를 자신의 MIB에 저장해두었다가 중앙의 관리국으로부터의 트래픽 정보 요구나 특정 동작 요청에 응답하고, 특정사건 발생시 관리국에 에이전트의 중요 정보를 제공한다.

SNMP기반의 TCP /IP 관리 프로토콜 관리 정보 베이스(Management Information Base) 네트워크 상의 트래픽 관리 정보를 관리하는 방법은 오브젝트로 정보를 관리하는 것이다. 각 정보를 하나의 오브젝트로 하여 오브젝트들의 계층적 구조로 트래픽 정보를 저장하고 검색할수 있도록 하는데, 이런 오브젝트들의 모임을 Management Information Base (MIB)라 한다 단순 네트워크 관리 프로토콜(SNMP) 관리국이 관리 에이전트의 트래픽 정보를 검색하고 그 MIB 설정을 바꿀수 있는 표준 프로토콜이 네트워크 관리 프로토콜 이다. 그 중 TCP/IP 네트워크의 관리용으로 쓰이는 프로토콜이 Simple Network Management Protocol (SNMP)이다. SNMP는 Network Management Station과 Agent라 불리는 Network 요소들 사이에 관리 정보(MIB) 를 교환하는 간단한 요청/응답 기능을 하는 Protocol 이다.

SNMP기반의 TCP /IP 관리 프로토콜 SNMP관리 모델 SNMP는 TCP/IP의 응용계층 프로토콜로 디자인되었고 전송 계층 프로토콜로는 UDP(User Datagram Protocol)를 사용한다.(. 포트 161) SNMP가 비접속 프로토콜(Connectionless Protocol)인 UDP를 사용하고 있기 때문에 SNMP 스스로도 비접속 프로토콜이다. 또한 SNMP는 네트워크장비 즉, 라우터나 브리지,서버, 호스트등의 Agent에 직접 Query하는 트랜젝션 지향 프로토콜(Transaction-Oriented Protocol)이다. Management Station의 관리 어플리케이션은 SNMP Agent의 MIB에 대한 접근과 객체를 관리하고, 네트워크 관리자(User)에 대한 인터페이스(GUI)를 제공. 각각의 Agent는 반드시 SNMP, UDP, IP를 반드시 구현. 게다가 Agent Process는 SNMP메시지를 해석 자기 자신의 MIB을 조정한다.

SNMP의 기능 크게 말해서 SNMP의 기능은 3가지 형태로 이루어져 있다. ① GET : SNMP Station이 Agent의 오브젝트 값을 검색할 수 있게 한다. ② SET : SNMP Station이 Agent의 오브젝트 값을 설정할 수 있게 한다. ③ TRAP : Agent가 SNMP Station에 중요한 사건을 알릴 수 있게 한다. SNMP Station의 관리 어플리케이션은 SNMP 관리자를 통해 3가지 형태의 SNMP메시지(GetRequest, GetNextRequest, SetRequest)를 생성하여 Agent로 전송. 그러면 Agent는 GetResponse 메시지로 SNMP Station에 응답을 하게된다. 또한 Agent는 자신의 MIB에 영향을 미치거나, 관리 자원에 발생할 수도 있는 사건(Event)을 알리기 위해 Trap 메시지를 만들어 SNMP Station에게 알린다.

SNMP 메시지 타입의 종류 ▶ SNMP PDU 타입 Get-Request Manager가 Agent에게 MIB관리 정보를 요청한다. Get-Next-Request Manager가 Agent에게 MIB관리 정보를 순차적으로 여러 개 가져올 것을 요청한다. Set-Request Manager가 Agent에게 MIB관리 정보의 값을 설정한다. Get-Response Agent가 Manager의 질의에 대한 응답을 보내준다. TRAP Agent에서 특별한 이벤트가 발생할 경우 Manager의 질의가 없어도 능동적으로 Manager에게 알려준다.

MIB (Management Information Base) Manager와 Agent사이에 특정한 정보를 주고 받는 것이 네트워크 관리의 기본이다. 관리 되어야 할 특정한 정보(Information), 자원(Resource)을 객체(Object)라 한다. 이런 객체들을 모아놓은 집합체를 MIB이라고 한다. MIB은 관리되는 네트워크 요소의 각 특성 객체들의 계층적이며 구조적인 집합을 의미한다. 네트워크를 관리한다는 것은 관리대상인 장비(Workstation, printer,server,hub,router…)들이 제공하는MIB중에서 특정값을 얻어와서 그 장비의 상태를 파악하거나, 그 값을 변경함을 의미

MIB의 구조 MIB를 정의하고 구성하는 뼈대(Framework)인 SMI는 RFC1155에 아래와 같은 사항을 정의하고 있다. (1) MIB의 각 객체(Object)들은 ISO와 ITU-T에 의해 표준화되고 개발된 언어인 ASN.1(Abstract Syntax Notation One)을 사용해서 정의한다. (2) 정의할 모든 객체는 반드시 이름, Syntax, 부호화(Encoding)을 갖고 있어야 한다. Ⅰ. 이름 : 해당 객체를 식별하는 객체 식별자 예)Object Identifier Ⅱ. Syntax : 객체의 데이터 종류 예) Interger, Octect String… Ⅲ. 부호화 : 객체의 데이터가 어떤 Encoding방식으로 전송되는가? MIB의 구조는 계층적 트리구조의 형태를 이루고 있다. 특정 객체는 객체 식별자(ObjectIdentifier = OID)에 의해서 구분된다. 실제로 OID는 우리가 일반적으로 사용하는 문자가 아니라 연속된 정수이다. MIB tree는 root를 기준으로 동일한 범주에 속하는 객체들을 분류하는 식으로 OID가 정해지고 snmp는 최종 노드인Object만을 읽고 쓸수가 있다.

MIB MIBBROWSER      트리 형식의 계층적 구조        Managed Object는 Object Identifier(OID)를 가짐         OID 표기법 A.        internet OBJECT IDENTIFIER := { iso(1) org(3) dod(6) 1 } B.        internet OBJECT IDENTIFIER := { 1 3 6 1 } C.       internet OBJECT IDENTIFIER := 1.3.6.1

MIB MIB구조는 루트를 기준으로 동일한 범주에 속하는 객체들을 분류하는 식으로 OID가 정해지고 SNMP는 최종 노드인 리프(leaf)만을 쓸 수가 있다. 모든 업체들을 구별하는 OID가 있어야 하는데 이는 IANA(Internet Assigned Number Authority)에서 관리하고 있다. 그러므로 자체 전사적인 MIB를 구현하기 위해서는 IANA에서 OID를 부여 받아야 한다. 그래야 그 하위 MIB의 객체의 우일성이 보장되고 그래야 다른 업체의 사설  MIB와 구별이 가능하다. IANA에 등록하면 (iana-mib@isi.edu) 곧 번호(OID)를 부여 받을 수 있다.

MIB의 확장 MIB-II 는 몇 개의 오브젝트와 몇 개의 그룹을 더한 MIB-Ⅰ의 확장판이다. Ⅲ. 특정 벤더/개인에 의한 확장은 Private 서브트리에 추가될 수 있다. * 기본 System, interfaces, at(주소변환), ip, icmp, tcp, udp등의 그룹 등으로 구성

MIB OBJECT MIB-II 오브젝트는 11개의 MIB Object Group으로 나뉜다. I. System Group : 시스템 그룹은 Agent에 대한 일반 정보를 제공한다 II. Interface Group : 인터페이스 그룹은 네트워크 시스템의 인터페이스에서 발생할 수 있는 트래픽 사건의 통계와 조직 정보를 포함하여, 개체의 물리적 인터페이스와 관련된 순수한 정보를 가지고 있다. III . Address-Translation Group : 주소 변환 그룹은 IP Address와 MAC Address간의 매핑 표로 구성된다 Ⅳ. IP Group : IP 그룹은 노드에서 IP의 구현과 수행에 관련된 정보를 포함한다 Ⅴ. ICMP(Internet Control Meassge Protocol) : ICMP 그룹은 노드에서 ICMP의 구현과 동작에 관련된 정보. 즉, ICMP 입출력 메시지중에서 Error, TimeExcds, Echos등의 정보 통계를 포함한다. 이 그룹은 오로지 주고 받는 ICMP 메시지의 다양한 형태를 측정한다.

MIB OBJECT Ⅵ. TCP ( Transmission Control Protocol ) : TCP그룹은 노드에서 TCP의 구현과 동작에 관련된 정보를 포함 TCP세션 정보가 계속 모니터링되어 저장된다 Ⅶ. UDP ( User Datagram Protocol ) : UDP 그룹은 노드에서 UDP의 구현과 동작에 관련된 정보 포함 게다가 주고 받은 데이터그램과 관련된 정보 즉, 입력 데이터그램의 수(udpDatagrams), 입력 에러 데이터그램(udpError)등과 같은 객체들이 있다. Ⅷ. EGP (External Gateway Protocol ) : EGP 그룹은 노드에서 EGP의 구현과 동작에 관련된 정보를 포함한다. Ⅸ. Transmission Group : 전송 그룹은 시스템의 각 인터페이스에 대해 전송 매체에 있을 수 있는 세부 사항을 제공하는 오브젝트를 포함하려는 의도로 만들어졌다. Ⅹ. SNMP Group : 원격의 관리 시스템(SNMP agent)으로의 접근을 위한 응용 프로토콜 그룹이다

SNMP기반의 통신 OSI 7 layer 상의 통과단계와 해당 요구,응답의 단계 관리 어플리케이션 Agent 자원 SNMP M/G

SNMP Message Format

SNMP Message Format

SNMP Message Format 버전(Version) :SNMP의 버전을 나타내는 버전 번호를 포함한다. IP헤더 UDP 헤더 버전(0) 공동체 PDU 타입(0-3) 요구 ID 에러상황(0-5) 에러인덱스 이름 값 버전(Version) :SNMP의 버전을 나타내는 버전 번호를 포함한다. Manager 와 Agent 간의 동일한 버전 정보를 가져야 한다. 공통체(COMMUNITY ):타 시스템간의 구분하는 이름 Manager와 Agent 간에는 서로 같은 공동체 명을 가지고 있어야 하며 이것은 최소한의 인증절차를 위한 암호 기능을 한다

SNMP Message Format PDU 유형 이름 설명 Get – request MIB관리 정보를 요청한다. 1 IP헤더 UDP 헤더 버전(0) 공동체 PDU 타입(0-3) 요구 ID 에러상황(0-5) 에러인덱스 이름 값 PDU 유형 이름 설명 Get – request MIB관리 정보를 요청한다. 1 Get – next-request 다음 MIB관리 정보를 요청한다. 2 Get – response MIB관리 정보의 값을 설정한다. 3 Set – request 질의에 대한 응답을 보내준다. 4 trap MIB 변경의 값을 능동적으로 보내준다. GetRequest : Management Station이 관리대상들의 리스트에 관한 속성값을 얻기위해 Agent에 요구. Agent는 그 요구에 대한 성공이나 실패를 나타내는 답을 보낸다. 즉.그 요구가 성공적 이라면 결과 메시지는 어떤 요구된 대상의 값을 포함하게 된다. GetNextRequest : GetRequest-PDU와 동작원리가 거의 동일한 교환형태를 지니며 같은 형식을 갖고있다. 유일한 차이점은 GetRequest-PDU는 주어진 오브젝트에 대한 값이 결과로 돌아오는 반면에 GetNextRequest-PDU는 주어진 오브젝트의 사전적 순서의 다음 오브젝트의 값이 돌아온다는 것이다. GetResponse : 이 PDU는 Management Station에 의해 요구된 MIB의 오브젝트의 속성값을 되돌려주기 위해 SNMP Agent에 의해 사용된다. SetRequest : Agent의 특정 MIB 오브젝트 값을 읽기보다는 쓰기를 위한 동작이다.그러므로 Variable Binding의 의 목록에 오브젝트명(OID)과 값의 형식, 쓰고자 하는 값을 모두 넣어줘야 한다. Trap: Trap은 Agent 자신에 의해서 발생한다. 즉, 특정 상황이 발생했음을 Management Station에게 알린다.

SNMP Message Format 요구 ID(Request –ID): A. get, set을 위한 것 IP헤더 UDP 헤더 버전(0) 공동체 PDU 타입(0-3) 요구 ID 에러상황(0-5) 에러인덱스 이름 값 에러상태 이름 설명 noError 모든것이 OK 1 tooBig 응답을 단일 SNMP 메시지에 맞 출수 없음 ※ tooBig의 max message size : 484octet (1octet = 8bit = 1byte) 2 noSuchName 존재하지 않은 변수의 지정 3 badValue 설정에서의 무효인 값 혹은 문맥의 지정 4 readOnly 관리자가 읽기만 가능한 값의 변경 5 genErr 그밖의 에러상황 요구 ID(Request –ID): A.        get, set을 위한 것 B.        여러 개의 agent에 multiple request가 가능 C.       Manager가 보낸 request ID가 response 메시지에 실려온 ID와 일치하는 확인

SNMP Message Format 에러인덱스(error index) IP헤더 UDP 헤더 버전(0) 공동체 PDU 타입(0-3) 요구 ID 에러상황(0-5) 에러인덱스 이름 값 에러인덱스(error index) 에러 발생시 variable bindings의 몇 번째 OID에서 오류가 발생한 것인지 나타냄 이름 / 값 ,변수 영역(variable bindings) A.        1~N개 까지의 OID가 이어질 수 있음 B.        OID와 OID Value로 한 세트 C.       길이 제한 있음 Trap PADDING PDU 유형(4) Enteterprise Agent Addr Trap Type(0~6) 이름 값 specific-trap Time stamp Enterprise 트랩을 발생시키는 객체 유형 Agent Addr 트랩을 발생 시키는 객체 주소(IP 주소) Specific-trap 더 세분하게 트렙의 내용을 나타내는 코드 = 구체 적인 트렙의 내용 RFC-1215에 따르면 일반적인 트랩의 경우에는 0로 설졍 되나 트렙에 타입에 따라 정의하는 부분은 설계가 되어 있지 않다고 함 Time stamp 초기화 시간으로 부터 현재 트랩이 발생한 시간을 나타냄

SNMP Message Format PDU 유형(4) Enteterprise Agent Addr Trap Type(0~6) 이름 값 specific-trap Time stamp 트랩 유형 이 름 설 명 1 2 3 4 5 6 coldStart warmStart linkDown linkUp authenticationFailure egpNeighborLoss enterpriseSpecific Agent가 자기 자신을 초기화 Agent가 자기 자신을 재 초기화 인터페이스가 가동상태에서 정지상태로 변화(구문 그대로 링크가 단절) 인터페이스가 가동상태에서 정지상태로 변화(구문 그대로 링크가 연결) SNMP 관리자로부터 무효인 공동체의 메시지를 받음 EGP 상대방이 정지상태로 변화 트랩의 정보에 관한 특정 코드 필드를 보는 것(밴더별 특정 코드값) 1. coldStart (0) : 송신하는 SNMP 개체는 에이전트의 구성이나 프로토콜 개체의 구현이 변경되어지는 경우에 스스로 재초기화할 수 있다. 전형적으로 이것은 충돌이나 주요 결함에 의한 예기치 않은 재시작이다. 2. warmStart (1) : 송신하는 SNMP 개체는 에이전트의 구성이나 프로토콜 개체의 구현이 변경되어지는 경우와 관 계 없이 스스로 재초기화 할 수 있다. 전형적으로 이것은 정해진 재시작이다. 3. linkDown (2) : 에이전트의 통신 링크 중 하나에 결함이 생겼음을 알린다. Variable binding의 처음은 참조하 고자 하는 인터페이스의 ifIndex의 이름과 값이다. 4. linkUp(3) : 에이전트의 통신 링크가 가동되었음을 알린다. Variable binding의 처음은 참조하고자 하는 인터 페이스의 ifIndex의 이름과 값이다. 5. authenticationFailure (4) : 송신하는 프로토콜 개체가 인증에 실패했다는 메시지를 받았음을 알린다. 6. egpNeighborLoss (5) : EGP 이웃이 사라졌거나 이웃 관계가 더 이상 존재하지 않을 때 이를 알린다. 7. enterpriseSpecific (6) : EnterpriseSpecific은 표준 Trap을 제외한 그밖의 상태를 알리고자하는데 사용된다

SNMP V1 / V2 WAN환경에서 SNMP의 한계점 I . 대역폭의 과다 소요로 많은 장비를 관리하기 어렵다. II . SNMP를 지원하는 네트워크 장비간의 트래픽을 모니터링할 때 해당 노드의 인터페이스에서 발생하지 않은 트래픽에 대해서는 인식하지 못할 수 도 있다. III . 여러 Agent들의 데이터를 처리하여 통계 정보를 분석할 경우 해당 Agent들로부터 필요한 모든 정보를 관리국이 수집해야 하므로 많은 트래픽이 관리국으로 집중, 관리국의 성능을 고려해야 한다. Ⅳ. SNMP Agent를 갖고 있는 네트워크 장비는 만일 그 장비가 본연의 임무를 수행하는 동안 Agent가 트래픽 정보를 분석하는 경우 그 자원의 왜곡이 있을 수 있으며, 충분한 성능을 확보하지 못할 때는 문제가 될 수 있다.

SNMP V1 / V2 SNMPv1의 문제점 및 SNMPv2의 생성배경 1)SNMPv1 의 문제점 I . 보안기능이 거의 없다. II . sysLocation 처럼 객체에 단 하나만의 값이 존재하는 경우는 문제가 없으나 RoutingTable처럼 많은 열(row)이 존재하는 경우에는 전체 테이블을 읽고 싶을 때 수많은 요청/응답을 반복해야 한다. III. 여러 관리자가 존재시에 관리자간의 통신기능이 정의 되어 있지 않다. 이러한 문제점을 수정하기 위해서 SNMPv2가 등장했다.

SNMP V1 / V2 SNMPv2 의 등장 I . 관리자와 관리자간의 통신을 위한 InformRequest-PDU가 정의되었고 이를 위한 Management To Management MIB를 정의. 관리자간의 통신이 가능해짐으로 분산관리의 도입이 가능해졌다. II . 커다란 테이블 객체들의 값을 손쉽게 읽어오기 위해서 GetBulkRequest-PDU를 도입했다. 이에 따라 한번의 요청으로 여러 테이블 값들을 읽어오는 것이 가능해졌고 불필요한 대역폭을 줄일수 있게되었다. III . 가장 큰 문제였던 보안 기능이 추가되었다. 전송되는 데이터 보안 기능을 위해서 DES(Data Encryption Standard) 알고리즘을 사용.인증 절차에 대한 보안을 위해서 MD5(Message Digest 5)알고리즘을 사용.party mib을 이용해서 특정한 사용자에게만 특정 객체를 이용하거나 못하게하는 접근통제(Access Control)기능추가. Ⅳ. SNMPv1은 UDP를 기본으로 이용하는데 비해서 SNMPv2는 전송계층에 대해서 UDP 뿐만 아니라 OSI Connectionless Network Services(CLNS) AppleTalk’s Datagram Deivery Protocol(DDP)Novell’s Internetwork Packet Exchange(IPX) 등도 구현할 수 있도록 정의 SNMPv3 보안기능 제공 Authentication(인증) Encryption(암호)

Q/A trap 이 발생하는 이유 trap의 필요성 >장비가 꺼졌다 켜졌을 때 >특정 포트의 장애가 발생하여 port down이 발생했을 때 trap의 필요성 SNMP Manager는 polling이라는 방식을 통해 주기적으로 자신이 관리할 네트워크 장비들에게 질의를 보낸다. 예를 들어, 200대의 스위치, 라우터, 서버, UPS가 등록된 네트워크를 관리하는 경우에는 200번의 polling이 필요하다. 그런데 SNMP manager와 SNMP agent간의 네트워크 상태가 안 좋거나 할 때는 retry가 발생할 수 있기 때문에 장애가 있는 장비까지 polling이 도달하는 시간이 느려진다. 이런 경우 장애가 발생한 장비를 늦게 검색할 수 있는 위험이 있고 SNMP manager의 polling 프로세서가 알고리즘의 문제로 인해 장애장비를 polling하기 이전에 그 이전의 polling list에 등록된 장비를 무한 polling하는 오류가 생길 수도 있다. 이러한 맹점을 보완하기 위해 SNMP에서 trap이라는 interrupt를 발생시켜 SNMP manager에게 빠른 처리 요청을 할 수 있는 보완장치를 둔 것이다.

Q/A MIB에 들어가는 내용은… MIB는 정보를 각각의 그룹에 맞게끔 분류해서 정보를 담아 놓고 있고 아래와 같음 그룹 내용 SNMP SNMP 프로토콜에 대한 정보를 갖는 객체들의 그룹이다. System 시스템의 상태에 대한 객체들을 갖는다. 마지막으로 부팅된 시간, 시스템의 위치 등이 이에 해당된다. Interface 인터페이스 그룹 역시 모든 시스템에서 필수 사항이다. 시스템의 인터페이스개수, 상태 등이 그 객체다. AT Address Translation의 약자로 그룹으로서 각 인터페이스별 네트워크 주소 해석에 대한 객체를 갖는다. IP IP 패킷의 단편화, 패킷의 재조합 상태 등이 그 객체다. ICMP ICMP 오류 패킷의 수, 전송 불가 패킷의 수 등이 객체다. TCP 특정 TCP 접속에 대한 정보를 펴현하는 객체 유형들은 일시적이다. 그 실체들은 접속이 끝남과 동시에 없어진다. UDP 전송된 UDP의 개수, 수신된 UDP 패킷의 개수, 열린 포트 등의 정보들이 이에 해당된다. EGP EGP를 유지 관리하기 위한 객체들이다. Transmission 각 인터페이스별 전송에 대한 정보들이 그 객체가 된다.

참조 대한민국 전산망표준 [단순 망 관리 규약(SNMP) 표준] KIS―3I―0016 RFC-1155,1156,1157