[데이터 통신과 네트워킹] 네트워크 관리 & SNMP

네트워크 관리란?

• 한 기관에 의해 정의된 요구 사항들을 만족하기 위해 네트워크 개체의 감시, 검사, 구성, 문제해결을 진행하는 것
• 요구사항들은 사용자를 위해 미리 정의한 서비스 품질을 제공하는 네트워크의 원활하고 효율적인 동작을 포함
• 이러한 작업을 완성하기 위해서 네트워크 관리 시스템은 하드웨어, 소프트웨어 그리고 사람을 이용

국제표준기구(ISO)는 네트워크 관리를 다섯 영역으로 정의

1. 구성관리
2. 장애 관리
3. 성능 관리
4. 보안 관리
5. 과금 관리

네트워크 관리 영역

1. 구성 관리

• 대규모 네트워크는 보통 수백 개에 이르는 물리적 또는 논리적으로 연결된 개체(entity)들로 이루어져 있음.
• 개체들은 네트워크가 설정될 때 초기 구성이 이루어지지만 시간이 지남에 따라 바뀔 수 있음.
• 구성 관리(configuration management) 시스템은 각 개체들의 상태와 다른 개체들과의 관계를 언제라도 알 수 있어야 함.
• 2개의 서브 시스템인 재구성(reconfiguration)과 문서화(documentation)로 나눌 수 있음.

재구성 하드웨어 재구성, 소프트웨어 재구성, 사용자 계정 재구성이라는 세 가지 유형의 재구성이 있음. 하드웨어 재구성(hardware reconfiguration)은 하드웨어에 대한 모든 변경을 다룸. 소프트웨어 재구성(software reconfiguration)은 소프트웨어에 대한 모든 변경을 다룸. 사용자 계정 재구성(user-account reconfiguration)은 시스템에서 사용자를 단순하게 추가하고 삭제할 수 없으며 반드시 사용자의 권한을 개별적인 것과 어떤 그룹의 일원인 것으로 모두 고려해야 함. 문서화 초기 네트워크 구성과 계속적으로 이어지는 변경은 기록되어야 함. - 하드웨어, 소프트웨어, 사용자 계정에 대해 문서화 하드웨어 문서화(hardware documentation) - 일반적으로 맵(map)과 규격(specification)을 포함 - 맵은 하드웨어 하나 하나와 이것들의 네트워크 연결을 추적 - 규격은 하드웨어 유형, 일련 번호, 제조회사(주소와 전화 번호), 구입 날짜와 보증정보와 같은 정보를 포함 소프트웨어 문서화(software documentation) - 소프트웨어 유형, 버전 정보, 설치 날짜, 인가 계약(license agreement)과 같은 정보를 포함 사용자 계정 문서화(user-account documentation) - 업데이트하고 안전하게 해야 함.

 

2. 장애 관리

• 문제를 처리하는 네트워크 관리 영역
• 사후 장애 관리와 사전 장애 관리라는 2개의 서브 시스템으로 구분

사후 장애 관리 시스템 장애를 탐지하고 분리하며 정정 및 기록하는 역할 장애검출 - 정확한 장애의 위치를 탐지 - 장애는 시스템에 대한 비정상적인 상태를 말하며 장애가 발생하면 시스템은 정상적으로 작업하는 것을 멈추거나 많은 장애를 생성하는 시스템을 분리함. 장애 분리 - 장애를 분리하면 장애는 보통 몇몇 일부 사용자에게만 영향을 미침. - 분리한 후에 영향을 받은 사용자에게 즉시 통지하고 예상되는 정정 시간을 알려줌. 장애 정정 - 결함이 있는 구성요소의 교체 또는 수리를 포함할 수도 있음. 장애 기록 - 장애가 정정된 후 반드시 문서화해야 함. - 기록은 정확한 장애 발생 위치, 가능한 원인, 장애를 정정하기 위한 작동, 비용, 각 단계에서 소비한 시간을 보여줌. 사전 장애 관리 시스템 장애 발생을 방지 사전 장애 관리가 항상 가능한 것은 아니지만 장애의 일부 종류는 예측할 수 있고 예방할 수 있음. 예1 : 제조업자가 구성요소나 구성요소의 일부에 대한 수명을 나타낸 것은 구성요소의 수명이 다하기 전에 교체하기 위한 좋은 방법 예2 : 네트워크의 특정 한 부분에서 자주 장애가 발생한다면 장애가 다시 발생하는 것을 방지하기 위해 네트워크를 재구성하는 것이 현명한 방법

 

3. 성능 관리

가능한 효율적인 운영을 보장하기 위해 네트워크를 감시하고 제어

• 용량(capacity)
• 트래픽(traffic)
• 처리율(throughput)
• 응답 시간(response time)

과 같이 측정할 수 있는 양을 이용하여 성능을 측정

용량 - 모든 네트워크의 용량은 한계가 있고, 성능 관리 시스템은 반드시 이 용량을 초과해서 사용하면 안 된다는 것을 보장해야 함. 트래픽 - 내부 트래픽은 네트워크 내부의 패킷(또는 바이트) 이동의 수를 측정 - 외부 트래픽은 네트워크 외부의 패킷(또는 바이트) 교환을 측정시스템이 과중하게 사용되는 피크(peak) 시간 동안에는 과도한 - 트래픽을 차단할 수도 있음. 처리율 - 개별적인 장치(라우터와 같은) 또는 네트워크의 한 부분에 대한 처리율(throughput)을 측정할 수 있음. - 수용할 수 없는 단계까지 떨어지지 않는 것을 보장하기 위해서 처리율을 감시 응답 시간 - 일반적으로 사용자가 서비스를 요청한 시간부터 서비스를 받은 시간까지를 측정 - 평균 응답 시간과 피크(peak) 시간 응답 시간을 감시 - 응답 시간이 증가하는 것은 네트워크가 용량을 초과해서 동작한다는 것을 나타내는 것으로 매우 심각한 상태임

 

4. 보안 관리

• 정의된 정책에 따라 네트워크 접근을 제어하는 역할

 

5. 과금 관리

• 요금을 통해 네트워크 자원에 접근하는 사용자를 제어
• 과금 관리에 따라 개별 사용자, 부서, 프로젝트는 네트워크에서 받는 서비스에 대해 요금이 부여됨

---

단순 네트워크 관리 프로토콜(SNMP)

• TCP/IP 프로토콜을 사용하는 인터넷의 장치를 관리하는 기반구조
• 인터넷 감시와 유지보수를 위한 기본적인 일련의 기능들을 제공
• 관리자와 에이전트의 개념을 사용
• 일반적으로 호스트인 한 관리자가 보통 라우터 또는 서버인 에이전트 그룹을 제어하고 감시
• 서로 다른 제조회사에서 만들어지고 서로 다른 물리적인 네트워크에 설치된 장치들을 감시할 수 있도록 응용 수준에서 설계
•  
  관리 대상 장치의 물리적 특성과 현재의 네트워크 연결 기술로부터 관리 업무를 분리
•  
  서로 다른 제조회사에 의해 만들어진 라우터에 의해 연결된 종류가 다른 LAN과 WAN으로 구성되는 이질적인 인터넷에서도 사용될 수 있음.

SNMP 개념

관리자와 에이전트

관리자라 불리는 관리 지국은 SNMP 클라이언트 프로그램을 수행하는 호스트

 

에이전트라는 관리 대상 지국은 SNMP 서버 프로그램을 수행하는 라우터

• 관리는 관리자와 에이전트 간의 간단한 대화에 의해 수행
• 에이전트는 데이터베이스에 성능 정보를 저장
• 관리자는 데이터베이스에서 값들을 획득
• 관리자는 또한 라우터로 하여금 특정한 동작을 행하도록 할 수 있음
• 에이전트에서 수행되는 서버 프로그램은 환경을 검사하여 만일 비정상적인 무엇인가를 찾아내면, 관리자에게 경고 메시지(trap이라고 부름)를 송신할 수도 있음

---

관리 구성 요소

관리 작업을 수행하기 위해 다른 두 가지 프로토콜, 즉 관리 정보 구조(SMI)와 관리 정보 베이스(MIB)를 사용

인터넷 네트워크 관리 구성요소

SNMP의 역할: 전송 프로토콜

• SNMP는 관리자와 에이전트 사이에 주고받는 패킷의 형식을 정의
• 결과를 해석하고 통계 자료를 생성
• 교환되는 패킷들은 객체(변수) 이름과 그들의 상태(값)가 들어 있는데 이러한 값들을 읽고 변경하는 책임

SMI의 역할: 관리 형태 제공

• 객체의 이름을 작성하는 기준 제공
• 객체의 유형을 정의

MIB의 역할: 관리할 개체들의 집합(각 에이전트마다 로컬 MIB DB 구성)

• 관리될 각 개체를 위해 객체의 수를 결정하고,
• 이들을 SMI에 의해 정의된 규칙에 따라 이름을 붙이며,
• 이름이 붙여진 각 개체에 유형을 결합하는 프로토콜

컴퓨터 프로그래밍과 네트워크 관리의 비교

 

관리 정보 구조(SMI)

관리 정보 구조, 버전 2(SMIv2, Structure of Management Information, version 2)

SMI는 SNMP를 위한 지침이며, 객체를 다루기 위해 이름, 데이터 유형, 부호화 방식 등 3개의 속성을 강조

기능

• 객체에 이름을 설정
• 객체에 저장될 수 있는 데이터의 유형을 정의
• 네트워크상의 전송을 위해 데이터를 어떻게 부호화할지 표현

이름

• SMI는 각 관리 대상 객체(라우터나 라우터에 있는 변수, 값 등과 같은)가 유일한 이름을 갖도록 요구함.
• 객체의 이름을 범용으로 짓기 위해, SMI는 트리 구조에 기초한 계층적 식별자인 객체 식별자(object identifier)를 사용
• 각 객체는 점으로 구분된 정수 열을 사용하여 정의될 수 있음.
• 트리 구조는 또한 점으로 구분된 문자 이름들의 열을 사용하여 객체를 정의할 수도 있음.
• SNMP에서 사용되는 객체는 mib-2 객체 밑으로 위치하므로, 식별자는 항상 1.3.6.1.2.1로 시작함.

데이터 유형

• 데이터 유형을 정의하기 위해, SMI는 기본적인 추상 구문 표현 1(ASN.1, Abstract Syntax Notation One) 규약을 사용하고, 몇 개의 새로운 정의를 추가
• 단순 데이터 유형과 구조적 데이터 유형 존재

단순 데이터 유형 - 원시적 데이터 유형 - 이들 중 어떤 것은 ASN.1로부터 직접 얻은 것이고, 어떤 것은 SMI에 의해 추가된 것 구조적 데이터 유형 sequence와 sequence of라는 두 가지 구조적 데이터 유형을 정의 sequence 데이터 유형 - 같은 데이터 유형일 필요 없는 단순 데이터 유형들의 조합 - C와 같은 프로그래밍 언어에서 사용되는 구조체(struct)나 레코드(record)의 개념과 비슷 sequence of 데이터 유형 - 모두 같은 유형인 단순 데이터 유형들의 결합이거나, 모두 같은 유형인 sequence 데이터 유형들의 결합 - C와 같은 프로그래밍 언어에서 사용되는 배열의 개념과 비슷

부호화 방식

기본 부호화 방식(BER)이라는 또 다른 표준을 사용하여 네트워크를 통해 전송되는 데이터를 부호화

• 데이터의 각 부분이 태그, 길이, 값(TLV)이라는 세 가지가 한 조가 되는 형식으로 부호화하도록 규정

부호화 형식

태그는 데이터 유형을 정의하는 1바이트 필드 길이 필드는 한 바이트 또는 그 이상 - 만약 한 바이트면 최상위 비트는 반드시 0이며 다른 7개의 비트는 데이터의 길이를 규정 - 만약 한 바이트 이상이면 최상위 비트는 반드시 1이어야 하며, 첫 번째 바이트의 다른 7개의 비트는 길이를 정의하는데 필요한 바이트 수를 나타냄 값 필드는 BER에서 정의된 규칙에 따라 데이터의 값을 부호화

데이터 유형의 코드

INTEGER 14

OCTET STRING ‘HI’

ObjectIdentifier   1.3.6.1

---

관리 정보 베이스(MIB)

관리 정보 베이스, 버전 2(MIB2, MIB, Management Information Base, version 2)는 네트워크 관리에서 사용되는 두 번째 구성요소

• 각 에이전트는 관리자가 관리할 수 있는 모든 객체를 모아놓은 자신의 MIB2를 가짐

일부 mib-2 그룹들

sys (system) : 이름, 위치, 수명과 같은 노드(시스템)에 관한 일반적인 정보를 정의 if (interface) : 인터페이스 번호, 물리 주소와 IP 주소를 포함한 노드의 모든 인터페이스에 관한 정보를 정의 at (address translation) : ARP(address resolution protocol: IP-MAC) 테이블에 관한 정보를 정의 ip : 라우팅 테이블과 IP 주소와 같은 IP에 관한 정보를 정의 icmp : 송수신된 패킷 수와 생성된 전체 장애와 같은 ICMP에 관한 정보를 정의 tcp : 연결 테이블, 타임아웃 값, 포트 수, 송수신된 패킷 수와 같은 TCP에 관한 일반적인 정보를 정의 udp : 포트 수와 송수신된 패킷 수와 같은 UDP에 관한 일반적인 정보를 정의 egp : EGP의 기능과 관련되어 있음. trans : 전송의 특정한 방법과 관련되어 있음(미래에 사용). snmp : SNMP 자체에 관련된 일반적인 정보를 규정

---

SNMP 동작

SNMP는 인터넷 네트워크 관리에 SMI와 MIB를 모두 사용

 

SNMP는 다음을 허용하는 응용 프로그램

1. 에이전트에 정의된 객체의 값을 읽기 위한 관리자
2. 에이전트에 정의된 객체에 값을 저장하기 위한 관리자
3. 관리자에게 비정상적 상황에 대한 경고 메시지를 보내기 위한 에이전트

PDU(Protocol Data Unit)

SNMPv3는 다음 8가지 유형의 패킷(PDU)을 정의

SNMP PDU

GetRequest - 변수 하나 또는 일련의 변수들의 값을 읽기 위하여 관리자(클라이언트)로부터 에이전트(서버)로 보내짐. GetNextRequest - 한 변수의 값을 읽기 위하여 관리자에서 에이전트로 보내짐. - 읽힌 값은 PDU에 정의된 ObjectId 바로 다음 객체의 값으로 대부분 테이블에 있는 항목들의 값을 읽기 위해 사용됨. GetBulkRequest - 많은 양의 데이터를 읽기 위하여 관리자로부터 에이전트로 보내짐. - 여러 개의 GetRequest와 GetNextRequest PDU를 대신하여 사용할 수 있음. SetRequest - 변수에 값을 설정(저장)하기 위하여 관리자가 에이전트로 보냄. Response - GetRequest나 GetNextRequest에 대한 응답으로 에이전트가 관리자에게 보내며 관리자에 의해 요청된 변수의 값을 포함 Trap (SNMPv1 Trap과 구별하기 위해 SNMPv2 Trap이라고도 부름) - 에이전트가 사건을 관리자에게 보고하기 위해 전송 - 예를 들어 만일 에이전트가 재시동되면, 에이전트는 관리자에게 이를 알리고 재시동 시간을 보고 InformRequest - 한 관리자가 다른 원격 관리자에게 전송하는 것으로 원격 관리자의 제어 하에 있는 에이전트로부터 일부 변수의 값을 얻기 위한 것 Report - 관리자들 사이에 어떤 장애 유형들을 보고하기 위해 설계 (아직 사용되지 않음)

 

PDU 유형

PDU 유형

 

요청 ID(Request ID)

• 이 필드는 관리자가 요청 PDU에서 사용하며 에이전트는 응답으로 반복하는 순서 번호
• 요청과 응답을 일치시키는데 사용

오류 상태(Error status)

• 응답 PDU에서만 사용되는 정수로써 에이전트에 의해 보고되는 장애의 종류를 나타냄.
• 요청 PDU에서는 값이 0

오류의 유형

무-반복(Non-repeaters)

• 이 필드는 GetBulkRequest에서만 사용되며, 요청 PDU에서 비어 있는 error status 필드를 대체

장애 색인(Error index)

• 장애 색인은 관리자에게 장애를 일으킨 변수가 어느 것인지를 알려주는 옵셋

최대-반복(Max-repetition)

• 이 필드 또한 GetBulkRequest에서만 사용되며, 요청 PDU에서 비어 있는 장애 색인 필드를 대체

변수-값 리스트(Variable-value pair list)

• 이 리스트는 매니저가 읽거나 설정을 원하는 대응되는 값을 가진 변수들의 집합
• 요청 PDU들에서는 무효(null)값

메시지

SNMP는 단지 PDU만을 전송하지 않고 메시지에 PDU를 포함

SNMP 메시지

UDP 포트

SNMP는 잘 알려진 포트 161과 162를 통해 UDP의 서비스를 사용

 

잘 알려진 포트 161은 서버가 사용하며, 잘 알려진 포트 162는 클라이언트가 사용

 

에이전트가 수동 개방하는 경우

• 에이전트(서버)는 포트 161에 수동적 개방을 수행하고 관리자(클라이언트)로부터의 연결을 기다린다.
• 관리자(클라이언트)는 임시 포트(ephemeral port)를 사용하여 능동적 개방을 수행한다.
• 요청 메시지는 클라이언트로부터 서버로 전송되는데, 이때 발신지 포트로는 임시 포트를 사용하며, 목적지 포트로는 잘 알려진 포트 161을 사용한다.
• 응답 메시지는 서버로부터 클라이언트로 전송되는데, 이 때 발신지 포트로 잘 알려진 포트 161을 사용하며, 목적지 포트로는 임시 포트를 사용한다.

관리자(클라이언트)가 수동 개방하는 경우

• 관리자(클라이언트)는 포트 162에 수동적 개방을 수행한 후, 에이전트(서버)로부터의 연결을 기다린다.
• 에이전트(서버)는 전송할 Trap 메시지가 있을 때마다 임시 포트를 사용하여 능동적 개방을 수행한다.
• 이 연결은 서버에서 클라이언트로 단방향이다.

SNMP에서 클라이언트/서버 방식은 다른 프로토콜과는 다름

• 여기서는 클라이언트와 서버 모두 잘 알려진 포트를 사용한다.
• 그리고 클라이언트와 서버 모두 무한히 계속 수행되어야 한다.
• 그 이유는 요청 메시지는 관리자(클라이언트)에 의해 만들어지나, Trap 메시지는 에이전트(서버)에 의해 만들어지기 때문이다.

SNMP를 위한 포트 번호