제 친구 중에 초등학교 교사가 있습니다. 하는 말을 들어보니 예전보다야 학생 수는 줄었지만 돌보고 가르치는 것은 더더욱 어렵다고 합니다. 요즘 같이 교권이 바닥에 추락한 현실에 한창 뛰어놀 수많은 아이들을 통제한다는 건 여간 어려운 일이 아니기 때문이죠. 천방지축 아이들인지라 어디서 놀다가 다치기라도 한다면 큰일이니까요. 과거에도 학교 밖에 학생들이 사고를 치면 담임선생님이 경찰서로 달려가는 일이 비일비재했지요.
네트워크 장비를 관리한다는 것은 아이들을 돌보는 것과 비슷한 어려움이 있습니다. 일반적으로 대규모 네트워크에서 관리해야 할 네트워크 장비의 수는 수백 대 ~ 수천 대에 달해 일일이 관리하기 어렵습니다. 게다가 네트워크 장비는 무생물이다 보니 자기 자신에 문제 생겨도 아무 말을 하지 않죠. 그렇다 보니 그중에 한 대라도 고장이 난다면 이를 알아채고 대응하기가 매우 어렵습니다.. 그뿐만이 아닙니다. 네트워크 장비 자체의 고장이 아닌 인터페이스의 고장이라면? 하필 그 인터페이스가 가장 중요한 서버로 연결된 인터페이스라면 어떨까요? 큰 장애로 이어질 수 있습니다.
문제가 있으면 이를 해결한 천재들이 있는 법! 네트워크의 천재들은 이미 이 문제를 해결하기 위한 프로토콜을 개발해두었습니다. 네트워크 장비들의 주요 성능과 기능을 모니터링(관제)하고 장애 발생 시 이를 관리자에게 전달하거나 장비에 문제가 생기지 않아도 먼저 관리자에게 특이점을 보고할 수 있는 프로토콜을 말이죠. Simple Network Management Protocol(SNMP)입니다.
SNMP(Simple Network Managemnet Protocol)이란?
간이 망 관리 프로토콜(Simple Network Management Protocol, SNMP)은 IP 네트워크 상의 장치로부터 정보를 수집 및 관리하며, 또한 정보를 수정하여 장치의 동작을 변경하는 데에 사용되는 인터넷 표준 프로토콜이다. SNMP를 지원하는 대표적인 장치에는 라우터, 스위치, 서버, 워크스테이션, 프린터, 모뎀 랙 등이 포함된다.
- 출처 : 위키 백과 -
Simple Network Management Protocol(이하 SNMP)는 네트워크 장비의 성능과 핵심 기능의 현 상태/기능 정보를 수집하고 관리, 저장할 수 있는 프로토콜입니다. 관리자는 SNMP를 통해 수집한 정보를 바탕으로 네트워크 장비의 현재 기능 상태와 성능 정보, 장애 발생 부분을 확인하고 대처할 수 있습니다. 뿐만 아니라 SNMP를 통해 장비의 정보(설정, Config)를 수정할 수도 있지요. SNMP는 UDP(Port 161)를 사용하여 장비의 정보를 수집합니다. 즉 SNMP를 사용한다는 것은 UDP/IP를 사용하며 Port 161을 사용한다는 것을 의미하죠.
여기까지 보시면 네트워크 장비만을 관제하기 위한 프로토콜 같아 보이지만 그렇지 않습니다. SNMP를 지원하는 컴퓨터 혹은 장비라면 SNMP를 이용해 관제할 수 있습니다. 아래 그림을 보시면 각종 네트워크 장비뿐만 아니라 프린터와 컴퓨터까지 있는 것을 볼 수 있죠. 여러분이 사용하고 있는 PC도 SNMP를 활성화시킨다면 SNMP를 이용해 컴퓨터의 각종 성능을 관제할 수 있습니다.
SNMP가 장비의 정보를 수집하고 저장하는 역할을 하는 프로토콜이기 때문에 이를 활용하기 위해서는 정보를 수집하는 주체와 정보를 제공하는 주체가 있어야 합니다. SNMP에서는 이를 Manager와 Agent로 표현합니다. Manager(이하 매니저)는 장비의 정보를 수집하는 하드웨어/소프트웨어를, Agent(이하 에이전트)는 정보를 제공하는 주체인 네트워크 장비를 의미합니다.
현업에서는 이를 Manager, Agent라고 부르지 않고 Manager는 실제 장비를 정보를 수집하는 하드웨어/소프트웨어이므로 Network Management System(NMS)라고 부릅니다. Network Management System(NMS)는 SNMP를 활용하여 네트워크 장비의 정보를 상시 수집하고 장애 발생시(SNMP 정보 변경 시) 이를 사용자에 알려주는 소프트웨어입니다. NMS 솔루션을 활용하여 네트워크 내에 사용 중인 네트워크 장비를 모니터링하며 이상 정보 발생 시 알람을 전달받을 수 있습니다. (NMS를 활용한 네트워크 장비 등록 / 모니터링 과정은 차후 자세히 설명합니다) 구글에서 'NMS'를 검색해보면 NMS 유료 솔루션 혹은 무료 오픈소스 솔루션을 찾아보실 수 있습니다. 정보를 제공하는 주체인 Agent의 경우, 네트워크 장비 내에서 가동되는 SNMP Daemon을 의미하지만 보통 네트워크 장비로 통칭합니다.
SNMP Version
SNMP에도 버전이 존재합니다. 여느 프로토콜이 그렇듯 처음부터 완벽하지 않은 SNMP이기에 개정된 버전이 여럿 나왔습니다. SNMPv1, SNMPv2c, SNMPv3가 바로 그것입니다. 버전이 바뀐다고 해서 많은 것이 바뀐 것은 아니며 보안을 강화하기 위한 수단을 추가하면서 버전이 계속 올라간 것이죠. SNMP 정보에 무슨 보안이냐 하실 수 있을 텐데요. SNMP 정보 자체가 아닌 매니저(NMS)와 에이전트(네트워크 장비) 간 인증을 위한 값, Community String(이하 커뮤니티 값)의 보안 취약성 때문입니다.
커뮤니티 값은 NMS 솔루션과 네트워크 장비 간 인증에 사용되는 값입니다. NMS 솔루션이 특정 네트워크 장비를 관제하고자 할 경우, 네트워크 장비에 설정된 커뮤니티 값과 동일한 평문(String)을 네트워크 장비에 전달해야 합니다. 일종의 비밀번호 같은 것이죠. 커뮤니티 값이 일치하지 않으면 네트워크 장비는 관제를 거부합니다. SNMP를 이해함에 있어 커뮤니티 값은 매우 중요합니다. 이제 SNMP 버전별과 특징과 커뮤니티 값이 어떻게 사용되는지 알아보겠습니다.
SNMPv1
SNMP의 최초 버전인 SNMPv1입니다. 커뮤니티 값을 활용하여 매니저(NMS)와 에이전트(네트워크 장비) 간 인증을 실현합니다. 다만 커뮤니티 값이 평문으로 전달되기 때문에 보안에 취약하고, 장비 정보 값 수집에 있어 대량 수집 요청이 불가능하다는 특징이 있어 사용되지 않습니다.
SNMPv2 / SNMPv2c
SNMPv1에서 보안 취약점과 장비 정보 값 대량 수집 요청 기능 등이 추가된 버전이 SNMPv2입니다. 여기서 보안 취약점이란 커뮤니티 값이 평문으로 전달되는 문제점을 말하는데 SNMPv2에서는 이를 암호화하여 전송하도록 변경하였습니다. 그러나 사용하기 너무 복잡하다는 문제점에 봉착한 후, 이를 평문 커뮤니티 값을 전달하는 것으로 도로 원복하게 됩니다. 이것이 SNMPv2c입니다. 현재에도 SNMPv2c를 사용하는 곳이 꽤 있습니다.
SNMPv3
SNMPv2가 커뮤니티 값을 평문으로 전달한다는 것은 변함이 없기 때문에 보안 기능을 추가로 강화한 것이 바로 SNMPv3입니다. 장비 정보 값을 얻기 위해 접근 시 단순 커뮤니티 값을 제공하는 것이 아닌 'Username(계정)'과 'Password(비밀번호, 커뮤니티 값에 해당)'를 제공해야 합니다. 이 중 비밀번호는 인증 값과 암호 값으로 구성되며 2개 모두를 입력해야 합니다. 암호 값은 암호화 알고리즘(AES, 3-DES)에 의해 암호화되는 비밀번호이며, 인증 값은 해쉬 알고리즘(MD5, SHA)을 적용해 위변조 여부를 확인하는 값이죠.
SNMP의 개요에 대해 대강 살펴보았으니 이제 실제로 주고받는 값과 주고받는 방법에 대해 알고자 합니다. 지금까지 다룬 내용이 그저 SNMP 자체에 대한 내용이 주를 이루었다면 지금부터는 현업에서 NMS와 같은 솔루션을 사용할 때 실제로 이해하고 활용해야 하는 내용을 다루고자 합니다. SNMP Message(이하 메시지)와 Object ID, OID입니다.
SNMP Message
SNMP의 궁극적인 목적은 네트워크 장비의 현 정보를 수집하여 NMS와 같은 관리 솔루션 혹은 관리자에게 전송하는 것입니다. 그렇기에 SNMP의 정보를 전달할 메시지가 존재하며 메시지에도 Type(이하 타입)이 존재합니다. 메시지의 타입에는 여러 가지 종류가 있지만 대표적으로 3개로 나누면 SNMP Get, SNMP Set, SNMP TRAP이 있습니다. Get은 말 그대로 정보를 가져오는 메시지 타입이며, Set는 SNMP를 이용해 장비의 정보를 변경(설정)하는 메시지 타입입니다. 아래 그림의 우측을 보시면 SNMP Manager(NMS)와 SNMP Agent(네트워크 장비)가 메시지를 이용해 통신하는 것을 확인하실 수 있습니다. 위에서 언급한 것처럼 UDP를 사용하는 것도 확인할 수 있죠.
SNMP TRAP은 사용자(관리솔루션)가 요청한 정보가 아닌, 이상 발생 시 장비가 즉시 전송하는 메시지입니다. 장비가 먼저 전송한다는 점에서 SNMP TRAP이 발생했다는 것은 중대한 사안이 발생했음을 의미하지요. 차후 자세히 설명합니다.
SNMP Get
SNMP Get은 말 그대로 장비 기능/설정을 확인하기 위해 SNMP 정보를 요청하기 위한 메시지입니다. 그렇기에 정보 요청을 위한 GetRequest와 응답을 위한 GetReponse로 구분됩니다. GetRequest는 한 개의 정보만을 수집하기 위한 메시지로 기본이 되는 메시지입니다. 하지만 현업에서는 주로 SNMP 정보를 가져올 때 대량으로 가져오기 때문에 GetRequest 메시지 하나만으로는 문제가 있었고 대량 검색이 가능한 메시지가 필요하게 되었죠. 그리하여 GetNextRequest와 GetBulkRequest가 존재하게 됩니다.
GetNextRequest는 단독으로 존재하는 정보가 아닌 연속적으로 다수 존재하는 정보를 한 번에 가져오기 위한 메시지이고 GetBulkRequest는 'Bulk'라는 단어처럼 정보 묶음을 통째로 가져오기 위한 메시지입니다. 위에서 SNMP Version을 설명할 때 SNMPv1의 결함 중 값을 대량으로 가져오는 메시지가 없다는 것이 존재한다고 했었죠. 그래서 SNMPv2에서 추가된 것이 바로 GetBulkRequest입니다.
SNMP Set
SNMP Get이 네트워크 장비의 기능/설정 확인을 위해 SNMP 정보를 요청하는 것이라면 SNMP Set은 네트워크 장비의 설정을 변경하기 위해 정보를 역으로 전달하는 메시지입니다. 다시 말해 SNMP Set 메시지를 이용해 네트워크 장비의 설정을 제어하는 것이죠. 다만 굳이 SNMP가 아니어도 장비의 설정을 바꿀 수 있는 방법은 무궁무진한 데다 네트워크 장비의 설정을 변경하는 것은 주로 네트워크 엔지니어이기 때문에 잘 사용되지는 않습니다.
SNMP TRAP
Manager가 요청 않더라도 Agent에 의해 자의적으로 생성/송신하는 SNMP 메시지 중 하나
- 출처 : 정보통신기술용어해설 -
SNMP TRAP(이하 트랩)은 사용자(관리솔루션)이 먼저 정보를 요청하지 않아도 장비가 이상 상황 발생 시 사용자에게 메시지를 보낼 때 사용하는 메시지 타입입니다. 보통 SNMP를 이용한 네트워크 장비 모니터링은 사용자가 원하는 항목만을 선정하여 해당 항목의 정보를 수집하는 경우가 대부분입니다. 시스템의 리소스라는 것은 늘 한정적이기 때문에 SNMP를 이용한 모니터링 또한 매우 중요한 정보와 사용자가 원하는 정보만을 모니터링하기 마련입니다. 아래 그림의 우측 하단에 보시면 다른 메시지들은 Request에 해당하는 Response만을 전송하는 반면 Trap은 일방적으로 에이전트에서 매니저로 전송되는 것을 확인하실 수 있습니다.
트랩은 장비 운용에 있어 큰 영향을 미칠 수 있는 중대한 정보 변경 사항을 사용자에게 능동적으로 전송함으로써, 사용자가 장비 모니터링에 있어 놓칠 수 있는 부분을 보완하는 역할을 합니다. 그만큼 중요하기 때문에 SNMP 정보 교환에 있어 UDP 161번을 사용하는 SNMP Get/Set과는 달리 UDP 162번이라는 독자적인 포트 번호를 사용하여 일반적인 정보 교환과 통로를 따로 두고 있죠.
Object ID(OID)
지속성 있는 유무형의 객체를, 전 세계적으로 유일하게 식별하기 위한 ID 체계
- 출처 : 정보통신기술용어해설 -
마지막으로 살펴볼 것은 대망의 Object ID입니다! 지금까지는 매니저와 에이전트가 메시지를 통해 SNMP 정보를 주고받는다고 설명했었죠. 이번에는 이 SNMP 정보가 어떻게 구별되고 관리되는지 알아보고자 합니다. SNMP에서는 네트워크 장비의 기능과 설정을 Object ID(OID)라는 개념을 통해 구별하고 정리합니다. 줄여서 OID라고 부르죠. 예를 들어 네트워크 장비의 CPU 평균 5초 / 1분 / 5분 사용률은 각각의 OID에 의해서 제공됩니다. Cisco社의 네트워크 장비 CPU 사용률 OID 제공 값을 보겠습니다.
위 사진은 Cisco社의 네트워크 장비 CPU 사용률 OID를 나열한 표입니다. '개체'라고 써진 부분의 오른쪽에 보시면 CPU 사용률 5초 / 1분 / 5분 사용률의 OID를 확인하실 수 있습니다. '1.3.6.1. ... .1.1.1.5' 등으로 표시된 숫자의 나열이 바로 OID입니다. 어느 정보를 나타내는 OID냐에 따라 숫자의 나열과 숫자가 달라집니다. 이를 통해 SNMP 정보 값을 구분하고 표시하는 것이죠. OID를 형태를 확인했으니 이제 OID의 구조와 읽는 방법에 대해 알아봐야겠죠?
OID의 구조와 읽는 법
위 그림에서 잠시 확인했지만 OID는 숫자의 나열로 이루어져 있습니다. 이를 길게 나열하였기에 단순 나열로 보이지만 OID는 원래 트리구조의 정보체계 속에서 존재합니다.
OID가 속한 집합과 그 집합의 성격을 확인하기 위해서는 트리구조의 최상단(root)부터 순차적으로 확인하면 됩니다. 표기 또한 트리 구조의 최상단부터 순차적으로 표기하지요. 위에서 언급한 Cisco 社의 CPU 평균 5분 사용률 OID인 '1.3.6.1.4.1.9.9.109.1.1.1.1.5'을 위 트리 구조에 빗대어 살펴보면 다음과 같습니다.
iso(1)-org(3)-dod(6)-internet(1)-private(4)-enterprise(1)-cisco(9)-
ciscoMgmt(9)-ciscoProcessMIB(109)-ciscoProcessMIBObjects(1)-cpmCPU(1)-cpmCPUTotalTable(1)-cpmCPUTotalEntry(1)-cpmCPUTotal5min(5)
최상단(맨좌측 숫자)부터 모든 네트워크 장비의 Vendor(이하 벤더)에 공통되는 숫자를 나열하다가 'enterprise(1)' 이후 벤더별 특성에 맞는 숫자(cisco(9))를 나열해 벤더와 벤더 장비의 기능을 숫자로 표현합니다. 다시 말해 각각의 숫자에는 모두 의미가 있으며 그 숫자를 따라내려가면 CPU 평균 5분 사용률에 대한 정보가 나오고 해당 OID로 SNMP GetRequest를 실시하게 되면 네트워크 장비는 해당 OID에 적재된 현재 값을 Response 하게 되는 것입니다. 물론 'enterprise(1)'라는 중간 숫자만 있는 것이 아니고 다양한 숫자가 존재하고 그에 걸맞게 다양한 트리가 존재하지만 이 모두를 알 필요는 없습니다. 모니터링이 필요한 정보에 대한 OID를 검색하여 확인 후 사용하기 때문에 아무리 NMS를 개발하는 사람이라도 위 순서를 외우지도 않고 모두 사용하지도 않습니다. 또한 OID에도 종류는 존재합니다. 벤더를 가리지 않고 사용되는 OID와 벤더별로 지정하여 사용하는 OID, 2가지가 그것인데요. 편의상 전자를 'Public OID', 후자를 'Private OID'라고 부르도록 하겠습니다.
Public OID
어느 벤더이든 반드시 공통적으로 사용해야 하는 OID가 존재합니다. System, Interface, IP, TCP, UDP, SNMP 관련 정보 등 벤더별 차이점이 존재하지 않고 꼭 정보를 제공해야 하는 OID이죠. 이 OID에 정해진 이름은 없지만 전 'Public OID'로 통칭하여 부르곤 했습니다. OID 번호는 '1.3.6.1.2.1.x'로 시작하며 광범위한 정보를 담고 있습니다. 예를 들어 Pubilc OID 중 System OID을 살펴보면 Uptime, Name, Description, SYSOID 등이 존재합니다.
SYSOID
SYSOID는 각 벤더별로 사용하는 번호가 다른, 다시 말해 식별 번호에 해당하며 해당 벤더만이 사용하는 OID입니다. Cisco CPU 사용률을 확인하기 위한 OID값을 자세히 보시면 'enterprise' 다음 숫자에 cisco(9)라고 적힌 것을 보실 수 있습니다. 이는 벤더를 상징하는 숫자인데요. 말그대로 네트워크 장비 벤더를 구분하기 위한 숫자입니다. 그리고 벤더를 구분하기 위한 OID가 바로 SYSOID입니다. SYSOID는 Public OID에 소속되어 있으며 SYSOID를 가리키는 OID값은 '1.3.6.1.2.1.1.2.0'입니다. 보통 '1.3.6.1.4.1.SYSOID'로 표시됩니다.
Private OID
벤더별로 자신만이 사용하는 OID로 편의상 'Private OID'라고 부르겠습니다. Private OID에는 해당 벤더가 제공하는 고유한 정보들이 대부분 존재합니다. CPU 사용률부터 메모리 사용량, FAN 상태, 온도, POWER 상태, 기능 상태 등이 포함됩니다. Private OID는 주로 '1.3.6.1.4.1.x'로 시작하는 것이 대부분입니다. Cisco 社의 CPU 평균 5분 사용률 OID인 '1.3.6.1.4.1.9.9.109.1.1.1.1.5' 또한 Private OID에 해당합니다.
Management Information Base(MIB)
OID들의 집합을 Management Information Base, MIB이라고 부릅니다. MIB에는 OID를 다양한 목적별로 모아둔 테이블로서 벤더마다 다수의 MIB을 보유하고 이를 사용자에게 제공함으로서 NMS 솔루션에 MIB에 적힌 OID를 추가하여 관제할 수 있도록 돕습니다. MIB은 보통 벤더마다 다른 값을 갖지만 벤더 내 모델별로 다른 MIB을 제공하는 경우가 흔합니다. 그래서 아무리 같은 벤더라 하더라도 모델이 다르면 MIB이 다르고 MIB이 다르면 OID가 다르니 신규 모델의 장비를 모니터링할 때 OID를 추가로 확보해야하는 경우도 종종 있습니다.
현업에서 각 벤더의 장비가 어떤 OID를 제공하는지 눈으로 식별하고자 할 때 사용하는 소프트웨어가 있으니 바로 'MIB Browser'입니다.
MIB Browser가 설치된 PC와 모니터링하고자 하는 네트워크 장비가 네트워크 상으로 연결되어있다면 위 소프트웨어를 통해서 네트워크 장비가 보유하고 있는 OID와 OID가 품고 있는 값을 확인할 수 있습니다. MIB Browser는 무료로 사용 가능한 소프트웨어이니 필요하신 분은 다음 링크에서 다운로드받아 사용하시기 바랍니다. 'https://www.ireasoning.com/mibbrowser.shtml'
여기까지가 SNMP의 이론적인 내용입니다. 다음 문서에서는 현업에서 주로 사용하는 SNMP 관련 정보에 대한 이야기를 해보겠습니다. 감사합니다.
'Network Infra 쉽게 이해하기 > L4 & L7 Network 쉽게 이해하기' 카테고리의 다른 글
| SNMP 쉽게 이해하기 #2 (2) | 2022.12.04 |
|---|---|
| Destination IP NAT 쉽게 이해하기 (4) | 2021.12.19 |
| Source IP NAT 쉽게 이해하기 (6) | 2021.11.21 |
| NAT 쉽게 이해하기 (19) | 2021.09.18 |
| L4/L7 로드밸런싱 쉽게 이해하기 (19) | 2021.03.28 |
댓글