SNMP - 네트워크 관리 개요 및 SNMP 프로토콜 동작과정 김재환

Presentation on theme: "SNMP - 네트워크 관리 개요 및 SNMP 프로토콜 동작과정 김재환"— Presentation transcript:

1 SNMP - 네트워크 관리 개요 및 SNMP 프로토콜 동작과정- 20021455 김재환

2 Contents SNMP? 목표와 체제 관리 모형 및 구조 메시지 MIB 목차로는 다음과 같습니다.

3 SNMP? Simple Network Management Protocol
TCP/IP 네트워크에서 사용되는 네트워크 관리 소프트웨어 SNMP(Simple Network Management Protocol)는 네트워크 장비를 관리 감시하기 위한 목적으로 TCP/IP 상에 정의된 응용 계층 프로토콜이다. SNMP는 네트워크 관리자가 네트워크 성능을 관리하고 네트워크 문제점을 찾아 수정하는데 도움을 준다. 네트워크상에서 문제점 진단 및 해결이란 발생한 문제점을 복구하는 데 반드시 필요하다. 하지만, 네트워크 관리자의 궁극적인 목표는 바로 이런 문제점이 발생하지 않도록 하는 일이다. 이는 네트워크 관리 소프트웨어의 궁극적인 목표이기도 하다. TCP/IP 네트워크에서 사용되는 네트워크 관리 소프트웨어는 바로 SNMP(Simple Network Management Protocol, 네트워크 관리 프로토콜)를 이용한 것들이다.

4 목표와 체제 ● “SNMP는 관리 에이전트 스스로가 파악한 관리 기능의 수와 복잡성을 최소화한다.” - RFC 1157 -
프로토콜을 지원하려는 업체들의 부담이 줄어들어 그 프로토콜을 폭넓게 수용. ● SNMP는 확장성이 좋아서 업체들이 네트워크 관리 기능을 추가하기가 쉽다. SNMP는 단순하도록 설계되어있다. SNMP는 이것을 세 가지 방식으로 해결한다. RFC(Request for Comments) 문서는 비평을 기다리는 문서라는 의미로, 네트워크공학 등에서 인터넷 기술에 적용 가능한 새로운 연구, 혁신, 기법 등을 아우르는 메모를 나타낸다. 인터넷 협회(Internet Society)에서 기술자 및 컴퓨터과학자들은 RFC 메모의 형태로 생각을 출판하게 되며, 이러한 출판의 목적은 자신의 새로운 생각 및 정보에 대해 전문가 비평을 바라는 것, 혹은 그러한 생각을 단순히 전달하는 것이다. 때로는 공학적인 유머를 위해서이기도 하다(만우절 RFC를 참조하기 바란다). 인터넷국제표준화기구(IETF)는 일부 RFC를 인터넷 표준으로 받아들이기도 한다. ● SNMP는 호스트나 라우터 등의 하드웨어 장치들이 구성하고 있는 체제에서 관리 체제를 분리시켜서 복수 업체 지원 체제의 폭을 넓혔다.

5 SNMP 기반의 TCP/IP 네트워크 관리 모형
TCP/IP 관리 구조는 네트워크 상에 관리 에이전트(SNMP agent)가 탑재되어 있고 중앙의 관리국이 이런 에이전트로부터 각 네트워크 장비의 관리 정보를 모니터링 함으로써 이루어진다. 이때 각 관리 에이전트와 관리국간의 네트워크 관리 정보를 전송하기 위해 사용되는 네트워크 관리 프로토콜이 SNMP이다 TCP/IP에서 사용되는 네트워크 관리 모형은 다음의 주요 요소가 있다.       관리 에이전트 관리 정보 베이스(Management Information Base : MIB) 네트워크 관리 프로토콜(SNMP) 이와 같이 네트워크 관리자, 엔지니어의 부담은 가중되고 있으며 그 역할이 매우 중요하게 되었다. 네트워크 관리자의 부담이 증가함에 따라 네트워크 관리자가 복잡한 망을 효과적으로 다룰 수 있도록 지원하며 데이터가 최대한 효율성을 가지고 전송될 수 있도록 하는 기능이 필요하게 되었다.

6 관리 체제의 구조 SNMP는 크게 4가지 요소로 구성된다.
Management Station(관리 시스템) Management Agent를 통한 네트웍 장비 모니터 및 관리 Management Agent(SNMP agent) 네트웍 장비에 위치하며, 관리시스템으로부터의 정보 요청과 설정 명령을 실행한 후 응답을 보낸다. Network Management Protocol 관리 시스템과 네트웍 장비간의 통신에 사용되는 프로토콜 Management Information Base(MIB) 네트웍 장비 정보 데이터 SNMP에 의한 관리 구조는 다음 그림과 같이 agent와 manager의 구조로 되어 있다. 여기서 MIB(Management Information base)란 네트워크 요소들이 유지하는 정보를 말하는 것으로 Agent들은 네트워크 노드에서 그 노드에 대한 정보를 유지하고 있다. Manager는 전체 네트워크에 대한 MIB 명세서를 가지고 각각의 agent가 관리하는 MIB를 수집해서 관리한다.

7 프로토콜 구조 ● TCP/IP 스택 중에 응용 프로그램 계층(Application Layer)에 해당되는 프로토콜
전송계층에서는 UDP를 사용하며 161, 162 두 개의 포트를 통해 메시지를 주고 받는다.

8 메시지 종류 ● agent와 manager 사이에 전달되는 정보의 완성된 형태 SNMP Manager SNMP Agent
Get-Request port:161 Get-Next-Request port:161 Set-Request port:161 Get-Reponse 메시지 : agent와 manager 사이에 전달되는 정보의 완성된 형태 Manager가 agent에 질의하면 agent는 이에 대한 응답을 되돌리는 형식으로 정보를 주고 받는데 이를 위해 총 다섯개의 메시지 종류를 정의하고 있다. Get-Request : agent가 관리하는 MIB 자료를 하나 가져올 것을 요청한다. Get-Next-Request : agent가 관리하는 MIB 자료를 순차적으로 여러 개 가져올 것을 요청한다. Set-Request : agent가 관리하는 MIB 자료의 값을 설정한다. Get-Resonse : Manager의 질의에 대한 결과를 되돌려 준다. Trap : agent에 특별한 이벤트가 발생할 경우 이를 manager에 알린다. Port: Trap

9 메시지 형식 SNMP를 이용한 인터넷 관리에서 관리국과 SNMP 에이전트간의 정보 교환은 SNMP 메시지의 형태로 교환된다. SNMP는 세 가지 버전이 있는데 현재 대부분의 에이전트가 지원하는 것은 버전 1이다. 버전 2와 3는 현재 연구와 적용 실험중이다. 따라서 각 메시지는 첫 번째 필드에 SNMP의 버전을 나타내는 버전 번호를 포함한다. 그리고 두 번째 필드는 community라는 필드인데 이 필드는 에이전트로의 접근을 허가하는 일종의 패스워드 역할을 수행한다. SNMP PDU에는 5가지 종류가 있다. SNMP PDU의 첫 번째 필드는 PDU type을 지시하며 이 필드를 통해 5가지 PDU 종류가 구분된다. [그림 4-5]는SNMP PDU 포맷을 보여주며, 그림 (b)의 PDU는 GetRequest PDU, GetNextRequest PDU, 그리고 SetRequest PDU를 나타내며 (c)는 GetResponse PDU를, (d)는 Trap PDU를 나타낸다. 각각의 다섯 PDU는 ASN.1 형태에 의해 개별적으로 정의된다. 그리고 각 PDU의 variablebindings 필드는 이름과 값의 필드들로 이루어진다. GetRequest PDU는 피관리 에이전트의 MIB 오브젝트 값을 읽어오기 위한 메시지이다. PDU 포맷의 두 번째 필드인 request-id필드는 SNMP 개체가 신뢰할 수 없는 전송 서비스로 인해 메시지가 중복되는 것을 막게하기 위한 식별 필드이다. 그리고 variable binding필드에는 에이전트로 요청되는 오브젝트 원소의 목록을 포함한다. 이 메시지의 응답에서 GetResponse PDU로 응답하는 SNMP 개체는 위와 같은 request-id를 포함시킨다. GetNextRequest PDU는 GetRequest PDU와 거의 동일하다. 둘은 거의 같은 교환 형태를 지니며 같은 형식을 갖고 있다. 유일한 차이점은 GetRequest PDU는 주어진 오브젝트에 대한 값이 결과로 돌아오는 반면에 GetNextRequest PDU는 주어진 오브젝트의 사전적 순서의 다음 오브젝트의 값이 돌아온다는 것이다. SetNextRequest PDU는 GetRequest PDU와 거의 동일하나 SetRequest는 피관리 에이전트의 특정 MIB 오브젝트 값을 읽기보다는 쓰기를 위한 동작이다. 그러므로 variable binding의 목록에 오브젝트 원소와 값의 형식, 쓰고자 하는 값을 모두 넣어줘야 하는 것이다. Trap PDU는 SNMP 개체에 의한 대표적인 네트워크 관리국 응용이다. Trap은 관리국에 비동기적인 중요한 사건의 발생을 알린다. PDU 형식은 다른 PDU와는 상당히 다르다. 각 필드는 다음과 같다.

10 SNMP가 지원하는 동작 ● MIB 오브젝트 값의 변경과 검색
- get : 관리국이 에이전트의 MIB 오브젝트 값을 검색해온다. - get next : get과 같은 일, 각 정보들은 계층적으로 관리하는 것이 다름 - set : 관리국이 에이전트의 write 가능한 MIB오브젝트 값을 설정한다. - trap : SNMP 에이전트가 관리국에 자발적으로 특정 사건을 보고하는 오브젝트 값을 보낸다. Get : 관리 시스템은 정보를 모집하기 위하여 SNMP Agent가 탑재된 관리대상 장비로 SNMP Request명령을 보낸다. SNMP Agent는 요구한 장비 정보와 SNMP Response를 보낸다. Set : 관리 시스템이 관리 대상 장비의 MIB값을 셋팅한다. Trap : 긴급한 사건에 대하여 SNMP Agent가 관리 시스템으로 알림 정보를 보낸다.

11 SMI ● SNMP MIB들을 정의하기 위한 일반적인 구조 ● MIB 객체들은 ASN.1 문법에 따라 정의
- 이름과 표기 문법, 전송을 위한 인코딩 규칙을 가짐 ● SNMP MIB에서 사용되는 객체들은 RFC1155에 ISO의 표준안에 따라 정의 SNMP 환경에서 데이터들이 어떻게 표현되어야 하는지를 정의한다. SMI는 RFC 1155와 RFC 1065 Structure and Identification of Management Information for TCP/IP-based Internets에 설명되어 있다. SMI는 관리 객체들이 어떻게 명명되는지, 이들의 문법은 어떻게 되는지, 네트워크를 통해 전송될 때 어떻게 인코딩되는지 등을 정의한다. SMI는 앞에서 언급한 ISO에 기반하고 있다. 각 관리 객체들은 객체 지시자(object identifier)라는 유일한 이름을 부여받는다. 이 객체 지시자는 ISO에 의해 관리되는 계층적 이름 구조의 한 부분이다. 이 계층적 이름 구조는 DNS와 마찬가지로 각 이름이 유일하게 사용되는 것을 보장하기 위해 사용된다. 객체 지시자에서 각 계층은 숫자로 구분된다.

12 MIB의 구조 ● ASN.1이라는 추상 구문 표기법에 의해 정의
● 각 오브젝트는 계층적인 OBJECT IDENTIFIER로서 식별 ● 정수의 연속된 나열로 표시 ● 정의된 오브젝트의 집합은 트리 구조 ● 식별자 정의 directory OBJECT INDENTIFER ::={internet 1} Directory -> O-ID 이름 Internet -> Parent O-ID 1 -> O-ID 번호 SNMP로 관리되는 모든 객체들은 ASN.1 문법에서 정의한 유일한 객체 지시자와 BER에서 정의한 인코딩을 갖는다. 이들 유일한 객체들을 통틀어 MIB(Management Information Base)라고 한다. MIB는 SNMP에 의해 관리되는 모든 정보들을 일컫는다. 하지만, 일반적으로 “a MIB" 또는 ”the MIBs(복수)“는 RFC에서 정의된 각각의 관리 정보 데이터베이스를 가리킨다.

13 MIB의 구조 Internet OBJECT IDENTIFIER ::={iso(1) org(3) dod(6) 1}
MIB는 위에서처럼 계층적인(디렉터리) 구조를 가지게 된다(위의 그림은 MIB를 설명하기 위해 일부만을 표시하고 있다). 예를 들어서 agent가 설치되어 있는 시스템으로부터 시스템부가정보(sysDescr)를 얻어오길 원한다면 ISO.org. dod. internet. mgmt.mib-2. system.sysDescr과 같은 식으로 manger에서 데이터를 요청하면 된다. 위의 MIB계층 구조를 보면 각 MIB옆에 숫자가 있는 것을 볼 수 있다. 이 숫자가 OID번호이다. 즉 sysDescr의 OID값은 이 될 것이다. OID번호를 이용하는 이유는 MIB고유 문자열을 통해서 원하는 데이터를 가져오기 위해서는 아무래도 요청이 길어질 수가 있기 때문이다.

14 MIB의 구조 ● internet 노드 밑에는 다음과 같은 4 개의 노드가 정의된다.
  - directory : 이 서브트리는 나중의 OSI directory (X.500)를 위해 예약된다.   - mgmt : 이 서브트리는 IAB에서 정의한 오브젝트들 용으로 쓰인다.   - experimental : 이 서브트리는 Internet에서 실험적인 오브젝트를 나타낸다.   - private : 이 서브트리는 주로 특정 벤더/개인의 오브젝트를 나타내기 위해 쓰인다.

15 MIB II ● MIB의 두 번째 버전 (RFC – 1213에 정의) (첫번째 버전인 MIB-I은 RFC1156에 나타남)
● TCP/IP 프로토콜 상에서 관리되어야 하는 객체들에 관해 정의 ● 가장 대중적으로 사용되는 MIB

16 Thank you 이상으로 발표를 마치고 질의 응답 시간을 가지겠습니다.