공유기 로그 ACK = acknowlegement 

udhcpd dhcp server...


SNMP에 대해 알아보자.

SNMP를 설명하기 전에 나오게 된 배경부터 보면,

과거에는 ping과 같은 툴을 이용하여 데이터 송수신에 대한 가능/불가능 확인을 함으로써 네트워크 시스템을 관리하였으나 현재는 네트워크로 연결된 시스템들의 복잡도가 굉장히 증가하였고, 이에 따라 문제 파악이 쉽지 않아져서 “관리”의 필요성이 대두되었다.

이러한 필요성에 의해 SGMP(Simple Gateway Monitoring Protocol)이 만들어졌고, 이는 아래와 같은 장점을 가졌다.

  • PING보다 더 많은 기능
  • 보다 직관적이고 쉽게 네트워크 문제 파악
  • 표준화된 프로토콜

이 때 CMIP라는 표준이 나왔으나 많은 표준이 그렇듯, 유럽/북미 간의 규격 싸움으로 인해 표준안 정립이 늦어졌고, SGMP가 진화한 SNMP가 암묵적인 표준이 되었다.

역시 이런 뒷 얘기들(?)을 알면 재밌다.

SNMP (Simple Network Management Protocol)은 말 그대로  프로토콜이라 통신 규약일 뿐이다. 따라서 SNMP 자체가 네트워크 장비를 직접 관리하지 않는다.

그래서 네트워크 관리를 위해 필요한 개념이 있다.

  • Manager
  • Agent
  • MIB (Management Information Base)

 

SNMP를 이용한 관리 시스템의 개념도

SNMP를 이용한 관리 시스템의 개념도

 

Manager란 관리를 하는 서버이고 Agent는 관리의 대상이 되는 서버이다. 일반적으로 Manager가 Agent에게 요청을 하고 Agent는 요청에 따른 정보를 수집하여 Manager에게 제공한다. 그 외에도 Agent는 Manager의 요청 없이 특정 정보를 알림을 통해 전달하기도 한다. 마지막으로 MIB는 각 Agent에 존재하고, 이는 필요한 정보가 저장되어 있는 데이터베이스이다.

물론 여기서 말하는 서버는 논리적 개념의 서버이고, 꼭 하드웨어로 분리되어야 하는 것은 아니다.

MIB에 대해 좀더 자세히 알아보자. 이 문서는 Novonetworks 기술문서: SNMP 개념 이해 를 참고하였으며, 기본 개념 설명에 사용된 예를 그대로 활용하였다.
설명하기에 앞서 OOP를 해본 사람이라면 이해에 큰 무리가 없다. Object / Instance를 구분할 줄 안다면..

MIB는 앞서 말했듯이 Agent가 정보를 저장하는 방식이다. MIB는 Object의 집합으로, 트리 형태로 저장되어 있다.

 

MIB는 객체의 집합이다.

MIB는 객체의 집합이다.

객체와 인스턴스와의 관계

객체와 인스턴스와의 관계

 

이처럼 Object는 특정 레이아웃(?)이 정의된 자료구조라고 보면되고, Instance는 그 자료구조에 들어간 값을 의미한다.

위와 같은 개념 말고 실제 구조를 보면 앞서 말했듯 트리 형태로 유지가 되고 각 Object는 Object name과 Object ID(OID)를 가진다. 일반적으로 OID를 이용하여 접근을 한다.

 

MIB의 예

MIB의 예

 

위 그림처럼 OID를 이용하여 접근할 수 있다. 시스템 설명 부분의 경우 1.1.1로 접근이 가능하다.

하지만! 이는 Object에 대한 접근이지, Instance에 대한 접근이 아니다. 즉 Instance를 얻기 위해서는 Instance ID를 알아야 한다.

이는 Object의 종류에 따라 Instance ID 접근이 다른데, Object 종류는 Scalar Object, Table Object로 나뉜다.

  • Scalar Object: 특정 자료구조를 갖지 않고 “값”만을 가진 형태로, Instance ID는 Object ID+.0이다. 즉 위 예중 시스템 설명 부분의 Instance ID는 1.1.1.0이다.
  • Table Object: 테이블 형태의 자료구조에 값을 가진 형태로, 특정 컬럼을 Row의 인덱스로 활용

Table Object의경우 예를 보는 편이 이해가 빠르다.

Table Object를 예시를 위한 그림

Table Object를 예시를 위한 그림

위 그림의 IP테이블에서 첫번째 컬럼을 인덱스로 활용한다고 가정할 때 IP테이블의 3번째 row의 2번째 컬럼 값을 얻을 경우에는 1.2.3.2.2.3이 된다.

1.2.3 / 2.2 / 3

테이블 Object ID / 원하는 위치의 Object ID / Index

이처럼 이뤄져있다. 즉 원하는 위치의 Object ID만을 알면 안되고 원하는 위치 Object와 같은 로우에 있는 Index(Instance 값)까지 알아야 한다. 이 얼마나 불편하단 말인가.. 내가 원하는 Instance 값을 얻기위해 다른 곳의 Instance 값을 얻어야 하는 불편함이란..!

SNMP는 이를 위한 방안을 가지고 있다. 바로 트리구조를 이용한 방법인데, MIB가 Ordering을 가지고 순회 순서를 가지고 있는 것이다.

순회 순서는 root를 시작으로 왼쪽에서 오른쪽 방향이고 Table Object도 왼쪽 상단->왼쪽 하단->오른쪽 상단->오른쪽 하단 순으로 Ordering을 갖는다.

MIB 순회 순서

MIB 순회 순서

 

이와 같이 순회 순서를 정하고 GetNext Request를 지원한다. GetNext Request란 전달한 Object ID 혹은 Instance ID와 가장 인접한 Instance ID와 값을 반환하는 요청이다.

예를 들어 GetNext Request로 1.1을 전달하면 1.1.1.0이 나온다. 순회 순서가 왼쪽부터 이기 때문이다.


 

이제 MIB의 구조와 접근 방법을 알았으니 SNMP 에서 어떤 명령어들을 통해 이를 관리하는지 알아보자.

Manager와 Agent간의 명령어는 맨처음 관리 시스템 개념도에서 알 수 있듯이 아래 3가지로 이루어져있다.

  • Get: Manager가 Agent로부터 MIB를 읽음
  • Set: Manager가 Agent의 MIB를 변경
  • Trap: Agent가 Manager에게 정보를 전송 (Notification)

위 명령어를 주고 받기 위해 아래 메시지를 사용한다.

  • GetRequest: (Manager->Agent) 전달하는 Instance ID의 값을 요청
  • GetNextRequest: (Manager->Agent) 전달하는 Object ID or Instance ID와 가장 인접한 Instance의 ID와 값을 요청
  • SetRequest: (Manager->Agent) 전달하는 Instance ID의 값을 변경
  • Response: (Agent->Manager) 요청의 성공 유무 및 데이터를 전달
  • Trap: (Agent->Manager)  중요한 사항에 대해 요청에 무관하게 메시지를 전달

 

Get 커맨드 동작 개념

Get 커맨드 동작 개념

먼저 Get과 관련된 명령어인 GetRequest와 GetNextRequest는 결국 요청하는 Instance를 얻어오는 명령이다. 각 요청에 대한 응답으로 ‘Response’가 오고 GetRequest의 경우 Object ID를 전달하거나 MIB에 없는 Instance ID를 전달할 경우 에러를 발생시킨다.

RequestGet RequestGetNext Request
Object ID (1.1.1)ErrorInstance
Instance ID (1.1.1.0)Instance ID: (1.1.1.0)
Instance Value: System ~~
Instance ID: (1.1.2.0)
Instance Value: Alghost-PC ~~
Instance ID (1.1.4.0)
(MIB에 존재X)
ErrorInstance ID: (1.2.1.0)
Instance Value: Forwarding

Set과 관련된 명령어는 SetRequest가 있고, 요청한 Instance의 값을 변경한다. 마찬가지로 요청에 대한 응답으로 ‘Response’가 오고 성공 유무가 전달된다.

Set 커맨드 동작 개념

Set 커맨드 동작 개념

Trap 명령어는 Agent가 Manager에게 중요한 사항(Pre-defined)에 대해 보고를 하는 명령어로 Manager로부터 응답은 없다.

SNMP를 이용하여 관리 시스템을 구축하는 이유중 하나가 바로 이  Trap을 사용하기 위한 것인데, 이는 규격에서 제공하는 Trap 외에도 관리자가 직접 정의할 수 있다.

  • 규격) 장비가 특정 이유로 재시동 되었다면, Agent는 ‘ColdStart’ Trap을 발생시킨다.
  • 규격X) 장비의 온도가 40도 이상일 경우 알림을 사전 정의, 온도가 40도 이상이 될 경우 Agent는 Trap을 발생시킨다.
Trap 커맨드 동작 개념

Trap 커맨드 동작 개념

 


 

설명한 SNMP를 간단히 사용해보기 위해 net-snmp를 활용하여 실습해본다. 테스트한 환경은 CentOS 7이 설치된 서버이다.

net-snmp 설치 및 설정
  1. $ yum -y install net-snmp net-snmp-utils
  2. $ cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig
  3. $ vi /etc/snmp/snmpd.conf
  4. 41: com2sec not ConfigUser default YOUR_COMMUNITY
MIB의 모든 정보를 가져오기
  1. $ snmpwalk -v 2c -c YOUR_COMMUNITY HOST
  2. SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64
  3. SNMPv2-MIB::sysObject_ID.0 = IOD: NET-SNMP-MIB::netSnmpAgentIODs.10
  4. ...
snmpget으로 MIB Instance 가져오기
  1. $ snmpget -v 2c -c COMMUNITY 127.0.0.1 sysContact.0
  2. SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
  3. $snmpget -v 2c -c COMMUNITY 127.0.0.1 sysContact #OID를 입력한 경우
  4. SNMPv2-MIB::sysContact = No Such Instance currently exists at this OID
snmpgetnext으로 MIB Instance 가져오기
  1. $ snmpgetnext -v 2c -c COMMUNITY 127.0.0.1 sysContact.0
  2. SNMPv2-MIB::sysName.0 = STRING: localhost.localdomain
  3. $ snmpgetnext -v 2c -c COMMUNITY 127.0.0.1 sysContact # OID를 입력한 경우
  4. SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> (configure /etc/snmp/snmp.local.conf)

 

위처럼 CLI를 이용하여 가져올 수 있고 GUI로 트리를 확인할 수 있다.

mbrowse를 활용한 MIB 트리 확인

mbrowse를 활용한 MIB 트리 확인

여담이지만 GUI 프로그램에 Object Identifier 부분을 보면 CLI때와 Depth가 차이나는데 이는 CLI 설정(/etc/snmp/snmpd.conf)에 .iso.org.dod.internet.mgmt.mib-2.system이 기본 PATH에 추가되있기 때문이다.

 

사실 SNMP 자체의 용도가 현업에서 얼마나 필수로 작용하는진 모르겠지만 Trap은 많은 곳에서 중요한 요소로 활용되고 있다. 직접 Trap을 생성해서 테스트 해보는 것도 좋을 것 같다. :D

Alghost
Follow me

Alghost

Researcher at Gluesys Co.,Ltd.
개발자 블로그지만 개발 이야기만 하지 않습니다

관심분야: Storage system, Flash memory, Distributed System, Web, Mobile


+ Recent posts