'Computer/Network'에 해당되는 글 4건

  1. 2009.11.11 SNMP
  2. 2009.10.29 ICMP
  3. 2009.02.04 Libpcap 사용하기
  4. 2008.12.22 SNMP
2009.11.11 15:00

단순 망 관리 규약(SNMP) 표준

------------------------------------------------------------------------------------------------------------------------------

 

대한민국 전산망표준 
KIS―3I―0016('93) 
단순 망 관리 규약(SNMP) 표준 
1993. 12 
  

체 신 부 
  

전 문

 본 규약은 이기종으로 구성된 전산망의 효율적인 관리를 목표로, TCP/IP를 기반으로 하는 전산망을 관리하기 위해 간단히 운용할 수 있는 구조와 시스템을 제공한다. 본 규약은 국내전산 망이 개방시스템 상호접속(OSI)으로 완전히 전환되기 전까지는 전산망관리 잠정표준으로서 전산 망에 적용된다.

 본 규약은 전산망내에 있는 노드들을 관리하기 위해 사용되는 단순 네트워크 관리 프로토콜 (SNMP: Simple Network Management Protocol)을 규정한다. 그리고 관리정보의 정의를 위한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 규정하고, TCP/IP를 기반으로 하는 전산망에서, 피관리 대상들의 집합체인 관리정보베이스의 두 번째 버전(MIB-II: Management Information Base)을 정의한다.

 본 규약은 미국 IETF(Internet Engineering Task Force)에서 발간된 RFC(Request For Comments) 1155 -- SMI, RFC 1213 -- MIB-II, RFC 1157 -- SNMP 를 번역하여 국내 전문가의 기술적인 검토를 토대로 작성되었다.

 

* 주요단어 : 단순전산망관리(SNMP), 관리정보구조(SMI), 관리정보베이스(MIB)

--------------------------------------------------------------------------------------------------------------------------------
  

목 차

제 1 장 총 칙

1.1 목적 
1.2 필요성 
1.3 적용대상 및 범위 
1.4 주요내용

 

제 2 장 근거 및 관련표준 
  2.1 근거
  2.2 관련표준

 

제 3 장 용어의 정의 
  3.1 주요 용어 정의

 

제 4 장단순 전산망관리 프로토콜(SNMP) 
  4.1 개요
  4.2 SNMP 구조
  4.2.1 구조의 목적 
  4.2.2 구조의 구성 요소 
  4.3 프로토콜 명시 
  4.3.1 절차 요소
  4.4 정의 
  4.5 참고 문헌

 

제 5 장 TCP/IP기반 연결망(internets)을 위한 관리정보의 구조(SMI) 
  5.1 개요 
  5.2 관리 정보의 구조와 식별 
  5.2.1 이름 
  5.2.2 구문 
  5.2.3 부호화 
  5.3 관리 객체 
  5.3.1 객체 이름에 대한 지침 
  5.3.2 객체 유형과 실체 
  5.3.3 관리 객체를 위한 매크로 
  5.4 MIB 확장 
  5.5 정의 
  5.6 참고 문헌

 

제 6 장 TCP/IP기반 연결망의 네트워크관리를 위한 관리정보베이스(MIB-II) 
  6.1 개요 
  6.2 RFC 1156으로부터의 변화 
  6.2.1 삭제 대상 객체 
  6.2.2 출력 문자열 
  6.2.3 물리적 주소 
  6.2.4 시스템 그룹 
  6.2.5 인터페이스 그룹 
  6.2.6 주소 해석 그룹 
  6.2.7 IP 그룹 
  6.2.8 ICMP 그룹 
  6.2.9 TCP 그룹 
  6.2.10 UDP 그룹 
  6.2.11 EGP 그룹 
  6.2.12 전송 그룹 
  6.2.13 SNMP 그룹 
  6.2.14 RFC 1158로부터의 변화 
  6.3 관리 객체 
  6.3.1 정의 형식 
  6.4. 정의 
  6.4.1 본문의 관례적 표기
  6.4.2 MIB-II에서의 그룹 
  6.4.3 시스템 그룹 
  6.4.4 인터페이스 그룹
  6.4.5 주소 변환 그룹 
  6.4.6 IP 그룹 
  6.4.7 ICMP 그룹 
  6.4.8 TCP 그룹
  6.4.9 UDP 그룹 
  6.4.10 EGP 그룹 
  6.4.11 전송 그룹 
  6.4.12 SNMP 그룹 
  6.5 참고 문헌

 

보칙


부칙 
  
  

제 1 장 총 칙

1.1 목적

 이 표준은 TCP/IP 기반 전산망을 관리하기 위해 사용되는 단순전산망관리 규약(SNMP : Simple  Network Management Protocol)을 규정하여 효과적인 전산망관리를 도모하고자 한다. 
  

 

1.2 필요성

 전산망은 관련기술의 급속한 발달로 다양한 기능 및 서비스를 제공하고 있으며 과거의 중앙 집중방식에서 분산환경으로 바뀌고 있다. 또한 다수공급자에 의해 제공되며 다양한 장비로 구성되는 전산망은 본질적으로 복잡성 및 이질성을 내포하고 있다.


따라서 이러한 전산망 구성요소를 효과적으로 감시·통제하기 위한 전산망관리는 그 중요성이 점증되고 있다. 이질적인 전산망을 효과적으로 관리하기 위한 개방적이고 표준화된 괸리시스템이 존재하지 않는다면 호환성 및 상호운용성을 보장하는 개방시스템은 통제불능으로 인해 그의미가 상실될 것이다. 

효과적인 전산망관리를 수행하려면 기본적으로 전산망관리 시스템과 피관리노드간의 관리정보를 주고 받기위해 관리정보 통신프로토콜, 관리정보구조, 관리정보의 정의 등의 전산망관리 매카니즘이 표준화되어야 한다. 
  

 

1.3 적용대상 및 범위

 이 표준의 적용범위는 전산망관리 표준 프로토콜의 제정에 필요한 단순 전산망관리 규약(SNMP: Simple Network Management Protocol) 표준, 관리정보구조(SMI: Structure of Management Information)에 관한 표준, 관리정보베이스(MIB: Management Information Base) 표준을 포함하고 있다.

 국가기간전산망 또는 정부기관 전산망의 관리자와 전산망관리 제품의 구매자가 이 표준에서 언급하는 전산망관리 잠정표준 프로토콜과 동등한 기능을 제공하는 전산망관리 제품이나 서비스가 조달되어질 때 적용된다. 
  

 

1.4 주요내용

 이 표준의 내용은 다음과 같다.

 첫째, TCP/IP를 갑으로 하는 전산망에 있는 노드들을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공하는 단순 전산망관리 프로토콜(SNMP: Simple Network Management Protocol)을 규정한다.

 둘째, 관리정보는 TCP/IP를 기반으로 하는 전산망을 관리하는데 사용되는 것으로 이 관리정보의 정의에 대한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 제공한다.

 셋째, TCP/IP를 기반으로 하는 전산망의 관리 프로토콜을 이용한 관리정보베이스의 두번째 버전(MIB-II: Management Information Base)을 정의한다. 
  

 

제 2 장 근거 및 관련표준

2.1 근거

 전산망 기술기준에 관한 규칙 제 4 조 (기능표준등의 고시) 
  

 

2.2 관련표준

 ○ "Structure and Identification of Management Information for TCP/IP-based internets" RFC 1155, IETF. 

○ "The Simple Network Management Protocol (SNMP)", RFC 1157, IETF. 

○ "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, IETF.
  

 

제 3 장 용어의 정의

3.1 주요 용어 정의

 ⊙ CMIP over TCP(CMOT): OSI 전산망관리 프로토콜을 TCP/IP를 사용하는 전산망에 적용하는 전산망관리 방법 

⊙ High-level Entity Management System(HEMS): 인터네트에서 초기에 고안한 전산 망관리 시스템 

⊙ IP 계층(internet layer): 인터네트 프로토콜 중 상이한 물리적 전산망 사이의 상호 통신을 담당하는 계층 

⊙ Internet Assigned Numbers Authority(IANA): 인터네트 프로토콜에서 사용하는 할당 번호를 관리하는 기구 

⊙ Internet Control Message Protocol(ICMP): IP의 간단한 보고용 프로토콜 

⊙ Internet Engineering Steering Group(IESG): IETF의 활동을 조정하는 그룹 

⊙ Internet Engineering Task Force(IETF): 인터네트의 단기적 문제를 해결하기 위한 IAB의 소위원회 

⊙ Request for Comments(RFC): 인터네트 프로토콜 또는 그와 관련된 실험을 기술 하는 문서 

⊙ Simple Gateway Monitoring Protocol(SGMP): SNMP의 원형인 관리 프로토콜 참고 

⊙ 개방시스템상호접속(Open Systems Interconnection : OSI): IOS의 개방형 전산망 시스템 

⊙ 게이트웨이(gateway): 인터네트에서 라우터를 지칭하는 용어로 둘 또는 그 이상의 종속망을 상호접속하여 한 종속망에서 다른 쪽으로의 데이타의 통로를 가능케하는 장비 또는 장비의 쌍 

⊙ 경량 표현 프로토콜(light weight presentation protocol): OSI의 표현 서비스중 일부 만을 지원하는 프로토콜

⊙ 공개 키(public key): 이중 암호 시스템에서 공개시키는 키 

⊙ 공통관리 정보규약(Common Management Information Protocol : CMIP): 전산망 관리를 위해 OSI에서 제정한 프로토콜 

⊙ 공통관리 정보서비스(Common Management Information Service : CMIS): CMIP 에서 제공하는 전산망관리 서비스, OSI 시스템관리 소프트웨어 프로세스간에 관리정보 의 상호교환을 성취시켜주는 통신 메카니즘 

⊙ 관리 대상(managed object): 전산망관리에 필요한 정보 

⊙ 관리 대상군(managed object group): 같은 전산망 기능을 관리하는 관리 대상의 집합 

⊙ 관리 대상점(managed node): 전산망관리 대리인을 가지고 있는 전산망 장비 

⊙ 관리 정보 기반(Management Information Base : MIB): 관리 대상의 집합 

⊙ 구성 관리(configuration management): 전산망관리 기능중 전산망을 형성하는 전산망 요소들의 
연결성, 동작 상태, 관리 상태등을 감시하고 제어하는 기능 

⊙ 국제표준화기구(International Organization for Standardization : ISO): 국제 표준을 제정하는 기관 

⊙ 군체(community): 전산망관리 대리인과 전산망 관리소와의 행정적 관계 

⊙ 군체 단면(community profile): 군체의 소속원이 조작할 수 있는 전산망관리 대리인이 보유하고 있는 관리 대상의 일부 

⊙ 군체 이름(community name): 군체를 나타내는 문자 스트링 

⊙ 기본 부호화 법칙(Basic Encoding Rules): 전송 구문을 기술하는 OSI에서 정의한 언어 

⊙ 단순 네트워크 관리 프로토콜(Simple Network Management Protocol : SNMP): 
1988년 초, Internet Activities Board(IAB)가 가진 ad-hoc 모임 즉, 국가 전체의 TCP/IP에 기초를 둔 Internet를 관리하는데 있어 전략을 결정하기 위한 이 모임에서 표준화에 대한 단기해결책으로 제시한 방안. 

⊙ 단편(fragment): 큰 IP 데이타그램이 분할된 조각 

⊙ 데이터 그램(datagram): 다른 데이터그램 등과 독립적으로 전송되는 독립 데이터 단위 

⊙ 무결성(integtity): 현한을 부여 받지 않은 개체로 부터의 영향으로는 시스템이나 데이터가 변경되거나 파괴되지 않고 원래대로 보존되는 특성 

⊙ 무연결형(connection-less mode): 한 단계에서 데이터 전송과 주소 지정과 같은 제어를 같이하는 서비스 

⊙ 물리적 주소(hardware address): 물리적 인터페이스의 주소 

⊙ 분할(fragmentation): 큰 IP 데이터그램을 여러개의 단편으로 나누는 것 

⊙ 성능 관리(performance management): 전산망관리 기능중 전산망의 부하나 제반 성능을 감시하는 기능 

⊙ 세그먼트(segment): TCP의 통신 단위 

⊙ 실험적 MIB(experimental MIB): 인터네트 관리 공간중 experimental 트리에 등록되어 있는 관리 대상의 집합 

⊙ 연결형(connection-oriented mode): 경로 연결, 데이터 전송, 경로 해제의 세 단계로 구성된 서비스 

⊙ 외부 게이트웨이 프로토콜(Exterior Gateway Protocol : EGP): 인터네트의 외부 게이트웨이 사이에서 라우팅을 위해 제정한 프로토콜 

⊙ 응용 계층(application layer): 응용 프로세스 사이의 통신을 관리하는 OSI 시스템의 최상층 구조 

⊙ 인스턴스 인식표(instance-identifier): 관리 대상 인스턴스를 인식하는 방법 

⊙ 인증(Authentication): 통신 상대방의 신분을 확인하여 접근이 허용된 실체인지 확인하는 것 

⊙ 인터네트(Internet): 인터네트 프로토콜에 의해 상호 연결된 거대한 전산망의 집합 

⊙ 인터네트 전산망 관리 기초구조(Internet-standard Network Management Framework): REC 1155, 1156, 1157에 정의된 인터네트에서 제정한 전산망관리 시스템의 기본 구조 

⊙ 인터네트 초안(Internet Drafts): IETF의 작업결과를 기술하는 문서 

⊙ 인터네트 표준개발 위원회(Internet Activities Board : IAB): 인터네트 프로토 콜의 발달을 총괄하는 기술적 기구 

⊙ 인터네트 프로토콜(Internet Protocol : IP): IP 계층에서 사용하는 프로토콜 

⊙ 인터네트 프로토콜 주소(IP address): 인터네트에 접속된 점을 나타내는 32bit로 된 주소 

⊙ 인터페이트 계층(interface layer): 한 물리적 전산망안에서의 전송을 하는 인터네트 프로토콜의 최하계층 

⊙ 장애 관리(fault management): 전산망관리 기능 중 전산망 장비의 장애 발견 및 원인 구분, 그리고 비정상적인 동작이나 장애 상태를 수리하는 기능 

⊙ 전산망 관리소(network management station): 전산망의 관리를 관장하는 시스템 

⊙ 전산망 인식표(network-identifier): IP 주소중 전산망을 지칭하는 부분 

⊙ 전산망관리(network management): 전산망이 본연의 목적을 달성하도록 감시 제어 하는 행위 

⊙ 전산망관리 대리인(network management agent): 전산망 관리소의 감시, 제어하에 관리 대상을 관리하는 관리 대상점에 있는 전산망관리 프로토콜의 구현 

⊙ 전산망관리 프로토콜(network management protocol): 관리 정보를 전송하기 위한 프로토콜 

⊙ 전송 제어 규약(Transmission Control Protocol : TCP): 미국 국방성의 ARPANET 에서 처음 사용되었으며 ISO의 트랜스포트 계층에 해당하는 ordered, connection-oriented, reliable, full-duplex 프로토콜 

⊙ 접근 권한(Authorization): 통신 상대방이 접근할 수 있는 데이터의 범위와 접근 형태를 정의하는 것 

⊙ 접근 제어(access control): 불법적으로 시스템이나 레이더에 접근하는 것을 방지함 

⊙ 접근 형태(access mode): SNMP 군체가 보유하고 있는 관리 대상에 대한 접근 권한 

⊙ 추상 구문(abstract syntax): 하드웨어의 구조 및 한계와 독립적인 데이터 유형의 기술 

⊙ 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1): 추상 구문을 기술하기 위해 OSI에서 제정한 언어 ⊙ 포트 번호(port number): 인터네트 프로토콜의 전송 계층에서 응용 프로세스를 구별하는 번호 

⊙ 프로토콜 데이타 단위(protocol data unit:PDU) : 프로토콜 제어 정보와 사용자 데이터를 포함하는 프로토콜 실체간의 전송 단위 

⊙ 프로토콜 제어 정보(protocol control information): 상대편과의 통신을 제어하는 정보 

⊙ 행정 구조(administrative framework): 인증과 접근 권한 방침을 정의하기 위한 방법 

⊙ 호스트(host): 응용 계층 서비스를 하는 전산망 설비를 지칭하는 인터네트 용어 
  

 

제 4 장 단순 망관리 프로토콜(SNMP)

 4.1 개요

 단순 망관리 프로토콜(SNMP) 표준은 전산망 구성 요소에 관한 관리 정보가 논리적으로 원격 지사용자들에 의해 조사되거나 변경될 수 있게 지원하는 간단한 프로토콜을 정의한다. 특히, 관리정보 베이스(MIB)와 함께 관리 정보의 구조(SMI)를 기술하는 관련 표준들과 같이 본 표준은 TCP/IP를 기반으로 하는 연결망들(internets)을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공한다.


인터네트 전산망 관리 표준안(Internet Network Management Standards)[1] 개발을 위한 인터네트 표준개발 위원회(Internet Activities Board:IAB) 권고안인 RFC 1052에 보고된 것처럼,TCP/IP를 기반으로 하는 연결망의 전산망관리 표준을 위한 두가지 전략이 착수되었다. 단기적으로, 단순 전산망관리 프로토콜(SNMP)은 인터네트 공동체에 있는 노드들을 관리하기 위해 사용하고 장기적으로, OSI 전산망관리 체계로의 전환이 이루어지는 것이다. 

전략은 단기적으로 성공했다. 즉, 인터네트를 기반으로 하는 전산망관리 기술은 몇 달 내에 연구소와 기업체들에 의해 실제 상황에서 실험되었다. 이런 결과로, 인터네트 공동체의 일부분들은 적절한 방식으로 전산망관리가 용이해졌다. 

IAB는 "권고" 상태를 갖는 완전한 "표준 프로토콜"이 되기 위해 SNMP, SMI 그리고 초기 인터네트 MIB를 지정했다. 이런 행동에 의해, IAB는 모든 IP와 TCP 구현에 전산망 관리가 가능하며 전산망관리가 가능한 구현실상(instance)은 SMI, MIB, 그리고 SNMP를 채택하고 구현하도록 권고하고 있다.


이와같이, TCP/IP를 기반으로 하는 연결망을 위한 현재의 전산망관리 체계는 다음과 같이 구성된다. TCP/IP를 기반으로 하는 인터네트를 위한 관리 정보의 구조와 식별은 MIB에 포함된 관리객체가 RFC 1155[5]에서 제안된 것처럼 정의되는 방법을 기술한다. TCP/IP를 기반으로 하는 인터네트의 전산망 관리를 위한 관리 정보 베이스는 RFC 1156[6]에 제안된 것처럼 MIB에 포함된 관리객체를 기술한다.

그리고, 단순 전산망 관리 프로토콜은 이 표준에 제안된 것처럼 이런 객체들을관리하기 위해 사용되는 프로토콜을 정의한다. 
  

 

4.2 SNMP 구조

 SNMP의 구조적인 모델은 전산망 관리 스테이션들과 전산망 요소들로 이루어진다. 전산망 관리스테이션들은 전산망 요소들을 감시하고 통제하는 관리 응용들을 수행한다. 전산망 요소들은 
호스트, 게이트웨이, 단말기 서버등과 같은 장비이며, 이 장비에는 전산망 관리 스테이션들로 부터요청된 전산망 관리 기능들을 수행하는데 책임이 있는 관리 수행자가 있다.


단순 전산망 관리 프로토콜(SNMP)은 전산망 관리 스테이션들과 전산망 요소들에 있는 수행자들사이의 관리 정보를 교환하기 위해 사용된다.

 

4.2.1 구조의 목적

 SNMP는 관리 수행자 자체에 의해 실현되는 관리 기능의 수와 복잡성을 최소화한다. 이런 목적은 적어도 네가지 점에서 호소력이 있다.

(1) 프로토콜을 지원하기 위해 필요한 관리 수행자 소프트웨어의 개발 비용이 그에 맞추어 감소 된다. 
(2) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 업무에 있어서 연결망자원의 충분 한 이용을 가능하게 한다. 
(3) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 도구들의 형식과 정교함에 대해 가능한한 최소의 제한사항이 부과된다. 
(4) 관리 기능의 단순화된 집합은 전산망 관리 도구의 개발자들에 의해 쉽게 이해되고 사용된다.

 이 프로토콜의 두번째 목적은 감시와 제어를 위한 기능적인 형태 활용이 전산망 운영과 관리의 추가적이고 예측치 못한 측면을 조절할 정도로 충분히 확장가능하다는 것이다. 
세번째 목적은, 그 구조가 특정 호스트 또는 게이트웨이의 구조와 메카니즘과는 가능한 한 독립적이라는 것이다.

 

4.2.2 구조의 구성 요소

 SNMP 구조는 다음 사항에 의해 전산망 관리 문제의 해결책을 명확히 표명한다.

 (1) 프로토콜에 의해 교환되는 관리 정보의 영역, 
(2) 프로토콜에 의해 교환되는 관리 정보의 표현, 
(3) 프로토콜에 의해 지원되는 관리 정보에 관한 동작, 
(4) 관리 실체들 사이의 교환의 형식과 의미, 
(5) 관리 실체들 사이의 관리적인 관계의 정의, 
(6) 관리 정보 참조의 형식과 의미.

 

4.2.2.1 관리 정보의 영역

 SNMP의 운영에 의해 교환되는 관리 정보의 영역은 인터네트 표준 MIB에 정의된, 또는 인터네트표준 SMI[5]에 의해 제안된 규정에 따라 정의된 모든 단순 객체 유형의 실상(instance)에 의해 표현된다. 
MIB 내에서 집합 객체 유형에 대한 지원은 SMI를 따를 필요도 없고 SNMP에 의해 구현 되지도 않는다.

 

4.2.2.2 관리 정보의 표현

 SNMP 운영에 의해 교환되는 관리 정보는 SMI에 있는 단일 유형 정의로 명시된 ASN.1 언어 [9]의 부분 집합에 따라 표현된다.


SGMP는 ASN.1 언어[9]의 잘 정의된 부분집합을 사용한 규정을 채택했다. SNMP는 계속해서 이런 방식을 확장하여 관리 객체를 기술하고 그런 객체를 관리하는데 사용되는 프로토콜 데이타 단위(PDU)를 기술하는데 ASN.1의 좀 더 복잡한 부분집합을 사용한다.

더우기, OSI를 기반으로하는 전산망 관리 프로토콜로의 궁극적인 전이를 용이하게 하려는 경향이 인터네트 표준 관리 정보의 구조와 관리 정보 베이스를 ASN.1 언어로 정의하게 하였다. 부분적으로, ASN.1 언어의 사용은 이전의 노력 특히, SGMP에서 ASN.1의 성공적인 사용에 의해 장려되었다.

SMI의 부분인 ASN.1의 사용에 관한 제약사항은 SGMP의 경험에 의해 지지를 받고 타당성을 인정받은 단순성에 공헌했다. 또한 단순성을 위해, SNMP는 ASN.1의 BER[10]의 부분집합만을 사용한다. 다시 말해서, 모든 부호화는 한정된 길이의 형식을 사용한다.

가능하다면, 조립형 부호화보다는 비조립형 부호화가 사용된다. 이런 제한은 그들이 포함하는 자료 객체와 상위 계층 프로토콜 데이타 단위(PDU)를 위해 ASN.1 인코딩의 모든 측면에 적용된다.

 

4.2.2.3 관리 정보에 지원되는 동작

 SNMP는 변수의 변환 또는 조사로써 모든 관리 수행자의 기능을 모델화한다. 논리적으로 원격 지호스트 상의 프로토콜 엔티티(전산망 요소 자체)는 변수들을 바꾸거나 검색하기위해 전산망 요소상에 주둔하는 관리 수행자와 상호작용한다. 이런 방법은 적어도 두가지 긍정적인 결과를 갖는다.

(1) 관리 수행자에 의해 실현되는 필수적인 관리 기능의 수를 둘로 제한하는 결과를 가져온다. 
즉, 명시된 구성이나 다른 매개변수에 값을 할당하는 동작이고 다른 하나는 그런 값을 검색하는 동작이다.

(2) 이런 결정의 두번째 결과는 필수적인 관리 명령어를 위해서 프로토콜 정의에 대한 지원이 있어야 한다는 것을 피하게 해준다. 그런 명령어의 수는 실제로 계속 증가하고, 일반적으로 그런 명령어의 의미는 복잡하다.

 SNMP에서 암시하고 있는 전략은 세부적으로 중요한 수준에 있는 전산망 상태의 감시는 주로 감시 센타 부분의 해당 정보를 폴링하여 이뤄진다는 것이다. 제한된 수의 비요구 메세지(traps) 는폴링의 시기와 중요성을 지시한다. 요구되지 않은 메세지 수를 제한하는 것은 전산망 관리 기능에 의해 발생된 교통량을 최소화하고 단순성의 목적과 일관된다.


가시적으로 지원되는 관리 기능의 집합에서 지시 명령어의 배제는 바람직한 관리 수행자 운영을 방해하지는 않을 것이다. 현재, 대부분의 명령어는 어떤 매개변수 값을 설정하거나 그런 값을 검색하기 위해 요청된다. 그리고 현재 지원되는 몇가지 지시 명령어의 기능은 이런 관리 모델에 의해 비동기모드로 쉽게 조절된다.

이런 방법에서, 지시 명령어는 원하는 행동을 개시시키는 매개변수 값의 설정으로 구현되어야 한다. 예를 들면, "재시동 명령어"의 구현 보다는 이런 동작이 시스템 재시동될때까지의 초를 나타내는 매개변수를 설정하는 것에 의해 실행되어야 한다.

 

4.2.2.4 프로토콜 교환의 형태와 의미

 관리 실체들 사이의 관리 정보 교환은 프로토콜 메세지의 교환을 통해 SNMP 내에서 실현된다. 
그런 메세지의 형태와 의미는 3절에서 정의된다.


관리 수행자의 복잡성을 최소화하는 목적과 일관되도록 하기 위해, SNMP 메세지 교환은 비신 뢰적 데이타그램 서비스만을 요구하고, 모든 메세지는 하나의 수송계층 데이타그램에 의해 완전히독립적으로 표현된다. SNMP 메카니즘은 일반적으로 다양한 수송계층 서비스를 이용하기에 적합하다.

 

4.2.2.5 행정적 관계의 정의

 SNMP 구조는 프로토콜에 참여하는 실체들 사이의 다양한 행정적 관계를 인정한다. SNMP를 이용하여 서로 통신하는 전산망 요소와 관리 스테이션에 주둔하는 실체들은 SNMP 응용 엔티티라 한다. SNMP를 구현하여 SNMP 응용 실체들을 지원하는 동위 프로세스들은 프로토콜 엔티티라 한다.


SNMP 응용 엔티티의 임의의 집합으로 된 SNMP 수행자의 쌍을 SNMP 공동체라 한다. 각 SNMP 공동체는 옥테트 스트링으로 명명되는데, 그것은 공동체 이름으로 불리운다.


공동체 구성요소에 의해 명명되어 실제로 SNMP 공동체에 속하는 SNMP 응용 엔티티에 의해 발생한 SNMP 메세지를 인증된 SNMP 메세지라 한다. SNMP 메세지가 특정 SNMP 공동체를 위한 인증된 SNMP 메세지로 식별되는 법칙들의 집합을 인증 기법이라 한다. 여러 인증 기법에 따라 인증된 SNMP 메세지를 식별하는 기능의 구현은 인증 서비스라 한다.


SNMP 응용 실체들 사이의 행정적 관계의 확실하면서도 효과적인 관리는 고도의 확실성으로 인증된 SNMP 메세지를 식별할 수 있는 인증 서비스(암호화 또는 다른 기술을 이용한)를 요구한다. 몇가지 SNMP 구현은 모든 SNMP 메세지를 믿을만한 SNMP 메세지로 식별하는 단순한 인증 기법만을지원할 수 있다.


전산망 구성요소를 위해, 그 요소에 속한 MIB 내의 객체들의 부분집합을 SNMP MIB 영역이라 한다. SNMP MIB 영역에 표현된 객체 유형의 이름은 객체 유형 이름 공간의 하나의 서브트리에 속할필요는 없다.

 집합 { 읽기전용, 읽기쓰기 }의 요소는 SNMP 접근 방식이라 한다.

 SNMP MIB 영역을 갖는 SNMP 접근 방식의 쌍은 SNMP 공동체 프로화일이라 한다. SNMP 공동체 프로화일은 명시된 MIB 영역에 있는 변수들에 명시된 접근 권한을 나타낸다. 주어진 SNMP 공동체프로화일에 있는 MIB 영역 내의 모든 변수들에 대해, 변수 접근은 다음 규정에 따르는 프로화일로 나타낸다.

(1) 언급된 변수가 MIB 내에 "접근:"이 "금지"로 정의된다면, 어떤 연산자에 대한 피연산자로이용불가능하다. 

(2) 언급된 변수가 MIB 내에 "접근:"이 "읽기쓰기" 또는 "쓰기전용" 그리고 주어진 프로화일의 접근 모드가 "읽기쓰기"라면, 그 변수는 GET, SET, TRAP 동작의 피 연산자로 이용가능하다. 

(3) 그밖의 경우, 변수는 GET 그리고 TRAP 동작의 피연산자로 이용가능하다.

(4) "쓰기전용" 변수가 GET 또는 TRAP 동작에 사용되는 피연산자인 경우에, 그 변수 에 주어진 값은 구현시 결정할 수 있다.

 SNMP 공동체 프로화일을 갖는 SNMP 공동체의 쌍은 SNMP 접근 정책이라 불린다. 그 공동 체의 다른 구성원들에게 접근 정책이라는 것은 명시된 SNMP 공동체의 SNMP 수행자에 의해 제공되는 명시된 공동체 프로화일을 의미한다. SNMP 응용 실체들 사이의 모든 관리적인 관계 는 구조적으로 SNMP 접근 정책에 의해 정의된다.

 모든 SNMP 접근 정책에 대해, 명시된 SNMP 공동체에 대한 SNMP 수행자가 상주하는 전산 망 요소가 명시된 프로화일에 대한 MIB 영역에 속한 곳이 아니라면, 그 정책은 SNMP 대리 접근 정책이라 불리운다. 대리 접근 정책에 연관된 SNMP 수행자는 SNMP 대리 수행자로 불리운다.

대리 접근 정책의 부주의한 정의가 관리 루프를 초래할 수 있는 반면, 대리 정책의 신중한 정의는 적어도 두가지면에서 유용하다.

 (1) 관리 프로토콜과 수송계층 프로토콜을 사용하여 주소를 지정할 수 없는 전산망 요소의 제어와 감시를 허락한다. 다시 말해서, 대리 수행자는 상이한 관리 체계를 지원하는 모뎀, 멀티플렉서와 같은 장치를 포함하는 모든 전산망 요소에 일관된 관리 체계를 적용할 수 있도록 하는 프로토콜 변환 기능을 제공할 수 있다.

 (2) 잠재적으로 정교한 접근 제어 방식으로 부터 전산망 요소를 보호한다. 예를 들면, 대리 수행자는 MIB 내의 변수들의 다양한 부분집합이 전산망 요소의 복잡도를 증가시키지 않고 다른 관리 스테이션에 접근할 수 있게 한다.


범위 : 구성요소의 관리 범위 
PCommunity : 대리 수행자를 이용하는 공동체의 이름 
DCommunity : 직접 공동체의 이름

 

4.2.2.6 관리 객체에 대한 참조의 형식과 의미

 SMI는 이를 준수하는 관리 프로토콜의 정의가 다음을 설명한 것을 요구한다.

(1) 모호한 MIB 참조의 해결 
(2) 현존하는 MIB 버젼에 있어서 MIB 참조의 해결, 그리고 
(3) MIB에 정의된 객체 유형의 특정 실상(instance) 식별

 

4.2.2.6.1 모호한 MIB 참조의 해결

 SNMP 동작 영역은 개념적으로 하나의 네크워크 요소와 관계된 객체로 제한되고, MIB 객체 로의 모든 SNMP 참조는 (암시적 또는 표면적으로) 유일한 변수 이름으로 이루어지므로, MIB에 정의된 어떤 객체 유형에 대한 SNMP 참조가 그 유형의 여러 실상(instance)을 참조할 가능성은 없다.

 

4.2.2.6.2 MIB 버젼에 따른 참조의 해결

 어떤 SNMP 동작에 의해 참조되는 객체 실상(instance)은 전체 MIB 내에서 get-next 동작의 경우에 그의 직접적인 계승자 또는 동작 요청의 부분으로 명시된 것이다. 특히, 인터네트 표준 MIB버젼의 부분으로 객체에 대한 참조는 언급된 인터네트 표준 MIB 버젼의 부분이 아닌 객체를 해결하지 못한다.

다만, 요청된 동작이 get-next이고 명시된 객체 명이 언급된 인터네트 표준 MIB 버젼의 부분으로 나타난 모든 객체들의 이름 중에서 사전순으로 마지막인 경우는 예외이다.

 

4.2.2.6.3 객체 실상(instance)의 식별

 MIB에 있는 모든 객체 유형의 이름은 인터네트 표준 MIB 또는 SMI의 이름 설정 규정에 따르는 다른 문서에 명확히 정의된다. 이를 준수하는 관리 프로토콜이 특정 전산망 요소를 위한 객체 유형 각각의 실상(instance)을 식별하기 위한 메카니즘을 정의하는 것을 SMI는 요구한다.


MIB에 정의된 어떤 객체 유형의 각 실상(instance)은 그것의 "변수 명"으로 불리는 유일한 이름에 의해 SNMP 동작에서 식별된다. 일반적으로, SNMP 변수의 이름은 x.y 형식의 OBJECT IDENTIFIER로, x는 MIB에 정의된 단순 객체 유형의 이름이고 y는 명명된 객체 유형에 정해진 방법으로서, 원하는 실상(instance)을 식별하는 OBJECT IDENTIFIER 부분이다.

 이러한 명명 방법은 GetNextRequest-PDU 의미의 충분한 개발을 보장한다(3절 참조). 그 이유는MIB에 알려진 모든 변수 명이 사전편집 순서로 연속하도록 관련된 변수를 위한 이름을 할당하기 때문이다.


객체 실상(instance)의 유형에 정해진 명명은 많은 객체 유형의 등급을 위해 다음과 같이 정의 된다. 다음 명명 원칙 중에 응용할 수 없는 객체 유형의 실상(instance)은 x.0 형식의 OBJECT IDENTIFIER에 의해 명명된다. x는 MIB 정의에 있는 객체 유형으로 불리는 이름이다.


예를 들면, 변수 sysDescr의 실상(instance)을 식별하길 원한다고 가정하자. sysDescr을 위한 객체 등급은 다음과 같다.

 iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1

 그러므로, 객체 유형 x는 1.3.6.1.2.1.1.1이고 이것에 실상(instance) 서브 식별자로 0 이 추가된다. 다시 말해서, 1.3.6.1.2.1.1.1.0는 sysDescr의 실상(instance) 하나만을 식별한다.

 

4.2.2.6.3.1 ifTable 객체 유형 이름

 서브네트(Subnet) 인터페이스 s의 이름은 i 형식의 OBJECT IDENTIFIER 값이다. 이때 i는 s에 연관된 ifIndex 객체 유형의 실상(instance)의 값을 갖는다. 정의된 이름 n이 ifEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.s형식의 OBJECT IDENTIFIER로 명명되며, 이때 s는 i가 서브네트 인터페이스 정보를 나타내는 이름이다.


예를 들면, 인터페이스 2에 연관된 변수 ifType의 실상(instance)을 식별하길 원한다고 가정해보자. 이 경우 ifType.2는 원하는 실상(instance)을 식별한다.

 

4.2.2.6.3.2 atTable 객체 유형 이름

 AT-cached 전산망 주소의 이름 x는 1.a.b.c.d 형식의 OBJECT IDENTIFIER이다. 
이때 a.b.c.d("dot" 표기법)는 x에 연관된 atNetAddress 객체 유형의 값이다. 
주소 해석 동치 e의 이름은 s.w 형식의 OBJECT IDENTIFIER로, s는 e에 연관된 atIndex 객체 유형의 실상(instance) 값이고, w는 e에 연관된 AT-cached 전산망 주소의 이름이다.


정의된 이름 n이 atEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 주소 해석 동치 정보를 나타내는 이름이다. 
예를 들면, 인터페이스 3과 89.1.1.42 IP 주소에 연관된 주소 해석 테이블(ARP cache)에 있는 엔트리의 물리적 주소를 찾기를 원한다고 가정하자. 이 경우, atPhysAddress. 3.1.89.1.1.42는 원하는 실상(instance)을 식별한다.

 

4.2.2.6.3.3 ipAddrTable 객체 유형 이름

 IP 주소를 부여할 수 있는 전산망 요소 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 
이때, a.b.c.d("dot" 표기법)는 x에 연관된 ipAdEntAddr 객체 유형의 실상(instance) 값이다.


정의된 이름 n이 ipAddrEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 주소를 부여할 수 있는 전산망요소의 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42 IP 주소에 연관된 IP 인터페이스 테이블에 있는 엔트리의 네크워크 마스크를 찾기를 원한다고 가정하자. 이 경우, ipAdEntNetMask.89.1.1.42는 원하는 실상(instance)을 식별한다.

 

4.2.2.6.3.4 ipRoutingTable 객체 유형 이름

 IP 경로 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 ipRouteDest 객체 유형의 실상(instance) 값이다. 
정의된 이름 n이 ipRoutingEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 경로 정보를 나타내는 이름이다.


예를 들면, 89.1.1.42의 목적지에 연관된 IP 경로설정 테이블에 있는 엔트리의 다음 홉을 찾기를 원한다고 가정하자. 이 경우, ipRouteNextHop.89.1.1.42는 원하는 실상(instance)을 식별한다.

 

4.2.2.6.3.5 tcpConnTable 객체 유형 이름

 TCP 연결 x의 이름은 a.b.c.d.e.f.g.h.i.j 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("do t" 표기법)는 x에 연관된 tcpConnLocalAddress 객체 유형의 실상(instance) 값이다. f.g.h.i는 x 에 연관된 tcpConnRemoteAddress 객체 유형의 실상(instance) 값이다. e는 x에 연관된 tcpConnLocalPort 객체 유형의 실상(instance) 값이다. j는 x에 연관된 tcpConnRemotePort 객체 유형의 실상(instance) 값이다.


정의된 이름 n이 tcpConnEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 TCP 연결 정보를 나타내는 이름이다.


예를 들면, TCP 포트 21 상의 89.1.1.42 지역 주소와 TCP 포트 2059 상의 10.0.0.51 원격 주소 사이의 TCP 연결의 상태를 찾기를 원한다고 가정하자. 이 경우, tcpConnState.89.1.1.42.21.10.0.0.51.2059는 원하는 실상(instance)을 식별한다.

 

4.2.2.6.3.6 egpNeighTable 객체 유형 이름

EGP 이웃 노드 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 egpNeighAddr 객체 유형의 실상(instance) 값이다. 
정의된 이름 n이 egpNeighEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 EGP 이웃 노드의 정보를 나타내는 이름이다.


예를 들면, 89.1.1.42의 IP 주소의 이웃 노드 상태를 찾기를 원한다고 가정하자.

이 경우,egpNeighState.89.1.1.42는 원하는 실상(instance)을 식별한다. 
  

 

4.3 프로토콜 명시

 전산망관리 프로토콜은 관리대리인 MIB의 변수가 관찰되거나 변경될 수 있는 응용 프로토콜 이다. 
프로토콜 실체들 사이의 통신은 메세지의 교환에 의해 이뤄진다. 메세지 각각은 ASN.1의 BER 을 이용하는 하나의 UDP 데이타그램 내에서 완전히 그리고 독립적으로(2.2.2절에서 논의된 것처럼)표현된다.

메세지는 버젼 식별자, SNMP 공동체 이름, 그리고 프로토콜 데이타 단위(PDU)로 구성된다. 프로토콜 엔티티는 트랩을 보고하는 것을 제외하고(즉, Trap-PDU를 포함하는 것을 제외한 모든 메세지) 모든 메세지들에 연관된 그 호스트의 UDP 포트 161에서 메세지를 받는다.


트랩을 보고하는 메세지는 그 이상의 처리를 위해 UDP 포트 162 상에서 받아야한다. 이 프로토콜의 구현은 길이가 484 옥테트 이상인 메세지를 받을 필요는 없다. 그러나, 실행이 가능하다면 좀더 큰 데이타그램을 지원할 수 있도록 구현되는 것을 권고한다.


SNMP의 모든 구현은 다섯가지의 PDU 즉, GetRequest-PDU, GetNextRequest-P여, GetResponse-PDU, SetRequest-PDU, Trap-PDU 를 지원하는 것이 필수 사항이다.

RFC1157-SNMP 정의 ::= 시작

IMPORTS RFC1155-SMI로부터 ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks 를 가져온다.

-- 상위-레벨 메세지

 Message ::= 
SEQUENCE { 
version 
INTEGER { 
version-1(0) 
}, 
community -- 공동체 이름 
OCTET STRING, 
data -- 예를 들면, 단순한 인증이 
ANY -- 사용될 경우 PDU 
  

-- 프로토콜 데이타 단위

 PDUs ::= 
CHOICE { 
get-request 
GetRequest-PDU, 
get-next-request 
GetNextRequest-PDU, 
get-response 
GetResponse-PDU, 
set-request 
SetRequest-PDU, 
trap 
Trap-PDU 
}

-- 데이타 유형에 사용되는 각각의 PDU와 공통적인 PDU는 후에 정의될 것이다. 
  

 

4.3.1 절차 요소

 이 절은 SNMP를 구현하는 프로토콜 엔티티의 행동을 기술한다. 그러나, 이에 준하는 구현의 내부 구조를 제약하지는 않는다. 
다음의 원문에서, 수송계층 주소가 사용된다. UDP의 경우에, 수송계층 주소는 UDP 포트와 함께 IP 주소로 구성된다. 다른 수송계층 서비스는 SNMP를 지원하기 위해 사용될 수 있다. 이런 경우에, 수송계층 주소의 정의가 그것에 준하여 구성되어야 한다. 
메세지를 만들어 내는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) 먼저, ASN.1 객체로 해당 PDU(즉, GetRequest-PDU)를 구성한다.

(2) 다음에, 그의 근원지 주소와 목적지 주소인 공동체 이름과 함께 이 ASN.1 객체 를 원하는 인증 기법을 구현하는 서비스에게 넘겨준다. 이 인증 서비스는 또 다른 ASN.1 객체를 반환한다.

(3) 그 다음에, 프로토콜 엔티티는 공동체 이름과 생성된 ASN.1 객체를 이용하여 ASN.1 메세지 객체를 구성한다.

(4) 이런 새로운 ASN.1 객체는 ASN.1의 BER을 이용하여 연속적으로 나열되어서, 수송계층 서비스를 이용하여 상대방 프로토콜 엔티티로 보내진다. 
  

유사하게, 메세지를 받는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) ASN.1 메세지 객체에 대응하는 ASN.1 객체를 만들기 위해 유입되는 데이타그램의 기본적인 분석을 수행한다. 분석이 실패한다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(2) 그 다음, SNMP 메세지의 버젼 번호를 확인한다. 불일치가 있다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(3) 그 다음으로, 프로토콜 엔티티가 동일한 인증 기법을 사용하는 서비스에게 사용자 데이타와 공동체 이름을 넘겨주는데 이는 데이타그램의 근원지와 목적지 수송계층 주소를 포함하고 있는 ASN.1 메세지 객체에 존재하고 있다.

이 엔티티는 다른 ASN.1 객체를 반환하거나, 인증 실패를 알린다. 후자의 경우에, 프로토콜 엔티티는 트랩을 발생하여 이런 실패를 알리고, 데이타그램을 버린다. 그리고 그 이상의 행동을 수행하지 않는다.

(4) 그리고, 프로토콜 엔티티는 ASN.1 PDU 객체에 대응하는 ASN.1 객체를 만들기 위해 인증 서비스로 부터 반환된 ASN.1 객체에 관한 기본적인 분석을 행한다.

분석이 실패하면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다. 그렇지 않으면, 명명된 SNMP 공동체를 이용하여, 해당 프로화일이 선택되고, PDU가 그것에 따라서 처리된다. 이 처리의 결과로, 메세지가 반환된다면, 응답 메세지의 근원지 수송게층 주소가 원래 요청 메세지가 보내진 목적지 수송계층 주소와 동일해야 한다.

 

4.3.1.1 공통 구문

 프로토콜의 여섯가지 PDU 유형을 소개하기 전에, 자주 사용되는 ASN.1 구문들을 살펴보는 것이 좋다.

 -- 요청/응답 정보

 RequestID ::= 
INTEGER

 ErrorStatus ::= 
INTEGER { 
noError(0), 
tooBig(1), 
noSuchName(2), 
badValue(3), 
readOnly(4), 
genErr(5) 
}

 ErrorIndex ::= 
INTEGER 
  

-- 변수 결합

 VarBind ::= 
SEQUENCE { 
name 
ObjectName, 
value 
ObjectSyntax 
}

 VarBindList ::= 
SEQUENCE OF 
VarBind

 RequestID는 응답을 받지않은 요청들을 구분하기 위해 사용된다. RequestID를 이용하여, SNMP 응용 엔티티는 요청들과 유입되는 응답을 서로 연관시킬 수 있다. 신뢰할 수 없는 데이타 그램 서비스가 사용되고 있는 경우에, RequestID는 또한 전산망에 의해 중복되는 메세지를 식별하는 간단한 수단을 제공한다.


ErrorStatus의 0이 아닌 실상(instance)은 요청이 처리되는 동안 발생된 예외 상황을 알리기 위해 사용된다. 이런 경우에, ErrorIndex는 예외 상황이 발생된 목록에 있는 변수를 알리므로써 추가 정보를 제공할 수 있다.

 변수는 관리 객체의 실상(instance)을 언급한다. 변수 결합 VarBind는 변수와 해당변수 값의 쌍을 언급한다. VarBindList는 변수 명과 대응하는 값의 단순한 목록이다.

몇몇 PDU는 값이 아닌 변수 명에만 관계된다( 예를 들면, GetRequest-PDU ). 이런 경우에, 결합의 값 부분은 프로토콜 엔티티에 의해 무시된다. 그러나, 값 부분은 올바른 ASN.1 구문과 인코딩을 준수해야 한다. 
ASN.1 값 NULL이 그런 결합의 값 부분을 위해 사용되도록 권고된다.

 

4.3.1.2 GetRequest-PDU

 GetRequest-PDU의 형식은 다음과 같다.

 GetRequest-PDU ::= 
[0] 
IMPLICIT SEQUENCE { 
request-id 
RequestID,

 error-status -- 항상 0 
ErrorStatus,

 error-index -- 항상 0 
ErrorIndex,

 variable-bindings 
VarBindList 
}

 GetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다. GetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에 따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름과 정확히 맞지 않는다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체가 복합적인 유형 (SMI에 정의된것처럼)이라면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되었다는 것을 제외하고는, 동일한 형식의 
GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

 선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 명명된 각 객체에 대해,GetResponse-PDU의 대응하는 요소는 그 변수의 이름과 값이 나타낸다.


GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다. 
GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

 

4.3.1.3 GetNextRequest-PDU

 GetNextRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 
동일하다. ASN.1 언어로 다음과 같다.

 GetNextRequest-PDU ::= 
[1] 
IMPLICIT SEQUENCE { 
request-id 
RequestID,

 error-status -- 항상 0 
ErrorStatus,

 error-index -- 항상 0 
ErrorIndex,

 variable-bindings 
VarBindList 
}

 GetNextRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만 
들어진다. 
GetNextRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법 
칙에 따라 응답한다.

(1) variable-bindings 필드에 있는 임의의 객체 이름에 대해, 그 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름에 사전 순으로 선행하지 않으면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) 아래와 같이 기술됨으로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(3) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체에 대한 사전 순으로 다음의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr 이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

 선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 각 이름에 대해, GetResponse-PDU의 대응하는 요소는 그 객체의 이름과 값을 나타낸다.

그 객체의 이름은 그 값에 대한 바로 다음 요소의 이름 필드 값과 더불어, 관련 MIB 영역에서는 get 동작에 이용가능한 모든 객체들의 이름이 사전 순으로 존재한다. GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다. GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

 

 

4.3.1.3.1 테이블 조회의 예

 GetNextRequest-PDU의 한가지 중요한 이용은 MIB 내에 있는 개념적인 정보 테이블의 조회이다. 
MIB에 있는 객체 유형 각각의 실상(instance)을 구별하기 위한 프로토콜에 특이한 메카니즘과 더불어 이런 유형의 SNMP 메세지의 의미는 마치 그것들이 테이블 구성을 하고 있는 것처럼 MIB에 있는 관련 객체에 대한 접근을 제공한다.


아래에 기술된 SNMP 교환에 의해, SNMP 응용 엔티티는 특정 전산망 요소의 경로선택 테이블에 있는 각 엔트리에 대한 목적지 주소와 다음 홉 게이트웨이를 추출한다. 이 경로선택 테이블이 세가지 엔트리를 갖는다고 가정하자.

 목적지 다음 홉 메트릭

 10.0.0.99 89.1.1.42 5 
9.1.2.3 99.0.0.3 3 
10.2.0.0.51 89.1.1.42 5

 관리 스테이션은 요청된 변수 이름으로 지시된 OBJECT IDENTIFIER 값을 포함 하는 GetNextRequest-PDU를 SNMP 수행자에게 보낸다.

 GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

 SNMP 수행자는 GetResponse-PDU로 응답한다.

 GetResponse ((ipRouteDest.9.1.2.3 = "9.1.2.3"), 
(ipRouteNextHop9.1.2.3 = "99.0.0.3"), 
(ipRouteMetric1.9.1.2.3 = 3 ))

 관리 스테이션은 다음과 같이 계속한다.

 GetNextRequest ((ipRouteDest.9.1.2.3, 
ipRouteNextHop9.1.2.3, 
ipRouteMetric1.9.1.2.3)

 SNMP 수행자는 다음과 같이 응답한다.

 GetResponse ((ipRouteDest.10.0.0.51 = "10.0.0.51"), 
(ipRouteNextHop10.0.0.51 = "89.1.1.42"), 
(ipRouteMetric1.10.0.0.51 = 5 ))

 관리 스테이션은 다음과 같이 계속한다.

 GetNextRequest ((ipRouteDest.10.0.0.51, 
ipRouteNextHop.10.0.0.51, 
ipRouteMetric1.10.0.0.51)

 SNMP 수행자는 다음과 같이 응답한다.

 GetResponse ((ipRouteDest.10.0.0.99 = "10.0.0.99"), 
(ipRouteNextHop10.0.0.99 = "89.1.1.42"), 
(ipRouteMetric1.10.0.0.99 = 5 ))

 관리 스테이션은 다음과 같이 계속한다.

 GetNextRequest ((ipRouteDest.10.0.0.99, 
ipRouteNextHop.10.0.0.99, 
ipRouteMetric1.10.0.0.99)

 테이블에 그 이상의 엔트리가 없을 때, SNMP 수행자는 알려진 객체 이름의 사전순으로있는 다음의 객체들을 반환한다. 이 응답은 관리 스테이션에 경로선택 테이블의 끝임을 알린다. 
  

 

4.3.1.4 GetResponse-PDU

 GetResponse-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다. 
ASN.1 언어로 다음과 같다.

 GetResponse-PDU ::= 
[2] 
IMPLICIT SEQUENCE { 
request-id 
RequestID,

 error-status 
ErrorStatus,

 error-index 
ErrorIndex,

 variable-bindings 
VarBindList 

  

GetResponse-PDU는 이 표준의 다른 곳에서 기술된 것처럼 GetRequest-PDU, GetNextRequest-PDU, 또는 SetRequest-PDU를 받자마자 프로토콜 엔티티에 의해 만들어진다. 
GetResponse-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다. 
  

 

4.3.1.5 SetRequest-PDU

 SetRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다. 
ASN.1 언어로 다음과 같다.

 SetRequest-PDU ::= 
[3] 
IMPLICIT SEQUENCE { 
request-id 
RequestID,

 error-status -- 항상 0 
ErrorStatus,

 error-index -- 항상 0 
ErrorIndex,

 variable-bindings 
VarBindList 
}

SetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다. 
SetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 그 객체가 관련 MIB 영역에 있는 set 동작에 이용가능하지 않다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 값 필드의 내용이 ASN.1 언어에 따라 변수에 필요로 되는 것과 일치된 유형, 길이, 그리고 값을 명시하지 않는다면, 수신 엔티티는 error-status 필드의 값이 badValue이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 Get Response 유형 메세지의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 변경될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

 선행하는 법칙들중 적용되는 것이 없다면, 수신 메세지의 variable-bindings 필드에 있는 명명된 각 객체에 대해, 대응하는 값이 변수에 할당된다. SetRequest-PDU에 의해 명시된 각 변수 할당은 마치 동일 메세지에 명시된 모든 다른 할당에 관해 동시에 설정하는 것처럼 되어야 한다.


수신 엔티티는 생성된 메세지의 error-status 필드 값이 noError이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

 

4.3.1.6 Trap-PDU

 Trap-PDU의 형식은 다음과 같다.

 Trap-PDU ::= 
[4] 
IMPLICIT SEQUENCE { 
enterprise -- 트랩을 발생시키는 객체 유형 
  

OBJECT IDENTIFIER, --[5]의 sysObjectID를 참조

 agent-addr -- 트랩을 발생시키는 객체 주소 
NetworkAddress,

 generic-trap -- 일반 트랩 유형 
INTEGER { 
coldStart(0), 
warmStart(1), 
linkDown(2), 
linkUP(3), 
authenticationFailure(4), 
egpNeighborLoss(5), 
enterpriseSpecific(6) 
},

 specific-trap -- 일반-트랩이 enterpriseSpecific이 INTEGER, -- 아니더라도 specific-code는 존재

 time-stamp -- 전산망 엔티티의 마지막 초기화와 
TimeTicks, -- 트랩 생성 사이의 경과된 시간

 variable-bindings -- "관심있는" 정보 
VarBindList 
}

 Trap-PDU는 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 생성된다. SNMP 응용 엔티티가 SNMP 응용 엔티티의 목적지 주소를 선택하는 수단은 구현하기 나름이다. 
Trap-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다 
Trap-PDU의 variable-bindings 요소의 의미는 구현하기 나름이다. 
  

 

4.3.1.6.1 coldStart 트랩

 coldStart(0) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이 
변경될 수 있기 위해 스스로 재초기화하고 있는 것을 알린다.

 

4.3.1.6.2 warmStart 트랩

 warmStart(1) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이 변경되지 않고 스스로 재초기화하고 있는 것을 알린다.

 

4.3.1.6.3 linkDown 트랩

 linkDown(2) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 고장임을 인식하고 알리는 것이다. linkDown 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

 

4.3.1.6.4 linkUp 트랩

 linkUp(3) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 발생하였음을 인식하고 알리는 것이다. linkUp 형태의 Trap-PDU는 variable-bindings의 첫 번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

 

4.3.1.6.5 authenticationFailure 트랩

 authenticationFailure(4) 트랩은 송신 프로토콜 엔티티가 부당하게 인증된 프로토콜 메세지의 주소임을 알린다. SNMP 구현이 이 트랩을 생성할 수 있어야만 하는 반면, 구현에 의존적인 메카니즘을 통한 트랩의 발생을 저지할 수 있어야만 한다.

 

4.3.1.6.6 egpNeighborLoss 트랩

 egpNeighborLoss(5) 트랩은 송신 프로토콜 엔티티가 동위 EGP였던 EGP 이웃 노드가 고장난 것으로 나타나고 더 이상 동위 관계를 얻을 수 없는 것을 알린다.

egpNeighborLoss 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받는 이웃 노드에 대한 egpNeighAddr 실상(instance)의 이름과 값을 포함한다.

 

4.3.1.6.7 enterpriseSpecific 트랩

 enterpriseSpecific(6) 트랩은 송신 프로토콜 엔티티가 어떤 회사에 특정한 사건이 발생했음을 인식하고 알린다. 이 특정 트랩 필드는 발생한 특정 트랩을 식별한다.

 

4.4 정의

 RFC1157-SNMP DEFINITIONS ::= BEGIN

 IMPORTS 
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks 
FROM RFC1155-SMI;

 -- top-level message

 Message ::= 
SEQUENCE { 
version -- 이 RFC의 버젼-1 
INTEGER { 
version-1(0) 
}, 
community 
OCTET STRING, -- 공동체명

 data -- 일상적인 인증이 사용된 
ANY -- PDUs 

  

-- 프로토콜 데이타 단위 
  

PDUs ::= 
CHOICE { 
get-request 
GetRequest-PDU,

 get-next-request 
GetNextRequest-PDU,

 get-response 
GetResponse-PDU,

 set-request 
SetRequest-PDU,

 trap 
Trap-PDU 
}

 -- PDUs

 GetRequest-PDU ::= 
[0] 
IMPLICIT PDU

 GetNextRequest-PDU ::= 
[1] 
IMPLICIT PDU

 GetResponse-PDU ::= 
[2] 
IMPLICIT PDU

 SGetRequest-PDU ::= 
[3] 
  

IMPLICIT 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 

  

Trap-PDU ::= 
[4] 
IMPLICIT SEQUENCE { 
enterprise -- 트랩을 생성하는 객체 유형 
OBJECT IDENTIFIER, -- [5]의 sysObjectID 참조

 agent-addr -- 트랩을 생성하는 객체 주소 
NetworkAddress,

 generic-trap --일반 트랩 유형 
INTEGER { 
coldStart(0), 
warmStart(1), 
linkDown(2), 
linkUp(3), 
authenticationFailure(4), 
egpNeighborLoss(5), 
enterpriseSpecific(6) 
},

 specific-trap 
INTEGER,

 time-stamp 
TimeTicks,

 variable-bindings 
VarBindList 
}

 -- variable bindings

 VarBind ::= 
SEQUENCE { 
name 
ObjectName, 
value 
ObjectSyntax 

VarBindList ::= 
SEQUENCE OF 
VarBind 
END 
  

 

4.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institure, November 1980. 
  

 

제 5 장 TCP/IP 기반 연결망(internets)을 위한 관리 정보의 구조(SMI)

5.1 개요

 관리정보구조 표준은 TCP/IP를 기반으로 하는 연결망(internets)을 관리하는데 사용되는 관리정보의 정의를 위한 공통 구조와 식별 기법을 기술한다. 관리 정보를 기술하기 위한 포괄적 유형의 집합과 전산망 관리를 위한 객체 정보 모델의 기술이 포함된다. 구조의 공식적 기술은 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1)[1]을 사용한다.


이 표준은 조직적인 관계와 행정적 정책에 주로 관여한다. 즉, 관리되는 객체 및 객체를 관리하기 위해 사용하는 프로토콜은 이 표준에서 다루지 않는다. 이런 것들은 두개의 관련 표준에 의해 설명된다.

하나는 관리 정보 베이스(MIB)를 기술한 표준[2]이며, 다른 하나는 단순 전산망 관리 프로토콜(SNMP)을 기술한 표준[3]이다. 
관리정보구조 표준의 목적은 단순성과 확장성을 달성하는 것이다. 이 두 목적은 공통 문제에 의해 동기부여 되었다. 즉, 간단한 SMI를 제안하므로써 앞으로의 잠재적 기법에 부과되는 제약을 최소화한다. 더우기, 확장가능한 SMI를 작성하므로써 가능한한 많은 수의 잠재적 기법이 실험에 이용될 수 있다.


본 관리정보구조 표준과 관련된 문서는 "인터네트(Internet) 전산망 관리 표준의 개발을 위한 IAB 권고안", RFC 1052 [5]와 "전산망 관리 특수(Ad Hoc) 검토 그룹의 두번째 보고", RFC 1109 [6]에서 발표된 지침서 등이 있다. 특히, 우리는 관리 정보 베이스를 기술하는 표준과 더불어 이 표준은 인터네트(Internet)의 전산망 관리를 위한 확고한 기초를 제공한다고 생각한다. 
  

 

5.2 관리 정보의 구조와 식별

 관리 객체(Managed Objects)들은 관리 정보 베이스 또는 MIB로 불리는 가상 정보 저장소를 통해 접근된다. MIB에 있는 객체들은 추상 구문 표기법 1 (ASN.1)을 사용해서 정의된다[1]. 
각 객체의 유형(객체 유형이라 불리우는)은 이름, 구문, 부호를 갖는다. 이름은 OBJECT DENTIFIER로유일하게 표현된다. OBJECT IDENTIFIER는 행정적으로 할당되는 이름이다. 이름을 할당하는데 사용되는관리 방법은 이 표준의 끝부분에서 논의된다.


객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. 예를 들면, 주어진 객 체 유형의 구조는 INTEGER 또는 OCTET STRING일 수 있다. 일반적으로, 객체 유형의 구문을 정의하는데 사용되는 모든 이용가능한 ASN.1 구성요소를 허락할 수 있으나, 이 표준에서는 사용될 수 있는 ASN.1 구성을 의도적으로 제한하고 있다. 이런 제한은 단지 단순성을 지원하기 위한 것이다.


객체 유형의 부호화(encoding)는 단순히 객체 유형 실상(instance)들이 객체 유형 구문을 사용 하여 어떻게 표현되는 가를 의미한다. 객체의 구문과 부호화 개념은 객체가 전산망에서 전송될 때 표현되는 방법을 암시한다. 이 표준은 ASN.1의 BER(Basic Encoding Rules)을 이용하여 명시한다[7].

 

5.2.1 이름

 이름은 관리 객체를 식별하기 위해 사용된다. 이 표준은 이름을 명명할때 계층적인 구조를 명시하고 있다. OBJECT IDENTIFIER 개념은 계층적인 이름을 구현하기 위해 사용된다.

OBJECT IDENTIFIER는 관리 객체 유형을 명명하는 것 이외에 사용될 수도 있다. 예를 들면, 여러 국제 표준안들의 식별을 위해 OBJECT IDENTIFIER를 할당받을 수 있다. 단순히 OBJECT IDENTIFIER는 객체에 연관된 의미(예, 전산망 객체, 표준 문서 등)와는 무관하게 객체를 식별하는 수단이다.


OBJECT IDENTIFIER는 전체 트리를 조회하는 정수들의 나열이다. 이 트리는 에지(edge)를 통해서 여러개의 레이블된 노드와 연결된 루트노드로 구성되었다. 각 노드는 차례로 레이블되는 자신들의 후손노드들을 갖는다. 이 경우에, 그 노드를 서브트리라 한다. 이 과정은 임의의 깊이 수준까지 계속될 수 있다. OBJECT IDENTIFIER 개념의 핵심은 노드들에 할당되는 의미의 관리적 제어가 트리를 조회할 때 위임될 수 있다는 것이다. 레이블은 간단한 문자열과 정수의 쌍이다.


루트 노드 자체는 레이블되지 않지만 바로 세개의 후손노드들을 갖는다: 한 노드는 레이블 iso(1)로서 국제표준화기구에 의해 관리된다. 두번째 노드는 레이블 ccitt(0)로서 국제전신전화자 문위원회에 의해 관리된다. 세번째 노드는 joint-iso-ccitt(2)로서 ISO와 CCITT에 의해 연합 관리된다.


iso(1) 노드 하에 있는 ISO는 다른 국제조직에 의해 사용되는 하나의 서브트리, org(3)를 사용한다. 현재 후손 노드들 중 두개의 노드는 U.S. NIST에 의해 할당된다. 이 서브트리 중 하나 인 dod(6)는 NIST에 의해 미 국방성에게 양도되었다.


현재 이 표준에서, DoD(Department of Defense)는 그의 서브트리를 관리하는 방법을 지시하지는 않는다. 이 표준은 DoD가 다음과 같이 IAB에 의해 관리되기 위해 인터네트 공동체에게 한 노드를 할당할 것으로 가정한다.

 internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

 다시 말해서, OBJECT IDENTIFIER인 인터네트 서브트리는 다음 접두사로 시작한다:

 1.3.6.1.

 IAB에 의해 승인된 표준안으로, 이 표준은 OBJECT IDENTIFIER 서브트리가 관리되는 방법을 명시한다. 
시작 부분에 네개의 노드가 존재한다.

이는 다음과 같다.

 directory OBJECT IDENTIFIER ::= { internet 1 } 
mgmt OBJECT IDENTIFIER ::= { internet 2 } 
experimental OBJECT IDENTIFIER ::= { internet 3 } 
private OBJECT IDENTIFIER ::= { internet 4 } 
  

 

5.2.1.1 디렉토리(Directory)

 서브트리 directory(1)은 OSI 디렉토리가 인터네트에서 어떻게 사용될 수 있는 가를 논의할 표준에 사용된다.

 

5.2.1.2 Mgmt

 서브트리 mgmt(2)는 IAB에서 승인한 문서에 정의된 객체들을 식별하기 위해 사용된다. 
서브트리 mgmt(2)의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에 위임된다. 인터네트 표준 관리 정보 베이스의 새 버젼을 정의하는 RFC들이 승인될 때, 그 문서에 의해 정의된 객체들을 식별하기 위해 IANA가 OBJECT IDENTIFIER를 할당한다.


예를 들면, 초기 인터네트 표준 MIB를 정의하는 RFC는 관리 문서 번호 1이 할당된다. 이 RFC는 인터네트 표준 MIB를 정의하는 OBJECT IDENTIFIER로 { mgmt 1 } 또는 1.3.6.1.2.1 을 사용한다.

 인터네트 표준 MIB의 새 버젼은 정밀한 과정을 거쳐 출현한다. 이 표준의 5절은 새 버젼이 정의될 때 사용되는 법칙들을 기술한다.

 

5.2.1.3 Experimental

 서브트리 experimental(3)은 인터네트 실험에 사용되는 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해서 인터네트의 IANA에게 위임된다. 
예를 들면, 실험자는 번호 17을 받고, 이용가능한 OBJECT IDENTIFIER로 { experimental 17 } 또는 1.3.6.1.3.17 
을 갖는다.

 할당 과정의 부분으로, IANA는 서브트리가 어떻게 사용되는가에 관한 요구조건을 만들 수 있다.

 

5.2.1.4 Private

 서브트리 private(4)는 단독으로 정의된 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에게 위임된다. 처음에, 이 서브트리는 다음과 같이 적어도 하나의 후손을 갖는다.

 enterprises OBJECT IDENTIFIER ::= { private 1 }

 서브트리 enterprises(1)은 전산망 서브시스템을 제공하는 회사들이 그들의 상품 모델을 등록하도록 허락하기 위해 사용된다. 
예를 들면, 기업은 서브트리를 받자마자 이 서브트리에 새로운 MIB 객체들을 정의할 수 있다.


게다가, 관리 프로토콜에 사용될 확실한 식별 메카니즘을 제공하기 위해 기업이 이 서브트리에 그의 네트워킹 서브시스템들을 등록하도록 권고된다. 예를 들면, "Flintstones, Inc." 기업이 전산망 서브시스템을 생산하였다면, 그들은 IANA로 부터의 enterprises 서브트리 하에 노드를 요구할 수 있다. 그런 노드는 다음과 같이 번호가 붙는다.

 1.3.6.1.4.1.42

 "Flintstones, Inc." 기업은 그들의 "Fred Router"를 다음과 같이 등록할 수 있다.

 1.3.6.1.4.1.42.1.1 
  

 

5.2.2 구문

 구문은 객체 유형에 대응하는 구조를 정의하는데 사용된다. ASN.1 조립형은 ASN.1의 완전한 일반성이 허락되지 않을 지라도 이 구조를 정의하기 위해 사용된다. 
ASN.1 유형 ObjectSyntax는 객체 유형을 정의하는데 사용될 수 있는 다른 구문들을 정의한다.

 

5.2.2.1 프리미티브 유형

 ASN.1 프리미티브 유형으로 INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL이 가능하다. 이것들은 단일 유형으로 일컫는다.

 

5.2.2.1.1 열거형 INTEGER에 대한 지침

 열거형 INTEGER가 객체 유형으로 나열된다면, 0의 값이 열거 리스트에 존재해서는 안된다. 
이 값의 사용은 금지되어 있다.

 

5.2.2.2 조립형 유형

 ASN.1 조립형 유형인 SEQUENCE가 테이블이나 리스트를 만들기 위해 사용 가능하다. 
리스트의 구문은 다음과 같은 형태를 취한다:

 SEQUENCE { , ..., }

 각 은 위에서 나열된 ASN.1 프리미티브 유형 중 하나가 된다. 더우기, 이 ASN.1 유형들은 항상 존재한다 (DEFAULT와 OPTIONAL 절은 SEQUENCE 정의에 나타나지 않는다). 
테이블의 구문은 다음과 같은 형태를 취한다.

 SEQUENCE OF 는 리스트 조립형이 된다. 
리스트들과 테이블들은 집합 유형으로 일컫는다.

 

5.2.2.3 정의된 유형

 추가적으로, 응용 분야의 유형이 정의될 수 있다. 그것들은 잠재적으로 정의된 ASN.1 프리미 티브 유형, 리스트, 테이블, 또는 다른 응용 분야에 사용할 수 있는 유형으로 설명된다.

처음에 는, 거의 응용 분야에 사용할 수 있는 유형이 정의되지 않는다. 앞으로의 문서에서는 일단 합의만 되면 다른 것들을 정의할 것이다.

 

5.2.2.3.1 NetworkAddress

 CHOICE는 여러 프로토콜 부류 중 하나인 주소를 표현한다. 현재, 유일한 프로토콜 부류인 인터네트 부류만이 CHOICE에 존재한다.

 

5.2.2.3.2 IpAddress

 이 응용분야의 유형은 32-비트 연결망 주소를 표현한다. 그것은 길이가 4인 OCTET STRING 으로 전산망 바이트 순(network byte-order)으로 표현된다. 
이 ASN.1 유형이 ASN.1 BER을 사용하여 부호화될 때, 프리미티브 부호 형태만이 사용되어야 한다.

 

5.2.2.3.3 Counter

 이 응용 분야의 유형은 최대값이 될 때까지 단조롭게 증가하는 음이 아닌 정수를 표현한다. 
최대값에 이르면 영(0)부터 다시 증가하기 시작한다. 이 문서는 Counter의 최대치로 2^32-1 
(4294967295 십진수)을 명시하고 있다.

 

5.2.2.3.4 Gauge

 이 응용 분야의 유형은 증가하거나 감소할 수 있는 음이 아닌 정수를 표현한다. 그러나 최대 치에서 정지된다. 이 문서는 Gauge의 최대치로 2^32-1 (4294967295 십진수)을 명시하고 있다.

 

5.2.2.3.5 TimeTicks

 이 응용 분야의 유형은 어떤 시기이래로 백분의 1초 단위로 시간을 세는 음이 아닌 정수를 나타낸다.

객체 유형이 이 ASN.1 유형을 사용해서 MIB에 정의될 때 객체 유형은 참조 시기를 식별한다.

 

5.2.2.3.6 Opaque

 이 응용 분야의 유형은 임의의 ASN.1 구문을 통과하기 위한 능력을 지원한다. 값은 ASN.1 BER을 사용하여 옥테트들의 나열로 부호화된다. 차례로, 이것은 OCTET STRING으로 부호화 된다.

실제로, 원래 ASN.1 값을 이중으로 감싸는 것과 같다. 구현시 지킬 것은 단지 불투명하게 부호화된 자료를 받아서 인식하면 된다. 그것은 자료를 복호화할 필요는 없고 내용을 해석하면 된다.


더우기, ASN.1 이외의 부호화는 ASN.1 EXTERNAL 유형을 이용하여, 불투명하게 부호화된 자료에 사용될 수 있다.

 

5.2.3 부호화

 일단 객체 유형의 실상(instance)가 식별되면, 그것의 값은 객체 유형을 위한 구문에 ASN.1 BER을 적용하여 전송될 수 있다. 
  

 

5.3 관리 객체

 MIB 내의 객체들을 정의하는 것이 본 표준의 목적이 아니라, 이 표준은 이런 객체들을 정의하는 다른 표준들에 의해 사용되는 형식을 명시한다. 
객체 유형 정의는 다섯개의 필드로 구성된다.

 객체(OBJECT): 
객체 기술자(OBJECT DESCRIPTOR)라 불리는 객체 유형의 문자열과 이에 대응하는 OBJECT IDENTIFIER

 구문(SYNTAX): 
객체 유형의 추상 구문. 
이것은 ASN.1 유형 ObjectSyntax의 실상(instance)가 되어야 한다.

 정의(Definition): 
객체 유형의 의미를 나타내는 설명을 기술.

 이 MIB는 많은 기업체의 제품이 운영되는 환경에서 사용되므로 구현은 객체의 실상(instance)이 이 정의를 이행하는 것을 보장해야 한다. 그와 같이 객체들 이 모든 장비에서 일관된 의미를 갖는 것은 중요하다.

 접근(Access): 
읽기전용, 읽기쓰기, 쓰기전용, 또는 접근금지 중 하나

 상태(Status): 
필수사항, 선택사항, 폐지사항 중 하나

 앞으로의 표준은 그들이 정의한 객체들의 다른 필드를 역시 명시할 수 있다.

 

5.3.1 객체 이름에 대한 지침

 인터네트 표준 MIB의 객체 유형은 이름 내에 부식별자 0을 사용해서는 안된다. 이 값은 앞으로의 확장을 위해 예약된다. 
인터네트 표준 MIB에 있는 객체 유형에 대응하는 각 객체 기술자는 유일하면서 기억하기 쉬운 인쇄 가능한 스트링이어야 한다. 이것은 사람들이 MIB를 논의할 때 사용하기 위한 공통 언어를 장려하고 사용자 인터페이스를 위해 간단한 테이블 매핑을 돕는다.

 

5.3.2 객체 유형과 실상(instance)

 객체 유형은 관리 객체 정의이다. 실제로 그것은 선언이다. 이와 대조적으로, 객체 실상 (instance)은 객체 유형이 값을 갖게되는 것 즉, 객체 유형의 실상(instance)이다. 예를 들면, 경로설정 테이블에 존재하는 엔트리 개념은 MIB에 정의되어야 한다. 그런 개념은 객체 유형에 해당한다

그러나,어느순간에 존재하는 특정 경로설정 테이블의 각각의 엔트리들은

그객체유형의객체실상(instance)이다. 
객체 유형의 집합은 MIB에 정의된다. 각각의 객체 유형은 객체 식별자로 유일하게 명명되고, 그것의 객체 기술자인 이름을 갖는다. 객체 실상(instance)들이 참조되는 수단은 MIB에 정의되지 않는다. 객체실상(instance)들에 대한 참조는 프로토콜 특정 메카니즘에 의한다.

즉, 그것은 이 메카니즘을 정의하는 SMI를 준수하는 각 관리 프로토콜의 책임이다. 
객체 유형의 실상(instance)이 "하위" 객체 유형의 실상(instance)에 의해 표현되는 정보의 집합을 나타내는 MIB에 객체 유형이 정의될 수 있다.

 예를 들면, 다음의 객체 유형들이 MIB에 정의된다고 가정해보자:

객체: 
atIndex { atEntry 1 }

구문: 
INTEGER

정의: 
실제 주소에 관한 인터페이스 번호

접근: 
읽기쓰기

상태: 
필수사항 
  

객체: 
atPhysAddress { atEntry 2 }

구문: 
OCTET STRING

정의: 
매체 의존적인 실제 주소

접근: 
읽기쓰기

상태: 
필수사항

객체: 
atNetAddress { atEntry 3 }

구문: 
NetworkAddress

정의: 
매체 의존적인 실제 주소에 대응하는 전산망 주소

접근: 
읽기쓰기

상태: 
필수사항 
  

그러면, 네번째 객체 유형은 또한 MIB에 정의된다.

객체: 
atEntry { atTable 1 }

구문: 
AtEntry ::= SEQUENCE { 
atIndex 
INTEGER, 
atPhysAddress 
OCTET STRING, 
atNetAddress 
NetworkAddress 
}

정의: 
주소 번역 테이블의 엔트리

접근: 
읽기쓰기

상태: 
필수사항

 이 객체 유형의 각 실상(instance)은 이전의 세 객체 유형의 실상(instance)에 의해 표현되는 정보를 포함한다. 이런 방식으로 정의된 객체 유형을 리스트라 한다. 
유사하게, 테이블은 리스트 유형의 집합에 의해 형성될 수 있다. 예를 들면, 다섯번째 객체 유형은 MIB에 정의된다. 
  

객체: 
atTable { at 1 }

구문: 
SEQUENCE OF AtEntry

정의: 
주소 번역 테이블

접근: 
읽기쓰기

상태: 
필수사항 
  

atTable 객체의 각 실상(instance)은 주어진 atTable 객체 실상(instance) 즉, 주어진 주소 번역 테이블을 구성하는 atEntry 객체 유형의 집합에 의해 표현되는 정보를 포함한다. 
테이블 내의 간단한 객체를 어떻게 참조하는지 고려해보자. 이전의 예제에서, 연속해서 객체 유형

{ atPhysAddress } 를 명명하고 프로토콜 특정 메카니즘을 이용하여 객체 실상(instance)

 { atNetAddress } = { internet "10.0.0.52" } 
을 명시한다.

 이 객체 유형과 객체 실상(instance)의 쌍은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 주소 번역 테이블에 있는 엔트리 부분인 atPhysAddress의 모든 실상(instance)을 참조한다.

 이 예제에 계속해서, 테이블 내의 집합 객체를 어떻게 참조하는지 고려해보자. 
객체 유형 
{ atEntry } 
을 명명하고, 특정 프로토콜 메카니즘을 사용하여 객체 실상(instance)

 { atNetAddress } = { internet "10.0.0.52" }

을 명시하는 것은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 테이블에 있는 엔트리들 의 모든 실상(instance)을 참조한다.

 각 관리 프로토콜은 단순한 객체 유형에 접근하는 메카니즘을 제공해야 한다. 각 관리 프로토콜은 집합 객체 유형에 대한 접근을 지원하는 지를 명시한다. 더우기, 프로토콜은 객체 유형과 실상(instance) 쌍이 하나의 유형에 대한 여러개의 실상(instance)을 참조할 때 "반환되는" 실상 (instance)들을 명시해야 한다.

 다양한 관리 프로토콜에 대한 지원을 제공하기 위해, 주어진 객체 유형의 실상(instance)들을 훌륭히 식별시킬 수 있는 정보는 MIB에 정의된 객체 유형의 실상(instance)들에 의해 표현된다.

 

5.3.3 관리 객체를 위한 매크로

 MIB 정의를 처리하는 도구의 이용을 손쉽게 하기 위해 객체-유형 매크로가 사용될 수 있다. 
이 매크로는 객체 유형의 중요한 점들이 형식적인 방법으로 표현되도록 한다.

 객체-유형 매크로 ::= 
시작 
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax) 
"접근" 접근 
"상태" 상태 
값 표기 ::= 값 (값 ObjectName)

 접근 ::= "읽기전용" 
| "읽기쓰기" 
| "쓰기전용" 
| "접근금지" 
상태 ::= "필수사항" 
| "선택사항" 
| "폐지사항"

 끝

 처음에 정의된 객체 유형이 주어진다면, 우리는 MIB에 존재하는 다음의 정의들을 상상할 수 있다.

 atIndex 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
::= { atEntry 1 }

 atPhysAddress 객체-유형 
구문 OCTET STRING 
접근 읽기쓰기 
상태 필수사항 
::= { atEntry 2 }

 atNetAddress 객체-유형 
구문 NetworkAddress 
접근 읽기쓰기 
상태 필수사항 
::= { atEntry 3 }

 atEntry 객체-유형 
구문 AtEntry 
접근 읽기쓰기 
상태 필수사항 
::= { atTable 1 }

 atTable 객체-유형 
구문 SEQUENCE OF AtEntry 
접근 읽기쓰기 
상태 필수사항 
::= { at 1 }

 AtEntry ::= 객체-유형 { 
atIndex 
INTEGER, 
atPhysAddress 
OCTET STRING, 
atNetAddress 
NetworkAddress 

  

처음의 다섯가지 정의는 예를 들어, 객체 기술자 atIndex에 관계된 객체 식별자 { atEntry 1 } 객체 유형을 기술한다. 게다가, 이 객체의 구문은 가능한 접근 (읽기쓰기)과 상태 (필수사항) 와 (INTEGER)로 정의된다. 여섯번째 정의는 AtEntry라 불리는 ASN.1 유형을 기술한다. 
  

 

5.4 MIB 확장

 모든 인터네트 표준 MIB 문서는 이전의 문서를 폐지시킨다.

 객체 식별자

 { mgmt version-number }

 다음에 나오는 객체를 명명하기 위해 사용되는 꼬리라 불리는 이름 부분은 버젼들 간에 바뀌어서는 안된다. 새로운 버젼은

(1) 구식 객체 유형을 폐지로 선언하지만 그들의 이름은 제거하지 않는다. 

(2) 리스트 내에 있는 객체 유형에 단순 유형이 추가되면서 리스트에 대응하는 객체 유형의 정의를 확장한다. 또는, 

(3) 완전히 새로운 객체 유형을 정의한다.

새로운 버젼들은 (1) 그 객체 이름을 바꾸지 않고 이전에 정의된 객체의 의미를 바꿀 수 없다.

 이런 법칙들은 그들이 인터네트 표준 MIB의 많은 버젼들에 대한 좀 더 용이한 지원을 허용하므로 중요 하다. 특히, 이름의 꼬리에 연관된 의미는 MIB의 다른 버젼들을 통해 일정하게 남는다.

MIB의 많은 버젼들은 "꼬리 공간"에서 동시에 일어날 수 있으므로 MIB의 다양한 버젼을 지원하는 구현은 단순화될 수 있다. 
그러나, 결과적으로 관리 수행자는 예상되는 객체 유형의 모집합에 대응하는 실상(instance)을 반환한다.

이런 예외적인 경우에, 확고한 원칙에 따라, 관리자는 예상되는 객체 유형의 정의를 넘어선 어떤 추가적인 정보를 무시해야 한다. 그러나, 확고한 원칙은 제어 행위에 관한 실행 보호 조치가 필요하다. 

즉, 실상(instance)이 그의 예측된 객체 유형과 같은 구문을 갖지 않는다면, 그런 제어 행동은 실행되지 않아야 한다. 감시와 제어의 경우, 동작에 의해 반환되는 객체의 이름은 동작에 의해 요구된 이름과 같아야 한다. 
  

 

5.5 정의

RFC1155-SMI 정의 ::= 시작

EXPORTS -- 모든 것 
internet, directory, mgmt, experimental, private, enterprises, 
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,

 ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, 
TimeTicks, Opaque;

-- 루트로 부터의 경로

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 } 
  

-- 객체 유형의 정의

 객체-유형 매크로 ::= 시작 
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax) 
"접근" 접근 
"상태" 상태 
값 표기 ::= 값 (값 ObjectName)

 접근 ::= "읽기전용" 
| "읽기쓰기" 
| "쓰기전용" 
| "접근금지" 
상태 ::= "필수사항" 
| "선택사항" 
| "폐지사항" 
  

끝 
  

-- MIB 내의 객체 이름

ObjectName ::= 
OBJECT IDENTIFIER

-- MIB 내의 객체 구문

ObjectSyntax ::= 
CHOICE { 
simple 
SimpleSyntax,

-- 간단한 SEQUENCE는 단순성을 유지하기 위해 여기에서 직접 언급되지 않았다. 
그러나, 간단한 SEQUENCE로 암시적으로 부호화되는 응용 분야에 사용할 수 있는 유형은 다음의 CHOICE에 나타날 수 있다.

 application-wide 
ApplicationSyntax 
}

SimpleSyntax ::= 
CHOICE { 
number 
INTEGER, 
string 
OCTET STRING, 
object 
OBJECT IDENTIFIER, 
empty 
NULL 
}

ApplicationSyntax ::= 
CHOICE { 
address 
NetworkAddress, 
counter 
Counter, 
gauge 
Gauge, 
ticks 
TimeTicks, 
arbitrary 
Opaque

-- 그들이 정의된 것처럼, 다른 응용 분야에 사용할 수 있는 유형은 여기에 추가 될 수있다 

  

NetworkAddress ::= 
CHOICE { 
internet 
IpAddress 
}

IpAddress ::= 
[APPLICATION 0] -- 전산망-바이트 순으로 
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] -- 임의의 ASN.1 값, 
IMPLICIT OCTET STRING -- "이중-봉쇄"

끝 
  

 

5.6 참고 문헌

[1] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[2] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer 
Science, May 1990.

[4] LaBarre, L., "Structure and Identification of Management Information for the Internet", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, April 1988.

[5] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[6] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[7] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987. 
  

 

제 6 장 TCP/IP 기반 연결망의 전산망관리를 위한 관리 정보 베이스 (MIB-II) 

6.1 개요

 이 표준은 TCP/IP를 기반으로 하는 연결망(internets)의 전산망 관리 프로토콜을 이용한 관리 정보 베이스의 두번째 버젼을 정의한다. 
단기적으로 간단하게 운용할 수 있는 시스템들을 만들기 위한 IAB 전략과 일치하여 여기에서 정의된 관리 객체들의 리스트는 필수적으로 고려되는 요소들만을 채택하는 것으로 유래되었다.


필수적인 객체들만을 채택하는 방법은 제한하지 않는다. 왜냐하면, 관련 문서에 정의된 SMI는 세 개의 확장 메카니즘을 제공하기 때문이다.

첫째, MIB의 새로운 버전 정의를 통한 새로운 표준 객체들의 추가 이다.

둘째, 실험 서브트리를 통하여 다방면에 이용가능하지만 비표준인 객체들의 추가이다.

셋째, 기업 서브트리를 통한 사적인 객체들의 추가이다. 추가된 그런 객체들은 특정 업체의 요소들 뿐아니라 다른객체들에 필수적인 지식에 요구되는 실험에도 사용될 수 있다. 
MIB-II의 설계는 첫번째 확장 메카니즘에 의해 많은 영향을 받았다. 여러 새로운 변수들은 운 
영 경험과 요구사항들을 기반으로 추가되었다. 이런 것을 기반으로, MIB-II에 있는 객체들을 
포함하는 기준은 MIB-I의 기준과 매우 유사하다.

즉, 다음과 같다.

(1) 장애 또는 구성 관리에 필수적으로 요구되는 객체

(2) 약한 제어 객체들만이 허락된다(강력하지 못하므로, 그것들을 간섭하는 것은 단지 손상을 제한할 수 있다는 것을 의미한다). 이런 기준은 현재 관리 프로토콜들이 좀 더 강력한 제어 동작들을 수행할 정도로 안전하지 않다는 사실을 반영 한다.

(3) 현재 사용과 유용성의 확증이 요구된다.

(4) MIB-I에서는, 업체들이 그들의 소프트웨어를 적어도 기기에 설치하기 쉽도록 하기 위해 객체 수를 약 100 정도로 제한하였다. MIB-II에서는, MIB-I을 구현하는 다양한 기술적 기반으로 이런 제한이 향상되었다.

(5) 중복 변수를 피하기 위해, MIB에 있는 다른 변수들에서 유도될 수 있는 것이 포함되는 객체가 없도록 요구했다.

(6) 특정 구현 객체들은 배제된다.( 예를 들면, BSD UNIX )

(7) 코드의 기준 절들을 설치하는 것을 피하는데 합의되었다. 일반적인 지침은 계층 당 기준 절에 하나의 카운터이다.

이전의 버전인 인터네트 표준 MIB처럼 MIB-II는 필수적인 요소들만을 포함한다. 
각각의 객체들이 선택사항이 될 필요는 없다. 오히려, 객체들은 다음 그룹들로 배열된다.

- 시스템 
- 인터페이스 
- 주소변환(삭제대상) 
- IP 
- ICMP 
- TCP 
- UDP 
- EGP 
- 전송 
- SNMP

 이런 그룹들은 적합성의 기본 단위이다. 즉, 방법은 다음과 같다. 어떤 그룹의 의미가 구현에 응용가능하다면, 그 그룹에 있는 모든 객체들을 구현해야 한다. 예를 들면, EGP를 구현할 때만 EGP 그룹을 구현해야 한다.


이런 그룹들을 정의하는 데는 두가지 이유가 있다. 첫째, 객체 구별자를 할당하는 수단을 제공하기 위해서이다. 둘째는, 그들이 어떤 객체들을 구현할 것인가를 알려고 하는 관리 수행자들의 구현을 위한 방법을 제공하기 위해서이다. 
  

 

6.2 RFC 1156으로부터의 변화

 이 MIB의 특성은 다음을 포함한다.

 (1) 새로운 운영가능한 요구조건을 반영하기 위한 추가사항

 (2) SMI/MIB와 SNMP와의 향상된 호환성

 (3) 다양한 프로토콜 엔티티를 위한 개선된 지원

 (4) 명확성과 판독성을 개선하기 위한 MIB 원문의 정리

 MIB-II에 정의된 객체들은 다음과 같이 MIB-I에서 사용된 접두사와 같은 OBJECT IDENTIFIER 접두사를 갖는다.

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

 

6.2.1 삭제 대상 객체

 구현자가 MIB 내의 앞으로의 변화를 준비하기 위해, 새로운 용어 "삭제대상"은 객체를 기술할 때 사용 될 수 있다. MIB에 있는 "삭제대상" 객체는 지원되어야 하지만 MIB의 새 버젼(예를 들면, MIB-III)에서는 거의 제거될 것이다. 
MIB-II는 삭제대상으로 다음 객체를 명시한다.

 atTable

 atTable 객체를 삭제대상으로 하는 결과로써, 전체 주소 변환 그룹은 삭제대상이 된다. 
이런 객체들의 삭제로 상실되는 기능은 없다. 다시 말해서 동등하거나 그 이상의 기능을 제공하는 새로운 객체들이 MIB-II에 정의된다.

 

6.2.2 출력 문자열

 MIB 규정에 의해 다음과 같은 데이타 유형이 소개되고 있다.

 DisplayString ::= 
OCTET STRING

 DisplayString은 [6]의 10쪽에서 11쪽에 정의된 NVT ASCII 문자 집합으로 제한된다. 
다음 객체들은 DisplayString에 의해 정의된다.

 sysDescr 
ifDescr

 이런 변화는 이 객체들의 구문이나 의미에 영향을 주지 않는다. DisplayString 표기의 사용은 MIB-II와 미래의 MIB에 사용되는 해석 방법상의 인공물일 뿐이다. 
더우기 OCTET STRING에 의해 정의된 객체는 임의의 이진 자료를 포함하고, 각 옥테트는 0에서255(십진수)사이의 값을 갖는다.

 

6.2.3 물리적 주소

 MIB 내에는 그 밖의 문서적 규정으로서,

 PhysAddress ::= 
OCTET STRING

과 같은 데이타 유형이 매체- 또는 물리-계층 주소들을 표현하기 위해서 소개되고 있다. 
다음의 객체들은 PhysAddress에 의해 정의된다.

 ifPhysAddress 
atPhysAddress 
ipNetToMediaPhysAddress

 이런 변화는 객체의 구문이나 의미에 영향을 주지 않는다. PhysAddress 표기의 사용은 단지 MIB-II와 미래의 MIB에 사용되는 해석 방법의 인공물일 뿐이다.

 

6.2.4 시스템 그룹

 네개의 새로운 객체들이 이 그룹에 추가된다.

 sysContact 
sysName 
sysLocation 
sysServices

 이것들은 피관리 노드에 관한 접촉, 관리, 위치, 서비스 정보를 제공한다.

 

6.2.5 인터페이스 그룹

 IP를 지원하기 위한 모든 인터페이스들을 필요로 할 때, ifNumber 객체의 정의는 잘못되었다. (예를 들면, 이 정의가 엄격하게 준수될 경우 MAC-계층 브리지와 같이 IP계층이 없는 장치들은 관리될 수 없다.) 따라서 ifNumber 객체의 기술은 바뀐다.


ifTable 객체는 읽기쓰기로 잘못 명시되었다. 그것은 접근금지로 올바르게 재설정되었다. 추가 로, 여러 새로운 값들이 ifTable 객체의 ifType 란에 추가되었다.

 ppp(23) 
softwareLoopback(24) 
eon(25) 
ethernet-3Mbit(26) 
nsip(27) 
slip(28) 
ultra(29) 
ds3(30) 
sip(31) 
frame-relay(32)

 마지막으로, 다음과 같이 새로운 란이 ifTable 객체에 추가되었다.

 ifSpecific

 이것은 인터페이스를 실현하기 위해 사용되는 매체 특유의 정보에 관한 정보를 제공한다.

 

6.2.6 주소 변환 그룹

 MIB-I에서 이 그룹은 전산망 주소(예를 들면, IP 주소)에서 물리적 주소(예를 들면, MAC 주소)로의 사상을 가능하게 하는 테이블을 포함했다. 이 테이블의 효율적인 구현은 두가지를 가정한다. 하나의 전산망 프로토콜 환경과 전산망 주소에서 물리적 주소로의 사상만 일어난다.

다양한 프로토콜 노드들을 지원하기 위한 요구(예를 들면, IP와 CLNP가 모두 살아있는 것 등을)와 역사상을 지원하기 위한 요구(예를 들면, ES-IS)는 이런 가정 모두를 무효화했다. 따라서, atTable 객체는 삭제대상으로 선언된다.


다양한 프로토콜과 역 사상 요구조건을 만족시키기 위해 MIB-II와 이것의 후속 문서들은 각 전산망 프로토콜 그룹 내의 두 주소 변환 테이블까지 할당할 것이다. 다시 말해서, IP 그룹은 IP 주소에서 물리적 주소로 가기 때문에 하나의 주소 변환 테이블을 포함할 것이다. 유사하게, CLNP를 위한 MIB 객체들을 정의하는 문서를 만들 때(예를 들면, [7]), 이것은 완전한 기능을 필요로 하기 때문에 양 방향으로의 사상을 위해 두개의 테이블을 포함할 것이다.


양 방향의 사상을 위해 두 테이블을 선택하는 것은 여러 가지로 구현에 편의를 제공하고 하나 의 내부 테이블을 통해 주소 변환 추상화를 실현하는 구현상의 부담이 없어진다.

 

6.2.7 IP 그룹

 변수 ipForwarding의 접근 속성은 읽기전용에서 읽기쓰기로 바뀌었다. 
특정 인터페이스 상에서 재결합될 수 있는 가장 큰 IP 데이타그램을 기억하는 ipAdEntReasmMaxSize 
라는 새로운 열이 ipAddrTable 객체에 추가된다. 
ipRoutingTable 객체의 기술자는 다른 IP 경로설정 객체들과의 일관성을 위해 ipRouteTable로 바뀌었다. 
또한 ipRouteTable 객체에는 세개의 새로운 열이 있다.

 ipRouteMask 
ipRouteMetric5 
ipRouteInfo

 첫번째 것은 임의의 서브네트 마스크를 지원하는 IP 경로설정 서브시스템들을 위해 사용된다. 
나머지 둘은 IP 경로설정 프로토콜에 특유한 것이다. 
IP 그룹에 추가되는 두개의 새로운 객체는 다음과 같다.

 ipNetToMediaTable 
ipRoutingDiscards

 첫번째 객체는 IP 그룹을 위한 주소 변환 테이블이다(주소 해석 그룹의 삭제대상 atTable과동일한 기능을 제공하는 것이다). 두번째 객체는 경로설정 정보가 버퍼 공간의 부족으로 상실될 때, 정보를 제공한다.

 

6.2.8 ICMP 그룹

 이 그룹에는 변화가 없다.

 

6.2.9 TCP 그룹

 두개의 새로운 변수가 추가된다.

 tcpInErrs 
tcpOutRsts

 위 변수들은 오류로 수신된 TCP 세그먼트 수와 TCP에 의해 생성된 복귀 수를 기억한다.

 

6.2.10 UDP 그룹

 새로운 테이블,

 udpTable

 이 추가된다.

 

6.2.11 EGP 그룹

 EGP 감시에 유용한 객체들의 추가가 필요하다. egpNeighborTable 객체는 다음과 같다. 
egpNeighAs 
egpNeighInMsgs 
egpNeighInErrs 
egpNeighOutMsgs 
egpNeighOutErrs 
egpNeighInErrMsgs 
egpNeighOutErrMsgs 
egpNeighStateUps 
egpNeighStateDowns 
egpNeighIntervalHello 
egpNeighIntervalPoll 
egpNeighMode 
egpNeighEventTrigger

 위 객체에 추가로, EGP 엔티티에 연관된 독립적 시스템에 주는 egpAs 라는 새로운 변수가 추가된다.

 

6.2.12 전송 그룹

 MIB-I은 전송 매체의 다른 유형들을 구별하지 않았다. 새로운 그룹인 전송 그룹은 이 목적을 위해 할당된다.

transmission OBJECT IDENTIFIER ::= { mib-2 10 } 
  

전송 매체를 관리하는 인터네트 표준 정의들이 정의될 때, 전송 그룹은 그 객체들의 이름에 접두사를 제공하기 위해 사용된다. 
실제로, 그런 정의들은 "입증"될 때까지 MIB의 실험 부분에 존재하다가 인터네트 표준화 과정 의 부분으로써, 그 정의가 적절히 향상되어서, 전송 그룹하에 새로운 객체 식별자가 정의된다. 
규정에 따라 할당되는 이름은 다음과 같다.

 type OBJECT IDENTIFIER ::= { transmission number }

 "type"은 ifTable 객체의 ifType 란에 있는 매체에 사용된 기호 값이다. "number"는 기호에 대응하는 실제 정수 값이다.

 

6.2.13 SNMP 그룹

 IETF의 응용 지향적 연구 그룹은 그들 각각의 응용에 특유한 MIB 변수들을 정의하여 잘 받 아들이도록 작업해오고 있다.

 SNMP의 경우, 통계적인 정보를 갖는데 유용하다. 새로운 그룹인 SNMP 그룹은 이 목적을 위해 할당된다.

 snmp OBJECT IDENTIFIER ::= { mib-2 11 } 
  

 

6.2.14 RFC 1158로 부터의 변화

 이 MIB의 특성은 다음을 포함한다.

 (1) 이 표준에 있는 관리 객체는 [14]에 명시된 확장에 의해 개선된 인터네트 표준 SMI에 정의된 규정을 이용해서 정의되었다. 이런 확장을 이용해서 만들어진 정의는 RFC 1158의 것과 의미상으로 동일하다는 것이 강조되었다.

 (2) PhysAddress 원문 표기는 매체 주소를 표현하기 위해 소개되었다.

 (3) sysLocation의 접근 절은 읽기쓰기이다.

 (4) sysServices의 정의가 명백해졌다.

 (5) 새로운 ifType 값(29-32)이 정의되었다. 게다가, DS1과 E1 인터페이스 유형을 위한 본문의 기술자가 교정되었다.

 (6) ipForwarding 정의가 명백해졌다.

 (7) ipRouteType 정의가 명백해졌다.

 (8) ipRouteMetric5와 ipRouteInfo 객체가 정의되었다.

 (9) tcpConnState의 접근 절은 TCP 연결과 관련된 TCP의 제거를 제공하기 위한 읽기 쓰기이다. 이 객체의 정의는 용도를 설명하기 위해 명백해졌다.

 (10) egpNeighEventTrigger 정의가 명백해졌다.

 (11) 새로운 snmp 그룹에 있는 여러 변수의 정의가 명백해졌다. 게다가, snmpInBadTypes와 snmpOutReadOnlys 객체는 더 이상 존재하지 않는다. (그러나 객체에 관련된 객체 구별자들은 사용을 금지하도록 예약되었다.)

 (12) snmpInReadOnlys 정의가 명백해졌다.

 (13) snmpEnableAuthTraps의 본문 기술자는 snmpEnableAuthenTraps으로 바뀌었고, 정의가 명백해졌다.

 (14) ipRoutingDiscards 객체가 추가되었다.

 (15) IP 주소와 경로설정 테이블의 실체를 구별할 때 구현에 따른 작은 양수의 선택 적 사용은 금지되었다. 
  

 

6.3 관리 객체

 관리 객체들은 관리 정보 베이스 또는 MIB라 불리는 가상 정보 저장소를 통해 접근된다. 
MIB에 있는 객체들은 SMI에 정의된 추상 구문 표기법 1(ASN.1)의 부분집합을 이용해서 정의 된다. 특히, 각 객체는 이름, 구문, 부호를 갖는다. 이름은 객체 유형을 명시하는 객체 식별자로 행정적으로 할당되는 이름이다. 객체 실체와 함께 객체 유형은 객체의 특정 실체를 유일하게 구분한다. 인간의 편의를 위해, 우리는 객체 유형을 참조하기 위한 객체 기술자라고 하는 문서상의 문자열을 이용한다.


객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. ASN.1 언어는 이런 목적을 위해 사용된다. 그러나, SMI는 주로 사용될 ASN.1 구문들을 제한한다. 이런 제한은 단순성을 위해 명확하게 만들어진다.


객체 유형의 부호화은 객체 유형이 객체 유형의 구문을 사용해서 어떻게 표현되는가를 나타낸다. 객체 유형의 구문과 부호화 개념의 결합은 암시적으로 전산망로 전송될 때 객체 유형이 어떻게 표현되는 가를 보이는 것이다. 
SMI는 SNMP에 의해 부과된 추가적인 요구조건에 의한 ASN.1 BER의 이용을 명시한다.

 

6.3.1 정의 형식

 4절은 이 MIB 모듈에 포함된 모든 객체 유형의 명시를 포함한다. 객체 유형은 [14]에 명시된 
확장들에 의해 개선된 SMI에 정의된 규정들을 이용해서 정의된다. 
  

 

6.4 정의

 RFC1213-MIB 정의 ::= 시작

 IMPORTS 
mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks 
FROM RFC1155-SMI 
OBJECT-TYPE 
FROM RFC-1212; 
-- 이 MIB 모듈은 [14]에 정의된 것으로 확장된 OBJECT-TYPE 매크로를 사용한다.

 -- MIB-II ( MIB-I과 같은 접두사 )

 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

 

6.4.1 본문의 관례적 표기

 DisplayString ::= 
OCTET STRING

 -- 이 데이타 유형은 NVT ASCII 문자 집합에서 채택된 정보를 구현하기 위해 사용된다. 관례에 따라, 이런 구문으로 된 객체들은 SIZE (0..255)로 선언된다.

 PhysAddress ::= 
OCTET STRING

 -- 이 데이타 유형은 매체 주소를 모델화하기 위해 사용된다. 여러 매체 유형을 위해, 이것은 이진 표현일 것이다. 예를 들면, ethernet 주소는 6 옥테트 문자열로 표현된다.

 

6.4.2 MIB-II에서의 그룹

 system OBJECT IDENTIFIER ::= { mib-2 1 } 
interface 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 }

 -- 과거를 반영(히스테리적이라고도 한다) 
-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

 transmission OBJECT IDENTIFIER ::= { mib-2 10 } 
snmp OBJECT IDENTIFIER ::= { mib-2 11 }

 

6.4.3 시스템 그룹

 -- 시스템 그룹의 구현은 모든 시스템을 위한 필수사항이다. 수행자가 이 변수들 중 임의의 값을 갖지 않는다면, 길이가 0인 문자열이 반환된다.

 sysDescr 객체-유형 
구문 DisplayString(SIZE (0..255)) 
접근 읽기전용 
상태 필수사항 
기술 "엔티티의 설명. 이 값은 시스템의 하드웨어 유형, 소프트웨어 운영 유형, 그리고 네트워킹 소프트웨어의 고유명과 버젼 구별을 포함하여 야 한다. 이것이 인쇄가능한 ASCII 문자를 포함할 때만 필수사항이 다." 
::= { system 1 }

 sysObjectID 객체-유형 
구문 OBJECT IDENTIFIER 
접근 읽기전용 
상태 필수사항 
기술 "엔티티에 포함되는 전산망 관리 서브시스템 제공자의 권한 구별.
이 값은 SMI enterprises 서브트리 (1.3.6.1.4.1) 내에 할당되어 관리되고 있는 '종류'를 결정하기 용이하고 분명한 수단을 제공한다. 
예를 들면, 'Flintstones, Inc' 기업이 서브트리 1.3.6.1.4.1.4242로 할당되었다면, 그 기업의 'Fred Router'에는 식별자 1.3.5.1.4.1.4242.1.1을 할당한다." 
::= { system 2 }

 sysUpTime 객체-유형 
구문 TimeTicks 
접근 읽기전용 
상태 필수사항 
기술 "시스템의 전산망 관리 부분이 마지막으로 재초기화된 이후의 시간 
(1/100 초 단위)." 
::= { system 3 }

 sysContact 객체-유형 
구문 DisplayString(SIZE (0..255)) 
접근 읽기쓰기 
상태 필수사항 
기술 "이 피관리 노드를 위해 접촉할 사람의 구별과 이 사람과 접촉하는 방법에 관한 정보." 
::= { system 4 }

 sysName 객체-유형 
구문 DisplayString(SIZE (0..255)) 
접근 읽기쓰기 
상태 필수사항 
기술 "이 피관리 노드를 위해 행정적으로 할당된 이름. 규정에 의해, 이것은 그 노드의 완전히 승인된 영역명이다.". 
::= { system 5}

 sysLocation 객체-유형 
구문 DisplayString(SIZE (0..255)) 
접근 읽기쓰기 
상태 필수사항 
기술 "이 노드의 물리적인 위치(예를 들면, 3층 전화가 있는 방)" 
::= { system 6 }

 sysServices 객체-유형 
구문 INTEGER (0..127) 
접근 읽기전용 
상태 필수사항 
기술 "이 엔티티가 주로 제공하는 서비스의 집합을 가리키는 값. 
이 값은 합이다. 이 합은 초기에 영의 값을 채택하고, 그 다음 1에서 7까지의 범위에 있는 각 계층 L을 위해 이 노드는 2의 (L-1) 승이 그 합에 더해지는 트랜잭션을 수행한다.

예를 들면, 주로 경로선택 기능 을 수행하는 노드는 2의 (3-1)승인 4의 값을 갖는다. 반대로, 응용 서비스를 제공하는 호스트인 노드는 (2^(4-1)+2^(7-1))인 72의 값을 갖게 된다. 인터네트 프로토콜 쌍의 환경에서 값들은 다음과 같이 그것에 따라 계산되어야 한다.

 계층 기능 
1 물리적 (예를 들면, 리피터) 
2 데이타연결/서브네트워크 (예를 들면, 브릿지) 
3 인터네트 (예를 들면, IP 게이트웨이) 
4 종단간 (예를 들면, IP 호스트) 
7 응용 (예를 들면, 메일 중계)

 OSI 프로토콜을 포함하는 시스템의 경우, 계층 5와 6이 계산될 수 있다." 
::= { system 7 }

 

6.4.4 인터페이스 그룹

 -- 인터페이스 그룹의 구현은 모든 시스템에서 필수사항이다.

 ifNumber 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "이 시스템 상에 존재하는 (그들의 현 상태와는 무관하게) 전산망 인터페이스의 갯수." 
::= { interfaces 1 }

 -- 인터페이스 테이블

 -- 인터페이스 테이블은 엔티티의 인터페이스에 관한 정보를 포함한다. 각 인터페이스는 '서브네트워크'에 붙은 것으로 간주된다. 이 용어는 인터네트 프로토콜 쌍 에 사용되는 주소 분할 기법을 참조하는'서브네트'와 혼동되어서는 않된다.

 ifTable 객체-유형 
구문 SEQUENCE OF IfEntry 
접근 접근금지 
상태 필수사항 
기술 "인터페이스 엔트리의 나열. 엔트리의 갯수는 ifNumber 값에 의해 주어진다." 
::= { interfaces 2 }

 ifEntry 객체-유형 
구문 IfEntry 
접근 접근금지 
상태 필수사항 
기술 "서브네트워크 계층과 특정 인터페이스 하에 있는 객체들을 포함하는 인터페이스 엔트리." 
::= { ifTable 1 }

 IfEntry ::= 
SEQUENCE { 
ifIndex 
INTEGER, 
ifDescr 
DisplayString, 
ifType 
INTEGER, 
ifMtu 
INTEGER, 
ifSpeed 
Gauge, 
ifPhysAddress 
PhysAddress, 
ifAdminStatus 
INTEGER, 
ifOperStatus 
INTEGER, 
ifLastChange 
TimeTicks, 
ifInOctets 
Counter, 
ifInUcastPkts 
Counter, 
ifInNUcastPkts 
Counter, 
ifInDiscards 
Counter, 
ifInErrors 
Counter, 
ifInUnknownProtos 
Counter, 
ifOutOctets 
Counter, 
ifOutUcastPkts 
Counter, 
ifOutNUcastPkts 
Counter, 
ifOutDiscards 
Counter, 
ifOutErro

rs 
Counter, 
ifOutQLen 
Gauge, 
ifSpecific 
OBJECT IDENTIFIER 
}

 ifIndex 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "각 인터페이스에 유일한 값. 그 값의 범위는 1부터 ifNumber의 값이다. 각 인터페이스에 대한 값은 적어도 그 엔티티의 전산망 관리 시스템의 재초기화로부터 다음 재초기화까지 일정하게 남아야 한다." 
::= { ifEntry 1 }

 ifDescr 객체-유형 
구문 DisplayString(SIZE(0..255)) 
접근 읽기전용 
상태 필수사항 
기술 "인터페이스에 관한 정보를 포함하는 문자열. 이 문자열은 하드웨어 인터페이스의 제조자 이름, 상품명, 그리고 버젼을 포함하여야 한다." 
::= { ifEntry 2 }

 ifType 객체-유형 
구문 INTEGER { 
other(1), -- 다음에 없는 것 
regular1822(2), 
hdh1822(3), 
ddn-x25(4), 
rfc877-x25(5), 
ethernet-csmacd(6), 
iso88023-csmacd(7), 
iso88024-csmacd(8), 
iso88025-csmacd(9), 
iso88026-man(10), 
starLan(11), 
proteon-10Mbit(12), 
proteon-80Mbit(13), 
hyperchannel(14), 
fddi(15), 
lapb(16), 
sdlc(17), 
ds1(18), 
e1(19), --T-1에 대응하는 유럽표준 
basicISDN(20), 
primaryISDN(21), -- 독자적인 선로 
propPointToPointSerial(22), 
ppp(23), 
softwareLoopback(24), 
eon(25), -- IP 상의 CLNP [11] 
ethernet-3Mbit(26), 
nsip(27), -- IP 상의 XNS 
slip(28), -- 일반 SLIP 
ultra(29), -- ULTRA 기술 
ds3(30), -- T-3


sip(31), -- SMDS 
frame-relay(32), 

접근 읽기전용 
상태 필수사항 
기술 "프로토콜 스택에 있는 전산망 계층 바로 '아래'의 물리/연결 프로토콜에 따라 구별되는 인터페이스의 유형." 
::= { ifEntry 3 }

 ifMtu 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "인터페이스에서 송신 또는 수신할 수 있는 옥테트로 명시된 가장 큰 데이타그램의 크기. 전산망에 데이타그램을 전송하기 위해 사용되는 인터페이스의 경우, 이것은 그 인터페이스에 보내질 수 있는 최대 
전산망 데이타그램의 크기이다." 
::= { ifEntry 4 }

 ifSpeed 객체-유형 
구문 Gauge 
접근 읽기전용 
상태 필수사항 
기술 "bps로 인터페이스의 현재 대역폭 평가. 대역폭이 변하지 않거나 정확한 평가가 이루어지지 않는 인터페이스에 대해, 이 객체는 명목 상의 대역폭을 포함해야한다." 
::= { ifEntry 5 }

 ifPhysAddress 객체-유형 
구문 PhysAddress 
접근 읽기전용 
상태 필수사항 
기술 "프로토콜 스택의 전산망 계층 바로 아래에 있는 프로토콜 계층의 인터페이스 주소. 그와 같은 주소 (예를 들면, 통신선로)를 갖지 않는 인터페이스의 경우, 이 객체는 길이가 0인 옥테트 문자열을 포함 
하여야 한다." 
::= { ifEntry 6 }

 ifAdminStatus 객체-유형 
구문 INTEGER { 
up(1), -- 패킷을 넘길 준비가 됨 
down(2), 
testing(3), -- 테스트 모드 

접근 읽기쓰기 
상태 필수사항 
기술 "인터페이스의 원하는 상태. testing(3) 상태는 동작 패킷이 통과될수 없음을 지시한다." 
::= { ifEntry 7 }

 ifOperStatus 객체-유형 
구문 INTEGER { 
up(1), -- 패킷을 넘길 준비가 됨 
down(2), 
testing(3), -- 시험 모드 

접근 읽기전용 
상태 필수사항 
기술 "인터페이스의 현 동작 상태. testing(3) 상태는 동작 패킷이 통과될 수 없음을 지시한다." 
::= { ifEntry 8 }

 ifLastChange 객체-유형 
구문 TimeTicks 
접근 읽기전용 
상태 필수사항 
기술 "인터페이스가 현재 동작 상태에 들어갔을 때의 sysUpTime의 값. 현 상태가 국부 전산망 관리 서브시스템의 마지막 재초기화에 앞서 들어왔다면, 이 객체는 영의 값을 포함한다." 
::= { ifEntry 9 }

 ifInOctets 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "프레임 구성 문자를 합쳐서, 인터페이스에 수신된 옥테트의 총갯수." 
::= { ifEntry 10 }

 ifInUcastPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상위 계층 프로토콜에 전달되는 서브네트워크-유니캐스트 패킷의 갯 수." 
::= { ifEntry 11 }

 ifInNUcastPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상위 계층 프로토콜에 전달되는 비유니캐스트(서브네트워크-브로드캐스트 또는서브네트워크-멀티캐스트) 패킷의 갯수." 
::= { ifEntry 12 }

 ifInDiscards 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상위 계층 프로토콜에 전달되는 것을 막는 오류가 검출되지 않았을지라도 버려지는 도착 패킷의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다." 
::= { ifEntry 13 }

 ifInErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "패킷에 포함된 오류때문에 상위 계층 프로토콜에 전달되지 못한 도착 패킷의 갯수." 
::= { ifEntry 14 }

 ifInUnknownProtos 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "알려지지 않았거나 지원되지 않은 프로토콜때문에 버려지는 인터페이스를 통해 수신된 패킷의 갯수." 
::= { ifEntry 15 }

 ifOutOctets 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "프레임 구성 문자를 포함하여, 인터페이스를 벗어나서 전송되는 총 옥테트 갯수." 
::= { ifEntry 16 }

 ifOutUcastPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 서브네트워크-유니캐스트 주소에 전송되는 패킷의 총 갯수." 
::= { ifEntry 17 }

 ifOutNUcastPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 비유니캐스트(다시 말해서, 서브네트워크-브로드캐스트 또는 서브네트워크-멀티캐스트) 주소에 전송되는 패킷의 총 갯수." 
::= { ifEntry 18 }

 ifOutDiscards 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류때문에 전송되지 못하는 패킷이 없을지라도 버려지는 발신 패킷 의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다." 
::= { ifEntry 19 }

 ifOutErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류때문에 전송될 수 없는 발신 패킷의 갯수." 
::= { ifEntry 20 }

 ifOutQLen 객체-유형 
구문 Gauge 
접근 읽기전용 
상태 필수사항 
기술 "출력 패킷 큐의 길이." 
::= { ifEntry 21 }

 ifSpecific 객체-유형 
구문 OBJECT IDENTIFIER 
접근 읽기전용 
상태 필수사항 
기술 "인터페이스를 실현하기 위해 사용되는 어떤 매체에 특정한 MIB 정의 에 대한 참조. 예를 들면, 인터페이스가 ethernet에 의해 실현된다면 이 객체의 값은 ethernet에 특정한 객체를 정의하는 문서를 언급한 
이 정보가 존재하지 않는다면, 그것의 값은 OBJECT IDENTIFIER {0 0} 에 설정되어야 한다. 이 OBJECT IDENTIFIER는 타당한 OBJECT IDENTIFIER이고, ASN.1과 BER을 준수하는 구현은 이 값을 생성하고 
인식할 수 있어야 한다." 
::= { ifEntry 22 }

 

6.4.5 주소 변환 그룹

 -- 주소 변환 그룹의 구현은 모든 시스템에 필수사항이다. 그러나, MIB-II는 이 그룹 을삭제대상으로 한다. 다시 말해서, 주소 변환 그룹은 MIB-I 노드와의 호환성을 위해서는 포함되고, MIB-III 노드에서는 제외되는 것이 바람직하다는 것이다. 

-- MIB-II 이후로, 각 전산망 프로토콜 그룹은 그 자신의 주소 변환 테이블을 포함 한다. 
-- 주소 변환 그룹은 NetworkAddress(예를 들면, IP 주소)를 서브네트워크에 특정한 주소로 변환하기 위한 변환 테이블의 모든 인터페이스를 거치는 결합된 하나의 테이블을 포함한다. 좀 더 좋은 용어의 결핍으로, 이 문서는 서브네트워크에 특정한 주소를 '물리적' 주소로 일컫는다.


-- 그와같은 변환 테이블의 예는 다음과 같다. ARP를 사용하는 방송전달 매체의 경우, 변환 테이블은 ARP 캐쉬와 동등하다. 또는 X.121 주소에 대한 비알고리즘 방식의 해석이 요구되는 X.25의 경우, 변환 테이블은 X.121 주소와 동등한 NetworkAddress를 포함한다.

 atTable 객체-유형 
구문 SEQUENCE OF AtEntry 
접근 접근금지 
상태 삭제대상 
기술 "주소 변환 테이블은 '물리적' 주소와 동등 관계인 NetworkAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소(예를 들면, DDN-X.25 는 알고리즘 방식을 갖는다)를 결정하기 위해 변환 테이블을 사용하 
지 않는다.

모든 인터페이스가 이런 유형이 된다면, 주소 변환 테이블은 빈다. 다시 말해서, 엔트리를 갖지 않게된다." 
::= { at 1 }

 atEntry 객체-유형 
구문 AtEntry 
접근 접근금지 
상태 삭제대상 
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 NetworkAddress를 포함한다."

 인덱스 { atIfIndex, 
atNetAddress } 
::= { atTable 1 }

 AtEntry ::= 
SEQUENCE { 
atIfIndex 
INTEGER, 
atPhysAddress 
PhysAddress, 
atNetAddress 
NetworkAddress 
}

 atIfIndex 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 삭제대상 
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 색인의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 인터페이스와 같다." 
::= { atEntry 1 }

 atPhysAddress 객체-유형 
구문 PhysAddress 
접근 읽기쓰기 
상태 삭제대상 
기술 "매체-의존적인 '물리적' 주소. 
이 객체를 널 문자열로 설정하는 것은 atTable 객체에 있는 대응하는 엔트리를 무효화하는 효과가 있다. 다시 말해서, 그것은 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별된 인터페이스를 
효과적으로 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거 하는 것은 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자로 부터 테이블 정보를 받을 준비가 되어있어야 한다. 그런 엔트리들의 알맞은 해석은 관련된 atPhysAddress 객체의 시험을 필요로 한다." 
::= { atEntry 2 }

 atNetAddress 객체-유형 
구문 NetworkAddress 
접근 읽기쓰기 
상태 삭제대상 
기술 "매체-의존적인 '물리적' 주소에 대응하는 NetworkAddress(예를 들면, IP 주소)." 
::= { atEntry 3 }

 

6.4.6 IP 그룹

 -- IP 그룹의 구현은 모든 시스템에 대해 필수사항이다.

 ipForwarding 객체-유형 
구문 INTEGER { 
forwarding(1), -- 게이트웨이로서 동작 
not-forwarding(2) -- 게이트웨이로서 동작 안함 

접근 읽기쓰기 
상태 필수사항 
기술 "이 엔티티로 주소가 지정되지 않았지만 이 엔티티에 의해 수신된 데이타그램의 발송에 관한 IP 게이트웨이로서 이 엔티티가 동작하는지 에 대한 지시. IP 게이트웨이는 데이타그램을 발송한다.

IP 호스트는 발송하지 않는다.(호스트에 의해 송신지가 경로를 지정한 것을 제외 하고).  몇몇 피관리 노드의 경우, 이 객체는 가능한 값들의 부분집합만을 채택할 수 있다는 것을 주목하라.

따라서, 관리 스테이션이 이 객체를 부적합한 값으로 변경하려한다면, 'badValue'라는 응답을 수행자에게 반환하는 것이 합당하다." 
::= { ip 1 }

 ipDefaultTTL 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "TTL 값이 수송 계층 프로토콜에 의해 지원되지 않을 때마다 이 엔티티에서 기인되는 IP 데이타그램 머리부분의 Time-To-Live 필드로 삽입되는 기본형 값." 
::= { ip 2 }

 ipInReceives 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "인터페이스로 부터 수신된 입력 데이타그램의 총 갯수로 오류로 수신된 것도 포함한다." 
::= { ip 3 }

 ipInHdrErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "IP 머리부분 내의 오류로 인해 버려지는 입력 데이타그램의 갯수로서 잘못된 검사합, 버젼의 불일치, 다른 형식 오류, 패킷 존재 시간 (time-to-live) 초과, IP 선택사항 처리에서 발견된 오류 등을 포함 한다." 
::= { ip 4 }

 ipInAddrErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "IP 헤더의 목적지 필드에 있는 IP 주소가 이 엔티티에 수신될 타당한 주소가 아니므로 버려진 입력 데이타그램의 갯수. 이 카운트는 의미 없는 주소(예를 들면, 0.0.0.0)와 지원되지 않는 등급(예를 들면, 
등급 E)를 포함한다.

IP 게이트웨이가 아니므로 데이타그램을 진행시키지 않는 엔티티의 경우, 이 카운터는 목적지 주소가 국부 주소가 아니므로 버려진 데이타그램을 포함한다." 
::= { ip 5 }

 ipForwDatagrams 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "마지막 목적지에 데이타그램을 보내기 위한 경로를 찾는 시도의 결과 로, 이 엔티티는데이타그램들의 마지막 IP 목적지가 아닌 입력 데이타그램의 갯수. IP 게이트웨이로써 동작하지 않는 실체들의 경우에 
대해, 이 카운터는 해당 엔티티를 경유하여 송신지에서 결정된 경로 를 갖는 패킷들 중 성공적으로 처리된 패킷들만 포함할 것이다." 
::= { ip 6 }

 ipInUnknownProtos 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "알려지지 않았거나 지원되지 않는 프로토콜때문에 성공적으로 수신되었지만 버려지는 국부적인 주소를 가진 데이타그램의 갯수." 
::= { ip 7 }

 ipInDiscards 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "데이타그램의 계속되는 처리를 막는 문제는 없으나 버려지는 입력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 재조 립을 기다리는 동안 버려지는 데이타그램은 포함하지 않는다." 
::= { ip 8 }

 ipInDelivers 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "IP 사용자 프로토콜(ICMP를 포함한다.)에 성공적으로 전달되는 입력 데이타그램의 총 갯수." 
::= { ip 9 }

 ipOutRequests 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "국부 IP 사용자 프로토콜(ICMP를 포함한다)이 전송을 위한 요청으로 IP에 지원했던 IP 데이타그램의 총 갯수. 이 카운터는 ipForwDatagrams에서 계산된 데이타그램을 포함하지 않는다." 
::= { ip 10 }

 ipOutDiscards 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "데이타그램의 목적지 전송을 방해하는 문제는 없으나 버려지는 출력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 어떤 패킷이 이런 (임의의) 버려지는 기준을 만족했다면 ipForwDatagrams에서 계산된 데이타그램을 포함한다." 
::= { ip 11 }

 ipOutNoRoutes 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "목적지까지 데이타그램을 전송하기 위해 찾을 수 있는 경로가 없으므로 버려지는 IP 데이타그램의 갯수. 이 카운터는 이런 '무경로' 기준 을만족하는 ipForwDatagrams에서 계산되는 패킷을 포함한다. 이것은 
호스트의 기본형 게이트웨이 모두가 작동되지 않아 경로선택을 할 수 없는 데이타그램을 포함한다." 
::= { ip 12 }

 ipReasmTimeout 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "이 엔티티에서 재조합을 기다리는 동안 수신된 프레그먼트가 유지되는 최대치" 
::= { ip 13 }

 ipReasmReqds 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "이 엔티티에서 재조합되기 위해 요구되는 수신된 IP 프레그먼트의 갯 수." 
::= { ip 14 }

 ipReasmOKs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "성공적으로 재조합되는 IP 데이타그램의 갯수." 
::= { ip 15 }

 ipReasmFails 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "IP 재조합 알고리즘에 의해 검출되는 실패의 갯수(어떤 이유든, 즉 시간초과, 오류 등등). 몇가지 알고리즘(RFC 815에 있는 알고리즘)이 수신될때 결합되는 것에 의해 프레그먼트의 갯수를 잃을 수 있으므로 이것이 필요로해서 버려지는 IP 프레그먼트의 수는 아니다." 
::= { ip 16 }

 ipFragOKs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "성공적으로 분해된 IP 데이타그램의 갯수." 
::= { ip 17 }

 ipFragFails 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "이 엔티티에서 분해될 필요가 있었으나 Don't Fragment 플래그가 설정되었기에 분해될 수 없었으므로 버려졌던 IP 데이타그램의 갯수. 
::= { ip 18 }

 ipFragCreates 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "이 엔티티에서 분해의 결과로 생성되었던 IP 데이타그램의 프레그먼 트 갯수." 
::= { ip 19 }

 -- IP 주소 테이블 
-- IP 주소 테이블은 해당엔티티의 IP 주소지정 정보를 포함한다.

 ipAddrTable 객체-유형 
구문 SEQUENCE OF IpAddrEntry 
접근 접근금지 
상태 필수사항 
기술 "해당엔티티의 IP 주소에 관련된 주소지정 정보의 테이블." 
::= { ip 20 }

 ipAddrEntry 객체-유형 
구문 IpAddrEntry 
접근 접근금지 
상태 필수사항 
기술 "해당엔티티의 IP 주소 중 하나에 대한 주소지정 정보." 
인덱스 { ipAdEntAddr } 
::= { ipAddrTable 1 }

 IpAddrEntry ::= 
SEQUENCE { 
ipAdEntAddr 
IpAddress, 
ipAdEntIfIndex 
INTEGER, 
ipAdEntNetMask 
IpAddress, 
ipAdEntBcastAddr 
INTEGER, 
ipAdEntReasmMaxSize 
INTEGER (0..65535) 

  

ipAdEntAddr 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔트리의 주소지정 정보가 관계하는 IP 주소." 
::= { ipAddrEntry 1 }

 ipAdEntIfIndex 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔트리가 적용될 수 있는 인터페이스를 유일하게 구별하는 인덱 스 값. 해당인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex 의 값에 의해 구별되는 것과 같은 인터페이스이다." 
::= { ipAddrEntry 2 }

 ipAdEntNetMask 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔트리의 IP 주소와 연관된 서브네트 마스크. 이 마스크의 값은 모든 네트워크 비트가 1로 설정되고 호스트 비트는 0으로 설정된 IP 주소이다." 
::= { ipAddrEntry 3 }

 ipAdEntBcastAddr 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔트리의 IP 주소에 연관된 (논리적인) 인터페이스 상에 데이타 그램을 보내기 위해 사용되는 IP 브로드캐스트 주소에 있는 최하위 비트의 값. 예를 들면, 모두 1로 된 인터네트 표준 브로드캐스트 주 
소가 사용될 때, 값은 1이 될 것이다.

이 값은 이런 (논리적) 인터페이스 상의 엔티티에 의해 사용되는 서브네트와 네트워크 브로드캐스트 주소에 적용한다." 
::= { ipAddrEntry 4 }

 ipAdEntReasmMaxSize 객체-유형 
구문 INTEGER (0..65535) 
접근 읽기전용 
상태 필수사항 
기술 "해당엔티티가 이 인터페이스 상에 수신되어 들어오는 분해된 IP 데이타그램의 입력을 재조립할 수 있는 최대 IP 데이타그램의 크기." 
::= { ipAddrEntry 5 }

 -- IP 경로선정 테이블 
-- IP 경로선정 테이블은 현재 해당 엔티티에 알려진 각 경로를 위한 엔트리를 포함 한다.

 ipRouteTable 객체-유형 
구문 SEQUENCE OF IpRouteEntry 
접근 접근금지 
상태 필수사항 
기술 "해당 엔티티의 IP 경로선정 테이블." 
::= { ip 21 }

 ipRouteEntry 객체-유형 
구문 IpRouteEntry 
접근 접근금지 
상태 필수사항 
기술 "특정 목적지로의 경로." 
인덱스 { ipRouteDest } 
::= { ipRouteTable 1 }

 IpRouteEntry ::= 
SEQUENCE { 
ipRouteDest 
IpAddress, 
ipRouteIfIndex 
INTEGER, 
ipRouteMetric1 
INTEGER, 
ipRouteMetric2 
INTEGER, 
ipRouteMetric3 
INTEGER, 
ipRouteMetric4 
INTEGER, 
ipRouteNextHop 
IpAddress, 
ipRouteType 
INTEGER, 
ipRouteProto 
INTEGER, 
ipRouteAge 
INTEGER, 
ipRouteMask 
IpAddress, 
ipRouteMetric5 
INTEGER, 
ipRouteInfo 
OBJECT IDENTIFIER 
}

 ipRouteDest 객체-유형 
구문 IpAddress 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로의 목적지 IP 주소. 값이 0.0.0.0인 엔트리는 기본형 경로로 간주된다. 한 목적지로의 다양한 경로들은 테이블 내에 있을 수 있다.

그러나 그런 여러 엔트리로의 접근은 사용중인 네트워크 관리 프로토콜에 의해 정의된 테이블-접근 메카니즘에 의존한다." 
::= { ipRouteEntry 1 }

 ipRouteIfIndex 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로가 다음 홉에 도달되기 위해 거쳐야 하는 국부 인터페이스를 유일하게 구별하는 인덱스 값. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex의 같은 값에 의해 구별되는 것과 같은 인터페 
이스이다." 
::= { ipRouteEntry 2 }

 ipRouteMetric1 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로에 대한 주요 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다." 
::= { ipRouteEntry 3 }

 ipRouteMetric2 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다." 
::= { ipRouteEntry 4 }

 ipRouteMetric3 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다." 
::= { ipRouteEntry 5 }

 ipRouteMetric4 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다." 
::= { ipRouteEntry 6 }

 ipRouteNextHop 객체-유형 
구문 IpAddress 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로의 다음 홉에 대한 IP 주소.(브로드캐스트 매체를 통해 실현 되는 인터페이스에 속한 경로의 경우에, 이 필드의 값은 그 인터페이 스에 관한 수행자의 IP 주소이다.)" 
::= { ipRouteEntry 7 } 
ipRouteType 객체-유형 
구문 INTEGER { 
other(1), -- 다음에 없는 것 
invalid(2), -- 무효화된 경로 
direct(3), -- 직접 연결된 (서브-) 네트워크 
-- 로의 경로 
indirect(4) -- 국부가 아닌 호스트/네트워크/ 
-- 서브-네트워크로의 경로 

접근 읽기쓰기 
상태 필수사항 
기술 "경로 유형. direct(3)와 indirect(4) 값은 IP 구조 내의 직접 그리고 간접 경로선정의 개념을 나타낸다.

 invalid(2) 값으로 이 객체를 설정하는 것은 ipRouteTable 객체에 있는 대응하는 엔트리를 무효화하는 것이다. 다시 말해서, 언급된 엔트로 구별되는 경로로부터 언급된 엔트리로 구별되는 목적지를 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipRouteType 객체의 검사를 요구한다." 
::= { ipRouteEntry 8 }

 ipRouteProto 객체-유형 
구문 INTEGER { 
other(1), -- 다음에 없는 것 
local(2), -- 프로토콜이 아닌 정보 예를 들면, 수작업으로 구성된 엔트리 
netmgmt(3), -- 네트워크 관리 프로토콜을 통해 설정 
icmp(4), -- ICMP를 통해 얻어진 것 
-- 예를 들면, 경로 재지정 
-- 남은 값은 모든 게이트웨이 경로 
-- 선택 프로토콜이다. 
egp(5), 
ggp(6), 
hello(7), 
rip(8), 
is-is(9), 
es-is(10), 
ciscoIgrp(11), 
bbnSpfIgp(12), 
ospf(13), 
bgp(14) 

접근 읽기전용 
상태 필수사항 
기술 "경로를 알아내는 경로선정 메카니즘. 게이트웨이 경로선정 프로토콜 
을 위한 값의 포함은 호스트가 그런 프로토콜을 지원해야한다는 것을 
의미하려는 것은 아니다." 
::= { ipRouteEntry 9 }

 ipRouteAge 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "경로가 가장 최근에 이루어진 경로의 갱신 또는 경로가 교정되도록 결정된 이후에 경과된 초의 수. 주의할 점은 경로를 알아내는 경로 선택 프로토콜에 관한 이해없이는 어떠한 'too old'의 의미도 내포될 
수 없다는 것이다." 
::= { ipRouteEntry 10 }

 ipRouteMask 객체-유형 
구문 IpAddress 
접근 읽기쓰기 
상태 필수사항 
기술 "ipRouteDest 필드에 있는 값과 비교되기 전에 목적지 주소와 마스크 를 논리적 AND 시키도록 지시. 임의의 서브네트 마스크를 지원하지 않는 시스템의 경우, 수행자는 대응하는 ipRouteDest 필드의 값이 등 
급 - A, B, 또는 C 네트워크에 속하는지를 결정하고 다음 중 하나를 사용하여 ipRouteMask의 값을 구성한다.

 마스크 네트워크 
255.0.0.0 등급-A 
255.255.0.0 등급-B 
255.255.255.0 등급-C

 ipRouteDest 값이 0.0.0.0라면(기본형 경로), 마스크 값은 또한 0.0.0.0이다. 모든 경로선정 IP 서브시스템이 암시적으로 이 메카니 즘을 사용한다는 것을 주목해야 한다." 
::= { ipRouteEntry 11 }

 ipRouteMetric5 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다." 
::= { ipRouteEntry 12 }

 ipRouteInfo 객체-유형 
구문 OBJECT IDENTIFIER 
접근 읽기전용 
상태 필수사항 
기술 "경로의 ipRouteProto 값에 명시된 값에 의해 결정될 때, 이 경로에 책임이 있는 특정 경로선정 프로토콜에 대해서 특별한 MIB 정의에 대한 참조. 이 정보가 없다면, 그 값은 OBJECT IDENTIFIER { 0 0 }로 
설정되어야 한다. 구문적으로 타당한 객체 식별자이고, ASN.1과 BER 을 준수하는 구현은 이 값을 생성하고 인식할 수 있어야 한다." 
::= { ipRouteEntry 13 }

 -- IP 주소 해석 테이블

 -- IP 주소 해석 테이블은 '물리적' 주소와 동등 관계인 IpAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소를 결정하기 위해 해석 테이블을 사용하지 않는다 
-- (예를 들면, DDN-X.25는 알고리즘 방식을 갖는다). 모든 인터페이스가 이런 유형 이라면, 주소 해석 테이블은 비게한다. 다시 말해서, 엔트리를 갖지 않는다.

 ipNetToMediaTable 객체-유형 
구문 SEQUENCE OF IpNetToMediaEntry 
접근 접근금지 
상태 필수사항 
기술 "IP 주소에서 물리적 주소로의 사상에 사용되는 IP 주소 해석 테이블." 
::= { ip 22 }

 ipNetToMediaEntry 객체-유형 
구문 IpNetToMediaEntry 
접근 접근금지 
상태 필수사항 
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 IpAddress를 포함한다." 
인덱스 { ipNetToMediaIfIndex, 
ipNetToMediaNetAddress } 
::= { ipNetToMediaTable 1 }

 IpNetToMediaEntry ::= 
SEQUENCE { 
ipNetToMediaIfIndex 
INTEGER, 
ipNetToMediaPhysAddress 
PhysAddress, 
ipNetToMediaNetAddress 
IpAddress, 
ipNetToMediaType 
INTEGER 
}

 ipNetToMediaIfIndex 객체-유형 
구문 INTEGER 
접근 읽기쓰기 
상태 필수사항 
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 것과 같은 인터페이스이다." 
::= { ipNetToMediaEntry 1 }

 ipNetToMediaPhysAddress 객체-유형 
구문 PhysAddress 
접근 읽기쓰기 
상태 필수사항 
기술 "매체 의존적인 '물리적' 주소." 
::= { ipNetToMediaEntry 2 }

 ipNetToMediaNetAddress 객체-유형 
구문 IpAddress 
접근 읽기쓰기 
상태 필수사항 
기술 "매체 의존적인 '물리적' 주소에 대응하는 IpAddress." 
::= { ipNetToMediaEntry 3 }

 ipNetToMediaType 객체-유형 
구문 INTEGER { 
other(1), -- 다음에 없는 것 
invalid(2), -- 무효화된 사상 
dynamic(3), 
static(4) 

접근 읽기쓰기 
상태 필수사항 
기술 "사상의 유형.

 이 객체를 invalid(2)로 설정하는 것은 ipNetToMediaTable에 있는 대응하는 엔트리를 무효화하는 것이다.

다시 말해서, 실제로 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별되는 인터페이스를 분리한다. 수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다.

따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipNetToMediaType 객체의 조사를 요구한다." 
::= { ipNetToMediaEntry 4 }

 -- 추가되는 IP 객체

 ipRoutingDiscards 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "엔트리들이 유효하더라도 버려지도록 선택된 경로선정 엔트리의 갯수. 그런 엔트리를 버리는 이유 중의 하나가 다른 경로 엔트리를 위해서 버퍼 공간을 비우는 행위가 될 수 있을 것이다." 
::= { ip 23 }

 

6.4.7 ICMP 그룹

 -- ICMP 그룹의 구현은 모든 시스템에 필수사항이다.

 icmpInMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "엔티티가 수신한 ICMP 메세지의 총 갯수. 이 카운터는 icmpInErrors 에 의해 계산된 것 모두를포함한다." 
::= { icmp 1 }

 icmpInErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "엔티티가 수신했으나 ICMP 정의 오류(불량 ICMP 검사합, 길이 불량 등)를 가지고 있는 것으로 판명된 ICMP 메세지들의 갯수." 
::= { icmp 2 }

 icmpInDestUnreachs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 목적지 도달 불가능 메세지의 갯수." 
::= { icmp 3 }

 icmpInTimeExcds 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 시간 초과 메세지의 갯수." 
::= { icmp 4 }

 icmpInParmProbs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 매개변수 문제 메세지의 갯수." 
::= { icmp 5 }

 icmpInSrcQuenchs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 발신지 억제 메세지의 갯수." 
::= { icmp 6 }

 icmpInRedirects 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 경로전환 메세지의 갯수." 
::= { icmp 7 }

 icmpInEchos 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 에코우(요청) 메세지의 갯수." 
::= { icmp 8 }

 icmpInEchosReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 에코우 응답 메세지의 갯수." 
::= { icmp 9 }

 icmpInTimestamps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP Timestamp(요청) 메세지의 갯수." 
::= { icmp 10 }

 icmpInTimestampReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP Timestamp 응답 메세지의 갯수." 
::= { icmp 11 }

 icmpInAddrMasks 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 주소 마스크 요청 메세지의 갯수." 
::= { icmp 12 }

 icmpInAddrMaskReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 ICMP 주소 마스크 응답 메세지의 갯수." 
::= { icmp 13 }

 icmpOutMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔티티가 송신하려고 시도했던 ICMP 메세지의 총 갯수. 이 카운터는 icmpOutErrors에 의해 계산된 모든 것을 포함한다." 
::= { icmp 14 }

 icmpOutErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔티티가 버퍼 부족과 같은 ICMP 내에서 발견되는 문제로 인해 송신하지 않은 ICMP 메세지의 갯수. 이 값은 IP의 결과로서 생성된 데이타그램의 경로를 정하지 못하는 것과 같은 ICMP 계층을 벗어나서 
발견된 오류를 포함해서는 안된다. 몇가지 구현에서, 이 카운터 값의 원인인 오류 유형은 없다." 
::= { icmp 15 }

 icmpOutDestUnreachs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 목적지 도착 불가능 메세지의 갯수." 
::= { icmp 16 }

 icmpOutTimeExcds 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 시간 초과 메세지의 갯수." 
::= { icmp 17 }

 icmpOutParmProbs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 매개변수 문제 메세지의 갯수." 
::= { icmp 18 }

 icmpOutSrcQuenchs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 발신지 억제 메세지의 갯수." 
::= { icmp 19 }

 icmpOutRedirects 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 경로전환 메세지의 갯수. 호스트의 경우, 이 객체는 항상 0이다. 호스트는 방향전환 메세지를 보내지 않기 때문이다." 
::= { icmp 20 }

 icmpOutEchos 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 에코우 (요청) 메세지의 갯수." 
::= { icmp 21 }

 icmpOutEchoReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 에코우 응답 메세지의 갯수." 
::= { icmp 22 }

 icmpOutTimestamps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP Timestamp (요청) 메세지의 갯수." 
::= { icmp 23 }

 icmpOutTimestampReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP Timestamp 응답 메세지의 갯수." 
::= { icmp 24 }

 icmpOutAddrMasks 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 주소 마스크 요청 메세지의 갯수." 
::= { icmp 25 }

 icmpOutAddrMaskReps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "송신된 ICMP 주소 마스크 응답 메세지의 갯수." 

::= { icmp 26 }

 

6.4.8 TCP 그룹

-- TCP 그룹의 구현은 TCP를 구현하는 모든 시스템에 필수사항이다. 
-- 특정 TCP 접속에 대한 정보를 표현하는 객체 유형의 실체들은 일시적이다. 그 실체들은 접속이 끝남과 동시에 없어진다.

 tcpRtoAlgorithm 객체-유형 
구문 INTERGER { 
other(1), -- 다음에 없는 것

 constant(2), -- 상수 rto 
rsre(3), -- MIL-STD-1778, 부록 B 
vanj(4) -- Van Jacobson의 알고리즘[10] 

접근 읽기전용 
상태 필수사항 
기술 "인정되지 않은 옥테트를 재전송하기 위해 사용되는 타임아웃 값을 결정하기 위해 사용되는알고리즘." 
::= { tcp 1 }

 tcpRtoMin 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최소 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특 
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 LBOUND 양의 의미를 갖는다." 
::= { tcp 2 }

 tcpRtoMax 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최대 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특 
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 UBOUND 양의 의미를 갖는다." 
::= { tcp 3 }

 tcpMaxConn 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "엔티티가 지원할 수 있는 TCP 접속의 총 갯수에 관한 제한. 연결의 최대 갯수가 유동적인 엔티티들에 대해, 이 객체는 -1 값을 포함해야 한다." 
::= { tcp 4 }

 tcpActiveOpens 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "TCP 접속이 CLOSED 상태에서 SYN-SENT 상태로의 직접적인 전이가 이 뤄진 횟수." 
::= { tcp 5 }

 tcpPassiveOpens 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "TCP 접속이 LISTEN 상태에서 SYN-RCVD 상태로의 직접적인 전이가 이뤄진 횟수." 
::= { tcp 6 }

 tcpAttemptFails 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "TCP 접속이 SYN-SENT 상태 또는 SYN-RCVD 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수와 TCP 접속이 SYN-RCVD 상태에서 LISTEN 상태로의 직접적인 전이가 이뤄진 횟수를 더한 것." 
::= { tcp 7 }

 tcpEstabResets 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "TCP 접속이 ESTABLISHED 상태 또는 CLOSE-WAIT 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수." 
::= { tcp 8 }

 tcpCurrEstab 객체-유형 
구문 Gauge 
접근 읽기전용 
상태 필수사항 
기술 "현 상태가 ESTABLISHED 또는 CLOSE-WAIT인 TCP 접속의 갯수." 
::= { tcp 9 }

 tcpInSegs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류로 수신된 것을 포함하여, 수신된 세그먼트의 총 갯수. 이 계산 은 현재 설정된 연결 상에서 수신된 세그먼트를 포함한다." 
::= { tcp 10 }

 tcpOutSegs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "현재 연결된 것을 포함하여 송신된 세그먼트의 총 갯수. 그러나 재전송되는 옥테트를 제외한다." 
::= { tcp 11 }

 tcpRetransSegs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "재전송되는 세그먼트의 총 갯수. 다시 말해서, 이전에 한번이상 전송 된 옥테트들을 포함하여 전송되는 TCP 세그먼트의 갯수." 
::= { tcp 12 }

 -- TCP 접속 테이블 
-- TCP 접속 테이블은 해당 엔티티에 존재하는 TCP 접속에 관한 정보를 포함한다.

 tcpConnTable 객체-유형 
구문 SEQUENCE OF TcpConnEntry 
접근 접근금지 
상태 필수사항 
기술 "TCP 접속 정의 정보를 포함하는 테이블." 
::= { tcp 13 }

 tcpConnEntry 객체-유형 
구문 TcpConnEntry 
접근 접근금지 
상태 필수사항 
기술 "현재 특정한 TCP 접속에 대한 정보. 이 유형의 객체는 일시적이다. 
그런 점에서, 연결이 CLOSED 상태로 전이할 때 이 객체의 존재는 사라진다." 
인덱스 { tcpConnLocalAddress, 
tcpConnLocalPort, 
tcpConnRemAddress, 
tcpConnRemPort } 
::= { tcpConnTable 1 }

 tcpConnEntry ::= 
SEQUENCE { 
tcpConnState 
INTEGER, 
tcpConnLocalAddress 
IpAddress, 
tcpConnLocalPort 
INTEGER (0..65535), 
tcpConnRemAddress 
IpAddress, 
tcpConnRemPort 
INTEGER (0..65535) 
}

 tcpConnState 객체-유형 
구문 INTEGER { 
closed(1), 
listen(2), 
synSent(3), 
synReceived(4), 
established(5), 
finWait1(6), 
finWait2(7), 
closeWait(8), 
lastAck(9), 
closing(10), 
timeWait(11), 
deleteTCB(12) 

접근 읽기쓰기 
상태 필수사항 
기술 "해당 TCP 접속의 상태.

 관리 스테이션에 의해 설정될 수 있는 유일한 값이 deleteTCB(12)이다. 따라서, 관리 스테이션이 이 객체를 어떤 다른 값으로 설정하려 한다면, 수행자가 'badValue' 응답을 반환하는 것이 합당하다.

 관리 스테이션이 이 객체를 deleteTCB(12)로 설정한다면, 이것은 피관리 노드 상에 있는 대응하는 연결의 TCB를 제거하고 바로 그 연결 을 해제한다.

 구현에 따른 선택사항으로, RST 세그먼트는 피관리 노드에서 다른 TCP 종점으로 보내질 수 있다(그러나, 주목해야할 점은 RST 세그먼트 는 비신뢰적으로 송신된다는 것이다)." 
::= { tcpConnEntry 1 }

 tcpConnLocalAddress 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "해당 TCP 접속을 위한 국부 IP 주소. 그 노드에 접속된 IP 인터페이 스를 위한 연결을 받아들이는 LISTEN 상태에 있는 연결에 대해, 값 0.0.0.0이 사용된다." 
::= { tcpConnEntry 2 }

 tcpConnLocalPort 객체-유형 
구문 INTEGER (0..65535) 
접근 읽기전용 
상태 필수사항 
기술 "해당 TCP 접속을 위한 국부 포트 번호." 
::= { tcpConnEntry 3 }

 tcpConnRemAddress 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "해당 TCP 접속을 위한 원격 IP 주소." 
::= { tcpConnEntry 4 }

 tcpConnRemPort 객체-유형 
구문 INTEGER(0..65535) 
접근 읽기전용 
상태 필수사항 
기술 "해당 TCP 접속을 위한 원격 포트 번호." 
::= { tcpConnEntry 5 }

-- 추가되는 TCP 객체

 tcpInErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류로 수신된 세그먼트의 총 갯수(예를 들면, 불량 TCP 검사합)." 
::= { tcp 14 }

 tcpOutRsts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "RST 플래그를 포함하는 송신된 TCP 세그먼트의 갯수." 
::= { tcp 15 }

 

6.4.9 UDP 그룹

 -- UDP 그룹의 구현은 UDP를 구현하는 모든 시스템에 필수사항이다.

 udpInDatagrams 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "UDP 사용자들에게 전달되는 UDP 데이타그램의 총 갯수." 
::= { udp 1 }

 udpNoPorts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "목적지 포트에 응용 프로그램이 없는 경우, 수신된 UDP 데이타그램의 총 갯수." 
::= { udp 1 }

 udpInErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "목적지 포트에서 응용 프로그램의 문제 이외의 이유로 전달될 수 없는 수신된 UDP 데이타그램의 갯수." 
::= { udp 3 }

 udpOutDatagrams 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔티티로 부터 송신된 UDP 데이타그램의 총 갯수." 
::= { udp 4 }

 -- UDP Listener 테이블

 -- UDP Listener 테이블은 국부 응용이 현재 데이타그램을 받아들이는 해당 엔티티의UDP 종단점에 대한 정보를 포함한다.

 udpTable 객체-유형 
구문 SEQUENCE OF UdpEntry 
접근 접근금지 
상태 필수사항 
기술 "UDP Listener 정보를 포함하는 테이블." 
::= { udp 5 }

 udpEntry 객체-유형 
구문 UdpEntry 
접근 접근금지 
상태 필수사항 
기술 "특정한 현재 UDP Listener에 관한 정보." 
인덱스 { updLocalAddress, 
udpLocalPort } 
::= { udpTable 1 }

 UdpEntry ::= 
SEQUENCE { 
udpLocalAddress 
IpAddress, 
udpLocalPort 
INTEGER(0..65535) 
}

 udpLocalAddress 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "이 UDP Listener에 대한 국부 IP 주소. 그 노드에 접속된 IP 인터페이스를 위한 데이타그램을 받아들이는 UDP Listener에 대해, 값 0.0.0.0이 사용된다." 
::= { udpEntry 1 }

 udpLocalPort 객체-유형 
구문 INTEGER(0..65535) 
접근 읽기전용 
상태 필수사항 
기술 "이 UDP Listener에 대한 국부 포트 번호." 
::= { udpEntry 2 }

 

6.4.10 EGP 그룹

 -- EGP 그룹의 구현은 EGP를 구현하는 모든 시스템에 필수사항이다.

 egpInMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류없이 수신된 EGP 메세지의 갯수." 
::= { egp 1 }

 egpInErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류로 판명되어 수신된 EGP 메세지의 갯수." 
::= { egp 2 }

 egpOutMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "국부적으로 생성된 EGP 메세지의 총갯수." 
::= { egp 3 }

 egpOutErrors 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "EGP 엔티티 내에 있는 자원 제한때문에 송신되지 않아서 국부적으로 생성된 EGP 메세지의 갯수." 
::= { egp 4 }

 -- EGP 이웃 노드 테이블

 -- EGP 이웃 노드 테이블은 해당 엔티티의 EGP 이웃 노드들에 대한 정보를 포함한다.

 egpNeighTable 객체-유형 
구문 SEQUENCE OF EgpNeighEntry 
접근 접근금지 
상태 필수사항 
기술 "EGP 이웃 노드 테이블." 
::= { egp 5 }

 egpNeighEntry 객체-유형 
구문 EgpNeighEntry 
접근 접근금지 
상태 필수사항 
기술 "해당 엔티티의 특정 EGP 이웃 노드와의 관계에 관한 정보." 
인덱스 { egpNeighTable 1 } 
::= { egpNeighTable 1 }

 EgpNeighEntry ::= 
SEQUENCE { 
egpNeighState 
INTEGER, 
egpNeighAddr 
IpAddress, 
egpNeighAs 
INTEGER, 
egpNeighInMsgs 
Counter, 
egpNeighInErrs 
Counter, 
egpNeighOutMsgs 
Counter, 
egpNeighOutErrs 
Counter, 
egpNeighInErrMsgs 
Counter, 
egpNeighOutErrMsgs 
Counter, 
egpNeighStateUps 
Counter, 
egpNeighStateDowns 
Counter, 
egpNeighIntervalHello 
INTEGER, 
egpNeighIntervalPoll 
INTEGER, 
egpNeighMode 
INTEGER, 
egpNeighEventTrigger 
INTEGER 
}

 egpNeighState 객체-유형 
구문 INTEGER { 
idle(1), 
acquisition(2), 
down(3), 
up(4), 
cease(5) 

접근 읽기전용 
상태 필수사항 
기술 "해당 엔트리의 EGP 이웃 노드에 관한 국부 시스템의 EGP 상태. 각 EGP 상태는 RFC 904에서 언급된 상태와 연관된 수치보다 1 더 큰 수 치로 표현된다." 
::= { egpNeighEntry 1 }

 egpNeighAddr 객체-유형 
구문 IpAddress 
접근 읽기전용 
상태 필수사항 
기술 "해당 엔티티의 EGP 이웃 노드의 IP 주소." 
::= { egpNeighEntry 2 }

 egpNeighAs 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "해당 EGP의 상대 EGP인 독립적 시스템. 이웃 노드의 자율 시스템 번호가 아직 알려지지 않으면, 0이 명시되어야 한다." 
::= { egpNeighEntry 3 }

 egpNeighInMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "해당 EGP의 상대 EGP로 부터 오류없이 수신된 EGP 메세지의 갯수." 
::= { egpNeighEntry 4 }

 egpNeighInErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "오류로 판명된 해당 EGP의 상대 EGP로 부터 수신된 EGP 메세지의 갯수(예를 들면, 불량 EGP 검사합)." 
::= { egpNeighEntry 5 }

 egpNeighOutMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "해당 상대 EGP로 국부적으로 생성된 EGP 메세지의 갯수." 
::= { egpNeighEntry 6 }

 egpNeighOutErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "EGP 엔티티 내의 자원 제한때문에 상대 EGP로 송신되지 못한 국부적으로 생성된 EGP 메세지의 갯수." 
::= { egpNeighEntry 7 }

 egpNeighInErrMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상대 EGP로 부터 수신된 EGP 정의 오류 메세지의 갯수." 
::= { egpNeighEntry 8 }

 egpNeighOutErrMsgs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상대 EGP로 송신된 EGP 정의 오류 메세지의 갯수." 
::= { egpNeighEntry 9 }

 egpNeighStateUps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상대 EGP의 UP 상태로의 EGP 상태전이 갯수." 
::= { egpNeighEntry 10 }

 egpNeighStateDowns 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "상대 EGP의 UP 상태에서 다른 상태로의 EGP 상태전이 갯수." 
::= { egpNeighEntry 11 }

 egpNeighIntervalHello 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "EGP Hello 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t1 타이머를 나타낸다." 
::= { egpNeighEntry 12 }

 egpNeighIntervalPoll 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "EGP 폴 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t3 타이머를 나타낸다." 
::= { egpNeighEntry 13 }

 egpNeighMode 객체-유형 
구문 INTEGER { active(1), passive(2) } 
접근 읽기전용 
상태 필수사항 
기술 "EGP 엔티티의 폴링 모드. 수동 또는 능동의 값을 갖는다." 
::= { egpNeighEntry 14 }

 egpNeighEventTrigger 객체-유형 
구문 INTEGER { start(1), stop(2) } 
접근 읽기쓰기 
상태 필수사항 
기술 "운용자에 의해 개시된 시작과 종료사건을 기동하는데 사용되는 제어변수. 판독할 경우에는 이 변수는 항상 egpNeighEventTrigger에게 설정된 가장 최근의 값을 반환한다. 만약 노드상의 네트워크 관리 서브 
시스템의 마지막 초기화후 egpNeighEventTrigger가 설정되어있지 않았다면 'stop'이라는 값을 반환한다.

 설정시에는, RFC 904의 8-10페이지에 명시된 것같이 이 변수가 시작 사건이거나 종료사건을 명시된 이웃 상에서 일으키게 한다. 간단하게 말해서, 시작사건은 Idle 상태의 이웃 노드가 이웃 노드의 acquisition 상태를 시작할 수 있도록 해주고, Idle 상태가 아닌 상대 노드가 이웃 노드의 acquisition 상태를 재초기화하도록 한다.


종료사건은 Idle 상태가 아닌 상대 노드가 시작사건이 일어날 때까지 Idle 상태를 유지시킨다. 이때 egpNeighEventTrigger 또는 다른 것을 이용한다." 
::= { egpNeighEntry 15 }

 -- 추가되는 EGP 객체

 egpAs 객체-유형 
구문 INTEGER 
접근 읽기전용 
상태 필수사항 
기술 "이 EGP 엔티티의 독립적 시스템 갯수." 
::= { egp 6 }

 

6.4.11 전송 그룹

 -- 어떤 시스템 상의 각 인터페이스의 기초를 이루는 전송 매체에 근거하여 전송그룹과 일치하는 부분이 그 시스템에 대하여 의무적인 사항이 된다.

 -- 전송 매체를 관리하기 위한 인터네트 표준 정의가 내려질때, 전송그룹은 그들 객체들의 접두어를 제공하기 위해 사용된다.

 -- 실제로, 그런 정의들은 "입증"될때까지 MIB의 실험적 부분에 속하며, 그후에 인터네트 표준화 과정의 한 부분으로서 그 정의들은 적절하게 향상되어 전송그룹 내에 새로운 객체 식별자가 정의된다. 규정에 의해, 할당된 이름은 다음과 같다.


-- type OBJECT IDENTIFIER ::= { transmission number } 
-- "type"은 ifTable 객체의 ifType 열 내에 있는 매체를 위해 사용되는 기호값이며 "number"는 그 기호에 대응하는 실제 정수 값이다."

 

6.4.12 SNMP 그룹

 -- SNMP 그룹을 구현하는 것은 SNMP 프로토콜 엔티티를 유지하는 모든 시스템에 필수사항이다.

다음에 정의된 객체들 중 어떤 것은 관리 수행자 또는 관리 스테이션에 명시된 기능들만을 지원하도록 최적화된 SNMP 구현에서 0의 값이 된다. 특히, 주의해야할 것은 아래의 객체들은 SNMP 엔티티를 언급하고, 몇몇 SNMP 엔티티들은 관리 노드에 속할 수 있다는 것이다(예를 들면, 만약 노드가 관리 스테이 
-- 션처럼 호스트 역할을 한다면).

 snmpInPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "전송 서비스로 부터 SNMP 엔티티로 전달된 메세지들의 총 갯수." 
::= { snmp 1 } 
  

snmpOutPkts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티로 부터 전송 서비스에게 전달되는 SNMP 메세지의 총 갯수." 
::= { snmp 2 }

 snmpInBadVersions 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 전달되었으나 지원되지 않는 SNMP 버전에 대한 SNMP 메세지의 총 갯수." 
::= { snmp 3 }

 snmpInBadCommunityNames 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "언급된 엔티티에게는 알려지지않은 SNMP 공동체 명을 사용하여 SNMP프로토콜 엔티티에게 전달된 SNMP 메세지의 총 갯수." 
::= { snmp 4 }

 snmpInBadCommunityUses 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "전달된 메세지 내에 있는 SNMP 공동체 이름에 의거하여 허가되지 않 은 어떤 SNMP 동작을 갖는 SNMP 프로토콜 엔티티에게 전달되었던 SNMP 메세지의 총 갯수." 
::= { snmp 5 }

 snmpInASNParseErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "수신된 SNMP 메세지를 복호화할 때 SNMP 프로토콜 엔티티가 접하는 ASN.1이나 BER 오류의 총 갯수." 
::= { snmp 6 }

-- { snmp 7 }은 사용되지 않는다.

 snmpInTooBigs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드 값이 'too big' 인 SNMP PDU들의 총 갯수." 
::= { snmp 8 }

 snmpInNoSuchNames 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수." 
::= { snmp 9 }

 snmpInBadValues 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수." 
::= { snmp 10 }

 snmpInReadOnlys 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'readOnly'인 유효한 SNMP PDU들의 총 갯수. 주의해야할 점은 오류 상태 필드에 'read only' 값을 담고 있는 SNMP PDU를 생산하는 것은 프로토콜 오 
류라는 것이다. 이와같이, 이 객체는 SNMP의 잘못된 구현을 탐지하는 수단으로서 제공된다." 
::= { snmp 11 }

 snmpInGenErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'genErr'인 유효한 SNMP PDU들의 총 갯수." 
::= { snmp 12 }

 snmpInTotalReqVars 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "유효한 SNMP Get-Request와 Get-Next PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수." 
::= { snmp 13 }

 snmpInTotalSetVars 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "유효한 SNMP Set-Request PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수." 
::= { snmp 14 }

 snmpInGetRequests 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Request PDU의 총 갯수." 
::= { snmp 15 }

 snmpInGetNexts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Next PDU의 총 갯수." 
::= { snmp 16 }

 snmpInSetRequests 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Set-Request PDU의 총 갯수." 
::= { snmp 17 }

 snmpInGetResponses 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Response PDU의 총 갯수." 
::= { snmp 18 }

 snmpInTraps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Trap PDU 의 총 갯수." 
::= { snmp 19 }

 snmpOutTooBigs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'tooBig'인 SNMP PDU들의 총 갯수." 
::= { snmp 20 }

 snmpOutNoSuchNames 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수." 
::= { snmp 21 }

 snmpOutBadValues 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수." 
::= { snmp 22 }

-- { snmp 23 }은 사용되지 않는다.

 snmpOutGenErrs 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'genErr'인 SNMP PDU들의 총 갯수." 
::= { snmp 24 }

 snmpOutGetRequests 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Request PDU들의 총 갯수." 
::= { snmp 25 }

 snmpOutGetNexts 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Next PDU들의 총 갯수." 
::= { snmp 26 }

 snmpOutSetRequests 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Set-Request PDU들의 총갯수." 
::= { snmp 27 }

 snmpOutGetResponses 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Response PDU들의 총 갯수." 
::= { snmp 28 }

 snmpOutTraps 객체-유형 
구문 Counter 
접근 읽기전용 
상태 필수사항 
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Trap들의 총 갯수." 
::= { snmp 29 }

 snmpEnableAuthenTraps 객체-유형 
구문 INTEGER { enabled(1), disabled(2) } 
접근 읽기쓰기 
상태 필수사항 
기술 "SNMP 수행자 프로세스가 인증 실패 트랩들을 생성하도록 허용되었는지의 여부를 가리킨다. 이 객체의 값은 어떠한 구성 정보도 무시한다.

즉, 어떤 방법을 제공하는데 그 방법에 의해서 모든 인증 실패 트랩들이 생성될 수 없다.

 이 객체들을 비휘발성 기억소자에 저장하여 네트워크 관리 시스템의 재초기화 사이의 변함없는 값을 유지할 수 있도록 할 것이 강력히 권고되고 있음을 유의하여야 한다." 
::= { snmp 30 } 
  

 

6.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets," RFC 1065, TWG, August 1988.

[3] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol(SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, MIT Laboratory for 
Computer Science, April 1989.

[6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983.

[7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base", RFC1162, cisco Systems, Inc., June 1990.

[8] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 
1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International 
Standard 8825, December 1987.

[10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California.

[11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer", RFC 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The Wollongong Group, February 1989.

[12] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

[13] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer 
Science, May 1990.

[14] Rose, M., and K. McCloghrie, Editor, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems March 1991. 
  

보 칙

1. 이 표준에서 정하지 아니한 사항에 대하여는 "전산망 기술기준에 관한 규칙"의 관계 규정을 적용한다. 
  

부 칙

1. 이 표준은 1994년 3월 1일 부터 시행한다.

Posted by 두장
TAG Protocol, snmp
2009.10.29 16:18

ICMP 프로그래밍

윤 상배

dreamyun@yahoo.co.kr



1절. 소개

이문서는 실제로 ICMP 를 어떻게 이용할수 있는지에 대한 내용을 담고 있다. 간단한 ICMP 프로토콜에 대한 개요를 설명한후에 socket 를 이용해서 어떻게 ICMP 프로토콜의 사용이 가능한지에 대해서 얘기하게 될것이다.

이 문서는 여러분이 네트웍 프로토콜들과 TCP/IP 4계층과 socket 프로그래밍 환경에 대한 기본적인 이해를 하고 있다는 가정하에 만들어 졌다. 이들 내용은 이 사이트에서 여러개의 문서에 걸쳐서 다루고 있다. 네트웍 프로그래밍 섹션과 TCP/IP 섹션의 문서들을 참고하기 바란다.


2절. ICMP 프로토콜에 대해서

2.1절. ICMP 의 사용목적

ICMP 는 Inernet Control Message Protocol 의 줄임말이다. ICMP 프로토콜은 보통 다른 호스트나 게이트웨이 와 연결된 네트웍에 문제가 있는지 확인하기 위한 목적으로 주로 사용된다.

ICMP 를 이용한 가장 유명한 프로그램으로는 ping 프로그램이 있다. 우리는 ping 프로그램을 애용해서 특정한 게이트웨이, 호스트, 라우터 등이 제대로 작동을 하고 있는지 등을 조사하며, ICMP 요청에 대한 응답시간을 검사 함으로써 네트웍 상태도 어느정도 확인할수 있다.


2.2절. ICMP 프로토콜의 구조

ICMP 메시지는 기본적으로 IP header 를 이용해서 보내어진다. IP header 정보를 보면 (IP 자세히보기 를 참조하라), 9번째 필드가 protocol 을 위해서 사용되고 있음을 알수 있을것이다. ICMP protocol 을 위해서는 "1" 을 사용한다.

ICMP 는 다음과 같은 구조를 가진다. 첫번째 32 비트까지가 ICMP 헤더이며, 나머지부분은 ICMP 데이타이다. 이 데이타 영역은 ICMP의 어떤 기능을 이용할것이냐에 따라 다르게 설정될수 있다.

 0                                           31
 +------------+-------------+-----------------+
 | Type       | Code        | CheckSum        | 
 +------------+-------------+-----------------+
 | 가변 데이타                                |
 |                                            | 
			
Type 필드에는 ICMP 오류 메시지의 종류를 식별하는 코드가 채워진다. Code 는 각 Type 종류에 대한 자세한 오류의 유형을 알려주기 위해서 사용된다. 이 Type 에는 다음과 같은 종류가 있다.

표 1. ICMP Type 필드 유형

0 icmp echo replay icmp 요청에 대한 icmp 응답
3 Destination Unreachable Message 수신지까지 메시지가 도착할수 없음
4 Source Quench Message 송신지 억제
5 Redirect Message 재지시
8 icmp echo request 목적지 호스트에 ICMP 응답을 요청한다
11 Time Exceeded Message 데이타그램 시간초과(TTL 초과)
12 Parameter Problem Message 데이타그램에서의 파라메타 문제
13,14 Timestamp or Timestamp Reply Message 13:시간기록요청, 14:시간기록응답

Code 필드는 위에서 말했듯이 Type 에 따라 각각 다른 값을 가진다. 예를들어서 Type 3 번에 Code 0 번이 발생했을경우에는 오류 메시지 종류는 "수신지까지 메시지가 도착할수 없음" 이며, 그 이유는 Redirect datagrams for the Network, 즉 "네트웍을 획술할수 없음"이 된다. 이문서에서는 각 ICMP Type 에 따른 Code 까지 설명하진 않겠다. 이에 대한 자세한 내용은 rfc729를 참고하기 바란다.


3절. ICMP 프로그래밍

그럼 이제 ICMP 를 이용해서 실제 프로그래밍을 해보도록 하겠다.

ICMP 응답을 위해서 전송해야할 ICMP 헤더정보는 다음과 같다(rfc 문서에 정의되어 있음).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-
		
그러므로 우리는 Type, Code, Checksum, Identfier, Sequence Number 를 채워서 완전한 ICMP 패킷을 만들어줘야 한다. Type 는 8번이 될것이고, Code 는 0, Checksum, Identifier, Sequence Number 은 적당히 만들어줘서 채워주면 될것이다. Identifier 와 Sequence Number 는 내가 보낸 ICMP 응답에 대한 메시지인지를 확인하기 위한 목적으로 사용한다. 만약 내가 Identifier 를 120 으로 세팅해서 보냈다면, 수신된 ICMP 메시지의 Identifer 이 120인지를 확인함으로써, 내가 보낸 ICMP 요청에 대한 응답인지를 확인가능하다. 여기에 Sequence Number 를 이용함으로써, 패킷의 일련번호까지 확인할수 있다.

그럼 실제 프로그래밍 과정을 통해서 확인해 보도록 하자. 일단 socket 를 만들때 RAW 소켓(생소켓 혹은 날소켓이라고도 한다). ICMP 는 IP 와 같은 계층에 있음으로 TCP/UDP 소켓을 이용한 접근은 불가능하기 때문이다. 어쩔수 없이 RAW 소켓을 이용해서 직접 ICMP 헤더를 고쳐주어야 한다.

icmp 헤더를 세팅하는건 icmp 구조체에 필요한 값을 써줌으로써 간단히 해결할수 있다. icmp 헤더구조체는 /usr/include/netinet/ip_icmp.h 에 선언되어 있다. 구조체를 보면 상당히 많은 다양한 멤버 변수들을 가지고 있는데, 우리는 이들 값중 Type, Code, Checksum, Identifier, Sequence Number 만을 사용하면된다. 이들을 가르키는 멤버변수는 각각 icmp_type, icmp_code, icmp_id, icmp_seq 이다.

예제 : icmp_echo.c

	
#include <stdlib.h>
#include <string.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <arpa/inet.h>
#include <errno.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>

int in_cksum(u_short *p, int n);

int main(int argc, char **argv)
{
    int icmp_socket;
    int ret;
    struct icmp *p, *rp;
    struct sockaddr_in addr, from;
    struct ip *ip;
    char buffer[1024];
    int sl;
    int hlen;
    int ping_pkt_size;

    icmp_socket = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
    if(icmp_socket < 0)
    {
        perror("socket error : ");
        exit(0);
    }

    memset(buffer, 0x00, 1024);

    p = (struct icmp *)buffer;
    p->icmp_type=ICMP_ECHO;
    p->icmp_code=0;
    p->icmp_cksum=0;
    p->icmp_seq=15;
    p->icmp_id=getpid();

    p->icmp_cksum = in_cksum((u_short *)p, 1000);
    memset(&addr, 0, sizeof(0));
    addr.sin_addr.s_addr = inet_addr(argv[1]);
    addr.sin_family = AF_INET;


    ret=sendto(icmp_socket,p,sizeof(*p),MSG_DONTWAIT,(struct sockaddr *)&addr, sizeof(addr));
    if (ret< 0)
    {
        perror("sendto error : ");
    }

    sl=sizeof(from);
    ret = recvfrom(icmp_socket,buffer, 1024, 0, (struct sockaddr *)&from, &sl);  
    if (ret < 0)
    {
        printf("%d %d %d\n", ret, errno, EAGAIN);
        perror("recvfrom error : ");
    }

    ip = (struct ip *)buffer;
    hlen = ip->ip_hl*4;
    rp = (struct icmp *)(buffer+hlen);
    printf("reply from %s\n", inet_ntoa(from.sin_addr));
    printf("Type : %d \n", rp->icmp_type);
    printf("Code : %d \n", rp->icmp_code);
    printf("Seq  : %d \n", rp->icmp_seq);
    printf("Iden : %d \n", rp->icmp_id);
    return 1;
}

int in_cksum( u_short *p, int n )
{
    register u_short answer;
    register long sum = 0;
    u_short odd_byte = 0;

    while( n > 1 )
    {
        sum += *p++;
        n -= 2;
    
    }/* WHILE */


    /* mop up an odd byte, if necessary */
    if( n == 1 )
    {
        *( u_char* )( &odd_byte ) = *( u_char* )p;
        sum += odd_byte;
    
    }/* IF */

    sum = ( sum >> 16 ) + ( sum & 0xffff );    /* add hi 16 to low 16 */
    sum += ( sum >> 16 );                    /* add carry */
    answer = ~sum;                            /* ones-complement, truncate*/
    
    return ( answer );

} /* in_cksum() */
		
in_cksum 함수는 다른 ICMP 를 이용하는 프로그램에서 공통적으로 사용된다. checksum 을 만들기 위한 알고리즘 정도로 생각하면 될것 같다. 실제로 ping, aping, fping 등의 관련 어플리케이션에서 사용되어지고 있다.

이제 위의 코드를 컴파일한후 테스트를 해보자.

[root@local ping]# ./icmp_echo 66.218.71.89
reply from 66.218.71.89
Type : 0 
Code : 0 
Seq  : 15 
Iden : 2323
		
ICMP ECHO REPLY(Type 0) 로 ICMP ECHO(Type 8) 에 대한 응답이 왔음을 알수 있다. 또한 Seq과 Iden값을 이용해서 icmp_echo 가 보낸 어플리케이션의 ICMP ECHO 에 대한 응답임을 알수 있다.

심심한데? tcpdump 를 이용해서 실제 패킷이 어떻게 이동하는지 알아보자. 아래는 위의 결과를 tcpdump 한 화면이다. -x 는 16진수 코드로 출력받기 원할때 사용하는 옵션이다.

[root@coco ping]# tcpdump icmp -x
11:08:00.763994 eth0 > localhost > w10.scd.yahoo.com: icmp: echo request (DF)
                         4500 0030 0000 4000 4001 8b6f c0a8 6482
                         42da 4759 0800 d5f6 1309 0f00 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
11:08:00.933994 eth0 < w10.scd.yahoo.com > localhost: icmp: echo reply (DF)
                         4500 0030 8352 4000 3501 131d 42da 4759
                         c0a8 6482 0000 ddf6 1309 0f00 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
...
		
위의 dump 화면에서 하나의 문자는 4비트를 나타낸다. 위의 dump 를 간단히 분석해 보자면 4500 ~ 4759 까지가 TCP 헤더이고, 나머지 부분이 ICMP 헤더+데이타 부분임을 알수 있다(IP표준 헤더의 크기는 160 bit 임으로). ICMP 헤더부분은 0800 에서 d5f6 까지의 부분이며(ICMP 표준 헤더크기는 32 bit 임으로), 1309 이하가 ICMP 데이타 부분임을 알수 있다.

또한 우리는 IP 의 버전이 4 이고 프로토콜이 1을 사용하고 있음을 알수 있다. IP 헤더의 처음 4비트가 Version 정보를 나타내므로 4500 의 4가 version 정보, 5가 IHL정보 임을 알수 있다. 이런식으로 찾아보면 protocol 정보가 72bit 후에 존재하고 8bit 크기를 가짐으로 dump 의 5번째 값인 4001 의 01 임을 알수 있다. 그러므로 40 은 TTL 임을 알수 있을것이다. 또한 source address 는 c0a8 6482 destination address 는 42da 4759 임을 유추해 낼수 있을것이다(IPv4 의 주소체계에서 주소는 32비트 크기를 가짐으로). IP헤더 정보는 IP 자세히보기 를 참조하기 바란다.

그럼 ICMP 를 분석해보도록 하자. Type와 Code 는 각각 8bit 크기를 가짐으로 0800 이 Type 와 Code 를 가리킴을 알수있다. d5f6 는 cheksum 이며 1309 가 바로 Identifier 이다. 1309 가 정말로 우리가 입력한 Identifier 번호인 2323 인지 확인해보길 원한다면 10 진수를 16진수로 변환 가능한 계산기를 이용해서 계산해 보면된다. 0f 는 우리가 입력한 Sequence Number 15 임을 알수 있다.

w10.scd.yahoo.com 에서 넘어온 ICMP ECHO REPLAY dump 화면의 Identifier 과 Sequence Number 가 일치함을 알수 있다. 그러므로 우리는 해당 ICMP ECHO REPLAY 패킷이 우리가 전송한 ICMP ECHO에 대한 응답 패킷임을 알수 있다.

위 프로그램은 ICMP ECHO 체크를 위한 최소한의 기능만을 가지고 있다. 만약에 ICMP REPLAY 가 되지 않는 IP에 대해서는 계속 블럭된 상태로 있게 될것이다. 이럴때는 기다리는 시간을 체크하는 방법등을 이용해서 체크를 해주어야 할것이다.



출처 : http://joinc.co.kr/modules.php?name=News&file=article&sid=73&mode=nested

Posted by 두장

Libpcap 사용하기

노광민

           dalgu2 (at) kldp.org
        

libpcap의 정의와 사용법, 응용 등을 제시한다.

고친 과정
고침 0.4 2002-01-01 고친이 Kwang-Min Noh
Text 문서를 DocBook으로 수정 및 응용 부분 추가

Posted by 두장
2008.12.22 11:35

SNMP

윤 상배

dreamyun@yahoo.co.kr

교정 과정
교정 0.8 2003년 4월 20일 21시
최초 문서작성


1절. 소개

개인적으로 최근들어 SNMP에 관심을 가지게 되었다. (실은 상당히 오래되었지만) 그래서 앞으로 몇부? 에 걸쳐서 SNMP관련 강좌를 개설하고자 한다. 강좌는 SNMP개요및 설치운용에서 부터 시작해서 프로그래밍을 통해서 SNMP응용 애플리케이션을 제작하고, 확장 MIB(뒤에 설명한다)를 작성하는 것 까지를 다룰것이다.

이번글은 그중 첫번째 글로 SNMP개요와 설치및 운용에 대한 글이다. 설치및 운용은 실제 어떻게 작동되는지 눈으로 확인하는 차원의 수준에서 이루어질 것이며, 설치되는 snmp애플리케이션의 상세설치와 높은 수준에서의 운용에 대해서는 언급하지 않을것이다. 이러한 것들은 (필요할경우)해당 snmp애플리케이션의 메뉴얼을 참고해서 개인적으로 학습해야만 할것이다.

여기에서 얻은 지식은 나중에 SNMP애플리케이션을 제작하는 밑거름이 될것이다.


2절. SNMP개요

2.1절. SNMP란 무엇인가

SNMP는 Simple Network Management Protocol의 약자이다. 해석을 해보자면 간단한 네트워크관리를 위한 규약 인데, 말그대로 SNMP는 네트워크관리를 위한 용도로 사용되는 프로토콜이다. 가장 앞에 Simple라는 단어가 붙어있는데, 진짜로 간단한 프로토콜인지 아닌지는 사람에 따라 약간씩 차이가 있을수 있다. 필자가 보기엔 그리 복잡한 프로토콜은 아닌것 같은데, 어떤 사람들은 매우 복잡한 프로토콜 이라고 말하는 사람들도 있다.

그럼 먼저 SNMP가 나타난 배경에 대해서 알아보도록 하겠다. SNMP가 쓰이기 전에 일반적으로 사용되는 네트워크 관리는 ICMP에 의존했었다. ICMP는 Network계층의 프로토콜로써, 운영체제에 관계없이 사용할수 있는 간단한 프로토콜이였다. 이 프로토콜을 이용해서 우리는 네트워크로 연결된 각각의 호스트가 작동하고 있는지, 작동한다면 어느정도의 응답시간을 가지고 작동하는지 등의 간단한 정보를 얻을수 있었으며, 초기에는 이정도로도 필요한 네트워크 관리가 가능했었다. ICMP를 이용한 가장 유용한 도구는 아마도 ping 프로그램일 것이다.

그러나 인터넷의 사용이 보편화되고 네트워크에 연결된 호스트의 수가 증가하자 거기에 따라서 네트워크 구성역시 복잡해지고, ICMP만을 가지고는 이러한 네트워크의 관리를 효율적으로 할수 없게 되었다.

그래서 몇가지 프로토콜에 대한 연구가 진행되었고, SGMP, HIMS, CMIP/CMIS등이 제안되게 되었다. 이중에서 SGMP를 발전시킨 SNMP가 사실상 네트워크 관리를 위한 표준적인 프로토콜로 자리잡게 되었다. 다른 프로토콜들이 사용되지 않은데에는 몇가지 이유가 있었다. CMIP/CMIS는 너무 방대하고 너무 복잡했으며, HEMS의 경우에는 실제 적용사례가 적었기 때문이다.

어쨋든 SNMP는 거의 대부분의 운영체제에서 사용되어 지고 있다. 여러분이 사용하는 Linux, 그밖의 대부분의 유닉스와, 윈도우계열 운영체제는 기본적으로 SNMP프로토콜을 사용하는 도구들을 제공하고 있다. 그외에도 router등 TCP/IP를 네트워크 프로토콜로 사용되는 운영체제들 역시 SNMP는 필수적으로 제공하고 있다.


2.2절. SNMP로 할수 있는 것들

SNMP를 이용해서 할수 있는 것들은 다음과 같다.

네트워크 구성관리

네트워크상의 호스트들이 어떤 구조를 이루고 있는지 지도를 그리는게 가능하다.

성능관리

각 네트워크 세그먼트간 네트워크 사용량, 에러량, 처리속도, 응답시간 등 성능 분석에 필요한 통계정보를 얻어낼수 있다.

장비관리

SNMP의 주목적이 네트워크관리관리 이기는 하지만 SNMP특유의 유연한 확장성을 이용하여서 시스템정보(CPU, MEMORY, DISK 사용량)의 정보를 얻어올 수 있도록 많은 부분이 확장되었다. 이 정보는 네트워크문제를 해결하는데 큰도움을 준다. 예를들어 특정 세그먼트의 네트워크 사용량이 갑자기 급증했는데, 특정 호스트의 CPU사용율까지 갑자기 증가했다면, 우리는 해당 호스트에서 문제가 발생했을것이란걸 유추해낼수 있을것이다.

보안관리

정보의 제어 및 보호 기능, 최근버젼인 SNMP3는 특히 정보보호를 위한 기능이 향상되었다.


2.3절. SNMP를 통한 망의 구성

SMTP는 인터넷상에서 메시지를 교환하기 위한 프로토콜로 사용되며, 주로 전자메일 교환을 위해서 사용되는 프로토콜이다. 그러나 SMTP는 어디까지나 프로토콜일 뿐이며, 실제 메시지를 인터넷상에서 주고 받기 위해서는 SMTP프로토콜을 사용하는 SMTP서버(Sendmail같은)와 SMTP클라이언트(mutt, pine같은)가 준비되어 있어야만 한다.

SNMP역시 그자체로는 프로토콜일 뿐이며 SNMP프로토콜을 활용해서 실제 네트워크 관리 정보를 얻어오기 위해서는 응용 애플리케이션이 준비되어있어야만 한다. 보통의 네트워크프로토콜을 사용하는 애플리케이션이 서버/클라이언트 모델로 구성되듯이 SNMP역시 서버와 클라이언트로 구성된다.

그림 1. SNMP망 관리 시스템

일반적으로 SNMP망 에서는 서버/클라이언트라고 부르지 않고 snmp manager/snmp agent라고 부른다. snmp agent는 관리대상이 되는 시스템에 설치되어서 필요한 정보(네트워크 혹은 시스템)를 수집하기 위한 snmp 모듈(혹은 애플리케이션) 이며, snmp manager은 snmp agent가 설치된 시스템에 필요한 정보를 요청하는 snmp 모듈이다. snmp agent는 서버, snmp manager은 클라이언트로 생각하면 이해하기가 좀더 수월할 것이다(그러나 반드시 agent가 서버, manager이 클라이언트가 되는건 아니다. 그냥 개념적으로 이해만 하고 있도록 하자).


2.4절. MIB에 대해서

SNMP는 네트워크를 관리하기 위한 프로토콜이다. 그렇다면 무엇을 관리할 것인가(관리객체)를 결정해야 할것이다. 관리객체를 결정했다면, 이러한 관리객체를 효과적으로 관리하기 위해서 이를 분류해야 할것이다. 이게 바로 MIB이다.

MIB는 Man In Black의 줄임말이 아니다. Management Information Base의 줄임말인데, 관리되어야할 자원 객체의 분류된 정보를 말한다. 관리되어야할 객체는 시스템정보, 네트워크사용량, 네트워크 인터페이스정보 등이 된다.

이 MIB객체들은 관리하기 편하도록 Tree구조를 가지게 된다. 다음은 MIB의 일반적인 구조이다.

그림 2. MIB계층 구조

MIB는 위에서 처럼 계층적인(디렉토리) 구조를 가지게 된다(위의 그림은 MIB를 설명하기 위해 일부만을 표시하고 있다). 예를들어서 agent가 설치되어 있는 시스템으로 부터 시스템부가정보(sysDescr)를 얻어오길 원한다면 ISO.org.dod.internet.mgmt.mib-2.system.sysDescr과 같은 식으로 manger에서 데이타를 요청하면 된다.

위의 MIB계층 구조를 보면 각 MIB옆에 숫자가 있는것을 볼수 있다. 이 숫자가 OID번호이다. 즉 sysDescr의 OID값은 1.3.6.1.1.2.1.1.1 이 될것이다. OID번호를 이용하는 이유는 MIB고유 문자열을 통해서 원하는 데이타를 가져오기위해서는 아무래도 요청이 길어질수가 있기 때문이다.

MIB는 IANA(Internet Assigned Number Authority)라는 단체에서 관리하며 표준적으로 사용되고 있다. 그럼으로 표준적인 MIB구현을 위해서는 IANA에서 OID를 부여받아야만 한다. 그래야 전체네트워크상에서 다른 여러가지 MIB와 중복되지 않고 사용이 가능할것이다.

작은 정보: cisco과 같은 대중적인(거의 표준이나 마찬가지인) 제품들은 모두 자체적인 MIB를 구현해서 IANA에 등록하여 사용하고 있다. 여러분이 cisco 라우터등의 SNMP정보를 접근할수 있다면 cisco MIB가 등록되어 있음을 확인할수 있을것이다. 확인하는 방법은 다음 강좌에서 따로 언급하도록 하겠다.

MIB는 계층적 구조를 가짐으로 필요에 따라서 확장해서 사용이 가능하며, (물론 프로그래밍 능력이 있어야 하지만)때에 따라서는 자체 회사내에서만 사용가능하거나 제한된 네트워크 영역의 네트워크상황을 관제하는 제품을 위한 MIB를 추가해야 하는경우가 생길수 있을것이다. 그래서 사설로 MIB를 만들어서 사용할수 있는 여지를 남겨두었다. (마치 독립된 지역네트워크를 위해 사설IP를 사용하는 것처럼) 이러한 사설 MIB는 private(4)의 enterprises(1)에 정의해서 사용할수 있다. 여러분이 그리 대중적이지 않은 그래서 IANA에 등록되지 않은 어떤 장비의 고유 SNMP정보를 얻어오고 싶다면 업체에 문의하거나, 메뉴얼을 확인하는 정도로 쉽게 SNMP정보를 얻어올수 있다.

현재 MIB는 버젼 2까지나와 있으며, 버젼의 구분을 위해서 MIB-1, MIB-2로 부르고 있다. MIB-2는 MIB-1의 확장판으로 MIB-1의 모든 객체를 포함하여 약 171개의 객체들을 더 포함하고 있다. 최근의 제품들은 대부분 MIB-2를 지원하고 있다. 물론 위에서 말했듯이 독자적인 MIB를 만들어서 사용할수 있으며, 이를 확장 MIB라고 부른다.


2.5절. SNMP 프로토콜의 동작과 구성

현재 SNMP는 버전 3가지 나와있는 상태이지만 아직까지는 버젼2가 가장 널리 사용 되고 있다. 필자역시 SNMP 버젼 2에 대한 경험이 많은 관계로 버젼2를 기준으로 설명하도록 하겠다.

SNMP는 기본적으로 네트워크 정보를 수집하는데 그 목적이 있는데, 수집하는 몇가지 각각 다른 방법이 있다. 일반적으로 생각해서 우리가 생활중에 얻게 되는 정보는 우리가 요구해서 발생하는 정보와(신문을 구입한다든지, 인터넷으로 서핑을 하는등) 뉴스속보와 같은 형식으로 중요한 일이 있을때 발생하는 정보가 있을것이다. 또한 단지 정보를 얻는데 그치지 않고 정보를 입력하기도 한다.

SNMP정보수집역시 기본적으로 위의 일상생활에서의 정보수집과 같은 방식으로 이루어진다. 이하 snmp manager은 manager로 snmp agent는 agent로 부르도록 한다.

GET

manager에서 agent로 특정 정보를 요청하기 위해서 사용한다.

GET NEXT

기본적으로는 GET과 같은일을 한다. 그러나 SNMP에서 각정보들은 계층적 구조로 관리된다. 위의 MIB계층 구조를 나타낸 이미지에서 우리는 system(1)계층밑에 있는 모든 정보를 가져오고 싶을 때가 있을것이다. 그럴경우 GET NEXT를 사용할수 있다.

SET

manager에서 agent로 특정 값을 설정하기 위해서 사용한다.

TRAP

agent에서 통보해야될 어떤 정보가 발생했을때(임계치를 넘는네트워크자원 사용등) manager에게 해당 상황을 알리기 위해서 사용한다. 위의 다른 요청들이 동기적 요청이라면 이것은 비동기적 사건을 알리기 위해서 사용되어진다.

SNMP프로토콜은 기본적으로 어떤 정보를 요청하는 메시지와 이에 대한 응답메시지로 이루어지며 다음과 같은 구조를 가지고 있다.

표 1. SNMP 메시지

Version Community name SNMP PDU
Version은 말이 필요없다. SNMP프로토콜의 버젼번호를 나타낸다. Community name은 메니저와 에이전트간의 관계를 나타내는데, 인증, 접근통제등의 목적으로 사용된다. 보통은 간단하게 public을 사용한다. PDU 는 Physical Data Unit의 줄임말인데, 실제 전송되는 필요한 정보들을 담고 있는 Unit이다. Unit 이라고 하는 이유는 실제 전송되는 정보들의 부가 속성을 나타내기 위한 몇가지 값들을 포함하고 있기 때문이다. PDU는 PDU 타입(GET인지 Set인지 GET Next인지, TRAP인지등)과, Request-id, 실제보내고자 하는 데이타등(OID와 OID에 대한 값들)으로 구성되어 있다.

SNMP를 통해서 전달되는 메시지들은 기본적으로 UDP를 이용하게 된다. 바로위에서 PDU는 Request-id를 포함하고 있다고 했는데, 데이타그램처리방식인 UDP의 단점을 극복하기 위해서 사용되는 값으로, 각 메시지의 요청번호를 표시한다. 그래야만 수신된 SNMP메시지가 어떤 요청에 대해서 수신된 메시지인지 확인이 가능할것이기 때문이다.


3절. SNMP 설치 및 운용

그럼 실제로 시스템에 SNMP(agent와 manager 애플리케이션)을 설치해서 정보를 가져오는걸 간단히 테스트 해보도록 하겠다.

설치는 Linux(Kernel-2.4.x)에서 ucd-snmp로 할것이다. 위에서 설명했듯이, SNMP는 manager과 agent로 운영되게 되는데, 테스트의 편의를 위해서 하나의 시스템(localhost)에서 manager와 agent를 운용하도록 하겠다.


3.1절. ucd-snmp 설치

ucd-snmp는 net-snmp.sourceforge.net에서 얻을수 있으며 애플리케이션 관련 정보들도 얻을수 있다. ucd-snmp는 현재 버젼 5.x대까지 진행되어 있는데, 5.x부터는 net-snmp로 이름을 바꾸고 개발되어지고 있으며, 4.x버젼까지를 ucd-snmp라고 부르고 있다. 필자는 익숙한 ucd-snmp(버젼 4.x)를 설치하도록 할것이다. 비록 net-snmp가 최신이긴 하지만 별로 다루어본적이 없고, 대부분의 경우 아직까지는 ucd-snmp가 많이 사용되어지고 있기 때문이다. 최신이 아니라고 불만을 가질 필요는 없다. 근본적으로 net-snmp와 ucd-snmp간의 차이는 없으며, 우리의 목적은 최신의 snmp애플리케이션을 테스트하는게 아닌 snmp의 기능과 원리를 이해하고 이를 이용해서 필요한 응용 애플리케이션을 작성하는 것이기 때문이다.

위의 URL에서 ucd-snmp를 다운받아서 압축을 풀고 컴파일 하도록 하자. 컴파일 하는중에는 아마도 아무런 문제가 없을것이다. 컴파일은 매우 일반적인 방법을 따른다. 적당한 디렉토리에 압축을 풀고 ./configure, make, make install 하면된다.

	
[root@localhost src]# tar -xvzf ucd-snmp-4.2.6.tar.gz 
[root@localhost src]# cd ucd-snmp-4.2.6 
[root@localhost ucd-snmp-4.2.6]# ./configure  
[root@localhost ucd-snmp-4.2.6]# make 
[root@localhost ucd-snmp-4.2.6]# make install
			
헤에... 너무 간단하지 않은가 ?


3.2절. SNMP AGENT 실행

make install 까지 했다면 agent와 manager프로그램이 모두 설치되어 있을 것이다. 그리고 여기에 더불어 개발자를 위한 각종 라이브러리와 헤더파일들도 설치된다. 이 라이브러리와 헤더파일들은 개발할때 필요하며 다음 강좌에서 다루게 될것이다.

ucd-snmp는 agent 프로그램으로 snmpd를 제공한다. agent환경을 제대로 만들려면 복잡해보이는(사실은 그리 복잡하다고 볼수없는) 설정파일을 만들어줘야 하지만 이것은 각자의 몫이다. net-snmp프로젝트 홈페이지에서 제공하는 메뉴얼을 참고하기 바란다. 어쨋든 현재로써는 단지 snmpd를 띄우는 정도로 snmp agent환경을 만들수 있다.

[root@localhost root]# snmpd
			
이것으로 snmp를 테스트할 최소한의 agent환경이 구축되었다.


3.3절. SNMP MANAGER 테스트

3.3.1절. 동기적인 데이타 요청 - snmp get, get next

GETGET NEXT는 동기적인 정보요청을 위해서 사용한다. manager에서 agent에 대해서 정보를 요청했을때 해당 정보를 agent에서 보내주는 방식이다. GET은 단일정보요청을 위해서 사용하며, GET NEXT는 해당 계층의 하위에 있는 모든 정보의 요청을 위해서 사용된다.

ucd-snmp는 이러한 정보요청을 위한 manager프로그램으로 snmpgetsnmpnext, snmpwalk를 제공한다.

snmpget은 이름에서 알수 있듯이 agent로부터 특정한 정보를 얻어내기 위해서 사용한다. 정보를 얻기 위해 필요한 기본정보는 agent가 설치되어 있는 서버의 주소(혹은 이름) 와 커뮤니티(권한을 위한)이름 그리고 얻기 원하는 정보의 OID번호 혹은 MIB의 계층이름이다. 예를들어서 localhost로부터 public권한을 가지고 sysDescr(시스템 부가정보)정보를 얻어오고 싶다면 아래와 같이 하면 된다.

 
[root@localhost /root]# snmpget localhost public system.sysDescr.0
system.sysDescr.0 = Linux localhost 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
				
혹은 MIB이름대신에 OID번호를 사용해도 된다.
 
[root@localhost /root]# snmpget localhost public 1.1.0 
system.sysDescr.0 = Linux localhost 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
				

snmpwalk는 해당 MIB의 하위계층에 있는 모든 정보를 요청한다. 예를들어 system MIB의 하위 계층에 있는 모든 OID에 대한 정보를 요청하길 원한다면 아래와 같이 하면된다. 이게 가능한 이유는 snmpwalk가 정보를 요청하기 위해서 snmp메시지를 만들때 PDU타입을 GET NEXT를 사용하기 때문이다. 나중에 직접구현하게 될것이다. 지금은 구현에 신경쓰지 말자.

[root@localhost /root]# snmpwalk localhost public system
system.sysDescr.0 = Linux localhost 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (2685699) 7:27:36.99
system.sysContact.0 = yundream@joinc.co.kr
system.sysName.0 = localhost
system.sysLocation.0 = myhome 
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00
....
				
system하위의 모든 OID에 대한 정보를 얻어오고 있음을 확인할수 있다.

snmpgetnext는 snmpwalk의 기능 축소판정도로 볼수 있을것이다. 즉 MIB계층구조에서 현재 요청한 OID의 다음 OID의 정보를 가져온다. 예를들어 system.sysDescr.0에 대한 정보를 요청하면 다음 OID인 system.sysObjectID.0의 정보를 요청하게 될것이다. 이게 가능한 이유는 snmpwalk와 마찬가지로 내부적으로 GET NEXT를 이용하고 있기 때문이다. snmpwalk가 더이상 얻을수 없을때까지 OID를 요청하는것과 달리 snmpgetnext 바로다음의 OID만을 요청한다.

 
[root@localhost /root]# snmpgetnext localhost public system system.sysDescr.0
system.sysDescr.0 = Linux localhost 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
				


3.3.2절. 비동기적인 데이타 요청 - snmp trap

기본적으로 GET, GET NEXT를 통한 데이타요청은 일정한 polling시간을 가지고 manager에서 agent로 필요한 정보를 요청하는 방식이다. 그러나 이걸 이용해서는 비동기적으로 발생하는 정보를 수집할수가 없다.

이러한 비동기적인 정보는 여러가지가 될수 있다. 예를들면 특정 네트워크 세그먼트에 문제가 생겼다거나 디스크나 메모리용량을 과다하게 사용하고 있다거나(많은 운영체제의 경우 시스템정보까지도 snmp를 통해서 얻을수 있도록 허용하고 있다)하는 사건들은 비동기적으로 발생할것이다. 이럴경우에는 agent에서 manager측으로 사건을 통보해야 할것이다. 이렇게 agent에서 manager측으로 비동기적으로 사건을 통보하는 것을 SNMP TRAP라고 한다(간단히 말해서 경고메시지 보내는거다).

ucd-snmp에서는 이러한 trap정보를 전송하고 받기 위해서 snmptrapdsnmptrap를 제공한다. snmptrapd는 agent에 제공되는 데몬프로그램으로 manager에서의 trap데이타 발생을 기다린다. snmptrap는 agent에 설치되어서 사용될수 있으며 trap데이타를 manager로 전송하는 일을한다.

이 snmptrap은 꽤 유용하게 사용할수 있다. 간단하게 스크립트로 만들어서 어떤 파일이 변조되었을경우 trap정보를 manager쪽으로 발생시킨다거나, 프로세스 갯수가 일정갯수 이상 초과했을때 이를 전송한다든지 하는 기능을 비교적 간단하게 추가시킬수 있을것이다.

다음은 ucd-snmp에서 제공하는 trap애플리케이션을 이용한 간단한 테스트이다. 먼저 snmptrapd를 manager측에서 실행시켜야 한다. 이 애플리케이션은 옵션없이 실행할경우 데몬모드로 실행되며 표준출력을 시키지 않음으로 다음과 같이 옵션을 주고 실행시켜서 일반모드(forground)에서 받은 trap정보를 표준출력하도록 실행시키도록 하자.

[root@localhost root]# snmptrapd -f -P
2003-04-23 00:13:34 UCD-snmp version 4.2.6 Started.
				
이제 agent측에서 snmptrap를 이용해서 trap정보를 manager로 전송해보도록 하자.
[root@localhost root]# snmptrap -v 2c -c public localhost "" ucdStart sysContact.0 s "yundream"
				
그러면 manager로 system.sysContact.0="yundream" 과 같은 정보가 전달되는걸 확인할수 있을것이다.

이들 ucd-snmp에서 제공하는 애플리케이션들의 자세한 사용법은 메뉴얼 페이지를 참고하기 바란다.


4절. 결론

이상 SNMP의 개념과 개념의 이해를 위해서 실제 사용되는 snmp애플리케이션을 설치해서 간단히 운영테스트까지 해보았다. 이러한 운영테스트를 위해서 ucd-snmp를 사용했는데, 다음 강좌는 ucd-snmp에서 제공하는 snmplib를 통해서 snmp애플리케이션을 만드는 법을 다루도록 하겠다. 

Posted by 두장
이전버튼 1 이전버튼