Transcript SNMP for support

SNMP
(Simple Network Management System)
SNMP의 정의
• SNMP(Simple Network Management Protocol)
– 네트워크 장비를 관리 감시하기 위한 목적으로
TCP/IP 상에 정의된 응용 계층 표준 프로토콜
– 네트워크 관리자가 네트워크 성능을 관리, 문제 진단의 방법제시
SNMP의 출현 배경
Ping을 통해
ICMP를 이용.
88년 초 IAB에서
표준화 작업 시작
SNMP를
표준으로
채택
네트워크 관리, 관리자, SNMP
• 네트워크 관리 어플리케이션
–
–
–
–
네트워크 맵:
연결성, 토폴로지, 장치 상태를 표시
네트워크 부하 표시: 각 링크에 대한 현재 및 과거 사용량
에러 로그:
디바이스/링크 실패와 시간
성능 리포트
–
–
–
–
장치와 링크의 작동을 보장하기 위한 작동/성능 모니터링
최적의 성능을 위한 네트워크 튜닝
실패 시스템/소프트웨어/장치/링크 분리 및 수리
변경 또는 업그레이드를 위한 계획 수립
• 관리자의 역할
• SNMP 개념
– 매니저/에이전트 아키텍처, 관리 정보 기반 (MIB), 프로토콜
SNMP의 관리 기능
Functions
Management
Configuration
• Network 전체구성 파악
• 각각의 네트웍 장비를 비롯해 서버나 클라이언트 PC 등의 네트워크 구성 요소,
프로토콜, 토폴로지와 같은 요소들에 대한 정보를 GUI형태의 mapping을 통해
관리자 에게 전달하는 기능
Performance
• 네트웍 자원에 대한 현재 혹은 과거의 상태, 그 활용도 및 부하를 검사
• 향후 발생 가능한 문제점 검출 : 과다한 트래픽, 병목현상, 네트워크 응답시간
• 균형 있고 안정적인 네트워크가 될 수 있도록 해 주는 기능
Fault
• 네트워크 이상 동작 발견 시 : 원인파악 원인제거 향후 대책
• 장애 발생과 동시에 주변 네트워크 영향 최소화 작업
Security
• 내부의 중요하고, 민감한 데이터에 대해 외부로 부터의 침입이나 무단 사용을
• 방지하기 위한 기능
Account
• 네트워크 자원들을 사용하는 비용지불 : 이것(이를테면 공중 데이터망 포트)을
사용하는 그룹에 대하여 비용 계산을 한다.
• Account별 사용 특성 파악 : 통계자료를 통해서 향후 계획 수립
SNMP기반의 TCP /IP 관리 프로토콜
네트워크 관리 형태
관리 시스템
관리자 인터페이스
SNMP
UDP
MIB (Management Information Base)
: 관리되어야 할 객체들의 집합
MIB
IP
Network Interface
MIB
에이전트
프로세스
사용자
프로세스
SNMP
FTP
UDP
TCP
Network
Router
사용자
프로세스
에이전트
프로세스
FTP
SNMP
TCP
UDP
IP
Network Interface
에이전트 프로세스
IP
SNMP
Network Interface
UDP
Workstation
IP
Network Interface
Server
MIB
MIB
SNMP기반의 TCP /IP 관리 프로토콜
• 관리국(Management Station)
•
•
•
•
•
•
•
관리국이란 쉽게 말해서 우리가 일반적으로 NMS서버라 부르는 스테이션을 말한다.
관리국은 최소한 다음의 사항을 가지고 있어야 한다.
Ⅰ. 데이터 분석, 에러복구 등의 관리 어플리케이션들의 집합
Ⅱ. 네트워크 관리자가 네트워크를 감시하고 조정할 수 있게 하는 인터페이스
Ⅲ. 네트워크 관리자의 요구 즉, 네트워크상의 대상 요소를 실제로 감시하고 조정할 수 있도록
바꾸어 줄 수 있는 기능
Ⅳ. 모든 네트워크상의 관리되어 질 수 있는 개체(Agent)들의 MIB으로부터 뽑아낸 데이터 베이스 정보
• 관리 에이전트(Managed Agent)
•
일반적으로 SNMP 에이전트라고도 부르며 호스트 컴퓨터나 브리지, 라우터, 허브와 같은 장비로
관리국에 의해서 관리되어 질 수 있는 장비
•
피관리 에이전트는 독자적으로 장비 자신의 트래픽을 모니터링하고 그 통계 정보를 자신의 MIB
에 저장해두었다가 중앙의 관리국으로부터의 트래픽 정보 요구나 특정 동작 요청에 응답하고,
특정사건 발생시 관리국에 에이전트의 중요 정보를 제공한다.
SNMP기반의 TCP /IP 관리 프로토콜
•

관리 정보 베이스(Management Information Base)
네트워크 상의 트래픽 관리 정보를 관리하는 방법은 오브젝트로 정보를 관리하는 것이다.
각 정보를 하나의 오브젝트로 하여 오브젝트들의 계층적 구조로 트래픽 정보를 저장하고
검색할수 있도록 하는데, 이런 오브젝트들의 모임을 Management Information Base (MIB)라 한다
•

단순 네트워크 관리 프로토콜(SNMP)
관리국이 관리 에이전트의 트래픽 정보를 검색하고 그 MIB 설정을 바꿀수 있는
표준 프로토콜이 네트워크 관리 프로토콜 이다. 그 중 TCP/IP 네트워크의 관리용으로
쓰이는 프로토콜이 Simple Network Management Protocol (SNMP)이다.
•
SNMP는 Network Management Station과 Agent라 불리는 Network 요소들 사이에 관리 정보(MIB)
를 교환하는 간단한 요청/응답 기능을 하는 Protocol 이다.
SNMP기반의 TCP /IP 관리 프로토콜
• SNMP관리 모델
•
SNMP는 TCP/IP의 응용계층 프로토콜로 디자인되었고 전송 계층 프로토콜로는 UDP(User
Datagram Protocol)를 사용한다.(. 포트 161)
•
SNMP가 비접속 프로토콜(Connectionless Protocol)인 UDP를 사용하고 있기 때문에 SNMP
스스로도 비접속 프로토콜이다. 또한 SNMP는 네트워크장비 즉, 라우터나 브리지,서버,
호스트등의 Agent에 직접 Query하는 트랜젝션 지향 프로토콜(Transaction-Oriented
Protocol)이다.
•
Management Station의 관리 어플리케이션은 SNMP Agent의 MIB에 대한 접근과 객체를 관리하고,
네트워크 관리자(User)에 대한 인터페이스(GUI)를 제공.
•
각각의 Agent는 반드시 SNMP, UDP, IP를 반드시 구현.
게다가 Agent Process는 SNMP메시지를 해석 자기 자신의 MIB을 조정한다.
SNMP의 기능
• SNMP의 기능 3가지 : GET, SET , TRAP
UDP
161
조회
매니저
manager
조회에 대한 응답
UDP
162
트랩 전송
에이전트
agent
SNMP의 기능
GET : SNMP Station이 Agent의 오브젝트 값을 검색할 수 있게 한다.
SNMP의 기능
SET : SNMP Station이 Agent의 오브젝트 값을 설정할 수 있게 한다.
TRAP : Agent가 SNMP Station에 중요한
사건을 알릴 수 있게 한다.
SNMP 메시지 타입의 종류
SNMP PDU 타입
Get-Request
Get-Next-Request
Set-Request
Get-Response
TRAP
Manager가 Agent에게 MIB관리 정보를 요청한다.
Manager가 Agent에게 MIB관리 정보를 순차적으로 여러 개 가져올 것을 요청한다.
Manager가 Agent에게 MIB관리 정보의 값을 설정한다.
Agent가 Manager의 질의에 대한 응답을 보내준다.
Agent에서 특별한 이벤트가 발생할 경우 Manager의 질의가 없어도 능동적으로 Manager에게 알려
준다.
관리구성요소
관리 구성요소
• SNMP의 역할
– Manager와 Agent 사이에 교환되는 Packet(패킷)의 형식을 정의
– SNMP Packet에서 Object(객체)의 Status(값)을 읽고 변경할 수
있음
• SMI의 역할
– Object에 이름을 붙이고 객체의 유형을 정의
– 객체와 값들의 부호화하는 방법을 나타내기 위한 일반적인 규칙
들을 정의
– 어떤 개체가 관리해야 하는 객체의 수나 관리되는 객체의 이름
등은 정의하지 않음
– 객체와 값과의 연결은 관여하지 않음
• MIB의 역할
– 관리될 객체에서 이름이 지어진 객체와 그들의 유형, 그리고 서
로에 대한 관계들의 모음을 생성
SMI(Structure of Management Information)
• SMI(Structure of Management Information)
– SNMP의 위한 지침
– 기능
• 객체에 이름을 정의
• 객체에 저장된 데이터의 종류를 정의
• 네트워크 상의 전송을 위해 데이터의 인코딩을 정의
SMI(Structure of Management Information)
• NAME(개체 식별자)
트리 구조에 기초한 계층적 식
별자인 객체 식별자를 사용
정수-점 표현 : SNMP에 의해
사용
Ex) 1.3.6.1.2.1
이름-점 표현 : 사람이 사용
Ex)
iso.org.dod.internet.mgnt.
mib
SNMP에서 사용되는 객체는
mib 객체 밑에 위치
SMI(Structure of Management Information)
• Type
– 저장되는 데이터 유형
– SMI는 기본적인 ASN.1(Abstract Syntax Notation One) 규약을 사용
SMI(Structure of Management Information)
• Encoding Method
– BER(Basic Encodeing Rules)을 표준으로 사용
하여 전송되는 데이터를 인코딩
MIB (Management Information Base)
• MIB 분류
• 정보 내용 분류
– 설정 파라메터
• 주소, 기능 활성화/비활성화, 타이머 값 등등
– 작동 상태 정보
• 인터페이스 상태, 작동 모드 등등
– 성능 통계
• 프레임 카운트, 바이트 카운트, 에러 로그 등등
• 표준 MIB
– Ethernet, Token Ring, FDDI 등등
– IP, ICMP, UDP, TCP 등등
– Bridges
MIB의 구조
•
MIB를 정의하고 구성하는 뼈대(Framework)인 SMI는 RFC1155에 아래와 같은 사항을 정의
하고 있다.
(1) MIB의 각 객체(Object)들은 ISO와 ITU-T에 의해 표준화되고 개발된 언어인 ASN.1(Abstract
Syntax Notation One)을 사용해서 정의한다.
(2) 정의할 모든 객체는 반드시 이름, Syntax, 부호화(Encoding)을 갖고 있어야 한다.
Ⅰ. 이름 : 해당 객체를 식별하는 객체 식별자
예)Object Identifier
Ⅱ. Syntax : 객체의 데이터 종류
예) Interger, Octect String…
Ⅲ. 부호화 : 객체의 데이터가 어떤 Encoding방식으로 전송되는가?
MIB의 구조는 계층적 트리구조의 형태를 이루고 있다. 특정 객체는 객체 식별자
(ObjectIdentifier = OID)에 의해서 구분된다.
실제로 OID는 우리가 일반적으로 사용하는 문자가 아니라 연속된 정수이다.
MIB tree는 root를 기준으로 동일한 범주에 속하는 객체들을 분류하는 식으로 OID가 정해지고
snmp는 최종 노드인Object만을 읽고 쓸수가 있다.
MIB
•
•
•
트리 형식의 계층적 구조
Managed Object는 Object Identifier(OID)를 가짐
OID 표기법
–
–
–
A. internet OBJECT IDENTIFIER := { iso(1) org(3) dod(6) 1 }
B. internet OBJECT IDENTIFIER := { 1 3 6 1 }
C. internet OBJECT IDENTIFIER := 1.3.6.1
MIB
• MIB구조는 루트를 기준으로 동일한 범주에 속하는 객체들을 분류하
는 식으로
OID가 정해지고 SNMP는 최종 노드인 리프(leaf)만을 쓸 수가 있다.
• 모든 업체들을 구별하는 OID가 있어야 하는데 이는
IANA(Internet Assigned Number Authority)에서 관리하고 있다.
그러므로 자체 전사적인 MIB를 구현하기 위해서는 IANA에서
OID를 부여 받아야 한다.
그래야 그 하위 MIB의 객체의 우일성이 보장되고 그래야 다른 업체
의 사설 MIB와 구별이 가능하다.
IANA에 등록하면 ([email protected]) 곧 번호(OID)를 부여 받을 수
있다.
MIB의 확장
• MIB-II 는 몇 개의 오브젝트와 몇 개의 그룹을 더한 MIB-Ⅰ의 확장
판이다.
• 새로이 추가되는 오브젝트는 다음 3가지 방법중 한가지의 방법으로
MIB에 정의될 수 있다.
• Ⅰ. MIB-II 서브트리는 완전히 새로운 버전에 의해서 확장되거나 대
치될 수 있다.
• Ⅱ. 실험적인 MIB은 특정 어플리케이션에 대해 구축될 수 있다.
• Ⅲ. 특정 벤더/개인에 의한 확장은 Private 서브트리에 추가될 수 있
다.
* 기본 System, interfaces, at(주소변환), ip, icmp, tcp, udp등의 그룹
등으로 구성
MIB OBJECT
•
MIB-II 오브젝트는 11개의 MIB Object Group으로 나뉜다.
그룹
내용
SNMP
SNMP 프로토콜에 대한 정보를 갖는 객체들의 그룹이다.
System
시스템의 상태에 대한 객체들을 갖는다. 마지막으로 부팅된 시간, 시스템의 위치 등이 이
에 해당된다.
Interface
인터페이스 그룹 역시 모든 시스템에서 필수 사항이다. 시스템의 인터페이스개수, 상태
등이 그 객체다.
AT
Address Translation의 약자로 그룹으로서 각 인터페이스별 네트워크 주소 해석에 대한
객체를 갖는다.
IP
IP 패킷의 단편화, 패킷의 재조합 상태 등이 그 객체다.
ICMP
ICMP 오류 패킷의 수, 전송 불가 패킷의 수 등이 객체다.
TCP
특정 TCP 접속에 대한 정보를 펴현하는 객체 유형들은 일시적이다. 그 실체들은 접속이
끝남과 동시에 없어진다.
UDP
전송된 UDP의 개수, 수신된 UDP 패킷의 개수, 열린 포트 등의 정보들이 이에 해당된다.
EGP
EGP를 유지 관리하기 위한 객체들이다.
Transmission
각 인터페이스별 전송에 대한 정보들이 그 객체가 된다.
SNMP Message Format
SNMP Message Format
IP헤더 UDP 헤더 버전(0) 공동체 PDU 타입(0-3) 요구 ID 에러상황(0-5) 에러인덱스 이름
PDU 유형
이름
설명
0
Get – request
MIB관리 정보를 요청한다.
1
Get – next-request
다음 MIB관리 정보를 요청한다.
2
Get – response
MIB관리 정보의 값을 설정한다.
3
Set – request
질의에 대한 응답을 보내준다.
4
trap
MIB 변경의 값을 능동적으로 보내준다.
에러상태
이름
설명
0
noError
모든것이 OK
1
tooBig
응답을 단일 SNMP 메시지에 맞 출수 없음
2
noSuchName
존재하지 않은 변수의 지정
3
badValue
설정에서의 무효인 값 혹은 문맥의 지정
4
readOnly
관리자가 읽기만 가능한 값의 변경
5
genErr
그밖의 에러상황
값
※ tooBig의 max message size : 484octet (1octet = 8bit = 1byte)
SNMP Message Format
Trap PADDING
PDU 유형(4)
Enteterprise
Agent Addr
Trap Type(0~6) specific-trap
•
Enterprise
•
Agent Addr
•
트랩 메시지를 생성한 관리 에이젼트의 IP주소
Specific-trap
•
벤더에 의한 특별한 코드
Time stamp
•
트랩이 발생한 이후에 경과된 시간
•
•
•
Time stamp 이름
값
트랩 메시지를 생성한 SW 고유번호 기록
트랩 유형 이
름
설
명
0
1
coldStart
warmStart
Agent가 자기 자신을 초기화
Agent가 자기 자신을 재 초기화
2
linkDown
인터페이스가 가동상태에서 정지상태로 변화(구문 그대로 링크가 단절)
3
linkUp
인터페이스가 가동상태에서 정지상태로 변화(구문 그대로 링크가 연결)
4
authenticationFailure
SNMP 관리자로부터 무효인 공동체의 메시지를 받음
5
egpNeighborLoss
EGP 상대방이 정지상태로 변화
6
enterpriseSpecific
트랩의 정보에 관한 특정 코드 필드를 보는 것(밴더별 특정 코드값)
SNMP V1 / V2
•
1)SNMPv1 의 문제점
–
–
–
•
SNMPv2 의 등장
–
–
–
•
I . 관리자와 관리자간의 통신을 위한 InformRequest-PDU가 도입 분산관리의 가능.
II . 커다란 테이블 객체들의 값을 손쉽게 읽어오기 위해서 GetBulkRequest-PDU를 사용
이에 따라 한번의 요청으로 여러 테이블 값들을 읽어오는 것이 가능
III . 가장 큰 문제였던 보안 기능이 추가
그이외의 차이점
–
–
–
•
I . 보안기능이 거의 없다.
II . sysLocation 처럼 객체에 단 하나만의 값이 존재하는 경우는 문제가 없으나 RoutingTable처럼 많은 열
(row)이 존재하는 경우에는 전체 테이블을 읽고 싶을 때 수많은 요청/응답을 반복해야 한다.
III. 여러 관리자가 존재시에 관리자간의 통신기능이 정의 되어 있지 않다.
Get 명령은 SNMPv1의 경우 자동이지만 SNMPv2의 경우는 그렇지 않음
SNMPv1에서의 Get 명령은 요구되는 값에 대한 객체들의 목록을 포함하고 있는데, 이 목록의 객체중 적어
도 하나의 객체가 agent에 있지 않으면 전체의 명령은 받아들여지지 않음
SNMPv2의 경우는 부분적인 결과가 돌아올 수 있음
SNMPv3
–
–
–
보안기능 제공
Authentication(인증)
Encryption(암호)
Q/A
•
trap 이 발생하는 이유
•
trap의 필요성
– >장비가 꺼졌다 켜졌을 때
– >특정 포트의 장애가 발생하여 port down이 발생했을 때
– SNMP Manager는 polling이라는 방식을 통해 주기적으로 자신이 관리할 네트워크 장
비들에게 질의를 보낸다.
예를 들어, 200대의 스위치, 라우터, 서버, UPS가 등록된 네트워크를 관리하는 경우에
는 200번의 polling이 필요하다. 그런데 SNMP manager와 SNMP agent간의 네트워크
상태가 안 좋거나 할 때는 retry가 발생할 수 있기 때문에 장애가 있는 장비까지
polling이 도달하는 시간이 느려진다. 이런 경우 장애가 발생한 장비를 늦게 검색할 수
있는 위험이 있고 SNMP manager의 polling 프로세서가 알고리즘의 문제로 인해 장
애장비를 polling하기 이전에 그 이전의 polling list에 등록된 장비를 무한 polling하는
오류가 생길 수도 있다.
이러한 맹점을 보완하기 위해 SNMP에서 trap이라는 interrupt를 발생시켜 SNMP
manager에게 빠른 처리 요청을 할 수 있는 보완장치를 둔 것이다.