2010. 2. 1. 11:10

How to write a shell script

How to write a shell script

Introduction

A shell is a command line interpretor. It takes commands and executes them. As such, it implements a programming language. The Bourne shell is used to create shell scripts -- ie. programs that are interpreted/executed by the shell. You can write shell scripts with the C-shell; however, this is not covered here.

Creating a Script

Suppose you often type the command

find . -name file -print

and you'd rather type a simple command, say

sfind file

Create a shell script

% cd ~/bin

% emacs sfind

% page sfind

find . -name $1 -print

% chmod a+x sfind

% rehash

% cd /usr/local/bin

% sfind tcsh

./shells/tcsh

Observations

This quick example is far from adequate but some observations:

Shell scripts are simple text files created with an editor.
Shell scripts are marked as executeable

3. %chmod a+x sfind

Should be located in your search path and ~/bin should be in your search path.
You likely need to rehash if you're a Csh (tcsh) user (but not again when you login).
Arguments are passed from the command line and referenced. For example, as $1.

#!/bin/sh

All Bourne Shell scripts should begin with the sequence

#!/bin/sh

From the man page for exec(2):

"On the first line of an interpreter script, following the "#!", is the name of a program which should be used to interpret the contents of the file. For instance, if the first line contains "#! /bin/sh", then the con- tents of the file are executed as a shell script."

You can get away without this, but you shouldn't. All good scripts state the interpretor explicitly. Long ago there was just one (the Bourne Shell) but these days there are many interpretors -- Csh, Ksh, Bash, and others.

Comments

Comments are any text beginning with the pound (#) sign. A comment can start anywhere on a line and continue until the end of the line.

Search Path

All shell scripts should include a search path specifica- tion:

PATH=/usr/ucb:/usr/bin:/bin; export PATH

A PATH specification is recommended -- often times a script will fail for some people because they have a different or incomplete search path.

The Bourne Shell does not export environment variables to children unless explicitly instructed to do so by using the export command.

Argument Checking

A good shell script should verify that the arguments sup- plied (if any) are correct.

if [ $# -ne 3 ]; then

echo 1>&2 Usage: $0 19 Oct 91

exit 127

fi

This script requires three arguments and gripes accordingly.

Exit status

All Unix utilities should return an exit status.

# is the year out of range for me?

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of range

exit 127

fi

etc...

# All done, exit ok

exit 0

A non-zero exit status indicates an error condition of some sort while a zero exit status indicates things worked as expected.

On BSD systems there's been an attempt to categorize some of the more common exit status codes. See /usr/include/sysexits.h.

Using exit status

Exit codes are important for those who use your code. Many constructs test on the exit status of a command.

The conditional construct is:

if command; then

command

fi

For example,

if tty -s; then

echo Enter text end with \^D

fi

Your code should be written with the expectation that others will use it. Making sure you return a meaningful exit status will help.

Stdin, Stdout, Stderr

Standard input, output, and error are file descriptors 0, 1, and 2. Each has a particular role and should be used accordingly:

# is the year out of range for me?

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of my range

exit 127

fi

etc...

# ok, you have the number of days since Jan 1, ...

case `expr $days % 7` in

0)

echo Mon;;

1)

echo Tue;;

etc...

Error messages should appear on stderr not on stdout! Output should appear on stdout. As for input/output dialogue:

# give the fellow a chance to quit

if tty -s ; then

echo This will remove all files in $* since ...

echo $n Ok to procede? $c; read ans

case "$ans" in

n*|N*)

echo File purge abandoned;

exit 0 ;;

esac

RM="rm -rfi"

else

RM="rm -rf"

fi

Note: this code behaves differently if there's a user to communicate with (ie. if the standard input is a tty rather than a pipe, or file, or etc. See tty(1)).

Language Constructs

For loop iteration

Substitute values for variable and perform task:

for variable in word ...

do

command

done

For example:

for i in `cat $LOGS`

do

mv $i $i.$TODAY

cp /dev/null $i

chmod 664 $i

done

Alternatively you may see:

for variable in word ...; do command; done

Case

Switch to statements depending on pattern match

case word in

[ pattern [ | pattern ... ] )

command ;; ] ...

esac

For example:

case "$year" in

[0-9][0-9])

year=19${year}

years=`expr $year - 1901`

;;

[0-9][0-9][0-9][0-9])

years=`expr $year - 1901`

;;

*)

echo 1>&2 Year \"$year\" out of range ...

exit 127

;;

esac

Conditional Execution

Test exit status of command and branch

if command

then

command

[ else

command ]

fi

For example:

if [ $# -ne 3 ]; then

echo 1>&2 Usage: $0 19 Oct 91

exit 127

fi

Alternatively you may see:

if command; then command; [ else command; ] fi

While/Until Iteration

Repeat task while command returns good exit status.

{while | until} command

do

command

done

For example:

# for each argument mentioned, purge that directory

while [ $# -ge 1 ]; do

_purge $1

shift

done

Alternatively you may see:

while command; do command; done

Variables

Variables are sequences of letters, digits, or underscores beginning with a letter or underscore. To get the contents of a variable you must prepend the name with a $.

Numeric variables (eg. like $1, etc.) are positional vari- ables for argument communication.

Variable Assignment

Assign a value to a variable by variable=value. For example:

PATH=/usr/ucb:/usr/bin:/bin; export PATH

or

TODAY=`(set \`date\`; echo $1)`

Exporting Variables

Variables are not exported to children unless explicitly marked.

# We MUST have a DISPLAY environment variable

if [ "$DISPLAY" = "" ]; then

if tty -s ; then

echo "DISPLAY (`hostname`:0.0)? \c";

read DISPLAY

fi

if [ "$DISPLAY" = "" ]; then

DISPLAY=`hostname`:0.0

fi

export DISPLAY

fi

Likewise, for variables like the PRINTER which you want hon- ored by lpr(1). From a user's .profile:

PRINTER=PostScript; export PRINTER

Note: that the Cshell exports all environment variables.

Referencing Variables

Use $variable (or, if necessary, ${variable}) to reference the value.

# Most user's have a /bin of their own

if [ "$USER" != "root" ]; then

PATH=$HOME/bin:$PATH

else

PATH=/etc:/usr/etc:$PATH

fi

The braces are required for concatenation constructs.

$p_01

The value of the variable "p_01".

${p}_01

The value of the variable "p" with "_01" pasted onto the end.

Conditional Reference

o ${variable-word}

If the variable has been set, use it's value, else use word.

POSTSCRIPT=${POSTSCRIPT-PostScript};

export POSTSCRIPT

${variable:-word}

If the variable has been set and is not null, use it's value, else use word.

These are useful constructions for honoring the user envi- ronment. Ie. the user of the script can override variable assignments. Cf. programs like lpr(1) honor the PRINTER environment variable, you can do the same trick with your shell scripts.

${variable:?word}

If variable is set use it's value, else print out word and exit. Useful for bailing out.

Arguments

Command line arguments to shell scripts are positional vari- ables:

$0, $1, ...

The command and arguments. With $0 the command and the rest the arguments.

$#

The number of arguments.

$*, $@

All the arguments as a blank separated string. Watch out for "$*" vs. "$@".
And, some commands:

shift

Shift the postional variables down one and decrement number of arguments.

set arg arg ...

Set the positional variables to the argument list.

Command line parsing uses shift:

# parse argument list

while [ $# -ge 1 ]; do

case $1 in

process arguments...

esac

shift

done

A use of the set command:

# figure out what day it is

TODAY=`(set \`date\`; echo $1)`

cd $SPOOL

for i in `cat $LOGS`

do

mv $i $i.$TODAY

cp /dev/null $i

chmod 664 $i

done

Special Variables

o $$

Current process id. This is very useful for constructing temporary files.

tmp=/tmp/cal0$$

trap "rm -f $tmp /tmp/cal1$$ /tmp/cal2$$"

trap exit 1 2 13 15

/usr/lib/calprog >$tmp

$?

The exit status of the last command.

$command

# Run target file if no errors and ...

if [ $? -eq 0 ]

then

etc...

fi

Quotes/Special Characters

Special characters to terminate words:

; & ( ) | ^ < > new-line space tab

These are for command sequences, background jobs, etc. To quote any of these use a backslash (\) or bracket with quote marks ("" or '').

Single Quotes

Within single quotes all characters are quoted -- including the backslash. The result is one word.

grep :${gid}: /etc/group | awk -F: '{print $1}'

Double Quotes

Within double quotes you have variable subsitution (ie. the dollar sign is interpreted) but no file name generation (ie. * and ? are quoted). The result is one word.

if [ ! "${parent}" ]; then

parent=${people}/${group}/${user}

fi

Back Quotes

Back quotes mean run the command and substitute the output.

if [ "`echo -n`" = "-n" ]; then

n=""

c="\c"

else

n="-n"

c=""

fi

and

TODAY=`(set \`date\`; echo $1)`

Functions

Functions are a powerful feature that aren't used often enough. Syntax is

name ()

{

commands

}

For example:

# Purge a directory

_purge()

{

# there had better be a directory

if [ ! -d $1 ]; then

echo $1: No such directory 1>&2

return

fi

etc...

}

Within a function the positional parmeters $0, $1, etc. are the arguments to the function (not the arguments to the script).

Within a function use return instead of exit.

Functions are good for encapsulations. You can pipe, redi- rect input, etc. to functions. For example:

# deal with a file, add people one at a time

do_file()

{

while parse_one

etc...

}

etc...

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

cat $1 | do_file

else

do_file

fi

Sourcing commands

You can execute shell scripts from within shell scripts. A couple of choices:

sh command

This runs the shell script as a separate shell. For example, on Sun machines in /etc/rc:

sh /etc/rc.local

. command

This runs the shell script from within the current shell script. For example:

# Read in configuration information

. /etc/hostconfig

What are the virtues of each? What's the difference? The second form is useful for configuration files where environment variable are set for the script. For example:

for HOST in $HOSTS; do

# is there a config file for this host?

if [ -r ${BACKUPHOME}/${HOST} ]; then

. ${BACKUPHOME}/${HOST}

fi

etc...

Using configuration files in this manner makes it possible to write scripts that are automatically tailored for differ- ent situations.

Some Tricks

Test

The most powerful command is test(1).

if test expression; then

etc...

and (note the matching bracket argument)

if [ expression ]; then

etc...

On System V machines this is a builtin (check out the com- mand /bin/test).

On BSD systems (like the Suns) compare the command /usr/bin/test with /usr/bin/[.

Useful expressions are:

test { -w, -r, -x, -s, ... } filename

is file writeable, readable, executeable, empty, etc?

test n1 { -eq, -ne, -gt, ... } n2

are numbers equal, not equal, greater than, etc.?

test s1 { =, != } s2

Are strings the same or different?

test cond1 { -o, -a } cond2

Binary or; binary and; use ! for unary negation.

For example

if [ $year -lt 1901 -o $year -gt 2099 ]; then

echo 1>&2 Year \"$year\" out of range

exit 127

fi

Learn this command inside out! It does a lot for you.

String matching

The test command provides limited string matching tests. A more powerful trick is to match strings with the case switch.

# parse argument list

while [ $# -ge 1 ]; do

case $1 in

-c*) rate=`echo $1 | cut -c3-`;;

-c) shift; rate=$1 ;;

-p*) prefix=`echo $1 | cut -c3-`;;

-p) shift; prefix=$1 ;;

-*) echo $Usage; exit 1 ;;

*) disks=$*; break ;;

esac

shift

done

Of course getopt would work much better.

SysV vs BSD echo

On BSD systems to get a prompt you'd say:

echo -n Ok to procede?; read ans

On SysV systems you'd say:

echo Ok to procede? \c; read ans

In an effort to produce portable code we've been using:

# figure out what kind of echo to use

if [ "`echo -n`" = "-n" ]; then

n=""; c="\c"

else

n="-n"; c=""

fi

etc...

echo $n Ok to procede? $c; read ans

Is there a person?

The Unix tradition is that programs should execute as qui- etly as possible. Especially for pipelines, cron jobs, etc.

User prompts aren't required if there's no user.

# If there's a person out there, prod him a bit.

if tty -s; then

echo Enter text end with \^D

fi

The tradition also extends to output.

# If the output is to a terminal, be verbose

if tty -s <&1; then

verbose=true

else

verbose=false

fi

Beware: just because stdin is a tty that doesn't mean that stdout is too. User prompts should be directed to the user terminal.

# If there's a person out there, prod him a bit.

if tty -s; then

echo Enter text end with \^D >&0

fi

Have you ever had a program stop waiting for keyboard input when the output is directed elsewhere?

Creating Input

We're familiar with redirecting input. For example:

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

cat $1 | do_file

else

do_file

fi

alternatively, redirection from a file:

# take standard input (or a specified file) and do it.

if [ "$1" != "" ]; then

do_file < $1

else

do_file

fi

You can also construct files on the fly.

rmail bsmtp <<$1@newshost.uwo.ca>

rcpt to:

data

from: <$1@newshost.uwo.ca>

to:

Subject: Signon $2

subscribe $2 Usenet Feeder at UWO

.

quit

EOF

Note: that variables are expanded in the input.

String Manipulations

One of the more common things you'll need to do is parse strings. Some tricks

TIME=`date | cut -c12-19`

TIME=`date | sed 's/.* .* .* $.*$ .* .*/\1/'`

TIME=`date | awk '{print $4}'`

TIME=`set \`date\`; echo $4`

TIME=`date | (read u v w x y z; echo $x)`

With some care, redefining the input field separators can help.

#!/bin/sh

# convert IP number to in-addr.arpa name

name()

{ set `IFS=".";echo $1`

echo $4.$3.$2.$1.in-addr.arpa

}

if [ $# -ne 1 ]; then

echo 1>&2 Usage: bynum IP-address

exit 127

fi

add=`name $1`

nslookup < < EOF | grep "$add" | sed 's/.*= //'

set type=any

$add

EOF

Debugging

The shell has a number of flags that make debugging easier:

sh -n command

Read the shell script but don't execute the commands. IE. check syntax.

sh -x command

Display commands and arguments as they're executed. In a lot of my shell scripts you'll see

# Uncomment the next line for testing

# set -x

Based on An Introduction to Shell Programing by:

Reg Quinton

Computing and Communications Services

The University of Western Ontario

London, Ontario N6A 5B7

Canada

Press here to return to the General Unix Software Menu.

저작자표시

Posted by 두장

2009. 11. 11. 15:00

Computer/Network

SNMP

단순 망 관리 규약(SNMP) 표준

------------------------------------------------------------------------------------------------------------------------------

대한민국 전산망표준
KIS―3I―0016('93)
단순 망 관리 규약(SNMP) 표준
1993. 12

체 신 부

전 문

본 규약은 이기종으로 구성된 전산망의 효율적인 관리를 목표로, TCP/IP를 기반으로 하는 전산망을 관리하기 위해 간단히 운용할 수 있는 구조와 시스템을 제공한다. 본 규약은 국내전산 망이 개방시스템 상호접속(OSI)으로 완전히 전환되기 전까지는 전산망관리 잠정표준으로서 전산 망에 적용된다.

본 규약은 전산망내에 있는 노드들을 관리하기 위해 사용되는 단순 네트워크 관리 프로토콜 (SNMP: Simple Network Management Protocol)을 규정한다. 그리고 관리정보의 정의를 위한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 규정하고, TCP/IP를 기반으로 하는 전산망에서, 피관리 대상들의 집합체인 관리정보베이스의 두 번째 버전(MIB-II: Management Information Base)을 정의한다.

본 규약은 미국 IETF(Internet Engineering Task Force)에서 발간된 RFC(Request For Comments) 1155 -- SMI, RFC 1213 -- MIB-II, RFC 1157 -- SNMP 를 번역하여 국내 전문가의 기술적인 검토를 토대로 작성되었다.

* 주요단어 : 단순전산망관리(SNMP), 관리정보구조(SMI), 관리정보베이스(MIB)

--------------------------------------------------------------------------------------------------------------------------------

목 차

제 1 장 총 칙

1.1 목적
1.2 필요성
1.3 적용대상 및 범위
1.4 주요내용

제 2 장 근거 및 관련표준
2.1 근거
2.2 관련표준

제 3 장 용어의 정의
3.1 주요 용어 정의

제 4 장단순 전산망관리 프로토콜(SNMP)
  4.1 개요
  4.2 SNMP 구조
  4.2.1 구조의 목적
  4.2.2 구조의 구성 요소
  4.3 프로토콜 명시
  4.3.1 절차 요소
  4.4 정의
  4.5 참고 문헌

제 5 장 TCP/IP기반 연결망(internets)을 위한 관리정보의 구조(SMI)
  5.1 개요
  5.2 관리 정보의 구조와 식별
  5.2.1 이름
  5.2.2 구문
  5.2.3 부호화
  5.3 관리 객체
  5.3.1 객체 이름에 대한 지침
  5.3.2 객체 유형과 실체
  5.3.3 관리 객체를 위한 매크로
  5.4 MIB 확장
  5.5 정의
  5.6 참고 문헌

제 6 장 TCP/IP기반 연결망의 네트워크관리를 위한 관리정보베이스(MIB-II)
  6.1 개요
  6.2 RFC 1156으로부터의 변화
  6.2.1 삭제 대상 객체
  6.2.2 출력 문자열
  6.2.3 물리적 주소
  6.2.4 시스템 그룹
  6.2.5 인터페이스 그룹
  6.2.6 주소 해석 그룹
  6.2.7 IP 그룹
  6.2.8 ICMP 그룹
  6.2.9 TCP 그룹
  6.2.10 UDP 그룹
  6.2.11 EGP 그룹
  6.2.12 전송 그룹
  6.2.13 SNMP 그룹
  6.2.14 RFC 1158로부터의 변화
  6.3 관리 객체
  6.3.1 정의 형식
  6.4. 정의
  6.4.1 본문의 관례적 표기
  6.4.2 MIB-II에서의 그룹
  6.4.3 시스템 그룹
  6.4.4 인터페이스 그룹
  6.4.5 주소 변환 그룹
  6.4.6 IP 그룹
  6.4.7 ICMP 그룹
  6.4.8 TCP 그룹
  6.4.9 UDP 그룹
  6.4.10 EGP 그룹
  6.4.11 전송 그룹
  6.4.12 SNMP 그룹
  6.5 참고 문헌

보칙

부칙

제 1 장 총 칙

1.1 목적

이 표준은 TCP/IP 기반 전산망을 관리하기 위해 사용되는 단순전산망관리 규약(SNMP : Simple Network Management Protocol)을 규정하여 효과적인 전산망관리를 도모하고자 한다.

1.2 필요성

전산망은 관련기술의 급속한 발달로 다양한 기능 및 서비스를 제공하고 있으며 과거의 중앙 집중방식에서 분산환경으로 바뀌고 있다. 또한 다수공급자에 의해 제공되며 다양한 장비로 구성되는 전산망은 본질적으로 복잡성 및 이질성을 내포하고 있다.

따라서 이러한 전산망 구성요소를 효과적으로 감시·통제하기 위한 전산망관리는 그 중요성이 점증되고 있다. 이질적인 전산망을 효과적으로 관리하기 위한 개방적이고 표준화된 괸리시스템이 존재하지 않는다면 호환성 및 상호운용성을 보장하는 개방시스템은 통제불능으로 인해 그의미가 상실될 것이다.

효과적인 전산망관리를 수행하려면 기본적으로 전산망관리 시스템과 피관리노드간의 관리정보를 주고 받기위해 관리정보 통신프로토콜, 관리정보구조, 관리정보의 정의 등의 전산망관리 매카니즘이 표준화되어야 한다.

1.3 적용대상 및 범위

이 표준의 적용범위는 전산망관리 표준 프로토콜의 제정에 필요한 단순 전산망관리 규약(SNMP: Simple Network Management Protocol) 표준, 관리정보구조(SMI: Structure of Management Information)에 관한 표준, 관리정보베이스(MIB: Management Information Base) 표준을 포함하고 있다.

국가기간전산망 또는 정부기관 전산망의 관리자와 전산망관리 제품의 구매자가 이 표준에서 언급하는 전산망관리 잠정표준 프로토콜과 동등한 기능을 제공하는 전산망관리 제품이나 서비스가 조달되어질 때 적용된다.

1.4 주요내용

이 표준의 내용은 다음과 같다.

첫째, TCP/IP를 갑으로 하는 전산망에 있는 노드들을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공하는 단순 전산망관리 프로토콜(SNMP: Simple Network Management Protocol)을 규정한다.

둘째, 관리정보는 TCP/IP를 기반으로 하는 전산망을 관리하는데 사용되는 것으로 이 관리정보의 정의에 대한 공통구조와 식별기법을 기술한 관리정보구조(SMI: Structure of Management Information)를 제공한다.

셋째, TCP/IP를 기반으로 하는 전산망의 관리 프로토콜을 이용한 관리정보베이스의 두번째 버전(MIB-II: Management Information Base)을 정의한다.

제 2 장 근거 및 관련표준

2.1 근거

전산망 기술기준에 관한 규칙 제 4 조 (기능표준등의 고시)

2.2 관련표준

○ "Structure and Identification of Management Information for TCP/IP-based internets" RFC 1155, IETF.

○ "The Simple Network Management Protocol (SNMP)", RFC 1157, IETF.

○ "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, IETF.

제 3 장 용어의 정의

3.1 주요 용어 정의

⊙ CMIP over TCP(CMOT): OSI 전산망관리 프로토콜을 TCP/IP를 사용하는 전산망에 적용하는 전산망관리 방법

⊙ High-level Entity Management System(HEMS): 인터네트에서 초기에 고안한 전산 망관리 시스템

⊙ IP 계층(internet layer): 인터네트 프로토콜 중 상이한 물리적 전산망 사이의 상호 통신을 담당하는 계층

⊙ Internet Assigned Numbers Authority(IANA): 인터네트 프로토콜에서 사용하는 할당 번호를 관리하는 기구

⊙ Internet Control Message Protocol(ICMP): IP의 간단한 보고용 프로토콜

⊙ Internet Engineering Steering Group(IESG): IETF의 활동을 조정하는 그룹

⊙ Internet Engineering Task Force(IETF): 인터네트의 단기적 문제를 해결하기 위한 IAB의 소위원회

⊙ Request for Comments(RFC): 인터네트 프로토콜 또는 그와 관련된 실험을 기술 하는 문서

⊙ Simple Gateway Monitoring Protocol(SGMP): SNMP의 원형인 관리 프로토콜 참고

⊙ 개방시스템상호접속(Open Systems Interconnection : OSI): IOS의 개방형 전산망 시스템

⊙ 게이트웨이(gateway): 인터네트에서 라우터를 지칭하는 용어로 둘 또는 그 이상의 종속망을 상호접속하여 한 종속망에서 다른 쪽으로의 데이타의 통로를 가능케하는 장비 또는 장비의 쌍

⊙ 경량 표현 프로토콜(light weight presentation protocol): OSI의 표현 서비스중 일부 만을 지원하는 프로토콜

⊙ 공개 키(public key): 이중 암호 시스템에서 공개시키는 키

⊙ 공통관리 정보규약(Common Management Information Protocol : CMIP): 전산망 관리를 위해 OSI에서 제정한 프로토콜

⊙ 공통관리 정보서비스(Common Management Information Service : CMIS): CMIP 에서 제공하는 전산망관리 서비스, OSI 시스템관리 소프트웨어 프로세스간에 관리정보 의 상호교환을 성취시켜주는 통신 메카니즘

⊙ 관리 대상(managed object): 전산망관리에 필요한 정보

⊙ 관리 대상군(managed object group): 같은 전산망 기능을 관리하는 관리 대상의 집합

⊙ 관리 대상점(managed node): 전산망관리 대리인을 가지고 있는 전산망 장비

⊙ 관리 정보 기반(Management Information Base : MIB): 관리 대상의 집합

⊙ 구성 관리(configuration management): 전산망관리 기능중 전산망을 형성하는 전산망 요소들의
연결성, 동작 상태, 관리 상태등을 감시하고 제어하는 기능

⊙ 국제표준화기구(International Organization for Standardization : ISO): 국제 표준을 제정하는 기관

⊙ 군체(community): 전산망관리 대리인과 전산망 관리소와의 행정적 관계

⊙ 군체 단면(community profile): 군체의 소속원이 조작할 수 있는 전산망관리 대리인이 보유하고 있는 관리 대상의 일부

⊙ 군체 이름(community name): 군체를 나타내는 문자 스트링

⊙ 기본 부호화 법칙(Basic Encoding Rules): 전송 구문을 기술하는 OSI에서 정의한 언어

⊙ 단순 네트워크 관리 프로토콜(Simple Network Management Protocol : SNMP):
1988년 초, Internet Activities Board(IAB)가 가진 ad-hoc 모임 즉, 국가 전체의 TCP/IP에 기초를 둔 Internet를 관리하는데 있어 전략을 결정하기 위한 이 모임에서 표준화에 대한 단기해결책으로 제시한 방안.

⊙ 단편(fragment): 큰 IP 데이타그램이 분할된 조각

⊙ 데이터 그램(datagram): 다른 데이터그램 등과 독립적으로 전송되는 독립 데이터 단위

⊙ 무결성(integtity): 현한을 부여 받지 않은 개체로 부터의 영향으로는 시스템이나 데이터가 변경되거나 파괴되지 않고 원래대로 보존되는 특성

⊙ 무연결형(connection-less mode): 한 단계에서 데이터 전송과 주소 지정과 같은 제어를 같이하는 서비스

⊙ 물리적 주소(hardware address): 물리적 인터페이스의 주소

⊙ 분할(fragmentation): 큰 IP 데이터그램을 여러개의 단편으로 나누는 것

⊙ 성능 관리(performance management): 전산망관리 기능중 전산망의 부하나 제반 성능을 감시하는 기능

⊙ 세그먼트(segment): TCP의 통신 단위

⊙ 실험적 MIB(experimental MIB): 인터네트 관리 공간중 experimental 트리에 등록되어 있는 관리 대상의 집합

⊙ 연결형(connection-oriented mode): 경로 연결, 데이터 전송, 경로 해제의 세 단계로 구성된 서비스

⊙ 외부 게이트웨이 프로토콜(Exterior Gateway Protocol : EGP): 인터네트의 외부 게이트웨이 사이에서 라우팅을 위해 제정한 프로토콜

⊙ 응용 계층(application layer): 응용 프로세스 사이의 통신을 관리하는 OSI 시스템의 최상층 구조

⊙ 인스턴스 인식표(instance-identifier): 관리 대상 인스턴스를 인식하는 방법

⊙ 인증(Authentication): 통신 상대방의 신분을 확인하여 접근이 허용된 실체인지 확인하는 것

⊙ 인터네트(Internet): 인터네트 프로토콜에 의해 상호 연결된 거대한 전산망의 집합

⊙ 인터네트 전산망 관리 기초구조(Internet-standard Network Management Framework): REC 1155, 1156, 1157에 정의된 인터네트에서 제정한 전산망관리 시스템의 기본 구조

⊙ 인터네트 초안(Internet Drafts): IETF의 작업결과를 기술하는 문서

⊙ 인터네트 표준개발 위원회(Internet Activities Board : IAB): 인터네트 프로토 콜의 발달을 총괄하는 기술적 기구

⊙ 인터네트 프로토콜(Internet Protocol : IP): IP 계층에서 사용하는 프로토콜

⊙ 인터네트 프로토콜 주소(IP address): 인터네트에 접속된 점을 나타내는 32bit로 된 주소

⊙ 인터페이트 계층(interface layer): 한 물리적 전산망안에서의 전송을 하는 인터네트 프로토콜의 최하계층

⊙ 장애 관리(fault management): 전산망관리 기능 중 전산망 장비의 장애 발견 및 원인 구분, 그리고 비정상적인 동작이나 장애 상태를 수리하는 기능

⊙ 전산망 관리소(network management station): 전산망의 관리를 관장하는 시스템

⊙ 전산망 인식표(network-identifier): IP 주소중 전산망을 지칭하는 부분

⊙ 전산망관리(network management): 전산망이 본연의 목적을 달성하도록 감시 제어 하는 행위

⊙ 전산망관리 대리인(network management agent): 전산망 관리소의 감시, 제어하에 관리 대상을 관리하는 관리 대상점에 있는 전산망관리 프로토콜의 구현

⊙ 전산망관리 프로토콜(network management protocol): 관리 정보를 전송하기 위한 프로토콜

⊙ 전송 제어 규약(Transmission Control Protocol : TCP): 미국 국방성의 ARPANET 에서 처음 사용되었으며 ISO의 트랜스포트 계층에 해당하는 ordered, connection-oriented, reliable, full-duplex 프로토콜

⊙ 접근 권한(Authorization): 통신 상대방이 접근할 수 있는 데이터의 범위와 접근 형태를 정의하는 것

⊙ 접근 제어(access control): 불법적으로 시스템이나 레이더에 접근하는 것을 방지함

⊙ 접근 형태(access mode): SNMP 군체가 보유하고 있는 관리 대상에 대한 접근 권한

⊙ 추상 구문(abstract syntax): 하드웨어의 구조 및 한계와 독립적인 데이터 유형의 기술

⊙ 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1): 추상 구문을 기술하기 위해 OSI에서 제정한 언어 ⊙ 포트 번호(port number): 인터네트 프로토콜의 전송 계층에서 응용 프로세스를 구별하는 번호

⊙ 프로토콜 데이타 단위(protocol data unit:PDU) : 프로토콜 제어 정보와 사용자 데이터를 포함하는 프로토콜 실체간의 전송 단위

⊙ 프로토콜 제어 정보(protocol control information): 상대편과의 통신을 제어하는 정보

⊙ 행정 구조(administrative framework): 인증과 접근 권한 방침을 정의하기 위한 방법

⊙ 호스트(host): 응용 계층 서비스를 하는 전산망 설비를 지칭하는 인터네트 용어

제 4 장 단순 망관리 프로토콜(SNMP)

4.1 개요

단순 망관리 프로토콜(SNMP) 표준은 전산망 구성 요소에 관한 관리 정보가 논리적으로 원격 지사용자들에 의해 조사되거나 변경될 수 있게 지원하는 간단한 프로토콜을 정의한다. 특히, 관리정보 베이스(MIB)와 함께 관리 정보의 구조(SMI)를 기술하는 관련 표준들과 같이 본 표준은 TCP/IP를 기반으로 하는 연결망들(internets)을 관리하기 위해 간단하고 운영가능한 구조와 시스템을 제공한다.

인터네트 전산망 관리 표준안(Internet Network Management Standards)[1] 개발을 위한 인터네트 표준개발 위원회(Internet Activities Board:IAB) 권고안인 RFC 1052에 보고된 것처럼,TCP/IP를 기반으로 하는 연결망의 전산망관리 표준을 위한 두가지 전략이 착수되었다. 단기적으로, 단순 전산망관리 프로토콜(SNMP)은 인터네트 공동체에 있는 노드들을 관리하기 위해 사용하고 장기적으로, OSI 전산망관리 체계로의 전환이 이루어지는 것이다.

전략은 단기적으로 성공했다. 즉, 인터네트를 기반으로 하는 전산망관리 기술은 몇 달 내에 연구소와 기업체들에 의해 실제 상황에서 실험되었다. 이런 결과로, 인터네트 공동체의 일부분들은 적절한 방식으로 전산망관리가 용이해졌다.

IAB는 "권고" 상태를 갖는 완전한 "표준 프로토콜"이 되기 위해 SNMP, SMI 그리고 초기 인터네트 MIB를 지정했다. 이런 행동에 의해, IAB는 모든 IP와 TCP 구현에 전산망 관리가 가능하며 전산망관리가 가능한 구현실상(instance)은 SMI, MIB, 그리고 SNMP를 채택하고 구현하도록 권고하고 있다.

이와같이, TCP/IP를 기반으로 하는 연결망을 위한 현재의 전산망관리 체계는 다음과 같이 구성된다. TCP/IP를 기반으로 하는 인터네트를 위한 관리 정보의 구조와 식별은 MIB에 포함된 관리객체가 RFC 1155[5]에서 제안된 것처럼 정의되는 방법을 기술한다. TCP/IP를 기반으로 하는 인터네트의 전산망 관리를 위한 관리 정보 베이스는 RFC 1156[6]에 제안된 것처럼 MIB에 포함된 관리객체를 기술한다.

그리고, 단순 전산망 관리 프로토콜은 이 표준에 제안된 것처럼 이런 객체들을관리하기 위해 사용되는 프로토콜을 정의한다.

4.2 SNMP 구조

SNMP의 구조적인 모델은 전산망 관리 스테이션들과 전산망 요소들로 이루어진다. 전산망 관리스테이션들은 전산망 요소들을 감시하고 통제하는 관리 응용들을 수행한다. 전산망 요소들은
호스트, 게이트웨이, 단말기 서버등과 같은 장비이며, 이 장비에는 전산망 관리 스테이션들로 부터요청된 전산망 관리 기능들을 수행하는데 책임이 있는 관리 수행자가 있다.

단순 전산망 관리 프로토콜(SNMP)은 전산망 관리 스테이션들과 전산망 요소들에 있는 수행자들사이의 관리 정보를 교환하기 위해 사용된다.

4.2.1 구조의 목적

SNMP는 관리 수행자 자체에 의해 실현되는 관리 기능의 수와 복잡성을 최소화한다. 이런 목적은 적어도 네가지 점에서 호소력이 있다.

(1) 프로토콜을 지원하기 위해 필요한 관리 수행자 소프트웨어의 개발 비용이 그에 맞추어 감소 된다.
(2) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 업무에 있어서 연결망자원의 충분 한 이용을 가능하게 한다.
(3) 원격지에서 지원되는 관리 기능의 정도가 높아지면서 관리 도구들의 형식과 정교함에 대해 가능한한 최소의 제한사항이 부과된다.
(4) 관리 기능의 단순화된 집합은 전산망 관리 도구의 개발자들에 의해 쉽게 이해되고 사용된다.

이 프로토콜의 두번째 목적은 감시와 제어를 위한 기능적인 형태 활용이 전산망 운영과 관리의 추가적이고 예측치 못한 측면을 조절할 정도로 충분히 확장가능하다는 것이다.
세번째 목적은, 그 구조가 특정 호스트 또는 게이트웨이의 구조와 메카니즘과는 가능한 한 독립적이라는 것이다.

4.2.2 구조의 구성 요소

SNMP 구조는 다음 사항에 의해 전산망 관리 문제의 해결책을 명확히 표명한다.

(1) 프로토콜에 의해 교환되는 관리 정보의 영역,
(2) 프로토콜에 의해 교환되는 관리 정보의 표현,
(3) 프로토콜에 의해 지원되는 관리 정보에 관한 동작,
(4) 관리 실체들 사이의 교환의 형식과 의미,
(5) 관리 실체들 사이의 관리적인 관계의 정의,
(6) 관리 정보 참조의 형식과 의미.

4.2.2.1 관리 정보의 영역

SNMP의 운영에 의해 교환되는 관리 정보의 영역은 인터네트 표준 MIB에 정의된, 또는 인터네트표준 SMI[5]에 의해 제안된 규정에 따라 정의된 모든 단순 객체 유형의 실상(instance)에 의해 표현된다.
MIB 내에서 집합 객체 유형에 대한 지원은 SMI를 따를 필요도 없고 SNMP에 의해 구현 되지도 않는다.

4.2.2.2 관리 정보의 표현

SNMP 운영에 의해 교환되는 관리 정보는 SMI에 있는 단일 유형 정의로 명시된 ASN.1 언어 [9]의 부분 집합에 따라 표현된다.

SGMP는 ASN.1 언어[9]의 잘 정의된 부분집합을 사용한 규정을 채택했다. SNMP는 계속해서 이런 방식을 확장하여 관리 객체를 기술하고 그런 객체를 관리하는데 사용되는 프로토콜 데이타 단위(PDU)를 기술하는데 ASN.1의 좀 더 복잡한 부분집합을 사용한다.

더우기, OSI를 기반으로하는 전산망 관리 프로토콜로의 궁극적인 전이를 용이하게 하려는 경향이 인터네트 표준 관리 정보의 구조와 관리 정보 베이스를 ASN.1 언어로 정의하게 하였다. 부분적으로, ASN.1 언어의 사용은 이전의 노력 특히, SGMP에서 ASN.1의 성공적인 사용에 의해 장려되었다.

SMI의 부분인 ASN.1의 사용에 관한 제약사항은 SGMP의 경험에 의해 지지를 받고 타당성을 인정받은 단순성에 공헌했다. 또한 단순성을 위해, SNMP는 ASN.1의 BER[10]의 부분집합만을 사용한다. 다시 말해서, 모든 부호화는 한정된 길이의 형식을 사용한다.

가능하다면, 조립형 부호화보다는 비조립형 부호화가 사용된다. 이런 제한은 그들이 포함하는 자료 객체와 상위 계층 프로토콜 데이타 단위(PDU)를 위해 ASN.1 인코딩의 모든 측면에 적용된다.

4.2.2.3 관리 정보에 지원되는 동작

SNMP는 변수의 변환 또는 조사로써 모든 관리 수행자의 기능을 모델화한다. 논리적으로 원격 지호스트 상의 프로토콜 엔티티(전산망 요소 자체)는 변수들을 바꾸거나 검색하기위해 전산망 요소상에 주둔하는 관리 수행자와 상호작용한다. 이런 방법은 적어도 두가지 긍정적인 결과를 갖는다.

(1) 관리 수행자에 의해 실현되는 필수적인 관리 기능의 수를 둘로 제한하는 결과를 가져온다.
즉, 명시된 구성이나 다른 매개변수에 값을 할당하는 동작이고 다른 하나는 그런 값을 검색하는 동작이다.

(2) 이런 결정의 두번째 결과는 필수적인 관리 명령어를 위해서 프로토콜 정의에 대한 지원이 있어야 한다는 것을 피하게 해준다. 그런 명령어의 수는 실제로 계속 증가하고, 일반적으로 그런 명령어의 의미는 복잡하다.

SNMP에서 암시하고 있는 전략은 세부적으로 중요한 수준에 있는 전산망 상태의 감시는 주로 감시 센타 부분의 해당 정보를 폴링하여 이뤄진다는 것이다. 제한된 수의 비요구 메세지(traps) 는폴링의 시기와 중요성을 지시한다. 요구되지 않은 메세지 수를 제한하는 것은 전산망 관리 기능에 의해 발생된 교통량을 최소화하고 단순성의 목적과 일관된다.

가시적으로 지원되는 관리 기능의 집합에서 지시 명령어의 배제는 바람직한 관리 수행자 운영을 방해하지는 않을 것이다. 현재, 대부분의 명령어는 어떤 매개변수 값을 설정하거나 그런 값을 검색하기 위해 요청된다. 그리고 현재 지원되는 몇가지 지시 명령어의 기능은 이런 관리 모델에 의해 비동기모드로 쉽게 조절된다.

이런 방법에서, 지시 명령어는 원하는 행동을 개시시키는 매개변수 값의 설정으로 구현되어야 한다. 예를 들면, "재시동 명령어"의 구현 보다는 이런 동작이 시스템 재시동될때까지의 초를 나타내는 매개변수를 설정하는 것에 의해 실행되어야 한다.

4.2.2.4 프로토콜 교환의 형태와 의미

관리 실체들 사이의 관리 정보 교환은 프로토콜 메세지의 교환을 통해 SNMP 내에서 실현된다.
그런 메세지의 형태와 의미는 3절에서 정의된다.

관리 수행자의 복잡성을 최소화하는 목적과 일관되도록 하기 위해, SNMP 메세지 교환은 비신 뢰적 데이타그램 서비스만을 요구하고, 모든 메세지는 하나의 수송계층 데이타그램에 의해 완전히독립적으로 표현된다. SNMP 메카니즘은 일반적으로 다양한 수송계층 서비스를 이용하기에 적합하다.

4.2.2.5 행정적 관계의 정의

SNMP 구조는 프로토콜에 참여하는 실체들 사이의 다양한 행정적 관계를 인정한다. SNMP를 이용하여 서로 통신하는 전산망 요소와 관리 스테이션에 주둔하는 실체들은 SNMP 응용 엔티티라 한다. SNMP를 구현하여 SNMP 응용 실체들을 지원하는 동위 프로세스들은 프로토콜 엔티티라 한다.

SNMP 응용 엔티티의 임의의 집합으로 된 SNMP 수행자의 쌍을 SNMP 공동체라 한다. 각 SNMP 공동체는 옥테트 스트링으로 명명되는데, 그것은 공동체 이름으로 불리운다.

공동체 구성요소에 의해 명명되어 실제로 SNMP 공동체에 속하는 SNMP 응용 엔티티에 의해 발생한 SNMP 메세지를 인증된 SNMP 메세지라 한다. SNMP 메세지가 특정 SNMP 공동체를 위한 인증된 SNMP 메세지로 식별되는 법칙들의 집합을 인증 기법이라 한다. 여러 인증 기법에 따라 인증된 SNMP 메세지를 식별하는 기능의 구현은 인증 서비스라 한다.

SNMP 응용 실체들 사이의 행정적 관계의 확실하면서도 효과적인 관리는 고도의 확실성으로 인증된 SNMP 메세지를 식별할 수 있는 인증 서비스(암호화 또는 다른 기술을 이용한)를 요구한다. 몇가지 SNMP 구현은 모든 SNMP 메세지를 믿을만한 SNMP 메세지로 식별하는 단순한 인증 기법만을지원할 수 있다.

전산망 구성요소를 위해, 그 요소에 속한 MIB 내의 객체들의 부분집합을 SNMP MIB 영역이라 한다. SNMP MIB 영역에 표현된 객체 유형의 이름은 객체 유형 이름 공간의 하나의 서브트리에 속할필요는 없다.

집합 { 읽기전용, 읽기쓰기 }의 요소는 SNMP 접근 방식이라 한다.

SNMP MIB 영역을 갖는 SNMP 접근 방식의 쌍은 SNMP 공동체 프로화일이라 한다. SNMP 공동체 프로화일은 명시된 MIB 영역에 있는 변수들에 명시된 접근 권한을 나타낸다. 주어진 SNMP 공동체프로화일에 있는 MIB 영역 내의 모든 변수들에 대해, 변수 접근은 다음 규정에 따르는 프로화일로 나타낸다.

(1) 언급된 변수가 MIB 내에 "접근:"이 "금지"로 정의된다면, 어떤 연산자에 대한 피연산자로이용불가능하다.

(2) 언급된 변수가 MIB 내에 "접근:"이 "읽기쓰기" 또는 "쓰기전용" 그리고 주어진 프로화일의 접근 모드가 "읽기쓰기"라면, 그 변수는 GET, SET, TRAP 동작의 피 연산자로 이용가능하다.

(3) 그밖의 경우, 변수는 GET 그리고 TRAP 동작의 피연산자로 이용가능하다.

(4) "쓰기전용" 변수가 GET 또는 TRAP 동작에 사용되는 피연산자인 경우에, 그 변수 에 주어진 값은 구현시 결정할 수 있다.

SNMP 공동체 프로화일을 갖는 SNMP 공동체의 쌍은 SNMP 접근 정책이라 불린다. 그 공동 체의 다른 구성원들에게 접근 정책이라는 것은 명시된 SNMP 공동체의 SNMP 수행자에 의해 제공되는 명시된 공동체 프로화일을 의미한다. SNMP 응용 실체들 사이의 모든 관리적인 관계 는 구조적으로 SNMP 접근 정책에 의해 정의된다.

모든 SNMP 접근 정책에 대해, 명시된 SNMP 공동체에 대한 SNMP 수행자가 상주하는 전산 망 요소가 명시된 프로화일에 대한 MIB 영역에 속한 곳이 아니라면, 그 정책은 SNMP 대리 접근 정책이라 불리운다. 대리 접근 정책에 연관된 SNMP 수행자는 SNMP 대리 수행자로 불리운다.

대리 접근 정책의 부주의한 정의가 관리 루프를 초래할 수 있는 반면, 대리 정책의 신중한 정의는 적어도 두가지면에서 유용하다.

(1) 관리 프로토콜과 수송계층 프로토콜을 사용하여 주소를 지정할 수 없는 전산망 요소의 제어와 감시를 허락한다. 다시 말해서, 대리 수행자는 상이한 관리 체계를 지원하는 모뎀, 멀티플렉서와 같은 장치를 포함하는 모든 전산망 요소에 일관된 관리 체계를 적용할 수 있도록 하는 프로토콜 변환 기능을 제공할 수 있다.

(2) 잠재적으로 정교한 접근 제어 방식으로 부터 전산망 요소를 보호한다. 예를 들면, 대리 수행자는 MIB 내의 변수들의 다양한 부분집합이 전산망 요소의 복잡도를 증가시키지 않고 다른 관리 스테이션에 접근할 수 있게 한다.

범위 : 구성요소의 관리 범위
PCommunity : 대리 수행자를 이용하는 공동체의 이름
DCommunity : 직접 공동체의 이름

4.2.2.6 관리 객체에 대한 참조의 형식과 의미

SMI는 이를 준수하는 관리 프로토콜의 정의가 다음을 설명한 것을 요구한다.

(1) 모호한 MIB 참조의 해결
(2) 현존하는 MIB 버젼에 있어서 MIB 참조의 해결, 그리고
(3) MIB에 정의된 객체 유형의 특정 실상(instance) 식별

4.2.2.6.1 모호한 MIB 참조의 해결

SNMP 동작 영역은 개념적으로 하나의 네크워크 요소와 관계된 객체로 제한되고, MIB 객체 로의 모든 SNMP 참조는 (암시적 또는 표면적으로) 유일한 변수 이름으로 이루어지므로, MIB에 정의된 어떤 객체 유형에 대한 SNMP 참조가 그 유형의 여러 실상(instance)을 참조할 가능성은 없다.

4.2.2.6.2 MIB 버젼에 따른 참조의 해결

어떤 SNMP 동작에 의해 참조되는 객체 실상(instance)은 전체 MIB 내에서 get-next 동작의 경우에 그의 직접적인 계승자 또는 동작 요청의 부분으로 명시된 것이다. 특히, 인터네트 표준 MIB버젼의 부분으로 객체에 대한 참조는 언급된 인터네트 표준 MIB 버젼의 부분이 아닌 객체를 해결하지 못한다.

다만, 요청된 동작이 get-next이고 명시된 객체 명이 언급된 인터네트 표준 MIB 버젼의 부분으로 나타난 모든 객체들의 이름 중에서 사전순으로 마지막인 경우는 예외이다.

4.2.2.6.3 객체 실상(instance)의 식별

MIB에 있는 모든 객체 유형의 이름은 인터네트 표준 MIB 또는 SMI의 이름 설정 규정에 따르는 다른 문서에 명확히 정의된다. 이를 준수하는 관리 프로토콜이 특정 전산망 요소를 위한 객체 유형 각각의 실상(instance)을 식별하기 위한 메카니즘을 정의하는 것을 SMI는 요구한다.

MIB에 정의된 어떤 객체 유형의 각 실상(instance)은 그것의 "변수 명"으로 불리는 유일한 이름에 의해 SNMP 동작에서 식별된다. 일반적으로, SNMP 변수의 이름은 x.y 형식의 OBJECT IDENTIFIER로, x는 MIB에 정의된 단순 객체 유형의 이름이고 y는 명명된 객체 유형에 정해진 방법으로서, 원하는 실상(instance)을 식별하는 OBJECT IDENTIFIER 부분이다.

이러한 명명 방법은 GetNextRequest-PDU 의미의 충분한 개발을 보장한다(3절 참조). 그 이유는MIB에 알려진 모든 변수 명이 사전편집 순서로 연속하도록 관련된 변수를 위한 이름을 할당하기 때문이다.

객체 실상(instance)의 유형에 정해진 명명은 많은 객체 유형의 등급을 위해 다음과 같이 정의 된다. 다음 명명 원칙 중에 응용할 수 없는 객체 유형의 실상(instance)은 x.0 형식의 OBJECT IDENTIFIER에 의해 명명된다. x는 MIB 정의에 있는 객체 유형으로 불리는 이름이다.

예를 들면, 변수 sysDescr의 실상(instance)을 식별하길 원한다고 가정하자. sysDescr을 위한 객체 등급은 다음과 같다.

iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1

그러므로, 객체 유형 x는 1.3.6.1.2.1.1.1이고 이것에 실상(instance) 서브 식별자로 0 이 추가된다. 다시 말해서, 1.3.6.1.2.1.1.1.0는 sysDescr의 실상(instance) 하나만을 식별한다.

4.2.2.6.3.1 ifTable 객체 유형 이름

서브네트(Subnet) 인터페이스 s의 이름은 i 형식의 OBJECT IDENTIFIER 값이다. 이때 i는 s에 연관된 ifIndex 객체 유형의 실상(instance)의 값을 갖는다. 정의된 이름 n이 ifEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.s형식의 OBJECT IDENTIFIER로 명명되며, 이때 s는 i가 서브네트 인터페이스 정보를 나타내는 이름이다.

예를 들면, 인터페이스 2에 연관된 변수 ifType의 실상(instance)을 식별하길 원한다고 가정해보자. 이 경우 ifType.2는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.2 atTable 객체 유형 이름

AT-cached 전산망 주소의 이름 x는 1.a.b.c.d 형식의 OBJECT IDENTIFIER이다.
이때 a.b.c.d("dot" 표기법)는 x에 연관된 atNetAddress 객체 유형의 값이다.
주소 해석 동치 e의 이름은 s.w 형식의 OBJECT IDENTIFIER로, s는 e에 연관된 atIndex 객체 유형의 실상(instance) 값이고, w는 e에 연관된 AT-cached 전산망 주소의 이름이다.

정의된 이름 n이 atEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 주소 해석 동치 정보를 나타내는 이름이다.
예를 들면, 인터페이스 3과 89.1.1.42 IP 주소에 연관된 주소 해석 테이블(ARP cache)에 있는 엔트리의 물리적 주소를 찾기를 원한다고 가정하자. 이 경우, atPhysAddress. 3.1.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.3 ipAddrTable 객체 유형 이름

IP 주소를 부여할 수 있는 전산망 요소 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다.
이때, a.b.c.d("dot" 표기법)는 x에 연관된 ipAdEntAddr 객체 유형의 실상(instance) 값이다.

정의된 이름 n이 ipAddrEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 주소를 부여할 수 있는 전산망요소의 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42 IP 주소에 연관된 IP 인터페이스 테이블에 있는 엔트리의 네크워크 마스크를 찾기를 원한다고 가정하자. 이 경우, ipAdEntNetMask.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.4 ipRoutingTable 객체 유형 이름

IP 경로 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 ipRouteDest 객체 유형의 실상(instance) 값이다.
정의된 이름 n이 ipRoutingEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 IP 경로 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42의 목적지에 연관된 IP 경로설정 테이블에 있는 엔트리의 다음 홉을 찾기를 원한다고 가정하자. 이 경우, ipRouteNextHop.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.5 tcpConnTable 객체 유형 이름

TCP 연결 x의 이름은 a.b.c.d.e.f.g.h.i.j 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("do t" 표기법)는 x에 연관된 tcpConnLocalAddress 객체 유형의 실상(instance) 값이다. f.g.h.i는 x 에 연관된 tcpConnRemoteAddress 객체 유형의 실상(instance) 값이다. e는 x에 연관된 tcpConnLocalPort 객체 유형의 실상(instance) 값이다. j는 x에 연관된 tcpConnRemotePort 객체 유형의 실상(instance) 값이다.

정의된 이름 n이 tcpConnEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i 는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 TCP 연결 정보를 나타내는 이름이다.

예를 들면, TCP 포트 21 상의 89.1.1.42 지역 주소와 TCP 포트 2059 상의 10.0.0.51 원격 주소 사이의 TCP 연결의 상태를 찾기를 원한다고 가정하자. 이 경우, tcpConnState.89.1.1.42.21.10.0.0.51.2059는 원하는 실상(instance)을 식별한다.

4.2.2.6.3.6 egpNeighTable 객체 유형 이름

EGP 이웃 노드 x의 이름은 a.b.c.d 형식의 OBJECT IDENTIFIER이다. 이때 a.b.c.d("dot" 표기법)는 x에 연관된 egpNeighAddr 객체 유형의 실상(instance) 값이다.
정의된 이름 n이 egpNeighEntry의 접두사를 갖는 각 객체 유형 t에 대해, t의 실상(instance) i는 n.y 형식의 OBJECT IDENTIFIER에 의해 명명된다. y는 i가 EGP 이웃 노드의 정보를 나타내는 이름이다.

예를 들면, 89.1.1.42의 IP 주소의 이웃 노드 상태를 찾기를 원한다고 가정하자.

이 경우,egpNeighState.89.1.1.42는 원하는 실상(instance)을 식별한다.

4.3 프로토콜 명시

전산망관리 프로토콜은 관리대리인 MIB의 변수가 관찰되거나 변경될 수 있는 응용 프로토콜 이다.
프로토콜 실체들 사이의 통신은 메세지의 교환에 의해 이뤄진다. 메세지 각각은 ASN.1의 BER 을 이용하는 하나의 UDP 데이타그램 내에서 완전히 그리고 독립적으로(2.2.2절에서 논의된 것처럼)표현된다.

메세지는 버젼 식별자, SNMP 공동체 이름, 그리고 프로토콜 데이타 단위(PDU)로 구성된다. 프로토콜 엔티티는 트랩을 보고하는 것을 제외하고(즉, Trap-PDU를 포함하는 것을 제외한 모든 메세지) 모든 메세지들에 연관된 그 호스트의 UDP 포트 161에서 메세지를 받는다.

트랩을 보고하는 메세지는 그 이상의 처리를 위해 UDP 포트 162 상에서 받아야한다. 이 프로토콜의 구현은 길이가 484 옥테트 이상인 메세지를 받을 필요는 없다. 그러나, 실행이 가능하다면 좀더 큰 데이타그램을 지원할 수 있도록 구현되는 것을 권고한다.

SNMP의 모든 구현은 다섯가지의 PDU 즉, GetRequest-PDU, GetNextRequest-P여, GetResponse-PDU, SetRequest-PDU, Trap-PDU 를 지원하는 것이 필수 사항이다.

RFC1157-SNMP 정의 ::= 시작

IMPORTS RFC1155-SMI로부터 ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks 를 가져온다.

-- 상위-레벨 메세지

Message ::=
SEQUENCE {
version
INTEGER {
version-1(0)
},
community -- 공동체 이름
OCTET STRING,
data -- 예를 들면, 단순한 인증이
ANY -- 사용될 경우 PDU

-- 프로토콜 데이타 단위

PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}

-- 데이타 유형에 사용되는 각각의 PDU와 공통적인 PDU는 후에 정의될 것이다.

4.3.1 절차 요소

이 절은 SNMP를 구현하는 프로토콜 엔티티의 행동을 기술한다. 그러나, 이에 준하는 구현의 내부 구조를 제약하지는 않는다.
다음의 원문에서, 수송계층 주소가 사용된다. UDP의 경우에, 수송계층 주소는 UDP 포트와 함께 IP 주소로 구성된다. 다른 수송계층 서비스는 SNMP를 지원하기 위해 사용될 수 있다. 이런 경우에, 수송계층 주소의 정의가 그것에 준하여 구성되어야 한다.
메세지를 만들어 내는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) 먼저, ASN.1 객체로 해당 PDU(즉, GetRequest-PDU)를 구성한다.

(2) 다음에, 그의 근원지 주소와 목적지 주소인 공동체 이름과 함께 이 ASN.1 객체 를 원하는 인증 기법을 구현하는 서비스에게 넘겨준다. 이 인증 서비스는 또 다른 ASN.1 객체를 반환한다.

(3) 그 다음에, 프로토콜 엔티티는 공동체 이름과 생성된 ASN.1 객체를 이용하여 ASN.1 메세지 객체를 구성한다.

(4) 이런 새로운 ASN.1 객체는 ASN.1의 BER을 이용하여 연속적으로 나열되어서, 수송계층 서비스를 이용하여 상대방 프로토콜 엔티티로 보내진다.

유사하게, 메세지를 받는 프로토콜 엔티티의 상위-레벨 행동은 다음과 같다.

(1) ASN.1 메세지 객체에 대응하는 ASN.1 객체를 만들기 위해 유입되는 데이타그램의 기본적인 분석을 수행한다. 분석이 실패한다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(2) 그 다음, SNMP 메세지의 버젼 번호를 확인한다. 불일치가 있다면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다.

(3) 그 다음으로, 프로토콜 엔티티가 동일한 인증 기법을 사용하는 서비스에게 사용자 데이타와 공동체 이름을 넘겨주는데 이는 데이타그램의 근원지와 목적지 수송계층 주소를 포함하고 있는 ASN.1 메세지 객체에 존재하고 있다.

이 엔티티는 다른 ASN.1 객체를 반환하거나, 인증 실패를 알린다. 후자의 경우에, 프로토콜 엔티티는 트랩을 발생하여 이런 실패를 알리고, 데이타그램을 버린다. 그리고 그 이상의 행동을 수행하지 않는다.

(4) 그리고, 프로토콜 엔티티는 ASN.1 PDU 객체에 대응하는 ASN.1 객체를 만들기 위해 인증 서비스로 부터 반환된 ASN.1 객체에 관한 기본적인 분석을 행한다.

분석이 실패하면, 데이타그램을 버리고 그 이상의 행동을 수행하지 않는다. 그렇지 않으면, 명명된 SNMP 공동체를 이용하여, 해당 프로화일이 선택되고, PDU가 그것에 따라서 처리된다. 이 처리의 결과로, 메세지가 반환된다면, 응답 메세지의 근원지 수송게층 주소가 원래 요청 메세지가 보내진 목적지 수송계층 주소와 동일해야 한다.

4.3.1.1 공통 구문

프로토콜의 여섯가지 PDU 유형을 소개하기 전에, 자주 사용되는 ASN.1 구문들을 살펴보는 것이 좋다.

-- 요청/응답 정보

RequestID ::=
INTEGER

ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}

ErrorIndex ::=
INTEGER

-- 변수 결합

VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}

VarBindList ::=
SEQUENCE OF
VarBind

RequestID는 응답을 받지않은 요청들을 구분하기 위해 사용된다. RequestID를 이용하여, SNMP 응용 엔티티는 요청들과 유입되는 응답을 서로 연관시킬 수 있다. 신뢰할 수 없는 데이타 그램 서비스가 사용되고 있는 경우에, RequestID는 또한 전산망에 의해 중복되는 메세지를 식별하는 간단한 수단을 제공한다.

ErrorStatus의 0이 아닌 실상(instance)은 요청이 처리되는 동안 발생된 예외 상황을 알리기 위해 사용된다. 이런 경우에, ErrorIndex는 예외 상황이 발생된 목록에 있는 변수를 알리므로써 추가 정보를 제공할 수 있다.

변수는 관리 객체의 실상(instance)을 언급한다. 변수 결합 VarBind는 변수와 해당변수 값의 쌍을 언급한다. VarBindList는 변수 명과 대응하는 값의 단순한 목록이다.

몇몇 PDU는 값이 아닌 변수 명에만 관계된다( 예를 들면, GetRequest-PDU ). 이런 경우에, 결합의 값 부분은 프로토콜 엔티티에 의해 무시된다. 그러나, 값 부분은 올바른 ASN.1 구문과 인코딩을 준수해야 한다.
ASN.1 값 NULL이 그런 결합의 값 부분을 위해 사용되도록 권고된다.

4.3.1.2 GetRequest-PDU

GetRequest-PDU의 형식은 다음과 같다.

GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

GetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다. GetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에 따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름과 정확히 맞지 않는다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체가 복합적인 유형 (SMI에 정의된것처럼)이라면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되었다는 것을 제외하고는, 동일한 형식의
GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 명명된 각 객체에 대해,GetResponse-PDU의 대응하는 요소는 그 변수의 이름과 값이 나타낸다.

GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다.
GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

4.3.1.3 GetNextRequest-PDU

GetNextRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과
동일하다. ASN.1 언어로 다음과 같다.

GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

GetNextRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만
들어진다.
GetNextRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법
칙에 따라 응답한다.

(1) variable-bindings 필드에 있는 임의의 객체 이름에 대해, 그 이름이 관련 MIB 영역에 있는 get 동작에 이용가능한 객체의 이름에 사전 순으로 선행하지 않으면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) 아래와 같이 기술됨으로써 만들어진 GetResponse-PDU의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU 를 수신 메세지의 송신자에게 보낸다.

(3) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체에 대한 사전 순으로 다음의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 검색될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr 이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 프로토콜 엔티티는 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다. 이때, 수신 메세지의 variable-binding 필드에서 각 이름에 대해, GetResponse-PDU의 대응하는 요소는 그 객체의 이름과 값을 나타낸다.

그 객체의 이름은 그 값에 대한 바로 다음 요소의 이름 필드 값과 더불어, 관련 MIB 영역에서는 get 동작에 이용가능한 모든 객체들의 이름이 사전 순으로 존재한다. GetResponse-PDU의 error-status 필드의 값이 noError이고 error-index 필드의 값이 0이다. GetResponse-PDU의 request-id 필드의 값은 수신 메세지의 것이다.

4.3.1.3.1 테이블 조회의 예

GetNextRequest-PDU의 한가지 중요한 이용은 MIB 내에 있는 개념적인 정보 테이블의 조회이다.
MIB에 있는 객체 유형 각각의 실상(instance)을 구별하기 위한 프로토콜에 특이한 메카니즘과 더불어 이런 유형의 SNMP 메세지의 의미는 마치 그것들이 테이블 구성을 하고 있는 것처럼 MIB에 있는 관련 객체에 대한 접근을 제공한다.

아래에 기술된 SNMP 교환에 의해, SNMP 응용 엔티티는 특정 전산망 요소의 경로선택 테이블에 있는 각 엔트리에 대한 목적지 주소와 다음 홉 게이트웨이를 추출한다. 이 경로선택 테이블이 세가지 엔트리를 갖는다고 가정하자.

목적지 다음 홉 메트릭

10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.2.0.0.51 89.1.1.42 5

관리 스테이션은 요청된 변수 이름으로 지시된 OBJECT IDENTIFIER 값을 포함 하는 GetNextRequest-PDU를 SNMP 수행자에게 보낸다.

GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

SNMP 수행자는 GetResponse-PDU로 응답한다.

GetResponse ((ipRouteDest.9.1.2.3 = "9.1.2.3"),
(ipRouteNextHop9.1.2.3 = "99.0.0.3"),
(ipRouteMetric1.9.1.2.3 = 3 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.9.1.2.3,
ipRouteNextHop9.1.2.3,
ipRouteMetric1.9.1.2.3)

SNMP 수행자는 다음과 같이 응답한다.

GetResponse ((ipRouteDest.10.0.0.51 = "10.0.0.51"),
(ipRouteNextHop10.0.0.51 = "89.1.1.42"),
(ipRouteMetric1.10.0.0.51 = 5 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51)

SNMP 수행자는 다음과 같이 응답한다.

GetResponse ((ipRouteDest.10.0.0.99 = "10.0.0.99"),
(ipRouteNextHop10.0.0.99 = "89.1.1.42"),
(ipRouteMetric1.10.0.0.99 = 5 ))

관리 스테이션은 다음과 같이 계속한다.

GetNextRequest ((ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99)

테이블에 그 이상의 엔트리가 없을 때, SNMP 수행자는 알려진 객체 이름의 사전순으로있는 다음의 객체들을 반환한다. 이 응답은 관리 스테이션에 경로선택 테이블의 끝임을 알린다.

4.3.1.4 GetResponse-PDU

GetResponse-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다.
ASN.1 언어로 다음과 같다.

GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status
ErrorStatus,

error-index
ErrorIndex,

variable-bindings
VarBindList
}

GetResponse-PDU는 이 표준의 다른 곳에서 기술된 것처럼 GetRequest-PDU, GetNextRequest-PDU, 또는 SetRequest-PDU를 받자마자 프로토콜 엔티티에 의해 만들어진다.
GetResponse-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다.

4.3.1.5 SetRequest-PDU

SetRequest-PDU의 형식은 PDU 유형의 지시값을 제외하고 GetRequest-PDU의 형식과 동일하다.
ASN.1 언어로 다음과 같다.

SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,

error-status -- 항상 0
ErrorStatus,

error-index -- 항상 0
ErrorIndex,

variable-bindings
VarBindList
}

SetRequest-PDU는 해당 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 만들어진다.
SetRequest-PDU를 받자마자, 수신 프로토콜 엔티티는 아래의 목록에 있는 적용가능한 법칙에따라 응답한다.

(1) variable-bindings 필드에서 명명된 임의의 객체에 대해, 그 객체가 관련 MIB 영역에 있는 set 동작에 이용가능하지 않다면, 수신 엔티티는 error-status 필드의 값이 noSuchName이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(2) variable-bindings 필드에서 명명된 임의의 객체에 대해, 값 필드의 내용이 ASN.1 언어에 따라 변수에 필요로 되는 것과 일치된 유형, 길이, 그리고 값을 명시하지 않는다면, 수신 엔티티는 error-status 필드의 값이 badValue이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당하는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(3) 아래와 같이 기술되므로써 만들어진 Get Response 유형 메세지의 크기가 국부적인 제한을 초과한다면, 수신 엔티티는 error-status 필드의 값이 tooBig이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

(4) variable-bindings 필드에서 명명된 임의의 객체에 대해, 명명된 객체의 값이 선행하는 법칙의 어떤 것에 의해 적용되지 않는 이유들로 인해 변경될 수 없다면, 수신 엔티티는 error-status 필드의 값이 genErr이고 error-index 필드의 값이 수신 메세지에 있는 언급된 객체 이름 요소의 색인으로 할당되는 것을 제외하고는, 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

선행하는 법칙들중 적용되는 것이 없다면, 수신 메세지의 variable-bindings 필드에 있는 명명된 각 객체에 대해, 대응하는 값이 변수에 할당된다. SetRequest-PDU에 의해 명시된 각 변수 할당은 마치 동일 메세지에 명시된 모든 다른 할당에 관해 동시에 설정하는 것처럼 되어야 한다.

수신 엔티티는 생성된 메세지의 error-status 필드 값이 noError이고 error-index 필드의 값이 0으로 할당되는 것을 제외하고 동일한 형식의 GetResponse-PDU를 수신 메세지의 송신자에게 보낸다.

4.3.1.6 Trap-PDU

Trap-PDU의 형식은 다음과 같다.

Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- 트랩을 발생시키는 객체 유형

OBJECT IDENTIFIER, --[5]의 sysObjectID를 참조

agent-addr -- 트랩을 발생시키는 객체 주소
NetworkAddress,

generic-trap -- 일반 트랩 유형
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUP(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},

specific-trap -- 일반-트랩이 enterpriseSpecific이 INTEGER, -- 아니더라도 specific-code는 존재

time-stamp -- 전산망 엔티티의 마지막 초기화와
TimeTicks, -- 트랩 생성 사이의 경과된 시간

variable-bindings -- "관심있는" 정보
VarBindList
}

Trap-PDU는 SNMP 응용 엔티티의 요청시에만 프로토콜 엔티티에 의해 생성된다. SNMP 응용 엔티티가 SNMP 응용 엔티티의 목적지 주소를 선택하는 수단은 구현하기 나름이다.
Trap-PDU를 받자마자, 수신 프로토콜 엔티티는 그 내용을 SNMP 응용 엔티티에게 전달한다
Trap-PDU의 variable-bindings 요소의 의미는 구현하기 나름이다.

4.3.1.6.1 coldStart 트랩

coldStart(0) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이
변경될 수 있기 위해 스스로 재초기화하고 있는 것을 알린다.

4.3.1.6.2 warmStart 트랩

warmStart(1) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조 또는 프로토콜 엔티티 구현이 변경되지 않고 스스로 재초기화하고 있는 것을 알린다.

4.3.1.6.3 linkDown 트랩

linkDown(2) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 고장임을 인식하고 알리는 것이다. linkDown 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.4 linkUp 트랩

linkUp(3) 트랩은 송신 프로토콜 엔티티가 그 수행자의 구조에 나타나는 통신 연결의 하나가 발생하였음을 인식하고 알리는 것이다. linkUp 형태의 Trap-PDU는 variable-bindings의 첫 번째 구성요소로서 영향을 받은 인터페이스에 대한 ifIndex 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.5 authenticationFailure 트랩

authenticationFailure(4) 트랩은 송신 프로토콜 엔티티가 부당하게 인증된 프로토콜 메세지의 주소임을 알린다. SNMP 구현이 이 트랩을 생성할 수 있어야만 하는 반면, 구현에 의존적인 메카니즘을 통한 트랩의 발생을 저지할 수 있어야만 한다.

4.3.1.6.6 egpNeighborLoss 트랩

egpNeighborLoss(5) 트랩은 송신 프로토콜 엔티티가 동위 EGP였던 EGP 이웃 노드가 고장난 것으로 나타나고 더 이상 동위 관계를 얻을 수 없는 것을 알린다.

egpNeighborLoss 형태의 Trap-PDU는 variable-bindings의 첫번째 구성요소로서 영향을 받는 이웃 노드에 대한 egpNeighAddr 실상(instance)의 이름과 값을 포함한다.

4.3.1.6.7 enterpriseSpecific 트랩

enterpriseSpecific(6) 트랩은 송신 프로토콜 엔티티가 어떤 회사에 특정한 사건이 발생했음을 인식하고 알린다. 이 특정 트랩 필드는 발생한 특정 트랩을 식별한다.

4.4 정의

RFC1157-SNMP DEFINITIONS ::= BEGIN

IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;

-- top-level message

Message ::=
SEQUENCE {
version -- 이 RFC의 버젼-1
INTEGER {
version-1(0)
},
community
OCTET STRING, -- 공동체명

data -- 일상적인 인증이 사용된
ANY -- PDUs
}

-- 프로토콜 데이타 단위

PDUs ::=
CHOICE {
get-request
GetRequest-PDU,

get-next-request
GetNextRequest-PDU,

get-response
GetResponse-PDU,

set-request
SetRequest-PDU,

trap
Trap-PDU
}

-- PDUs

GetRequest-PDU ::=
[0]
IMPLICIT PDU

GetNextRequest-PDU ::=
[1]
IMPLICIT PDU

GetResponse-PDU ::=
[2]
IMPLICIT PDU

SGetRequest-PDU ::=
[3]

IMPLICIT PDU

PDU ::=
SEQUENCE {
request-id
INTEGER,

error-status -- 때로는 무시된다.
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},

error-index -- 때로는 무시된다.
INTEGER,

variable-bindings -- 값은 때로 무시된다.
VarBindList
}

Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- 트랩을 생성하는 객체 유형
OBJECT IDENTIFIER, -- [5]의 sysObjectID 참조

agent-addr -- 트랩을 생성하는 객체 주소
NetworkAddress,

generic-trap --일반 트랩 유형
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},

specific-trap
INTEGER,

time-stamp
TimeTicks,

variable-bindings
VarBindList
}

-- variable bindings

VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END

4.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institure, November 1980.

제 5 장 TCP/IP 기반 연결망(internets)을 위한 관리 정보의 구조(SMI)

5.1 개요

관리정보구조 표준은 TCP/IP를 기반으로 하는 연결망(internets)을 관리하는데 사용되는 관리정보의 정의를 위한 공통 구조와 식별 기법을 기술한다. 관리 정보를 기술하기 위한 포괄적 유형의 집합과 전산망 관리를 위한 객체 정보 모델의 기술이 포함된다. 구조의 공식적 기술은 추상 구문 표기법 1(Abstract Syntax Notation One : ASN.1)[1]을 사용한다.

이 표준은 조직적인 관계와 행정적 정책에 주로 관여한다. 즉, 관리되는 객체 및 객체를 관리하기 위해 사용하는 프로토콜은 이 표준에서 다루지 않는다. 이런 것들은 두개의 관련 표준에 의해 설명된다.

하나는 관리 정보 베이스(MIB)를 기술한 표준[2]이며, 다른 하나는 단순 전산망 관리 프로토콜(SNMP)을 기술한 표준[3]이다.
관리정보구조 표준의 목적은 단순성과 확장성을 달성하는 것이다. 이 두 목적은 공통 문제에 의해 동기부여 되었다. 즉, 간단한 SMI를 제안하므로써 앞으로의 잠재적 기법에 부과되는 제약을 최소화한다. 더우기, 확장가능한 SMI를 작성하므로써 가능한한 많은 수의 잠재적 기법이 실험에 이용될 수 있다.

본 관리정보구조 표준과 관련된 문서는 "인터네트(Internet) 전산망 관리 표준의 개발을 위한 IAB 권고안", RFC 1052 [5]와 "전산망 관리 특수(Ad Hoc) 검토 그룹의 두번째 보고", RFC 1109 [6]에서 발표된 지침서 등이 있다. 특히, 우리는 관리 정보 베이스를 기술하는 표준과 더불어 이 표준은 인터네트(Internet)의 전산망 관리를 위한 확고한 기초를 제공한다고 생각한다.

5.2 관리 정보의 구조와 식별

관리 객체(Managed Objects)들은 관리 정보 베이스 또는 MIB로 불리는 가상 정보 저장소를 통해 접근된다. MIB에 있는 객체들은 추상 구문 표기법 1 (ASN.1)을 사용해서 정의된다[1].
각 객체의 유형(객체 유형이라 불리우는)은 이름, 구문, 부호를 갖는다. 이름은 OBJECT DENTIFIER로유일하게 표현된다. OBJECT IDENTIFIER는 행정적으로 할당되는 이름이다. 이름을 할당하는데 사용되는관리 방법은 이 표준의 끝부분에서 논의된다.

객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. 예를 들면, 주어진 객 체 유형의 구조는 INTEGER 또는 OCTET STRING일 수 있다. 일반적으로, 객체 유형의 구문을 정의하는데 사용되는 모든 이용가능한 ASN.1 구성요소를 허락할 수 있으나, 이 표준에서는 사용될 수 있는 ASN.1 구성을 의도적으로 제한하고 있다. 이런 제한은 단지 단순성을 지원하기 위한 것이다.

객체 유형의 부호화(encoding)는 단순히 객체 유형 실상(instance)들이 객체 유형 구문을 사용 하여 어떻게 표현되는 가를 의미한다. 객체의 구문과 부호화 개념은 객체가 전산망에서 전송될 때 표현되는 방법을 암시한다. 이 표준은 ASN.1의 BER(Basic Encoding Rules)을 이용하여 명시한다[7].

5.2.1 이름

이름은 관리 객체를 식별하기 위해 사용된다. 이 표준은 이름을 명명할때 계층적인 구조를 명시하고 있다. OBJECT IDENTIFIER 개념은 계층적인 이름을 구현하기 위해 사용된다.

OBJECT IDENTIFIER는 관리 객체 유형을 명명하는 것 이외에 사용될 수도 있다. 예를 들면, 여러 국제 표준안들의 식별을 위해 OBJECT IDENTIFIER를 할당받을 수 있다. 단순히 OBJECT IDENTIFIER는 객체에 연관된 의미(예, 전산망 객체, 표준 문서 등)와는 무관하게 객체를 식별하는 수단이다.

OBJECT IDENTIFIER는 전체 트리를 조회하는 정수들의 나열이다. 이 트리는 에지(edge)를 통해서 여러개의 레이블된 노드와 연결된 루트노드로 구성되었다. 각 노드는 차례로 레이블되는 자신들의 후손노드들을 갖는다. 이 경우에, 그 노드를 서브트리라 한다. 이 과정은 임의의 깊이 수준까지 계속될 수 있다. OBJECT IDENTIFIER 개념의 핵심은 노드들에 할당되는 의미의 관리적 제어가 트리를 조회할 때 위임될 수 있다는 것이다. 레이블은 간단한 문자열과 정수의 쌍이다.

루트 노드 자체는 레이블되지 않지만 바로 세개의 후손노드들을 갖는다: 한 노드는 레이블 iso(1)로서 국제표준화기구에 의해 관리된다. 두번째 노드는 레이블 ccitt(0)로서 국제전신전화자 문위원회에 의해 관리된다. 세번째 노드는 joint-iso-ccitt(2)로서 ISO와 CCITT에 의해 연합 관리된다.

iso(1) 노드 하에 있는 ISO는 다른 국제조직에 의해 사용되는 하나의 서브트리, org(3)를 사용한다. 현재 후손 노드들 중 두개의 노드는 U.S. NIST에 의해 할당된다. 이 서브트리 중 하나 인 dod(6)는 NIST에 의해 미 국방성에게 양도되었다.

현재 이 표준에서, DoD(Department of Defense)는 그의 서브트리를 관리하는 방법을 지시하지는 않는다. 이 표준은 DoD가 다음과 같이 IAB에 의해 관리되기 위해 인터네트 공동체에게 한 노드를 할당할 것으로 가정한다.

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

다시 말해서, OBJECT IDENTIFIER인 인터네트 서브트리는 다음 접두사로 시작한다:

1.3.6.1.

IAB에 의해 승인된 표준안으로, 이 표준은 OBJECT IDENTIFIER 서브트리가 관리되는 방법을 명시한다.
시작 부분에 네개의 노드가 존재한다.

이는 다음과 같다.

directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }

5.2.1.1 디렉토리(Directory)

서브트리 directory(1)은 OSI 디렉토리가 인터네트에서 어떻게 사용될 수 있는 가를 논의할 표준에 사용된다.

5.2.1.2 Mgmt

서브트리 mgmt(2)는 IAB에서 승인한 문서에 정의된 객체들을 식별하기 위해 사용된다.
서브트리 mgmt(2)의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에 위임된다. 인터네트 표준 관리 정보 베이스의 새 버젼을 정의하는 RFC들이 승인될 때, 그 문서에 의해 정의된 객체들을 식별하기 위해 IANA가 OBJECT IDENTIFIER를 할당한다.

예를 들면, 초기 인터네트 표준 MIB를 정의하는 RFC는 관리 문서 번호 1이 할당된다. 이 RFC는 인터네트 표준 MIB를 정의하는 OBJECT IDENTIFIER로 { mgmt 1 } 또는 1.3.6.1.2.1 을 사용한다.

인터네트 표준 MIB의 새 버젼은 정밀한 과정을 거쳐 출현한다. 이 표준의 5절은 새 버젼이 정의될 때 사용되는 법칙들을 기술한다.

5.2.1.3 Experimental

서브트리 experimental(3)은 인터네트 실험에 사용되는 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해서 인터네트의 IANA에게 위임된다.
예를 들면, 실험자는 번호 17을 받고, 이용가능한 OBJECT IDENTIFIER로 { experimental 17 } 또는 1.3.6.1.3.17
을 갖는다.

할당 과정의 부분으로, IANA는 서브트리가 어떻게 사용되는가에 관한 요구조건을 만들 수 있다.

5.2.1.4 Private

서브트리 private(4)는 단독으로 정의된 객체들을 식별하는데 사용된다. 이 서브트리의 관리는 IAB에 의해 IANA(Internet Assigned Numbers Authority)에게 위임된다. 처음에, 이 서브트리는 다음과 같이 적어도 하나의 후손을 갖는다.

enterprises OBJECT IDENTIFIER ::= { private 1 }

서브트리 enterprises(1)은 전산망 서브시스템을 제공하는 회사들이 그들의 상품 모델을 등록하도록 허락하기 위해 사용된다.
예를 들면, 기업은 서브트리를 받자마자 이 서브트리에 새로운 MIB 객체들을 정의할 수 있다.

게다가, 관리 프로토콜에 사용될 확실한 식별 메카니즘을 제공하기 위해 기업이 이 서브트리에 그의 네트워킹 서브시스템들을 등록하도록 권고된다. 예를 들면, "Flintstones, Inc." 기업이 전산망 서브시스템을 생산하였다면, 그들은 IANA로 부터의 enterprises 서브트리 하에 노드를 요구할 수 있다. 그런 노드는 다음과 같이 번호가 붙는다.

1.3.6.1.4.1.42

"Flintstones, Inc." 기업은 그들의 "Fred Router"를 다음과 같이 등록할 수 있다.

1.3.6.1.4.1.42.1.1

5.2.2 구문

구문은 객체 유형에 대응하는 구조를 정의하는데 사용된다. ASN.1 조립형은 ASN.1의 완전한 일반성이 허락되지 않을 지라도 이 구조를 정의하기 위해 사용된다.
ASN.1 유형 ObjectSyntax는 객체 유형을 정의하는데 사용될 수 있는 다른 구문들을 정의한다.

5.2.2.1 프리미티브 유형

ASN.1 프리미티브 유형으로 INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL이 가능하다. 이것들은 단일 유형으로 일컫는다.

5.2.2.1.1 열거형 INTEGER에 대한 지침

열거형 INTEGER가 객체 유형으로 나열된다면, 0의 값이 열거 리스트에 존재해서는 안된다.
이 값의 사용은 금지되어 있다.

5.2.2.2 조립형 유형

ASN.1 조립형 유형인 SEQUENCE가 테이블이나 리스트를 만들기 위해 사용 가능하다.
리스트의 구문은 다음과 같은 형태를 취한다:

SEQUENCE { , ..., }

각 은 위에서 나열된 ASN.1 프리미티브 유형 중 하나가 된다. 더우기, 이 ASN.1 유형들은 항상 존재한다 (DEFAULT와 OPTIONAL 절은 SEQUENCE 정의에 나타나지 않는다).
테이블의 구문은 다음과 같은 형태를 취한다.

SEQUENCE OF 는 리스트 조립형이 된다.
리스트들과 테이블들은 집합 유형으로 일컫는다.

5.2.2.3 정의된 유형

추가적으로, 응용 분야의 유형이 정의될 수 있다. 그것들은 잠재적으로 정의된 ASN.1 프리미 티브 유형, 리스트, 테이블, 또는 다른 응용 분야에 사용할 수 있는 유형으로 설명된다.

처음에 는, 거의 응용 분야에 사용할 수 있는 유형이 정의되지 않는다. 앞으로의 문서에서는 일단 합의만 되면 다른 것들을 정의할 것이다.

5.2.2.3.1 NetworkAddress

CHOICE는 여러 프로토콜 부류 중 하나인 주소를 표현한다. 현재, 유일한 프로토콜 부류인 인터네트 부류만이 CHOICE에 존재한다.

5.2.2.3.2 IpAddress

이 응용분야의 유형은 32-비트 연결망 주소를 표현한다. 그것은 길이가 4인 OCTET STRING 으로 전산망 바이트 순(network byte-order)으로 표현된다.
이 ASN.1 유형이 ASN.1 BER을 사용하여 부호화될 때, 프리미티브 부호 형태만이 사용되어야 한다.

5.2.2.3.3 Counter

이 응용 분야의 유형은 최대값이 될 때까지 단조롭게 증가하는 음이 아닌 정수를 표현한다.
최대값에 이르면 영(0)부터 다시 증가하기 시작한다. 이 문서는 Counter의 최대치로 2^32-1
(4294967295 십진수)을 명시하고 있다.

5.2.2.3.4 Gauge

이 응용 분야의 유형은 증가하거나 감소할 수 있는 음이 아닌 정수를 표현한다. 그러나 최대 치에서 정지된다. 이 문서는 Gauge의 최대치로 2^32-1 (4294967295 십진수)을 명시하고 있다.

5.2.2.3.5 TimeTicks

이 응용 분야의 유형은 어떤 시기이래로 백분의 1초 단위로 시간을 세는 음이 아닌 정수를 나타낸다.

객체 유형이 이 ASN.1 유형을 사용해서 MIB에 정의될 때 객체 유형은 참조 시기를 식별한다.

5.2.2.3.6 Opaque

이 응용 분야의 유형은 임의의 ASN.1 구문을 통과하기 위한 능력을 지원한다. 값은 ASN.1 BER을 사용하여 옥테트들의 나열로 부호화된다. 차례로, 이것은 OCTET STRING으로 부호화 된다.

실제로, 원래 ASN.1 값을 이중으로 감싸는 것과 같다. 구현시 지킬 것은 단지 불투명하게 부호화된 자료를 받아서 인식하면 된다. 그것은 자료를 복호화할 필요는 없고 내용을 해석하면 된다.

더우기, ASN.1 이외의 부호화는 ASN.1 EXTERNAL 유형을 이용하여, 불투명하게 부호화된 자료에 사용될 수 있다.

5.2.3 부호화

일단 객체 유형의 실상(instance)가 식별되면, 그것의 값은 객체 유형을 위한 구문에 ASN.1 BER을 적용하여 전송될 수 있다.

5.3 관리 객체

MIB 내의 객체들을 정의하는 것이 본 표준의 목적이 아니라, 이 표준은 이런 객체들을 정의하는 다른 표준들에 의해 사용되는 형식을 명시한다.
객체 유형 정의는 다섯개의 필드로 구성된다.

객체(OBJECT):
객체 기술자(OBJECT DESCRIPTOR)라 불리는 객체 유형의 문자열과 이에 대응하는 OBJECT IDENTIFIER

구문(SYNTAX):
객체 유형의 추상 구문.
이것은 ASN.1 유형 ObjectSyntax의 실상(instance)가 되어야 한다.

정의(Definition):
객체 유형의 의미를 나타내는 설명을 기술.

이 MIB는 많은 기업체의 제품이 운영되는 환경에서 사용되므로 구현은 객체의 실상(instance)이 이 정의를 이행하는 것을 보장해야 한다. 그와 같이 객체들 이 모든 장비에서 일관된 의미를 갖는 것은 중요하다.

접근(Access):
읽기전용, 읽기쓰기, 쓰기전용, 또는 접근금지 중 하나

상태(Status):
필수사항, 선택사항, 폐지사항 중 하나

앞으로의 표준은 그들이 정의한 객체들의 다른 필드를 역시 명시할 수 있다.

5.3.1 객체 이름에 대한 지침

인터네트 표준 MIB의 객체 유형은 이름 내에 부식별자 0을 사용해서는 안된다. 이 값은 앞으로의 확장을 위해 예약된다.
인터네트 표준 MIB에 있는 객체 유형에 대응하는 각 객체 기술자는 유일하면서 기억하기 쉬운 인쇄 가능한 스트링이어야 한다. 이것은 사람들이 MIB를 논의할 때 사용하기 위한 공통 언어를 장려하고 사용자 인터페이스를 위해 간단한 테이블 매핑을 돕는다.

5.3.2 객체 유형과 실상(instance)

객체 유형은 관리 객체 정의이다. 실제로 그것은 선언이다. 이와 대조적으로, 객체 실상 (instance)은 객체 유형이 값을 갖게되는 것 즉, 객체 유형의 실상(instance)이다. 예를 들면, 경로설정 테이블에 존재하는 엔트리 개념은 MIB에 정의되어야 한다. 그런 개념은 객체 유형에 해당한다

그러나,어느순간에 존재하는 특정 경로설정 테이블의 각각의 엔트리들은

그객체유형의객체실상(instance)이다.
객체 유형의 집합은 MIB에 정의된다. 각각의 객체 유형은 객체 식별자로 유일하게 명명되고, 그것의 객체 기술자인 이름을 갖는다. 객체 실상(instance)들이 참조되는 수단은 MIB에 정의되지 않는다. 객체실상(instance)들에 대한 참조는 프로토콜 특정 메카니즘에 의한다.

즉, 그것은 이 메카니즘을 정의하는 SMI를 준수하는 각 관리 프로토콜의 책임이다.
객체 유형의 실상(instance)이 "하위" 객체 유형의 실상(instance)에 의해 표현되는 정보의 집합을 나타내는 MIB에 객체 유형이 정의될 수 있다.

예를 들면, 다음의 객체 유형들이 MIB에 정의된다고 가정해보자:

객체:
atIndex { atEntry 1 }

구문:
INTEGER

정의:
실제 주소에 관한 인터페이스 번호

접근:
읽기쓰기

상태:
필수사항

객체:
atPhysAddress { atEntry 2 }

구문:
OCTET STRING

정의:
매체 의존적인 실제 주소

접근:
읽기쓰기

상태:
필수사항

객체:
atNetAddress { atEntry 3 }

구문:
NetworkAddress

정의:
매체 의존적인 실제 주소에 대응하는 전산망 주소

접근:
읽기쓰기

상태:
필수사항

그러면, 네번째 객체 유형은 또한 MIB에 정의된다.

객체:
atEntry { atTable 1 }

구문:
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}

정의:
주소 번역 테이블의 엔트리

접근:
읽기쓰기

상태:
필수사항

이 객체 유형의 각 실상(instance)은 이전의 세 객체 유형의 실상(instance)에 의해 표현되는 정보를 포함한다. 이런 방식으로 정의된 객체 유형을 리스트라 한다.
유사하게, 테이블은 리스트 유형의 집합에 의해 형성될 수 있다. 예를 들면, 다섯번째 객체 유형은 MIB에 정의된다.

객체:
atTable { at 1 }

구문:
SEQUENCE OF AtEntry

정의:
주소 번역 테이블

접근:
읽기쓰기

상태:
필수사항

atTable 객체의 각 실상(instance)은 주어진 atTable 객체 실상(instance) 즉, 주어진 주소 번역 테이블을 구성하는 atEntry 객체 유형의 집합에 의해 표현되는 정보를 포함한다.
테이블 내의 간단한 객체를 어떻게 참조하는지 고려해보자. 이전의 예제에서, 연속해서 객체 유형

{ atPhysAddress } 를 명명하고 프로토콜 특정 메카니즘을 이용하여 객체 실상(instance)

{ atNetAddress } = { internet "10.0.0.52" }
을 명시한다.

이 객체 유형과 객체 실상(instance)의 쌍은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 주소 번역 테이블에 있는 엔트리 부분인 atPhysAddress의 모든 실상(instance)을 참조한다.

이 예제에 계속해서, 테이블 내의 집합 객체를 어떻게 참조하는지 고려해보자.
객체 유형
{ atEntry }
을 명명하고, 특정 프로토콜 메카니즘을 사용하여 객체 실상(instance)

{ atNetAddress } = { internet "10.0.0.52" }

을 명시하는 것은 관련된 atNetAddress 값이 { internet "10.0.0.52" }인 테이블에 있는 엔트리들 의 모든 실상(instance)을 참조한다.

각 관리 프로토콜은 단순한 객체 유형에 접근하는 메카니즘을 제공해야 한다. 각 관리 프로토콜은 집합 객체 유형에 대한 접근을 지원하는 지를 명시한다. 더우기, 프로토콜은 객체 유형과 실상(instance) 쌍이 하나의 유형에 대한 여러개의 실상(instance)을 참조할 때 "반환되는" 실상 (instance)들을 명시해야 한다.

다양한 관리 프로토콜에 대한 지원을 제공하기 위해, 주어진 객체 유형의 실상(instance)들을 훌륭히 식별시킬 수 있는 정보는 MIB에 정의된 객체 유형의 실상(instance)들에 의해 표현된다.

5.3.3 관리 객체를 위한 매크로

MIB 정의를 처리하는 도구의 이용을 손쉽게 하기 위해 객체-유형 매크로가 사용될 수 있다.
이 매크로는 객체 유형의 중요한 점들이 형식적인 방법으로 표현되도록 한다.

객체-유형 매크로 ::=
시작
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax)
"접근" 접근
"상태" 상태
값 표기 ::= 값 (값 ObjectName)

끝

처음에 정의된 객체 유형이 주어진다면, 우리는 MIB에 존재하는 다음의 정의들을 상상할 수 있다.

atIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
::= { atEntry 1 }

atPhysAddress 객체-유형
구문 OCTET STRING
접근 읽기쓰기
상태 필수사항
::= { atEntry 2 }

atNetAddress 객체-유형
구문 NetworkAddress
접근 읽기쓰기
상태 필수사항
::= { atEntry 3 }

atEntry 객체-유형
구문 AtEntry
접근 읽기쓰기
상태 필수사항
::= { atTable 1 }

atTable 객체-유형
구문 SEQUENCE OF AtEntry
접근 읽기쓰기
상태 필수사항
::= { at 1 }

AtEntry ::= 객체-유형 {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}

처음의 다섯가지 정의는 예를 들어, 객체 기술자 atIndex에 관계된 객체 식별자 { atEntry 1 } 객체 유형을 기술한다. 게다가, 이 객체의 구문은 가능한 접근 (읽기쓰기)과 상태 (필수사항) 와 (INTEGER)로 정의된다. 여섯번째 정의는 AtEntry라 불리는 ASN.1 유형을 기술한다.

5.4 MIB 확장

모든 인터네트 표준 MIB 문서는 이전의 문서를 폐지시킨다.

객체 식별자

{ mgmt version-number }

다음에 나오는 객체를 명명하기 위해 사용되는 꼬리라 불리는 이름 부분은 버젼들 간에 바뀌어서는 안된다. 새로운 버젼은

(1) 구식 객체 유형을 폐지로 선언하지만 그들의 이름은 제거하지 않는다.

(2) 리스트 내에 있는 객체 유형에 단순 유형이 추가되면서 리스트에 대응하는 객체 유형의 정의를 확장한다. 또는,

(3) 완전히 새로운 객체 유형을 정의한다.

새로운 버젼들은 (1) 그 객체 이름을 바꾸지 않고 이전에 정의된 객체의 의미를 바꿀 수 없다.

이런 법칙들은 그들이 인터네트 표준 MIB의 많은 버젼들에 대한 좀 더 용이한 지원을 허용하므로 중요 하다. 특히, 이름의 꼬리에 연관된 의미는 MIB의 다른 버젼들을 통해 일정하게 남는다.

MIB의 많은 버젼들은 "꼬리 공간"에서 동시에 일어날 수 있으므로 MIB의 다양한 버젼을 지원하는 구현은 단순화될 수 있다.
그러나, 결과적으로 관리 수행자는 예상되는 객체 유형의 모집합에 대응하는 실상(instance)을 반환한다.

이런 예외적인 경우에, 확고한 원칙에 따라, 관리자는 예상되는 객체 유형의 정의를 넘어선 어떤 추가적인 정보를 무시해야 한다. 그러나, 확고한 원칙은 제어 행위에 관한 실행 보호 조치가 필요하다.

즉, 실상(instance)이 그의 예측된 객체 유형과 같은 구문을 갖지 않는다면, 그런 제어 행동은 실행되지 않아야 한다. 감시와 제어의 경우, 동작에 의해 반환되는 객체의 이름은 동작에 의해 요구된 이름과 같아야 한다.

5.5 정의

RFC1155-SMI 정의 ::= 시작

EXPORTS -- 모든 것
internet, directory, mgmt, experimental, private, enterprises,
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,

ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks, Opaque;

-- 루트로 부터의 경로

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

enterprises OBJECT IDENTIFIER ::= { private 1 }

-- 객체 유형의 정의

객체-유형 매크로 ::= 시작
유형 표기 ::= "구문" 유형 (유형 ObjectSyntax)
"접근" 접근
"상태" 상태
값 표기 ::= 값 (값 ObjectName)

끝

-- MIB 내의 객체 이름

ObjectName ::=
OBJECT IDENTIFIER

-- MIB 내의 객체 구문

ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,

-- 간단한 SEQUENCE는 단순성을 유지하기 위해 여기에서 직접 언급되지 않았다.
그러나, 간단한 SEQUENCE로 암시적으로 부호화되는 응용 분야에 사용할 수 있는 유형은 다음의 CHOICE에 나타날 수 있다.

application-wide
ApplicationSyntax
}

SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}

ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque

-- 그들이 정의된 것처럼, 다른 응용 분야에 사용할 수 있는 유형은 여기에 추가 될 수있다
}

NetworkAddress ::=
CHOICE {
internet
IpAddress
}

IpAddress ::=
[APPLICATION 0] -- 전산망-바이트 순으로
IMPLICIT OCTET STRING (SIZE (4))

Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)

Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)

TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)

Opaque ::=
[APPLICATION 4] -- 임의의 ASN.1 값,
IMPLICIT OCTET STRING -- "이중-봉쇄"

끝

5.6 참고 문헌

[1] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[2] McCloghrie, K. and M. Rose, "Management Information Base for TCP/IP-based internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer
Science, May 1990.

[4] LaBarre, L., "Structure and Identification of Management Information for the Internet", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, April 1988.

[5] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[6] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[7] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

제 6 장 TCP/IP 기반 연결망의 전산망관리를 위한 관리 정보 베이스 (MIB-II)

6.1 개요

이 표준은 TCP/IP를 기반으로 하는 연결망(internets)의 전산망 관리 프로토콜을 이용한 관리 정보 베이스의 두번째 버젼을 정의한다.
단기적으로 간단하게 운용할 수 있는 시스템들을 만들기 위한 IAB 전략과 일치하여 여기에서 정의된 관리 객체들의 리스트는 필수적으로 고려되는 요소들만을 채택하는 것으로 유래되었다.

필수적인 객체들만을 채택하는 방법은 제한하지 않는다. 왜냐하면, 관련 문서에 정의된 SMI는 세 개의 확장 메카니즘을 제공하기 때문이다.

첫째, MIB의 새로운 버전 정의를 통한 새로운 표준 객체들의 추가 이다.

둘째, 실험 서브트리를 통하여 다방면에 이용가능하지만 비표준인 객체들의 추가이다.

셋째, 기업 서브트리를 통한 사적인 객체들의 추가이다. 추가된 그런 객체들은 특정 업체의 요소들 뿐아니라 다른객체들에 필수적인 지식에 요구되는 실험에도 사용될 수 있다.
MIB-II의 설계는 첫번째 확장 메카니즘에 의해 많은 영향을 받았다. 여러 새로운 변수들은 운
영 경험과 요구사항들을 기반으로 추가되었다. 이런 것을 기반으로, MIB-II에 있는 객체들을
포함하는 기준은 MIB-I의 기준과 매우 유사하다.

즉, 다음과 같다.

(1) 장애 또는 구성 관리에 필수적으로 요구되는 객체

(2) 약한 제어 객체들만이 허락된다(강력하지 못하므로, 그것들을 간섭하는 것은 단지 손상을 제한할 수 있다는 것을 의미한다). 이런 기준은 현재 관리 프로토콜들이 좀 더 강력한 제어 동작들을 수행할 정도로 안전하지 않다는 사실을 반영 한다.

(3) 현재 사용과 유용성의 확증이 요구된다.

(4) MIB-I에서는, 업체들이 그들의 소프트웨어를 적어도 기기에 설치하기 쉽도록 하기 위해 객체 수를 약 100 정도로 제한하였다. MIB-II에서는, MIB-I을 구현하는 다양한 기술적 기반으로 이런 제한이 향상되었다.

(5) 중복 변수를 피하기 위해, MIB에 있는 다른 변수들에서 유도될 수 있는 것이 포함되는 객체가 없도록 요구했다.

(6) 특정 구현 객체들은 배제된다.( 예를 들면, BSD UNIX )

(7) 코드의 기준 절들을 설치하는 것을 피하는데 합의되었다. 일반적인 지침은 계층 당 기준 절에 하나의 카운터이다.

이전의 버전인 인터네트 표준 MIB처럼 MIB-II는 필수적인 요소들만을 포함한다.
각각의 객체들이 선택사항이 될 필요는 없다. 오히려, 객체들은 다음 그룹들로 배열된다.

- 시스템
- 인터페이스
- 주소변환(삭제대상)
- IP
- ICMP
- TCP
- UDP
- EGP
- 전송
- SNMP

이런 그룹들은 적합성의 기본 단위이다. 즉, 방법은 다음과 같다. 어떤 그룹의 의미가 구현에 응용가능하다면, 그 그룹에 있는 모든 객체들을 구현해야 한다. 예를 들면, EGP를 구현할 때만 EGP 그룹을 구현해야 한다.

이런 그룹들을 정의하는 데는 두가지 이유가 있다. 첫째, 객체 구별자를 할당하는 수단을 제공하기 위해서이다. 둘째는, 그들이 어떤 객체들을 구현할 것인가를 알려고 하는 관리 수행자들의 구현을 위한 방법을 제공하기 위해서이다.

6.2 RFC 1156으로부터의 변화

이 MIB의 특성은 다음을 포함한다.

(1) 새로운 운영가능한 요구조건을 반영하기 위한 추가사항

(2) SMI/MIB와 SNMP와의 향상된 호환성

(3) 다양한 프로토콜 엔티티를 위한 개선된 지원

(4) 명확성과 판독성을 개선하기 위한 MIB 원문의 정리

MIB-II에 정의된 객체들은 다음과 같이 MIB-I에서 사용된 접두사와 같은 OBJECT IDENTIFIER 접두사를 갖는다.

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

6.2.1 삭제 대상 객체

구현자가 MIB 내의 앞으로의 변화를 준비하기 위해, 새로운 용어 "삭제대상"은 객체를 기술할 때 사용 될 수 있다. MIB에 있는 "삭제대상" 객체는 지원되어야 하지만 MIB의 새 버젼(예를 들면, MIB-III)에서는 거의 제거될 것이다.
MIB-II는 삭제대상으로 다음 객체를 명시한다.

atTable

atTable 객체를 삭제대상으로 하는 결과로써, 전체 주소 변환 그룹은 삭제대상이 된다.
이런 객체들의 삭제로 상실되는 기능은 없다. 다시 말해서 동등하거나 그 이상의 기능을 제공하는 새로운 객체들이 MIB-II에 정의된다.

6.2.2 출력 문자열

MIB 규정에 의해 다음과 같은 데이타 유형이 소개되고 있다.

DisplayString ::=
OCTET STRING

DisplayString은 [6]의 10쪽에서 11쪽에 정의된 NVT ASCII 문자 집합으로 제한된다.
다음 객체들은 DisplayString에 의해 정의된다.

sysDescr
ifDescr

이런 변화는 이 객체들의 구문이나 의미에 영향을 주지 않는다. DisplayString 표기의 사용은 MIB-II와 미래의 MIB에 사용되는 해석 방법상의 인공물일 뿐이다.
더우기 OCTET STRING에 의해 정의된 객체는 임의의 이진 자료를 포함하고, 각 옥테트는 0에서255(십진수)사이의 값을 갖는다.

6.2.3 물리적 주소

MIB 내에는 그 밖의 문서적 규정으로서,

PhysAddress ::=
OCTET STRING

과 같은 데이타 유형이 매체- 또는 물리-계층 주소들을 표현하기 위해서 소개되고 있다.
다음의 객체들은 PhysAddress에 의해 정의된다.

ifPhysAddress
atPhysAddress
ipNetToMediaPhysAddress

이런 변화는 객체의 구문이나 의미에 영향을 주지 않는다. PhysAddress 표기의 사용은 단지 MIB-II와 미래의 MIB에 사용되는 해석 방법의 인공물일 뿐이다.

6.2.4 시스템 그룹

네개의 새로운 객체들이 이 그룹에 추가된다.

sysContact
sysName
sysLocation
sysServices

이것들은 피관리 노드에 관한 접촉, 관리, 위치, 서비스 정보를 제공한다.

6.2.5 인터페이스 그룹

IP를 지원하기 위한 모든 인터페이스들을 필요로 할 때, ifNumber 객체의 정의는 잘못되었다. (예를 들면, 이 정의가 엄격하게 준수될 경우 MAC-계층 브리지와 같이 IP계층이 없는 장치들은 관리될 수 없다.) 따라서 ifNumber 객체의 기술은 바뀐다.

ifTable 객체는 읽기쓰기로 잘못 명시되었다. 그것은 접근금지로 올바르게 재설정되었다. 추가 로, 여러 새로운 값들이 ifTable 객체의 ifType 란에 추가되었다.

ppp(23)
softwareLoopback(24)
eon(25)
ethernet-3Mbit(26)
nsip(27)
slip(28)
ultra(29)
ds3(30)
sip(31)
frame-relay(32)

마지막으로, 다음과 같이 새로운 란이 ifTable 객체에 추가되었다.

ifSpecific

이것은 인터페이스를 실현하기 위해 사용되는 매체 특유의 정보에 관한 정보를 제공한다.

6.2.6 주소 변환 그룹

MIB-I에서 이 그룹은 전산망 주소(예를 들면, IP 주소)에서 물리적 주소(예를 들면, MAC 주소)로의 사상을 가능하게 하는 테이블을 포함했다. 이 테이블의 효율적인 구현은 두가지를 가정한다. 하나의 전산망 프로토콜 환경과 전산망 주소에서 물리적 주소로의 사상만 일어난다.

다양한 프로토콜 노드들을 지원하기 위한 요구(예를 들면, IP와 CLNP가 모두 살아있는 것 등을)와 역사상을 지원하기 위한 요구(예를 들면, ES-IS)는 이런 가정 모두를 무효화했다. 따라서, atTable 객체는 삭제대상으로 선언된다.

다양한 프로토콜과 역 사상 요구조건을 만족시키기 위해 MIB-II와 이것의 후속 문서들은 각 전산망 프로토콜 그룹 내의 두 주소 변환 테이블까지 할당할 것이다. 다시 말해서, IP 그룹은 IP 주소에서 물리적 주소로 가기 때문에 하나의 주소 변환 테이블을 포함할 것이다. 유사하게, CLNP를 위한 MIB 객체들을 정의하는 문서를 만들 때(예를 들면, [7]), 이것은 완전한 기능을 필요로 하기 때문에 양 방향으로의 사상을 위해 두개의 테이블을 포함할 것이다.

양 방향의 사상을 위해 두 테이블을 선택하는 것은 여러 가지로 구현에 편의를 제공하고 하나 의 내부 테이블을 통해 주소 변환 추상화를 실현하는 구현상의 부담이 없어진다.

6.2.7 IP 그룹

변수 ipForwarding의 접근 속성은 읽기전용에서 읽기쓰기로 바뀌었다.
특정 인터페이스 상에서 재결합될 수 있는 가장 큰 IP 데이타그램을 기억하는 ipAdEntReasmMaxSize
라는 새로운 열이 ipAddrTable 객체에 추가된다.
ipRoutingTable 객체의 기술자는 다른 IP 경로설정 객체들과의 일관성을 위해 ipRouteTable로 바뀌었다.
또한 ipRouteTable 객체에는 세개의 새로운 열이 있다.

ipRouteMask
ipRouteMetric5
ipRouteInfo

첫번째 것은 임의의 서브네트 마스크를 지원하는 IP 경로설정 서브시스템들을 위해 사용된다.
나머지 둘은 IP 경로설정 프로토콜에 특유한 것이다.
IP 그룹에 추가되는 두개의 새로운 객체는 다음과 같다.

ipNetToMediaTable
ipRoutingDiscards

첫번째 객체는 IP 그룹을 위한 주소 변환 테이블이다(주소 해석 그룹의 삭제대상 atTable과동일한 기능을 제공하는 것이다). 두번째 객체는 경로설정 정보가 버퍼 공간의 부족으로 상실될 때, 정보를 제공한다.

6.2.8 ICMP 그룹

이 그룹에는 변화가 없다.

6.2.9 TCP 그룹

두개의 새로운 변수가 추가된다.

tcpInErrs
tcpOutRsts

위 변수들은 오류로 수신된 TCP 세그먼트 수와 TCP에 의해 생성된 복귀 수를 기억한다.

6.2.10 UDP 그룹

새로운 테이블,

udpTable

이 추가된다.

6.2.11 EGP 그룹

EGP 감시에 유용한 객체들의 추가가 필요하다. egpNeighborTable 객체는 다음과 같다.
egpNeighAs
egpNeighInMsgs
egpNeighInErrs
egpNeighOutMsgs
egpNeighOutErrs
egpNeighInErrMsgs
egpNeighOutErrMsgs
egpNeighStateUps
egpNeighStateDowns
egpNeighIntervalHello
egpNeighIntervalPoll
egpNeighMode
egpNeighEventTrigger

위 객체에 추가로, EGP 엔티티에 연관된 독립적 시스템에 주는 egpAs 라는 새로운 변수가 추가된다.

6.2.12 전송 그룹

MIB-I은 전송 매체의 다른 유형들을 구별하지 않았다. 새로운 그룹인 전송 그룹은 이 목적을 위해 할당된다.

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

전송 매체를 관리하는 인터네트 표준 정의들이 정의될 때, 전송 그룹은 그 객체들의 이름에 접두사를 제공하기 위해 사용된다.
실제로, 그런 정의들은 "입증"될 때까지 MIB의 실험 부분에 존재하다가 인터네트 표준화 과정 의 부분으로써, 그 정의가 적절히 향상되어서, 전송 그룹하에 새로운 객체 식별자가 정의된다.
규정에 따라 할당되는 이름은 다음과 같다.

type OBJECT IDENTIFIER ::= { transmission number }

"type"은 ifTable 객체의 ifType 란에 있는 매체에 사용된 기호 값이다. "number"는 기호에 대응하는 실제 정수 값이다.

6.2.13 SNMP 그룹

IETF의 응용 지향적 연구 그룹은 그들 각각의 응용에 특유한 MIB 변수들을 정의하여 잘 받 아들이도록 작업해오고 있다.

SNMP의 경우, 통계적인 정보를 갖는데 유용하다. 새로운 그룹인 SNMP 그룹은 이 목적을 위해 할당된다.

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

6.2.14 RFC 1158로 부터의 변화

이 MIB의 특성은 다음을 포함한다.

(1) 이 표준에 있는 관리 객체는 [14]에 명시된 확장에 의해 개선된 인터네트 표준 SMI에 정의된 규정을 이용해서 정의되었다. 이런 확장을 이용해서 만들어진 정의는 RFC 1158의 것과 의미상으로 동일하다는 것이 강조되었다.

(2) PhysAddress 원문 표기는 매체 주소를 표현하기 위해 소개되었다.

(3) sysLocation의 접근 절은 읽기쓰기이다.

(4) sysServices의 정의가 명백해졌다.

(5) 새로운 ifType 값(29-32)이 정의되었다. 게다가, DS1과 E1 인터페이스 유형을 위한 본문의 기술자가 교정되었다.

(6) ipForwarding 정의가 명백해졌다.

(7) ipRouteType 정의가 명백해졌다.

(8) ipRouteMetric5와 ipRouteInfo 객체가 정의되었다.

(9) tcpConnState의 접근 절은 TCP 연결과 관련된 TCP의 제거를 제공하기 위한 읽기 쓰기이다. 이 객체의 정의는 용도를 설명하기 위해 명백해졌다.

(10) egpNeighEventTrigger 정의가 명백해졌다.

(11) 새로운 snmp 그룹에 있는 여러 변수의 정의가 명백해졌다. 게다가, snmpInBadTypes와 snmpOutReadOnlys 객체는 더 이상 존재하지 않는다. (그러나 객체에 관련된 객체 구별자들은 사용을 금지하도록 예약되었다.)

(12) snmpInReadOnlys 정의가 명백해졌다.

(13) snmpEnableAuthTraps의 본문 기술자는 snmpEnableAuthenTraps으로 바뀌었고, 정의가 명백해졌다.

(14) ipRoutingDiscards 객체가 추가되었다.

(15) IP 주소와 경로설정 테이블의 실체를 구별할 때 구현에 따른 작은 양수의 선택 적 사용은 금지되었다.

6.3 관리 객체

관리 객체들은 관리 정보 베이스 또는 MIB라 불리는 가상 정보 저장소를 통해 접근된다.
MIB에 있는 객체들은 SMI에 정의된 추상 구문 표기법 1(ASN.1)의 부분집합을 이용해서 정의 된다. 특히, 각 객체는 이름, 구문, 부호를 갖는다. 이름은 객체 유형을 명시하는 객체 식별자로 행정적으로 할당되는 이름이다. 객체 실체와 함께 객체 유형은 객체의 특정 실체를 유일하게 구분한다. 인간의 편의를 위해, 우리는 객체 유형을 참조하기 위한 객체 기술자라고 하는 문서상의 문자열을 이용한다.

객체 유형의 구문은 객체 유형에 대응하는 추상 자료 구조를 정의한다. ASN.1 언어는 이런 목적을 위해 사용된다. 그러나, SMI는 주로 사용될 ASN.1 구문들을 제한한다. 이런 제한은 단순성을 위해 명확하게 만들어진다.

객체 유형의 부호화은 객체 유형이 객체 유형의 구문을 사용해서 어떻게 표현되는가를 나타낸다. 객체 유형의 구문과 부호화 개념의 결합은 암시적으로 전산망로 전송될 때 객체 유형이 어떻게 표현되는 가를 보이는 것이다.
SMI는 SNMP에 의해 부과된 추가적인 요구조건에 의한 ASN.1 BER의 이용을 명시한다.

6.3.1 정의 형식

4절은 이 MIB 모듈에 포함된 모든 객체 유형의 명시를 포함한다. 객체 유형은 [14]에 명시된
확장들에 의해 개선된 SMI에 정의된 규정들을 이용해서 정의된다.

6.4 정의

RFC1213-MIB 정의 ::= 시작

IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212;
-- 이 MIB 모듈은 [14]에 정의된 것으로 확장된 OBJECT-TYPE 매크로를 사용한다.

-- MIB-II ( MIB-I과 같은 접두사 )

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

6.4.1 본문의 관례적 표기

DisplayString ::=
OCTET STRING

-- 이 데이타 유형은 NVT ASCII 문자 집합에서 채택된 정보를 구현하기 위해 사용된다. 관례에 따라, 이런 구문으로 된 객체들은 SIZE (0..255)로 선언된다.

PhysAddress ::=
OCTET STRING

-- 이 데이타 유형은 매체 주소를 모델화하기 위해 사용된다. 여러 매체 유형을 위해, 이것은 이진 표현일 것이다. 예를 들면, ethernet 주소는 6 옥테트 문자열로 표현된다.

6.4.2 MIB-II에서의 그룹

system OBJECT IDENTIFIER ::= { mib-2 1 }
interface OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }

-- 과거를 반영(히스테리적이라고도 한다)
-- cmot OBJECT IDENTIFIER ::= { mib-2 9 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }

6.4.3 시스템 그룹

-- 시스템 그룹의 구현은 모든 시스템을 위한 필수사항이다. 수행자가 이 변수들 중 임의의 값을 갖지 않는다면, 길이가 0인 문자열이 반환된다.

sysDescr 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기전용
상태 필수사항
기술 "엔티티의 설명. 이 값은 시스템의 하드웨어 유형, 소프트웨어 운영 유형, 그리고 네트워킹 소프트웨어의 고유명과 버젼 구별을 포함하여 야 한다. 이것이 인쇄가능한 ASCII 문자를 포함할 때만 필수사항이 다."
::= { system 1 }

sysObjectID 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "엔티티에 포함되는 전산망 관리 서브시스템 제공자의 권한 구별.
이 값은 SMI enterprises 서브트리 (1.3.6.1.4.1) 내에 할당되어 관리되고 있는 '종류'를 결정하기 용이하고 분명한 수단을 제공한다.
예를 들면, 'Flintstones, Inc' 기업이 서브트리 1.3.6.1.4.1.4242로 할당되었다면, 그 기업의 'Fred Router'에는 식별자 1.3.5.1.4.1.4242.1.1을 할당한다."
::= { system 2 }

sysUpTime 객체-유형
구문 TimeTicks
접근 읽기전용
상태 필수사항
기술 "시스템의 전산망 관리 부분이 마지막으로 재초기화된 이후의 시간
(1/100 초 단위)."
::= { system 3 }

sysContact 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 피관리 노드를 위해 접촉할 사람의 구별과 이 사람과 접촉하는 방법에 관한 정보."
::= { system 4 }

sysName 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 피관리 노드를 위해 행정적으로 할당된 이름. 규정에 의해, 이것은 그 노드의 완전히 승인된 영역명이다.".
::= { system 5}

sysLocation 객체-유형
구문 DisplayString(SIZE (0..255))
접근 읽기쓰기
상태 필수사항
기술 "이 노드의 물리적인 위치(예를 들면, 3층 전화가 있는 방)"
::= { system 6 }

sysServices 객체-유형
구문 INTEGER (0..127)
접근 읽기전용
상태 필수사항
기술 "이 엔티티가 주로 제공하는 서비스의 집합을 가리키는 값.
이 값은 합이다. 이 합은 초기에 영의 값을 채택하고, 그 다음 1에서 7까지의 범위에 있는 각 계층 L을 위해 이 노드는 2의 (L-1) 승이 그 합에 더해지는 트랜잭션을 수행한다.

예를 들면, 주로 경로선택 기능 을 수행하는 노드는 2의 (3-1)승인 4의 값을 갖는다. 반대로, 응용 서비스를 제공하는 호스트인 노드는 (2^(4-1)+2^(7-1))인 72의 값을 갖게 된다. 인터네트 프로토콜 쌍의 환경에서 값들은 다음과 같이 그것에 따라 계산되어야 한다.

계층 기능
1 물리적 (예를 들면, 리피터)
2 데이타연결/서브네트워크 (예를 들면, 브릿지)
3 인터네트 (예를 들면, IP 게이트웨이)
4 종단간 (예를 들면, IP 호스트)
7 응용 (예를 들면, 메일 중계)

OSI 프로토콜을 포함하는 시스템의 경우, 계층 5와 6이 계산될 수 있다."
::= { system 7 }

6.4.4 인터페이스 그룹

-- 인터페이스 그룹의 구현은 모든 시스템에서 필수사항이다.

ifNumber 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 시스템 상에 존재하는 (그들의 현 상태와는 무관하게) 전산망 인터페이스의 갯수."
::= { interfaces 1 }

-- 인터페이스 테이블

-- 인터페이스 테이블은 엔티티의 인터페이스에 관한 정보를 포함한다. 각 인터페이스는 '서브네트워크'에 붙은 것으로 간주된다. 이 용어는 인터네트 프로토콜 쌍 에 사용되는 주소 분할 기법을 참조하는'서브네트'와 혼동되어서는 않된다.

ifTable 객체-유형
구문 SEQUENCE OF IfEntry
접근 접근금지
상태 필수사항
기술 "인터페이스 엔트리의 나열. 엔트리의 갯수는 ifNumber 값에 의해 주어진다."
::= { interfaces 2 }

ifEntry 객체-유형
구문 IfEntry
접근 접근금지
상태 필수사항
기술 "서브네트워크 계층과 특정 인터페이스 하에 있는 객체들을 포함하는 인터페이스 엔트리."
::= { ifTable 1 }

IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
ifSpeed
Gauge,
ifPhysAddress
PhysAddress,
ifAdminStatus
INTEGER,
ifOperStatus
INTEGER,
ifLastChange
TimeTicks,
ifInOctets
Counter,
ifInUcastPkts
Counter,
ifInNUcastPkts
Counter,
ifInDiscards
Counter,
ifInErrors
Counter,
ifInUnknownProtos
Counter,
ifOutOctets
Counter,
ifOutUcastPkts
Counter,
ifOutNUcastPkts
Counter,
ifOutDiscards
Counter,
ifOutErro

rs
Counter,
ifOutQLen
Gauge,
ifSpecific
OBJECT IDENTIFIER
}

ifIndex 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "각 인터페이스에 유일한 값. 그 값의 범위는 1부터 ifNumber의 값이다. 각 인터페이스에 대한 값은 적어도 그 엔티티의 전산망 관리 시스템의 재초기화로부터 다음 재초기화까지 일정하게 남아야 한다."
::= { ifEntry 1 }

ifDescr 객체-유형
구문 DisplayString(SIZE(0..255))
접근 읽기전용
상태 필수사항
기술 "인터페이스에 관한 정보를 포함하는 문자열. 이 문자열은 하드웨어 인터페이스의 제조자 이름, 상품명, 그리고 버젼을 포함하여야 한다."
::= { ifEntry 2 }

ifType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
regular1822(2),
hdh1822(3),
ddn-x25(4),
rfc877-x25(5),
ethernet-csmacd(6),
iso88023-csmacd(7),
iso88024-csmacd(8),
iso88025-csmacd(9),
iso88026-man(10),
starLan(11),
proteon-10Mbit(12),
proteon-80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18),
e1(19), --T-1에 대응하는 유럽표준
basicISDN(20),
primaryISDN(21), -- 독자적인 선로
propPointToPointSerial(22),
ppp(23),
softwareLoopback(24),
eon(25), -- IP 상의 CLNP [11]
ethernet-3Mbit(26),
nsip(27), -- IP 상의 XNS
slip(28), -- 일반 SLIP
ultra(29), -- ULTRA 기술
ds3(30), -- T-3

sip(31), -- SMDS
frame-relay(32),
}
접근 읽기전용
상태 필수사항
기술 "프로토콜 스택에 있는 전산망 계층 바로 '아래'의 물리/연결 프로토콜에 따라 구별되는 인터페이스의 유형."
::= { ifEntry 3 }

ifMtu 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "인터페이스에서 송신 또는 수신할 수 있는 옥테트로 명시된 가장 큰 데이타그램의 크기. 전산망에 데이타그램을 전송하기 위해 사용되는 인터페이스의 경우, 이것은 그 인터페이스에 보내질 수 있는 최대
전산망 데이타그램의 크기이다."
::= { ifEntry 4 }

ifSpeed 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "bps로 인터페이스의 현재 대역폭 평가. 대역폭이 변하지 않거나 정확한 평가가 이루어지지 않는 인터페이스에 대해, 이 객체는 명목 상의 대역폭을 포함해야한다."
::= { ifEntry 5 }

ifPhysAddress 객체-유형
구문 PhysAddress
접근 읽기전용
상태 필수사항
기술 "프로토콜 스택의 전산망 계층 바로 아래에 있는 프로토콜 계층의 인터페이스 주소. 그와 같은 주소 (예를 들면, 통신선로)를 갖지 않는 인터페이스의 경우, 이 객체는 길이가 0인 옥테트 문자열을 포함
하여야 한다."
::= { ifEntry 6 }

ifAdminStatus 객체-유형
구문 INTEGER {
up(1), -- 패킷을 넘길 준비가 됨
down(2),
testing(3), -- 테스트 모드
}
접근 읽기쓰기
상태 필수사항
기술 "인터페이스의 원하는 상태. testing(3) 상태는 동작 패킷이 통과될수 없음을 지시한다."
::= { ifEntry 7 }

ifOperStatus 객체-유형
구문 INTEGER {
up(1), -- 패킷을 넘길 준비가 됨
down(2),
testing(3), -- 시험 모드
}
접근 읽기전용
상태 필수사항
기술 "인터페이스의 현 동작 상태. testing(3) 상태는 동작 패킷이 통과될 수 없음을 지시한다."
::= { ifEntry 8 }

ifLastChange 객체-유형
구문 TimeTicks
접근 읽기전용
상태 필수사항
기술 "인터페이스가 현재 동작 상태에 들어갔을 때의 sysUpTime의 값. 현 상태가 국부 전산망 관리 서브시스템의 마지막 재초기화에 앞서 들어왔다면, 이 객체는 영의 값을 포함한다."
::= { ifEntry 9 }

ifInOctets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "프레임 구성 문자를 합쳐서, 인터페이스에 수신된 옥테트의 총갯수."
::= { ifEntry 10 }

ifInUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 서브네트워크-유니캐스트 패킷의 갯 수."
::= { ifEntry 11 }

ifInNUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 비유니캐스트(서브네트워크-브로드캐스트 또는서브네트워크-멀티캐스트) 패킷의 갯수."
::= { ifEntry 12 }

ifInDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상위 계층 프로토콜에 전달되는 것을 막는 오류가 검출되지 않았을지라도 버려지는 도착 패킷의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ifEntry 13 }

ifInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "패킷에 포함된 오류때문에 상위 계층 프로토콜에 전달되지 못한 도착 패킷의 갯수."
::= { ifEntry 14 }

ifInUnknownProtos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "알려지지 않았거나 지원되지 않은 프로토콜때문에 버려지는 인터페이스를 통해 수신된 패킷의 갯수."
::= { ifEntry 15 }

ifOutOctets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "프레임 구성 문자를 포함하여, 인터페이스를 벗어나서 전송되는 총 옥테트 갯수."
::= { ifEntry 16 }

ifOutUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 서브네트워크-유니캐스트 주소에 전송되는 패킷의 총 갯수."
::= { ifEntry 17 }

ifOutNUcastPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "요청된 상위 계층 프로토콜이 버려진 것과 전송되지 않은 것을 포함하여 비유니캐스트(다시 말해서, 서브네트워크-브로드캐스트 또는 서브네트워크-멀티캐스트) 주소에 전송되는 패킷의 총 갯수."
::= { ifEntry 18 }

ifOutDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류때문에 전송되지 못하는 패킷이 없을지라도 버려지는 발신 패킷 의 갯수. 그런 패킷을 버리는 이유 중의 하나가 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ifEntry 19 }

ifOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류때문에 전송될 수 없는 발신 패킷의 갯수."
::= { ifEntry 20 }

ifOutQLen 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "출력 패킷 큐의 길이."
::= { ifEntry 21 }

ifSpecific 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "인터페이스를 실현하기 위해 사용되는 어떤 매체에 특정한 MIB 정의 에 대한 참조. 예를 들면, 인터페이스가 ethernet에 의해 실현된다면 이 객체의 값은 ethernet에 특정한 객체를 정의하는 문서를 언급한
이 정보가 존재하지 않는다면, 그것의 값은 OBJECT IDENTIFIER {0 0} 에 설정되어야 한다. 이 OBJECT IDENTIFIER는 타당한 OBJECT IDENTIFIER이고, ASN.1과 BER을 준수하는 구현은 이 값을 생성하고
인식할 수 있어야 한다."
::= { ifEntry 22 }

6.4.5 주소 변환 그룹

-- 주소 변환 그룹의 구현은 모든 시스템에 필수사항이다. 그러나, MIB-II는 이 그룹 을삭제대상으로 한다. 다시 말해서, 주소 변환 그룹은 MIB-I 노드와의 호환성을 위해서는 포함되고, MIB-III 노드에서는 제외되는 것이 바람직하다는 것이다.

-- MIB-II 이후로, 각 전산망 프로토콜 그룹은 그 자신의 주소 변환 테이블을 포함 한다.
-- 주소 변환 그룹은 NetworkAddress(예를 들면, IP 주소)를 서브네트워크에 특정한 주소로 변환하기 위한 변환 테이블의 모든 인터페이스를 거치는 결합된 하나의 테이블을 포함한다. 좀 더 좋은 용어의 결핍으로, 이 문서는 서브네트워크에 특정한 주소를 '물리적' 주소로 일컫는다.

-- 그와같은 변환 테이블의 예는 다음과 같다. ARP를 사용하는 방송전달 매체의 경우, 변환 테이블은 ARP 캐쉬와 동등하다. 또는 X.121 주소에 대한 비알고리즘 방식의 해석이 요구되는 X.25의 경우, 변환 테이블은 X.121 주소와 동등한 NetworkAddress를 포함한다.

atTable 객체-유형
구문 SEQUENCE OF AtEntry
접근 접근금지
상태 삭제대상
기술 "주소 변환 테이블은 '물리적' 주소와 동등 관계인 NetworkAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소(예를 들면, DDN-X.25 는 알고리즘 방식을 갖는다)를 결정하기 위해 변환 테이블을 사용하
지 않는다.

모든 인터페이스가 이런 유형이 된다면, 주소 변환 테이블은 빈다. 다시 말해서, 엔트리를 갖지 않게된다."
::= { at 1 }

atEntry 객체-유형
구문 AtEntry
접근 접근금지
상태 삭제대상
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 NetworkAddress를 포함한다."

인덱스 { atIfIndex,
atNetAddress }
::= { atTable 1 }

AtEntry ::=
SEQUENCE {
atIfIndex
INTEGER,
atPhysAddress
PhysAddress,
atNetAddress
NetworkAddress
}

atIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 삭제대상
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 색인의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 인터페이스와 같다."
::= { atEntry 1 }

atPhysAddress 객체-유형
구문 PhysAddress
접근 읽기쓰기
상태 삭제대상
기술 "매체-의존적인 '물리적' 주소.
이 객체를 널 문자열로 설정하는 것은 atTable 객체에 있는 대응하는 엔트리를 무효화하는 효과가 있다. 다시 말해서, 그것은 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별된 인터페이스를
효과적으로 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거 하는 것은 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자로 부터 테이블 정보를 받을 준비가 되어있어야 한다. 그런 엔트리들의 알맞은 해석은 관련된 atPhysAddress 객체의 시험을 필요로 한다."
::= { atEntry 2 }

atNetAddress 객체-유형
구문 NetworkAddress
접근 읽기쓰기
상태 삭제대상
기술 "매체-의존적인 '물리적' 주소에 대응하는 NetworkAddress(예를 들면, IP 주소)."
::= { atEntry 3 }

6.4.6 IP 그룹

-- IP 그룹의 구현은 모든 시스템에 대해 필수사항이다.

ipForwarding 객체-유형
구문 INTEGER {
forwarding(1), -- 게이트웨이로서 동작
not-forwarding(2) -- 게이트웨이로서 동작 안함
}
접근 읽기쓰기
상태 필수사항
기술 "이 엔티티로 주소가 지정되지 않았지만 이 엔티티에 의해 수신된 데이타그램의 발송에 관한 IP 게이트웨이로서 이 엔티티가 동작하는지 에 대한 지시. IP 게이트웨이는 데이타그램을 발송한다.

IP 호스트는 발송하지 않는다.(호스트에 의해 송신지가 경로를 지정한 것을 제외 하고). 몇몇 피관리 노드의 경우, 이 객체는 가능한 값들의 부분집합만을 채택할 수 있다는 것을 주목하라.

따라서, 관리 스테이션이 이 객체를 부적합한 값으로 변경하려한다면, 'badValue'라는 응답을 수행자에게 반환하는 것이 합당하다."
::= { ip 1 }

ipDefaultTTL 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "TTL 값이 수송 계층 프로토콜에 의해 지원되지 않을 때마다 이 엔티티에서 기인되는 IP 데이타그램 머리부분의 Time-To-Live 필드로 삽입되는 기본형 값."
::= { ip 2 }

ipInReceives 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "인터페이스로 부터 수신된 입력 데이타그램의 총 갯수로 오류로 수신된 것도 포함한다."
::= { ip 3 }

ipInHdrErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 머리부분 내의 오류로 인해 버려지는 입력 데이타그램의 갯수로서 잘못된 검사합, 버젼의 불일치, 다른 형식 오류, 패킷 존재 시간 (time-to-live) 초과, IP 선택사항 처리에서 발견된 오류 등을 포함 한다."
::= { ip 4 }

ipInAddrErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 헤더의 목적지 필드에 있는 IP 주소가 이 엔티티에 수신될 타당한 주소가 아니므로 버려진 입력 데이타그램의 갯수. 이 카운트는 의미 없는 주소(예를 들면, 0.0.0.0)와 지원되지 않는 등급(예를 들면,
등급 E)를 포함한다.

IP 게이트웨이가 아니므로 데이타그램을 진행시키지 않는 엔티티의 경우, 이 카운터는 목적지 주소가 국부 주소가 아니므로 버려진 데이타그램을 포함한다."
::= { ip 5 }

ipForwDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "마지막 목적지에 데이타그램을 보내기 위한 경로를 찾는 시도의 결과 로, 이 엔티티는데이타그램들의 마지막 IP 목적지가 아닌 입력 데이타그램의 갯수. IP 게이트웨이로써 동작하지 않는 실체들의 경우에
대해, 이 카운터는 해당 엔티티를 경유하여 송신지에서 결정된 경로 를 갖는 패킷들 중 성공적으로 처리된 패킷들만 포함할 것이다."
::= { ip 6 }

ipInUnknownProtos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "알려지지 않았거나 지원되지 않는 프로토콜때문에 성공적으로 수신되었지만 버려지는 국부적인 주소를 가진 데이타그램의 갯수."
::= { ip 7 }

ipInDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "데이타그램의 계속되는 처리를 막는 문제는 없으나 버려지는 입력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 재조 립을 기다리는 동안 버려지는 데이타그램은 포함하지 않는다."
::= { ip 8 }

ipInDelivers 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 사용자 프로토콜(ICMP를 포함한다.)에 성공적으로 전달되는 입력 데이타그램의 총 갯수."
::= { ip 9 }

ipOutRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "국부 IP 사용자 프로토콜(ICMP를 포함한다)이 전송을 위한 요청으로 IP에 지원했던 IP 데이타그램의 총 갯수. 이 카운터는 ipForwDatagrams에서 계산된 데이타그램을 포함하지 않는다."
::= { ip 10 }

ipOutDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "데이타그램의 목적지 전송을 방해하는 문제는 없으나 버려지는 출력 IP 데이타그램의 갯수(예를 들면, 버퍼 공간의 부족). 이 카운터는 어떤 패킷이 이런 (임의의) 버려지는 기준을 만족했다면 ipForwDatagrams에서 계산된 데이타그램을 포함한다."
::= { ip 11 }

ipOutNoRoutes 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지까지 데이타그램을 전송하기 위해 찾을 수 있는 경로가 없으므로 버려지는 IP 데이타그램의 갯수. 이 카운터는 이런 '무경로' 기준 을만족하는 ipForwDatagrams에서 계산되는 패킷을 포함한다. 이것은
호스트의 기본형 게이트웨이 모두가 작동되지 않아 경로선택을 할 수 없는 데이타그램을 포함한다."
::= { ip 12 }

ipReasmTimeout 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 재조합을 기다리는 동안 수신된 프레그먼트가 유지되는 최대치"
::= { ip 13 }

ipReasmReqds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 재조합되기 위해 요구되는 수신된 IP 프레그먼트의 갯 수."
::= { ip 14 }

ipReasmOKs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "성공적으로 재조합되는 IP 데이타그램의 갯수."
::= { ip 15 }

ipReasmFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "IP 재조합 알고리즘에 의해 검출되는 실패의 갯수(어떤 이유든, 즉 시간초과, 오류 등등). 몇가지 알고리즘(RFC 815에 있는 알고리즘)이 수신될때 결합되는 것에 의해 프레그먼트의 갯수를 잃을 수 있으므로 이것이 필요로해서 버려지는 IP 프레그먼트의 수는 아니다."
::= { ip 16 }

ipFragOKs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "성공적으로 분해된 IP 데이타그램의 갯수."
::= { ip 17 }

ipFragFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 분해될 필요가 있었으나 Don't Fragment 플래그가 설정되었기에 분해될 수 없었으므로 버려졌던 IP 데이타그램의 갯수.
::= { ip 18 }

ipFragCreates 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "이 엔티티에서 분해의 결과로 생성되었던 IP 데이타그램의 프레그먼 트 갯수."
::= { ip 19 }

-- IP 주소 테이블
-- IP 주소 테이블은 해당엔티티의 IP 주소지정 정보를 포함한다.

ipAddrTable 객체-유형
구문 SEQUENCE OF IpAddrEntry
접근 접근금지
상태 필수사항
기술 "해당엔티티의 IP 주소에 관련된 주소지정 정보의 테이블."
::= { ip 20 }

ipAddrEntry 객체-유형
구문 IpAddrEntry
접근 접근금지
상태 필수사항
기술 "해당엔티티의 IP 주소 중 하나에 대한 주소지정 정보."
인덱스 { ipAdEntAddr }
::= { ipAddrTable 1 }

IpAddrEntry ::=
SEQUENCE {
ipAdEntAddr
IpAddress,
ipAdEntIfIndex
INTEGER,
ipAdEntNetMask
IpAddress,
ipAdEntBcastAddr
INTEGER,
ipAdEntReasmMaxSize
INTEGER (0..65535)
}

ipAdEntAddr 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 주소지정 정보가 관계하는 IP 주소."
::= { ipAddrEntry 1 }

ipAdEntIfIndex 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 엔트리가 적용될 수 있는 인터페이스를 유일하게 구별하는 인덱 스 값. 해당인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex 의 값에 의해 구별되는 것과 같은 인터페이스이다."
::= { ipAddrEntry 2 }

ipAdEntNetMask 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 IP 주소와 연관된 서브네트 마스크. 이 마스크의 값은 모든 네트워크 비트가 1로 설정되고 호스트 비트는 0으로 설정된 IP 주소이다."
::= { ipAddrEntry 3 }

ipAdEntBcastAddr 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 IP 주소에 연관된 (논리적인) 인터페이스 상에 데이타 그램을 보내기 위해 사용되는 IP 브로드캐스트 주소에 있는 최하위 비트의 값. 예를 들면, 모두 1로 된 인터네트 표준 브로드캐스트 주
소가 사용될 때, 값은 1이 될 것이다.

이 값은 이런 (논리적) 인터페이스 상의 엔티티에 의해 사용되는 서브네트와 네트워크 브로드캐스트 주소에 적용한다."
::= { ipAddrEntry 4 }

ipAdEntReasmMaxSize 객체-유형
구문 INTEGER (0..65535)
접근 읽기전용
상태 필수사항
기술 "해당엔티티가 이 인터페이스 상에 수신되어 들어오는 분해된 IP 데이타그램의 입력을 재조립할 수 있는 최대 IP 데이타그램의 크기."
::= { ipAddrEntry 5 }

-- IP 경로선정 테이블
-- IP 경로선정 테이블은 현재 해당 엔티티에 알려진 각 경로를 위한 엔트리를 포함 한다.

ipRouteTable 객체-유형
구문 SEQUENCE OF IpRouteEntry
접근 접근금지
상태 필수사항
기술 "해당 엔티티의 IP 경로선정 테이블."
::= { ip 21 }

ipRouteEntry 객체-유형
구문 IpRouteEntry
접근 접근금지
상태 필수사항
기술 "특정 목적지로의 경로."
인덱스 { ipRouteDest }
::= { ipRouteTable 1 }

IpRouteEntry ::=
SEQUENCE {
ipRouteDest
IpAddress,
ipRouteIfIndex
INTEGER,
ipRouteMetric1
INTEGER,
ipRouteMetric2
INTEGER,
ipRouteMetric3
INTEGER,
ipRouteMetric4
INTEGER,
ipRouteNextHop
IpAddress,
ipRouteType
INTEGER,
ipRouteProto
INTEGER,
ipRouteAge
INTEGER,
ipRouteMask
IpAddress,
ipRouteMetric5
INTEGER,
ipRouteInfo
OBJECT IDENTIFIER
}

ipRouteDest 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "이 경로의 목적지 IP 주소. 값이 0.0.0.0인 엔트리는 기본형 경로로 간주된다. 한 목적지로의 다양한 경로들은 테이블 내에 있을 수 있다.

그러나 그런 여러 엔트리로의 접근은 사용중인 네트워크 관리 프로토콜에 의해 정의된 테이블-접근 메카니즘에 의존한다."
::= { ipRouteEntry 1 }

ipRouteIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로가 다음 홉에 도달되기 위해 거쳐야 하는 국부 인터페이스를 유일하게 구별하는 인덱스 값. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex의 같은 값에 의해 구별되는 것과 같은 인터페
이스이다."
::= { ipRouteEntry 2 }

ipRouteMetric1 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 주요 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 3 }

ipRouteMetric2 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 4 }

ipRouteMetric3 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 5 }

ipRouteMetric4 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 6 }

ipRouteNextHop 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "이 경로의 다음 홉에 대한 IP 주소.(브로드캐스트 매체를 통해 실현 되는 인터페이스에 속한 경로의 경우에, 이 필드의 값은 그 인터페이 스에 관한 수행자의 IP 주소이다.)"
::= { ipRouteEntry 7 }
ipRouteType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
invalid(2), -- 무효화된 경로
direct(3), -- 직접 연결된 (서브-) 네트워크
-- 로의 경로
indirect(4) -- 국부가 아닌 호스트/네트워크/
-- 서브-네트워크로의 경로
}
접근 읽기쓰기
상태 필수사항
기술 "경로 유형. direct(3)와 indirect(4) 값은 IP 구조 내의 직접 그리고 간접 경로선정의 개념을 나타낸다.

invalid(2) 값으로 이 객체를 설정하는 것은 ipRouteTable 객체에 있는 대응하는 엔트리를 무효화하는 것이다. 다시 말해서, 언급된 엔트로 구별되는 경로로부터 언급된 엔트리로 구별되는 목적지를 분리한다.

수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다. 따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipRouteType 객체의 검사를 요구한다."
::= { ipRouteEntry 8 }

ipRouteProto 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
local(2), -- 프로토콜이 아닌 정보 예를 들면, 수작업으로 구성된 엔트리
netmgmt(3), -- 네트워크 관리 프로토콜을 통해 설정
icmp(4), -- ICMP를 통해 얻어진 것
-- 예를 들면, 경로 재지정
-- 남은 값은 모든 게이트웨이 경로
-- 선택 프로토콜이다.
egp(5),
ggp(6),
hello(7),
rip(8),
is-is(9),
es-is(10),
ciscoIgrp(11),
bbnSpfIgp(12),
ospf(13),
bgp(14)
}
접근 읽기전용
상태 필수사항
기술 "경로를 알아내는 경로선정 메카니즘. 게이트웨이 경로선정 프로토콜
을 위한 값의 포함은 호스트가 그런 프로토콜을 지원해야한다는 것을
의미하려는 것은 아니다."
::= { ipRouteEntry 9 }

ipRouteAge 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "경로가 가장 최근에 이루어진 경로의 갱신 또는 경로가 교정되도록 결정된 이후에 경과된 초의 수. 주의할 점은 경로를 알아내는 경로 선택 프로토콜에 관한 이해없이는 어떠한 'too old'의 의미도 내포될
수 없다는 것이다."
::= { ipRouteEntry 10 }

ipRouteMask 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "ipRouteDest 필드에 있는 값과 비교되기 전에 목적지 주소와 마스크 를 논리적 AND 시키도록 지시. 임의의 서브네트 마스크를 지원하지 않는 시스템의 경우, 수행자는 대응하는 ipRouteDest 필드의 값이 등
급 - A, B, 또는 C 네트워크에 속하는지를 결정하고 다음 중 하나를 사용하여 ipRouteMask의 값을 구성한다.

마스크 네트워크
255.0.0.0 등급-A
255.255.0.0 등급-B
255.255.255.0 등급-C

ipRouteDest 값이 0.0.0.0라면(기본형 경로), 마스크 값은 또한 0.0.0.0이다. 모든 경로선정 IP 서브시스템이 암시적으로 이 메카니 즘을 사용한다는 것을 주목해야 한다."
::= { ipRouteEntry 11 }

ipRouteMetric5 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 경로에 대한 대체 경로선정 메트릭. 이 메트릭의 의미는 경로의 ipRouteProto 값에 명시된 경로선정 프로토콜에 의해 결정된다. 이 메트릭이 사용되지 않는다면, 그 값은 -1로 설정되어야 한다."
::= { ipRouteEntry 12 }

ipRouteInfo 객체-유형
구문 OBJECT IDENTIFIER
접근 읽기전용
상태 필수사항
기술 "경로의 ipRouteProto 값에 명시된 값에 의해 결정될 때, 이 경로에 책임이 있는 특정 경로선정 프로토콜에 대해서 특별한 MIB 정의에 대한 참조. 이 정보가 없다면, 그 값은 OBJECT IDENTIFIER { 0 0 }로
설정되어야 한다. 구문적으로 타당한 객체 식별자이고, ASN.1과 BER 을 준수하는 구현은 이 값을 생성하고 인식할 수 있어야 한다."
::= { ipRouteEntry 13 }

-- IP 주소 해석 테이블

-- IP 주소 해석 테이블은 '물리적' 주소와 동등 관계인 IpAddress를 포함한다. 몇몇 인터페이스는 동등 관계인 주소를 결정하기 위해 해석 테이블을 사용하지 않는다
-- (예를 들면, DDN-X.25는 알고리즘 방식을 갖는다). 모든 인터페이스가 이런 유형 이라면, 주소 해석 테이블은 비게한다. 다시 말해서, 엔트리를 갖지 않는다.

ipNetToMediaTable 객체-유형
구문 SEQUENCE OF IpNetToMediaEntry
접근 접근금지
상태 필수사항
기술 "IP 주소에서 물리적 주소로의 사상에 사용되는 IP 주소 해석 테이블."
::= { ip 22 }

ipNetToMediaEntry 객체-유형
구문 IpNetToMediaEntry
접근 접근금지
상태 필수사항
기술 "각 엔트리는 '물리적' 주소와 동등 관계인 하나의 IpAddress를 포함한다."
인덱스 { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }

IpNetToMediaEntry ::=
SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
PhysAddress,
ipNetToMediaNetAddress
IpAddress,
ipNetToMediaType
INTEGER
}

ipNetToMediaIfIndex 객체-유형
구문 INTEGER
접근 읽기쓰기
상태 필수사항
기술 "이 엔트리의 동등 관계가 유효한 인터페이스. 이 인덱스의 특정 값에 의해 구별되는 인터페이스는 ifIndex와 동일한 값에 의해 구별되는 것과 같은 인터페이스이다."
::= { ipNetToMediaEntry 1 }

ipNetToMediaPhysAddress 객체-유형
구문 PhysAddress
접근 읽기쓰기
상태 필수사항
기술 "매체 의존적인 '물리적' 주소."
::= { ipNetToMediaEntry 2 }

ipNetToMediaNetAddress 객체-유형
구문 IpAddress
접근 읽기쓰기
상태 필수사항
기술 "매체 의존적인 '물리적' 주소에 대응하는 IpAddress."
::= { ipNetToMediaEntry 3 }

ipNetToMediaType 객체-유형
구문 INTEGER {
other(1), -- 다음에 없는 것
invalid(2), -- 무효화된 사상
dynamic(3),
static(4)
}
접근 읽기쓰기
상태 필수사항
기술 "사상의 유형.

이 객체를 invalid(2)로 설정하는 것은 ipNetToMediaTable에 있는 대응하는 엔트리를 무효화하는 것이다.

다시 말해서, 실제로 언급된 엔트리로 구별되는 사상으로 부터 언급된 엔트리로 구별되는 인터페이스를 분리한다. 수행자가 테이블에서 무효화된 엔트리를 제거할지는 구현에 따르는 문제이다.

따라서, 관리 스테이션은 현재 사용하지 않는 엔트리에 대응하는 수행자들로 부터의 테이블 정보를 받을 준비가 되어 있어야 한다. 그런 엔트리에 대한 바른 해석은 관련 ipNetToMediaType 객체의 조사를 요구한다."
::= { ipNetToMediaEntry 4 }

-- 추가되는 IP 객체

ipRoutingDiscards 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔트리들이 유효하더라도 버려지도록 선택된 경로선정 엔트리의 갯수. 그런 엔트리를 버리는 이유 중의 하나가 다른 경로 엔트리를 위해서 버퍼 공간을 비우는 행위가 될 수 있을 것이다."
::= { ip 23 }

6.4.7 ICMP 그룹

-- ICMP 그룹의 구현은 모든 시스템에 필수사항이다.

icmpInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔티티가 수신한 ICMP 메세지의 총 갯수. 이 카운터는 icmpInErrors 에 의해 계산된 것 모두를포함한다."
::= { icmp 1 }

icmpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "엔티티가 수신했으나 ICMP 정의 오류(불량 ICMP 검사합, 길이 불량 등)를 가지고 있는 것으로 판명된 ICMP 메세지들의 갯수."
::= { icmp 2 }

icmpInDestUnreachs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 목적지 도달 불가능 메세지의 갯수."
::= { icmp 3 }

icmpInTimeExcds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 시간 초과 메세지의 갯수."
::= { icmp 4 }

icmpInParmProbs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 매개변수 문제 메세지의 갯수."
::= { icmp 5 }

icmpInSrcQuenchs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 발신지 억제 메세지의 갯수."
::= { icmp 6 }

icmpInRedirects 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 경로전환 메세지의 갯수."
::= { icmp 7 }

icmpInEchos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 에코우(요청) 메세지의 갯수."
::= { icmp 8 }

icmpInEchosReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 에코우 응답 메세지의 갯수."
::= { icmp 9 }

icmpInTimestamps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP Timestamp(요청) 메세지의 갯수."
::= { icmp 10 }

icmpInTimestampReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP Timestamp 응답 메세지의 갯수."
::= { icmp 11 }

icmpInAddrMasks 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 주소 마스크 요청 메세지의 갯수."
::= { icmp 12 }

icmpInAddrMaskReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 ICMP 주소 마스크 응답 메세지의 갯수."
::= { icmp 13 }

icmpOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티가 송신하려고 시도했던 ICMP 메세지의 총 갯수. 이 카운터는 icmpOutErrors에 의해 계산된 모든 것을 포함한다."
::= { icmp 14 }

icmpOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티가 버퍼 부족과 같은 ICMP 내에서 발견되는 문제로 인해 송신하지 않은 ICMP 메세지의 갯수. 이 값은 IP의 결과로서 생성된 데이타그램의 경로를 정하지 못하는 것과 같은 ICMP 계층을 벗어나서
발견된 오류를 포함해서는 안된다. 몇가지 구현에서, 이 카운터 값의 원인인 오류 유형은 없다."
::= { icmp 15 }

icmpOutDestUnreachs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 목적지 도착 불가능 메세지의 갯수."
::= { icmp 16 }

icmpOutTimeExcds 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 시간 초과 메세지의 갯수."
::= { icmp 17 }

icmpOutParmProbs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 매개변수 문제 메세지의 갯수."
::= { icmp 18 }

icmpOutSrcQuenchs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 발신지 억제 메세지의 갯수."
::= { icmp 19 }

icmpOutRedirects 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 경로전환 메세지의 갯수. 호스트의 경우, 이 객체는 항상 0이다. 호스트는 방향전환 메세지를 보내지 않기 때문이다."
::= { icmp 20 }

icmpOutEchos 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 에코우 (요청) 메세지의 갯수."
::= { icmp 21 }

icmpOutEchoReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 에코우 응답 메세지의 갯수."
::= { icmp 22 }

icmpOutTimestamps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP Timestamp (요청) 메세지의 갯수."
::= { icmp 23 }

icmpOutTimestampReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP Timestamp 응답 메세지의 갯수."
::= { icmp 24 }

icmpOutAddrMasks 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 주소 마스크 요청 메세지의 갯수."
::= { icmp 25 }

icmpOutAddrMaskReps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "송신된 ICMP 주소 마스크 응답 메세지의 갯수."
"
::= { icmp 26 }

6.4.8 TCP 그룹

-- TCP 그룹의 구현은 TCP를 구현하는 모든 시스템에 필수사항이다.
-- 특정 TCP 접속에 대한 정보를 표현하는 객체 유형의 실체들은 일시적이다. 그 실체들은 접속이 끝남과 동시에 없어진다.

tcpRtoAlgorithm 객체-유형
구문 INTERGER {
other(1), -- 다음에 없는 것

constant(2), -- 상수 rto
rsre(3), -- MIL-STD-1778, 부록 B
vanj(4) -- Van Jacobson의 알고리즘[10]
}
접근 읽기전용
상태 필수사항
기술 "인정되지 않은 옥테트를 재전송하기 위해 사용되는 타임아웃 값을 결정하기 위해 사용되는알고리즘."
::= { tcp 1 }

tcpRtoMin 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최소 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 LBOUND 양의 의미를 갖는다."
::= { tcp 2 }

tcpRtoMax 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "1/100 초 단위로 측정되는 재전송 타임아웃를 위한 TCP 구현에 의해 허용되는 최대 값. 이런 유형의 객체를 위한 좀 더 다듬어진 의미는 재전송 타임아웃을 판정하기 위해 사용되는 알고리즘에 의존한다. 특
히, 타임아웃 알고리즘이 rsre(3)일때, 이런 유형의 객체는 RFC 793 에서 기술된 UBOUND 양의 의미를 갖는다."
::= { tcp 3 }

tcpMaxConn 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "엔티티가 지원할 수 있는 TCP 접속의 총 갯수에 관한 제한. 연결의 최대 갯수가 유동적인 엔티티들에 대해, 이 객체는 -1 값을 포함해야 한다."
::= { tcp 4 }

tcpActiveOpens 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 CLOSED 상태에서 SYN-SENT 상태로의 직접적인 전이가 이 뤄진 횟수."
::= { tcp 5 }

tcpPassiveOpens 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 LISTEN 상태에서 SYN-RCVD 상태로의 직접적인 전이가 이뤄진 횟수."
::= { tcp 6 }

tcpAttemptFails 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 SYN-SENT 상태 또는 SYN-RCVD 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수와 TCP 접속이 SYN-RCVD 상태에서 LISTEN 상태로의 직접적인 전이가 이뤄진 횟수를 더한 것."
::= { tcp 7 }

tcpEstabResets 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "TCP 접속이 ESTABLISHED 상태 또는 CLOSE-WAIT 상태에서 CLOSED 상태로의 직접적인 전이가 이뤄진 횟수."
::= { tcp 8 }

tcpCurrEstab 객체-유형
구문 Gauge
접근 읽기전용
상태 필수사항
기술 "현 상태가 ESTABLISHED 또는 CLOSE-WAIT인 TCP 접속의 갯수."
::= { tcp 9 }

tcpInSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 수신된 것을 포함하여, 수신된 세그먼트의 총 갯수. 이 계산 은 현재 설정된 연결 상에서 수신된 세그먼트를 포함한다."
::= { tcp 10 }

tcpOutSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "현재 연결된 것을 포함하여 송신된 세그먼트의 총 갯수. 그러나 재전송되는 옥테트를 제외한다."
::= { tcp 11 }

tcpRetransSegs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "재전송되는 세그먼트의 총 갯수. 다시 말해서, 이전에 한번이상 전송 된 옥테트들을 포함하여 전송되는 TCP 세그먼트의 갯수."
::= { tcp 12 }

-- TCP 접속 테이블
-- TCP 접속 테이블은 해당 엔티티에 존재하는 TCP 접속에 관한 정보를 포함한다.

tcpConnTable 객체-유형
구문 SEQUENCE OF TcpConnEntry
접근 접근금지
상태 필수사항
기술 "TCP 접속 정의 정보를 포함하는 테이블."
::= { tcp 13 }

tcpConnEntry 객체-유형
구문 TcpConnEntry
접근 접근금지
상태 필수사항
기술 "현재 특정한 TCP 접속에 대한 정보. 이 유형의 객체는 일시적이다.
그런 점에서, 연결이 CLOSED 상태로 전이할 때 이 객체의 존재는 사라진다."
인덱스 { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort }
::= { tcpConnTable 1 }

tcpConnEntry ::=
SEQUENCE {
tcpConnState
INTEGER,
tcpConnLocalAddress
IpAddress,
tcpConnLocalPort
INTEGER (0..65535),
tcpConnRemAddress
IpAddress,
tcpConnRemPort
INTEGER (0..65535)
}

tcpConnState 객체-유형
구문 INTEGER {
closed(1),
listen(2),
synSent(3),
synReceived(4),
established(5),
finWait1(6),
finWait2(7),
closeWait(8),
lastAck(9),
closing(10),
timeWait(11),
deleteTCB(12)
}
접근 읽기쓰기
상태 필수사항
기술 "해당 TCP 접속의 상태.

관리 스테이션에 의해 설정될 수 있는 유일한 값이 deleteTCB(12)이다. 따라서, 관리 스테이션이 이 객체를 어떤 다른 값으로 설정하려 한다면, 수행자가 'badValue' 응답을 반환하는 것이 합당하다.

관리 스테이션이 이 객체를 deleteTCB(12)로 설정한다면, 이것은 피관리 노드 상에 있는 대응하는 연결의 TCB를 제거하고 바로 그 연결 을 해제한다.

구현에 따른 선택사항으로, RST 세그먼트는 피관리 노드에서 다른 TCP 종점으로 보내질 수 있다(그러나, 주목해야할 점은 RST 세그먼트 는 비신뢰적으로 송신된다는 것이다)."
::= { tcpConnEntry 1 }

tcpConnLocalAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 국부 IP 주소. 그 노드에 접속된 IP 인터페이 스를 위한 연결을 받아들이는 LISTEN 상태에 있는 연결에 대해, 값 0.0.0.0이 사용된다."
::= { tcpConnEntry 2 }

tcpConnLocalPort 객체-유형
구문 INTEGER (0..65535)
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 국부 포트 번호."
::= { tcpConnEntry 3 }

tcpConnRemAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 원격 IP 주소."
::= { tcpConnEntry 4 }

tcpConnRemPort 객체-유형
구문 INTEGER(0..65535)
접근 읽기전용
상태 필수사항
기술 "해당 TCP 접속을 위한 원격 포트 번호."
::= { tcpConnEntry 5 }

-- 추가되는 TCP 객체

tcpInErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 수신된 세그먼트의 총 갯수(예를 들면, 불량 TCP 검사합)."
::= { tcp 14 }

tcpOutRsts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "RST 플래그를 포함하는 송신된 TCP 세그먼트의 갯수."
::= { tcp 15 }

6.4.9 UDP 그룹

-- UDP 그룹의 구현은 UDP를 구현하는 모든 시스템에 필수사항이다.

udpInDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "UDP 사용자들에게 전달되는 UDP 데이타그램의 총 갯수."
::= { udp 1 }

udpNoPorts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지 포트에 응용 프로그램이 없는 경우, 수신된 UDP 데이타그램의 총 갯수."
::= { udp 1 }

udpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "목적지 포트에서 응용 프로그램의 문제 이외의 이유로 전달될 수 없는 수신된 UDP 데이타그램의 갯수."
::= { udp 3 }

udpOutDatagrams 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 엔티티로 부터 송신된 UDP 데이타그램의 총 갯수."
::= { udp 4 }

-- UDP Listener 테이블

-- UDP Listener 테이블은 국부 응용이 현재 데이타그램을 받아들이는 해당 엔티티의UDP 종단점에 대한 정보를 포함한다.

udpTable 객체-유형
구문 SEQUENCE OF UdpEntry
접근 접근금지
상태 필수사항
기술 "UDP Listener 정보를 포함하는 테이블."
::= { udp 5 }

udpEntry 객체-유형
구문 UdpEntry
접근 접근금지
상태 필수사항
기술 "특정한 현재 UDP Listener에 관한 정보."
인덱스 { updLocalAddress,
udpLocalPort }
::= { udpTable 1 }

UdpEntry ::=
SEQUENCE {
udpLocalAddress
IpAddress,
udpLocalPort
INTEGER(0..65535)
}

udpLocalAddress 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "이 UDP Listener에 대한 국부 IP 주소. 그 노드에 접속된 IP 인터페이스를 위한 데이타그램을 받아들이는 UDP Listener에 대해, 값 0.0.0.0이 사용된다."
::= { udpEntry 1 }

udpLocalPort 객체-유형
구문 INTEGER(0..65535)
접근 읽기전용
상태 필수사항
기술 "이 UDP Listener에 대한 국부 포트 번호."
::= { udpEntry 2 }

6.4.10 EGP 그룹

-- EGP 그룹의 구현은 EGP를 구현하는 모든 시스템에 필수사항이다.

egpInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류없이 수신된 EGP 메세지의 갯수."
::= { egp 1 }

egpInErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 판명되어 수신된 EGP 메세지의 갯수."
::= { egp 2 }

egpOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "국부적으로 생성된 EGP 메세지의 총갯수."
::= { egp 3 }

egpOutErrors 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티 내에 있는 자원 제한때문에 송신되지 않아서 국부적으로 생성된 EGP 메세지의 갯수."
::= { egp 4 }

-- EGP 이웃 노드 테이블

-- EGP 이웃 노드 테이블은 해당 엔티티의 EGP 이웃 노드들에 대한 정보를 포함한다.

egpNeighTable 객체-유형
구문 SEQUENCE OF EgpNeighEntry
접근 접근금지
상태 필수사항
기술 "EGP 이웃 노드 테이블."
::= { egp 5 }

egpNeighEntry 객체-유형
구문 EgpNeighEntry
접근 접근금지
상태 필수사항
기술 "해당 엔티티의 특정 EGP 이웃 노드와의 관계에 관한 정보."
인덱스 { egpNeighTable 1 }
::= { egpNeighTable 1 }

EgpNeighEntry ::=
SEQUENCE {
egpNeighState
INTEGER,
egpNeighAddr
IpAddress,
egpNeighAs
INTEGER,
egpNeighInMsgs
Counter,
egpNeighInErrs
Counter,
egpNeighOutMsgs
Counter,
egpNeighOutErrs
Counter,
egpNeighInErrMsgs
Counter,
egpNeighOutErrMsgs
Counter,
egpNeighStateUps
Counter,
egpNeighStateDowns
Counter,
egpNeighIntervalHello
INTEGER,
egpNeighIntervalPoll
INTEGER,
egpNeighMode
INTEGER,
egpNeighEventTrigger
INTEGER
}

egpNeighState 객체-유형
구문 INTEGER {
idle(1),
acquisition(2),
down(3),
up(4),
cease(5)
}
접근 읽기전용
상태 필수사항
기술 "해당 엔트리의 EGP 이웃 노드에 관한 국부 시스템의 EGP 상태. 각 EGP 상태는 RFC 904에서 언급된 상태와 연관된 수치보다 1 더 큰 수 치로 표현된다."
::= { egpNeighEntry 1 }

egpNeighAddr 객체-유형
구문 IpAddress
접근 읽기전용
상태 필수사항
기술 "해당 엔티티의 EGP 이웃 노드의 IP 주소."
::= { egpNeighEntry 2 }

egpNeighAs 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "해당 EGP의 상대 EGP인 독립적 시스템. 이웃 노드의 자율 시스템 번호가 아직 알려지지 않으면, 0이 명시되어야 한다."
::= { egpNeighEntry 3 }

egpNeighInMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 EGP의 상대 EGP로 부터 오류없이 수신된 EGP 메세지의 갯수."
::= { egpNeighEntry 4 }

egpNeighInErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "오류로 판명된 해당 EGP의 상대 EGP로 부터 수신된 EGP 메세지의 갯수(예를 들면, 불량 EGP 검사합)."
::= { egpNeighEntry 5 }

egpNeighOutMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "해당 상대 EGP로 국부적으로 생성된 EGP 메세지의 갯수."
::= { egpNeighEntry 6 }

egpNeighOutErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티 내의 자원 제한때문에 상대 EGP로 송신되지 못한 국부적으로 생성된 EGP 메세지의 갯수."
::= { egpNeighEntry 7 }

egpNeighInErrMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP로 부터 수신된 EGP 정의 오류 메세지의 갯수."
::= { egpNeighEntry 8 }

egpNeighOutErrMsgs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP로 송신된 EGP 정의 오류 메세지의 갯수."
::= { egpNeighEntry 9 }

egpNeighStateUps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP의 UP 상태로의 EGP 상태전이 갯수."
::= { egpNeighEntry 10 }

egpNeighStateDowns 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "상대 EGP의 UP 상태에서 다른 상태로의 EGP 상태전이 갯수."
::= { egpNeighEntry 11 }

egpNeighIntervalHello 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "EGP Hello 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t1 타이머를 나타낸다."
::= { egpNeighEntry 12 }

egpNeighIntervalPoll 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "EGP 폴 명령어 재전송 사이의 간격(1/100초 단위). 이것은 RFC 904에 정의된 것으로 t3 타이머를 나타낸다."
::= { egpNeighEntry 13 }

egpNeighMode 객체-유형
구문 INTEGER { active(1), passive(2) }
접근 읽기전용
상태 필수사항
기술 "EGP 엔티티의 폴링 모드. 수동 또는 능동의 값을 갖는다."
::= { egpNeighEntry 14 }

egpNeighEventTrigger 객체-유형
구문 INTEGER { start(1), stop(2) }
접근 읽기쓰기
상태 필수사항
기술 "운용자에 의해 개시된 시작과 종료사건을 기동하는데 사용되는 제어변수. 판독할 경우에는 이 변수는 항상 egpNeighEventTrigger에게 설정된 가장 최근의 값을 반환한다. 만약 노드상의 네트워크 관리 서브
시스템의 마지막 초기화후 egpNeighEventTrigger가 설정되어있지 않았다면 'stop'이라는 값을 반환한다.

설정시에는, RFC 904의 8-10페이지에 명시된 것같이 이 변수가 시작 사건이거나 종료사건을 명시된 이웃 상에서 일으키게 한다. 간단하게 말해서, 시작사건은 Idle 상태의 이웃 노드가 이웃 노드의 acquisition 상태를 시작할 수 있도록 해주고, Idle 상태가 아닌 상대 노드가 이웃 노드의 acquisition 상태를 재초기화하도록 한다.

종료사건은 Idle 상태가 아닌 상대 노드가 시작사건이 일어날 때까지 Idle 상태를 유지시킨다. 이때 egpNeighEventTrigger 또는 다른 것을 이용한다."
::= { egpNeighEntry 15 }

-- 추가되는 EGP 객체

egpAs 객체-유형
구문 INTEGER
접근 읽기전용
상태 필수사항
기술 "이 EGP 엔티티의 독립적 시스템 갯수."
::= { egp 6 }

6.4.11 전송 그룹

-- 어떤 시스템 상의 각 인터페이스의 기초를 이루는 전송 매체에 근거하여 전송그룹과 일치하는 부분이 그 시스템에 대하여 의무적인 사항이 된다.

-- 전송 매체를 관리하기 위한 인터네트 표준 정의가 내려질때, 전송그룹은 그들 객체들의 접두어를 제공하기 위해 사용된다.

-- 실제로, 그런 정의들은 "입증"될때까지 MIB의 실험적 부분에 속하며, 그후에 인터네트 표준화 과정의 한 부분으로서 그 정의들은 적절하게 향상되어 전송그룹 내에 새로운 객체 식별자가 정의된다. 규정에 의해, 할당된 이름은 다음과 같다.

-- type OBJECT IDENTIFIER ::= { transmission number }
-- "type"은 ifTable 객체의 ifType 열 내에 있는 매체를 위해 사용되는 기호값이며 "number"는 그 기호에 대응하는 실제 정수 값이다."

6.4.12 SNMP 그룹

-- SNMP 그룹을 구현하는 것은 SNMP 프로토콜 엔티티를 유지하는 모든 시스템에 필수사항이다.

다음에 정의된 객체들 중 어떤 것은 관리 수행자 또는 관리 스테이션에 명시된 기능들만을 지원하도록 최적화된 SNMP 구현에서 0의 값이 된다. 특히, 주의해야할 것은 아래의 객체들은 SNMP 엔티티를 언급하고, 몇몇 SNMP 엔티티들은 관리 노드에 속할 수 있다는 것이다(예를 들면, 만약 노드가 관리 스테이
-- 션처럼 호스트 역할을 한다면).

snmpInPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "전송 서비스로 부터 SNMP 엔티티로 전달된 메세지들의 총 갯수."
::= { snmp 1 }

snmpOutPkts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티로 부터 전송 서비스에게 전달되는 SNMP 메세지의 총 갯수."
::= { snmp 2 }

snmpInBadVersions 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 전달되었으나 지원되지 않는 SNMP 버전에 대한 SNMP 메세지의 총 갯수."
::= { snmp 3 }

snmpInBadCommunityNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "언급된 엔티티에게는 알려지지않은 SNMP 공동체 명을 사용하여 SNMP프로토콜 엔티티에게 전달된 SNMP 메세지의 총 갯수."
::= { snmp 4 }

snmpInBadCommunityUses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "전달된 메세지 내에 있는 SNMP 공동체 이름에 의거하여 허가되지 않 은 어떤 SNMP 동작을 갖는 SNMP 프로토콜 엔티티에게 전달되었던 SNMP 메세지의 총 갯수."
::= { snmp 5 }

snmpInASNParseErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "수신된 SNMP 메세지를 복호화할 때 SNMP 프로토콜 엔티티가 접하는 ASN.1이나 BER 오류의 총 갯수."
::= { snmp 6 }

-- { snmp 7 }은 사용되지 않는다.

snmpInTooBigs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드 값이 'too big' 인 SNMP PDU들의 총 갯수."
::= { snmp 8 }

snmpInNoSuchNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수."
::= { snmp 9 }

snmpInBadValues 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수."
::= { snmp 10 }

snmpInReadOnlys 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'readOnly'인 유효한 SNMP PDU들의 총 갯수. 주의해야할 점은 오류 상태 필드에 'read only' 값을 담고 있는 SNMP PDU를 생산하는 것은 프로토콜 오
류라는 것이다. 이와같이, 이 객체는 SNMP의 잘못된 구현을 탐지하는 수단으로서 제공된다."
::= { snmp 11 }

snmpInGenErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에게 전달되고 오류 상태 값이 'genErr'인 유효한 SNMP PDU들의 총 갯수."
::= { snmp 12 }

snmpInTotalReqVars 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "유효한 SNMP Get-Request와 Get-Next PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수."
::= { snmp 13 }

snmpInTotalSetVars 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "유효한 SNMP Set-Request PDU를 수신한 결과로써 SNMP 프로토콜 엔티티에 의해서 성공적으로 회수된 MIB 객체들의 총 갯수."
::= { snmp 14 }

snmpInGetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Request PDU의 총 갯수."
::= { snmp 15 }

snmpInGetNexts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Next PDU의 총 갯수."
::= { snmp 16 }

snmpInSetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Set-Request PDU의 총 갯수."
::= { snmp 17 }

snmpInGetResponses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Get-Response PDU의 총 갯수."
::= { snmp 18 }

snmpInTraps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 받아들여져서 처리된 SNMP Trap PDU 의 총 갯수."
::= { snmp 19 }

snmpOutTooBigs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'tooBig'인 SNMP PDU들의 총 갯수."
::= { snmp 20 }

snmpOutNoSuchNames 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'noSuchName'인 SNMP PDU들의 총 갯수."
::= { snmp 21 }

snmpOutBadValues 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'badValue'인 SNMP PDU들의 총 갯수."
::= { snmp 22 }

-- { snmp 23 }은 사용되지 않는다.

snmpOutGenErrs 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산되고 오류 상태 필드의 값이 'genErr'인 SNMP PDU들의 총 갯수."
::= { snmp 24 }

snmpOutGetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Request PDU들의 총 갯수."
::= { snmp 25 }

snmpOutGetNexts 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Next PDU들의 총 갯수."
::= { snmp 26 }

snmpOutSetRequests 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Set-Request PDU들의 총갯수."
::= { snmp 27 }

snmpOutGetResponses 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Get-Response PDU들의 총 갯수."
::= { snmp 28 }

snmpOutTraps 객체-유형
구문 Counter
접근 읽기전용
상태 필수사항
기술 "SNMP 프로토콜 엔티티에 의해서 생산된 SNMP Trap들의 총 갯수."
::= { snmp 29 }

snmpEnableAuthenTraps 객체-유형
구문 INTEGER { enabled(1), disabled(2) }
접근 읽기쓰기
상태 필수사항
기술 "SNMP 수행자 프로세스가 인증 실패 트랩들을 생성하도록 허용되었는지의 여부를 가리킨다. 이 객체의 값은 어떠한 구성 정보도 무시한다.

즉, 어떤 방법을 제공하는데 그 방법에 의해서 모든 인증 실패 트랩들이 생성될 수 없다.

이 객체들을 비휘발성 기억소자에 저장하여 네트워크 관리 시스템의 재초기화 사이의 변함없는 값을 유지할 수 있도록 할 것이 강력히 권고되고 있음을 유의하여야 한다."
::= { snmp 30 }

6.5 참고 문헌

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets," RFC 1065, TWG, August 1988.

[3] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol(SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, MIT Laboratory for
Computer Science, April 1989.

[6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983.

[7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base", RFC1162, cisco Systems, Inc., June 1990.

[8] Information porcessing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International Standard 8824, December
1987.

[9] Information porcessing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1)", International Organization for Standardization, International
Standard 8825, December 1987.

[10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California.

[11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer", RFC 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The Wollongong Group, February 1989.

[12] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

[13] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple Network Management Protocol", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, and the MIT Laboratory for COmputer
Science, May 1990.

[14] Rose, M., and K. McCloghrie, Editor, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems March 1991.

보 칙

1. 이 표준에서 정하지 아니한 사항에 대하여는 "전산망 기술기준에 관한 규칙"의 관계 규정을 적용한다.

부 칙

1. 이 표준은 1994년 3월 1일 부터 시행한다.

저작자표시

Posted by 두장

2009. 10. 29. 16:18

Computer/Network

ICMP

ICMP 프로그래밍

윤 상배

dreamyun@yahoo.co.kr

차례

1절. 소개

2절. ICMP 프로토콜에 대해서

2.1절. ICMP 의 사용목적
2.2절. ICMP 프로토콜의 구조

3절. ICMP 프로그래밍

1절. 소개

이문서는 실제로 ICMP 를 어떻게 이용할수 있는지에 대한 내용을 담고 있다. 간단한 ICMP 프로토콜에 대한 개요를 설명한후에 socket 를 이용해서 어떻게 ICMP 프로토콜의 사용이 가능한지에 대해서 얘기하게 될것이다.

이 문서는 여러분이 네트웍 프로토콜들과 TCP/IP 4계층과 socket 프로그래밍 환경에 대한 기본적인 이해를 하고 있다는 가정하에 만들어 졌다. 이들 내용은 이 사이트에서 여러개의 문서에 걸쳐서 다루고 있다. 네트웍 프로그래밍 섹션과 TCP/IP 섹션의 문서들을 참고하기 바란다.

2절. ICMP 프로토콜에 대해서

2.1절. ICMP 의 사용목적

ICMP 는 Inernet Control Message Protocol 의 줄임말이다. ICMP 프로토콜은 보통 다른 호스트나 게이트웨이 와 연결된 네트웍에 문제가 있는지 확인하기 위한 목적으로 주로 사용된다.

ICMP 를 이용한 가장 유명한 프로그램으로는 ping 프로그램이 있다. 우리는 ping 프로그램을 애용해서 특정한 게이트웨이, 호스트, 라우터 등이 제대로 작동을 하고 있는지 등을 조사하며, ICMP 요청에 대한 응답시간을 검사 함으로써 네트웍 상태도 어느정도 확인할수 있다.

2.2절. ICMP 프로토콜의 구조

ICMP 메시지는 기본적으로 IP header 를 이용해서 보내어진다. IP header 정보를 보면 (IP 자세히보기 를 참조하라), 9번째 필드가 protocol 을 위해서 사용되고 있음을 알수 있을것이다. ICMP protocol 을 위해서는 "1" 을 사용한다.

ICMP 는 다음과 같은 구조를 가진다. 첫번째 32 비트까지가 ICMP 헤더이며, 나머지부분은 ICMP 데이타이다. 이 데이타 영역은 ICMP의 어떤 기능을 이용할것이냐에 따라 다르게 설정될수 있다.

 0                                           31
 +------------+-------------+-----------------+
 | Type       | Code        | CheckSum        | 
 +------------+-------------+-----------------+
 | 가변 데이타                                |
 |                                            |

Type 필드에는 ICMP 오류 메시지의 종류를 식별하는 코드가 채워진다. Code 는 각 Type 종류에 대한 자세한 오류의 유형을 알려주기 위해서 사용된다. 이 Type 에는 다음과 같은 종류가 있다.

표 1. ICMP Type 필드 유형

0	icmp echo replay	icmp 요청에 대한 icmp 응답
3	Destination Unreachable Message	수신지까지 메시지가 도착할수 없음
4	Source Quench Message	송신지 억제
5	Redirect Message	재지시
8	icmp echo request	목적지 호스트에 ICMP 응답을 요청한다
11	Time Exceeded Message	데이타그램 시간초과(TTL 초과)
12	Parameter Problem Message	데이타그램에서의 파라메타 문제
13,14	Timestamp or Timestamp Reply Message	13:시간기록요청, 14:시간기록응답

Code 필드는 위에서 말했듯이 Type 에 따라 각각 다른 값을 가진다. 예를들어서 Type 3 번에 Code 0 번이 발생했을경우에는 오류 메시지 종류는 "수신지까지 메시지가 도착할수 없음" 이며, 그 이유는 Redirect datagrams for the Network, 즉 "네트웍을 획술할수 없음"이 된다. 이문서에서는 각 ICMP Type 에 따른 Code 까지 설명하진 않겠다. 이에 대한 자세한 내용은 rfc729를 참고하기 바란다.

3절. ICMP 프로그래밍

그럼 이제 ICMP 를 이용해서 실제 프로그래밍을 해보도록 하겠다.

ICMP 응답을 위해서 전송해야할 ICMP 헤더정보는 다음과 같다(rfc 문서에 정의되어 있음).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

그러므로 우리는 Type, Code, Checksum, Identfier, Sequence Number 를 채워서 완전한 ICMP 패킷을 만들어줘야 한다. Type 는 8번이 될것이고, Code 는 0, Checksum, Identifier, Sequence Number 은 적당히 만들어줘서 채워주면 될것이다. Identifier 와 Sequence Number 는 내가 보낸 ICMP 응답에 대한 메시지인지를 확인하기 위한 목적으로 사용한다. 만약 내가 Identifier 를 120 으로 세팅해서 보냈다면, 수신된 ICMP 메시지의 Identifer 이 120인지를 확인함으로써, 내가 보낸 ICMP 요청에 대한 응답인지를 확인가능하다. 여기에 Sequence Number 를 이용함으로써, 패킷의 일련번호까지 확인할수 있다.

그럼 실제 프로그래밍 과정을 통해서 확인해 보도록 하자. 일단 socket 를 만들때 RAW 소켓(생소켓 혹은 날소켓이라고도 한다). ICMP 는 IP 와 같은 계층에 있음으로 TCP/UDP 소켓을 이용한 접근은 불가능하기 때문이다. 어쩔수 없이 RAW 소켓을 이용해서 직접 ICMP 헤더를 고쳐주어야 한다.

icmp 헤더를 세팅하는건 icmp 구조체에 필요한 값을 써줌으로써 간단히 해결할수 있다. icmp 헤더구조체는 /usr/include/netinet/ip_icmp.h 에 선언되어 있다. 구조체를 보면 상당히 많은 다양한 멤버 변수들을 가지고 있는데, 우리는 이들 값중 Type, Code, Checksum, Identifier, Sequence Number 만을 사용하면된다. 이들을 가르키는 멤버변수는 각각 icmp_type, icmp_code, icmp_id, icmp_seq 이다.

예제 : icmp_echo.c

	
#include <stdlib.h>
#include <string.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <arpa/inet.h>
#include <errno.h>
#include <sys/socket.h>
#include <stdio.h>
#include <unistd.h>

int in_cksum(u_short *p, int n);

int main(int argc, char **argv)
{
    int icmp_socket;
    int ret;
    struct icmp *p, *rp;
    struct sockaddr_in addr, from;
    struct ip *ip;
    char buffer[1024];
    int sl;
    int hlen;
    int ping_pkt_size;

    icmp_socket = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
    if(icmp_socket < 0)
    {
        perror("socket error : ");
        exit(0);
    }

    memset(buffer, 0x00, 1024);

    p = (struct icmp *)buffer;
    p->icmp_type=ICMP_ECHO;
    p->icmp_code=0;
    p->icmp_cksum=0;
    p->icmp_seq=15;
    p->icmp_id=getpid();

    p->icmp_cksum = in_cksum((u_short *)p, 1000);
    memset(&addr, 0, sizeof(0));
    addr.sin_addr.s_addr = inet_addr(argv[1]);
    addr.sin_family = AF_INET;


    ret=sendto(icmp_socket,p,sizeof(*p),MSG_DONTWAIT,(struct sockaddr *)&addr, sizeof(addr));
    if (ret< 0)
    {
        perror("sendto error : ");
    }

    sl=sizeof(from);
    ret = recvfrom(icmp_socket,buffer, 1024, 0, (struct sockaddr *)&from, &sl);  
    if (ret < 0)
    {
        printf("%d %d %d\n", ret, errno, EAGAIN);
        perror("recvfrom error : ");
    }

    ip = (struct ip *)buffer;
    hlen = ip->ip_hl*4;
    rp = (struct icmp *)(buffer+hlen);
    printf("reply from %s\n", inet_ntoa(from.sin_addr));
    printf("Type : %d \n", rp->icmp_type);
    printf("Code : %d \n", rp->icmp_code);
    printf("Seq  : %d \n", rp->icmp_seq);
    printf("Iden : %d \n", rp->icmp_id);
    return 1;
}

int in_cksum( u_short *p, int n )
{
    register u_short answer;
    register long sum = 0;
    u_short odd_byte = 0;

    while( n > 1 )
    {
        sum += *p++;
        n -= 2;
    
    }/* WHILE */


    /* mop up an odd byte, if necessary */
    if( n == 1 )
    {
        *( u_char* )( &odd_byte ) = *( u_char* )p;
        sum += odd_byte;
    
    }/* IF */

    sum = ( sum >> 16 ) + ( sum & 0xffff );    /* add hi 16 to low 16 */
    sum += ( sum >> 16 );                    /* add carry */
    answer = ~sum;                            /* ones-complement, truncate*/
    
    return ( answer );

} /* in_cksum() */

in_cksum 함수는 다른 ICMP 를 이용하는 프로그램에서 공통적으로 사용된다. checksum 을 만들기 위한 알고리즘 정도로 생각하면 될것 같다. 실제로 ping, aping, fping 등의 관련 어플리케이션에서 사용되어지고 있다.

이제 위의 코드를 컴파일한후 테스트를 해보자.

[root@local ping]# ./icmp_echo 66.218.71.89
reply from 66.218.71.89
Type : 0 
Code : 0 
Seq  : 15 
Iden : 2323

ICMP ECHO REPLY(Type 0) 로 ICMP ECHO(Type 8) 에 대한 응답이 왔음을 알수 있다. 또한 Seq과 Iden값을 이용해서 icmp_echo 가 보낸 어플리케이션의 ICMP ECHO 에 대한 응답임을 알수 있다.

심심한데? tcpdump 를 이용해서 실제 패킷이 어떻게 이동하는지 알아보자. 아래는 위의 결과를 tcpdump 한 화면이다. -x 는 16진수 코드로 출력받기 원할때 사용하는 옵션이다.

[root@coco ping]# tcpdump icmp -x
11:08:00.763994 eth0 > localhost > w10.scd.yahoo.com: icmp: echo request (DF)
                         4500 0030 0000 4000 4001 8b6f c0a8 6482
                         42da 4759 0800 d5f6 1309 0f00 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
11:08:00.933994 eth0 < w10.scd.yahoo.com > localhost: icmp: echo reply (DF)
                         4500 0030 8352 4000 3501 131d 42da 4759
                         c0a8 6482 0000 ddf6 1309 0f00 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
...

위의 dump 화면에서 하나의 문자는 4비트를 나타낸다. 위의 dump 를 간단히 분석해 보자면 4500 ~ 4759 까지가 TCP 헤더이고, 나머지 부분이 ICMP 헤더+데이타 부분임을 알수 있다(IP표준 헤더의 크기는 160 bit 임으로). ICMP 헤더부분은 0800 에서 d5f6 까지의 부분이며(ICMP 표준 헤더크기는 32 bit 임으로), 1309 이하가 ICMP 데이타 부분임을 알수 있다.

또한 우리는 IP 의 버전이 4 이고 프로토콜이 1을 사용하고 있음을 알수 있다. IP 헤더의 처음 4비트가 Version 정보를 나타내므로 4500 의 4가 version 정보, 5가 IHL정보 임을 알수 있다. 이런식으로 찾아보면 protocol 정보가 72bit 후에 존재하고 8bit 크기를 가짐으로 dump 의 5번째 값인 4001 의 01 임을 알수 있다. 그러므로 40 은 TTL 임을 알수 있을것이다. 또한 source address 는 c0a8 6482 destination address 는 42da 4759 임을 유추해 낼수 있을것이다(IPv4 의 주소체계에서 주소는 32비트 크기를 가짐으로). IP헤더 정보는 IP 자세히보기 를 참조하기 바란다.

그럼 ICMP 를 분석해보도록 하자. Type와 Code 는 각각 8bit 크기를 가짐으로 0800 이 Type 와 Code 를 가리킴을 알수있다. d5f6 는 cheksum 이며 1309 가 바로 Identifier 이다. 1309 가 정말로 우리가 입력한 Identifier 번호인 2323 인지 확인해보길 원한다면 10 진수를 16진수로 변환 가능한 계산기를 이용해서 계산해 보면된다. 0f 는 우리가 입력한 Sequence Number 15 임을 알수 있다.

w10.scd.yahoo.com 에서 넘어온 ICMP ECHO REPLAY dump 화면의 Identifier 과 Sequence Number 가 일치함을 알수 있다. 그러므로 우리는 해당 ICMP ECHO REPLAY 패킷이 우리가 전송한 ICMP ECHO에 대한 응답 패킷임을 알수 있다.

위 프로그램은 ICMP ECHO 체크를 위한 최소한의 기능만을 가지고 있다. 만약에 ICMP REPLAY 가 되지 않는 IP에 대해서는 계속 블럭된 상태로 있게 될것이다. 이럴때는 기다리는 시간을 체크하는 방법등을 이용해서 체크를 해주어야 할것이다.

출처 : http://joinc.co.kr/modules.php?name=News&file=article&sid=73&mode=nested

저작자표시

Posted by 두장

2009. 7. 1. 21:56

Computer/Linux

php에서 날짜와 시간 표시

date(format,timestamp)

a : "am" or "pm" 표시
A : "AM" or "PM" 표시
d : 오늘이 몇일인지 표시 "01" to "31"
D : 영문으로 요일을 표시 "Mon", "Fri"
F : 영문으로 달을 표시 "January", "July"
h : 12시간을 표시. 오후 3시라도 03으로 표시. "01" to "12"
H : 24시간을 표시. 오후 3시 경우 15로 표시. "00" to "23"
g : 12시간을 표시. h와 다른 점은 0이 없다. "1" to "12"
G : 24시간을 표시. H와 다른점은 0이 없다. "0" to "23"
i : 분을 표시. "00" to "59"
j : 오늘이 몇일인지 표시. d와 다른 점은 0이 앞에 없다. "1" to "31"
l(소문자 엘) : "Friday"식으로 표시
m : 달(month)을 표시. "01" to "12"
n : 달을 표시. 0없이 "1" to "12"
M : "Jan"으로 표시
s : 초(sec)를 표시 "00" to "59"
t : 이번 달의 마지막 표시 "28" 부터 "31"일 까지
U : 기준 시점(GMT 1970년 1월 1일 00:00:00)으로부터 지난 시간을 초로 표시
w : 이번 주를 숫자로 표시 "0"(일요일) 부터 "6"(토요일)로 표시
Y : 연도(year)를 4자리로 표시. "2001"
y : 연도를 2자리로 표시. "01"
z : 올해부터의 날(day) 표시. "0" 부터 "365" 로 표시

저작자표시

Posted by 두장

2009. 7. 1. 21:41

Computer

mysql

select count(*) from flows;

select count( distinct SRCADDR) from flows;

delect from flows;

drop netflow;

drop table flows;

SELECT column_name(s)
FROM table_name
ORDER BY column_name(s) ASC|DESC

select * from table limit 5 처음부터 5개까지

select * from table limit 5,5 5개에서 10개 사이

select * from table limit 5,-1 5개에서 마지막까지

select * from tableA order by reg_dt desc limit 10; 내림차순으로 정렬해서 최상위 10개만 가져오기

저작자표시

Posted by 두장

2009. 6. 10. 00:26

Computer/Linux

Xmanager에서 Root로 리눅스 로그인하기..

vi /etc/gdm/custom.conf

[daemon]

[security]
AllowRemoteRoot=true => root로 로그인 허용

[xdmcp]
Enable=1 => xmanager 접속 허용

[gui]

[greeter]

[chooser]

[debug]

저작자표시

Posted by 두장

2009. 5. 27. 16:03

Computer/Linux

snort와 mysql 연동

snort 사이트 http://snort.org/ 에서 snort 소스를 다운 받아 압축을 푼다.

snort를 mysql에 연동하지 않고 컴파일 할때는

[root@localhost ~]# ./configure
[root@localhost ~]# make
[root@localhost ~]# make install

위와 같이 특별한 옵션 없이 컴파일후 사용하면 된다.

하지만 mysql에 연동을 하기 위해서는

[root@localhost ~]# ./configure --with-mysql
[root@localhost ~]# make
[root@localhost ~]# make install

위와 같이 mysql 옵션을 포함시켜서 configure를 해야 한다.

하지만 mysql의 위치를 제대로 찾지 못할경우..

[root@localhost ~]# ./configure --with-mysql="/usr/lib/mysql"
--with-mysql-include="/usr/include/mysql"

snort에서 제공하는 create_mysql을 통해 snort database에 table을 작성한다.

mysql -u root -p snort < schemas/create_mysql

저작자표시

Posted by 두장

2009. 5. 26. 17:36

Computer/Linux

Linux Run Level

RunLevel 0 : 시스템 종료(halt)

RunLevel 1 : 단일 사용자, 싱글 모드

RunLevel 2 : NFS를 지원하지 않는 다중 사용자 모드

RunLevel 3 : 모든 기능을 포함한 다중 사용자 모드(X윈도우 지원안함)

RunLevel 4 : 사용되지 않는 실행모드(사용자가 직접정의하여 사용)

RunLevel 5 : X윈도우 부팅, GUI환경

RunLevel 6 : 시스템 재부팅

RunLevel 3이라면 /etc/rc.d/rc3.d 디렉토리에 있는 심볼릭 링크 스크립트(실제 스크립트 파일은 /etc/rc.d/init.d 디렉토리에 있음)를 실행함.

init 명령어를 사용하여 RunLevel을 전환 할수 있다.

[root@localhost ~]# init 3

기본적으로 부팅되는 RunLevel을 변경하기 위해서는 /etc/inittab 파일을 수정해야 한다.

#

# inittab This file describes how the INIT process should set up

# the system in a certain run-level.

#

# Author: Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>

# Modified for RHS Linux by Marc Ewing and Donnie Barnes

#

# Default runlevel. The runlevels used by RHS are:

# 0 - halt (Do NOT set initdefault to this)

# 1 - Single user mode

# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)

# 3 - Full multiuser mode

# 4 - unused

# 5 - X11

# 6 - reboot (Do NOT set initdefault to this)

#

id:5:initdefault: # 부팅시 기본적으로 적용되는 RunLevel

# System initialization.

si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1

l2:2:wait:/etc/rc.d/rc 2

l3:3:wait:/etc/rc.d/rc 3

l4:4:wait:/etc/rc.d/rc 4

실행 레벨 설정 (chkconfig 명령어)

[root@localhost ~]# chkconfig --list

모든 데몬들의 실행 레벨을 확인

[root@localhost ~]# chkconfig --list httpd

httpd 데몬의 실행 레벨을 확인

[root@localhost ~]# chkconfig --level 2345 httpd on

httpd 데몬의 실행 레벨 2,3,4,5 번 활성화 시킴

Linux Root 계정의 PassWord를 잊어버렸을 경우 Linux 부팅시 RunLevel 1로 전환 후 부팅을 하면

Linux 부팅후 로그인 과정 없이 접속할수 있다.

Linux 를 부팅시 커널 버전을 선택할수 있는 Grub 화면이 뜨면
부팅 하고자 하는 커널 버전을 선택한후 'e'를 입력하면
RunLevel을 수정할수 있는 화면이 나온다..
kernel /vmlinuz-2.6.9-34.EL ro root=LABEL=/ 1
여기서 위와 같이 "root=LABEL=/" 뒤에 원하는 RunLevel "1"을 추가한후 부팅하면 된다

저작자표시

Posted by 두장

2009. 4. 28. 20:50

Computer/Linux

chkconfig 사용

시스템이 시작할 때 불필요하거나 사용하지 않는 서비스를 실행하지 않게 하는 방법 중 최근에 많이 쓰이는 명령어로 chkconfig가 있다. chkconfig 명령어를 이용하면 시스템에 설치되어 있는 모든 서비스 데몬을 확인할 수 있고, 특정 서비스를 쉽게 활성화하거나 해제할 수 있다.

예를 들어보자.

#chkconfig --list

//시스템에 설치되어 있는 모든 서비스 데몬을 확인할 수 있다.

#chkconfig --level 2345 sendmail off

//런레벨 2~5에서 sendmail을 해제한다.

#chkconfig --level 2345 nfs on

//런레벨 2~5에서 nfs 서비스를 활성화한다.

#chkconfig rlogin off

//xinetd 기반의 서비스인 rlogin을 해제한다.

--add와 --del 스위치를 사용해서 서비스를 추가하거나 삭제할 수 있다. chkconfig는 단지 설정 파일을 변경하여, 시스템을 부팅했을 때 해당 서비스 데몬의 실행 여부만 결정하는 것이므로, 다앙 서비스를 시작시키거나 중지시키려면 반드시 service 명령을 사용해야 한다. 참고로 service 명령어는 다음과 같이 사용한다.

service 서비스명 {start | stop | restart | reload}

레드햇에는 chkconfig외에도 ntsysv라는 조금은 오래된 툴이 있다. 이 툴은 시스템을 재시작할 때 자동으로 시작할 데몬을 *로 체크해서 손쉽게 지정할 수 있다.

ManPage

NAME

chkconfig - updates and queries runlevel information for system services

SYNOPSIS

chkconfig --list [name]

chkconfig --add name

chkconfig --del name

chkconfig [--level levels] name <on|off|reset>

chkconfig [--level levels] name

DESCRIPTION

chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipu-lating the numerous symbolic links in those directories.

This implementation of chkconfig was inspired by the chkconfig command present in the IRIX operating system. Rather than maintaining configuration information outside of the /etc/rc[0-6].d hierarchy, however, this version directly manages the symlinks in /etc/rc[0-6].d. This leaves all of the configuration information regarding what ser-vices init starts in a single location.

chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, chang- ing the startup information for services, and checking the startup state of a particu- lar service.

When chkconfig is run without any options, it displays usage information. If only a service name is given, it checks to see if the service is configured to be started in the current runlevel. If it is, chkconfig returns true; otherwise it returns false.

The --level option may be used to have chkconfig query an alternative runlevel rather than the current one.

If one of on, off, or reset is specified after the service name, chkconfig changes the startup information for the specified service. The on and off flags cause the service to be started or stopped, respectively, in the runlevels being changed. The reset flag resets the startup information for the service to whatever is specified in the init script in question.

By default, the on and off options affect only runlevels 2, 3, 4, and 5, while reset affects all of the runlevels. The --level option may be used to specify which run-levels are affected.

Note that for every service, each runlevel has either a start script or a stop script.

When switching runlevels, init will not re-start an already-started service, and will not re-stop a service that is not running.

chkconfig also can manage xinetd scripts via the means of xinetd.d configuration files. Note that only the on, off, and --list commands are supported for xinetd.d ser-vices.

OPTIONS

--level levels

Specifies the run levels an operation should pertain to. It is given as a string of numbers from 0 to 7. For example, --level 35 specifies runlevels 3 and 5.

--add name

This option adds a new service for management by chkconfig. When a new service is added, chkconfig ensures that the service has either a start or a kill entry in every runlevel. If any runlevel is missing such an entry, chkconfig creates the appropriate entry as specified by the default values in the init script.

Note that default entries in LSB-delimited ’INIT INFO’ sections take precedence over the default runlevels in the initscript.

--del name

The service is removed from chkconfig management, and any symbolic links in /etc/rc[0-6].d which pertain to it are removed.

Note that future package installs for this service may run chkconfig --add, which will re-add such links. To disable a service, run chkconfig name off.

--list name

This option lists all of the services which chkconfig knows about, and whether they are stopped or started in each runlevel. If name is specified, information in only display about service name.

RUNLEVEL FILES

Each service which should be manageable by chkconfig needs two or more commented lines added to its init.d script. The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list. The second line contains a description for the service, and may be extended across multiple lines with backslash continuation.

For example, random.init has these three lines:

# chkconfig: 2345 20 80

# description: Saves and restores system entropy pool for \

# higher quality random number generation.

This says that the random script should be started in levels 2, 3, 4, and 5, that its start priority should be 20, and that its stop priority should be 80. You should be able to figure out what the description says; the \ causes the line to be continued.

The extra space in front of the line is ignored.

저작자표시

Posted by 두장

2009. 4. 28. 13:07

Computer

아스키코드 표

10진수	16진수	8진수	2진수	ASCII	10진수	16진수	8진수	2진수	ASCII
0	0×00	000	0000000	NULL	64	0×40	100	1000000	@
1	0×01	001	0000001	SOH	65	0×41	101	1000001	A
2	0×02	002	0000010	STX	66	0×42	102	1000010	B
3	0×03	003	0000011	ETX	67	0×43	103	1000011	C
4	0×04	004	0000100	EOT	68	0×44	104	1000100	D
5	0×05	005	0000101	ENQ	69	0×45	105	1000101	E
6	0×06	006	0000110	ACK	70	0×46	106	1000110	F
7	0×07	007	0000111	BEL	71	0×47	107	1000111	G
8	0×08	010	0001000	BS	72	0×48	110	1001000	H
9	0×09	011	0001001	HT	73	0×49	111	1001001	I
10	0×0A	012	0001010	LF	74	0×4A	112	1001010	J
11	0×0B	013	0001011	VT	75	0×4B	113	1001011	K
12	0×0C	014	0001100	FF	76	0×4C	114	1001100	L
13	0×0D	015	0001101	CR	77	0×4D	115	1001101	M
14	0×0E	016	0001110	SO	78	0×4E	116	1001110	N
15	0×0F	017	0001111	SI	79	0×4F	117	1001111	O
16	0×10	020	0010000	DLE	80	0×50	120	1010000	P
17	0×11	021	0010001	DC1	81	0×51	121	1010001	Q
18	0×12	022	0010010	SC2	82	0×52	122	1010010	R
19	0×13	023	0010011	SC3	83	0×53	123	1010011	S
20	0×14	024	0010100	SC4	84	0×54	124	1010100	T
21	0×15	025	0010101	NAK	85	0×55	125	1010101	U
22	0×16	026	0010110	SYN	86	0×56	126	1010110	V
23	0×17	027	0010111	ETB	87	0×57	127	1010111	W
24	0×18	030	0011000	CAN	88	0×58	130	1011000	X
25	0×19	031	0011001	EM	89	0×59	131	1011001	Y
26	0×1A	032	0011010	SUB	90	0×5A	132	1011010	Z
27	0×1B	033	0011011	ESC	91	0×5B	133	1011011	[
28	0×1C	034	0011100	FS	92	0×5C	134	1011100	\
29	0×1D	035	0011101	GS	93	0×5D	135	1011101	]
30	0×1E	036	0011110	RS	94	0×5E	136	1011110	^
31	0×1F	037	0011111	US	95	0×5F	137	1011111	_
32	0×20	040	0100000	SP	96	0×60	140	1100000	.
33	0×21	041	0100001	!	97	0×61	141	1100001	a
34	0×22	042	0100010	"	98	0×62	142	1100010	b
35	0×23	043	0100011	#	99	0×63	143	1100011	c
36	0×24	044	0100100	$	100	0×64	144	1100100	d
37	0×25	045	0100101	%	101	0×65	145	1100101	e
38	0×26	046	0100110	&	102	0×66	146	1100110	f
39	0×27	047	0100111	'	103	0×67	147	1100111	g
40	0×28	050	0101000	(	104	0×68	150	1101000	h
41	0×29	051	0101001	)	105	0×69	151	1101001	i
42	0×2A	052	0101010	*	106	0×6A	152	1101010	j
43	0×2B	053	0101011	+	107	0×6B	153	1101011	k
44	0×2C	054	0101100	'	108	0×6C	154	1101100	l
45	0×2D	055	0101101	-	109	0×6D	155	1101101	m
46	0×2E	056	0101110	.	110	0×6E	156	1101110	n
47	0×2F	057	0101111	/	111	0×6F	157	1101111	o
48	0×30	060	0110000	0	112	0×70	160	1110000	p
49	0×31	061	0110001	1	113	0×71	161	1110001	q
50	0×32	062	0110010	2	114	0×72	162	1110010	r
51	0×33	063	0110011	3	115	0×73	163	1110011	s
52	0×34	064	0110100	4	116	0×74	164	1110100	t
53	0×35	065	0110101	5	117	0×75	165	1110101	u
54	0×36	066	0110110	6	118	0×76	166	1110110	v
55	0×37	067	0110111	7	119	0×77	167	1110111	w
56	0×38	070	0111000	8	120	0×78	170	1111000	x
57	0×39	071	0111001	9	121	0×79	171	1111001	y
58	0×3A	072	0111010	:	122	0×7A	172	1111010	z
59	0×3B	073	0111011	;	123	0×7B	173	1111011	{
60	0×3C	074	0111100	<	124	0×7C	174	1111100	\|
61	0×3D	075	0111101	=	125	0×7D	175	1111101	}
62	0×3E	076	0111110	>	126	0×7E	176	1111110	~
63	0×3F	077	0111111	?	127	0×7F	177	1111111	DEL

저작자표시

Posted by 두장

생활을 담고 싶다~나는 두장님~

'Computer'에 해당되는 글 43건

How to write a shell script

SNMP

목 차

제 1 장 총 칙

ICMP

ICMP 프로그래밍

윤 상배

1절. 소개

2절. ICMP 프로토콜에 대해서

2.1절. ICMP 의 사용목적

2.2절. ICMP 프로토콜의 구조

3절. ICMP 프로그래밍

php에서 날짜와 시간 표시

mysql

Xmanager에서 Root로 리눅스 로그인하기..

snort와 mysql 연동

Linux Run Level

chkconfig 사용

아스키코드 표

카테고리

태그목록

공지사항

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

링크

글 보관함

티스토리툴바

일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30