SNMP, MIB, SMI, RMON, netflow 등등 NMS 관련 용어들...

네트워크 관리 시스템은 말 그대로 네트워크 관리를 위한 시스템이다.

네트워크 관리를 위한 표준 프로토콜이 바로 SNMP이라는 것인데,

1990년대 말까지는 CMIP과 SNMP가 공존하다가 2000에 들어오면서 SNMP의 승리로

귀결지어졌다. 사람들은 복잡한 것을 별로 좋아하지 않는다는 사실이 다시 증명된 셈이랄까..

 

SNMP는 말 그대로 Simple Network Manahement Protocol 이다.

그러나 이 Simple이라는 단어는 항상 상대적으로 라는 수식어가 생략되어 있다는 것을 알아야 한다.

원래 완벽하고 상세하게 설계하기로 했던 CMIP에 비해 상대적으로  Simple 하다는 것일 뿐...

결코 이 프로토콜이 Simple 하다는 것은 아니다...

오히려 구현자가 제멋대로 mib을 결정할 수 있기 때문에 구현자 입장에서는 별로 달갑지 않다.

 

암튼 기본적인 개념상으로 볼 때 이 프로토콜은 매우 Simple 하다.

GET-RESPONSE : 값을 물어본다. 대답한다.

SET : 값을 셋팅한다.

TRAP : 스스로 상태를 보고한다.

이 세 가지 동작을 통해 네트워크를 관리하기로 한 것이니... 매우 Simple 하긴 하다.

 

그럼 방법을 정했으니, 어떤 데이터를 주고 받을 것인가도 알아야 한다.

그 데이터를 정의해 놓은 사전이 MIB(Management information base)이다.

자고로 네트워크 관리자라면 MIB 하면 이게 Man in black이 아니라는 사실을 알아야 겠다.

그리고 이 데이터들을 어떤 식으로 나열해 놓을 것인가를 정의한 것이
SMI(Structure of management information)이다.

 

쉡게 생각해서 SNMP는 언어, MIB은 사전, SMI는 언어규칙이라고 생각하면 된다.

나와 철수가 한국어로 말하고자 한다면...

둘은 일단 한국어로 말할 수 있어야 하며...

상황에 맞는 적절한 단어를 선택하여 정해진 구조(주어+목적어+동사)로 말해야 한다는 것이다.

네트워크 관리 시스템과 네트워크 관리 대상인 장비는

이 SNMP라는 프로토콜로 대화를 하며

SMI에 기반한 MIB에 정의되어 있는 항목을 적절히 선택하여 대화하는 것이다. 

 

때문에 SNMP를 지원하는 장비라고 해서 모두 내가 원하는 대로 관리될 수 있을 것으로

기대해서는 안된다. 예를 들자면 24개월짜리 아가와 대화를 하려면...

분명 한국말로 대화중임에도 불구하고 많은 제약이 뒤따르지 않는가... (아기와의 대화라... --)

네트워크 장비도 이 아가 수준의 장비들이 많이 존재한다고 보면 된다.

 

어쨌건 시장에서는 보다 완벽하고 상세하며 모든 요구사항들을 충족시키는(고자 했던) 

CMIP  대신에 보다 단순하고 구현하기 쉬우며 만들기 쉬운 SNMP를 선택했고...

(벤더 입장에서는 당연히 둘 중 뭘로 할래? 하면.. 쉬운 거.. 로 갈 수 밖에 없다.

개발기간 = 인력 = 돈 = 원가 상승이지 않은가... 사용자측에서도 빨리 되는 제품을 원했고... )

현재는 CORBA니 뭐니 하는 별종이 등장하고 있지만...

 

결국에는 현재 NMS에 주로 사용되는 주요 프로토콜은 SNMP라는 사실이 중요하다.

 

여기에 SNMP의 한계를 극복하기 위해 추가적으로 등장한 것이

RMON(Remote network MONitoring)이라는 프로토콜이다.

이름만 봐서는 무슨 용도인지 참 상상하기 어려운 용어인데...

이름대로 풀어보자면 멀리서 네트워크의 사용량을 감시하기 위한 프로토콜이다. ^^;;

즉 SNMP로 커버하기 힘든 멀리 떨어져 있는 특정 로컬 네트워크 영역(segment)에서의

네트워크 사용량(구조)을 알아보고자 하는 의도에서 시작되었으며,

SNMP와 유사한 구조로 MIB이라는 것을 채택하였다.

따라서 RMON I, II에서 정의한 MIB들이 존재하게 되었으며, 

RMON Probe 들은 이 RMON MIB을 지원하고,

대부분의 SNMP Manager에서 이 RMON MIB을 이용하여 해석할 수 있는 구조이다.

 

그러나 이 RMON이라는 것이 참 문제가 많았다.

여기서 필요한 데이터라는 것이 관리자들이 궁금해 하는 것들을 많이도 제공해주기는 했는데,

결정적으로 이러한 데이터들은 대단히 양이 많았고, 처리하는데 시간이 많이 걸린다는 것이었다.

따라서 RMON 정보들을 처리하기 위한 프로브들은 대량의 데이터를 보관, 처리해야 했고,

당시 저용량의 네트워크 장비들은 이러한 것들을 수용하기 힘들 수 밖에 없었다.

2000대 초반 장비들의 스펙들을 보면 RMON 지원이라는 항목들을 많이 볼 수 있는데,

엔지니어들은 이를 올리는 것을 대단히 꺼려하였다.

장비가 부하를 견디지 못해 죽어버리는 일이 종종 발생했기 때문이다.

특히 네트워크가 TCP/IP로 바뀌고, 네트워크의 데이터량이 증가하고,

전송속도가 10/100에서 1G/10G로 가는 현 시점에서 장비가 이런 데이터들을 수용하고 처리하는 것은 거의 재난에 가까운 일이었다. 때문에 현재는 일부 RMON 프로브만 남고 대부분 시장에서 사라진 상태다.

 

그러나 네트워크에 흘러다니는 데이터의 정체를 알고 싶다는 꾸준한  요구가 있었고,

이런 이유로 인해 최근에(2000년도 초반) 등장한 것이 netflow로 잘 알려진 nFlow 라는 개념이다.

 

본래 이 라우터, 스위치 등 네트워크 장비란 놈이 패킷 기반으로 동작을 한다.

즉 송신자가 발송한 정해진 사이즈의 패킷을 정해진 경로를 통해 수신자에게 잘 보내면 되는 것이 네트워크 장비의 역할인데... 이 패킷은 어떤 어플리케이션의 조각 또는 데이터의 조각이므로 실제로는 하나의 업무 Flow가 원활하게 이 정해진 경로를 타고 수행되는 것이 궁극적인 목표가 된다는 데 촛점을 맞춘 개념이다.

 

따라서 패킷과 경로라는 컨셉 기반의 라우터들이... 이 Flow 컨셉을 차용하여 장비에 적용하면서

그 동안 RMON에서 관리자들이 가장 궁금해 하던 부분만 떼어내어 관리용으로 제공하기로 한 것이다.

 

이 flow 라는 표준은 7개의 장비 제조 벤더들이 모여서 만들었기 때문에 RFC 어쩌고 하는 문서들이 없다. 대신 업체들이 동의한 규약은 있다. 큰 그림만 만들고 구현은 벤더 나름대로 했기 때문에 내용도 조금씩 다르다는 말이다. 

 

어찌되었건 중요한 것은 이 flow 표준을 따르는 장비들은 flow에 대한 정보들 -  ip, port(어플리케이션 구분 가능), 수신지 ip, port, 패킷량 등을 제공한다는 것이다.

네트워크 사용자들이 많이 궁금해 하는 것 중에 하나가 90% 이상 꽉꽉 차서 흘러다니는 저 회선에 실제 돌아다니는 패킷의 정체가 무엇이냐? 인데... 바로 이것을 해결해 준 것이다.

 

CISCO에서 사용하는 용어가 netflow이며..  flow의 대명사처럼 사용된다.

업체에 따라 c-flow, s-flow 등의 이름을 붙이기도 한다.

 

물론 RMON이 그것을 제공해 주기는 했지만....

엄청난 데이터의 발생으로 인한 여러 가지 문제를 극복하지 못했으므로...

flow를 통해서 그것을 제공해 주기로 한 것은 획기적인 일이 아닐 수 없었다.

 

처음에는 rmon이 그러했듯이.. flow 기능에도 여러 가지 문제들이 많이 있었지만...

지금은 cisco를 필두로... 많이 개선되어... 이를 기반으로 한 nms 제품들이 많이 나와 있다.

 

물론 이것도 만능은 아니며, 여전히 대용량 데이터에 대한 처리부분이 한계로 남아 있다.

cisco는 이것을 독립모듈로 떼어내어 NAM이라는 모듈로 제공하고 있다.