engineering/Network Eng.2006. 4. 7. 12:47

Well Known Port

WELL KNOWN PORT NUMBERS

The Well Known Ports are assigned by the IANA and on most systems can only be used by system (or root) processes or by programs executed by privileged users.

Ports are used in the TCP RFC793 to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port. The contact port is sometimes called the "well-known port".

To the extent possible, these same port assignments are used with the UDP RFC768.

The range for assigned ports managed by the IANA is 0-1023.

Port Assignments:

tcpmux1TCP Port Service Multiplexer
compressnet2Management Utility
compressnet3Compression Process
echo7Echo
discard9Discard
systat11Active Users
daytime13Daytime (RFC 867)
qotd17Quote of the Day
msp18Message Send Protocol
chargen19Character Generator
ftp-data20File Transfer Default Data
ftp21File Transfer Control
ssh22SSH Remote Login Protocol
telnet23Telnet
smtp25Simple Mail Transfer
nsw-fe27NSW User System FE
msg-icp29MSG ICP
msg-auth31MSG Authentication
dsp33Display Support Protocol
time37Time
rap38Route Access Protocol
rlp39Resource Location Protocol
graphics41Graphics
name42Host Name Server
nameserver42Host Name Server
nicname43Who Is
mpm-flags44MPM FLAGS Protocol
mpm45Message Processing Module recv
mpm-snd46MPM default send
ni-ftp47NI FTP
auditd48Digital Audit Daemon
tacacs49Login Host Protocol (TACACS)
re-mail-ck50Remote Mail Checking Protocol
la-maint51IMP Logical Address Maintenance
xns-time52XNS Time Protocol
domain53Domain Name Server
xns-ch54XNS Clearinghouse
isi-gl55ISI Graphics Language
xns-auth56XNS Authentication
xns-mail58XNS Mail
ni-mail61NI MAIL
acas62ACA Services
whois++63whois++
covia64Communications Integrator (CI)
tacacs-ds65TACACS-Database Service
sql*net66Oracle SQL*NET
bootps67Bootstrap Protocol Server
bootpc68Bootstrap Protocol Client
tftp69Trivial File Transfer
gopher70Gopher
deos76Distributed External Object Store
ettcp78vettcp
finger79Finger
http80World Wide Web HTTP
hosts2-ns81HOSTS2 Name Server
xfer82XFER Utility
mit-ml-dev83MIT ML Device
ctf84Common Trace Facility
mit-ml-dev85MIT ML Device
mfcobol86Micro Focus Cobol
kerberos88Kerberos
su-mit-tg89SU/MIT Telnet Gateway

[관련자료] 널리 알려진 포트 번호 보기

  PC의 모든 포트는 제한이 없어 어떤 프로그램이라도 자유롭게 데이터를 주고 받을 수 있다. 제한이 없는 만큼 밖에서 PC를 공격하는 프로그램이 밀고 들어와도 막을 방법이 없다. 방화벽(Firewall)은 열린 포트를 막아 밖에서 나쁜 프로그램이 침입하지 못하도록 한다. 물론 방화벽이 모든 인터넷 서비스를 막으면 안되니까 80(웹), 21(FTP)번 포트같이 자주 쓰고 믿을 수 있는 포트는 열어 놓는다. 방화벽은 밖에서 들어오는 공격도 막지만 안에서 밖으로 데이터를 보내지 못하도록 막는 일도 해 네트워크 안의 정보가 밖으로 새는 것을 막아준다.

자주 쓰는 프로그램, 서비스의 포트 번호

  포트 포워딩을 하려면 인터넷 서비스, 소프트웨어가 쓰는 포트 번호를 알아야 한다. 사람들이 많이 쓰는 네트워크 서비스, 메신저, P2P 프로그램의 포트 번호를 정리한다.

  ▲ 21번: FTP
  ▲ 22번: 보안 텔넷(SSH)
  ▲ 23번: 텔넷
  ▲ 25번: SMTP(메일 발송)
  ▲ 42번: 호스트 네임 서버
  ▲ 53번: 도메인 메인 서버
  ▲ 70번: 고퍼(Gopher)
  ▲ 79번: 핑거(Finger)
  ▲ 80번: 웹(HTTP)
  ▲ 88번: 커베로스 보안 규격
  ▲ 110번: POP3(메일 수신)
  ▲ 118, 156번: SQL 서비스
  ▲ 137~139번: NetBIOS(파일 서버)
  ▲ 161번: SNMP(네트워크 관리)
  ▲ 220번: IMAP3(일부 메일 서비스)
  ▲ 812, 987번: 버디버디
  ▲ 1214번: 카자
  ▲ 1720번: 넷미팅
  ▲ 1863, 6891~6900번: MSN 메신저
  ▲ 3389번: 터미널 서비스(원격 데스크톱)
  ▲ 4000번: ICQ
  ▲ 4000, 6112번: 배틀넷(디아블로, 스타크래스트, 워크래프트)
  ▲ 4662번: e동키(기본값)
  ▲ 5500, 5800, 5900번: VNC
  ▲ 6257, 6699번: 윈MX(기본값)
  ▲ 6346번: 그누텔라
  ▲ 6699번: 냅스터
  ▲ 7674, 22321번: 소리바다 2
  ▲ 9292, 9999번: 구루구루
  ▲ 28290번: PDBOX

  여기에 나오지 않은 프로그램의 포트 번호는 소프트웨어 제조사에 물어보면 알 수 있다. 몇몇 프로그램은 정해진 포트 번호를 쓰지 않고 사용자가 마음대로 정하는 메뉴를 둔다. 그런 프로그램을 쓴다면 포트 번호를 10,000번보다 높은 숫자로 정하는 것이 좋다. 이렇게 하면 다른 프로그램과 포트가 충돌하는 문제가 생기지 않는다.

첨부1) P2P 프로그램이 사용하는 네트워크 포트

Service NameProtocolPortDescription
당나귀
TCP4661서버 접근 포트(변경가능)
4662자료 전송 포트(변경가능)
4242
UDP4672
4665
iMashTCP5000
BitTorrentTCP6881
6889
소리바다 v.2UDP22321hello message, bye message 사용 포트
7674mp3를 검색
7675mp3파일을 보내는 사람
WINMXTCP6699
UDP6257
Direct-ConnectTCP411-412
UDP411-412
KaZaATCP1214
Guntella-MorpheusTCP6346-6347
UDP6346-6347
GuRuGuRuTCP9292
8282
31200
파일 구리TCP9493
Madster-AimsterTCP23172
9922
HotLineTCP5497
5498
5500-5503
UDP5499
V-ShareTCP8404
ManiacTCP2000
UDP2010
TCP2222
MiRCTCP6667Default
6665-6670변경
7000
ShareshareTCP6399
UDP6777
BlusterUDP41170
GoToMyPcTCP8200
NapsterTCP6600-6699
4444
5555
6666
7777
8888
8875
첨부2) 메신저 프로그램 사용 포트
Service NameServerPortDescription
MSN
64.4.130.0/24
207.46.104.0/24
207.46.106.0/24
207.46.107.0/24
207.46.108.0/24
207.46.110.0/24
TCP 1863 ,801863접속 시도 후 차단 되면 80 접속 시도
TCP 6891-6900파일 전송
UDP 6901음성채팅
UDP1863,5190Microsoft Network Messenger
Yahoo216.136.233.152/32
216.136.233.153/32
216.136.175.144/32
216.136.224.143/32
66.163.173.203/32
216.136.233.133/32
216.136.233.148/32
66.163.173.201/32
216.136.224.213/32
TCP 5050,51015050 접속 시도 후 차단 되어 있으면 Port 계속 변경
TCP 5000-5001음성채팅
TCP 5100화상채팅
Nate On203.226.253.75/32
203.226.253.135/32
203.226.253.82/32
TCP 5004-5010기본 포트 5004-5010 접속 시도후 차단되어 있으면 Port를 계속 변경
TCP80,83,7003웹 컨텐츠 및 문자 보내기
Daum211.233.29.78/32TCP 8062
SayClub211.233.47.20/32
AOLTCP 5190AOL Instant Messenger Also used by: ICQ
UDP 4000ICQ_locator
Dreamwize211.39.128.236/32
211.39.128.184/32
TCP 10000
버디버디TCP 810
TCP 940
TCP 950
케이친구TCP 7979
천리안TCP 1420
TCP4949, 8989파일 송수신
ICQTCP 5190
UINTCP 8080
Genile TCP 10000
Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 12:46

Net-SNMP

Contents

Net-SNMP Package

History of Net-SNMP

Applications of Net-SNMP

Trap Daemon

How to extend SNMP agents with Net-SNMP

Architecture of Net-SNMP Agent

Package

        An extensible agent

        An SNMP library

        tools to get or set information from SNMP agents

        tools to generate and handle SNMP traps

        a Tk/perl mib browser

History

        Originally based on the Carnegie Mellon University implementations

        University of California at Davis SNMP extends CMU-SNMP, calls UCD-SNMP

        UCD-SNMP moves to Net-SNMP in April, 2002 (Web sites also moves from www.ucd-snmp.net to www.net-snmp.net)

        Now, Net-SNMP 5.0.8 released

Application

        snmpcmd  [Common OPTIONS] AGENT [PARAMETERS]

        Common command line arguments

        Common OPTIONS

§         -c  community

§         -v 1 | 2c | 3

§         -r retries

§         -t timeout

        snmpget [COMMON OPTIONS] [-Cf] OID [OID]...

        SNMP application that uses the SNMP GET request to query for information on a network entity

        Ex) snmpget -c public localhost system.sysDescr.0

        Result) system.sysDescr.0 = Linux enterflex2.postech.ac.kr …

        snmpset [COMMON OPTIONS] OID TYPE VALUE

        SNMP application that uses the SNMP SET request to set information on a network entity

        Type: i (INTEGER), u (UNSIGNED), s (STRING)…

        ex)  snmpset -c private -v 1 localhost system.sysContact.0 s mjchoi@postech.ac.kr

        snmpwalk [APPLICATION OPTIONS] [COMMON OPTIONS] [OID]

        SNMP application that uses SNMP GETNEXT requests to query a network entity

        Retrieves lots of data, a part of MIB tree (subtree) at once

        Ex) snmpwalk -c public localhost system

        Result)      
  system.sysDescr.0 = …

                   system.sysObjectID.0 = …

                      system.sysUpTime.0 = …

        snmpstatus [COMMON OPTIONS]

        SNMP application that retrieves several important statistics from a network entity.

        The IP address of the entity. à sysDescr.0 / sysUpTime.0 /…

        Ex)  snmpstatus -c public -v 1 localhost

        Result) [127.0.0.1] à[Linux enterflex2 .postech . ac .kr 2.4.7-10 #1 Thu Sep 6 17 :27:27 EDT 2001 i386 ]…

        snmptranslate [OPTIONS] OID [OID]...

        Application that translates SNMP object identifier values from their symbolic (textual) forms into their numerical forms

        Ex) snmptranslate system.sysUpTime.0

        Result) .1.3.6.1.2.1.1.3.0

        snmptrap [COMMON OPTIONS] [-Ci] enterprise-oid agent generic-trap specific-trap uptime [OID TYPE VALUE]

        SNMP application that uses the SNMP TRAP operation to send information to a network manager 

        Definition)

TRAP-TEST-MIB DEFINITIONS ::= BEGIN

IMPORTS ucdExperimental FROM UCD-SNMP-MIB;

demotraps OBJECT IDENTIFIER ::= { ucdExperimental 990 }

demo-trap TRAP-TYPE

                      STATUS current

              ENTERPRISE demotraps

               VARIABLES { sysLocation }

               DESCRIPTION "This is just a demo"

               ::= 17

END

  Ex) snmptrap –v 1 -c public host TRAP-TEST-MIB::demotraps localhost 6 17 '' SNMPv2-MIB::sysLocation.0 s "Just here"

  Etc.

                          snmpgetnext: retrieving unknown indexed data.

                          snmpbulkwalk :uses SNMP GETBULK requests to query a network entity

                          snmptable: displaying table.

                          snmpnetstat: symbolically displays the values of various network-related information  retrieved  from  a remote system using the SNMP protocol

Trap Daemon

  snmptrapd [OPTIONS][LISTENING ADDRESSES]

                          SNMP application that receives and logs  SNMP TRAP

                          the default is to listen on UDP port 162

                          snmptrapd is displayed as follows

                          Result) 1999-11-12 23:26:07 localhost [127.0.0.1] TRAP-TEST-MIB::demotraps: Enterprise Specific Trap (demo-trap) Uptime: 1 day, 5:34:06 SNMPv2-MIB::sysLocation.0 = "Just here"


HOW To Extend

1.Define a private MIB: Example of Cluster MIB

2. Download net-snmp-5.0.8.tar.gz

3. Decompress the file in your home directory command: gtar xvfz net-snmp-5.0.8.tar.gz

4. Compile default SNMP agent

      cd net-snmp-5.0.8

      ./configure --prefix=“/usr/local/net-snmp”

      make

      make install

5. Install SNMP perl module for using mib2c

      cd net-snmp-5.0.8

      cd perl

      perl Makefile.PL -NET-SNMP-CONFIG=sh ../../net-snmp-config -NET-SNMP-IN-SOURCE=true 

      make

      make test

      make install

6. Compile the private MIB file using mib2c

        cd net-snmp-5.0.8

        cd local

        mkdir cluster

        copy the private mib in the current directory                           

ex) cp ~mjchoi/cluster.my ./cluster.my

        export MIBS=ALL

        MIBS=./cluster.my

        mib2c -c mib2c.scalar.conf generalInfo

        mib2c -c mib2c.scalar.conf currentStatus

        mib2c -c mib2c.array-user.conf loadBalancer

        mv generalInfo.* cluster

        mv currentStatus.* cluster

        mv loadBalancer.* cluster

        cp r cluster ../agent/mibgroup/.

8. Code the extension agent

(1) Header file: add necessary definitions C file

(1) Module definition: the code defining the contents of the MIB

     e.g. static oid      clusterName_oid[] = { 1, 3, 6, 1, 3, 1, 1, 1, 0 };

(2) Module initialization:

initialization before they can start providing the necessary information

    e.g. netsnmp_register_instance(netsnmp_create_handler_registration

                            ("clusterName",  do_clusterName, clusterName_oid,

                              OID_LENGTH(clusterName_oid), 

                              HANDLER_CAN_RWRITE));

(3) Variable handling: actually handles a request for a particular variable instance

    e.g.

char clusterName[NAME_LEN];

                     int *var_len;

  (4) Non-table-based modules:

the request handling routine is to retrieve any necessary scalar data

             e.g.

         switch (reqinfo->mode) {

           case MODE_GET:

             snmp_set_var_typed_value(requests->requestvb, ASN_OCTET_STR,

                                                         (u_char *) clusterName, var_len);

             break;

   

    }

(5) Simple tables: process a simple table with limited table index

e.g.

int serviceTable_handler(netsnmp_mib_handler *handler,

                    netsnmp_handler_registration *reginfo,

                    netsnmp_agent_request_info *reqinfo,

                    netsnmp_request_info *requests)  {

                           

                          switch (reqinfo->mode) {

                        case MODE_GET:

                                    switch (table_info->colnum) {

                                  case COLUMN_SRINDEX:

                               snmp_set_var_typed_value(var, ASN_INTEGER, );                                     

                                  break; 

                    

} (7) Set-able object: the handling of SNMPSET

e.g.

switch (reqinfo->mode) {

  

  case MODE_SET_ACTION:

       // XXX: perform the value change here

       if ( /* XXX: error? */ ) {

           netsnmp_set_request_error(reqinfo,

requests, error_msg.);

       }

       break;

  case MODE_SET_COMMIT:

       //  XXX: delete temporary storage

       if ( /* XXX: error? */ ) {

            netsnmp_set_request_error(reqinfo, requests,

                                     SNMP_ERR_COMMITFAILED);

       }

       break;

  }

                        

                          }

                            

}

(6) General tables: process a general table, which the maximum

           index is not determinable

           e.g.

              Init_{Name}_Entry();  // Perform any necessary initialization

              while (( index = Get_Next_{Name}_Entry() ) != EndMarker ) {

                  construct OID from vp->name and index

                  compare new OID and request

                  if valid {

                     save current data

                     if finished // exact match, or ordered table

                     break; // so don't look at any more entries

                  }

                

              }

          

9. Compile the MIB extension and generate SNMP daemon

        ./configure --with-mib-modules=cluster/generalInfo, cluster/currentStatus, cluster/loadBalancer”

        cd agent   

        make

        ./snmpd c config_file (ex) ./snmpd c /etc/snmp/snmpd.conf

        snmpd [OPTIONS] [LISTENING ADDRESSES]

        SNMP agent which binds to a port and awaits requests from SNMP management software.

        collects the requested information and/or performs the requested operations and returns the information to the sender.

        By default, snmpd listens for SNMP requests on  UDP port 161.

10.  Modify snmpd.conf for SNMP community

# First, map the community name

#               sec.name    source     community

com2sec  clusterUser  default       postech

# Second, map the security name into a group name:

#          groupName      securityModel  securityName

group clusterGroup              v1            clusterUser

# Third, create a view for us to let the group have rights to:

#          name        incl/excl          subtree               mask(optional)

view    mibview     included   .iso.org.dod.internet

# Finally, grant the group read-only access to the systemview view.

#             group context sec.model sec.level prefix read   write  notif

access  clusterGroup ""  any    noauth  exact  mibview  mibview none

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 12:32

1. NMS 란 무엇인가?

1.1 NMS의 정의

네트워크상의 전 장비들의 중앙 감시 체제를 구축하여 Monitoring, Planning 및 분석이 가능하여야 하며 관련 데이터를 보관하여 필요 즉시 활용 가능하게 하는 관리 시스템이다. 다시 말하면, NMS는 네트워크 관리자가 NMS제품을 사용하여 현재 운영되는 workstation으로부터 네트웍을 control and monitor할 수 있게 한다.

1.2 NMS가 하는 일

NMS(network Management System)는 전반에 걸친 정보를 수집 관리하는데 그 목적이 있다. 현재 많은 NMS상품들이 시중에 나와 있고 기본적으로 아래와 같은 공통점을 갖는다.

VENDER

상품

UB Network

NetDirector

IBM

Netview

Cisco

Ciscoworks

HP

Openview

Cabletron

Lanview

Synotics

Optivity

3COM

Viewbuilder

(1) 네트워크상의 전 장비들의 중앙 감시 체제를 구축하여 Monitoring, Planning 및 분석이 가능하여야 하며 관련 데이터를 보관하여 필요 즉시 활용 가능하여야 한다.
 
(2) SNMP Protocol을 관리Protocol로 사용하며 CMIP으로의 전환 방안이 제시되어야 한다.
 
(3) Ethernet및 FDDI네트워크에 접속되어있는 자원들을 관리할 수 있어야 한다.
 
(4) Graphic User Interface를 지향해야 한다.
 
(5) MIB-1, MIB-2및 타 Vendor Specific MIB을 지원할 수 있어야 한다.
 
(6) 보안성이 우수하고 관리가 용이해야 한다.

통상 NMS는 Workstation급에 Network관리자가 사용하기에 편한 곳에 설치하며 단위 Network에 복수 개의 NMS를 병행할 수도 있다. NMS구동은 SNPM에 의해 작동하며 SNMP(Single Network Management Protocol) System은 NMS, NMS Agent, MIB(Management Information Base) 3부분으로 이루어 진다. SNMP는 Network Device 즉, Routers, Bridges, Terminal Server, Host PC 등에 직접 Query하는 Transaction-Oriented Protocol이다.

NMS는 SNMP Agent에 정보를 의뢰함으로써 Device들을 감시 제어한다. SNMP Agent는 NMS의 요구에 응답하고 Network상의 관리 대상 장비에 존재하는 S/W이다. Agent에는 장비에 관한 정보인 MIB(Routing Table Counter, status indication 등)이 있으며 이들은 Agent에 대한 NMS의 Poll과 Query에 대한 응답으로 NMS에 보내지고 이들은 다시 DB에 저장된다.

본래 의미에서의 네트워크 관리 기능은 아직 사람에게 의지하고 있지만 최근에는 SNMP등의 규격화된 관리용 Protocol을 이용하는 제품이 출하되기 시작했다. 그러나 SNMP을 지원하고 있는 기기만 관리 대상이 되므로 이후 network에 접속되는 기기는 이와 같은 Protocol을 지원하는 추세가 가속화 되고 있다.

 

2. SNMP 프로토콜

2.1 기본 구성

위에서 말한 바와 같이 SNMP는 다음의 3부분으로 구성되어있다.

 1. 관리대상 (서비스 제공자, Agent)
 2. 네트워크 관리 Station(서비스 이용자, manager)
 3. 네트워크 관리 Protocol

SNMP의 기본관리구조는 그림 5.1과 같으며 서비스 제공자는 Agent로, 서비스 이용자는 Manager로 각각 불린다. 또 SNMP Protocol구성과 SNMP를 사용한 네트워크 관리방법은 그림 5.2와 같다.

SNMP는 IP (Internet Protocol)에서 작동하는 UDP(User datagram Protocol:커넥션형 트랜스포트 프로토콜)에 장치되어 있다. 따라서 SNMP통신을 하기 위해서는 Manager와 Agent모두에게 가IP Address가 필요하다.


<그림 5.1 SNMP의 기본적인 관리구조>


<그림 5.2 SNMP 프로토콜 구성과 SNMP를 사용한 네트워크 관리방법>

2.2 SNMP의 통신 방식

SNMP의 통신은 그림 5.3과 같다. SNMP를 사용한 통신은 SNMP Manager와 SNMP Agent사이에서 MIB(Management Information Base : 관리정보 베이스)를 기초로, 여러 명령어를 사용해서 네트워크를 관리한다.

● 기본 명령어와 동작

명령어

1. GET : 관리정보를 검색하는데 사용된다.
2. GET-NEXT : 관리정보를 연속해서 검색하는데 사용된다.
3. SET : 관리정보를 바꿔쓰는데 사용된다.
4. TRAP : 예외작동을 통지하는 경우에 사용된다.

동작

1. 변수 읽어들이기 : Agent가 가지고 있는 변수를 읽어들인다.
2. 변수 써 넣기 : Agent가 가지고 있는 변수를 바꿔 쓴다.
3. 트랩 : 예상치 못한 사태가 발생했음을 전한다.

이러한 명령어들은 모두 SNMP Manager측에서 발신되지만 SNMP Agent측에서는 장애 등의 예상치 못한 사태가 발생했을 때에만 SNMP Manager에게 trap명령을 통지하는 구조로 되어 있다. 또 SNMP Manager의 SNMP 애플리케이션에는 GUI와 SNMP Manager가 하나로 된 것과 따로 된 것이 있으므로 구입시 주의하여야 한다.


<그림 5.3 SNMP 통신 체제>

2.3 MIB (Management Information Base)

MIB는 SNMP에서 관리하는 정보의 데이터 베이스와 같은 것으로 (관리 항목의 정의 파일 및 표 등이 있는 것), 어떤 항목에 대하여 문의하면 어떤 대답이 되돌아올지를 각각 정해놓고 있다. MIB에는 다음의 세 종류가 있다.

1. MIB-1

MIB-1은 관리정보 베이스로 원래는 MIB라고 불렀으나 MIB의 확장판인 MIB-2가 발표됨에 따라 MIB-2와 구별하기 위해서 MIB-1이라 불리게 되었다.
MIB -1은 네트워크 관리에 필요한 최소한의 관리대상을 정의하고 있는데 그 object는 114개이다.

2. MIB-2

MIB-2는 MIB-1의 확장판으로 MIB-1의 모든 object들을 포함하여 총 171개의 object를 포함하고 있다. 현재 시장에서 제공되고 있는 대부분의 제품은 MIB-2를 지원하고 있다.

3. 확장 MIB

MIB-1, MIB-2에서는 규정되어 있지 않으나, Vendor가 가지고 있는 독자적 기능을 SNMP에서 관리할 수 있도록 정의한 관리 항목이다.

 

이상으로 근거리 통신망(LAN)의 전반적인 사항을 알아 보았다. 여기서는 데이터 통신의 기본 개념과 네트워킹의 기본, 네트워크 장비 및 인터네트워킹의 개요, 프로토콜, 네트워크 운영체제, 네트워크 관리 시스템 등에 대해 살펴 보았다. 이러한 근거리 통신망의 전반적인 사항은 뒤에서 배울 원거리 통신망의 기본이 된다.

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 11:53
RMON (Remote MONitoring)

RMON

Network의 효율적 이용을 위해서 현재의 Network 상태를 측정하고 과거의 기록을 토대로 앞으로의 Network 문제를 사전에 예견하고 제거하기 위해서 유용하게 이용되는 것이 RMON(Remote network-MONitoring)이다. 중앙에서 원거리 지역의 local Network의 전체 이용현황을 적은 대역폭으로 쉽게 알수 있게 해준다.

기존의 SNMP MIB들이 대리인(Agent)이 탑재된 장비 자신의 처리 결과만을 보유하고 있는 데 반해서 RMON agent는 한 세그먼트 전체에서 발생하는 트래픽을 파악하게 해준다. 즉 전체 발생 트래픽, segment에 연결된 각 호스트의 트래픽, 호스트들 간의 트래픽 발생현황을 알려준다.

이런 처리를 위해서 RMON agent는 전체 통계 데이타, 이력 데이타(history), HOST 관련 데이타, HOST MATRIX와 사전에 문제 예측 및 제거를 위해서 특정 패킷을 필터링하는 기능과 임계치를 설정해서 이에 도달하면 자동으로 알려주는 경보기능 및 사건 발생 기능을 보유하고 있어야 한다.

Network에서 발생한 트래픽 모두를 관찰하고자해서 나온 것이 Network Moniotor다. 또는 분석기(analayzer), Probe라고 부른다. 이글에서는 SNMP에서와의 혼동을 막기위해서 대리인(agent)라고 칭한다. 실제는 probe라는 말을 많이 쓴다. Network 데이타를 수집하는 Agent는 보통 단독 장비로 또는 W/S, PC/나 hub, switch등의 장비에 탑재하는 경우가 있다.단독 장비는 모든 트래픽을 분석할 수 있으나 별도로 구입해야하므로 비용이 문제고 기존장비에 탑재된 경우는 비용절감 효과는 있으나 장비고유의 업무처리 때문에 트래픽을 정확하게 분석할 수 없는 단점이 있다

1. RMON 표준

RMON이 정의되어있는 RFC1757(구rfc1271)는 주로 RMON MIB에 집중되어 있다.이 문서는 기본적으로 SNMP를 기반으로 한 RMON 대리인과 RMON 관리자간의 각종 절차를 담고 있다. 즉 대리인이 관리자의 요청에 의해서 어떻게 데이타를 채집하고 그리고 그 데이타를 보관하고 어떻게 삭제하는 가에 관한 것이다.

RMON이 갖추어야할 기본적인 목표를 다음과 같이 제시하고 있다.

1) Offline 동작
관리자와 RMON 대리인간의 통신에 여향을 받지 않고 대리인은 해당 세그먼트의 성능, 구성 정보등을 축적하고 관리할 수 있어야한다.

2) Proactive Monitoring
대리인에 주어진 자원에 따라 Network를 진단하고 성능 자료의 이력 관리를 통해서 장애 및 장애에 대한 기록을 관리자에게 보고할수 있어야 한다.

3) 문제 탐지 및 보고
관리자가 특정 상태 - error , 특정 패킷 -에 대한 보고를 명령하면 이를 계속 감시하다가 탐지되면 이 사건을 기록하고 관리자에게 통보할수 있어야 한다.

4) 부가 가치 자료
수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 가장 많은 트래픽과 에러를 발생시키는 호스트들을 집중 관찰함으로써 문제해결에 대한 세밀한 정보를 관리자에게 줄 수 있다.

5) 복수의 관리자
여러 관리자가 보내는 명령을 모두 수용해야 한다. 이때 대리인의 시스템 용랑에 따라서 즉 메보리 부족등으로 관리자 명령대로 수행을 못하거나 거절하는 경우가 발생할 수도 있다.

RMON 표준에는 관리자가 데이타 수집 명령을 내리지 않았을 때 , 즉 RMON Agent가 동작을 시작하면서 필요한 정보를 수집할 것인지에 대한 기준은 없다. 단지 구현하는 사람의 임의로 정해놓고 있다. 그래서 실제로 어떤 RMON Agent는 관리자가 일정한 데이타의 수집을 요청하지 않으면 전혀 데이타를 수집하지 않는 것도 있다. 대부분은 기본적으로 status , history, host, host matrix 정도의 데이타는 Agent가 스스로 데이타를 수집하기 시작한다.이때는 이 테이블 열(row)의 소유자 ,즉 만든 관리자는 "monitor"라는 이름으로 시작해서 구별할 것을 권장하고 있다.

RFC1757에는 9개의 MIB Group이 정의되어있다. 그러나 구현하는 것은 구현자 임의로 선택할 수 있다. 그러나 한 그룹을 구현하려면 그 그룹내에 있는 모든 객체를 구현해야만 한다. 즉 Host Group를 구현하면 반드시 HostControlTable, HostTable, HostTimeTable 모두를 반드시 구현해야 한다.

그리고 RMON MIB를 구현하기 위해서는 <그림1>의 system과 interface 그룹은 반드시 구현되어야 한다. 이는 RMON MIB에서 두 GROUP에 있는 객체를 이용하고 있기 때문이다. 또한 RMON MIB 각각의 그룹들은 서로 관련이 있는 경우가 많다. 그래서 하나의 그룹을 구현하면 반드시 다른 그룹도 구현해야 한다. HISTORY 그룹은 반드시 statistics 그룹의 구현이 필수다.

RMON MIB 그룹은 모두 테이블 형태다. 대부분의 그룹은 해당하는 객체들을 생성하는 데 필요한 각종 자료 - history 시간 간격, host 그룹의 HOST 수, 자료의 생성자(소유자) 등- 를 가지고 있는 관리(control) 테이블과 실제 필요한 자료를 수집하는 테이블로 구성되어있다. 관리 테이블에는 단순하게 크기를 제한하거나 수집할 자료의 interface를 지시하는 이외에 이 테이블을 포함해서 자료 테이블을 만들고 삭제하게 할 수 있는 "상태(status)" 객체가 정의되어있다.

이 상태 객체를 변경함으로써 테이블의 생성 , 자료 수집, 삭제가 이루어진다. 이 객체가 생성중(underCreation(3)) 상태이면 대부분의 자료 테이블은 완전한 자료가 아니다. 한편 대부분의 관리 테이블은 상태객체가 "valid(1)" 상태이면 관리 테이블의 자료를 수정할 수 없다. 이는 이미 설정된 관리값으로 자료 테이블이 형성된 다음이므로 수정하는 대신에 삭제하고 재설정 또는 생성중 상태로 먼저 수정하고 설정해야 한다.

복수의 관리자에게 대리인이 응답하므로 대리인은 많은 시스템 자원이 필효하게 된다. 복수관리자의 요청을 시스템 자원의 부족으로 거절하는 경우가 생길 수가 있다. 이러한 경우등을 방지하기 위해서는 주관리자가 각 그룹이에 설정될 수 있는 테이블의 열(ROW) 등을 제한하거나 관리자가 불필요하게 설정해 놓은 자원은 스스로 삭제하는 것이 필요하다. 물론 대부분의 대리인은 지나치게 많은 자원이 소모되면 일정한 규칙을 정해놓고 테이블의 열울 삭제한다. 이에 대한 명확한 표준은 없다.

2. RMON MIB

1) 통계(Statistics)
한 세그먼트내에서 발생한 패키/바이트 수, Broadcat/Multicast 수, 충돌(collision) 수 및 패킷 길이별 수 그리고 각종 에러(프래그먼트, CRCAlinment , jabber, 길이미달, 길이초과)에 대한 통계를 제공한다.

2) 이력(History)
관리자가 설정한 시간 간격내에 발생한 각종 트래픽 및 에러에 대한 정보를 제공한다. 기본적으로 단기/장기적으로 간격을 설정가능하고 1~3600초를 간격으로 제한다. 이 자료를 통해 시간대별 이용현황 및 다른 세그먼트와 비교가 가능하다.

3) 경보(Alarm)
주기적으로 특정한 값을 체크하여 기준치(임계치)에 도달하면 관리자에 보고하고 대리인 자신이 기록할 보유하고 있다. 기준치는 절대값및 상대값으로 정할수 있고 계속적인 경보발생을 막기 위해서 상/하한치를 설정해서 넘나드는 경우에만 경보를 발생하게 한다.

4) Host
세그먼트에 연결된 각 장비가 발생시킨 트래픽 , 에러수를 호스크별로 관리한다.

5) 상위 N개의 Host(HostTopN)
위 호스트 테이블에 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽을 발생시킨 호스트를 찾는다. 관리자는 원하는 종류의 자료(IN/OUT 패킷, 바이트, outErrors, broad/mutiCast 패킷)와 시간 간격 및 원하는 호스트의 갯수를 설정해서 정보를 얻을 수 있다.

6) 트래픽 매트릭스(Matrix)
Datalink layer, 즉 MAC ADDRESS를 기준으로 두 호스트간에 발생한 트래픽 및 에러에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은 이용자가 누구인지를 어느 정도는 알수 있다. 다른 세그먼트에 있는 호스트가 가장 많이 이용했다면 이것은 주로 라우터를 거치므로 실제 이용자는 알 수가 없다.

7) 필터(Filter)
관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다. 이를 이용해서 트정 패킷의 발생여부를 알 수 있고 경보와 사건(event) 기능을 이용해서 한계치 이상 발생시에 알 수가 있다.

8) 패킷 수집(Packet Capture)
세그먼트에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다. 관리자는 패킷의 전부 또는 일정한 길이만 보관하고 읽어올수 있도록 설정이 가능하다.

9) 사건(Event)
일저한 사건이 발생하면 그 기록을 보관하고 관리자에게 경고(trap) 메세지를 보낸다. 트랩발생 및 기록 보관은 선택적이다. 경보(alarm)와 연관되어서 사건이 발생하면 사건기록 및 트랩 발생은 관리자가 사전에 설정 가능하다.

3. RMON 자료 이용

1) 트래픽 동향분석
통계, 이력, 호스트, 호스트 메트릭스 그룹들을 통해서 얻은 정보를 바탕으로 특정 세그먼트나 특정 장비에 대한 각종 정보를 알수있다. 에러가 발생하는 상황이나 특정 시간대의 트래픽 분석 , 트래픽의 증가 속도등을 측정할 수 있다.

2) 주요 장비에 대한 트래픽 분석
특히 중요한 파일/프린터/메일 서버등에 발생하는 트래픽을 분석 가능하다. 물론 이런 장비는 독자적인 관리 기능을 갖추고 있으나 이 장비의 본래 기능은 아니다. rmon을 통하여 얼마나 많은 접근이 이루어지고 , 어느 호스트가 가장 많이 이용하는가를 알 수 있다. 이것을 서버가 직접 관리하면 많은 부하가 발생한다. 또 어느 시간대에 집중적으로 접근이 발생하는 지를 알 수 있다.

3) 사전 문제 발생 제거
에러나 collision등 Network 성능에 영향을 미칠수 있는 자료를 사전에 체크하여 문제가 발생하기 전에 조치를 취할 수 있게 한다.경보 및 사건 기능을 이용하여 한계치를 위험 수위별로 설정해서 관리하면 많은 도움이 된다.

4) Network 구성 변경 자료
통계 자료를 이용해서 Network의 이용효율을 측정해서 재배치하거나 또는 메트릭스와 HostTopN을 통하여 특정한 흐스트간의 사용빈도와 가장 트래픽이 심한 서버와 같은 host를 스위치같은 장비를 통해서 분리해서 동일한 사용간을 한 그룹으로 만들어서 대여폭을 높일수 있다. WAN 대역폭 등을 계산해서 회선 교환 및 증설을 검토할 수 있다.

5) 미지원 SNMP 장비에 대한 자료 이용
기존에는 SNMP를 지원하지 않는 장비에서 발생한 트래픽을 관찰할 방법이 별로 없었다. RMON은 OSI 데이타링크 레이어를 관리하기 때문에 상위프로토콜과는 무관하다. 그래서 망관리에 대한 기능이 없던 PC등이나 ip가 아닌 ipx등의 장비에 대한 트래픽도 충분히 관찰이 가능하다.

4. RMON2와 미래

기존에 발표된 RMON으로는 한 세그먼트에 대한 트래픽을 감시하는 데는 적합했다. 그러나 RMON은 MAC 게층까지만 분석이 가능하므로 어떤 프로토콜이 사용되는 지 그리고 어떤 애플리케이션이 Network에 영향을 주는 지는 거의 알수가 없었다. 결국 이런 점을 보완하기 위해서 등장한 것이 RMON2이다. RMON2는 최근에 표준으로 완성되어서 정식 문서로 배포되었다(RFC2021, RFC2074).

RMON2에 추가된 것은 프로토콜별 분포현황 , Network 계층 즉 IP, IPX, DECnet, AppleTalk 등의 호스트별 트래픽을 수집한다. Network 계층의 호스트간의 트래픽을 수집함으로써 애플리케이션, 웹서버와 같은 호스트에 가장 많은 트래픽을 발생시키는 호스트를 찾을 수도 있게 되었다. 그리고 애플리케이션 계층 차원에서 호스트별 트래픽을 감시 및 호스트간 트래픽을 관찰할 수 있다. 그이외에 많은 기능이 추가되었으나 자세한 설명은 RFC를 참조하면 된다.

RMON2가 발표되어서 Network 관리자는 이제 OSI 7 레이어 모두를 관찰할 수 있게 되었다. 그러나 이 모두를 구현하자면 대리인의 시스템 자원이 충분해야하고 성능이 대단해야 한다. 결국은 비용이 문제다. 이 모든 기능을 갖추려면 단독장비로 구성해야 한다. 그러나 요즘 Network 구성이 스위치를 이용해서 세그먼트를 분리하는 방향으로 나아가고 있다. 이때 스위치의 각 포트당 하나의 세그먼트가 되는 데 여기에 하나씩 RMON 대리인을 장착하기에는 비용이 문제다. 이를 해결하기 위해서 대부분의 스위치 장비가 RMON을 탑재하고 있으나 RMON과 RMON2의 모든 기능을 지원하기에는 스위치 본래의 기능에 악영향을 줄 수가 있다. 그래서 대부분 일부분만 지원할 수 밖에 없다.현재 대안으로 나온 것이 스위치의 각 PORT에 연결된 허브에 RMON을 탑재해서 해결하는 방안이다. HUB는 특별한 기능이 없어서 어느 정도는 가능하다.

출처 - http://www.hicore.com/

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 11:45


The Defense Advance Research Projects Agency (DARPA) originally developed Transmission Control Protocol/Internet Protocol (TCP/IP) to interconnect various defense department computer networks. The Internet, an international Wide Area Network, uses TCP/IP to connect government and educational institutions across the world. TCP/IP is also in widespread use on commercial and private networks. The TCP/IP suite includes the following protocols

Data Link Layer
ARP/RARPAddress Resolution Protocol/Reverse Address
DCAPData Link Switching Client Access Protocol

Network Layer
DHCPDynamic Host Configuration Protocol
DVMRPDistance Vector Multicast Routing Protocol
ICMP/ICMPv6Internet Control Message Protocol
IGMPInternet Group Management Protocol
IPInternet Protocol version 4
IPv6Internet Protocol version 6
MARSMulticast Address Resolution Server
PIMProtocol Independent Multicast-Sparse Mode (PIM-SM)
RIP2Routing Information Protocol
RIPng for IPv6Routing Information Protocol for IPv6
RSVPResource ReSerVation setup Protocol
VRRPVirtual Router Redundancy Protocol

Transport Layer
ISTP
Mobile IPMobile IP Protocol
RUDPReliable UDP
TALITransport Adapter Layer Interface
TCPTransmission Control Protocol
UDPUser Datagram Protocol
Van Jacobsoncompressed TCP
XOTX.25 over TCP

Session Layer
BGMPBorder Gateway Multicast Protocol
Diameter
DISDistributed Interactive Simulation
DNSDomain Name Service
ISAKMP/IKEInternet Security Association and Key Management Protocol and Internet Key Exchange Protocol
iSCSISmall Computer Systems Interface
LDAPLightweight Directory Access Protocol
MZAPMulticast-Scope Zone Announcement Protocol
NetBIOS/IPNetBIOS/IP for TCP/IP Environment

Application Layer
COPSCommon Open Policy Service
FANPFlow Attribute Notification Protocol
FingerUser Information Protocol
FTPFile Transfer Protocol
HTTPHypertext Transfer Protocol
IMAP4Internet Message Access Protocol rev 4
IMPPpre/IMPPmesInstant Messaging and Presence Protocols
IPDCIP Device Control
IRC·Internet Relay Chat Protocol
ISAKMPInternet Message Access Protocol version 4rev1
ISP
NTPNetwork Time Protocol
POP3Post Office Protocol version 3
RadiusRemote Authentication Dial In User Service
RLOGINRemote Login
RTSPReal-time Streaming Protocol
SCTPStream Control Transmision Protocol
S-HTTPSecure Hypertext Transfer Protocol
SLPService Location Protocol
SMTPSimple Mail Transfer Protocol
SNMPSimple Network Management Protocol
SOCKSSocket Secure (Server)
TACACS+Terminal Access Controller Access Control System
TELNETTCP/IP Terminal Emulation Protocol
TFTPTrivial File Transfer Protocol
WCCPWeb Cache Coordination Protocol
X-WindowX Window

Routing
BGP-4Border Gateway Protocol
EGPExterior Gateway Protocol
EIGRPEnhanced Interior Gateway Routing Protocol
HSRPCisco Hot Standby Router Protocol
IGRPInterior Gateway Routing
NARPNBMA Address Resolution Protocol
NHRPNext Hop Resolution Protocol
OSPFOpen Shortest Path First
TRIPTelephony Routing over IP

Tunneling
ATMPAscend Tunnel Management Protocol
L2FThe Layer 2 Forwarding Protocol
L2TPLayer 2 Tunneling Protocol
PPTPPoint to Point Tunneling Protocol

Security
AHAuthentication Header
ESPEncapsulating Security Payload
TLSTransport Layer Security Protocol

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 11:44
80년대에 한 대형 피자 체인점에서 “30분 내로 배달해드립니다”라는 광고를 한 적이 있다. 아마도 예상 시안 안에 피자를 받아본 경험들도 분명 있을 것이다. 피자는 25분, 27분, 혹은 가끔씩 31분에 배달되기도 하겠지만 그보다 더 오래 걸리지는 않을 것이라고 우리는 확신할 수 있다. 네트워크 QoS(Quality of Service)에도 몇 가지 예외만 제외하고는 같은 이론이 적용된다. 다른 점은 이 제품은 데이터이며, 속도가 가장 중요하고(분이 아니라 밀리 초로 계산되긴 하지만), 아무리 배달 기술이 좋다고 해도 제품의 품질을 보증할 수는 없다는 것이다.


불행히도 이더넷, IP 및 인터넷은 보증된 전달을 제공하거나 대역폭에 우선순위를 지정하는 것을 염두에 두고 나온 기술들이 아니다. 핑 응답 시간은 다양하며, 작업처리량도 일관성이 없고 네트워크는 가끔씩 너무 막혀서 세션이 가게 할 수조차 없을 때도 있다. 네트워크 자원들, 즉 사용 가능한 대역폭, 왠 이용, 최대 동시 세션, 라우터의 처리 능력 등은 언제나 제한적이다. 기업들은 대역폭 부족 때문이 아니라 과도한 웹 사용의 결과로 지사로의 VPN 연결이 참을 수 없이 느려지는 것을 목격할 수 있다. 학교들은 7월에 빨랐던 네트워크가 신입생들이 다이얼업이 없는 생활을 발견하게 되는 9월이 되면 딱할 정도로 느려지는 것을 경험하곤 한다.


QoS, 존재의 이유

>> 대기시간(latency)은 패킷이 한 곳에서 다른 곳으로 갈 때 걸리는 시간으로 대역폭 포화, 네트워크 장비의 자원(CPU나 램) 부족, 접속 거리나 종류 등에 따라 야기될 수 있다. QoS를 이행하면 이런 대기시간을 크게 줄일 수 있다.

>> 지터(jitter)는 대기시간에서의 변동을 뜻한다. 두 개의 노드가 같은 스위치에 있지 않으면 대기시간은 패킷마다 크게 달라질 수 있다. 네트워크 대역폭이 포화 상태가 되면 지터는 늘어난다. 파일 다운로드나 웹 브라우징과 같은 애플리케이션의 경우는 이것이 늘 큰 문제가 되는 것은 아니다. 하지만 스트리밍 비디오와 VoIP는 높은 지터로 인해 크게 고통을 받는다. QoS는 스트리밍 트래픽에 보다 높은 대역폭 우선순위를 제공함으로써 지터를 줄이는 데 도움이 될 수 있다. 또 한 가지 해결책으로 버퍼 크기를 늘리는 방법이 있다.

>> 랜덤 패킷 유실은 네트워크나 장비가 과포하 상태일 때 발생하며, 스트리밍 미디어 잘림 현상과 접속 리세트 및 유실, 그리고 다른 트랜잭션 문제를 야기한다. 더 나쁜 것은 유실된 패킷은 재전송이 되어야 하기 때문에 문제가 더 커진다는 사실이다. QoS 방안은 프로토콜이나 접속이 사용하는 대역폭 양을 제한할 수 있기 때문에 과포하를 방지, 혹은 제한해준다.

>> QoS를 이용해야 하는 마지막 이유는 대역폭 사용 제어다. FTP와 스트리밍 비디오와 같은 트래픽은 냅킨이 페페로니 피자 기름을 흡수하는 것처럼 대역폭을 빨아들일 수 있다. P2P 파일 공유는 대부분의 대학 캠퍼스에서 문제를 일으켰으며, 어떤 캠퍼스 네트워크는 P2P 트래픽만으로도 100% 포화상태가 되기도 했다. 기업 네트워크는 원격 제어 소프트웨어가 웹 서버의 응답성을 느리게 한다는 사실을 알게 될 것이다. 회사 이미지상 빠른 웹 서버 응답성이 중요할 경우에 이것은 문제가 된다.

대역폭을 제어할 수 있는 능력은 특히 할 수 있는 일이 많지가 않을 때 중요하다. QoS는 시트릭스(Citrix)나 네트워크 관리 작업, 혹은 데이터베이스 질의 등과 같은 기간 업무 애플리케이션들에게 우선순위를 주면서 나머지는 덜 중요한 활동을 위해 남겨둔다.

웹 브라우저가 네트워크에 끼칠 수 있는 손실을 결코 과소 평가해서는 안 된다. 대부분의 QoS 장비들이 프로토콜마다 최소 및 최대 속도를 지정할 수 있게 해주지만, 고급 제품들은 세션당 최소 및 최대 속도를 지정할 수 있게 해준다. 예를 들어 개별적인 모든 스트리밍 비디오 세션이 최소 100Kbps를 얻으면서 포함된 전체 스트리밍 비디오 세션은 1Mbps 이상을 사용할 수 없게 할 수도 있다. 특정 사용자에게 선호하는 상태를 주기 위해 QoS를 사용할 수도 있다.


레이어 4냐, 레이어 7이냐

QoS 이행을 고려할 때는 하이 레벨 점검을 할 수 있는 제품이 필요한지 여부를 결정해야 한다. QoS는 주로 레이어 OSI 모델의 레이어 4나 레이어 7에서 작동한다.

레이어 4에서는 포트 번호와 IP 어드레스만이 점검된다. 프로토콜이 자체 포트로 매칭되던 좋았던 시절에는 별 문제가 되지 않았지만 오늘날에는 대부분의 방화벽들이 조직 내 임의의 기계에서 포트 80을 통과하도록 트래픽을 허용하기 때문에, 사용자들은 스트리밍 비디오를 지켜보고, 웹 메일을 사용하며, P2P 서비스를 돌리고, 웹 페이지를 보고, SSH 접속을 터널링할 수 있다. 그리고 이 모든 것들이 포트 80을 통한다. 이런 수많은 활동들은 일반 HTTP나 암호화된 HTTPS를 사용할 수 있으며, 이것은 일부 콘텐츠 필터들을 혼란스럽게 할 것이다.

사용자가 자기 기계를 연결하거나 승인받지 않은 소프트웨어를 설치하려 하지 않는 폐쇄된 환경에 있을 경우에는 레이어 7 능력이 결정적이지 않을 수도 있다. 반면 대학 캠퍼스에서는 앞서 말한 하이 레벨 점검을 다시 생각해볼 필요조차 없다.

레이어 7 지원 QoS 장비를 선택하지 않으면 다른 멋진 기능들은 놓쳐버리게 될 수도 있다. 예를 들어 시타라의 QoS웍스(QoSWorks)는 HTTP 콘텐츠 유형을 기반으로 트래픽을 식별할 수 있다. 보다 빠른 HTML 텍스트 전송기를 허용하기 위해 이미지나 탑재된 멀티미디어 파일의 속도를 제한할 수 있다. 일부 레이어 7 장비들은 또한 HTTP 프로토콜을 사용하는 세션이 웹 페이지를 전달하거나 MP3를 다운로드하고 있는지 여부를 탐지할 수도 있다. 아마도 이런 두 가지 기능을 위해서는 별도의 정책을 두고 싶을 것이다.

레이어 4냐, 레이어 7이냐를 떠나서 QoS 모델을 선택할 때는 기본적인 것에 충실해야 복잡해지지 않을 수 있다. 간단하게 시작해 보자.


무조건 더 많이

네트워크 자원 부족 문제에 직면하게 되면 가장 쉬운 해결책은 과도하게 설비하는 것(overprovision)이다. 더 많은 대역폭이 필요한가? 두 번째 T1을 설치하라. 라우터가 패킷을 유실시키는가? 램을 업그레이드하라. QoS에 비하면 게으른 사람의 대답처럼 들릴지는 모르겠지만, 오버프로비저닝은 유효하며 가끔씩 필요한 방법이기도 하다. 예를 들어 캠코더 DV(Digital Video) 스트림은 802.11b에서 실시간으로 전송할 수가 없다.

소비자 품질의 DV는 25~36Mbps에서 돌아가는데 802.11b는 11Mbps로 운영되기 때문이다(실제로는 4~6Mbps밖에 되지 않는다). 128Kbps ISDN 회선을 갖고 있고 100개의 동시 VoIP 세션을 8Kbps에서 돌리고 싶다면 아무리 QoS를 완전하게 한다고 해도 해결이 되지 않는다.

나아가 라우터, 방화벽 및 기타 네트워크 인프라 장비에서 어떠한 QoS 방안을 시행할 경우에는 프로세싱 파워와 램이 소모되며, 이는 어쨌거나 더 강력한 장비를 사야 하게 만드는 것이다.

다만 전문 QOS 기술을 사용하는 것보다 설비에 더 많은 돈을 지출하지 않도록 조심해야 한다. 예를 들어 월 150달러가 드는 1.5Mbps DSL 접속이 있는 지사가 있다고 하자. 웹 트래픽이 너무 느려서 대역폭 부족에 대한 사용자들의 불만을 듣느니 차라리 듀얼 접속으로 업그레이드를 하려고 할 수 있다. 이럴 경우 먼저 트래픽을 분석해야 한다. 스트리밍 인터넷 라디오와 같은 사소한 것들이 범인일 수도 있기 때문이다. QoS를 이용해 스트리밍 오디오를 줄이거나 제거함으로써 이 지사는 실제로 연간 1천800달러를 절약할 수 있었다.

대역폭을 절약할 수 있는 또 한 가지 방법은 압축 기술을 이용하는 것이다. 그래픽은 자체 해상도나 컬러 심도를 줄일 수 있고 비디오는 MPEG나 DivX와 같은 효율적인 코덱을 이용해 압축될 수 있다. 그리고 오디오는 보다 낮은 비트로 인코딩되거나 스테레오를 모노로 바꿀 수 있다. 이런 로시(lossy) 압축 방안은 품질이 눈에 띌 만큼 떨어지지 않을 때까지만 취해질 수 있다.

여기에 대한 한 가지 대안으로 zip나 gzip, 혹은 알라딘 스터핏(Aladdin Stuffit)과 같은 로스리스(lossless) 방안을 사용할 수도 있다. 로스리스 압축은 품질을 떨어뜨리지는 않지만 파일 크기를 크게 줄이지도 못한다. 나아가 로스리스 압축은 JPEG나 MP3, 혹은 비디오 파일들처럼 이미 압축된 데이터에는 효율적이지 못하다.

또 한 가지 베스트 프랙티스로 웹 서버에서의 HTTP 압축 실행이 있다. 압축은 HTTP 1.0에서 정의되었지만 클라이언트 지원에 대해서는 옵션으로 남아있었다. 반면에 HTTP 1.1 클라이언트는 압축 지원에 요청된다. HTML은 효율적으로 압축을 했는데, 8GB의 텍스트를 한 장의 표준 CD에 담아본 적도 있다. 이 방법의 유일한 약점은 HTTP 압축이 CPU 오버헤드를 부과한다는 것이다.

익스팬드 네트웍스(Expand Networks), 패킷티어(Packeteer), 그리고 페리비트 네트웍스(Peribit Networks)는 모두 지사의 인터넷 라우터 뒤에 배치되어 이들을 통과해 흐르는 모든 트래픽을 자동으로 압축해주는 사이트간 압축 어플라이언스를 판매하고 있다. 물론 연결의 각 종단 지점에는 압축 어플라이언스가 있어야 하며, 어플라이언스들 사이로 보내지는 트래픽은 압축되지 않는다. 그러나 이런 장비들은 저렴하며 왠 회선을 극대화해줄 것이다.

이런 간단한 방법들이 모두 만족스럽지 못하다면 이제 좀더 공을 들일 시간이다.

QoS 확보 기술

인터넷 상에서 이동하는 데이터와 달리 랜 전용 트래픽은 다양한 서브넷들간에 QoS 정책을 받을 만하다. 트래픽은 클래스로 분리되며, 이런 클래스는 프로토콜, IP 범위나 MAC 어드레스, 그리고 플로우(flow) 등을 나타내는 것일 수 있다. 대부분의 시스템들은 완전한 하나의 TCP 세션을 하나의 플로우라고 한다. 웹 사용자가 TCP 3방향 핸드쉐이크(three-way handshake)와 HTTP 전송을 수행한 다음 끝으로 세션을 닫을 때 이 모든 트래픽은 동일한 플로우의 일부로 간주된다. QoS 장비는 하나의 클래스 전체에 정책을 적용시키기도 하고, 개별 플로우에 적용시키기도 하며, 혹은 두 가지를 다 하기도 한다.

QoS를 얻기 위해서는 ToS(Type of Service) 비트를 바꿔야 한다. ToS는 8비트로 구성돼 있으며 IPv4 헤더의 9번째 비트와 16번째 비트 사이에 위치한다. ToS 필드의 비트 0과 1, 그리고 2는 패킷의 상대적 우선순위를 0~7까지 숫자로 나타내는 데 사용될 것이다. 비트 3은 정상적이거나 낮은 지연을 가리키며, 비트 4는 정상적이거나 높은 작업처리량, 그리고 비트 5는 정상적이거나 높은 신뢰성을 가리킨다. RFC는 패킷이 이 세 가지 옵션들 중에서 두 개까지만 사용하도록 규정하고 있다. 비트 6과 7는 앞으로의 사용을 위해 예비된다.

이런 정보로 무엇을 할지에 대해서는 공식적인 지침서가 없다. 네트워크는 우선순위가 높은 트래픽을 위해 낮은 트래픽은 유실시키는 책임을 맡게 된다. 우선순위가 같은 트래픽은 더 차별화될 수 없으며, 네트워크 제어 트래픽(RIP나 ICMP 메시지 등)은 언제나 가장 높은 우선순위를 차지하기 때문에 사실상 유효한 것은 6 단계밖에 없는 셈이다.

시스코시스템즈에 따르면, 불행히도 비트 3~5는 네트워크 업체들간에 일관성있게 이행되지 않았다고 한다. 게다가 설상가상으로 RFC 1349는 비트 3~6을 10년이 지난 후 지연의 최소화, 작업처리량의 최대화, 신뢰성 최대화, 금전적 비용의 최소화, 혹은 정상적 서비스 등 5가지 분류로 다시 지정했다. 우리는 단 하나만 선택할 수 있었으며 이들 중 어떤 것도 대역폭 용량을 보장해주지는 못했다. IPv6는 ToS 옥테트(octet)를 버리고‘트래픽 클래스’ 옥테트를 선택했다.

ToS 비트를 사용하는 것은 종종 ‘컬러링(coloring)’으로 표현되는데, 오래되긴 했지만 아직도 많은 서비스 사업자들이 브론즈, 실버, 골드, 다이아몬드, 그리고 플래티넘 서비스 레벨이란 말을 사용하고 있다. ToS는 아직도 가끔씩 사용되긴 하지만 랜에서는 거의 사용되지 않는다.

인티그레이티드 서비스(Integrated Services), 즉 인트서브(IntServ)는 네트워크에 있는 모든 라우터가 인터서브를 지원하고 존중하는 한 사용 가능한 대역폭 수준을 보장함으로써 종단간 QoS를 제공할 수 있다.

QoS 레벨로는 두 가지가 제공되는데, 하나는 서비스 보증(guaranteed service)이고 하나는 부하 제어(controlled load)다. 서비스 보증 레벨은 일정량의 대역폭이 사용 가능하도록, 그리고 큐잉 패킷의 계정에서 추가 지연이 없도록 보장해 준다. 네트워크를 오버프로비저닝한다고 하더라도 인터서브는 역시 서비스 보증 레벨을 지킬 수 있도록 보장해줄 것이다.


ToS 비트 바꿔야

부하 제어는 부하가 가벼운 네트워크에서 전통적인 IP 트래픽처럼 작동한다. 즉 베스트 에포트(best-effort) 기반으로 일이 진행되며 어떠한 강력한 보증도 없다. 비 인터서브 트래픽은 나머지 것들로 남게 된다.

종단 호스트는 RSVP(Resource Reservation Protocol; RFC 2205)를 내보냄으로써 인트서브 QoS 세션을 초기화한다. RSVP는 네트워크에서 자원 예비를 요청하는 시그널링 프로토콜이다. 네트워크는 모든 연결이 요청을 만족시킬 수 있는지 여부에 따라 요청을 승인, 혹은 거절할 것이다. 승인될 경우 대역폭은 예비된다. 각각의 라우터에는 모든 인트서브 세션에 대한 상황 테이블이 있다. 원래의 송신자가 오류가 나거나 접속을 상실하게 되면 인트서브 세션은 타임아웃이 되고 예비는 취소된다.

인트서브에서 한 가지 문제는 전체 네트워크에서 상태를 유지해야 한다는 것이다. 이것은 라우터에게 제한된 CPU와 램 자원이라는 부담을 지운다.

그리고 종단 지점을 포함해 패킷의 경로에 있는 모든 장비들이 인트서브를 이해해야 한다. 실제로 인트서브는 소규모 네트워크에서 사용돼 왔지만 분산, 혹은 대형 네트워크에서는 인기를 끌지 못했는데, 그것은 바로 확장성에 대한 염려 때문이다.

디프서브(Differentiated Services; RFC 2475)는 인트서브와 ToS의 단점을 얼마간 해결했다. 디프서브는 보다 확장성이 있으며, 정확히 이행될 경우 다중 네트워크에서 작동할 수 있다. IPv4 패킷에 있는 처음 6개 ToS 비트나 IPv6 패킷에 있는 트래픽 클래스 옥테트를 DSCP(Differentiated Services Codepoint; RFC 2474)라고 하는데, DSCP는 자그마치 64개나 되는 클래스를 지원한다.

네트워크는 ‘디프서브 구름’이라고 일컬어지는 디프서브 라우터 집합을 형성할 것이다. 트래픽은 이 구름으로 들어갈 때 분류가 나뉘어진다. 사업자는 언제나 고객과 협상을 해서 서비스 수준 협정을 만들 것이다. 예를 들어, 한 회사에서 한 ISP의 브론즈, 실버, 혹은 골드 패키지에 가입할 수 있으며, 이 회사에서 하는 계약에 따라 디프서브 우선순위 세팅이 결정될 것이다.

디프서브의 가장 큰 이점은 이것이 경계선에서 작동한다는 것이다. 일단 데이터가 구름 속으로 들어가면 내부의 라우터는 QoS 상태 정보를 보유할 필요가 없으며, 따라서 내부 라우터가 라우팅에만 전념할 수 있게 된다.

하지만 디프서브는 여전히 예측 불가능하다. 개별적인 내부 라우터들은 ToS 필드에 대해 이상하게 반응하거나 경보를 낼 수도 있다. 어떠한 정해진 표준도 없으며, 한 사업자의 골드 기준이 다른 사업자의 브론즈 기준이 될 수도 있다. 따라서 최고의 서비스를 위해 돈을 지불한다고 생각하지만 ISP의 피어링 협정은 다른 얘기를 하고 있을 수도 있다. 디프서브는 포화도가 높은 기간 동안 패킷을 선택적으로 유실시킴으로써 작동하기 때문에 가장 낮은 클래스 회원들은 버스트 동안 몇 초간은 접속이 완전히 끊길 수도 있다.

디프서브는 인트서브보다 오버헤드가 낮고 확장성이 좋기 때문에 보다 큰 랜이나 왠에서 잘 작동할 수 있다. 디스퍼브의 등급 분류는 구름의 입구에서 이루어지므로, 종단 노드와 그 사이의 라우터들은 디프서브 비트를 이해하거나 설정할 필요가 없다.


트래픽 쉐이퍼

트래픽 쉐이퍼(traffic shaper)는 QoS의 정점이며, 가끔씩 두 용어가 서로 바뀌어 사용되기까지 한다. 이 범주에는 앨럿 커뮤니케이션즈(Allot Communications), 라이트스피드 시스템즈(Lightspeed Systems), 패킷티어(Packeteer) 및 시타라 네트웍스(Sitara Networks)의 제품들이 포함돼 있으며, 이들은 QoS와 심도 깊은 패킷 점검, 등급 분류 및 트래픽 보고 등을 수행한다. 이런 제품들은 디프서브와 ToS 세팅을 살펴봄으로써 데이터의 등급을 분류할 수 있지만 이런 기술에 의존하지는 않는다. 그리고 이런 장비는 독립형 어플라이언스로 작동하기 때문에, 네트워크 나머지 부분에서 구성 변경이나 상호운용성 문제를 경험할 필요가 없다.

이들 제품은 내부 랜 트래픽을 쉐이핑하는 데도 이용이 가능하긴 하지만 전통적으로 네트워크 에지에 놓인다. 대부분은 레이어 7에서 작동함으로써 ‘포트 80을 통해 모든 것을 돌리면 아무도 이것을 알려주지 못할 것’이라는 신드롬을 해결해준다. 이 문제는 원치 않는 프로토콜과 같은 포트에서 돌아가는 프로토콜(HTTP라고 하자)에 대한 정책을 설정하고 싶을 때 발생한다. 레이어 7 장비는 포트 80으로 가려는 트래픽이 HTTP나 P2P, 스트리밍 비디오, 혹은 HTML이나 JPG 전송기일 경우 알려줄 수 있다.

트래픽 쉐이퍼들은 보통 며칠동안 모니터 전용 모드로 설치된다. 때문에 네트워크를 가로질러 가는 트래픽이 어떤 것인지, 그리고 무엇이 가장 많은 대역폭을 차지하고 있는지를 확인할 수 있으며, 트래픽 쉐이퍼의 보고 툴은 아마도 이들의 가장 소중한 자산일 것이다.

정의와 사양이 업체마다 다르긴 하지만, 트래픽 쉐이퍼에는 몇 가지 공통된 기능들이 있다. 트래픽은 클래스(프로토콜이나 서브넷 등)나 플로, 혹은 둘 다를 기반으로 쉐이핑된다. 그리고 버스트뿐만 아니라 최소 및 최대 대역폭의 설정도 가능하다.

버스트는 별도의 대역폭이 사용 가능할 경우에만 허용된다. 예를 들어 FTP 10Mbps를 정상적일 때는 FTP 10Mbps를 할당하고, 대역폭이 사용 가능할 때는 15Mbps까지 버스트를 할당할 수 있다. 하이엔드 쉐이퍼에는 ‘모든 VoIP 세션용으로 8Kbps를 허용하지만 VoIP가 1Mbps만 사용하도록 하라. VoIP가 1Mbps를 사용중이면 새로운 VoIP 세션은 하나도 허용하지 말라’와 같은, 다소 진보된 명령어들을 줄 수도 있다.

큐잉이냐 창이냐

트래픽 쉐이퍼들은 패킷을 큐잉하거나 TCP 창 크기를 조작함으로써 작동한다. 큐잉을 사용하는 업체들은 대기열로 인해 TCP가 자동으로 스스로 작아지기 때문에 TRS(TCP Rate Shaping)는 불필요하고 자연스럽지 못하며 IETF에서 규정한 것도 아니라고 주장하고 있다.

TRS는 또한 UDP(User Datagram Protocol) 트래픽을 처리하지도 못한다. 이것은 하지만 사소한 일인데, 그 이유는 TRS를 사용하는 트래픽 쉐이핑 업체는 어느 곳이든 제 2의 큐잉 기반 알고리즘을 이행해 UDP를 처리할 것이기 때문이다. 앨럿과 라이트스피드는 모두 큐잉 트래픽 쉐이퍼를 만들고 있다.

TRS는 TCP 제어 데이터와 창 크기를 조작함으로써 작동하며, TCP 세션을 훨씬 더 느린 회선에 있는 호스트와 커뮤니케이션을 하는 것처럼 믿게 만든다. 모뎀 사용자가 T3에 있는 서버에 접속할 경우 이와 유사한 쉐이핑이 당연히 발생할 것이다.

TRS 업체들은 큐잉이 대기시간을 추가하고, 더 많은 패킷 유실을 가져오며, 수신 트래픽을 느리게 하는 것 만큼 좋지가 않다고 주장하고 있다. 패킷티어와 시타라는 모두 TRS를 사용하는 업체들이다.

큐잉 업체들이 다룰 수 있는 주요 기술들로는 다음과 같은 네 가지가 있다:

>> PQ(Priority Queuing)는 ToS와 유사한 방식이다. 우선순위가 높은 대기열이 낮은 대기열에 앞서 송신하며, 이는 즉 우선순위가 가장 낮은 대기열은 굶어죽을 수도 있다는 얘기다.

>> CBQ(Class-Based Queuing)는 PQ에서의 기아 문제를 어느 정도 해결했다. 클래스는 최소한의 대역폭을 갖도록 구성될 수 있으며, 가능할 경우 다른 클래스에서 대역폭을 빌려올 수도 있다.

>> WFQ(Weighted Fair Queuing)은 우선순위 레벨을 기준으로 대기열 크기를 늘리거나 줄여준다. 여기서 대역폭 이용도는 참작되지 않는다.

>> HWFQ(Hierarchical Weighted Fair Queuing)은 실시간 트래픽을 기반으로 다양한 트래픽 상황 하에서 최악의 경우 패킷 지연을 평가하며, 대기열 평가에 이 데이터를 사용한다.

큐잉 대 속도 쉐이핑의 논쟁은 수년 동안 계속돼 온 것이지만, 사실 관리 인터페이스, 보고 품질, 그리고 성능은 기반 기술보다도 SUB의 문제라는 게 우리 생각이다.


단기적 이행도 유용

QoS 이행이 꼭 어렵거나 지나치게 시간 소모적인 것은 아니지만 너무 힘들게 하다보면 그렇게 될 수도 있다. 절대적으로 필요한 애플리케이션들을 선택하고, 이들이 충분한 네트워크 자원을 언제나 확보하고 있는지를 확인하라. 아니면 그냥 최악의 범죄자들을 제한하라.

이 글의 결론은 성능 부족을 바로 더 많은 대역폭에의 필요와 연관짓지 말라는 것이다. 무료로 라우터에서 QoS를 지원함으로써 만족스러운 결과를 얻을 수 있을 때 굳이 기가비트 이더넷으로 이동할 이유가 없다. QoS는 최소한 다음 구매 사이클 때까지 네트워크가 가동되도록 유지하기 위해 단기적으로 사용될 수도 있다.




===== 랜과 왠에서의 QoS =====

궁극적으로 진정한 QoS는 네트워크의 경계선만큼만 확장될 수 있기 때문에 사실상 인터넷 라우터에서 중단된다. ISP와 인터넷 백본 사업자들은 QoS 방안을 존중할 필요가 없기 때문에 사실 이들이 QoS를 간단히 무시해버리는 것도 충분히 예상할 수 있는 일이다.

그렇다면 QoS를 이행해야 할까, 아니면 그냥 대역폭을 더 사는 게 나을까.

‘더 많은 대역폭을 사는 게 좋다’는 논거는 간단하다. 즉 대역폭은 저렴하고 QoS는 복잡하다는 것이다. 용량이 충분하다면 QoS는 의미가 없다. 인터넷은 용량 면에서 계속 성장하고 있으며, 기술적인 진보는 네트워킹 속도를 지속적으로 향상시키고 있다.

이 주장은 왠 쪽 보다는 랜 쪽에서 더 잘 적용된다. 기가비트 이더넷은 가격이 적당하며 대부분의 시스템들은 이것을 포화 상태로 만들기 힘들기 때문에 10기가비트 이더넷은 말할 것도 없다. 하지만 왠 속도는 그렇듯 적당한 가격에서 향상되지 않았으며, 인터넷 접속이 최소한 하루 몇 시간 동안 포화 상태에 있는 것을 쉽게 볼 수 있다.

QoS 기능은 이제 포티넷(FortiNet)의 포티게이트(FordiGate)와 같은 다용도 보안 제품과 VPN 게이트웨이 및 라우터 등 많은 인프라 제품에서 무료로 제공되고 있다.

무제한 공급 모델에서 가장 간과하기 쉬운 문제는 여분의 대역폭이 있을 경우 누군가 이것을 사용하게 될 수 있다는 것이다. 이것은 마치 교통 시스템과 같다. 1930년대 뉴욕시에서는 기존 구간에서의 정체를 완화하기 위해 두 개의 다리를 만들었다. 다리가 완성되고 난 후 늘어난 수용량에도 불구하고 정체는 이 프로젝트가 시작되기 전이나 다를 게 없었다.

공유, 음악 교류 및 P2P의 급증으로 인해 대역폭은 더 이상 무한대라는 말이 어울릴 수가 없게 되었다. 웹페이지도 또한 점차 부풀어가고 있다.

콘텐츠 필터로 중요하지 않은 다운로드들을 차단할 수도 있다(사용자가 콘텐츠 필터가 쉽게 암호화된 HTTPS 트래픽을 차단할 수 없다는 사실을 알 만큼 현명하지 못하다는 전제하에). 하지만 수용 가능한 사용 정책을 따르는 트래픽이라 하더라도 파괴력을 행사할 수 있다. 즉 100명의 수신자에게 전송되는 5MB 첨부 파일도 얼마간의 손상을 입힐 수 있다. 웹 서버에 접속하는 사용자들은 DSL 사용자들에게서 모든 대역폭을 앗아가 버릴 것이다. QoS는 모든 사용자가 사이트에서 동등한 경험을 하도록 보장해줄 수 있다.

일부 조직에서는 웹 로그 파일에 대해 웹사이트 분석 툴을 실행하고 있다. 이런 파일들은 여러 기가비트로 구성될 수 있기 때문에 웹 서버에서 FTP로 이들을 다운로딩하는 데 너무 많은 대역폭을 써서 정작 중요한 SQL 룩업에는 거의 대역폭이 남지 않을 수도 있다.

그리고 VoIP가 있다. 독자들은 VoIP 파일로트가 많은 IT 관리자들의 아젠다란 얘기를 한다. 당신도 마찬가지라면 QoS가 필요할 것이다. 대역폭 포화 기간이 아무리 짧다고 하더라도(몇 초밖에 되지 않더라도) 전화 통화에서는 단절이 일어날 수 있다. VoIP 호출이 POTS 호출만큼이나 상태가 좋다는 보증이 없이는 경영진이 VoIP 배치를 승인하도록 만들기가 힘들 것이다.

=================================================================

Executive Summary

Quality of Service

완전한 세상이라면 QoS는 인터넷에 처음부터 구축되었을 것이며, 그랬더라면 일관성 없는 대역폭 이용, 지터 대기시간, 패킷 유실, 그리고 탐욕스러운 애플리케이션들로 인해 걱정할 필요도 없었을 것이다.

하지만 세상은 완전하지 않으며, 따라서 VoIP(Voice over IP)와 같은 스트리밍 미디어에 대해서는 정량의 대역폭뿐만 아니라 낮고 일정한 대기시간을 보장해야 한다. FTP나 웹 트래픽과 같은 애플리케이션들은 대기시간에 민감하지 않을지 모르지만, 이들은 미친 듯이 대역폭을 먹어치울 수 있다. 과포화된 네트워크는 패킷 유실과 비효율적인 데이터 전송을 가져오고 사용자를 아우성치게 만든다.

QoS는 몇 가지 방법으로 확보될 수 있다. 압축을 지원하고 더 많은 대역폭을 구입하는 게 가장 간단한 방법이지만, 지연만은 피해갈 수 없을 것이다. 사용자 파이프를 막히게 하지 못하게 할 수 있는 보다 효과적인 방법은 ToS(Type of Service), 인티그레이티드 서비스(Integrated Services), 디퍼런시에이티드 서비스(Differentiated Services), 큐잉, 혹은 TCP 속도 쉐이핑(TCP rate-shaping) 등을 이용하는 것이다. 이들 중에서 인터넷을 가로질러 전송되는 데이터를 제어하는 데는 뒤의 두 가지만이 효과적이다. 나머지는 내부 랜 QoS나 서비스 협정을 맺은 파트너들간에 사용하기에 가장 좋다.

부족할 때는 언제든 더 많은 대역폭만 사면된다는 식의 생각을 해서는 안 된다. 몇 가지 간단한 QoS 정책을 이행함으로써 기간 업무 프로토콜을 존중하면서 대역폭에 목말라하는 애플리케이션을 달랠 수 있다. 그리고 QoS 능력은 네트워크 인프라의 많은 조각들에서 지원되고 있기 때문에, QoS 시행 비용은 최소화될 수 있을 것이다.
Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 01:17

1. GLBP란..

Cisco 전용 프로토콜로써, MHSRP와 MVRRP에 단점을 보안하여 효울성있게 각각 Host들에게 로드밸런싱을 하여 보내는 방식이다. 라우터들 사이에서 패킷 Load Sharing을 수행하고 동시에 백업라인구성으로 라우터 장애에 대비하게 된다.

2. GLBP Supported Platforms.

Cisco 1700 Series, Cisco 2600 Series, Cisco 3620, Cisco 3631, Cisco 3660, Cisco 3725, Cisco 3725, Cisco 3745, Cisco 7100 Series, Cisco 7200 Series, Cisco 7400 Series, Cisco 7500 Series.


3. GLBP의 개념.

- IEEE 802.3 LAN에서 단일 게이트웨이로 구성된 IP Host들을 위한 자동 라우터 백업을 제공.

- GLBP는 단일 Virtual IP 주소와 여러 개의 MAC주소를 사용하여 여러 라우터에게 Load Balancing 을 제공.

- Host들은 같은 Virtual IP 주소로 설정되고, Virtual Router 그룹 내에 모든 라우터들은 동시에 패킷 스위칭이 가능.


4. AVG(Active Virtual Gateway)

- GLBP 그룹내에 하나의 AVG는 선출되어야 되고, 선출 방법은 HSRP와 VRRP처럼 우선순위가 가장 높은 라우터가 AVG가 되며 그다음 높은 우선순위 라우터가 STandby AVG가 된다. 만약, 같은 우선순위일때는 높은 IP주소를 가지는 라우터가 선출이 된다.

< GLBP의 우선순위 설정 >

// 설정하고자하는 인터페이스 모드에서.. //

Switch(Config-if)#glbp group Priority level Group Number: 0~1023, Priority: 1~255(가장높은값: 255, Default:100)


- AVG는 같은 GLBP 그룹내에 라우터에게 Virtual Mac 주소를 각각 할당.

- 하나의 GLBP 그룹에는 최대 4대의 라우터가 존재 가능.

- PC혹은 서버와 AVF간의 중개자 역할 수행.

- HSRP처럼 현재 Active라우터가 죽을때까지 다른하나의 라우터가 Active상태로 될수 없지만, 현재 AVG의 우선순위보다 더 높은 우선순위를 갖는 라우터가 있다면 Preempt명령어로 Active상태 전환을 허용함.

< Standby AVG에서 Active AVG라우터로의 변환 설정 >

Switch(config-if)#glbp group preempt [delay minimum seconds] []안은 생략 가능함을 말함.


5. AVF(Active Virtual Forwarder)


- AVG로부터 Virtual Mac주소를 할당받은 라우터.

- GLBP는 라우터가 같은그룹내에서 하나의 Virtual Mac 주소를 가진 AVF를 결정하기 위해서 WEIGHT 기능을 사용. 각각의 라우터는 최대 WEIGHT 값(1~254)으로 시작. 특정 인터페이스가 다운이 될때, 그 WEIGHT값은 설정된 값 만큼 감소.

- GLBP는 한 라우터가 AVF가 될때와 AVF가 될수 없수을때 한계치(threshold)를 사용.  만약, 그 WEIGHT값이 낮은 한계치 아래로 떨어진다면, 그 라우터는 AVF역할은 포기. WEIGHT값이 좀 높은 한계치 위로 올라간다면, 그 라우터는 AVF역할을 다시 시작할수 있다. (Default WEIGHT는 100)

- 동적 웨이팅 조정을 원한다면 GLBP는 그 WEIGHT를 조정하기 위한 방법과 이동하기 위한 인터페이스를 알아야 함.


< 이동 되는 인터페이스에서 동적 웨이팅 설정 >

Switch(config)#track Object-number interface type mod/num {line-protocol | ip routing}
Object-number는 WEIGHT 조정을 위해 사용되어지는 임의의 값.(1~500)

조정을 일으키는 조건은 Line-Protocol(인터페이스 line-protocol이 UP인 상태) 혹은 Ip routing(IP Routing이 활성화 되어져 있어야하고, 인터페이스에는 IP가 할당되고 UP이어야한다.) 될수있다.


< GLBP 인터페이스에 한계치 설정 >

Switch(config-if)#glbp group weighting maximum [lower lower] [upper upper]
Maximum weight: 1~254(Default: 100) upper과 lower 한계치는 그 라우터가 AVF가 될수 있을때와 될수 없을때 각각 정의해준다.


< 인터페이스 모드에서 웨이팅값이 조정되어지기 위한 이동을 하기위해 어느 objects인지 알기 위해 GLBP를 설정 >

Switch(config-if)glbp group weighting track object-number [decrement value]
이동 되는 object가 실폐를 할때, 그 웨이팅은 decrement value만큼 감소 되어짐.
(1~254 Default:100)

- Host들은 통신을 하기 위해 MAC 주소를 알아야 한다. Host가 ARP로 요구를 하게 되면 한 라우터의 Virtual Mac 주소를 갖게 되고 Virtual IP를 받아 Host의 ARP 테이블에 등록을 시켜 놓는다.

(각각의 Host는 같은 가상 Ip를 같지만 가상 Mac은 서로 다를수 있다. 이것은 밑에 설명할 GLBP의 로드밸런싱에 따라 달라지게 된다.) Host는 ARP 테이블을 참고하여 하나의 AVF를 선택하여 통신하게 된다.


6. GLBP 로드밸런싱 방법

AVG는 결정론적의 구조에서 클라이언트들로 가상 라우터 MAC 주소를 분배해주는것에 의해 로드밸런싱을 설립한다.  당연히 AVG는 각각의 가상 MAC 주소를 사용하는 그룹안에 AVF들에게 먼저 알려준다. 순차적인 순서로 할당되어진 네개의 가상 MAC주소를 통하여 한그룹 안에서 사용되어진다.

1) Round Robin: Default로 설정 되어 있으며, Host가 Default Gateway MAC을 질의 할때, 다음 이용 가능한 AVF의 가상 주소를 순서대로 받는다. 트래픽 부하는 각각의 클라이언트이 똑같은양의 트래픽을 보내고 받는것으로 간주할때,  그룹내에 AVF들로 역할을하는 모든 라우터들을 통해 균등히 분배되어 진다.

2)Veighted: GLBP 그룹 인터페이스의 Weighting 값은 AVF로 보내어지는 트래픽의 비율을 결정한다. 빈번히 발생하는 ARP에서 더 높은 Weighting 결과들은 그 라우터에 가상 MAC 주소를 포함하여 응답하게 된다. 만약 인터페이스 트래킹이 설정되지 않았다면, 설정되어진 가장 최대 Weighting 값이 AVF들 사이에서 관계적인 비율로 접근하기 위해 사용되어진다. 한마디로 설명하자면 웨이트 비율에 따라 AVG의 가상 MAC주소 응답 비율을 달리하여 응답한다. (장비 성능에 차이 ...etc)

3)HOst-dependent: 가상 라우터 주소를 위해 ARP Request를 발생하는 각각의 클라이언트는 응답에 있어 늘 똑같은 가상 MAC 주소를 받는다. 이 방법은 만약 고정된 Gateway MAC 주소에 대한 요구를 가진다면 사용 되어진다. (달리 말하자면, 한 클라이언트는 Router over time동안 사용중인 로드 밸런싱 방법에 따라 다른 MAC주소들과 함께 회답들을 받는다.) 간단히 요약하자면 특정 PC나 서버에게 항상 특정 AVF의 가상 MAC주소로 ARP를 응답함.


7. GLBP 설정

Switch>enable

Switch#configure terminal

Switch(config)#interface type number

Switch(config-if)#ip address ip-address mask [secondary]

Switch(config-if)#glbp group authentication text string

// 그 그룹에서 다른 라우터들로부터 받은 GLBP패킷들을 인증화한다. (만약 당신이 authentication으로 설정한다면 GLBP 그룹내에 모든 라우터들은 같은 인증 문자열을 사용해야함.) //

Switch(config-if)#glbp group forwarder preempt [delay minimum seconds]

// 현재 AVF보다 더 높은 우선순위를 가진 라우터를 가졌다면, 한 그룹에서 AVF의 역할을 이어 받도록 그 라우터를 설정한다. (기본 delay 시간이 30초) //

Switch(config-if)#glbp group load-balancing [host-dependent | round-robin | weighted]

// GLBP AVG에 의해 사용되어지는 Load balancing의 방법을 명세화한다. //

Switch(config-if)#glbp group preempt [delay minimum seconds]

// 현재 AVG보다 더 높은 우선순위를 가진 라우더를 가졌다면,  한 GLBP그룹을 위해 AVG의 역할을 이어 받기 위해 그 라우터를 설정한다. ( 이 명령어는 기본 비활성화되어져 있다.) //

Switch(config-if)#glbp group priority level

// GLBP그룹내에서 게이트웨이의 우선순위 수준을 정한다 (Default value: 100) //

Switch(config-if)#glbp group timers [msec] hellotime [msec] holdtime

// 한 GLBP그룹에서 AVG에 의해 보내어진 성공적인 hello packet들의 사이의 간격을 설정한다. ( holdtime 인수는 hello 패킷에서 가상 게이트웨이나 가상 전송자 정보가 무효하게 설정되어지기 전에 초단위로 간격을 명세화한다. msec 키워드는 기본 초단위전송이 아닌 1/100초 단위로 표현되어 질것이다.) //

Switch(config-if)#glbp group timers redirect redirect timeout

// AVG가 하나의 AVF로 클라이언트들의 방향을 고쳐 나가도록 계속하는동안 시간 간격을 설정한다. (timeout인수는 두번째 가상 전송자가 효력이 없어지기전에 초단위로 간격을 명세화한다.) //

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 01:16

라우터 백업을 가능하게 하는 HSRP프로토콜.

디폴트 게이트 웨이 역할을 하는 라우터가 고장났을때 다른 라우터가 있더라도 디폴트레이트웨이가 고장난 라워로 설정되어 있으므로 멀쩡한 라우터를 사용할 수 없다.

그래서 디폴트 게이트웨이 역할을 하는 라우터가 고장 났을때 고장이 나지 않은 다른 라우터를 사용하기 위해서 시스코 라우터는 HSRP를 사용한다.

PC들은 HSPR 상에서 여러대의 라우터들을 하나의 라우터로 보는데 이것을 버추얼 라우터라고 한다. 각 라우터가 가진 실게 IP주소와 MAC주소 외에 버추얼 라우터도 하나의 IP주소와 MAC주소를 가진다. PC에서는 버추얼 라우터 주소를 디폴트게이트웨이의 주소로 구현한다. 버추얼 라우터의 IP 주소와 MAC 주소를 공유하는 라우터들은 액티브 라우터와 스탠바이 라우터로 나뉘는데, 액티브 라우터가 고장났을 때 스탠바이 라우터가 액티브 라우터 역할을 대신한다.


HSRP는 한개 이상의 그룹으로 나눌 수 있다. 왜냐하면 항상 하나의 그룹으로 묶으면 항상 한 라우터는 사용해야 하고, 다른 라우터는 쉬어야 하는데 이것은 합리적이지 않기 때문이다.  이렇게 HSRP를 여러개의 그룹으로 나누어 라우터 간에 부하를 분산하는 것을 MHSRP라고 한다.


HSRP가 시스코 프로토콜인데 반해 VRRP는 표준 프로토콜이다. 기능상으로는 둘이 같다.


GLBP의 기능도 HSRP, VRRP와 비슷. HSRP, VRRP는 한 서브넷 내에서 하나의 그룹 번호만 사용해 두대 중 한대의 라우터만 쓰레되면 트래픽 로드가 라우터 한대로 집중된다. 그래서 MHSRP, MVRRP를 사용하는데 HSRP와 VRRP에서는 MHSRP, MVRRP라고 별도로 구현해 주어야 하지만,  GLBP는 따로 구현재 주지 않아도 된다.


GLBP내의 로드 밸런싱 방법에는 3가지가 있다.

라운드로빈 :

가장 간단한 방법. pc, 서버가 디폴트 게이트웨이 mac 주소를 알고자 ARP 요청을 보내면 AVF의 버추얼 MAC 주소를 순서대로 알려준다.

WEIGHTED :

AVF 마다 다른 WEIGHT를 구현했을 때의 방법. 웨이트 비율에 따라 AVG의 버추얼 MAC 주소 응답 비율이 달라진다. 따라서 특정 AVF가 다른 AVF보다 트래픽을 많이 처리할 수도 있고, 그 반대일 수도 있다.

HOST-DEPENDENT :

특정 PC, 서버에게는 항상 특정 AVF의 버추얼 MAC주소로 ARP응답을 하는것.


AVG : Active Virtual Gateway, GLBP그룹내의 가장 높은 proirity를 가진 라우터.

AVF : Active Virtual Rorward. 일반 라우터

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 01:14


ROUTER의 멀티부팅

라우터에 전원을 넣으면 Boot image file 을 ROUTER내 ROM, Flash MEMORY, 또는 TFTP 서버에서 가지고 온다.



ROM으로 부팅하기

san#conf t


Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#no boot system


san(config)#boot system rom


san(config)#^Z


san#wr m


san#reload


san#sh ver


~ running defailt software


1. ROM에서 부팅하도록 설정하면 일반적으로 bootflash memory에서 부팅하게 된다.


2. 부팅속도가 가장 빠르다


3. 일반적으로 ROM부팅은 비상시 이용하는 것이므로 완전한 S/W set을


제공하지는 않는다.


4. Boot field의 config-register값을 0x2101로 설정하면 부팅설정에 관계없이
ROM 부팅을 하게 된다.


san(config)#config-register 0x2101


참고

: Boot field의 config-register값을 0x2100로 설정하면 Bootstrap이 내장된

라우터 내의 boot ROM에서 직접 부팅을 한다.


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#config-register 0x2100


san(config)#^Z


san#


san#wr m


san#reload


roceed with reload? [confirm]

%SYS-5-RELOAD: Reload requested

System Bootstrap, Version 4.14(7), SOFTWARE

Copyright (c) 1986-1994 by cisco Systems

4000 processor with 8192 Kbytes of main memory


rommon>


참고2

: 위의 ROM Monitor 모드에서 다시 필요에 따라 bootflash, flash, tftp서버등의 2차 부팅을 유도할수 있다.


1) rommon>

rommon>b <== bootflash memory에서 재부팅하기


2) rommon>

rommon>b flash <== flash memory에서 재부팅하기


3) rommon>


rommon>b xx-in-m.102-2 202.30.68.241

<== tftp서버(202.30.68.241)에서 재부팅하기

<== 여기서 xx-in-m.102-2는 읽어올 image-file이다.

: cisco 7000 이상은 위의 command와 조금 다르다.


5. bootflash memory 에 완전한 IMAGE S/W set을 넣어 정상적인
부팅을 시도할수 있다.



Flash Memory 로 부팅하기


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#no boot system


san(config)#boot system flash


san(config)# ^Z


san#wr m


san#reload


san#sh ver

~ system image file is "flash:c4500-i-mz.111--7" booted via flash


1. Flash Memory 를 partition한 경우 특정 partition에서 부팅하고자 할 때는
다음과 같이 셋팅한다.

san(config)#boot system flash flash:1:rsp-jsv-mz.120-3c


2. CISCO 7507등의 경우 SLOT에 삽입된 카드타입의 Flash Memory로 부팅할 때는

다음과 같이 셋팅한다.

san(config)#boot system flash slot0:rsp-jsv-mz.120-3c


(3) TFTP 서버(202.30.68.241)로 부팅하기


san#


san#


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#no boot system


san(config)#boot system tftp c4500-i-mz.111--7 202.30.68.241


san(config)#^Z


san#wr m


san#reload


san#sh ver


~ system image file is "c4500-i-mz.111--7" booted via tftp from 202.30.68.241

1. 위의 경우 라우터는 network내 tftp server (202.30.68.241)에서 image-file (c4500-i-mz.111--7)을 읽어서 부팅하게 된다.

2. LAN 구간에서 TFTP 서버 부팅이 가능하다.


3. WAN 구간을 경유한 경우에도 TFTP 서버 부팅이 가능하다.



멀티부팅 설정하기


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#no boot system


san(config)#boot system flash


san(config)#boot system tftp c4500-i-mz.111-7 202.30.68.241


san(config)#boot system rom


san(config)#^Z


san#wr m


san#reload

1. 위의 경우 처음에 flash memory부터 부팅하게 되며 부팅 실패시 TFTP 서버로부터

부팅하게 되며 역시 부팅 실패시 마지막으로 ROM에서 부팅을 시도한다.



라우터를 TFTP 서버로 이용하기


-Server router설정하기


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#int e 0


san(config-if)#ip addr 202.30.68.241 255.255.255.0


san(config-if)#exit


san(config)#


san(config)#tftp-server flash c4500-i-mz.111-7 1


san(config)#access-list 1 permit 210.109.216.0 0.0.0.255


san(config)#^Z


san#wr m


san#reload

1. CISCO 7507등의 경우는 tftp-server 설정부분에서 조금 틀리다.

san(config)#tftp-server flash:rsp-jsv-mz.120-3c 1


2. CISCO 7507등의 경우 SLOT에 삽입된 카드타입의 Flash Memory를 이용할 때는
다음과 같이 셋팅한다.

san(config)#tftp-server slot0:rsp-jsv-mz.120-3c 1


-Client router 설정하기


san#conf t

Enter configuration commands, one per line. End with CNTL/Z.


san(config)#


san(config)#int e 0


san(config-if)#ip addr 210.109.216.241 255.255.255.0


san(config-if)#exit


san(config)#


san(config)#no boot system


san(config)#boot system tftp c4500-i-mz.111-7 202.30.68.241


san(config)#^Z


san#


san#wr m


san#reload

1. 위의 경우 Client router는 network에 연결된 Server router(202.30.68.241)의 image-file

(c4500-i-mz.111-7)을 읽어서 부팅하게 된다.



show version command 분석


san#sh ver

Cisco Internetwork Operating System Software

IOS (tm) 4500 Software (C4500-I-M), Version 11.1(7), RELEASE SOFTWARE (fc2)

:현재 동작하고 있는 Image version이 11.1(7)임을 의미한다.


Copyright (c) 1986-1996 by cisco Systems, Inc.


Compiled Wed 23-Oct-96 21:35 by tej


Image text-base: 0x600088A0, data-base: 0x60436000


ROM: System Bootstrap, Version 5.2(7b) [mkamson 7b],RELEASE


SOFTWARE (fc1)

: Boot ROM의 Bootstrap을 의미한다.


ROM: 4500 Bootstrap Software (C4500-BOOT-M), Version 10.3(7),


RELEASE SOFTWARE


(fc1):Bootflash Memory의 Image를 의미한다.


seoul uptime is 30 minutes


System restarted by power-on


System image file is "flash:c4500-i-mz.111-7", booted via flash

:flash에 의해 부팅되었으며 flash내 Image version이 11.1(7)임을 의미한다.


cisco 4500 (R4K) processor (revision D) with 8192K/4096K


bytes of memory.

:Main Memory가 8M이고 Shared Memory가 4M이다.


Processor board ID 04007035


R4700 processor, Implementation 33, Revision 1.0


G.703/E1 software, Version 1.0.


Bridging software.


X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.


1 Ethernet/IEEE 802.3 interface.


4 Serial network interfaces.


128K bytes of non-volatile configuration memory.


4096K bytes of processor board System flash (Read/Write)


4096K bytes of processor board Boot flash (Read/Write)

:위에서는 라우터의 전반적인 하드웨어/소프트웨어 사양을 보여주고 있다.


Configuration register is 0x2102

: Boot field의 config-register가 0x2102로 되어있다.





[참 고]


: Privileged EXEC모드 관련 COMMAND


- CD - PWD - COPY


- DIR - PARTITION - FORMAT


- VERIFY - ERASE - DELETE / UNDELETE


- SQUEEZE




[참고2]


: 라우터와 메모리


1. Boot ROM


: bootstrap이 내장되어 있다.


2. ROM( bootflash )


: 부팅에 필요한 최소한의 기능이 내장된 image-file set 이 들어있다.


: bootflash memory 에 완전한 image-file set을 넣어 정상적인 부팅을
시도할수 있다.


3. Flash( system Flash = embedded Flash = internal Flash )


: 정상적인 부팅에 필요한 모든 기능이 내장된 image-file set 이 들어있다


4. RAM( Main Memory와 Shared Memory로 나뉘며 DRAM, SIMM등
여러 타입이 있다. )


: Main Memory는 image, routing table, protocols,기타 등에 이용되며


Shared Memory는 buffer로 이용된다.



[참고3]


: 라우터의 부팅과정


1. 라우터에 전원을 넣으면 프로세서가 먼저 H/W를 인식한 후에


2. Boot ROM에서 bootstrap을 Main Memory로 로딩한다.


3. 로딩된 bootstrap은 보통의 경우 먼저 Flash Memory에서
image-file을 Main Memory로 로딩


4. 다시 bootstrap은 NVRAM에서 Configuration을 Main Memory로 로딩한다.


5. 이후 Main Memory로 로딩된 image-file에 의해 라우터가 부팅을 하며
부팅된 라우터의 프로세서가 전반적인 설정환경등을 인식하여 기능을 수행한다.

Posted by theYoungman
engineering/Network Eng.2006. 4. 7. 01:05
출처 블로그 > hazia님의 블로그
원본 http://blog.naver.com/hazia/10001202458
Helper-Address

1. 기본 개념

라우터는 기본적으로 Broadcast 패킷을 보내지 않는다. Broadcast 패킷이 Forwarding 될 경우 많은 Network Hosts 는 이 패킷에 대해 응답을 해야 한다. 따라서 시간이 지남에 따라 Broadcast Storm이 발생하게 된다.

만약 Server가 Client 와 다른 Network대에 존재한다면, Client 는 Server 의 주소를 알기위해 Broadcast 패킷을 보내게 된다. 하지만 이 패킷은 라우터에 의해 Blocking 된다.
이 경우 라우터에 Helper-address 를 적용시키면 해당 Server에 직접 Forwarding 되어 연결된다.


그림 1

- 10.1.1.0
  :그림 1 에서 보듯이 Client 는 부팅하기 위해 BootP Server로 Broadcast 패킷을 보내
   게 된다. 하지만 라우터에서 Blocking 되므로 접속할 수 없다. Router 1 의 Interface
   에 Helper-address 를 적용시키면 Broadcast 패킷이 Unicast 패킷으로 전환되어 직접
   Server에 접속하게 되는 것이다.


2. 실제응용

◎ 2-1 Remote 서버가 한개일 경우

그림 1




◎ 참고
- UDP Port를 추가/ 삭제할 경우
: Interface e0
: Ip address 10.1.1.1 255.255.255.0
: Ip helper-address 10.1.2.2
: Ip forward-protocol udp 1000
: No ip forward-protocol udp 100
: e0 에 도착한 패킷을 10.1.2.2 로 보냄에 있어, UDP 3000번 포트를사용하는 패킷은
   전달하고 UDP 100번 포트를 사용하는 패킷은 Blocking 한다.

 

2-2 Remote 서버가 여러 개 일 경우

그림 2



2-3 Remote 서버가 Server farm 을 형성 할 경우

그림 3

Posted by theYoungman