SNMP (Simple Network Management Protocol)란

탄생 배경 

TCP/IP 초기 네트워크 환경에서는 ICMP(Ping)를 이용하여 장비 간의 연결 상태를 Check 하였으나 이는 단순하게 네트웍 장비의 작동 여부 및 응답 시간을 측정하는 등의 기능만을 제공하였다.

 

인터넷이 보편화되고 Host가 대폭적으로 증가하고 네트웍 구성이 복잡해짐에 따라 새로운 표준화된 프로토콜이 필요하게 되었다.

 

1988년에 IAB에서 표준화 작업을 진행하였고 그 당시에 연구가 진행됐던 HIMS, SGMP, CMIP/CMIS 중에서 SGMP를 발전시킨 SNMP를 표준으로 채택하게 되었다.

---

SNMP란

SNMP란 네트워크 장비를 Manage 및 Monitoring 하기 위한 목적으로 UDP 상에 정의된 응용 계층 표준 프로토콜이다.

일반적으로 서버, 네트웍 장비, SNMP 설정이 가능한 장비들에 대한 정보 (CPU 및 Memory Usage, Port Up/Down Status 등등)를 수집하여 NMS라는 네트웍 관리 시스템에서 Manage 및 Monitoring 하기 위해 사용되어진다.

---

동작 방식

Manager (ex. NMS)는 3가지 형태의 SNMP 메시지를 생성하여 Agent로 전송하고 Agent는 GetResponse 메시지로 응답한다. (GetRequest, GetNextRequest, SetRequest)

 

또한, Agent는 자신의 MIB에 영향을 미치거나 관리 자원에 발생할 수도 있는 Event를 알리기 위해 Trap 메시지를 만들어 Manager에게 전송하기도 한다.

 

[추가 내용]

 

① Request Message (GetRequest, GetNextRequest, SetRequest)는 UDP 161 포트 이용

② Response Message (Trap)는 UDP 162 포트 이용

③ SNMP v2부터 Request (GetBulk), Response (Inform) 추가

 

👉 Manager는 Agent의 관리 정보를 수집하거나 변경할 때, Get, GetNext, GetBulk, Set 요청을 보내고 Agent는 이에 대한 응답으로 GetResponse 메시지를 Manager 로 보낸다 (Polling 방식)

 

👉 또한, Agent는 Trap, Inform Message를 통해 Manager (NMS)가 미리 설정해둔 특정한 Event가 발생했다는 메시지를 보낼 수도 있다. (Event Reporting 방식)

 

---

 

Polling 방식 (Get / GetNext / GetBulk / Set)

일반적으로 SNMP Manager는 위처럼 Polling 방식으로 주기적으로 Agent에게 관리 정보에 대해 Query를 하게 되는데 연결된 네트워크 구간이 혼잡할 경우, Retry 장애가 발생한 네트워크 장치로의 Polling이 느려져 장애 여부를 늦게 알게 된다거나 알고리즘의 오류로 무한 Polling 하는 오류가 발생할 수 있다.

 

 

 

Event Reporting 방식 (Trap / Inform)

Trap

Inform

 

Polling 방식의 단점을 보완하고자 SNMP에서는 Trap 이라는 Interrupt를 발생시켜 NMS에게 빠른 처리 요청을 할 수 있는 보완 장치를 두게 되었다.

 

👉 Trap 및 Inform 메시지는 유사하게 동작하지만 약간의 차이점이 있다.

 

👉 Trap은 NMS로 메시지를 전송만 하고 정확히 도달했는 지에 대한 확인을 하지 않는다.

 

👉 Inform은 NMS의 수신 확인 Ack 메세지가 없으면 메시지를 재전송한다.

 

[참고] SNMP PDU

 

---

구성 요소

 

SNMP Manager

NMS 프로그램 자체를 의미하며, Agent에 Request를 전송하고 해당 Request에 대한 Response를 수신하고 MIB를 조작하거나 네트웍 장치의 Event를 인식함

 

SNMP Agent

관리 정보를 수집하고 관리자에게 받은 Query에 대해 응답하며 네트워크 장치의 Event를 전송함

 

Managed Device

관리 대상에 해당되는 네트워크 장치

 

MIB (Management Information Base)

관리 장치에서 수집하는 특정한 정보 (Object)들을 모아 놓은 데이터베이스이다.

MIB는 Object별로 Tree 구조를 이루며 Tree의 leaf 노드 Object가 실제로 수집된 관리 정보를 가지고 있다.

Object는 OID (Object Identifier)에 의해 구분되며, NMS에서 관리 정보를 수정하기 위해 Set Request PDU를 생성할 때, OID 값을 알고 있어야 한다.

 

 

 [참고] OID

 

OID는 고유한 특정한 숫자의 연속으로 표현되며, 예를 들어 sysDescr의 OID는 1.3.6.1.2.1.1.1 이다. ( 위 → 아래)

추가적으로 NMS에서 장비들에 대한 MIB/OID 값을 넣어서 필요한 정보를 수집하는데 보통 벤더마다 각각의 Object에 대한 값은 틀리므로 이 점을 유의한다.

 

[참고] SNMP Framework

SMI는 MIB 정보가 어떻게 정의되어야 하는 지를 기술하는 설계도이며, 여러 벤더들 간의 장비와 호환성을 제공하기 위해 공통된 방식으로 표준화 되어 있다.

MIB를 구성하는 Object는 주로 MIB 모듈이라고 불리는 집합으로 묶여 있으며 모듈 형태로 구성되기 때문에 필요한 경우 추가해서 이용할 수 있어 확장성과 유연성이 높은 편이다.

 

---

 

Version

 

SNMP v1

암호화하지 않으며, 보안 기능이 존재하지 않고 Community String에만 의존

 

SNMP v2

SNMP v1에 보안 기능 추가 및 관리 효율성 향상

 

SNMP v2c

SNMP v2에서 보안 기능을 제거

Community String 사용

 

SNMP v3

Manager / Agent 구조를 Object 구조로 바꾸어 각 장치들은 manager가 될 수 있고 Agent가 될 수 있음
널리 사용되지는 않음

 

---

 

Requirement

SNMP Manager (NMS)와 SNMP Agent (Managed Device)가 서로 통신이 가능하려면 최소한 아래의 사항은 충족이 되어야 한다.

 

 

👉 버전 : Manager와 Agent 시스템간 SNMP 버전이 일치해야 한다.

                (v1과 v2의 포맷이 다르기 때문이다.)

 

👉 Community : 상호 간에 설정한 Community String이 일치해야 한다.
                           (최소한의 인증 절차를 위한 암호 기능으로써의 역할을 지님)

 

👉 PDU Type

 

[참고] Community String

SNMP 데몬 (Manager)과 클라이언트 (Agent)가 데이터를 교환하기 전에 인증을 위해 사용하는 일종의 패스워드로, 초기값으로 Public 또는 Private가 설정되어 있습니다.

 

SNMP에서는 RO (Read Only)와 RW (Read Write) 모드를 제공하며, 쓰기 권한이 있을 경우에는 중요 Config를 수정할 수 있으므로 심각한 보안 문제를 유발할 수 있기 때문에 가급적 사용 자제를 권고한다.