* about Network..

Multiprotocol Label Switching (MPLS)의 등장 배경과 장점

현재 코어 IP 네트워크를 구성하는 방법은 크게 두 가지가 있다. (1) 기존의 IP 데이타그램 라우터들로 구성-코어와 에지 모두 라우터로 구성 (순수 라우터 기반 구조)  (2) ATM 교환기로 코어 네트워크를 구성하고 그 위에(또는 에지에) 데이타그램 라우터를 두는 오버레이 모델로 구성하는 하는 것이다.

기존의 IP 백본 네트워크(대략, 1996년까지)은 (1)의 구조로 이루어져 있었으며, 여기서의 라우팅 파라다임은 네트워크내의 모든 라우터에서 매 패킷마다 Layer 3 packet forwarding (LPM) 기능을 수행하였다. 기존의 라우터는 소프웨어 기반으로 패킷의 Next-hop을 찾으므로, 네트워크 링크 속도가 증가하면서 이 포워딩 기능이 전체 네트워크의 성능 저하의 주된 요소가 되었다.

그래서, 대안으로 출현한 구조가 총 세 가지이다.

첫번째는 제일 먼저 나온 구조로 IP over ATM 오버레이 구조이다(대략, 1997-98년). 위의 (2).
(IP/ATM/SONET)

두번째는 (1)구조를 그대로 가면서(즉, 모든 라우터가 매 패킷마다 Layer 3 packet forwarding 수행), 문제가 되었던 라우터의 성능을 대폭 향상시키는 방안이다. 즉, 라우터의 패킷 포워딩 성능을 향상시키기 위해서 고속의 프러세서, 메모리, 스위칭 패브릭을 사용하고, 효율적인 LPM 알고리즘을 적용하고, 포워딩 엔진을 ASIC화하여 라우터의 포워딩 및 교환 능력을 몇 order 정도 향상시키는 방안이다. 98년부터 이러한 고속 라우터가 출시되기 시작하였으며 99년에는 많은 상용 ISP 네트워크에 설치되고 있다.
(IP/L2, or IP/SONET)

세번째는 바로 MPLS로 IP 백본 네트워크의 코어 라우터의 기능을 단순화시키는 접근 방법이다. 즉, 비연결-지향형 IP 네트워크에 연결-지향적인 미케니즘을 도입한 것이다.
(IP/MPLS/L2)
                        < Data forwarding >                          < Core Signaling >
---------------------------------------------------------------------------------------------
                  Edge                      Core
---------------------------------------------------------------------------------------------
IP over ATM       L3(IP)              L2(ATM, PVC/SVC, 연결지향)     PVC or ATM signaling
고속 라우터       L3(IP)              L3(IP, per-hop 라우팅)              -
MPLS               L3(IP)                L2(LSP, 연결지향)                   LDP
---------------------------------------------------------------------------------------------

그림 1. 순수 라우터기반 인터넷 백본 구조

그림 2. IP over ATM overlay 구조

그림 3. 고속 라우터의 등장

MPLS의 장점을 기술하기 위해서 먼저 MPLS의 대안(경쟁) 기술에 대해 알아보고, 이들과 MPLS를 상대적으로 비교함으로써 MPLS가 가져다주는 여러가지 이득에 관해 알아본다. 따라서, 이 글은 두 부분으로 나누어 지는 데, 첫번째는 순수 라우터 기반 네트워크(pure datagram routed network)와 비교했을 때 MPLS의 장점을 기술하고 두번째는 IP over ATM 오버레이 네트워크와 비교했을 때 MPLS의 장점에 대해 알아본다. 두번째 내용은 MPLS의 등장 배경과 장점 (2)에서 기술한다.

들어가기전에 MPLS네트워크의 라우팅 파라다임을 간단하게 알아보자. (후에 자세히 기술함.)

그림 4에서 보이듯이, MPLS 네트워크는 MPLS 네트워크의 에지에 위치하여 non-MPLS 네트워크와 연동하는 LER (Label Edge Router)와 MPLS 네트워크의 코어에 위치하는 LSR (Label Switch Router)로 이루어 진다.

Ingress LER은
(1) non-MPLS 네트워크로부터 전달되어 오는 패킷의 헤더(destination IP address, 등)를 분석하여 이 패킷이 전달될 LSP (Label Switched Path)를 결정한다.
(2) 해당 outgoing interface(Layer 2)에 따라 패킷을 인캡슐레이션한다(링크계층에 따라 다른 포맷의 레이블을 부착).

LSR은 LER로부터 레이블화된 패킷이 들어오면 그 레이블만 검사하여, 레이블값을 바꾸고 정해진 outgoing interface로 전달한다. 이 과정은 ATM 교환기에서 VPI/VCI 테이블을 룩업하여 셀을 교환하는 과정과 동일하다. (또한 ATM에서 VPI/VCI 룩업 테이블을 ATM signaling protocol이 생성하듯이 MPLS에서는 LDP 프로토콜이 룩업 테이블 (LIB: Label Information Base)를 생성한다.

Egress LER에서는 도착한 패킷에서 레이블을 제거하고 그 패킷의 목적지로 패킷을 전달한다.

이같은 과정에서 알 수 있듯이, MPLS 네트워크에서는 LSP의 종단점에 해당하는 LER에서는 Layer 3 apcket forwarding이 수행되고 코어의 LSR에서는 Layer 2 forwarding (스위칭) 기능을 수행하게 된다.

이 때, LER과 LSR에서 룩업 테이블은 LDP (Label Distribution Protocol) 프로토콜이 생성해준다. 이 과정은 추후 자세히 기술한다.

순수 라우터 기반 네트워크(pure datagram routed network)에 대한 MPLS의 장점
(Benefits Relative to Use of a Router Core)

포워딩 구조의 단순화 (Simplified Forwarding)

기존의 라우터에서는 도착 패킷마다 도착 패킷의 Next-hop(근까, 목적지로 가기 위해 경유해야 하는 다음 라우터)를 알아내기 위해, IP address lookup을 수행하는 데, 이 때 각 패킷의 destination address prefix의 길이가 제각각 다르므로(CIDR의 사용으로 인해), 라우팅 테이블의 엔트리중에서 prefix가 가장 길게 매칭되는 엔트리를 찾아야 한다. 이 과정을 Longest Prefix Matching이라고 하며 긴 시간이 소요된다.
그러나 레이블 교환 방식은 가변길이의 긴 prefix로 LPM을 수행할 필요없이, 짧고 고정된 길이의 레이블에 대한 Exact match를 찾으면 되므로 패킷 포워딩 파라다임이 지극히 단순하고(마치 ATM과 똑같이 되고) 지극히 짧은 시간(보통, nsec)에 수행된다.
또한 MPLS에서 사용되는 레이블 헤더는 IP 헤더보다 훨씬 단순하다. 이로인해 기존의 라우터의 경우에 존재하던 IP 헤더 처리에 소요되는 시간을 없애준다.

Efficient Explicit Routing

Explicit routing(Source Routing이라고도 함: source-여기서는 ingress LER-에서 destination-egress LER까지 망내 경로를 명시적/인위적으로 지정해줄 수 있는 기능)은 앞으로 다양한 목적으로 사용될 수 있는 매우 강력한 기술이다. 물론 순수한 데이타그램 라우팅에서도 이러한 기능은 지원된다. 이러기 위해서는, 각 패킷에 도착지까지의 모든 라우트를 실어야 하는 데 이는 아래 그림에서 보듯이 오버헤드가 너무 크다.

그림 5. IP packet format: IP 헤더 + route

MPLS에서는 이 explicit route(명시 경로)를 LSP를 설정할 때 한번 전달하면 되고 명시된 대로 LSP가 설정되면 그 다음부터는 IP 패킷을 그대로 보내면 되므로 실질적으로 의미있는 explicit routing을 구현할 수 있다.

Traffic Engineering

트래픽 엔지니어링이란 트래픽을 네트워크상-많은 링크, 스위치, 라우터들-에 골고루 분산시키도록 트래픽을 경로를 제어해주는 기술을 의미한다. 특히, 네트워크내의 두 지점간에 복수개의 경로(또는 대체 경로)가 존재하는 경우 트래픽 엔지니어링은 큰 의미를 갖는다.
인터넷의 급속한 성장으로, 몇몇 코어 네트워크(ISP 백본망)는 이 급증하는 IP 트래픽에 대처하기 위해 자신들의 망내에 라우터와 전송 링크를 증설하고 있다. 이로 인해 ISP 백본망은 노드와 링크 측면에서 확장되고 있으며 따라서 망내에 수 많은 대체 경로가 존재하게 되었다. 이런 측면이 트래픽 엔지니어링의 필요성과 중요성을 더욱 부각시키고 있다.

그렇다면, 지금까지는 트래픽 엔지니어링 기술이 상용서비스망에서 적용되지 않았던 새로운 기술인가? 그렇지 않다. 오늘날 많은 ISP망이 IP over ATM 오버레이 모델을 취하고 있다. 즉, 코어에 고속 ATM 교환기를 배치하고 에지에(또는 위에) IP 라우터를 두는 구조이다. 이 라우터간에 연결성은 ATM PVC로 제공되며, 각 에지 라우터는 ATM PVC full-mesh의 형태로 연결되며 모든 라우터가 다른 라우터와 1-hop(layer 3)으로 연결된다.
ISP 네트워크 설계자/관리자는 각 라우터간에 ATM PVC를 설정할 때 ATM 네트워크에 부하가 골고루 분산되도록 (많이) 신경써서 설정한다. 근까, 현재도 트래픽 엔지니어링 기술은 적용되고 있는 것이다.

순수 라우터 기반 네트워크에서는 트래픽 엔지니어링을 구현하기란 여간 어려운게 아니다. 어느 정도의 부하 균등화 (load balancing)는 네트워크 링크와 관련된 메트릭(라우팅 알고리즘에서 사용됨.)을 조절하여 제공될 수는 있다. 그러나, 이런 식으로 트래픽을 다양한 링크로 분산시키기에는 한계가 있고, 특히, 대체 경로가 무지 많은 대규모 네트워크에서, 어느 두 지점간에 이러한 메트릭값을 조절하여 부하 균등 분산 효과를 얻는 것을 매우 어렵다. (이게 다 라우팅 알고리즘때문에 그렇다. 근까, OSPF처럼 최단 경로로 무조건 패킷을 포워딩하는 비지능성때문!) 이 예가 그림 7에 나타나 있다.

(a)

(b)

그림 7 IGP의 문제점

그림 8. Explicit LSP 설정을 통한 트래픽 엔지니어링 예

근데, MPLS에서는 그림6에서처럼 Explicit routing기능을 갖고 있어 홉수는 더 많더라도 다른 대체 경로를 선택할 수 있다. 그림 8처럼 LSP를 ingress LER이 설정하여 네트워크 자원은 효율적으로 쓰면서 사용자에게는 더 좋은 서비스(delay,loss 등의 측면에서, 근까, 한마디로 빠르게 해준다.)를 제공해줄 수 있게 된다.

IP 패킷과 FEC의 매핑(Mappings from IP Packet to Forwarding Equivalence Class)

MPLS에서는 IP 패킷을 FEC로 딱 한번만, MPLS망의 유입부(ingress LER)에서, 매핑해주면 된다.
이 것이 얼마나 편한 건지 한 번 예를 들어 생각해 보자. 어떤 ISP가 차등화 서비스(differentiated services)에 가입한 고객에게 그렇지 않은 'best effort service'를 쓰는 사용자와 어떻게 서비스를 차별화 시켜줄 것인가? ISP 망이 순수 라우터 기반 네트워크인 경우에 차별화 서비스를 제공하려면, 일단 라우터가 도착하는 패킷들이 차등화 서비스에 가입한 고객이 보낸 패킷인지 아닌지를 구분해낼 수 있어야 한다. 알아야 서비스를 해주니까. 이를 위해서 도착 패킷의 source and destination IP address(L3), incoming interface, 또 필요하면 source and destination port number(L4) 등을 살펴봐야 되고 그럴려면 엄청난 량의 패킷 필터(packet filter or classifier)가 필요하다. 근데, 중요한 것은 이 패킷 필터링 기능(도착 패킷이 중요한 패킷인지 아니지를 식별해내는 기능)이 네트워크내의 모든 라우터에서 필요하다는 것이다. 라우터는 hop-by-hop개념으로 패킷을 포워딩하니까, 이전 라우터에서 그 패킷이 특별 대접을 받았다고 해도 다음 라우터에서는 이 패킷이 특별 대접을 해줘야 할 놈인지 아닌지는 모른다. 근까, 모든 라우터에 패킷 필터링 기능이 포함되어 있어야 종단간에 서비스 품질이 보장될 수 있다.
 
 

DiffServ, or DS (differentiated services) ; 차등화 서비스

DiffServ는 음성 등과 같이 데이터의 흐름이 끊어지면 안 되는 비교적 특별한 형식의 트래픽들에 대해, 다른 종류의 일반 트래픽에 비해 우선권을 갖도록 네트웍 트래픽을 등급별로 지정하고, 제어하기 위한 프로토콜이다. DiffServ는 서비스의 등급, 즉 CoS (Class of Service)라고 불리는 형태로 트래픽을 관리하는 가장 진보된 방식이다. DiffServ는 802.1p에서의 태그 이용 그리고 ToS (Type of Service) 등과 같은 초창기 방식과는 달리, 주어진 네트웍 패킷을 어떻게 전달할 것인지를 결정하기 위해 단순히 우선 순위를 위한 태그를 붙이는 대신, 좀더 복잡한 정책이나 규칙문을 사용한다. DiffServ는 사람이 여행을 할 때 안락함, 여정 중의 들르는 회수, 대기 상태, 여행에 소요되는 시간 등을 모두 고려하여, 기차, 버스, 비행기 등 여러 가지 교통 수단 중 하나를 선택하는 것과 유사한 방식이다. 주어진 패킷 이동 규칙에서, 패킷은 홉당 움직임, 즉 PHB (per hop behaviors)라고 불리는 64개의 가능한 전달 움직임 중 하나가 적용된다. IP 헤더 내 DSCP (DiffServ code point)라는 여섯 비트 길이의 필드가 주어진 패킷의 흐름에 대해 홉당 움직임을 지정한다.

DiffServ와 CoS 접근방식은 트래픽의 제어에 있어, QoS 방식에 비해 보다 유연하고 더 큰 범위성을 제공한다.

[IT키워드] MPLS

[전자신문 2004-12-21 09:23]

MPLS는 ‘Multiprotocol Label Switching’의 약자로 데이터 패킷에 IP 주소 대신 별도의 라벨을 붙여 스위칭 및 라우팅하는 기술이다.

패킷이 발생하면 기존 라우터 기반의 백본에서는 라우터가 IP를 보고 패킷을 전달했으나, MPLS 네트워크에서는 레이어2 기반의 라벨을 보고 스위칭한다. 즉 소프트웨어 기반 처리를 라벨을 읽음으로써 하드웨어 기반 처리로 바꾸면서 고속 스위칭을 가능케 했다.

MPLS는 다양한 프로토콜을 수용하기 때문에 IP망은 물론 ATM, 프레임 릴레이에도 적용할 수 있다. 이로써 각 네트워크에서 오는 트래픽을 융합해 단일 네트워크로 결합함으로써 운영비를 절감할 수 있다.

주로 가상사설망(VPN)에 적용되며 기존 IP가 지원하기 힘든 서비스품질(QoS) 지원 및 확장성도 뛰어나다. 반면 MPLS를 적용하려면 모든 백본망의 라우터를 최상위 기종으로 업그레이드해야 한다는 점이 단점으로 지적된다.

MPLS란 무엇인가?

1 MPLS의 등장 배경

기존의 IP 백본 네트워크는 IP 데이터그램 라우터들로 구성(코어와 에지 모두 라우터로 구성)하여 순수 라우터 기반 구조로 이루어져 있었으며, 여기에서의 라우팅 구조는 네트워크 내의 모든 라우터에서 매 패킷 마다 Layer 3 packet forwarding 기능을 수행. 기존의 라우터는 소프트웨어 기반으로 패킷의 Next-hop을 찾으므로, 네트워크 링크 속도가 증가하면서 이 포워딩 기능이 전체 네트워크 성능 저하의 주된 요소가 됨 .

MPLS(Multi-Protocol Label Switch, IETF) 기술은 기존의 라우팅 방식을 기반으로 ATM의 고속 멀티 서비스 교환 기능을 결합하여 IP 패킷을 전달하는 방식으로 대규모의 망에서 고속의 데이터 전송과 QoS(Quality of Service) 등의 기능 제공을 목적으로 제시패킷 전달을 고속화하기 위해 ATM이나 Frame Relay와 같은 Layer 2의 교환 기술을 사용하고, 망의 확장성을 제공하기 위해서 Layer 3의 라우팅 기능을 접목한 Layer 3 스위칭 기술의 일종. 이런 MPLS에서는 짧고 고정된 길이의 레이블을 기반으로 패킷을 전송하는 레이블 교환(Label Switching) 방식을 이용 그러므로 IP 패킷을 목적지까지 전송하기 위해 필요한 IP 헤더 처리 과정이 모든 홉에서 수행될 필요 없이 MPLS 망에 진입하는 시점에서 단 한 번만 수행된다. 그리고 이 시점에서 IP 패킷이 하나의 레이블로 매핑됨으로써 스위칭 기술을 이용한 고속의 Layer 2 데이터 전송이 이루어지며, 경우에 따라서 Traffic Engineering이나 VPN(Virtual Private Network)과 같은 다양한 부가 서비스도 제공 .

▣ 기존의 IP Routing과 MPSL

◎ IP Header Processing

라우터에서 IP packet을 다음 hop으로 전송하기 위해서는 TTL, Checksum, Routing Table Lookup 등 IP Header 내의 많은 처리 과정이 필요

◎ Longest Prefix Matching

IP packet을 전송하기 위해 다음 hop을 찾는 과정에서 Longest Prefix Matching 방식을 사용함으로써 등록된 Routing Table에 따라 Routing Table Lookup 과정이 지연

◎ Hop-by-Hop Forwarding

Data를 전송지부터 목적지까지 전달하기 위해 거쳐야 하는 모든 Hop에서 IP Header 처리 및 Longest Prefix Matching 방식을 이용한 Routing Table Lookup 과정을 수행해야 하기 때문에 고속 Data 전송에 부적합

◎ Best Effort Service

현재 인터넷 망에서는 모든 패킷을 Routing Protocol이 정한 경로에 따라 라우터에서 동일하게 처리하는 Best Effort Service만을 제공하고 있기 때문에 전송 지연 또는 패킷 손실에 대한 보장 처리를 수행하기 어려움

◎ Traffic Engineering

Routing Protocol에 의해서 결정된 전송 경로를 기반으로 LSP(Label Switching Path)를 설정하도록 되어 있으나 네트워크 관리자가 선택적으로 Explicit Route를 설정할 수 있는 기능과 함께 LSP 설정시 망 자원을 적절히 할당할 수 있는 기능을 제공함으로써 Traffic Engineering 기능 수행 가능

CMTS (cable modem termination system)는 케이블 모뎀(Cable Modem) 데이터를 인터넷으로 전송하기 위한 데이터용 패킷으로 바꾸어주는 장비이다.  MCNS 스펙에 따라 RF Return 시스템에서 CMTS는 하향 시스템(Downstream System)과 상향(Upstream System)으로 구성한다. CPE(Customer Premise Equipment)를 목적지로 가지는 하향 데이타 패킷은 CMTS-NSI(Cable Modem Termination System Network Side Interface)를 거쳐서 CMTS를 거쳐 케이블 TV망을 이용하여CM(Cable Modem)으로 전송된 뒤 CMCI(Cable Modem CPE Interface)를 통해 CPE로 전송되어야 한다. 상향 데이타 패킷은 역으로 패킷 전송이 이루어 진다.
CMTS는 데이터 네트워크에서 RF케이블 네트워크로 라우팅 기능을 제공하는 CAR(Cable Access Router)카드와 하향 데이타를 위한 64/256QAM을 처리할 수 있는 QAM Modulator, 상향 데이타를 위한 QPSK/QAM Modulator로 구성 가능하다.

케이블모뎀종단치(CMTS)는 HFC 망이 끝나는 분배센터 내에 위치하여 양방향 HFC망을 통해 케이블 모뎀장비와 인터페이스를 수행하여 외부망과 연결된다. CMTS는 케이블 모뎀과 인터페이스를 위해 다양한 종류의 케이블 모뎀 카드 지원 및 케이블 모뎀 인증을 담당하며, 상 하양 채널의 주파수를 지정하고 채널에 대한 데이터를 암호호한다. CMTS는 대게 라우터,변조기,라인카드가 조합된 형태로 구성이 되며, 인터넷/인트라넷 백본 데이터 네트워크와 지역 액세스 케이블 네트워크 간에 고속 통신을 가능하게 한다. 일부 벤더들은 L#라우터 대신에 L2 브리징과 스위칭 기술을 사용하여 CMTS와 분산된 라우터를 연결한다.

CMTS 구성도

MRTG는 장비의 CPU, 메모리, 4～7계층 스위치, 다양한 서버와 애플리케이션의 상태를 모니터링 하는 툴로, 네트워크 관리자라면 한번 이상은 사용해 봄직한 공개용 툴이다. 하지만 알고 있는 것과 실제로 잘 활용하는 것은 별개의 문제. MRTG 설치시 유의할 점과 MRTG 전체 구조의 이해 등을 통해 실력있는 네트워크 관리자의 세계로 한단계 성큼 다가서 보자.

네트워크에 연결돼 있는 수많은 스위치, 라우터, 서버 등과 같은 여러 장비들을 관리하는 엔지니어들이 가장 궁금해 하는 것 중에 하나가 바로 ‘어떻게 장비의 상태를 주기적으로 모니터링할 수 있을까’일 것이다.

과거 네트워크 장비 상태를 점검한다고 하면 대부분 ‘트래픽’의 양에만 국한됐다. 하지만 최근에는 장비의 CPU, 메모리, 4～7계층 스위치, 다양한 서버와 애플리케이션까지 등장하면서 보다 다양한 값을 포함하게 됐다.

MRTG는 이런 상태를 모니터링하는 툴 중 하나로, ‘Mutli Router Traffic Grapher’의 줄임말이다. MRTG는 이름에서 알 수 있듯이 기본적으로 라우터에서 가장 중요한 여러 인터페이스들의 ‘In/Out’ 트래픽을 일간, 주간, 월간, 년간을 기준으로 각각 별도의 그래프를 그려주고, 이들의 현재, 평균, 최대치를 한눈에 알 수 있게끔 해주는 아주 유용한 툴이다.

(화면 1) 네트워크 장비의 트래픽(주간)

MRTG는 라우터를 기본적으로 하고 있지만 조금만 응용해서 사용한다면 상상 이상의 것들도 모니터링이 가능하다. MRTG 활용으로 유명한 국내 사이트인 www.mrtg.co.kr로 가면 네트워크 장비들의 내부 온도를 나타내는 수치를 이용해, 온도 그래프까지 그려보이고 있다.

그만큼 네트워크를 하는 사람들에게 MRTG는 잘 알려진 툴이며, 많이들 사용하고 있고, 실제 상용화된 네트워크 제품들이 통계치를 가진 그래프가 필요할 때 많이 사용된다. 아직 MRTG를 접해보지 않은 독자들이 있다면 이번 글을 통해 유용한 툴 하나를 얻을 수 있을 것이다.

MRTG의 동작 원리
MRTG는 여러 가지 요소가 복합적으로 동작을 하기 때문에 제일 먼저 MRTG가 전체적으로 어떻게 구성돼 있는지를 이해해야만 한다. 필자가 처음 MRTG를 접하고 나서 어느 정도 익숙해지기까지 시간이 많이 걸렸던 것도 바로 이런 부분을 그냥 지나쳤기 때문이었던 것으로 기억한다. 때문에 이 같은 시행착오를 거치지 않으려면 MRTG의 전체 구성을 반드시 이해하고 넘어가는 것이 좋다.

MRTG는 (그림 2)와 같이 모니터링 대상이 되는 시스템과 그 시스템을 모니터링 하는 두 개의 시스템으로 구성된다.

(그림 1) MRTG의 구성과 동작 원리

(그림 2)와 같이 네트워크 장비의 트래픽을 모니터링하고 싶을 경우 MRTG 서버의 SNMP(Simple Network Management Protocol) 요청에 응답하기 위해 시스템에서 제일 먼저 SNMP는 에이전트(Agent)를 구동시켜야 한다. 물론 이때 두 시스템은 네트워크에서 연결이 돼야 한다(인터넷 구간에서도 많이들 사용한다).

다음으로 MRTG가 구동될 서버에는 모니터링 장비에 정보를 요청하고, 그 값을 로그로 남기고, 그래프를 만드는 MRTG 프로그램을 설치해야 한다. 이들 결과값을 사용자가 웹 브라우저를 이용해서 볼 수 있도록 웹 서버를 설치해야 한다. 웹 서버는 결과값을 만드는데는 필요하지 않고, MRTG의 결과값이 gif, png 형태의 그래프와 HTML 형식으로 만들어지기 때문에 사용될 뿐이다.

여기서 웹 서버는 자주 사용하는 리눅스(유닉스 계열)의 아파치나 마이크로소프트의 윈도우 NT 계열 이상에 설치되는 IIS 또는 개인용 웹서버라고 불리우는 ‘Persnal Web Server’이어도 상관없다.

다시 한번 정리하면 모니터링 대상이 되는 시스템에 SNMP가 구동돼야 하고, MRTG가 설치된 서버에 MRTG 프로그램과 웹 서버를 설정하면 모든 작업은 끝난다. 이제 필요할 때마다 웹 브라우저를 이용해 장비 상태를 점검하면 된다.

다양한 운영체제 지원
MRTG가 가장 많이 사용되는 시스템은 리눅스(유닉스) 계열이고, 최근에는 마이크로소프트의 윈도우 계열에서도 많이 사용한다. 그 이유는 더 편해서라기 보다는 대부분의 사람들이 윈도우를 사용하기 때문일 것이다.

최근 리눅스 배포판들의 경우는 대부분 MRTG를 이미 포함하고 있기 때문에 리눅스가 있다면 바로 사용할 수 있다. 참고로 MRTG는 다음과 같은 다양한 운영체제를 지원한다.

• 리눅스 1.2.x, 2.0.x, 2.2.x, 2.4.x(인텔, 알파, 스팍, 파워PC)
  
• 리눅스 MIPS, 리눅스 S/390
  
• SunOS 4.1.3
  
• MacOSX 10.2.8
  
• 솔라리스 2.4, 2.5, 2.5.1, 2.6, 7, 8, 9
  
• AIX 4.1.4, 4.2.0.0, 4.3.2
  
• HPUX 9,10,11
  
• 윈도우 NT 3.51, 4.0, 2k, XP, 2003(95, 98, ME too, but only for die-hards)
  
• IRIX 5.3, 6.2, 6.5
  
• BSDI BSD/OS 2.1, 4.x, 3.1
  
• NetBSD 1.5.x 1.6.x
  
• FreeBSD 2.1.x, 2.2.x, 3.1, 3.4, 4.x
  
• OpenBSD 2.x, 3.x
  
• Digital Unix 4.0
  
• SCO Open Server 5.0
  
• Reliant UNIX
  
• NeXTStep 3.3
  
• OpenStep 4.2
  
• Mac OS X 10.1
  
• 기타 유닉스 계열의 운영체제

이렇게 다양한 운영체제를 지원하는 것만으로도 MRTG가 얼마나 범용적인 툴인가를 알 수 있다.

이번 기고에서는 지면 관계상 MRTG 설치법에 대해서는 자세히 다루지 않는다. 그렇다고 걱정할 필요는 없다. 다음과 같은 홈페이지를 이용하면, 보다 더 자세한 설치 매뉴얼을 얻을 수 있으니 말이다.

• www.mrtg.co.kr
  
• http://people.ee.ethz.ch/~oetiker/webtools/mrtg

대신 MRTG 설치시 주로 고민하게 되는 몇 가지에 대해서만 간단히 짚고 넘어가도록 하겠다. 우선 MRTG는 펄(Perl)과 C를 기본으로 동작하는데, 리눅스의 경우 대부분 펄이 이미 설치돼 있기 때문에 MRTG만 설치하면 되지만, 윈도우에서는 그렇지가 못하다. 때문에 ‘윈도우용 Perl’을 별도로 설치해야만 한다.

자신의 시스템에 펄이 설치돼 있지 않다면 www.perl.com이나 www.perl.org를 방문해서 별도로 펄을 설치해야 한다. 참고로 펄은 스크립트형 프로그래밍 언어로, 유닉스 계열에서 많이 사용되며, 특히 웹 서버들의 프로그래밍에 많이 사용돼 왔다.

MRTG 실행 파일 활용 1 : cfgmaker
MRTG에는 다음과 같은 3개의 실행 파일이 있다.

• cfgmaker
  
• mrtg
  
• indexmaker

cfgmaker는 이름에서 짐작할 수 있듯이 MRTG가 구동되기 위한 Config 파일을 만드는데 사용된다. 사실 Config 파일의 포맷을 정확히 알고 있다면 cfgmaker를 사용할 필요가 없지만, 그렇지 않은 경우에는 cfgmaker를 이용해서 설치를 한 후에 간단하게 Config 파일을 만들 수 있다.

그 다음으로 이 Config 파일을 자신이 원하는 형태로 수정을 하면 된다. cfgmaker의 경우, 처음에 Config 파일을 생성할때만 사용된다. 다음은 간단한 cfgmaker 사용법이다.

[root@tech mrtg]# cfgmaker admin@192.168.10.10 switch.cfg

여기에 사용된 ‘admin’은 실제 모니터링을 할 시스템인 192.168.10.10에 설정된 SNMP 커뮤니티 값이다. 그리고 다음에 있는 switch.cfg는 cfgmaker에 의해 만들어질 Config 파일의 이름이다.

여기서 cfgmaker는 192.168.10.10 시스템에 직접 SNMP 통신을 해 모든 인터페이스들의 값을 나타내고자 한다. 그러므로 cfgmaker를 구동할 때는 시스템과 SNMP 통신이 가능해야만 한다. 만약에 그렇지 않다면 ‘에러’를 만나게 될 것이다.

MRTG 실행 파일 활용 2 : mrtg
MRTG의 또다른 실행파일인 mrtg는 기본적으로 5분마다 실행돼 Config 파일에 따라서 SNMP 요청을 하고, 그 결과값으로 로그를 남기고 그래프도 만든다. cfgmaker와 indexmaker가 어떤 대상을 모니터링 하고자 할 때 처음에만 사용된다고 한다면, mrtg 파일은 모니터링을 하는 동안 계속해서 사용된다.

[root@tech mrtg]# mrtg switch.cfg

mrtg 파일은 cfgmaker로 만들어지거나 임의로 만든 Config 파일을 이용해 실행할 수 있다. 이때도 물론 해당 서버와 통신이 가능해야만 정확한 값을 가지고 올 수 있다. mrtg의 경우, 이전에 남은 로그를 비교해서 만들기 때문에 초기에 실행하면 첫번째, 두번째는 에러가 나고, 세번째에야 에러가 없이 동작을 하게 되니, 첫 번째, 두 번째 에러에 너무 당황하지 않아도 된다.

설치 초기에만 mrtg 파일을 수동으로 실행시키고 이후에는 유닉스의 자동 스케줄 프로그램인 cron을 이용해서 5분마다 구동시키면 된다. 다음은 cron에 등록돼 5분마다 실행하도록 추가된 내용이다.

*/5 * * * * /usr/local/mrtg-2/bin/mrtg /var/www/html/mrtg/switch.cfg

mrtg를 5분마다 실행하는 또 다른 방법으로는 Config 파일에 다음과 같은 항목을 넣어주는 것이다.

RunAsDaemon:Yes
Interval:5

위와 같은 항목만 넣어주고 mrtg가 실행되면서 데몬으로 동작을 하게된다. mrtg가 cron에서 동작할 경우 매번 Config 파일을 로딩하고 파싱을 해야 하는 반면, 데몬의 경우 그 동작을 한번만 수행하는 장점이 있다.

다만 데몬으로 동작하는 경우는 시스템 구동시 시작되도록 시작 스크립트에 mrtg가 한번 구동되도록 해야 한다는 점을 절대 잊지 말자.

MRTG 실행 파일 활용 3 : indexmaker
'indexmaker' 파일도 cfgmaker와 마찬가지로 초기에 cfgmaker를 만들고, mrtg 파일을 다음에 한번만 생성하면 된다. 이 파일은 실제 mrtg가 동작하는데 사용되기 보다는 mrtg로 만들어진 결과값을 사용자가 웹 브라우저로 볼 때 만들어지는 HTML 형태의 초기 화면을 만들어주는 역할을 한다. 그러니 mrtg를 구동하고 처음에 한번만 실행을 하면 된다.

[root@tech mrtg]# indexmaker --title "스위치“ --output ./switch/index.html switch.cfg

위의 명령어를 실행시키고 나면 ‘switch’라는 폴더에 ‘index.html’이라는 파일이 생성됨을 알 수 있을 것이다. 물론 이 페이지를 열게 되면 페이지 맨 위의 제목이 ‘스위치’로 돼 있다. 참. 이때 간단한 내용이지만 주의할 점은 이 파일이 만들어지는 위치는 당연히 웹 서버의 홈 디렉토리 내부에 위치해야만 웹 브라우저로 볼 수가 있다는 것이다.

지금까지 살펴본 cfgmaker, mrtg, indexmaker 파일이 각각 어떤 역할을 하는지 명확히 구분할 수 있다면 MRTG를 처음 설치하더라도 걱정할 것이 없다.

MRTG의 로그값 분석하기
이제부터는 MRTG가 남기는 로그에 대해 알아보자. MRTG는 5분마다 얻어진 로그를 남기고, 이전까지의 값들을 계산해 최고, 평균값들을 남긴다. 이들의 로그 포맷은 (화면 2)와 같다.

(화면 2) MRTG의 로그 포맷

MRTG는 이렇게 남겨진 로그를 갖고 그래프를 그린다. 기본 입력값은 Byte/Sec 단위이다. MRTG의 로그중에서 가장 재미있는 내용은 시간 필드이다. 이 필드는 MRTG가 유닉스 계열에서 만들어졌음을 여실히 나타내고 있다.

이 시간들은 유닉스의 기본값인 1970년 1월 1일부터 초단위로 증가한 시간을 나타낸다. 물론 사용자가 이 시간을 구분할 필요는 없다. 이 값은 그래프로 그려지는 순간에 이미 사용자가 알 수 있는 시간으로 변환돼 있기 때문이다(그래프가 그렇다는 것이지 로그파일 자체가 바뀌는 것은 아니다).

MRTG의 CFG 파일 구조
다음으로 MRTG의 CFG 파일의 구조를 간단하게 살펴보자. 앞서 설명한 실행 파일인 cfgmaker로 파일을 만들고 나면 그 파일을 그대로 쓰는 것보다는 몇 가지를 수정해서 사용하는 편이 낫다. 물론 수정을 하다가 에러를 만들 위험도 있지만 몇가지 정도만 수정을 하면 보다 깔끔한 화면과 원하는 화면을 만날 수 있을 것이다.

cfgmaker로 만들어진 보통 파일들은 대부분 위와 같은 형태를 갖고 있는데 크게 3가지로 구분할 수가 있다. 첫번째로 Config 파일 전체에 영향을 미치는 ‘전체 환경 설정’ 부분이 있는데 이 부분에서는 사용하는 언어라든가 작업 디렉토리, 또는 각각의 항목에 영향을 미칠만한 옵션들을 사용할 수 있다. 필자가 주로 사용하는 옵션은 (표 1)과 같다.

(표 1)의 첫 번째 줄에 있는 'WorkDir: /home/www/mrtg'는 없어서는 안되는 아주 중요한 옵션이며, 그밖의 두 가지는 없어도 문제가 없지만 가독성에 상당한 도움이 되므로 알아두면 도움이 되는 옵션이다.

(화면 3) MRTG의 Config 파일

Xbit Labs FC-테스트 결과

환경 설정 내용 WorkDir: /home/www/mrtg MRTG 로그와 그래프들이 생성되는 디렉토리(필수) Language: Korean 설정 안하면 기본값 영문 Options[_]: growright, bits growright는 그래프 흐름을 오른쪽 방향으로 흐르게 함. MRTG는 기본 바이트(Byte) 단위이므로 bits를 사용해 단위 변경

(화면 4) Language 옵션으로 달라질 수 있는 페이지(한글/영어)

MRTG는 영어를 기본으로 하고 있다. 하지만 (표 1)의 두 번째 줄에 있는 ‘Language: Korean’이라는 옵션을 사용하면 화면이 한글로 변환된다. (화면 4)에서 좌측에 보이는 ‘일간 그래프’는 우측의 영문 버전으로는 ‘Daily Graph’로 표시된다. 역시 마찬가지로 좌측의 ‘최대 수신’은 우측에는 ‘Max In’이라고 표시된다. 한글이든 영문이든 의미가 같은데 뭐 그리 크게 다를 것이 있냐고 할 수도 있지만, 한국 사람은 아무리 영어를 잘 하더라도 한글 페이지가 더 편하게 느껴질 수밖에 없지 않겠는가.

다시 (화면 3)으로 돌아가서 두번째 사항인 ‘장비에 대한 설명’ 부분을 살펴보자. 이는 SNMP의 값 중에서 모니터링 대상이 되는 시스템이 어떤 정보들을 남겼느냐에 따라서 다르게 설명할 수 있다. 이 부분은 동작에 이상이 없지만 말 그대로 장비에 대한 설명이므로 장비의 SNMP 설정에서 시스템에 맞는 값으로 조절해 두는 것도 괜찮은 방법일 것이다.

마지막으로 (화면 3)의 ‘항목에 대한 내용’은 실제로 시스템에서 모니터링을 하고자 하는 항목에 대한 내용이다. cfgmaker로 만들었다면 장비가 갖고 있는 모든 인터페이스에 대한 각각의 항목들이 생겨난다.

다시 말해 24포트 스위치라면 24개의 항목이 생긴다. 다만 이중에 링크(Link)가 다운(Down)된 포트는 모두 주석(#) 처리가 된다. cfgmaker가 사용하지 않는 포트로 인식하기 때문이다. 하지만 주석으로 표시됐지만 실제로 사용하는 포트라면 주석만 삭제해주면 된다. 그리고 실제 데이터 값과는 상관없는 여러 ‘설명 항목’들이 있는데 이 부분은 사용자의 입맛에 맛게 수정하면 된다.

필요할 경우 항목 하나하나를 복사해서 추가해주고 각각의 항목들을 수정해주면 별도의 cfgmaker로 만들 필요가 없다.

다각도로 활용 가능한 MRTG
MRTG의 초기 개발 의도는 라우터 트래픽을 모니터링하는 것이었다. cfgmaker를 이용해서 Config 파일을 만들고 나면 더더욱 개발 의도가 그랬다는 것을 몸으로 느낄 수 있을 것이다(대부분 트래픽에 관한 용어들만 사용되고 있기 때문에). 하지만 MRTG의 활용도는 라우터 트래픽 분석 그 이상의 의미를 갖고 있다.

(화면 5)는 전형적인 MRTG의 페이지로 MRTG의 특징을 그대로 보여주고 있다. (화면 6)은 4계층 스위치에서 처리하는 TCP/UDP 커넥션 숫자를 SNMP를 이용해서 MRTG에서 얻은 그래프이다. 이 그래프를 이용해서 실제 이 사이트의 사용자 접속형태를 알 수 있고, 어떤 시간대에 가장 많은 사용자 증가가 있었는지를 짐작할 수 있다. 물론 이를 이용해서 시스템 확장 여부도 가늠할 수 있을 것이다.

(화면 5) 라우터의 트래픽 모니터링 하기

(화면 6) 4계층 스위치에서의 동시 사용자 모니터링

(화면 7)은 예전에 필자가 만졌던 장비의 CPU 사용률을 알아보기 위해 MRTG를 이용해서 얻은 결과이다. 이 그래프를 보면 CPU가 아침 9시부터 증가해서 초저녁까지 증가세가 이어졌다가 다시 새벽까지 천천히 내려가는 패턴을 보이고 있다. (화면 7)의 그래프 중에 그래프를 보면 갑자기 CPU가 뚝 떨어져 있는 것도 볼 수 있을 것이다. 이 그래프에서 우리는 어떤 문제점이 있었는지를 짐작할 수가 있다. 물론 문제가 아니라 시스템 점검으로 서비스를 중단했을 가능성도 있다.

이렇게 그래프를 통하면 직관적으로 원하는 요소들이 각각 어떤 패턴을 갖고 있는지를 짐작할 수 있도록 해주며, MRTG의 경우 일간, 주간, 월간, 년간으로 각각 그려주기 때문에 전체적인 흐름을 이해하는데 아주 많은 도움이 된다.

(화면 7) 시스템의 CPU 사용률 모니터링

‘MRTG에서 RRDTool로 새롭게 도전하자’
마지막으로 MRTG 활용과는 상관이 없지만 지금껏 MRTG를 사용해 온 독자라면 분명 매력적이라고 느낄 툴 하나를 더 소개하고자 한다. 이 툴의 이름은 ‘RRDTool’이며, ‘Round Robin Database Tool’의 약자이다.

RRDTool은 MRTG의 그래프 기능과 로깅 기능을 강화한 새로운 형태의 툴이다. RRDTool과 MRTG의 가장 큰 차이는 처리 속도와 유연성의 강화에 있다. 참고로 RRDTool에 대한 보다 자세한 정보는 홈페이지(www.rrdtool.com)에서 얻을 수 있다.

(화면 8)은 해외의 유명한 음악공유 사이트인 냅스터(www.napster.com)에서 사용하고 있는 RRDTool의 화면이다. 이 사이트에서는 각종 서비스들의 트래픽 사용률을 나타내고 있다. (화면 9)는 미국에서 모뎀으로 통신 접속을 하는 가입자들의 평균 속도를 구분하고자 사용된 RRDTool이다. 이 그래프를 이용해서 보다 화려한 그래프로 통계치를 나타내고 있다. MRTG와 비교해 보다 시각적인 면에서 발전된 양상을 보여주는 툴이 바로 RRDTool이다. 이미 MRTG에 익숙한 사용자라면 한단계 발전한 RRDTool을 이용해 보다 화려하고 다양한 그래프를 만들어 보는 것도 나쁘지 않을 것이다.

MRTG나 RRDTool은 모두 공개용 툴이므로 돈을 주고 사는 상용 툴과 달리 사용자 힘으로 처음부터 끝까지 모든 것을 해결해야 한다. 즉, 제품 구매 업체에 전화를 해서 도움을 청할 수도 없고, 의논을 할 수도 없다. 하지만 두려워할 필요는 없다. 인터넷 여러 사이트를 뒤지면 많은 유용한 정보들이 넘쳐나고 있기 때문이다. 엔지니어라면 누구나 마음만 먹고, 노력한다면 공개툴에 가볍게 도전할 수 있을 것이다. 이미 많은 사람들이 그렇게 해서 아주 유용하게 사용하고 있으니 말이다. @

(화면 8) 넵스터 서비스의 사용률

(화면 9) 모뎀 속도에 따른 접속자 수 분석

출처: ZDNet 테크업데이트 >강좌 & 팁> 네크워크 -> [공개 네트워크 모니터링 툴 활용]  MRTG

[TIP]네트워크 연결진단법

네트워크의 연결진단 방법

1. ping 명령을 사용하여 TCP/IP 구성 테스트
2. ping 명령과 net view 명령을 사용하여 TCP/IP 연결 테스트
3. tracert 명령을 사용하여 경로 추적
4. nbtstat 명령을 사용하여 NetBIOS 이름 테이블 보기
5. nbtstat 명령을 사용하여 NetBIOS 이름을 해제하고 새로 고치기
6. ARP(Address Resolution Protocol) 캐시 보기
7. 정적 ARP 캐시 항목 추가
8. 현재 TCP/IP 프로토콜 및 연결 통계 보기

1. ping 명령을 사용하여 TCP/IP 구성 테스트

1. 컴퓨터의 TCP/IP를 빠르게 구성하려면 명령 프롬프트를 연 다음 ipconfig를 입력합니다.
2. 명령 프롬프트에 ping 127.0.0.1를 입력하여 루프백 주소를 ping합니다.
  ping 명령이 실패하면 TCP/IP가 설치되고 구성된 후 컴퓨터를 다시 시작하였었는지를 확인합니다.
3. 컴퓨터의 IP 주소를 ping합니다.
  ping 명령이 실패하면 TCP/IP가 설치되고 구성된 후 컴퓨터를 다시 시작하였었는지를 확인합니다.
4. 기본 게이트웨이의 IP 주소를 ping합니다.
  ping 명령이 실패하면 기본 게이트웨이 IP 주소가 올바르고 게이트웨이(라우터)가 작동되는지 확인합니다.
5. 원격 호스트(다른 서브넷 상의 호스트)의 IP 주소를 ping합니다.
  ping 명령이 실패하면 원격 호스트 IP 주소가 올바른지, 원격 호스트가 작동되는지, 이 컴퓨터와 원격 호스트 간의 모든 게이트웨이(라우터)가 작동되는지 확인합니다.
6. DNS 서버의 IP 주소를 ping합니다.
  ping 명령이 실패하면 DNS 서버 IP 주소가 올바른지, DNS 서버가 작동되는지, 이 컴퓨터와 DNS 서버 사이의 모든 게이트웨이(라우터)가 작동되는지 확인합니다.

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*ping 명령이 없거나 실패하면 이벤트 뷰어를 사용하여 시스템 로그를 확인하여 설정 또는 인터넷 프로토콜(TCP/IP) 서비스에 의해 보고된 문제를 찾을 수 있습니다.

2. ping 명령과 net view 명령을 사용하여 TCP/IP 연결 테스트

1. ping 명령을 사용하여 TCP/IP 연결성을 테스트하려면 명령 프롬프트를 연 다음 IP 주소를 사용하여 원하는 호스트를 ping합니다.
  ping 명령이 실패하여 "요청 시간이 초과되었습니다."라는 메시지가 표시되면 호스트 IP 주소가 올바른지, 호스트가 작동되는지, 이 컴퓨터와 호스트 간의 모든 게이트웨이(라우터)가 작동되는지 확인합니다.
2. ping 명령을 사용하여 호스트 이름 확인을 테스트하려면 해당 호스트 이름을 사용하고 이름 확인을 원하는 호스트를 ping합니다.
  ping 명령이 실패하여 "알 수 없는 호스트"라는 메시지가 표시되면 호스트 이름이 올바른지, 사용자의 DNS 서버가 호스트 이름을 확인할 수 있는지를 확인합니다.
3. net view 명령을 사용하여 TCP/IP 연결을 테스트하려면 명령 프롬프트를 연 다음 net view \\computername을 입력합니다. net view 명령은 임시 NetBIOS 연결을 만들어 Windows 2000을 실행하는 컴퓨터의 파일 및 인쇄 공유를 목록으로 표시합니다. 지정된 컴퓨터에 파일 또는 인쇄 공유가 없으면 net view 명령은 "목록에 항목이 없습니다."라는 메시지를 표시합니다.
  net view 명령이 실패하여 "시스템 오류 53이 발생했습니다."라는 메시지가 표시되면 computername이 올바른지, Windows 2000을 실행하는 컴퓨터가 작동되는지, 이 컴퓨터와 Windows 2000을 실행하는 컴퓨터 사이의 모든 게이트웨이(라우터)가 작동되는지 확인합니다.

이 연결성 문제를 더 자세히 해결하려면 아래와 같은 작업을 수행합니다.

*ping 명령을 사용하여 computername을 ping합니다.
ping 명령이 실패하여 "알 수 없는 호스트"라는 메시지가 표시되면 해당 IP 주소에서 computername을 확인할 수 없습니다.
*net view 명령 및 Windows 2000을 실행하는 컴퓨터의 IP 주소를 아래와 같이 사용합니다.
net view \\IP address

net view 명령이 성공하면 잘못된 IP 주소에 computername이 연결되어 있습니다.

Windows 2000을 실행하는 컴퓨터가 Microsoft 네트워크용 파일 및 프린터 공유 서비스를 실행하고 있지 않으면 net view 명령이 실패하여 "시스템 오류 53이 발생하였습니다."라는 메시지가 표시됩니다.

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*ping 명령이 없거나 실패하면 이벤트 뷰어를 사용하여 시스템 로그를 확인하여 설정 또는 인터넷 프로토콜(TCP/IP) 서비스에 의해 보고된 문제를 찾을 수 있습니다.

3. tracert 명령을 사용하여 경로 추적

*명령 프롬프트를 연 다음 아래와 같이 입력합니다.
tracert host_name
또는  tracert ip_address를 입력합니다.

여기서 host_name 또는 ip_address는 각각 원격 컴퓨터의 호스트 이름 또는 IP 주소입니다.

예를 들어, 이 컴퓨터에서 www.microsoft.com으로 연결 경로를 추적하려면 명령 프롬프트에 아래와 같이 입력합니다.

tracert www.microsoft.com

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*tracert 명령은 이 컴퓨터에서 다른 원격 컴퓨터까지의 TCP/IP 패킷의 경로를 추적합니다. tracert 명령은 ICMP echo 요청 및 응답 메시지(ping 명령과 비슷)를 사용하여 각 홉에 대한 왕복 이동 시간(RTT) 및 전달되는 각 라우터에 대한 명령줄 보고서를 출력합니다.
*tracert가 성공하지 못하면, 명령 출력을 사용하여 전달에 실패하거나 느려진 중간 라우터를 결정하는 것을 도울 수 있습니다.

4. nbtstat 명령을 사용하여 NetBIOS 이름 테이블 보기

1. 명령 프롬프트를 엽니다.
2. 명령 프롬프트에서 아래와 같이 입력합니다.
nbtstat -n

이 컴퓨터의 NetBIOS 로컬 이름 테이블은 명령줄 출력으로 표시됩니다. 이름 형식이 표시되어 각각의 이름이 고유 이름인지 또는 그룹 이름인지 나타냅니다. 또한 이름이 네트워크에 등록되었는지의 여부를 나타내는 각 이름의 상태가 표시됩니다.

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*nbtstat 명령은 TCP/IP(NetBT) 연결에서 NetBIOS가 사용하는 통계 및 이름 정보를 표시합니다. -n 옵션은 이 컴퓨터에 대한 로컬 NetBIOS 이름만 목록으로 표시하는 데 사용됩니다. nbtstat를 사용하여 아래와 같은 작업을 수행할 수도 있습니다.
*원격 컴퓨터의 NetBIOS 이름 테이블 목록 표시
*이 컴퓨터 또는 다른 원격 컴퓨터에 NetBIOS 이름 캐시의 내용 표시
*Lmhosts 파일에 있는 항목을 #PRE 옵션과 함께 사용하여 NetBIOS 이름 캐시 수동으로 로드 또는 다시 로드
*TCP/IP 세션 통계에서 NetBIOS 목록 표시
*WINS에서 NetBIOS 이름 해제 및 새로 고침

5. nbtstat 명령을 사용하여 NetBIOS 이름을 해제하고 새로 고치기

1. 명령 프롬프트를 엽니다.
2. 명령 프롬프트에서 아래와 같이 입력합니다.
nbtstat -RR

해제 및 새로 고침 작업의 진행률은 명령줄 출력으로 표시됩니다. 이 정보는 이 컴퓨터에 대해 WINS에 현재 등록된 모든 로컬 NetBIOS 이름이 WINS 서버로 등록을 해제하고 갱신하였는지 나타냅니다.

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*NetBIOS 이름은 WINS와 함께 등록되며 일반적으로 컴퓨터가 정상적으로 종료될 때 해제됩니다. 컴퓨터가 정상적으로 종료되지 않았거나 컴퓨터 이름을 종료 및 해제하는 동안 WINS 서버를 연결할 수 없었으면 이 명령을 사용하여 이 컴퓨터에 대한 로컬 이름을 WINS에서 새로 고치고 업데이트할 수 있습니다. 이것은 네트워크의 다른 위치들 사이에서 이동되는 이동식 컴퓨터 또는 휴대용 컴퓨터에 유용합니다.
*nbtstat 명령을 사용하여 아래와 같은 작업을 할 수도 있습니다.

이 컴퓨터 또는 다른 원격 컴퓨터에 등록된 NetBIOS 이름 목록 표시
이 컴퓨터 또는 다른 원격 컴퓨터에 NetBIOS 이름 캐시의 내용 표시
#PRE 옵션과 함께 Lmhosts 파일에 있는 항목을 사용하여 NetBIOS 이름 캐시 수동으로 로드 또는 다시 로드
TCP/IP 세션 통계에서 NetBIOS 목록 표시

6. ARP(Address Resolution Protocol) 캐시 보기

1. 명령 프롬프트를 엽니다.
2. 명령 프롬프트에 arp -a를 입력합니다.
예를 들어, 최근에 ping 명령을 사용하여 이 컴퓨터에서 IP 주소 10.0.0.99인 호스트 컴퓨터으로의 연결을 테스트 및 확인한 경우에는 ARP 캐시에 아래 항목이 표시됩니다.

인터페이스: 인터페이스 0x1의 10.0.0.1
인터넷 주소 실제 주소 형식
10.0.0.99 00-e0-98-00-7c-dc dynamic

이 예에서 캐시 항목은 10.0.0.99의 원격 호스트 컴퓨터가 원격 컴퓨터의 네트워크 어댑터 하드웨어에 지정된 미디어 액세스 제어 주소 00-e0-98-00-7c-dc로 확인됨을 나타냅니다. 미디어 액세스 제어 주소는 네트워크에서 컴퓨터가 이 원격 TCP/IP 호스트와의 실제 통신에 사용한 주소입니다.

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*Windows 2000은 나중에 사용할 수 있도록 하드웨어-투-소프트웨어 주소 매핑의 캐시를 유지하여 네트워크에서 ARP 브로드캐스트 트래픽을 최소화합니다. 이 캐시에는 아래와 같은 두 가지 종류의 항목이 포함됩니다.
*동적 ARP 캐시 항목
이 항목들은 원격 컴퓨터에서 TCP/IP 세션을 정상적으로 사용하는 동안 자동으로 추가되고 삭제됩니다. 동적 항목은 2분 내에 다시 사용되지 않으면 캐시에서 만료됩니다. 동적 항목을 2분 내에 다시 사용하는 경우에는 동적 항목이 캐시에 남아 있을 수 있고 ARP 브로드캐스트 작업을 사용하여 제거하거나 캐시 갱신을 요청할 때까지 최대 캐시 수명인 10분까지 유지될 수 있습니다.

정적 ARP 캐시 항목
이 항목은 arp 명령을 -s 옵션과 함께 사용하여 수동으로 추가됩니다. 정적 항목은 컴퓨터가 다시 시작될 때까지 ARP 캐시에 남아 있습니다.

7. 정적 ARP 캐시 항목 추가

명령 프롬프트를 엽니다.
명령 프롬프트에서 아래와 같이 입력합니다.
arp -s ip_address mac_address

각각의 의미는 아래와 같습니다.

ip_address   같은 서브넷의 로컬 TCP/IP 노드의 IP 주소를 지정합니다.
mac_address 로컬 TCP/IP 노드에 설치되어 사용되는 네트워크 어댑터의 미디어 액세스 제어 주소를 지정합니다.

예를 들어, 00-10-54-CA-E1-40의 미디어 액세스 제어 주소를 확인하는 10.0.0.200의 IP 주소를 사용하여 로컬 TCP/IP 노드에 정적 ARP 항목을 추가하려면 명령 프롬프트에 아래와 같이 입력합니다.

arp -s 10.0.0.200 00-10-54-CA-E1-40

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*정적 ARP 항목은 자주 사용되는 호스트에 대한 빠른 액세스를 도와 줄 수 있습니다.
*정적 항목은 Windows 2000이 다시 시작될 때 까지만 유효합니다. 정적 ARP 캐시 항목을 영구적으로 만들기 위해 arp 명령을 시스템이 시작할 때 실행되는 일괄 파일에 추가할 수 있습니다.

8. 현재 TCP/IP 프로토콜 및 연결 통계 보기

1. 명령 프롬프트를 엽니다.
2. 명령 프롬프트에서 아래와 같이 입력합니다.
netstat

참고
*명령 프롬프트를 열려면 시작을 클릭하고 프로그램, 보조프로그램을 차례로 가리킨 다음 명령 프롬프트를 클릭합니다.
*netstat 명령줄 옵션을 보려면 아래와 같이 입력합니다.
netstat /?

라우터에서 액세스 리스트는 패킷 필터링, QoS, 라우팅 프로토콜 관련 정책 등 다방면으로 사용된다. 그런데, 액세스 리스트를 사용하다 보면 한가지 불만이 생긴다. 왜 액세스 리스트는 이해하기 편한 서브넷 마스크를 사용하지 않고 어렵고 복잡한 와일드카드 마스크를 이용할까. 이 문제에 대해 우스게 소리로, 한 친구는 "액세스 리스트를 잘못 설정하면 네트워크에 큰 영향을 끼칠 수 있기 때문에 일부러 어렵게 만들어서 네트워크를 잘 모르는 사람은 아예 사용할 수 없도록 하기 위해서"라고 하기도 했다.
액세스 리스트가 서브넷 마스크 대신 와일드카드 마스크를 고집하는 데는 분명 이유가 있을 것이다. 하지만 네트워크 교재나 기술 문서를 아무리 찾아봐도 이 부분에 대해 언급한 내용은 없었다. 예전에 뉴스그룹에서 이것에 대해 토론 공방이 있었는데 그 중에서 가장 신빙성이 있고 현실적으로 피부에 와닿는 내용이 있어서 대략적으로 정리해보도록 하겠다.

액세스 리스트는 필수적으로 갖춰야 할 조건이 있다. 여러 조건이 있겠지만, 그 중에서  가장 기본이 되는 것은 구현할 수 있는 방법이 많아야 되고 효율적이어야 한다는 것이다. 만약 서브넷 마스크를 이용하면 구현할 수 있는 방법이 몇 가지 밖에 안되지만, 와일드 카드 마스크를 이용하면 그것의 몇 배 혹은 몇 십배 이상 많다면 어떨까? 그리고 서브넷 마스크를 이용하면 수십, 수백 줄의 라인이지만, 와일드카드 마스크를 이용하면 단 몇 줄로 줄어든다고 한다면 어떨까?
당연히 액세스 리스트의 라인 갯수가 줄어들면 CPU가 처리해야 될 양이 줄어들고 절약도 된다. 그리고 관리자가 세팅해야 될 환경설정이 수십 줄 줄어든다면, 네트워크 관리자도 오히려 더 편할 것이다. 추측하건데 이 같은 여러 가지 점을 고려할 때 와일드카드 마스크를 사용하지 않았을까 한다.
다음 두 가지 상황에 대해 서브넷 마스크를 이용해 구현하는 방법과 와일드카드 마스크를 이용해 구현하는 방법을 비교해 보자.

[1] 짝수 번호만 필터링하는 예제(100.100.100.0/24 기준)

(1) 서브넷 마스크(약 120여 줄)

access-list 100 deny ip 100.100.100.2 255.255.255.255
access-list 100 deny ip 100.100.100.4 255.255.255.255
access-list 100 deny ip 100.100.100.6 255.255.255.255
...
...
access-list 100 deny ip 100.100.100.250 255.255.255.255
access-list 100 deny ip 100.100.100.252 255.255.255.255
access-list 100 deny ip 100.100.100.254 255.255.255.255   
access-list 100 permit ip any any

(2) 와일드카드 마스크(2줄)

access-list 101 deny ip 100.100.100.0 0.0.0.254
access-list 101 permit ip any any
    
짝수 번호의 특징은 마지막 비트(32번째)가 모두 0이라는 점이다.

(표 1)에서 보듯이 첫번째 비트부터 31번째 비트에는 어떤 수가 와도 괜챦다(don't care)는 것이다. 이것은 와일드카드 마스크의 개념인 don't care bit(그림에서 x로 표시)에 아주 적합한 내용이다.

[2] 좀 더 범위를 크게 잡아 보도록 하자

전체 IP 100.100.0.0/16, 각 서브넷은 C클래스 디폴트(255.255.255.0)를 사용, 각 서브넷의 디폴트 게이트웨이(라우터) IP 어드레스는 모두 1번임, 모든 네트워크(255개)에서 각 네트워크의 디폴트 게이트웨이 IP 어드레스인 100.100.x.1으로 들어오는 패킷을 막고 나머지를 모두 허용하는 경우

(1) 서브넷 마스크(약 250여 줄)
             
access-list 100 deny ip any 100.100.1.1 255.255.255.255
access-list 100 deny ip any 100.100.2.1 255.255.255.255
...
...
access-list 100 deny ip any 100.100.253.1 255.255.255.255
access-list 100 deny ip any 100.100.254.1 255.255.255.255
access-list 100 permit ip any any

(2) 와일드카드 마스크(2줄)

access-list 101 deny ip any 100.100.255.1 0.0.255.0 
access-list 101 permit ip any any

서브넷 마스크는 불연속적인 0과 1을 사용하지 못하지만, 와일드카드 마스크는 불연속적인 0과 1을 허용하는 것이 가장 큰 차이점이다. 결론적으로 각 비트를 펼쳐 놓고 이것은 x(don't care 비트)로 표현하면 이것이 결국은 와일드카드 마스크로 축약된다는 것이다.