이번 호에는 네트워크 관리자의 기본적인 임무인 네트워크 관리에 대해 공부하
기로 하겠다.
양종윤 : 인하 대학교 전자 계산 공학과 전문가 시스템 연구실
들어가며
네트워크 관리란 어디까지를 말하는 것일까? 이에 대한 확실한 규정은 없다. 하
지만 일반적으로 네트워크 관리라 하면 네트워크의 장애 발견과 대책, 보안 정
책, 네트워크 부하의 조절 등의 업무를 의미한다.
참고적으로 국제표준화기구(ISO : International Organization for Standar
dization)가 정의하고 있는 다섯 가지의 네트워크 관리 기능에 대해 살펴보자.
(1) 네트워크 구성관리 - 네트워크 구성의 현상태를 감시하거나 보수 유지하는
기능.
(2) 네트워크 장애관리 - 네트워크에서 발생한 장애 등의 이상상태를 발견해서
장애가 발생한 장소와 발생하지 않은 장소를 분별하는 기능.
(3) 네트워크 보안관리 - 사용자 권한 설정 등의 접근 관리나 접근 권한을 관리
하는 기능.
(4) 성능관리 - 네트워크 기기의 용량이나 부하를 감시해서 성능을 일정 수준
으로 관리하는 기능.
(5) 계정관리 - 네트워크 사용자의 자원이용 상황에 관한 정보를 수집해서 네트
워크 사용자의 사용료를 부과하는 기능.
이 글에서는 이러한 여러 기능 가운데서 네트워크 장애 발견과 대책 그리고 네
트워크 감시에 대한 내용과 네트워크 관리 프로토콜에 대해 살펴보겠다.
네트워크 결함 발견하기
사실 잘 쓰던 네트워크가 갑자기 다운되었을 때 그 원인을 판단하는 것은 그다
지 어려운 일이 아니다. 네트워크가 완전히 다운된 경우는 다음의 몇 가지 원인
을 파악해 보면 그 이유를 알 수 있다.
(1) 게이트웨이 혹은 라우터 시스템이 다운된 경우
(2) 도메인네임 시스템(DNS)이 다운된 경우(물론 IP 주소로는 연결 가능하지만
과연 한 사람이 기억하는 IP 주소는 얼마나 될까?)
(3) LAN 선이 어디선가 끊긴 경우(물론 허브로 연결된 경우는 상관없다)
그리고 네트워크가 부분적으로 동작하는 경우는 LAN선 자체가 불량이거나 혹
은 LAN 터미네이터 혹은 카드 불량이다. 또 한 가지 원인은 게이트웨이가 처리
가능한 양보다많은 패킷이 흐르는 경우 게이트웨이가 패킷을 제대로 소화하지
못해서 발생한다. 원인이야 어찌되었건 일단 이러한 네트워크 불량이 발생하면
이를 체크해 원인을 파악해야 하는 것은 당연하며 이제부터 그 방법에 대해 설
명하겠다.
ping 명령으로 연결 확인
ping 명령에 대해서는 이미 앞서 TCP/IP에 대해 설명할 때 소개하였다. 사실
아주 간단한 명령이지만 어떤 호스트의 다운여부나 네트워크 불능여부를 파악하
는데는 이 명령 하나면 된다. 내부적으로 들어가면 ICMP의 echo request 기능
을 이용하는데 사실 문제점은 이 명령만 가지고는 호스트가 문제는 있지만 다운
되지는 않은 상태인 경우는 이를 파악하기 어렵다는 것이다. 이런 경우는 DNS
혹은 NFS 등의 서비스를 테스트해서 부수적인 정보를 더 얻을 필요가 있다.
traceroute 명령의 사용
ping 명령을 통해 기본적으로 네트워크에 문제가 있음을 알았으면 그 다음 조치
로는 traceroute 명령을 사용하여 네트워크 선로 중 어느 곳에 문제가 있는지를
추적한다.
다음의 예는 정상적으로 네트워크가 동작하는 경우의 결과를 보인 것이다. 목적
지까지 패킷이 제대로 전달됨을 볼 수 있다. 참고로 도메인 이름이 아닌 IP주소
로 나타난 호스트는 DNS에 등록이 되지 않았다는 의미이다.
[/inha5]# traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max,
40 byte packets
1 165.246.10.250 (165.246.10.250) 1 ms 1 ms 1 ms
2 165.246.15.1 (165.246.15.1) 2 ms 1 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 35 ms 32 ms 43 ms
4 203.240.29.81 (203.240.29.81) 57 ms 36 ms 69 ms
5 203.240.29.250 (203.240.29.250) 49 ms 85 ms 56 ms
6 210.120.128.5 (210.120.128.5) 77 ms 71 ms 57 ms
7 203.233.37.202 (203.233.37.202) 158 ms * 106 ms
8 www.lg.co.kr (165.243.5.37) 75 ms 549 ms 32 ms
이제 다음의 예를 보자. 3번째 호스트 혹은 라우터에 ‘!N’이 표시된 것을 볼
수 있을 것이다. 이는 ‘network unreachable’을 의미하는 것으로
pado-inha.kreonet.re.kr 호스트의 라우팅 테이블에 문제가 있어 패킷을 전달시
키지 못하는 것을 말한다.
[/inha5]# traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max,
40 byte packets
1 165.246.10.250 (165.246.10.250) 1 ms 1 ms 1 ms
2 165.246.15.1 (165.246.15.1) 2 ms 1 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) !N !N !N
다음의 예는 그리 흔한 예는 아니지만 멀티플렉싱 라우터의 예이다. 즉 아래의
호스트 중에 6번의 Taejon-Seoul-T3.kreonet.re.kr 호스트는 kfddi3.kreonet.re.kr
과 mix-serial4-1.SanFrancisco.mci.net 두군데로 패킷을 동시에 전송하는 것이
다.
[/inha5]# traceroute www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max,
40 byte pacs
1 165.246.10.250 (165.246.10.250) 2 ms 2 ms 2 ms
2 165.246.15.1 (165.246.15.1) 2 ms 2 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 6 ms 5 ms 4 ms
4 hongneung-nca-T3.kreonet.re.kr (134.75.27.1) 16 ms 8 ms 17 ms
5 gurum.kreonet.re.kr(134.75.28.1) 9 ms 14 ms 6 ms
6 Taejon-Seoul-T3.kreonet.re.kr(134.75.3.1) 10 ms 9 ms 31 ms
7 kfddi3.kreonet.re.kr (134.75.20.3) 68 ms 23 ms 16 ms
mix-serial4-1.SanFrancisco.mci.net (204.189.216.181) 298 ms
520 ms 545 ms
traceroute 명령의 결과에 ‘*’ 표시가 나타나는 경우가 있다. 이는 게이트웨이
가 제대로 동작하지 않음, 즉 패킷을 제대로 처리하지 못함을 의미한다. 이러한
‘*’ 표시가 계속적으로 보이면 그 게이트웨이는 십중팔구는 다운된 것이다.
그리고 산발적으로 보이는 경우는 네트워크의 패킷 흐름양이 너무 많아져 게이
트웨이가 상당히 늦게 패킷을 처리해서 생기는 결과이다. 다음이 그 예이다.
[/inha5]# traceroute -q 4 www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111),
30 hops max, 40 byte pacs
1 165.246.10.250 (165.246.10.250) 2 ms 2 ms 2 ms 2 ms
2 165.246.15.1 (165.246.15.1) 2 ms 2 ms 1 ms 2 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 6 ms 5 ms 4 ms 4 ms
4 hongneung-nca-T3.kreonet.re.kr (134.75.27.1) 16 ms 8 ms
17 ms 10 ms
5 gurum.kreonet.re.kr (134.75.28.1) 9 ms * 6 ms 6 ms
6 Taejon-Seoul-T3.kreonet.re.kr (134.75.3.1) * * * *
7 kfddi3.kreonet.re.kr (134.75.20.3) 68 ms 23 ms 16 ms 21 ms
mix-serial4-1.SanFrancisco.mci.net (204.189.216.181) 298 ms
520 ms 545 ms
위의 예에서 옵션 ‘-q’에 이어지는 4는 각 호스트마다 4개의 패킷을 보내어
확인하라는 의미이다. 이 경우 hongneung-nca-T3.kreonet.re.kr과
gurum.kreonet.re.kr 사이의 네트워크 전송 부하가 크며
Taejon-Seoul-T3.kreonet.re.kr 호스트는 다운된 상태로 보면 무난하다. 하지만
당부하고 싶은 것은 여러 이유로 인해 위의 리스트를 보고 예측한 것이 틀릴 수
도 있다는 점이다. 그러므로 최종적인 확인은 gurum.kreonet.re.kr과
Taejon-Seoul-T3.kreonet.re.kr 각각의 호스트로의 ping 명령을 통해 이루어져야
한다.
netstat 명령으로 네트워크 에러 체크하기
자, 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 특정 컴퓨터나 혹은
몇개의 컴퓨터만이 네트워크가 매우 느리거나 하는 경우가 있다. 이 경우
netstat 명령을 통해 확인한다. 이전 연재에서도 설명하였었지만 복습겸 다시 한
번 설명하도록 하겠다. 우선, 다음의 예를 보자. ‘-i’ 옵션은 네트워크 인터페
이스(카드)의 상태를 보여준다고 설명했었다.
[/inha5/g9611243]# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
tu0 1500 08:00:2b:e4:aa:33 45759959 14 30461144 0 336319
tu1 1500 07:00:4b:e2:aa:23 45759959 14 30461144 0 1336319
lo0 1536 115424 0 115424 0 0
lo0 1536 loop localhost 115424 0 115424 0 0
앞에서 보면 ‘tu0’이 받은 패킷 수는 45759959개이며 입력 에러 수는 14개,
출력 패킷 수는 30461144개이며 출력에러가 없다는 것을 알 수 있다. 입쪾출력
에러는 그 원인이 다양하므로 여기서는 논의하지 않겠다.
여기서 입쪾출력 에러의 비가 1%를 넘게되면 무슨 문제가 있다는 얘기이다. 만
약 특정 컴퓨터 하나에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에
문제가 있다는 것이므로 네트워크 카드의 교체를 검토해야 할 것이다. 주위의
다른 컴퓨터들에서도 같은 결과가 나온다면 이는 이들 컴퓨터 사이에 연결된 선
로에 문제가 있다는 것을 의미한다. 이런 경우 선로를 교체해야 할 것이다.
Coll 필드는 패킷의 충돌 횟수를 의미하는데 출력 패킷 수(Opkts)에 대한 비율
로 따져 1% 이하면 일반적인 경우이며 3% 이상이면 네트워크에 심각한 부하가
걸리는 것을 의미한다.
위의 경우 ‘tu1’ 네트워크 인터페이스에 부하가 많이 걸리는 것을 나타낸다.
이 경우는 선로에 대한 전반적인 설계를 다시 고려해야 함을 의미한다.
참고적으로 다음의 예는 순간순간 일정한 간격을 두고 처리되는 네트워크 정보
를 알고자 하는 경우 사용하는 ‘-I’ 옵션을 예로 든 것이다.
[/inha5/g9611243]# netstat -I tu0 5
input (tu0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
45761501 14 30462626 0 336324 45876925 14 30578050 0 336324
352 0 360 0 0 352 0 360 0 0
253 0 219 0 0 253 0 219 0 0
304 0 337 0 1 304 0 337 0 1
304 0 313 0 0 304 0 313 0 0
311 0 315 0 0 311 0 315 0 0
229 0 260 0 0 229 0 260 0 0
네트워크 관리 프로토콜
과거 네트워크가 그다지 보급되지 않은 시절에는 관리하는 네트워크 기기의 수
가 얼마 되지 않았다. 그래서 관리자는 이 기기들을 파악하여 문제가 발생할 때
경험과 직관으로 해결하였었다.
하지만 오늘날 네트워크가 대중화되어 그 기기의 수는 기하급수적으로 늘어났을
뿐만 아니라 이에 대한 관리는 때로는 기업의 이익과 직결된다고 보아도 틀린
말은 아닐 것이다. 이렇게 무수히 늘어난 네트워크 기기로 구성된 네트워크의
관리는 인터넷의 본고장인 미국에서 TCP/IP의 보급이 급속히 진전되면서 네트
워크 관리 프로토콜의 개발로 이어졌다.
최초로 고안된 것이 SGMP(Simple Gateway Monitoring Protocol)이다. 이것은
이름 그대로 네트워크 기기 중에서도 게이트웨이를 감시하기 위한 프로토콜이었
다. 이외에도 여러 가지 프로토콜들이 고안되었으나 IAB(Internet Architecture
Board)가 이러한 여러 프로토콜들의 장점을 모아 새로운 네트워크 관리 프로토
콜을 만들었다. 이것이 TCP/IP를 기반으로 SGMP를 계승한 SNMP(Simple
Network Management Protocol)이다.
한편, 국제표준화기구(ISO)에서는 OSI를 기반으로 한 네트워크 관리 프로토콜인
CMIS/CMIP(Common Mana gem ent Information Service/Protocol)의 표준화를
진행시키고 있었다. 당초 SNMP는 OSI를 사용한 네트워크 관리 프로토콜이 실
용화되기 전까지의 잠정적인 것이었으나 장치가 간단하다는 장점 때문에 많은
회사 기기에 장착되어 현재에 이르고 있다. OSI 기반의 CMIS/CMIP는 실용적
으로는 그다지 보급되지 못한 상황이기에 현시점에서 표준적인 네트워크 관리
프로토콜은 SNMP라고 할 수 있다.
SNMP
(The Simple Network Management Protocol)
SNMP는 일종의 클라이언트/서버 모델인 매니저(manager)/에이전트(agent)구
조이다. 각각의 에이전트들은 네트워크 장비나 호스트를 나타내는데 이들은 자
신의 네트워크에 대한 정보를 가지며 보통 snmpd라는 데몬을 수행한다. 그래서
매니저가 자신의 네트워크 정보에 대한 질의를 해오면 이에 대답하는 구조를 가
진다. TCP/IP의 네트워크 구성요소는 다음의 세 가지이다.
(1) Management Information Base(MIB)
- 에이전트가 어떤 정보를 가져야 하는지 정의
(2) Structure of Management Information(SMI)
- MIB의 변수값을 참조할 때 사용되는 계층구조
(3) Simple Network Management Protocol(SNMP)
- 매니저와 에이전트사이의 통신 프로토콜
SNMP 네임공간
SNMP 데이터 공간은 적어도 이론적으로는 광범위하게 확장 가능하다. 많은 부
분이 확장을 위해 남겨져 있다. 이러한 네임공간의 기본 형식은 SMI(Structure
of Management Information)이라 불리며 RFC1155에 기술되어 있다.
SMI는 파일시스템과 유사하게 계층적 구조를 가진다. 다른 점은 분리자로 도트
(.)를 사용하며 각 노드는 이름보다는 번호로 지정된다는 점이다. 하지만 관례적
으로 각 노드에는 텍스트 이름이 또한 주어진다. 이는 IP주소와 도메인명의 공
존이유처럼 사용자의 편의를 위한 것이다. 각 노드로의 경로는 OID(Object
IDentifier)라 불린다. 다음의 트리를 보자.
root
+----------------------+--------------------------+
ccitt(0) iso(1) joint-iso-ccitt(2)
|
org(3)
|
dod(6)
|
internet(1)
+-----------+----------+----------+--------+----------+
directory(1) mgmt(2) experimental(3) private(4) security(5) snmpv2(6)
| |
mib-2(1) enterprises(1)
+------------+--------+-----+------+------+------+------+-----+-
---+
system(1) interface(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) ...(9)
snmp(10)
가장 하위 노드들(system, interface 등)은 각각 네트워크 관리 정보를 가지는
변수들을 가진다. 각 변수들을 알아보기에 앞서 이러한 변수들의 데이터 타입에
대해 알아보도록 하자. 다음의 표는 객체(Object-변수)가 가질 수 있는 데이터
의 종류이다.
데이터 타입 설명
INTEGER 인터페이스의 MTU, IP forwarding flag, 여러 최대/최
소값 등을 나타낸다.
OCTET STRING 8비트 값을가지며 바이트(0~255 사이의 정수값)값의 나
열로써 BER인코딩 등에 사용된다.
DisplayString 8비트값을 가지는 것은 OCTER STRING과 같으나 각
바이트는 NVT ASCII의 문자이다. 이런 문자의 나열
로 MIB-II의 경우는 255개보다 적어야 한다.
OBJECT IDENTIFIER SMI에서의 각 객체(변수)를 나타내는 경로명 NULL값
을 가지지 않음을 나타낸다.
IpAddress 길이가 4인 OCTET STRING, 즉 IP주소를 나타낸다.
PhysAddress 길이가 6인 OCTET STRING으로 이서네트 주소를 나
타내는데 사용된다.
Counter 음수가 아닌 정수로 그 값이 0~4,294,967,295 사이를 순
차적으로 가지며 끝에 서는 다시 0으로 돌아오는 카운
터 용도이다.
Gauge Counter와 마찬가지이지만 그 값은 증가도 될 수 있고
감소도 될 수 있다. 값이 최대값에 이르면 리셋될 때까
지 대기한다.
TimeTicks 시간을 세는 카운터로서 보통 에이전트가 작동된 후의
시간을 100분의 1초로 나타내는데 사용한다.
SEQUENCE C 언어의 구조체와 유사하다. 즉 위의 데이터의 모음을
나타낸다.
SEQUENCE OF 일종의 배열로 기본 데이터형의 모음이다.
SMI의 노드인 OID는 위의 값 중 하나를 가지며 원하는 OID의 지정은 앞서 얘
기한 것처럼 ‘ . ’로 연결한 정수값을 이용한다. 위의 트리에서 예를 들면 at
의 경우 OID는 1.3.6.1.2.1.3이 되는 것이다.
Management Information Base(MIB)
네임공간의 실제 내용은 SNMP 프로토콜을 통해 접근할 수 있는 데이터를 나타
내는 MIB라 불리는 조각에 의해 모여져 있다. 기본적인 SNMP MIB는
RFC1066에 자세히 나와있다. 그리고 이에 대한 확장인 MIB-II에 대한 것은
RFC1213에 기술되어 있다. 요즘 대부분 시스템들은 MIB-II를 지원하는 추세이
다. 다음 표는 그 중 대표적인 몇 가지를 예로 든 것이다.
OID 이터 타입 내용
system.sysDescr text 시스템 정보-회사, 모델, OS종류 등
system.sysLocation text 시스템의 물리적 위치
system.sysContact text 시스템 구입자에 대한 연락 정보
system.sysName text 시스템의 이름, 보통 완전한 DNS명
interfaces.ifNumber int 존재하는 네트워크 인터페이스의 개수
interfaces.ifTable table 각 인터페이스에 대한 정보비트 테이블
ip.ipForwarding int 시스템이 게이트웨이면 1, 아니면 2
ip.ipAddrTable table IP 주소 데이터의 테이블(masks등)
ip.ipRouteTable table 시스템의 라우팅 테이블
icmp.icmpInRedirects int 수신된 ICMP redirects의 수
icmp.icmpInEchos int 수신된 ping의 개수
tcp.tcpConnTable table 현재 TCP 연결 테이블
udp.udpTable table 서버가 기다리는 UDP 소켓 테이블
위의 표에서 쓰인 데이터 타입은 독자들의 이해를 돕기 위해 간단히 나타낸 것
이나 엄밀히 말하면 앞서 얘기한 MIB 데이터 타입 중의 하나이다.
‘sys...’인 OID는 system 그룹의 OID 중의 하나이며 ‘interface..’인 OID는
if 그룹, ‘ip..’는 ip 그룹, ‘icmp..’는 icmp 그룹에 속한다. 이러한 MIB의 변
수들은 실제 참조할 때 인스턴스의 의미로 OID 끝에 ‘.0’을 붙인다. 예를 들
면 ‘system. sysDescr.0’과 같은 형태이다. 또한 각 변수들은 읽기/쓰기가 가
능한 것이 있는 반면 쓰기는 하지 못하는 변수도 있다.
SNMP 프로토콜 동작
SNMP는 다음의 5가지 종류의 메시지로서 매니저(클라이언트)와 에이전트(서
버) 사이의 통신이 이루어진다.
(1) 하나 이상의 변수값을 가져온다 : get-request 메시지
(2) 하나 이상의 변수 지정 후 다음 변수의 값을 가져온다
: get-next 메시지(테이블에서)
(3) 하나 이상의 변수 값을 지정한다 : set-request 메시지
(4) 하나 이상의 변수 값을 반환한다 : get-response 메시지, 에이전트가 매니저
로 앞의 3가지 메시지에 대한 결과로 전달하는 메시지
(5) 에이전트에 무슨 일이 발생하는 경우 매니저로 알려준다
: trap 메시지
trap 메시지의 경우는 전부 6가지가 있다. 다음 표를 확인해 보기 바란다.
trap 종류 이름 설 명
0 coldStart 에이전트가 자체적으로 초기화중이다.
1 warmStart 에이전트가 자체적으로 재초기화중이다.
2 linkDown 인터페이스가 다운되었음
3 linkUp 인터페이스가 구동하였음
4 authenticationFailure 매니저에게 받은 커뮤너티가 유효하지 않음
5 egpNeighborLoss EGP peer가 다운되었음
6 enterpriseSpecific 특정 시스템에 종속된 내용으로 specific code 필드
참조
이러한 클라이언트와 서버사이의 통신에는 사용자 인증, 혹은 패스워드와 같은
것이 존재해 서비스의 허용을 지정하는데 이 문자열을 커뮤너티(community)라
고 한다.
SNMP는 위와 같이 단순 질의/응답 프로토콜이므로 UDP 프로토콜을 통해 패
킷이 전송된다. 그러므로 매니저는 에이전트의 응답이 없는 경우 재전송이 필요
하게 된다.
SNMP는 2개의 포트를 사용한다. (1)-(4)의 메시지의 경우는 에이전트의 161번
포트로 접속하며 (5)같은 메시지는 매니저의 162번 포트로 접속된다. 그러므로
하나의 시스템이 매니저와 에이전트를 겸하는데 전혀 무리가 없다.
SNMP 패킷의 길이는 정해져 있지 않다. 그 이유는 ASN.1과 BER이라 불리는
것에 의해 인코딩되기 때문이다. 이것들에 대해서는 조금 뒤에서 설명하도록 하
겠다.
SNMP 문서들
다음은 SNMP와 관련된 문서들을 나타낸 것이다. SNMP, 특히 지면관계로 이
글에서는 언급하지 않은 OID들의 종류들에 대해서 자세히 알고자 하는 경우 참
조하기 바란다.
RFC 날짜 타이틀
1155 90.5 TCP-IP 기반의 인터넷을 위한 SMI
1157 90.5 A Simple Network Management Protocol (SNMP)
1212 91.3 MIB의 자세한 정의
1213 91.3 TCP-IP 기반의 인터넷을 위한 MIB : MIB-II
1351 92.7 SNMP 관리 모델
1352 92.7 SNMP 보안 프로토콜
1441 93.5 SNMP 버전 2의 소개
1442 93.5 SNMP 버전 2를 위한 SMI
1443 93.5 SNMP 버전 2를 위한 규약
1445 93.5 SNMP 버전 2를 위한 관리 모델
1446 93.5 SNMP 버전 2를 위한 보안 프로토콜
1450 93.5 SNMP 버전 2를 위한 MIB
1452 93.5 SNMP 버전 1, 2사이의 공유
1470 93.6 Network Management Tool Catalog에서의 FYI
1503 93.8 SNMP 버전 2 메니저에서의 자동 관리를 위한 알고리듬
1592 94.3 SNMP 분산 프로토콜 인터페이스 버전 2
RFC 항목 RFC 항목
1230 IEEE 802.4 토큰 버스 1512 FDDI
1231 IEEE 802.5 토큰 링 1513 토큰 링 확장
1243 AppleTalk 1514 호스트 리소스
1253 OSPF 1559 DECNET Phase IV
1315 Frame Relay DTEs 1565 서비스 모니터링
1354 IP forwarding tables 1566 메일 모니터링
1381 X.25 LAPB 1567 X.500 모니터링
1382 X.25 Packet layer 1593 SNA APPN 노드들
1389 RIP 버전 2
여러 시스템에서의 SNMP
HP-UX, IRIX 그리고 OSF/1에는 모두 SNMP 에이전트가 기본으로 설치되어있
다. 모두 MIB-II를 지원한다. 다른 시스템들 즉 BSDI, Solaris, SunOS 등은 상
용 패키지를 구해 설치해야 한다.
HP-UX의 경우 snmpd 데몬 프로그램은 /etc/snmpd.conf 파일에서 환경세팅을
한다. ‘#’으로 시작하는 줄은 주석을 의미한다. 5개의 서로다른 키워드가 사용
되는데 그 예는 다음과 같다.
# SNMP configuration file for host "hp712".
get-community-name: cuslug
set-community-name: cuslug
trap-dest: eslab
trap-dest: hp712
location: Inha Univ. 407
contact: Yang, Jong Yoon, ES Lab.
get-community-name과 set-community-name 키워드는 데이터값을 읽고 쓸 수
있게 허가된 SNMP 커뮤너티를 나열한다. 물론 하나 이상이 지정될 수 있다.
trap-dest 키워드는 trap 통보를 받아야하는 SNMP 클라이언트의 IP주소나 호스
트명을 지정한다. location과 contact 키워드는 보는 바와 같이 시스템의 위치와
관리하는 사람의 연락처 등을 형식없이 지정한다. 불행히도 HP-UX의 snm pd
는 syslog를 사용하지 않고 /usr/adm/snmpd.log 파일에 기록한다. 참고로 HP의
snmpd는 로그되는 정보양을 조절할 수 있는데
snmpd -m 로그매스크
명령을 통해 지정하며 로그매스크는 다음 표의 플래그를 bitwise OR 연산으로
묶는다. 예를 들면 6은 로그 에러와 컨피그 요구에 대한 로깅 정보를 기록한다.
플래그 의미 플래그 의미
0 로깅 기능 정지 8 로그 SNMP 트랜잭션
1 로그 인증 실패 16 로그 추가된 개체
2 로그 에러 32 모든 패킷을 16진수로 덤프
4 로그 컨피그 요구 64 로그 추적 메시지
IRIX는 snmpd를 부팅할 때 구동되도록 하려면 chkconfig snmpd on과 같은 명
령을 통해 지정하면 된다. 물론 수동으로 구동할 수도 있다. /etc/snmpd.auth 파
일은 보안환경 설정에 사용된다. 파일의 내용은 다음과 같다.
(accept|request) 호스트명:커뮤너티/동작....
모든 호스트를 나타내는 경우 와일드카드로서 ‘*’가 사용될 수 있다. 동작 필
드에는 빈칸으로 남겨놓으면 자동으로 모든 동작을 지정한다. 만약 읽기만 가능
하도록 하려면 get을 지정하면 된다. IRIX의 snmpd는 syslog를 이용하여 로깅
정보를 기록한다. 마찬가지로 옵션에 따라 로깅정보의 양을 조절할 수 있는데
매뉴얼을 참고하기 바란다.
OSF/1 시스템은 SNMP 에이전트가 여러 프로세스와 세팅 파일로 나뉘어 있다.
상당히 복잡하지만 확장가능성 면에서는 매우 좋다. 즉 새로운 MIB와 코드가
기존의 것과 잘 통합될 수 있다. 그 구성은 다음 표와 같다.
Component 기능
snmp_pe 기본 SNMP 프로토콜을 구현
mold snmp_pe를 이용해 MOM을 등록, 질의
internet_mom 표준 MIB-II를 구현하는 MOM
trn_mom RFC 1231에 지정된 토큰링에 대한 MOM
fddi_mom RFC 1285에 지정된 FDDI에 대한 MOM
snmpsetup 시스템의 SNMP세팅을 맞추는 스크립트
momgen 새 MOM을 기술하는데 사용하는 개발 도구
위에서 보면 생소한 단어가 나오는데 MOM이란 DEC에서 사용하는 말로
Managed Object Module의 약자이다. 이는 MIB를 구현한 프로그램을 뜻한다.
시스템에 새로운 MOM을 추가할 수 있는데 자세한 것은 snmpsetup의 매뉴얼
페이지를 참고하기 바란다.
기본적인 셋업에는 두개의 세팅파일이 사용되는데 /etc/eca /snmp_pe.conf 파일
은 기본적인 SNMP 프로토콜 엔진을 세팅하며 /etc/eca/internet_mom.conf 파일
은 MIB-II에 대한 옵션을 지정한다. 이 파일들은 직접 수정할 수도 있고 snmp
setup 스크립트를 사용할 수도 있다. snmp_pe.conf 파일에는 3가지 종류의 문장
이 사용되는데 community 문장에는 기본 SNMP 커뮤너티가 정의된다.
형식은 다음과 같다.
community 이름 IP주소 종류
‘이름’ 필드에는 커뮤너티의 이름이 지정되며 ‘종류’ 필드에는 접근권한을
지정한다. ‘종류’ 필드에는 readonly, rea dwrite, writeonly, none이 올 수 있
다.
‘IP주소’필드에 주소가 쓰이면 그 주소의 호스트만이 SN MP 에이전트에 접
근 가능하게 된다. 만약 0.0.0.0이 사용되면 주소 체크는 하지 않게 된다. trap 문
장에는 trap의 통보를 해줄 목적지 호스트를 지정한다. 형식은 다음과 같다.
trap 이름 IP주소
‘이름’ 필드에는 커뮤너티명이 들어간다. 물론 해당 호스트의 IP주소를 지정
하는 것은 필수이다. 또하나의 문장은 no_auth_traps이다. 이는 ‘authentication
failure’ trap이 발생하는 것을 막는다. internet_mom.conf 파일은 sysLocation
과 sysContact OID의 내용과 인터페이스가 제대로 잘 동작하는지 폴링하는 시
간을 초단위로 지정한다.
그 예가 다음과 같다.
Inha Univ. Inchon Nam-gu Young-Hyun Dong
Yang, Jong Yoon, ES LAB
60
CMU SNMP
상용의 SNMP 패키지를 제외한 프리웨어 SNMP 패키지 중에 가장 유명한 것
이 카네기 멜론 대학에서 만든 CMU SNMP 패키지이다. 이 패키지는 일반적인
anonymous ftp 사이트에 가면 쉽게 구할 수 있으니 여러분도 설치해 보기 바란
다. 이 툴 중에 가장 쓸만한 것이라면 snmpnetstat로써 지정된 호스트의 네트워
크 상태를 보여주는 것으로 거의 netstat 명령과 유사하다. 이 명령을 이용하면
해당 호스트로 로그인하지 않고도 네트워크 상태를 파악할 수 있는 것이다.
snmpnetstat 명령에 대한 여러 옵션은 다음과 같다.
옵션 의미
-i 네트워크 인터페이스의 상태를 보여줌
-INIC 지정된 인터페이스의 상태를 보여줌
-r 라우팅 테이블을 보여줌
-s 프로토콜 통계를 덤프함
다음은 명령을 사용한 예이다.
% snmpnetstat -i mllab.inha.ac.kr
Nmae MTU Ipkts Ierrs Opkts Oerrs
lo0 1536 2029 0 2035 0
en0 1500 3169 0 3395 0
snmpwalk 명령어는 하나의 OID의 변수값으로 모두 보여주는 명령이며
snmpget 명령은 OID의 한 변수값만을 보여준다. 다음은 사용예이다.
% snmpwalk -v 1 eslab.inha.ac.kr public
system.sysDescr.0 = "SunOS 4.1.3 Expert System Lab,
Inha Univ."
system.sysObjectID.0 = OID:enterprises.1701.1.1
.......
.......
% snmpwalk -v 1 eslab.inha.ac.kr public system.sysDescr.0
system.sysDescr.0 = "SunOS 4.1.3 Expert System Lab,
Inha Univ."
이 외에도 여러 명령어가 있어 SNMP 네임공간의 여러 부분에 대한 질의를 할
수 있다.
ASN.1과 BER
ASN.1(Abstract Syntax Notation 1)은 데이터를 기술하고 그 데이터의 속성을
나타내는데 사용하는 정형화된 언어이다. MIB의 모든 변수들과 SNMP 메시지
가 ASN.1을 통해 기술된다.
예를 들면 MIB의 IpAddress 데이터 타입은 다음처럼 정의 된다.
IpAddress ::=
[APPLICATION 0] -- 네트워크 바이트 순서
IMPLICIT OCTET STRING (SIZE (4))
비슷하게 하나의 변수에 대해서도 다음처럼 정의될 수 있다.
udpNoPorts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"수신된 UDP 데이터그램의 총 수"
::= { udp 2 }
그리고 이렇게 정의된 데이터들이 SNMP 패킷으로 만들어 질 때에는
BER(Basic Encode Rules) 방법을 통해 압축(?)되는 것이다.
SNMP Version 2
1993년 SNMPv1을 보안한 SNMPv2가 RFC1441에 발표되었다. 주로 새로운
MIB와 메시지가 추가되었다. 그래서 최근에는 많은 상업용 에이전트나 매니저
는 이 SNMPv2를 사용하고 있는 추세이다.
마치며
이번 호에는 네트워크 관리에 대해서 다루었다. 다른 주제에 대한 것도 마찬가
지이지만 특히 네트워크의 문제를 진단하고 해결하는 것은 그 원인이 무수히 많
은 것처럼 어떤 원칙이 없는 경우가 허다하다. 그러므로 많이 경험하는 것이 유
일한 공부 방법이라 할 수 있을 것이다. 다음에는 유즈넷 내용을 다루도록 하겠
다. 뉴스그룹이란 이름으로 잘 알려진 유즈넷이 어떻게 이루어지는지 자세히 공
부하도록 하겠다.
필자연락처 : Hitel-huclons 천리안-huclons
기로 하겠다.
양종윤 : 인하 대학교 전자 계산 공학과 전문가 시스템 연구실
들어가며
네트워크 관리란 어디까지를 말하는 것일까? 이에 대한 확실한 규정은 없다. 하
지만 일반적으로 네트워크 관리라 하면 네트워크의 장애 발견과 대책, 보안 정
책, 네트워크 부하의 조절 등의 업무를 의미한다.
참고적으로 국제표준화기구(ISO : International Organization for Standar
dization)가 정의하고 있는 다섯 가지의 네트워크 관리 기능에 대해 살펴보자.
(1) 네트워크 구성관리 - 네트워크 구성의 현상태를 감시하거나 보수 유지하는
기능.
(2) 네트워크 장애관리 - 네트워크에서 발생한 장애 등의 이상상태를 발견해서
장애가 발생한 장소와 발생하지 않은 장소를 분별하는 기능.
(3) 네트워크 보안관리 - 사용자 권한 설정 등의 접근 관리나 접근 권한을 관리
하는 기능.
(4) 성능관리 - 네트워크 기기의 용량이나 부하를 감시해서 성능을 일정 수준
으로 관리하는 기능.
(5) 계정관리 - 네트워크 사용자의 자원이용 상황에 관한 정보를 수집해서 네트
워크 사용자의 사용료를 부과하는 기능.
이 글에서는 이러한 여러 기능 가운데서 네트워크 장애 발견과 대책 그리고 네
트워크 감시에 대한 내용과 네트워크 관리 프로토콜에 대해 살펴보겠다.
네트워크 결함 발견하기
사실 잘 쓰던 네트워크가 갑자기 다운되었을 때 그 원인을 판단하는 것은 그다
지 어려운 일이 아니다. 네트워크가 완전히 다운된 경우는 다음의 몇 가지 원인
을 파악해 보면 그 이유를 알 수 있다.
(1) 게이트웨이 혹은 라우터 시스템이 다운된 경우
(2) 도메인네임 시스템(DNS)이 다운된 경우(물론 IP 주소로는 연결 가능하지만
과연 한 사람이 기억하는 IP 주소는 얼마나 될까?)
(3) LAN 선이 어디선가 끊긴 경우(물론 허브로 연결된 경우는 상관없다)
그리고 네트워크가 부분적으로 동작하는 경우는 LAN선 자체가 불량이거나 혹
은 LAN 터미네이터 혹은 카드 불량이다. 또 한 가지 원인은 게이트웨이가 처리
가능한 양보다많은 패킷이 흐르는 경우 게이트웨이가 패킷을 제대로 소화하지
못해서 발생한다. 원인이야 어찌되었건 일단 이러한 네트워크 불량이 발생하면
이를 체크해 원인을 파악해야 하는 것은 당연하며 이제부터 그 방법에 대해 설
명하겠다.
ping 명령으로 연결 확인
ping 명령에 대해서는 이미 앞서 TCP/IP에 대해 설명할 때 소개하였다. 사실
아주 간단한 명령이지만 어떤 호스트의 다운여부나 네트워크 불능여부를 파악하
는데는 이 명령 하나면 된다. 내부적으로 들어가면 ICMP의 echo request 기능
을 이용하는데 사실 문제점은 이 명령만 가지고는 호스트가 문제는 있지만 다운
되지는 않은 상태인 경우는 이를 파악하기 어렵다는 것이다. 이런 경우는 DNS
혹은 NFS 등의 서비스를 테스트해서 부수적인 정보를 더 얻을 필요가 있다.
traceroute 명령의 사용
ping 명령을 통해 기본적으로 네트워크에 문제가 있음을 알았으면 그 다음 조치
로는 traceroute 명령을 사용하여 네트워크 선로 중 어느 곳에 문제가 있는지를
추적한다.
다음의 예는 정상적으로 네트워크가 동작하는 경우의 결과를 보인 것이다. 목적
지까지 패킷이 제대로 전달됨을 볼 수 있다. 참고로 도메인 이름이 아닌 IP주소
로 나타난 호스트는 DNS에 등록이 되지 않았다는 의미이다.
[/inha5]# traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max,
40 byte packets
1 165.246.10.250 (165.246.10.250) 1 ms 1 ms 1 ms
2 165.246.15.1 (165.246.15.1) 2 ms 1 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 35 ms 32 ms 43 ms
4 203.240.29.81 (203.240.29.81) 57 ms 36 ms 69 ms
5 203.240.29.250 (203.240.29.250) 49 ms 85 ms 56 ms
6 210.120.128.5 (210.120.128.5) 77 ms 71 ms 57 ms
7 203.233.37.202 (203.233.37.202) 158 ms * 106 ms
8 www.lg.co.kr (165.243.5.37) 75 ms 549 ms 32 ms
이제 다음의 예를 보자. 3번째 호스트 혹은 라우터에 ‘!N’이 표시된 것을 볼
수 있을 것이다. 이는 ‘network unreachable’을 의미하는 것으로
pado-inha.kreonet.re.kr 호스트의 라우팅 테이블에 문제가 있어 패킷을 전달시
키지 못하는 것을 말한다.
[/inha5]# traceroute www.lg.co.kr
traceroute to www.lg.co.kr (165.243.5.37), 30 hops max,
40 byte packets
1 165.246.10.250 (165.246.10.250) 1 ms 1 ms 1 ms
2 165.246.15.1 (165.246.15.1) 2 ms 1 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) !N !N !N
다음의 예는 그리 흔한 예는 아니지만 멀티플렉싱 라우터의 예이다. 즉 아래의
호스트 중에 6번의 Taejon-Seoul-T3.kreonet.re.kr 호스트는 kfddi3.kreonet.re.kr
과 mix-serial4-1.SanFrancisco.mci.net 두군데로 패킷을 동시에 전송하는 것이
다.
[/inha5]# traceroute www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max,
40 byte pacs
1 165.246.10.250 (165.246.10.250) 2 ms 2 ms 2 ms
2 165.246.15.1 (165.246.15.1) 2 ms 2 ms 1 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 6 ms 5 ms 4 ms
4 hongneung-nca-T3.kreonet.re.kr (134.75.27.1) 16 ms 8 ms 17 ms
5 gurum.kreonet.re.kr(134.75.28.1) 9 ms 14 ms 6 ms
6 Taejon-Seoul-T3.kreonet.re.kr(134.75.3.1) 10 ms 9 ms 31 ms
7 kfddi3.kreonet.re.kr (134.75.20.3) 68 ms 23 ms 16 ms
mix-serial4-1.SanFrancisco.mci.net (204.189.216.181) 298 ms
520 ms 545 ms
traceroute 명령의 결과에 ‘*’ 표시가 나타나는 경우가 있다. 이는 게이트웨이
가 제대로 동작하지 않음, 즉 패킷을 제대로 처리하지 못함을 의미한다. 이러한
‘*’ 표시가 계속적으로 보이면 그 게이트웨이는 십중팔구는 다운된 것이다.
그리고 산발적으로 보이는 경우는 네트워크의 패킷 흐름양이 너무 많아져 게이
트웨이가 상당히 늦게 패킷을 처리해서 생기는 결과이다. 다음이 그 예이다.
[/inha5]# traceroute -q 4 www.oracle.com
traceroute to inet07-1.us.oracle.com (192.86.154.111),
30 hops max, 40 byte pacs
1 165.246.10.250 (165.246.10.250) 2 ms 2 ms 2 ms 2 ms
2 165.246.15.1 (165.246.15.1) 2 ms 2 ms 1 ms 2 ms
3 pado-inha.kreonet.re.kr (134.75.181.1) 6 ms 5 ms 4 ms 4 ms
4 hongneung-nca-T3.kreonet.re.kr (134.75.27.1) 16 ms 8 ms
17 ms 10 ms
5 gurum.kreonet.re.kr (134.75.28.1) 9 ms * 6 ms 6 ms
6 Taejon-Seoul-T3.kreonet.re.kr (134.75.3.1) * * * *
7 kfddi3.kreonet.re.kr (134.75.20.3) 68 ms 23 ms 16 ms 21 ms
mix-serial4-1.SanFrancisco.mci.net (204.189.216.181) 298 ms
520 ms 545 ms
위의 예에서 옵션 ‘-q’에 이어지는 4는 각 호스트마다 4개의 패킷을 보내어
확인하라는 의미이다. 이 경우 hongneung-nca-T3.kreonet.re.kr과
gurum.kreonet.re.kr 사이의 네트워크 전송 부하가 크며
Taejon-Seoul-T3.kreonet.re.kr 호스트는 다운된 상태로 보면 무난하다. 하지만
당부하고 싶은 것은 여러 이유로 인해 위의 리스트를 보고 예측한 것이 틀릴 수
도 있다는 점이다. 그러므로 최종적인 확인은 gurum.kreonet.re.kr과
Taejon-Seoul-T3.kreonet.re.kr 각각의 호스트로의 ping 명령을 통해 이루어져야
한다.
netstat 명령으로 네트워크 에러 체크하기
자, 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 특정 컴퓨터나 혹은
몇개의 컴퓨터만이 네트워크가 매우 느리거나 하는 경우가 있다. 이 경우
netstat 명령을 통해 확인한다. 이전 연재에서도 설명하였었지만 복습겸 다시 한
번 설명하도록 하겠다. 우선, 다음의 예를 보자. ‘-i’ 옵션은 네트워크 인터페
이스(카드)의 상태를 보여준다고 설명했었다.
[/inha5/g9611243]# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
tu0 1500 08:00:2b:e4:aa:33 45759959 14 30461144 0 336319
tu1 1500 07:00:4b:e2:aa:23 45759959 14 30461144 0 1336319
lo0 1536 115424 0 115424 0 0
lo0 1536 loop localhost 115424 0 115424 0 0
앞에서 보면 ‘tu0’이 받은 패킷 수는 45759959개이며 입력 에러 수는 14개,
출력 패킷 수는 30461144개이며 출력에러가 없다는 것을 알 수 있다. 입쪾출력
에러는 그 원인이 다양하므로 여기서는 논의하지 않겠다.
여기서 입쪾출력 에러의 비가 1%를 넘게되면 무슨 문제가 있다는 얘기이다. 만
약 특정 컴퓨터 하나에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에
문제가 있다는 것이므로 네트워크 카드의 교체를 검토해야 할 것이다. 주위의
다른 컴퓨터들에서도 같은 결과가 나온다면 이는 이들 컴퓨터 사이에 연결된 선
로에 문제가 있다는 것을 의미한다. 이런 경우 선로를 교체해야 할 것이다.
Coll 필드는 패킷의 충돌 횟수를 의미하는데 출력 패킷 수(Opkts)에 대한 비율
로 따져 1% 이하면 일반적인 경우이며 3% 이상이면 네트워크에 심각한 부하가
걸리는 것을 의미한다.
위의 경우 ‘tu1’ 네트워크 인터페이스에 부하가 많이 걸리는 것을 나타낸다.
이 경우는 선로에 대한 전반적인 설계를 다시 고려해야 함을 의미한다.
참고적으로 다음의 예는 순간순간 일정한 간격을 두고 처리되는 네트워크 정보
를 알고자 하는 경우 사용하는 ‘-I’ 옵션을 예로 든 것이다.
[/inha5/g9611243]# netstat -I tu0 5
input (tu0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
45761501 14 30462626 0 336324 45876925 14 30578050 0 336324
352 0 360 0 0 352 0 360 0 0
253 0 219 0 0 253 0 219 0 0
304 0 337 0 1 304 0 337 0 1
304 0 313 0 0 304 0 313 0 0
311 0 315 0 0 311 0 315 0 0
229 0 260 0 0 229 0 260 0 0
네트워크 관리 프로토콜
과거 네트워크가 그다지 보급되지 않은 시절에는 관리하는 네트워크 기기의 수
가 얼마 되지 않았다. 그래서 관리자는 이 기기들을 파악하여 문제가 발생할 때
경험과 직관으로 해결하였었다.
하지만 오늘날 네트워크가 대중화되어 그 기기의 수는 기하급수적으로 늘어났을
뿐만 아니라 이에 대한 관리는 때로는 기업의 이익과 직결된다고 보아도 틀린
말은 아닐 것이다. 이렇게 무수히 늘어난 네트워크 기기로 구성된 네트워크의
관리는 인터넷의 본고장인 미국에서 TCP/IP의 보급이 급속히 진전되면서 네트
워크 관리 프로토콜의 개발로 이어졌다.
최초로 고안된 것이 SGMP(Simple Gateway Monitoring Protocol)이다. 이것은
이름 그대로 네트워크 기기 중에서도 게이트웨이를 감시하기 위한 프로토콜이었
다. 이외에도 여러 가지 프로토콜들이 고안되었으나 IAB(Internet Architecture
Board)가 이러한 여러 프로토콜들의 장점을 모아 새로운 네트워크 관리 프로토
콜을 만들었다. 이것이 TCP/IP를 기반으로 SGMP를 계승한 SNMP(Simple
Network Management Protocol)이다.
한편, 국제표준화기구(ISO)에서는 OSI를 기반으로 한 네트워크 관리 프로토콜인
CMIS/CMIP(Common Mana gem ent Information Service/Protocol)의 표준화를
진행시키고 있었다. 당초 SNMP는 OSI를 사용한 네트워크 관리 프로토콜이 실
용화되기 전까지의 잠정적인 것이었으나 장치가 간단하다는 장점 때문에 많은
회사 기기에 장착되어 현재에 이르고 있다. OSI 기반의 CMIS/CMIP는 실용적
으로는 그다지 보급되지 못한 상황이기에 현시점에서 표준적인 네트워크 관리
프로토콜은 SNMP라고 할 수 있다.
SNMP
(The Simple Network Management Protocol)
SNMP는 일종의 클라이언트/서버 모델인 매니저(manager)/에이전트(agent)구
조이다. 각각의 에이전트들은 네트워크 장비나 호스트를 나타내는데 이들은 자
신의 네트워크에 대한 정보를 가지며 보통 snmpd라는 데몬을 수행한다. 그래서
매니저가 자신의 네트워크 정보에 대한 질의를 해오면 이에 대답하는 구조를 가
진다. TCP/IP의 네트워크 구성요소는 다음의 세 가지이다.
(1) Management Information Base(MIB)
- 에이전트가 어떤 정보를 가져야 하는지 정의
(2) Structure of Management Information(SMI)
- MIB의 변수값을 참조할 때 사용되는 계층구조
(3) Simple Network Management Protocol(SNMP)
- 매니저와 에이전트사이의 통신 프로토콜
SNMP 네임공간
SNMP 데이터 공간은 적어도 이론적으로는 광범위하게 확장 가능하다. 많은 부
분이 확장을 위해 남겨져 있다. 이러한 네임공간의 기본 형식은 SMI(Structure
of Management Information)이라 불리며 RFC1155에 기술되어 있다.
SMI는 파일시스템과 유사하게 계층적 구조를 가진다. 다른 점은 분리자로 도트
(.)를 사용하며 각 노드는 이름보다는 번호로 지정된다는 점이다. 하지만 관례적
으로 각 노드에는 텍스트 이름이 또한 주어진다. 이는 IP주소와 도메인명의 공
존이유처럼 사용자의 편의를 위한 것이다. 각 노드로의 경로는 OID(Object
IDentifier)라 불린다. 다음의 트리를 보자.
root
+----------------------+--------------------------+
ccitt(0) iso(1) joint-iso-ccitt(2)
|
org(3)
|
dod(6)
|
internet(1)
+-----------+----------+----------+--------+----------+
directory(1) mgmt(2) experimental(3) private(4) security(5) snmpv2(6)
| |
mib-2(1) enterprises(1)
+------------+--------+-----+------+------+------+------+-----+-
---+
system(1) interface(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) ...(9)
snmp(10)
가장 하위 노드들(system, interface 등)은 각각 네트워크 관리 정보를 가지는
변수들을 가진다. 각 변수들을 알아보기에 앞서 이러한 변수들의 데이터 타입에
대해 알아보도록 하자. 다음의 표는 객체(Object-변수)가 가질 수 있는 데이터
의 종류이다.
데이터 타입 설명
INTEGER 인터페이스의 MTU, IP forwarding flag, 여러 최대/최
소값 등을 나타낸다.
OCTET STRING 8비트 값을가지며 바이트(0~255 사이의 정수값)값의 나
열로써 BER인코딩 등에 사용된다.
DisplayString 8비트값을 가지는 것은 OCTER STRING과 같으나 각
바이트는 NVT ASCII의 문자이다. 이런 문자의 나열
로 MIB-II의 경우는 255개보다 적어야 한다.
OBJECT IDENTIFIER SMI에서의 각 객체(변수)를 나타내는 경로명 NULL값
을 가지지 않음을 나타낸다.
IpAddress 길이가 4인 OCTET STRING, 즉 IP주소를 나타낸다.
PhysAddress 길이가 6인 OCTET STRING으로 이서네트 주소를 나
타내는데 사용된다.
Counter 음수가 아닌 정수로 그 값이 0~4,294,967,295 사이를 순
차적으로 가지며 끝에 서는 다시 0으로 돌아오는 카운
터 용도이다.
Gauge Counter와 마찬가지이지만 그 값은 증가도 될 수 있고
감소도 될 수 있다. 값이 최대값에 이르면 리셋될 때까
지 대기한다.
TimeTicks 시간을 세는 카운터로서 보통 에이전트가 작동된 후의
시간을 100분의 1초로 나타내는데 사용한다.
SEQUENCE C 언어의 구조체와 유사하다. 즉 위의 데이터의 모음을
나타낸다.
SEQUENCE OF 일종의 배열로 기본 데이터형의 모음이다.
SMI의 노드인 OID는 위의 값 중 하나를 가지며 원하는 OID의 지정은 앞서 얘
기한 것처럼 ‘ . ’로 연결한 정수값을 이용한다. 위의 트리에서 예를 들면 at
의 경우 OID는 1.3.6.1.2.1.3이 되는 것이다.
Management Information Base(MIB)
네임공간의 실제 내용은 SNMP 프로토콜을 통해 접근할 수 있는 데이터를 나타
내는 MIB라 불리는 조각에 의해 모여져 있다. 기본적인 SNMP MIB는
RFC1066에 자세히 나와있다. 그리고 이에 대한 확장인 MIB-II에 대한 것은
RFC1213에 기술되어 있다. 요즘 대부분 시스템들은 MIB-II를 지원하는 추세이
다. 다음 표는 그 중 대표적인 몇 가지를 예로 든 것이다.
OID 이터 타입 내용
system.sysDescr text 시스템 정보-회사, 모델, OS종류 등
system.sysLocation text 시스템의 물리적 위치
system.sysContact text 시스템 구입자에 대한 연락 정보
system.sysName text 시스템의 이름, 보통 완전한 DNS명
interfaces.ifNumber int 존재하는 네트워크 인터페이스의 개수
interfaces.ifTable table 각 인터페이스에 대한 정보비트 테이블
ip.ipForwarding int 시스템이 게이트웨이면 1, 아니면 2
ip.ipAddrTable table IP 주소 데이터의 테이블(masks등)
ip.ipRouteTable table 시스템의 라우팅 테이블
icmp.icmpInRedirects int 수신된 ICMP redirects의 수
icmp.icmpInEchos int 수신된 ping의 개수
tcp.tcpConnTable table 현재 TCP 연결 테이블
udp.udpTable table 서버가 기다리는 UDP 소켓 테이블
위의 표에서 쓰인 데이터 타입은 독자들의 이해를 돕기 위해 간단히 나타낸 것
이나 엄밀히 말하면 앞서 얘기한 MIB 데이터 타입 중의 하나이다.
‘sys...’인 OID는 system 그룹의 OID 중의 하나이며 ‘interface..’인 OID는
if 그룹, ‘ip..’는 ip 그룹, ‘icmp..’는 icmp 그룹에 속한다. 이러한 MIB의 변
수들은 실제 참조할 때 인스턴스의 의미로 OID 끝에 ‘.0’을 붙인다. 예를 들
면 ‘system. sysDescr.0’과 같은 형태이다. 또한 각 변수들은 읽기/쓰기가 가
능한 것이 있는 반면 쓰기는 하지 못하는 변수도 있다.
SNMP 프로토콜 동작
SNMP는 다음의 5가지 종류의 메시지로서 매니저(클라이언트)와 에이전트(서
버) 사이의 통신이 이루어진다.
(1) 하나 이상의 변수값을 가져온다 : get-request 메시지
(2) 하나 이상의 변수 지정 후 다음 변수의 값을 가져온다
: get-next 메시지(테이블에서)
(3) 하나 이상의 변수 값을 지정한다 : set-request 메시지
(4) 하나 이상의 변수 값을 반환한다 : get-response 메시지, 에이전트가 매니저
로 앞의 3가지 메시지에 대한 결과로 전달하는 메시지
(5) 에이전트에 무슨 일이 발생하는 경우 매니저로 알려준다
: trap 메시지
trap 메시지의 경우는 전부 6가지가 있다. 다음 표를 확인해 보기 바란다.
trap 종류 이름 설 명
0 coldStart 에이전트가 자체적으로 초기화중이다.
1 warmStart 에이전트가 자체적으로 재초기화중이다.
2 linkDown 인터페이스가 다운되었음
3 linkUp 인터페이스가 구동하였음
4 authenticationFailure 매니저에게 받은 커뮤너티가 유효하지 않음
5 egpNeighborLoss EGP peer가 다운되었음
6 enterpriseSpecific 특정 시스템에 종속된 내용으로 specific code 필드
참조
이러한 클라이언트와 서버사이의 통신에는 사용자 인증, 혹은 패스워드와 같은
것이 존재해 서비스의 허용을 지정하는데 이 문자열을 커뮤너티(community)라
고 한다.
SNMP는 위와 같이 단순 질의/응답 프로토콜이므로 UDP 프로토콜을 통해 패
킷이 전송된다. 그러므로 매니저는 에이전트의 응답이 없는 경우 재전송이 필요
하게 된다.
SNMP는 2개의 포트를 사용한다. (1)-(4)의 메시지의 경우는 에이전트의 161번
포트로 접속하며 (5)같은 메시지는 매니저의 162번 포트로 접속된다. 그러므로
하나의 시스템이 매니저와 에이전트를 겸하는데 전혀 무리가 없다.
SNMP 패킷의 길이는 정해져 있지 않다. 그 이유는 ASN.1과 BER이라 불리는
것에 의해 인코딩되기 때문이다. 이것들에 대해서는 조금 뒤에서 설명하도록 하
겠다.
SNMP 문서들
다음은 SNMP와 관련된 문서들을 나타낸 것이다. SNMP, 특히 지면관계로 이
글에서는 언급하지 않은 OID들의 종류들에 대해서 자세히 알고자 하는 경우 참
조하기 바란다.
RFC 날짜 타이틀
1155 90.5 TCP-IP 기반의 인터넷을 위한 SMI
1157 90.5 A Simple Network Management Protocol (SNMP)
1212 91.3 MIB의 자세한 정의
1213 91.3 TCP-IP 기반의 인터넷을 위한 MIB : MIB-II
1351 92.7 SNMP 관리 모델
1352 92.7 SNMP 보안 프로토콜
1441 93.5 SNMP 버전 2의 소개
1442 93.5 SNMP 버전 2를 위한 SMI
1443 93.5 SNMP 버전 2를 위한 규약
1445 93.5 SNMP 버전 2를 위한 관리 모델
1446 93.5 SNMP 버전 2를 위한 보안 프로토콜
1450 93.5 SNMP 버전 2를 위한 MIB
1452 93.5 SNMP 버전 1, 2사이의 공유
1470 93.6 Network Management Tool Catalog에서의 FYI
1503 93.8 SNMP 버전 2 메니저에서의 자동 관리를 위한 알고리듬
1592 94.3 SNMP 분산 프로토콜 인터페이스 버전 2
RFC 항목 RFC 항목
1230 IEEE 802.4 토큰 버스 1512 FDDI
1231 IEEE 802.5 토큰 링 1513 토큰 링 확장
1243 AppleTalk 1514 호스트 리소스
1253 OSPF 1559 DECNET Phase IV
1315 Frame Relay DTEs 1565 서비스 모니터링
1354 IP forwarding tables 1566 메일 모니터링
1381 X.25 LAPB 1567 X.500 모니터링
1382 X.25 Packet layer 1593 SNA APPN 노드들
1389 RIP 버전 2
여러 시스템에서의 SNMP
HP-UX, IRIX 그리고 OSF/1에는 모두 SNMP 에이전트가 기본으로 설치되어있
다. 모두 MIB-II를 지원한다. 다른 시스템들 즉 BSDI, Solaris, SunOS 등은 상
용 패키지를 구해 설치해야 한다.
HP-UX의 경우 snmpd 데몬 프로그램은 /etc/snmpd.conf 파일에서 환경세팅을
한다. ‘#’으로 시작하는 줄은 주석을 의미한다. 5개의 서로다른 키워드가 사용
되는데 그 예는 다음과 같다.
# SNMP configuration file for host "hp712".
get-community-name: cuslug
set-community-name: cuslug
trap-dest: eslab
trap-dest: hp712
location: Inha Univ. 407
contact: Yang, Jong Yoon, ES Lab.
get-community-name과 set-community-name 키워드는 데이터값을 읽고 쓸 수
있게 허가된 SNMP 커뮤너티를 나열한다. 물론 하나 이상이 지정될 수 있다.
trap-dest 키워드는 trap 통보를 받아야하는 SNMP 클라이언트의 IP주소나 호스
트명을 지정한다. location과 contact 키워드는 보는 바와 같이 시스템의 위치와
관리하는 사람의 연락처 등을 형식없이 지정한다. 불행히도 HP-UX의 snm pd
는 syslog를 사용하지 않고 /usr/adm/snmpd.log 파일에 기록한다. 참고로 HP의
snmpd는 로그되는 정보양을 조절할 수 있는데
snmpd -m 로그매스크
명령을 통해 지정하며 로그매스크는 다음 표의 플래그를 bitwise OR 연산으로
묶는다. 예를 들면 6은 로그 에러와 컨피그 요구에 대한 로깅 정보를 기록한다.
플래그 의미 플래그 의미
0 로깅 기능 정지 8 로그 SNMP 트랜잭션
1 로그 인증 실패 16 로그 추가된 개체
2 로그 에러 32 모든 패킷을 16진수로 덤프
4 로그 컨피그 요구 64 로그 추적 메시지
IRIX는 snmpd를 부팅할 때 구동되도록 하려면 chkconfig snmpd on과 같은 명
령을 통해 지정하면 된다. 물론 수동으로 구동할 수도 있다. /etc/snmpd.auth 파
일은 보안환경 설정에 사용된다. 파일의 내용은 다음과 같다.
(accept|request) 호스트명:커뮤너티/동작....
모든 호스트를 나타내는 경우 와일드카드로서 ‘*’가 사용될 수 있다. 동작 필
드에는 빈칸으로 남겨놓으면 자동으로 모든 동작을 지정한다. 만약 읽기만 가능
하도록 하려면 get을 지정하면 된다. IRIX의 snmpd는 syslog를 이용하여 로깅
정보를 기록한다. 마찬가지로 옵션에 따라 로깅정보의 양을 조절할 수 있는데
매뉴얼을 참고하기 바란다.
OSF/1 시스템은 SNMP 에이전트가 여러 프로세스와 세팅 파일로 나뉘어 있다.
상당히 복잡하지만 확장가능성 면에서는 매우 좋다. 즉 새로운 MIB와 코드가
기존의 것과 잘 통합될 수 있다. 그 구성은 다음 표와 같다.
Component 기능
snmp_pe 기본 SNMP 프로토콜을 구현
mold snmp_pe를 이용해 MOM을 등록, 질의
internet_mom 표준 MIB-II를 구현하는 MOM
trn_mom RFC 1231에 지정된 토큰링에 대한 MOM
fddi_mom RFC 1285에 지정된 FDDI에 대한 MOM
snmpsetup 시스템의 SNMP세팅을 맞추는 스크립트
momgen 새 MOM을 기술하는데 사용하는 개발 도구
위에서 보면 생소한 단어가 나오는데 MOM이란 DEC에서 사용하는 말로
Managed Object Module의 약자이다. 이는 MIB를 구현한 프로그램을 뜻한다.
시스템에 새로운 MOM을 추가할 수 있는데 자세한 것은 snmpsetup의 매뉴얼
페이지를 참고하기 바란다.
기본적인 셋업에는 두개의 세팅파일이 사용되는데 /etc/eca /snmp_pe.conf 파일
은 기본적인 SNMP 프로토콜 엔진을 세팅하며 /etc/eca/internet_mom.conf 파일
은 MIB-II에 대한 옵션을 지정한다. 이 파일들은 직접 수정할 수도 있고 snmp
setup 스크립트를 사용할 수도 있다. snmp_pe.conf 파일에는 3가지 종류의 문장
이 사용되는데 community 문장에는 기본 SNMP 커뮤너티가 정의된다.
형식은 다음과 같다.
community 이름 IP주소 종류
‘이름’ 필드에는 커뮤너티의 이름이 지정되며 ‘종류’ 필드에는 접근권한을
지정한다. ‘종류’ 필드에는 readonly, rea dwrite, writeonly, none이 올 수 있
다.
‘IP주소’필드에 주소가 쓰이면 그 주소의 호스트만이 SN MP 에이전트에 접
근 가능하게 된다. 만약 0.0.0.0이 사용되면 주소 체크는 하지 않게 된다. trap 문
장에는 trap의 통보를 해줄 목적지 호스트를 지정한다. 형식은 다음과 같다.
trap 이름 IP주소
‘이름’ 필드에는 커뮤너티명이 들어간다. 물론 해당 호스트의 IP주소를 지정
하는 것은 필수이다. 또하나의 문장은 no_auth_traps이다. 이는 ‘authentication
failure’ trap이 발생하는 것을 막는다. internet_mom.conf 파일은 sysLocation
과 sysContact OID의 내용과 인터페이스가 제대로 잘 동작하는지 폴링하는 시
간을 초단위로 지정한다.
그 예가 다음과 같다.
Inha Univ. Inchon Nam-gu Young-Hyun Dong
Yang, Jong Yoon, ES LAB
60
CMU SNMP
상용의 SNMP 패키지를 제외한 프리웨어 SNMP 패키지 중에 가장 유명한 것
이 카네기 멜론 대학에서 만든 CMU SNMP 패키지이다. 이 패키지는 일반적인
anonymous ftp 사이트에 가면 쉽게 구할 수 있으니 여러분도 설치해 보기 바란
다. 이 툴 중에 가장 쓸만한 것이라면 snmpnetstat로써 지정된 호스트의 네트워
크 상태를 보여주는 것으로 거의 netstat 명령과 유사하다. 이 명령을 이용하면
해당 호스트로 로그인하지 않고도 네트워크 상태를 파악할 수 있는 것이다.
snmpnetstat 명령에 대한 여러 옵션은 다음과 같다.
옵션 의미
-i 네트워크 인터페이스의 상태를 보여줌
-INIC 지정된 인터페이스의 상태를 보여줌
-r 라우팅 테이블을 보여줌
-s 프로토콜 통계를 덤프함
다음은 명령을 사용한 예이다.
% snmpnetstat -i mllab.inha.ac.kr
Nmae MTU Ipkts Ierrs Opkts Oerrs
lo0 1536 2029 0 2035 0
en0 1500 3169 0 3395 0
snmpwalk 명령어는 하나의 OID의 변수값으로 모두 보여주는 명령이며
snmpget 명령은 OID의 한 변수값만을 보여준다. 다음은 사용예이다.
% snmpwalk -v 1 eslab.inha.ac.kr public
system.sysDescr.0 = "SunOS 4.1.3 Expert System Lab,
Inha Univ."
system.sysObjectID.0 = OID:enterprises.1701.1.1
.......
.......
% snmpwalk -v 1 eslab.inha.ac.kr public system.sysDescr.0
system.sysDescr.0 = "SunOS 4.1.3 Expert System Lab,
Inha Univ."
이 외에도 여러 명령어가 있어 SNMP 네임공간의 여러 부분에 대한 질의를 할
수 있다.
ASN.1과 BER
ASN.1(Abstract Syntax Notation 1)은 데이터를 기술하고 그 데이터의 속성을
나타내는데 사용하는 정형화된 언어이다. MIB의 모든 변수들과 SNMP 메시지
가 ASN.1을 통해 기술된다.
예를 들면 MIB의 IpAddress 데이터 타입은 다음처럼 정의 된다.
IpAddress ::=
[APPLICATION 0] -- 네트워크 바이트 순서
IMPLICIT OCTET STRING (SIZE (4))
비슷하게 하나의 변수에 대해서도 다음처럼 정의될 수 있다.
udpNoPorts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"수신된 UDP 데이터그램의 총 수"
::= { udp 2 }
그리고 이렇게 정의된 데이터들이 SNMP 패킷으로 만들어 질 때에는
BER(Basic Encode Rules) 방법을 통해 압축(?)되는 것이다.
SNMP Version 2
1993년 SNMPv1을 보안한 SNMPv2가 RFC1441에 발표되었다. 주로 새로운
MIB와 메시지가 추가되었다. 그래서 최근에는 많은 상업용 에이전트나 매니저
는 이 SNMPv2를 사용하고 있는 추세이다.
마치며
이번 호에는 네트워크 관리에 대해서 다루었다. 다른 주제에 대한 것도 마찬가
지이지만 특히 네트워크의 문제를 진단하고 해결하는 것은 그 원인이 무수히 많
은 것처럼 어떤 원칙이 없는 경우가 허다하다. 그러므로 많이 경험하는 것이 유
일한 공부 방법이라 할 수 있을 것이다. 다음에는 유즈넷 내용을 다루도록 하겠
다. 뉴스그룹이란 이름으로 잘 알려진 유즈넷이 어떻게 이루어지는지 자세히 공
부하도록 하겠다.
필자연락처 : Hitel-huclons 천리안-huclons
