본문 바로가기
조회 수 8535 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print
?

단축키

Prev이전 문서

Next다음 문서

+ - Up Down Comment Print

http://cafe.naver.com/neteg/66391


VI. IP QoS

 

QoS‘Quality of Service’의 약자로 서비스 품질의 보장정도로 해석할 수 있다. 인터넷은 원래 ‘Best Effort’ , 아무런 QoS가 없는 형태로 디자인 되어 있다. Best Effort데이터 전송을 위해 최선을 다하는 형태정도로 해석이 될 수 있지만, 사실상 데이터 전송에 대한 아무런 정책이 없는 상태를 의미한다. 이런 환경에서는 네트워크에 혼잡(congestion)이나 지연(delay)이 발생해도 아무런 대안없이 방치되어 버린다

 

FTP P2P같은 일반 데이터 패킷의 경우에는 QoS가 없더라도 궁극적으로 원하는 데이터의 전송만 완료되면 아무런 이슈가 발생되지 않는다. FTP 같은 트래픽의 경우는 데이터 전송 중단간에 딜레이(지연; delay)가 발생하더라도 최종적으로 데이터 수신만 완료되면 별다른 문제가 제기되지 않기 때문이다. 그러나 비디오(방송)나 보이스(전화)같은 실시간 스트림 형태의 트래픽들은 얘기가 달라진다. 전화의 경우 통화 도중에 딜레이가 발생한다면 이는 서비스 퀄리티에 치명적인 악조건으로 문제시 되기 때문이다. 이런 사유로 네트워크에서는 패킷 또는 서비스의 종류에 따라 상이한 정책이 요구되어 지며, 경우에 따라서는 일반 패킷에 패널티를 주는한이 있더라도 보다 중요한 패킷이나 서비스에 대해 우선권을 보장하여야 한다. 이러한 개념이 바로 QoS가 필요한 이유이며 여러가지 QoS 정책이 존재해야 하는 원인이다.

 

이번 장에서는 네트워크에 트래픽의 혼잡이 발생하였을 경우, 이를 제어하기 위한 혼잡 관리(congestion Management) 기술과 혼잡 자체가 발생하지 않게 원천적으로 차단하는 혼잡 회피(Congestion avoidance) 기술에 대한 학습을 하게 될 것이다. 또한 관리자가 설정한 임계치 이상의 트래픽에 대한 처리를 위한 폴리싱(policing)과 셰이핑(shaping)기술에 대한 차이도 정확히 학습하게 될 것이다. 그리고 시스코 라우터나 스위치에 QoS를 설정하기 위한 대표적인 세가지 방법인 MQC(Modular QoS CLI)에 대해 학습해 보도록 하자.<?xml:namespace prefix = o /><?xml:namespace prefix = o />

 

[표 – QoS 출제 범위]

Quality of service solutions

QoS Models

QoS Mechanisms

- Classification

- Congestion management

- Congestion avoidance

- Policing and shaping

- Compression

- Link efficiency mechanisms

Modular QoS command line

 

 

 

 

!======================================================================================

 

 

 

1. Quality of Service solutions

 

QoS는 왜 필요할까? 간단히 말하자면 QoS는 네트워크에 혼잡(congestion)이 발생하기 때문에 필요하다. 네트워크에 혼잡은 다양한 사유로 발생하는데, 일반적으로 대역폭(bandwidth)의 부족이나 병목현상(bottle neck)등이 그 원인이다. 이 외에도 네트웍에서는 앞서 설명한 다양한 종류의 딜레이, 지터, 패킷 로스등의 다양한 이슈가 발생할 수 있기 때문에 중요한 패킷에 대한 우선적인 취급이 중요하다. 결국 QoS특정 사용자 또는 어플리케이션에 양질의 또는 특별한 서비스를 제공하기 위해, 상대적으로 덜 중요한 다른 유저와 어플리케이션에 손해를 주는 정책이라고 정의할 수 있다.

 

앞서 설명했듯이 IP 네트워크는 일반적으로 데이터의 단순한 전송만을 목적으로 개발되었다. 그러나 오늘날의 BCN(Broadband Converged Network) 또는 NGNA(Next Generation Network Architecture)의 경우에는 IP 망을 기반으로 데이터, 보이스, 비디오등이 융합되어 전달되게 된다. 보이스나 비디오의 경우 딜레이에 민감하고 재전송이 사실상 무의미하므로 최초 전달시에 반드시 그 품질을 보장해 주어야 한다.

 

[보이스 & 비디오 스트림의 특징]

구분

보이스(Voice)

비디오(Video)

데이터(Data)

허용 지연시간

150ms

150ms

딜레이 허용

지터

30ms

30ms

지터 허용

로스

1%

1%

재전송 허용

데이터 사이즈

저용량

(60~120byte)

일반적으로 고용량

(코덱/해상도에 의존)

저용량/고용량 공존

스트림 유형

주기적이며 일정

주기적이지만 가변적

랜덤하며 가변적

중요도

~

 

보이스와 비디오같은 실시간 스트림의 경우 대역폭 부족뿐만 아니라 딜레이(delay), 지터(jitter), 패킷 로스(packet loss)등의 다양한 이슈들에 상당히 취약하다. FTP와 같은 TCP를 사용하는 데이터들은 패킷 로스가 발생하여도 재전송으로 해결할 수 있지만, 비디오와 보이스 같은 스트림은 대부분 UDP를 사용하므로 패킷의 드랍은 재전송으로 해결이 불가능하다. 또한 비디오와 보이스는 실시간 수신이 아니면 의미가 없으므로, 재전송이 가능하다고 하더라도 의미가 없다.

 

[– IP 네트웍의 서비스 품질 이슈]

구분

설명

대역폭 부족

 

여러개의 데이터 플로우가 제한된 대역폭에서 경쟁하게 될 때 발생함

종단간 딜레이

 

패킷이 여러 개의 네트워크 장비와 링크들을 지나갈 때 발생하는 딜레이(지연)을 총 합산한 시간

가변 딜레이(지터)

 

이따금 유입되는 다른 트래픽으로 인해 발생하는 추가적인 딜레이

패킷 로스

 

네트워크 장비의 링크상에서 트래픽 혼잡이 발생할 경우 발생할 수 있는 패킷의 누수 또는 손실

 

이번장에서는 IP망에서 전송되는 보이스와 비디오 스트림의 특징과 발생될 수 있는 다양한 이슈와 이에 대한 대안을 정의해 보도록 하자.

 

 

 

1) 대역폭 부족 (Lack of Bandwidth)

 

대역폭의 부족은 일반적으로 두가지 사유로 발생한다. 먼저 패킷이 유입되는 인터페이스는 여러 개인데 반해 유출되는 인터페이스가 더 적은 경우 발생한다. 예를들어 100Mbps 인터페이스 5개에서 패킷이 유입되는 반면, 유출될 인터페이스가 100Mbps 1개 뿐인 경우이다. 두번째로는 인터페이스간 대역폭 미스매치인 경우이다. 패킷이 유입되는 인터페이스의 대역폭이 100Mbps인데, 패킷이 유출될 인터페이스의 대역폭이 10Mbps만 지원할 경우도 마찬가지이다.

 

일반적으로 네트웍 종단간의 최대 가용 대역폭(maximum available bandwidth)은 그 네트웍상에 존재하는 가장 저속의 대역폭과 동일하다. 일종의 병목현상 때문에 발생하는 이슈라고 보면 된다. 만약 어플리케이션의 입장에서 본다면, 다른 수많은 트래픽 플로우가 있는 환경에서 상호간에 대역폭을 잠식하게 되는 경우에도 동일하게 대역폭 부족을 경험하게 될 것이다.

 

이에 대한 대안은 몇가지가 있다. 먼저 가장 좋은 방법은 당연히 대역폭을 확장하는 것이다. , 100Mbps 인터페이스를 1Gbps 인터페이스로 확장하는 방법이다. 그러나 현실적으로 추가적인 시간, 비용, 인력이 투입되어야 하는 단점이 있다. 반대로 물리적인 대역폭은 그대로 두고 대역폭을 효율적으로 사용하는 방법도 있다. 압축(compress)하는 방법인데, 이는 L2 프레임의 페이로드 부분 또는 L3 IP 패킷의 헤더를 압축하는 방식이다. 마지막으로 CISCO 라우터상에서 IP QoS 기술을 사용하는 방법이 있다. 후에 설명할 PQ, CQ, MDRR, WFQ, CBWFQ, LLQ등의 기술을 사용하여 우선 순위가 있는 패킷을 먼저 처리하는 기법들이다.

 

 

 

2) 종단간 딜레이 (End-to-End Delay)

 

최초로 패킷을 발송한 호스트와 이를 수신할 호스트 사이에는 수많은 네트워크 장비와 인터페이스(링크), 그리고 물리적인 케이블들이 존재한다. 종단간 딜레이는 송신 호스트로부터 떠난 패킷이 목적지 호스트에게 최종적으로 수신되는 시간차를 의미하므로, 결국 종단과 종단간에 존재하는 모든 구간의 딜레이의 합산이라고 보면 된다. 딜레이는 다양한 사유로 발생되는데 일반적으로 프로세싱 & 큐잉 딜레이, 프로퍼게이션 딜레이 그리고 시리얼라이제이션 딜레이로 구분된다.

 

[딜레이의 종류]

구분

설명

프로세싱 딜레이

(Processing Delay)

라우터가 인터페이스로 패킷을 수신한 후에 CPU등을 경유하여 아웃풋 인터페이스의 아웃푼 큐(queue)에 도달하는데 걸리는 시간

큐잉 딜레이

(Queuing Delay)

라우터의 아웃풋(output) 인터페이스의 큐에 패킷이 대기하는 시간

프로퍼게이션 딜레이

(Propagation Delay)

물리적인 광(fiber optic) 또는 구리(copper) 케이블 통과하는 데 소요되는 시간

시리얼라이제이션 딜레이

(Serialization Delay)

패킷이 비트화 되어 케이블로 전달되기까지 걸리는 시간

 

이에 대한 대안으로 가장 좋은 방법은 물리적인 인터페이스 즉, 링크의 대역폭을 확장하는 방법이지만 역시 가장 많은 비용이 소요된다. 앞서 설명했듯이 CISCO IOS의 기능을 이용하여 딜레이에 민감한 패킷들을 우선적으로 처리하는 방법이 있다. PQ, CQ, MDRR, LLQ등의 기술이 있다. 그외에 앞서와 마찬가지로 L2 프레임의 페이로드 또는 L3 패킷의 헤더를 압축하면 패킷의 사이즈가 작아지므로 빨리 처리할 수 있다. 보이스 패킷은 페이로드에 비해 헤더가 크므로 RTP 헤더 압축을 통해 딜레이를 줄일 수 있다.

 

 

 

3) 패킷 로스 (Packet Loss)

 

만약 라우터의 아웃풋 인터페이스의 큐가 가득찬다면 패킷의 태일-드랍(tail-drop)이 발생한다. 그외에도 다양한 사유로 패킷은 유실될 수 있는데, 일반적으로 라우터에서 혼잡이 발생하거나 아웃풋 인터페이의 큐와 같은 버퍼가 패킷으로 가득찰 경우, 뒤에 들어온 패킷이 저장되지 못하고 버려지는 현상이다. 여기에는 인풋 큐 드랍, 이그노어, 오버런, 프레임 에러등이 있다.

 

구분

설명

인풋 큐 드랍

(Input queue drop)

CPU에서 혼잡이 발생하여 더 이상 패킷에 대한 프로세싱이 불가능 할 경우에 인풋 큐가 가득 차면 발생함

이그노어

(Ignore)

라우터의 버퍼 영역이 가득 차게 되면 발생함

오버런

(Overrun)

CPU에 혼잡이 발생한 상태에서 유입된 새로운 패킷을 버퍼의 빈공간에 할당하지 못할 경우 발생함

프레임 에러

(Frame error)

유입된 프레임상에서 CRC등의 하드웨어 에러가 감지될 경우 발생함

 

패킷 로스에 대한 대안으로는 앞서와 동일하게 대역폭을 확장하는 방법이 있다. 그리고 중요한 패킷들에 대해서는 대역폭을 보장하는 방법이 있다. 그외에 혼잡이 발생하기 전에 보다 덜 중요한 패킷을 먼저 버려서 혼잡이 발생하는 것 자체를 사전에 방지하는 방법이 있다.

 

아이러니하게도 패킷 유실을 방지하기 위해 사전에 고의로 패킷을 유실시키는 방법이다. 이는 RED(Rendom Early Detection)라고 부르는데 TCP 슬로우다운(slowdown) 현상을 막기 위함이다. TCP의 경우 세션이 열리게 되면 데이터 전송시에 윈도우 사이즈(window size)를 조절하게 된다. TCP 세션이 열린후의 윈도우 사이즈는 작지만, 이를 점점 키워가게 되므로 시간이 지나면 최초에 비해 동일 시간동안 훨신 많은 패킷을 처리하게 되는 알고리즘이다. 만약 네트워크에 혼잡이 발생하여 TCP 세션이 닫히게 되거나 윈도우 사이즈를 줄이게 된다면 데이터의 재전송률은 급속하게 경감되기 때문이다.

 

RED의 경우에는 단점이 있다. 말 그대로 랜덤하게 아무 패킷이나 버리기 때문에, 보이스나 비디오 같은 우선순위가 높으면서도 재전송이 불가능한 패킷도 버려질 수 있기 때문이다. 그래서 이에 대한 대안으로 WRED(Weighted RED) 기술이 제공된다. WRED는 상대적으로 덜 중요한 패킷을 버림으로써 보이스와 비디오 같은 중요한 패킷에 대한 유실을 방지하는 기술이다.

 

 

 

!======================================================================================

 

 


2. QoS Models (Signaling)

 

IP 네트워크에서는 QoS를 보장하기 위한 세가지 유형의 모델이 있다.

구분

설명

Best-Effort (BE)

아무런 QoS도 설정되지 않은 상태를 의미한다.

IntServ

네트워크에 혼잡 발생이 예견될 경우, 이를 방지하기 위해 사전에 이를 제어하기 위한 어플리케이션 시그널을 앞단 장비에 전달하여 트래픽 흐름을 통제하는 방법이다.

DiffServ

네트워크에 혼잡 발생한 경우, 클래스 등급별로 정의된 정책에 따라 패킷의 처리 우선 순위를 결정하는 방법이다.

 

Best-Effort 모델은 아무런 QoS가 설정되지 않은 IP 네트워크를 의미한다. 대역폭이 충분하거나 별도의 QoS 정책이 필요하지 않은 상태를 의미하며, 뒤에 언급할 다양한 큐잉(queuing)기술중에 FIFO(first in first out)를 사용하는 상태를 의미한다. 아무런 QoS 정책도 없는 상태이므로 구현 방법이나 확장성등은 뛰어나지만 중요한 패킷에 대한 아무런 전송 보장을 할 수 없는 상태이다.

 

IntServ 모델은 아주 중요한 IP 패킷에 대해 QoS의 높은 우선순위를 제공할 수 있다. 이는 아주 중요한 패킷이 네트워크상에서 수신될 경우를 대비하여 라우터간에 어플리케이션 레벨에서 네트워크의 혼잡을 통제하기 위한 시그널링을 하는 경우를 의미한다. 네트워크상에서 데이터 전송이 라우터간에 제어가 되므로 혼잡이 발생하지 않아 전송에 대한 확실한 보증이 가능하지만, 확장성 등의 이슈로 사용이 어렵다.

 

DiffServ 모델은 확장성과 유연성측면에서 뛰어나므로 네트워크에 QoS를 적용하기에 유리하다. 다만 혼잡이 발생한 상황에서 클래스별로 적용한다는 단점과, 라우터와 같은 네트워크 홉마다 각각 설정해 주어야 하는 불편함이 있다. 그러나 현실적으로 가장 선호되는 방식이며 CCIE R&S 시험의 QoS 파트도 여기에 포커싱 하고 있다.

 

그럼 여기서는 이 세가지 모델에 대해 자세히 알아보도록 하자.

 

 

 

1) Best-Effort 모델

 

베스트 에포트(best-effort)라는 말을 우리식으로 표현한다면 최선을 다한다라는 의미로 번역될 수 있다. 사실 최선을 다한다라는 것은 상당히 긍정적인 표현이지만, 다른 의미로 표현한다면 전송을 위한 효과적인 방법론이나 구체적인 정책없이 단순히 상황이 좋으면 많이 전송하고, 상황이 좋지 않으면 상황에 맞게 전송한다는 표현이다. 결국 베스트 에포트란 전송에 대해 아무런 보증을 하지 않겠다는 의미이다.

 

이 모델의 대표적인 케이스가 바로 인터넷인데, 패킷 전송에 대한 아무런 보장도 없는 상태를 의미한다. 어떠한 QoS 정책도 적용되지 않은 기본적인 전송 상태를 의미하는데, 이는 데이터간의 우선순위를 위한 클래스 개념이 존재하지 않기 때문에 보이스나 비디오 같은 중요한 패킷도 일반 데이터 패킷처럼 처리해 버린다.

 

베스트-에포트 모델의 장점으로는 높은 확장성과 별도의 메커니즘을 사용하지 않는다는 단순성정도이다. 단점으로는 데이터 전송에 대한 보증이나 차별화된 서비스가 불가하다는 것이다. 사실 베스트 에포트 모델은 뒤에서 설명할 인트서브(IntServ)와 디프서브(DiffServ)를 설명하기 위한 비교 대상일 뿐, 그 자체로는 아무런 의미가 없다.

 

 

 

2) IntServ 모델

 

인트서브(IntServ)‘Integrated Services Model)의 약자로 통합 서비스 모델정도로 풀이된다. 앞서도 설명했지만 QoS라는 것은 혼잡이 발생하기 때문에 필요한 기술인데, 인트서브는 혼잡 자체를 사전에 방지하는 기술이므로 이론적으로는 가장 바람직한 방법이다. 그러나 뒤에서 설명하겠지만 사전에 혼잡을 방지한다는 것은 상당히 어렵기 때문에 현실적으로 디프서브(DiffServ) 모델에 비해 사용빈도가 떨어진다.

 

인트서브는 보이스와 비디오처럼 최소 대역폭과 최소 딜레이가 보장되어야 하는 어플리케이션 또는 서비스를 위해 사용되어 진다. 인트서브 모델은 이러한 어플리케이션을 위한 네트워크의 상태 예측과 이에 대한 보장을 위해 도입되어 졌다. 이것은 마치 고속도로의 갓길과도 같은 것으로 다른 어떤 트래픽은 이 대역폭을 절대 사용할 수 없다.

 

인트서브의 장점은 다음과 같다. 첫번째로 종단간 자원 관리를 확실히 제어할 수 있다. 두번째로 관리자의 정책 기반에 의한 통제가 가능하며, 세번째로 H.323같은 다이나믹 포트 넘버를 사용한 시그널링이 가능하다. 단점으로는 첫번째로 네트워크 상황에 대해 진단하며 지속적으로 시그널링을 해야만 한다는 것이다. 두번째로는 데이터 또는 서비스 플로우 단위로 제어해야 하기 때문에 인터넷과 같은 여러 사업자가 연동된 대규모 네트워크에서는 현실적으로 사용이 불가능하다는 점이다. 이런 사유로 앞서도 언급했듯이 인트서브 모델은 이론적으로는 가장 이상적인 모델이지만 현실적으로 인터넷과 같은 환경에서는 적용하기가 어렵다. 그럼 이번에는 인트서브의 대표적인 프로토콜인 RSVP에 대해 알아보자.

 

 

 

RSVP

 

RSVP‘Resource ReserVation Protocol’의 약자로 네트워크 가용 자원 예약 프로토콜정도로 해석이 될 수 있다. 이는 VoIP(Voice over IP) 네트워크에서 QoS를 수행하여 가용 자원을 보장하기 위해 사용되는 프로토콜이다. RSVP는 일종의 IP 서비스로서 라우터가 존재하는 네트웍에서 호스트와 같은 종단(end-to-end) 시스템간에 데이터 전송시 QoS를 확립하고 대역폭을 보장하기 위해 제공되어 진다. RSVP는 현재로서는 종단간 대역폭 보장을 위한 사실상의 유일한 표준 프로토콜이다.

 

일반적으로 LLQ 또는 WRED RSVP를 위해 사용되어 진다. 이는 데이터의 플로우에 대한 서비스 예약이 필요한 경우에 패킷의 분류와 전송 스케줄링을 하기 위해 사용되어 진다. 아래는 시스코 라우터에서 글로벌과 인터페이스 모드에서의 RSVP에 대한 설정 사례이다.

 

[– RSVP /w LLQ 설정]

! RSVP 글로벌 설정

R1(config)#ip rsvp ?

  listener          Configure RSVP Listener

  msg-pacing        Enable RSVP Output msg-pacing

  policy            Policy control commands

  pq-profile        <?xml:namespace prefix = st1 /><?xml:namespace prefix = st1 /><?xml:namespace prefix = st1 />Configure PQ traffic profile for RSVP flows

  reservation       Configure static RSVP Reservation Information

  reservation-host  Configure static RSVP host Reservation Information

  sender            Configure static RSVP Path Information

  sender-host       Configure static RSVP host Path Information

  signalling        RSVP Signalling

 

! RSVP 인터페이스 설정

R1(config-if)#ip rsvp ?

  admission-control  RSVP Admission Control

  authentication     Enables RSVP neighbor cryptographic authentication (RFC

                     2747)

  bandwidth          RSVP Reservable Bandwidth (kbps)

  burst              RSVP burst

  data-packet        RSVP data packet

  flow-assist        Install RSVP feature in fast path

  layer2             Layer 2 RSVP settings

  neighbor           Select permissible RSVP neighbors

  precedence         RSVP precedence setting

  resource-provider  RSVP resource provider

  signalling         RSVP signalling

  tos                RSVP TOS setting

  udp-multicasts     Use RSVP UDP Multicasts

PQ CBWFQ를 혼용한 기술이 LLQ이다.

 

 

 

3) DiffServ 모델

 

디프서브(DiffServ)‘Differentiated Services Model)의 약자로 차별화된 서비스 모델정도로 풀이된다. 인트서브가 네트워크에서 발생될 혼잡을 사전에 방지하는 것과는 달리, 디프서브는 네트워크에 혼잡이 발생한 경우 중요한 패킷을 먼저 포워딩하기 위한 기술로 풀이된다. 이를 위해서 일반적으로 패킷들은 관리자가 사전에 정의해 둔 클래스라고 불리는 그룹에 소속이 되게 된다. 이 클래스마다 각기 다른 QoS 정책들이 적용되고, 이 정책에 따라 패킷들은 적절히 우선순위가 주어진다던가 선폐기등의 정책이 적용된다.

 

일반적으로 인트서브가  하드(hard) QoS’라고 불리는 반면 디프서브는 소프트(soft) QoS’라고 불리운다. 인트서브가 혼잡을 방지하기 위해 사전에 시그널링을 보내는 방법을 사용하는 반면, 디프서브는 시그널링 없이 혼잡 발생시 QoS를 적용하는 방식을 사용하기 때문이다. 이런 사유로 디프서브는 종단간에 걸친 QoS 전략없이 단순히 홉단위(hop-by-hop)의 정책에 의한 트래픽 관리만이 존재한다.

 

디프서브의 장점을 보자. 디프서브는 홉 즉, 개별 라우터 단위로 정책을 적용할 수 있기 때문에 확장성에서 유리하다. 또한 다양한 클래스를 만들고, 각 클래스별로 다양한 정책을 적용할 수 있다. 그러나 혼잡이 발생한 이후 허용된 범위 내에서 QoS를 적용하기 때문에 정의된 클래스에 대해 절대적인 서비스 품질을 제공할 수 없다는 단점이 있다. 그리고 상당히 다양한 기술이 존재하고 메커니즘도 복잡하다는 단점이 있다.

 

그럼 이번에는 디프서브의 기술의 기반이 되는 DSCP 및 이와 관련된 IP Precedence등에 대해 알아 보도록 하자. 일반적으로 디프서브에서 QoS 적용을 위해 패킷을 클래스에 유입시키기 위해서는 패킷에 대한 감정(identify)하고 적절하게 분류해야 한다. 패킷에 대한 인지 포인트는 프로토콜, IP 어드레스, 포트등을 사용하면 된다. 그러나 패킷에 이미 클래스가 마킹되어 있거나 또는 관리자가 마킹할 수 있다면 디프서브에서 홉단위로 이루어지는 패킷에 대한 감정이 쉬워질 것이다.

 

이런 사유로 모든 IP 패킷의 헤더에는 ToS(Type of Service)라는 필드가 1바이트 존재한다. 일반적으로 DSCP IP Precedence는 이 필드를 적절히 활용함으로써 패킷을 쉽게 감지하고 분류할 수 있으므로 클래스화하기 용이하다. ToS 필드는 8비트중 최초 3비트만을 사용하여 8개의 클래스로 구분되는 IP Precedence 기술과 최초 6비트를 사용하여 64개의 클래스로 구분되는 DSCP 기술이 있다. 마지막의 2비트는 WRED와 같은 패킷의 사전 드랍에 대한 가능성을 표기하는데 사용되며 4가지 클래스로 우선 순위를 설정할 수 있다.

 

[그림 – ToS 필드내의 IP Precedence DSCP 필드]

IP Precedence RFC 791 1812, DSCP RFC 2474에 정의되어 있다.

 

 

 

IP Precedence

 

TOS 필드는 1byte , 8bit로 구성되는데 최초의 3비트를 사용하는 기술을 IP precedence라고 한다. IP precedence 3비트를 사용하므로 000, 001, 010, 011, 100, 101, 110, 111이라는 8가지 경우의 수가 나온다. 이런 사유로 IP precedence 8개의 클래스를 사용할 수 있다. 패킷의 TOS 필드중 최초 3비트만 사용하는 경우를 IP precedence라고 하며 이는 일반적으로 CoS , ‘Class of Service’를 구현하기 위해 사용되어 진다.

 

IP precedence 8개의 클래스이며 이는 0부터 7까지로 구분되는데, 0이 가장 낮은 우선순위이고 7이 가장 높은 우선순위를 가진다. 일반적으로 인터넷 데이터 패킷은 ToS 필드가 0, 보이스 패킷은 ToS 필드가 5로 마킹된다. ToS 필드 6 7은 현재 미사용중으로 향후에 보이스보다 높은 서비스를 위해 예약되어 있다. 일반적으로 802.1Q ISL같은 L2 기술에서도 CoS(Class of Service)라는 형태로 QoS구현이 가능하다. CoS에서의 클래스 레벨은 IP Precedence와 유사하다.

 

[– IP Precedence 필드]

비트

이름

어플리케이션

7

111

Network

미사용

6

110

Internet

미사용

5

101

Critical

보이스

4

100

Flash-override

비디오 컨퍼런싱

3

011

Flash

콜 시그널링

2

010

Immediate

최우선 순위 데이터

1

001

Piority

중간 순위 데이터

0

000

Routine

베스트 에포트 데이터

 

 

 

DSCP

 

DSCP‘Differentiated Services Code Point’의 약자로 점점 복잡해지는 트래픽을 더 세분하게 클래스하고 처리하기 위해 제안되었다. 이는 IP precedence를 대체하기 위해 제안되기도 하였는데, IP precedence 8개의 클래스만 지원하는 반면, DSCP는 최대 64개의 클래스를 지원한다. IP precedence ToS 필드의 처음 3비트만 사용하는 반면, DSCP는 처음의 6개의 비트를 사용하기 때문이다. 이렇게 보면 DSCP에서 사용하는 ToS 6비트 IP precedence 3비트를 포함하고 있다. 이런 사유로 DSCP IP precedence를 호환한다.

 

[– DSCP 필드]

 

DSCP값은 패킷에 마킹을 하고 홉 단위로 처리되어 진다. DSCP값은 가급적 패킷의 발생지쪽에서 마킹이 되어지면 코어(core) 네트워크를 지나도 라우터 단위로 빠르게 처리가 될 수가 있다. PHB(per-hop behavior)는 개별 라우터(hop) 단위로 패킷에 대한 QoS를 처리한다는 의미로로 크게 4가지로 분류된다. IETF 표준에 정의된 PHB는 아래와 같다.

 

[그림 – PHB 개념도]

 

다시 정리한다면 DSCP 값이 0이면 PHB를 기본(default)이으로 즉, 아무런 QoS를 보증하지 말라는 의미이다. 만약 보이스와 비디오 같은 중요한 패킷은 분명 DSCP 값이 46으로 맵핑되어 있을 것이므로 이때는 PHB EF(Expedited Forwarding)로 처리하라 즉, 즉각적으로 딜레이없이 바로 처리해야 한다.

 

[– IETF에서의 PHB 정의]

구분

DSCP의 비트 설정

설명

기본 PHB

5,6,7번이 000인 경우

베스트 에포트 서비스

Expedited Forwarding PHB

5,6,7번이 101인 경우

딜레이 적은 서비스

Assured Forwarding PHB

5,6,7번이 001, 010, 011, 110인 경우

대역폭에 대한 보증이 필요한 서비스

Class Selector PHB

2,3,4번이 000인 경우

DS를 지원하지 않는 장비와의 호환성을 위해 사용함

 

 

 

DiffServ 기술 비교

 

앞서 설명했듯이 ToS 필드내의 최초 3비트를 IP precedence, 최초 6비트를 DSCP가 사용하므로 DSCP IP precedence를 내포하고 호환한다. L3에서 QoS를 사용하기 위해서는 패킷의 ToS 필드에 마킹된 IP Precedence DSCP를 참조하여 라우터는 패킷을 적절히 처리(PHB)를 진행하면 된다. L2에서는 802.1Q ISL과 같은 VLAN 태깅 기술을 사용하여 CoS를 적용할 수 있다. 자세한 내용은 아래 표를 참조하기 바란다.

 

[– IP precedence vs DSCP 비교]

 

 

 

 

!======================================================================================

 

 


[출제유형 1 – RSVP를 위한 LLQ 설정]

구분

내용

토폴로지

출제유형

R2에서 RSVP관련 traffic에 대해서 profile1024, 128로 설정하고, bandwidth512, 128로 설정하시오.

설명

정리해보면 아래와 같다.

ⓐ 글로벌 설정에서 RSVP pq-profile 1024, 128로 설정한다.

ⓑ 인터페이스에서 bandwidth 512, 128로 설정한다.

솔루션

[R2]

ip rsvp pq-profile 1024 128

!

interface Serial1/0.2 point-to-point

 ip rsvp bandwidth 512 128

결과값

[R2]

R2#show ip rsvp  

RSVP: enabled (on 2 interface(s))

Rate Limiting: disabled

  Max msgs per interval: 4

  Interval length (msec): 20

  Max queue size: 500

  Max msgs per second: 200

 

Refresh Reduction: disabled

  ACK delay (msec): 250

  Initial retransmit delay (msec): 1000

  Local epoch: 0xA0940D

  Message IDs: in use 0, total allocated 0, total freed 0

 

Neighbors: 0

  RSVP encap: 0 UDP encap: 0 RSVP and UDP encap: 0

 

Local policy:

COPS:

 

Generic policy settings:

    Default policy: Accept all

    Preemption:     Disabled

 

 

 

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

 

 


3. QoS Mechanisms

 

QoS 메커니즘들은 네트워크상의 장비들에서 QoS 정책을 구현하기 위해 사용되어지는 기술들이다. IP 패킷이 네트워크 장비에 유입되는 순간, 이들은 라우터나 스위치의 프로세스에 의한 논리적인 식별자인 클래시파이어(classfier)에 의해 감지되고 식별되어 진다. 그후에 패킷들은 IP, 포트, 서비스 등에 의해 관라자가 사전에 정의해 둔 각 클래스(class)로 분류된다. 그후에 QoS 메커니즘 기술들에 의해 각 패킷들은 카운트(counted), 전달(expedited), 지연(delayed), 압축(compressed), 분할(fragmented)되거나 또는 고의적으로 드랍(drop)이 되어지기도 진다.

 

결국 QoS 메커니즘이라 함은 라우터나 스위치에 유입된 패킷에 대해 어떤 정책을 적용하고 어떻게 취급할 것인가 하는 방법론들이다. 이 장에서는 클래시피캐이션(classification; 분류), 마킹(marking; 표기), 컨제션 매니지먼트(congestion management; 혼잡 관리), 컨제션 어보이던스(congestion avoidance; 혼잡 회피), 폴리싱과 셰이핑(policing and shaping) 그리고 링크 에피션시(Link Efficiency)에 대해서 알아보도록 하자.

 

[– IP QoS 메커니즘]

구분

설명

Classification

클래스(class) 기반의 QoS 메커니즘 각각은 몇가지 타입의 분류 방법을 지원한다.

Marking

Classification 또는 Marking에 기반하여 분류된 패킷에 표기를 하는 것이다.

Congestion Management

각 인터페이스들은 패킷 전송시에 우선 순위를 위한 큐잉(queuing) 메커니즘을 가진다.

Congestion Avoidance

네트웍상에서 혼잡(congestion)이 발생하기 이전에 임의의 패킷을 버리는 기술이다.

Policing and Shaping

미터링(metering) 기반의 정책에서 rate-limit(대역폭 제한)을 집행하는 기술로, 임계치를 초과하는 트래픽에 대해 드랍, 마킹, 또는 딜레이에 대한 적용을 결정하는 기술이다.

Link Efficiency

대역폭(bandwidth)을 효율적으로 사용하기 위하여 유입된 패킷을 압축(compression)하거나 또는 딜레이(delay)나 지터(jitter)를 줄이기 위해 LFI(link fragmentation and interleaving)를 하는 기술이다.

 

 


1) Classification

 

클래시피캐이션(classification)은 유입된 패킷을 감정하고 사전에 정의된 몇가지 클래스 중 하나로 분류하는 작업이다. QoS가 활성화 되어있는 네트웍이라면, 모든 트래픽은 QoS를 인지할 수 있는 네트웍 장비들에 의해 인터페이스로 유입시에 분류되어 질 수 있다. 패킷은 사전에 정의된 여러가지 요인(일반적으로 패킷 헤더의 TOS와 어드레스 필드)에 의해 사전에 정의되어 있을 수 있기 때문에 손쉬운 분류가 가능할 수 있다.

 

[패킷 식별 요소]

구분

설명

DSCP

패킷 헤더의 TOS 필드 중 최초 6bit

IP Precedence

패킷 헤더의 TOS 필드 중 최초 3bit (DSCP에 포함됨)

Source Address

패킷 헤더의 L3 어드레스 중 송신지 IP

Destination Address

패킷 헤더의 L3 어드레스 중 수신지 IP

 

QoS가 활성화 된 네트워크에서는 일반적으로 패킷의 최초 인입단인 호스트와 직접 연동된 스위치 또는 호스트 그 자체에서 패킷의 TOS 필드에 IP precedence 또는 DSCP를 이용하여 패킷의 우선순위(priority)를 마킹(marking)할 수 있다. 그리고 라우터 또는 스위치에서는 유입되는 패킷의 TOS 필드의 내용을 신뢰(trust)하거나 비신뢰(not trust)할 수 있다. 일반적으로 호스트에 종단 사용자가 직접 마킹한 TOS 필드는 해커등에 의해 조작되어 있을 가능성이 높으므로 비신뢰하는 경우가 많지만, 상윗단의 L2 스위치나 L3 라우터에서는 이 부분에 대해 신뢰해야 하는지를 고려해 보아야 한다. 왜냐하면 네트워크 관리자가 유입된 패킷의 TOS 필드를 신뢰하거나 또는 재조정하여 상위 네트워크로 패킷을 전달한다면, 그 이후의 네트워크 장비들은 패킷의 TOS 필드만 확인후 적절한 QoS 정책을 쉽게 적용할 수 있기 때문이다. 이를 일반적으로 트러스트 바운드리(trust boundary)라고 한다.

 

라우터에서 패킷을 분류하는 방법은 일반적으로 두가지가 있다. 첫번째로 엑세스 리스트를 활용하는 방법인데, 엑세스 리스트를 활용하면 DSCP, IP Precedence, Source Address, Destination Address 모두에 대한 식별이 가능하다. 두번째로 MQC(Modular QoS CLI)를 사용할 경우 클래스맵(class-map)에서 식별이 가능한데, 이때는 일반적으로 IP address 부분을 제외한 DSCP, IP Precedence, 포트넘버 등으로 식별이 가능하다. 문제에서 별도로 언급이 없다면 엑세스 리스트를 사용하면 된다. 그러나 일부 문제에서는 IP precedence 문제를 내면서 엑세스 리스트를 사용하지 말라고 언급할 수도 있는데, 이때는 클래스맵(class-map)에서 IP precedence중 원하는 필드(eg, routine or priority)를 매칭시키면 된다.

 


 

2) Marking

 

마킹은 일반적으로 컬러링(coloring)라고도 하는데, 각 패킷을 적절한 네트워크 클래스(class)의 멤버로 간주하기 위한 일종의 표식을 하기 때문이다. 이렇게 클래스의 멤버가 된 패킷은 네트워크에 가용한 대역폭이 발생하면 클래스에 정의된 정책을 기반하여 즉각적으로 적절한 대역폭이 할당받을 수 있다. 마킹은 일반적으로 네트워크 바운드리의 종단쪽, 즉 최초에 패킷이 네트워크에 유입되는 L2 스위치나 라우터단에서 설정하는 것이 유리하며, MQC로 설정이 가능하다.

 

각 패킷들이 적절한 클래스로 결정되면, QoS 메커니즘에 의해 ToS 필드의 DSCP IP precedence의 비트(bit)들 부분에 마킹이 된다. 이렇게 패킷에 ToS 필드에 마킹이 되면, 대부분의 다른 QoS 메커니즘들이 해당 패킷을 어떻게 처리해야 할지에 중요한 자료로 활용된다. 예를들어 IP precedence에 우선 순위가 5로 마킹된 보이스 패킷은 일반적으로 PHB에서 EF로 간주되므로 어떠한 딜레이도 없이 즉각적으로 전송이 되어진다. 만약 IP precedence0으로 마킹된 일종의 P2P와 같은 패킷등은 혼잡이 발생할 경우 TCP 테일드롭(tail drop)등을 방지하기 위해 정책상 사전에 버려질 수도 있다.

 

 

 

3) Congestion Management

 

패킷이 라우터의 아웃풋 인터페이스에서 전송되기 전에 머무르는 곳, 일종의 버퍼를 일반적으로 큐(queue)라고 부른다. 큐는 다시 인터페이스의 물리적인 하드큐(hard queue)와 논리적인 소프트큐(soft queue)로 구분할 수 있다. 혼잡 관리(congestion management)란 라우터의 인터페이스에서 혼잡이 발생하였을 경우에, 패킷에 기록된 마킹을 근거로하여 이를 어느 큐에 대응시킬 것인가 하는 것이다. 이런 사유로 혼잡 관리 메커니즘은 큐잉 알고리즘(queuing algorithms)이라고도 불리운다. 예를들어 WFQ(Weighted Fair Queuing)이나 LLQ(Low Latency Queuing)을 사용하여 지연율에 민감한 보이스와 같은 패킷을 우선권이 있는 큐에 배치하여 먼저 전송하는 기술들이다.

 

다음은 시스코 라우터에서 지원 가능한 혼잡 관리 기술들이다.

 

[시스코 지원 혼잡 관리 기술]

구분

설명

First In First Out (FIFO)

가장 기본적인 싱글 큐 구조로 먼저 들어온 패킷을 먼저 내보내는 기술이다. 결국 패킷을 베스트 에포트로 처리하므로 아무런 QoS가 없는 상태를 의미한다.

Priority Queuing (PQ)

FIFO의 단점을 해결하기 위해 ‘high, medium, normal, low’ 4가지 클래스로 나눠 차등화된 서비스를 제공하는 큐잉 기법이다. 우선순위가 높은 패킷을 모두 우선적으로 처리한 다음 우선 순위가 낮은 패킷을 처리하므로, 우선 순위가 낮은 패킷은 대역폭 고갈(starve)로 지속적으로 미처리될 수 있다.

Custom Queuing (CQ)

PQ의 우선 순위가 낮은 트래픽에 대한 서비스 불가 현상을 해결하기 위해 각 클래스별로 큐를 라운드 로빈(round-robin) 방식으로 하나씩 처리하는 방법이다. 이는 가용 대역폭 범위내에서 일정한 비율을 특정 프로토콜에 맞추어 사용하는 큐잉 방식으로 최대 16개의 클래스를 지원한다.

Weighted Fair Queuing (WFQ)

PQ에서 우선 순위가 낮은 트래픽에 대한 서비스 불가 현상과 CQ에서 클래스별로 차등화된 서비스를 받지 못한다는 단점을 해결하기 위해 만들어졌다. 트래픽 플로우별로 상이한 큐를 만들어 트래픽을 조절하고 특정 트래픽에 대해서는 가중치를 정하여 플로우 간에도 차별을 두는 방식이다.

Class-based Weighted Fair Queuing (CBWFQ)

WFQ의 확장판으로 각 클래스별로 bandwidth, weight, packet limit 정책을 정의할 수 있고, WRED도 사용할 수 있다.

Low Latency Queuing (LLQ)

PQ CBWFQ를 합친 기술이다. 일반적으로 보이스 패킷은 PQ로 처리하고 나머지 패킷에 대해 CBWFQ로 처리한다.

 

 

 

4) Congestion Avoidance

 

혼잡 회피(Congestion Avoidance)란 트래픽이 사전에 정의된 범위에 도달하면 패킷을 큐에 저장된 패킷을 버림으로써 혼잡에 대한 발생을 방지하는 기술이다. 네트워크에 혼잡이 발생하여 패킷이 유실되는 것을 막기 위해 그 이전에 패킷을 버림으로써 패킷 유실을 사전에 방지한다는 것은 조삼모사처럼 들릴 수 있지만 사실 상당히 다르다.

 

예를들어 TCP의 경우 세션이 맺어진 이후에 데이터 통신은 윈도우 사이즈를 조절하는 버퍼링 기술을 사용하는데, 최초에는 윈도우의 크기를 작게하지만 점진적으로 크게 조절하므로 시간이 지날수록 전송효율이 좋아지는 특징이 있다. 이를 TCP 슬로우 스타트라고 하는데, 만약 혼잡이 발생하여 패킷 로스가 발생하면 TCP는 윈도우 사이즈를 줄이게 되므로 슬로우 스타트 과정을 다시 거치게 된다.

 

[그림 – TCP 테일 드롭(tail-drop)시 슬로우 스타트]

 

이를 방지하기 위해 사용되는 기술이 RED(Random Early Detection)인데, 이는 혼잡이 발생하는 네트워크에서 관리자가 정해둔 임계치 이상의 트래픽을 사전에 버림으로써 향후 발생할 패킷 드롭이나 TCP 슬로우 스타트를 방지하는 기술이다. 그러나 RED의 경우 말 그대로 아무 패킷이나 랜덤하게 드롭하므로 보이스나 비디오 같은 중요한 패킷이 버려질 가능성이 높다. 이를 보완한 기술이 WRED(Weighted RED)인데, 이는 보이스와 비디오 같은 패킷에 먼저 가중치(weighted)를 적용한 후에 패킷을 버릴 때 가중치가 높은 패킷은 전송을 보장하고 가중치가 낮은 패킷중에서만 랜덤하게 버리는 기술이다.

 

 

 

5) Policing & Shaping

 

폴리싱과 셰이핑은 모두 라우터에 유입되는 패킷을 다른 라우터로 전달하기 이전에 어떻게 처리할 것인가 하는것에 관련된 기술이다. 폴리싱은 일반적으로 관리자가 정한 대역폭의 임계치를 초과하는 트래픽에 대해 드롭(drop)을 하거나 마킹(marking)한 후에 전송하는 기술이다. 폴리싱은 패킷이 유입되는 인풋 인터페이스와 전송되는 아웃풋 인터페이스 모두에 적용이 가능한 기술이다. 라우터에서 적용하는 방법으로는 클래스 기반의 폴리싱(Class-based Policing) CAR(committed Access Rate)가 있다.

 

셰이핑은 일반적으로 아웃풋 인터페이스에서만 적용이 되는데, 임계치 이상의 트래픽이 들어오면 일단 큐에 저장해 두었다가 여유 대역폭이 발생하면 전달하는 기술이다. 폴리싱의 경우 임계치 이상의 트래픽을 버리게 되므로 TCP 테일 드롭으로 슬로우 스타트가 발생하거나 패킷 재전송이 요구되어 진다. 그러나 셰이핑은 패킷을 가급적 버리지 않고 저장해 두었다가 전송하는 방식(store-and-forward)을 취하기 때문에 실제 망에 적용시 상당히 부드럽게 데이터가 전달된다고 인지하게 된다.

 

그러나 셰이핑의 경우, 큐에 데이터를 저장하고 있어야 하므로 시스템 부하가 다소 높고 패킷의 전송에 대한 딜레이가 발생할 수 있다. 또한 일반적으로 아웃풋 인터페이스에만 적용이 가능하며, 궁극적으로 아웃풋 큐의 저장 한계를 넘어서는 트래픽은 결국 드롭된다는 단점이 있다. 라우터에서 셰이핑을 적용하는 방법으로는 GTS(Generic Traffic Shaping) FRTS(Frame Relay Traffic Shaping) 기술이 있다.

 

결론적으로 폴리싱은 임계치(limit)를 초과(exceed)하는 트래픽에 대해 드롭(drop)을 하는 경향이 있고, 셰이핑은 임계치를 초과하는 트래픽을 일단 큐에 저장해 두었다가 여유 대역폭이 생길 경우 전달하는 기술이다. CCIE 시험에서는 폴리싱을 위해 CAR, 셰이핑을 위해 FRTS 기술, 또는 양자 모두를 위해 MQC 사용을 유도한다.

 

[그림 폴리싱 & 셰이핑]

 

 

 

6) Compression

 

네트워크상에서 전송 효율을 높이는 방법에는 압축(compression) 기술이 있다. 보이스 패킷은 특성상 페이로드(payload) 영역이 약 20바이트로 상당히 작지만, 이런 페이로드에도 항상 40바이트의 헤더가 붙어야 된다는 것이다. 문제는 보이스를 전달하기 위해 패킷으로 인캡슐레이션(encapsulation)될 때 페이로드 영역보다도 오버헤드가 더 크다는 것이다. 이런 문제를 해결하기 위한 방법이 바로 압축 기술인데, 압축은 크게 L3의 헤더를 압축하는 기술과 L2의 프레임 자체를 압축하는 기술이 있다.

 

일반적으로 보이스에서는 L3의 오버헤드를 압축하게 되는데, 이는 일반적으로 WAN 구간에서 양 장비간의 사전의 약속에 의해 압축이 된다. cRTP(compressed Real-Time Transport Protocol) PHS 기술을 사용하게 되는데, 이때는 보이스 패킷에 내포된 40바이트의 헤더가 2바이트로 압축이 되는데, 만약 CRC가 여기에 추가가 된다면 4바이트로 압축이 되기도 한다.

 

[그림 보이스 헤더 압축]

 

항상 압축 기술이 좋은 것은 아니다. 압축을 하게 되면 패킷 사이즈가 작아져서 전송 효율이 좋아지지만, WAN의 양단 장비가 모두 압축 기능을 지원해야 하고, 또한 압축을 하는 순간과 압축을 푸는 순간에 어느 정도 프로세싱 딜레이가 발생할 수 있다. 보이스의 경우 일반적으로 소프트 방식이 아닌 하드 방식으로 압축을 처리하기 때문에 딜레이가 적지만 소프트 방식으로 압축한다면 150ms 이내에 도달해야 품질이 보증되는 패킷 특성상 압축 프로세싱으로 인한 딜레이로 인해 서비스 품질이 떨어질 수도 있다.

 

 

 

7) Link Fragmentation and Interleaving

 

일반적으로 QoS L3 기술이다. 여기에 한가지 함정이 있는데, L3에서 아무리 완벽하게 QoS가 보장 되더라도 그 하위 레이어, L1이나 L2 수준에서 QoS를 지원해 주지 않는다면 서비스 품질은 저하될 것이다. 예를들어 L3에서 작은 보이스 패킷을 선처리 하더라도, L2에서 FTP 벌크 데이터 같은 거대한 패킷이 지나가 버린다면 상당히 보이스 패킷은 상당한 딜레이가 발생한 후에 데이터를 전송하게 될 것이다.

 

앞서 TCP 윈도우 사이즈에서 설명하였듯이 윈도우 사이즈나 MTU는 크면 클수록 전송효율이 좋다. 이것은 이삿짐을 1톤 트럭으로 10번 왕복하여 전달하는 것보다 10톤 트럭으로 한번 전달하는 것이 더 효율적인 것과 같은 원리이다. 그러나 앞서 설명하였듯이 보이스 패킷은 특성상 종단간 150ms 이상의 딜레이가 발생할 경우 서비스 품질의 저하가 발생한다. 참고로 이더넷에서의 MTU(Maximum Transmission Unit)은 보통 약 1500바이트이다. 1500바이트의 프레임은 56kbps의 저속 구간에서 214ms 딜레이를 발생시키는데, 이 경우 단 한대의 라우터만 건너더라도 딜레이는 150ms가 넘기 때문에 서비스 품질 저하가 발생한다.

 

[– MTU 사이즈에 따른 딜레이]

 

이런 사유로 데이터의 절대적인 전송 효율은 떨어지더라도 큰 사이즈의 프레임을 여러 개로 작은 프레임으로 나누고(fragmentation), 그 나뉘어진 프레임의 중간에 보이스 패킷들을 삽입하면(interleaving) 보이스 패킷에 대한 전체 딜레이를 줄일 수 있다. 이를 LFI(Link Fragmentation and Interleaving)라고 한다.

 

[그림 – LFI 원리]

 

LFI 설정은 다음과 같다. 먼저 map-class 명령어로 fragment, cir, bc 값을 차례로 입력하고 fair-queue를 설정한다. 그후에 메인 인터페이스 하단에서 traffic-shaping을 반드시 선언해야 한다. 끝으로 서브 인터페이스를 사용한다면, 다시 서브 인터페이스로 들어가서 class 명령어로 map-class명을 입력한다.

 

[명령어 – LFI 설정]

map-class frame-relay FRF12

 frame-relay fragment 80

 frame-relay cir 64000

 frame-relay bc 2600

 frame-relay fair-queue

!

interface serial 1/0

 encapsulation frame-relay

 frame-relay traffic-shaping

!

interface serial 1/0.1 point-to-point

 frame-relay interface-dlci 102

  class FRF12

 

[– QoS 설정에서 fair-queue가 필요한 경우]

CCIE R&S 시험의 QoS 파트에서는 fair-queue를 설정해야 하는 경우가 있다. 일반적으로다음의 세가지 경우에는 fair-queue 명령어를 사용해야 한다.

RSVP를 사용한 경우 인터페이스에 fair-queue 설정

LFI를 사용한 경우 map-class에서 fair-queue 설정

CBWFQ를 사용한 경우, policy-map class-default에서 fair-queue 설정

 

 

 

!======================================================================================

 

 

 

[출제유형 1 – IP precedence에 대한 marking 설정]

구분

내용

토폴로지

출제유형

R1 R2구간의 시리얼 구간을 서브 인터페이스를 사용하여 P2P로 연동하라. (서브 인터페이스 번호는 라우터 번호를 사용하라.) R2 S0에 유입되는 패킷중 소스 IP R1 Lo0인 경우 IP precedence 3으로 마킹하고 next-hop R3 F0/0으로 가게 설정하라. 반드시 PBR을 사용하여야 한다.

설명

정리해보면 아래와 같다.

R1 S0.1, R2 S0.2라는 서브 인터페이스를 사용한다. 이때 DLCI 명령어와 번호는 interface-dlci는 각각 102, 201을 사용하면 된다.

R1, R2, R3의 모든 인터페이스(룹백0 포함) OSPF AREA 0로 선언한다.

R2에서는 R1 Lo0 IP 1.1.1.1에 대해 엑세스 리스트를 이용하여 인터레스팅 트래픽으로 정의해 둔다.

PBR을 위해 route-map을 사용하여 IP precedence 3(또는 flash)으로, next-hop 1.1.23.3(또는 F0/0)으로 설정한다.

ⓔ 위에서 설정한 route-map R2 S0.2에 적용한다.

솔루션

[R2]

access-list 1 permit 1.1.1.1

!

route-map PBR permit 10

 match ip address 1

 set ip precedence flash

 set ip next-hop 1.1.23.3

!

interface Serial1/0.2 point-to-point

 ip address 1.1.12.2 255.255.255.252

 ip policy route-map PBR

 frame-relay interface-dlci 201

결과값

[R1]

R1#ping 1.1.3.3 source 1.1.1.1

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.3.3, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/103/200 ms

 

[R2]

R2#show route-map PBR

route-map PBR, permit, sequence 10

  Match clauses:

    ip address (access-lists): 1

  Set clauses:

    ip precedence flash

    ip next-hop 1.1.23.3

  Policy routing matches: 5 packets, 520 bytes

 


 

[출제유형 2 – DSCP에 대한 marking 설정]

구분

내용

토폴로지

출제유형

R2에서 F0/0으로 유입되는 트래픽에 대해 아래 조건처럼 2개의 클래스로 구분후 마킹하라.

CLASS1 : DSCP cs5 이고, 패킷 사이즈가 500~1500 이내일 때, IP precedence‘immediate’로 설정하라.

CLASS2 : DSCP cs5 이고, 패킷 사이즈가 1000 인 경우, IP precedence ’priority’로 설정하라.

설명

정리해보면 아래와 같다.

MQC를 사용하며 클래스 이름은 CLASS1 CLASS2이다. (클래스 이름을 정확히 입력해야 한다)

ⓑ 패킷에 대해 구분할 때 DSCP cs5와 패킷 사이즈가 모두 충족되어야 하는 조건이다. (match all)

CLASS2 CLASS1에 포함된 개념이므로 유의해야 한다. CLASS1에서는 ‘match not’ 명령어를 사용하여 패킷사이즈 1000인 경우를 제외하면 된다.

ⓓ 폴리스맵에서 CLASS1에 대해 immediate, CLASS2에 대해 priority로 설정하면 된다.

ⓔ 마지막으로 서비스 폴리시 명령어를 이용하여 R2 F0/0‘input’으로 적용한다.

솔루션

[R2]

class-map match-all CLASS2

 match  dscp cs5

 match packet length min 1000 max 1000

class-map match-all CLASS1

 match  dscp cs5

 match packet length min 500 max 1500

 match not packet length min 1000 max 1000

!

policy-map POLICY_MARKING

 class CLASS1

  set precedence 2

 class CLASS2

set precedence 1

!

interface FastEthernet0/0

 service-policy input POLICY_MARKING

결과값

[R1]

! 설정 확인

R2#show policy-map POLICY_MARKING      

  Policy Map POLICY_MARKING

    Class CLASS1

      set precedence 2

    Class CLASS2

      set precedence 1

 

! 동작 확인

R2#show policy-map interface f0/0 input

 FastEthernet0/0

 

  Service-policy input: POLICY_MARKING

 

    Class-map: CLASS1 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match:  dscp cs5 (40)

      Match: packet length min 500 max 1500

      Match: not packet length min 1000 max 1000

      QoS Set

        precedence 2

          Packets marked 0

 

    Class-map: CLASS2 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match:  dscp cs5 (40)

      Match: packet length min 1000 max 1000

      QoS Set

        precedence 1

          Packets marked 0

 

    Class-map: class-default (match-any)

      15 packets, 1410 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any


 

 

[출제유형 3 – Congestion Management – ECN 설정 ]

구분

내용

토폴로지

출제유형

R2 S0의 아웃바운드 트래픽이 전체 대역폭의 70%에 도달하면, R2는 네트워크가 혼잡하다는 것을 알리도록 설정하여, 이를 수신한 장비가 전송하는 패킷의 양을 감소시킬수 있도록 하라. (map-class를 사용하지 마시오)

설명

이 문제는 FECN이나 BECN을 사용하지 말고 WRED를 사용하라는 의미이다.

ⓐ 폴리시맵을 만들어 대역폭이 70%가 될 경우 random-detect ecn을 설정하라는 의미이다.

ⓑ 클래스를 별도로 만들 필요없이 기본 클래스인 ‘class-default’를 사용한다.

ⓒ 만약 random-detect ecn을 해야 할 경우에는 기본적으로 random-detect 명령어를 적용해 주어야 한다.

ⓓ 최종적으로 관련 인터페이스은 S0이며 방향은 아웃바운드이다. 참고로 서브 인터페이스에서는 해당 명령어가 적용되지 않으므로 반드시 물리적 인터페이스 하단에서 바로 설정한다.

솔루션

[R2]

policy-map POLICY_WRED

 class class-default

  bandwidth percent 70

  random-detect

  random-detect ecn

!

interface serial 0

 service-policy output POLICY_WRED

결과값

[R2]

R2#show policy-map POLICY_WRED

  Policy Map POLICY_WRED

    Class class-default

      Bandwidth 70 (%)

            exponential weight 9

            explicit congestion notification

            class    min-threshold    max-threshold    mark-probablity

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

 

            0          -                  -                1/10

            1          -                  -                1/10

            2          -                  -                1/10

            3          -                  -                1/10

            4          -                  -                1/10

            5          -                  -                1/10

            6          -                  -                1/10

            7          -                  -                1/10

            rsvp       -                  -                1/10

 

 


[출제유형 4 – Congestion Management – de-list 설정 ]

구분

내용

토폴로지

출제유형

R2 S0 인터페이스에서 혼잡이 발생할 경우, IP precedence routine priority로 설정된 패킷을 de-bit로 설정하라.

설명

문제에서 언급한대로 de-bit가 설정되면 de-list와 연계하여 혼잡 발생시 먼저 버려지게 되는 패킷에 대한 마킹을 하는 것이다.

IP precedence에서 routine priority는 가장 낮은 등급은 0 1이다.

ⓑ 익스텐디드 엑세스 리스트로 두 타입의 패킷을 정의한다.

ⓒ 위의 패킷 타입을 de-list로 만든 다음 시리얼 인터페이스에서 de-group로 정의한다. 서브 인터페이스가 있다면 서브 인터페이스에 설정하면 된다.

솔루션

[R2]

access-list 100 permit ip any any precedence routine

access-list 100 permit ip any any precedence priority

!

frame-relay de-list 1 protocol ip list 100

!

interface Serial1/0.2 point-to-point

 frame-relay de-group 1 201

결과값

[R2]

R2#show ip access-lists 100

Extended IP access list 100

    10 permit ip any any precedence routine (5 matches)

    20 permit ip any any precedence priority


 

 

[출제유형 5 – Shaping 설정]

구분

내용

토폴로지

출제유형

R2F0/1에 적용하라. VLAN_32(R2 F0/1 구간)로 가는 WEB traffic에 대해 10Mb shaping 시키시오. , MQC는 사용할 수 없다.

설명

정리해보면 아래와 같다.

ⓐ 먼저 익스텐디드 엑세스 리스트로 www(http; 80포트)에 대해 인터레스팅 트래픽으로 정의한다.

MQC를 사용하면 안되므로, 아웃 바운드 인터페이스 하단에서 바로 적용할 수 있는 ‘traffic-shaping’ 명령어를 사용하여 위의 엑세스 리스트를 불러온 다음 대역폭을 10,000,000bps로 정의한다.

솔루션

[R2]

access-list 100 permit tcp any any eq www

!                                 

interface FastEthernet0/1

traffic-shape group 100 10000000

결과값

[R2]

R2#show traffic-shape fastEthernet 0/1

 

Interface   Fa0/1

       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt

VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active

-      100    10000000  62500  250000    250000    25        31250     -

 


 

[출제유형 6 – Policing & Shaping 설정]

구분

내용

토폴로지

출제유형

R2 S0에서 R1으로 가는 트래픽중에 IP precedence routine(0)인 트래픽에 대해서는 대역폭을 128Kbyte로 제한하라. 만약 IP precedence priority(1)인 트래픽에 대해서는 대역폭을 256Kbyt로 제한하되 policing이나 rate-limiting을 사용해서는 안된다. IP precedence 대한 정의를 위해 ACL을 사용해서는 안된다.

설명

R2에서 S0를 이용해 R1으로 가는 트래픽에 대해 설정하기 위해 클래스를 2개 만든다.

ACL을 사용하면 안되므로 IP precedence class-map에서 매치시킨다.

IP precedence routine에 대해서는 128K policing, priority에 대해서는 256K shaping을 시켜야 한다.

ⓒ 마찬가지로 서브 인터페이스가 있으면 거기에 설정한다.

솔루션

[R2]

class-map match-all CLASS_PRIORITY

 match  precedence 1

class-map match-all CLASS_ROUTINE

 match  precedence 0

!

policy-map POLICY_PRECEDENCE

 class CLASS_ROUTINE

   police 128000

 class CLASS_PRIORITY

  shape average 256000

!

interface Serial1/0.2 point-to-point

 service-policy output POLICY_PRECEDENCE

결과값

[R2]

R2#show policy-map POLICY_PRECEDENCE

  Policy Map POLICY_PRECEDENCE

    Class CLASS_ROUTINE

     police cir 128000 bc 4000

       conform-action transmit

       exceed-action drop

    Class CLASS_PRIORITY

      Traffic Shaping

         Average Rate Traffic Shaping

         CIR 256000 (bps) Max. Buffers Limit 1000 (Packets)


 

 

[출제유형 7 – LFI 설정]

구분

내용

토폴로지

출제유형

R1 R2간의 인터페이스 S0(서브 인터페이스)에서 트래픽의 지연율(latency)을 최소화 하라. 이를 위해 프레임 사이즈를 640byte로 프레크먼트 하도록 하라.

설명

정리해보면 아래와 같다.

R1 R2에서 먼저 map-class fragment 640를 선언한다.

fragment를 선언한 후에는 반드시 fair-queue를 선언한다.

R1 R2 S0에서 frame-relay traffic-shaping을 선언한다.

R2 R2 S0.x(서브 인터페이스)로 들어간다.

ⓔ 서브 인터페이스를 사용하므로 interface-dlci 하단에서 class로 선언한다.

솔루션

[R1]

map-class frame-relay LFI

 frame-relay fair-queue

 frame-relay fragment 640

!

interface Serial1/0

 frame-relay traffic-shaping

!

interface Serial1/0.1 point-to-point

 frame-relay interface-dlci 102  

class LFI

 

[R2]

map-class frame-relay LFI

 frame-relay fair-queue

 frame-relay fragment 640

!

interface Serial1/0

 frame-relay traffic-shaping

!

interface Serial1/0.2 point-to-point

 frame-relay interface-dlci 201  

  class LFI

결과값

[R1]

R1#show frame-relay fragment interface serial 1/0.1 102

 

 fragment size 640                      fragment type end-to-end

 in fragmented pkts 0                   out fragmented pkts 0        

 in fragmented bytes 0                  out fragmented bytes 0        

 in un-fragmented pkts 37               out un-fragmented pkts 37       

 in un-fragmented bytes 4228            out un-fragmented bytes 4228     

 in assembled pkts 37                   out pre-fragmented pkts 37       

 in assembled bytes 4228                out pre-fragmented bytes 4228     

 in dropped reassembling pkts 0         out dropped fragmenting pkts

            0        

 in DE fragmented pkts 0                out DE fragmented pkts 0         

 in DE un-fragmented pkts 0             out DE un-fragmented pkts 0        

 in timeouts 0        

 in out-of-sequence fragments 0        

 in fragments with unexpected B bit set 0        

 in fragments with skipped sequence number 0        

 out interleaved packets 0


 

 

!======================================================================================

 

 

 

4. Modular QoS command line

 

시스코 라우터에서 QoS를 설정하는 방법은 다양하다. 일반적으로 시스코 라우터에서 QoS를 설정하는 방법으로는 CLI, MQC, AutoQoS 그리고 QPM 이라는 4가지 방법이 존재한다. CLI‘Command line Interface’라는 의미이지만 여기서는 QoS를 인터페이스마다 일일이 설정해야 했던 구형 CLI라는 의미이다. AutoQoS는 인터페이스에서 단 한줄로 QoS를 설정할 수 있는 편리한 방법이지만 기능에는 제한이 있다. QPM‘QoS Policy Manager’의 약자로 CiscoWorks와 연계하여 사용하는 GUI 구조의 툴이다. 그리고 일반적으로 가장 많이 사용되는 MQC가 존재하는데, 이는 ‘Modular QoS Command’의 약자로 시스코 라우터 상에서 몇가지 계층적인 단계로 구분된 CLI 프로세스를 통해 QoS를 설정하는 방식이다.

 

모듈러(modular)라는 말이 의미하듯이 설정은 class-map, policy-map, service-policy로 구분이 되어 각자 별도로 정의가 되지만, 실제 적용시에는 상호 유기적으로 연관을 갖고 동작한다. 일반적으로 class-map에서 특정 트래픽들에 대한 클래스를 정의하고, policy-map에서 각 클래스에 대한 정책을 결정한 다음, 끝으로 servicy-policy를 통해 인터페이스에 해당 QoS 정책을 최종적으로 적용하는 방식이다.

 

[그림 – MQC 구조]

 

CAR(committed Access Rate) 같은 설정 방법은 인터페이스마다 해당 설정을 반복해야 하지만, MQC의 경우는 한번 정책을 만들게 되면 그 후에는 여러 개의 인터페이스에서 그 정책을 반복적으로 사용할 수 있기 때문에 상당히 효율적인 구조이다.

 

[– MQC 단계]

1단계. Class Map

2단계. Policy Map

3단계. Service Policy

트래픽에 대한 클래스 결정

클래스를 위한 정책 정의

인터페이스에 적용

 

정리하면 MQC는 시스코 라우터상에서 QoS 적용을 위한 모듈러화된 명령어 설정법이다. 이는 1단계에서는 QoS가 적용될 트래픽의 그룹을 결정하고, 2단계에서는 해당 클래스에 대한 각종 정책을 정의하며, 위에서 정의된 정책을 실제 라우터의 인터페이스에 적용하는 3단계가 존재한다.

  

 


1) Class Map

 

클래스맵에서는 ‘QoS를 적용해야 할 트래픽에 대해 결정을 하는 것이 가장 중요하다. 여기서는 결정된 클래스의 종류만큼 클래스를 만들어주면 되는데, 각 트래픽 클래스별로 3가지를 고려해야 한다. 먼저 클래스의 이름을 만드는 것인데 ‘CLASS_VOICE_01’처럼 일반적인 알파벳 문구나 특수문자, 그리고 숫자를 사용할 수 있다.

 

두번째로 해당 클래스로 결정된 트래픽의 종류가 다수일 경우 ‘match’ 명령어를 사용하게 되는데, 나열된 다수의 트래픽 모두의 합집합에 대해서만 조건을 만족한다면 ‘match all’, 나열된 다수의 트래픽중에 한 개 이상의 조건만 맞아도 조건을 만족한다면 ‘match any’를 사용하면 된다. 예를들어 IP precedence‘routine’이면서 소스 IP‘1.1.1.0/24’를 모두 만족해야 한다면 ‘match all’, IP precedence‘routine’이거나 또는 소스 IP‘1.1.1.0/24’인 것중에 아무거나 한가지 조건만 매치되어도 된다면 ‘match any’이다. 쉽게 말해 ‘and’ 연산인 경우는 ‘match all’, ‘or’ 연산일 경우에는 ‘match any’를 사용하면 된다. 참고로 아무런 ‘match’ 명령어를 사용하지 않는다면 일반적으로 ‘match all’로 간주한다.

 

마지막으로 CLI상에서 같은 라인에서 match 명령어 이후의 여러가지 조건(condition)‘match any’로 간주한다. 또한 이러한 match 라인이 여러 라인 존재한다면, 이는 ‘match all’로 간주한다. 이는 사실 말을 이해하기 상당히 어려우면서도 중요한 내용이다.

 

[ - 클래스맵 match 구문]

구분

명령어

match all

class-map match-all CLASS_VOICE_01

 match ip precedence 4  5

 match not input-interface FastEthernet0/1

 match access-group 100

match any

class-map match-any CLASS_VOICE_01

 match ip precedence 0  1

 match not input-interface FastEthernet0/1

 match access-group 100

 

위 표에서 먼저 match all을 보자. 앞서도 언급했듯이 ‘match all’의 경우는 아래에 나열된 세개 라인에 대해 모두 해당되는 패킷에 대해서만 ‘CLASS_VOICE_01’로 만족시켜 준다. 다시 설명하면, 먼저 유입된 패킷이 IP precedence 4 또는 5 둘중에 한 개만 해당되면 된다. 이 부분이 중요한데, 아무리 ‘match all’ 구문이라도 한 라인에서 복수의 조건이 오면 이때는 무조건 ‘match any’로 간주하기 때문이다. 그리고 반드시 해당 패킷이 유입된 인터페이스가 F0/1가 아니어야 하며, 마지막으로 엑세스리스트에서 100에 정의된 패킷이어야만 한다.

 

이번에는 ‘match any’ 구문을 보자. 이 경우 해당 클래스에 포함된 라인은 ‘match all’때와 동일하지만 내용은 전혀 다른 것이 된다. 위의 유입된 패킷이 라인중 단 한 라인에만 매치되어도 조건은 만족되는것으로 간주하기 때문이다. , IP precedence 4 인 경우, IP precedence 5인 경우, 패킷이 유입된 인터페이스가 F0/1이 아닌 경우, 매치 엑세스 그룹이 100인 경우중에서 한가지만 만족하면 된다는 것이다. 위의 경우 사실상 F0/1에서 유입된 패킷을 제외하고는 모든 패킷은 ‘CLASS_VOICE_01’에 해당될 것이다. 왜냐하면 ‘match not’ 구문에서 ‘F0/1에서 유입되지 않은 모든 패킷이라고 정의하였기 때문이다.

 

참고로 클래스 맵을 만든후에 아래처럼 조건 라인에서 match any를 설정하는 경우도 있다.

 

[클래스맵 디폴트 설정]

구분

명령어

기본 정책

class-map match-all CLASS_VOICE_01

 match ip precedence 4  5

 match not input-interface FastEthernet0/1

 match access-group 100

!

class-map match-all CLASS-ALL

 match any

 

일반적으로 클래스는 4~5개까지만 만들기를 권장한다. 클래스가 지나치게 많아지는 것은 정책적인 측면이나 관리적인 측면에서 비효율적이기 때문이다. 위의 ‘CLASS-ALL’의 경우, 다른 클래스들에 해당되지 않은 모든 패킷은 이곳에 소속되어라는 의미로 맨 마지막으로 만들어 주었다. 뒤에서 학습하겠지만, 여러 개의 클래스간에도 공통된 매치 정책이 있을 수 있는데, 이때는 뒤의 폴리시맵에서 설명하겠지만 순서상 먼저 윗줄에 기재된 클래스맵이 먼저 적용이 되게 되어 있다.

 

참고로 클래스맵에서 매치 조건을 지정할 수 있는 방법은 상당히 많다. 아래표에서도 보여지듯이 access-group, COS, IP precedence, DSCP, IP, 프로토콜, IP등의 다양한 방법이 있다. 예를들어 IP precedence 1인 패킷을 매치시키기 위해서는 클래스맵 하단의 명령어인 ‘match ip precedence 1’으로 설정해도 되지만, IP precedence 1인 패킷을 permit 시키는 엑세스 리스트를 만든 후 클래스맵에서 ‘access-group’ 명령어를 불러들여와도 된다. 이때는 설정하기 편하면서도 가급적 시스템의 리소스를 적게 먹는 클래스맵 하단의 ‘IP precedence’ 명령어를 사용하는게 유리하다.

 

[클래스맵 match 조건]

R1(config)#class-map CLASS_TEST

R1(config-cmap)#match ?

  access-group         Access group

  any                  Any packets

  class-map            Class map

  cos                  IEEE 802.1Q/ISL class of service/user priority values

  destination-address  Destination address

  discard-class        Discard behavior identifier

  dscp                 Match DSCP in IP(v4) and IPv6 packets

  fr-de                Match on Frame-relay DE bit

  fr-dlci              Match on fr-dlci

  input-interface      Select an input interface to match

  ip                   IP specific values

  mpls                 Multi Protocol Label Switching specific values

  not                  Negate this match result

  packet               Layer 3 Packet length

  precedence           Match Precedence in IP(v4) and IPv6 packets

  protocol             Protocol

  qos-group            Qos-group

  source-address       Source address

 

 


2) Policy Map

 

폴리시맵은 위에서 정의한 클래스맵에 대해 어떤 정책을 적용할 것인가 하는 것이다. 트래픽 폴리시에서는 세가지 중요한 구성 요소가 있다. 먼저 폴리시의 이름을 만드는 것으로 ‘POLICY_VOICE_01’처럼 영문자와 특수문자, 그리고 숫자를 사용할 수 있다. 두번째로 폴리시맵은 앞서 만든 클래스맵에 정책을 적용하는 것이므로 클래스를 불러들여오면 된다. 마지막으로 각 트래픽 클래스에 원하는 정책에 대한 액션을 지정해 주면 된다. 한 개의 폴리시맵은 256개까지의 클래스를 불러들여올 수 있다. 폴리시맵 하단에서 불러들여온 클래스맵은 작성한 순서대로 정책 적용이 되므로 순서에 상당히 유의하여야 한다.

 

폴리시맵에서 불러온 클래스에는 다양한 QoS 메커니즘에 따라 다양한 정책을 적용할 수 있다. 적용이 가능한 기술로는 일반적으로 CBWFQ, LLQ, 폴리싱(policing), 셰이핑(shaping), 마킹(marking)등의 정책을 적용할 수 있다.

                                                                                            

여기서는 IP precedence 5이거나 DSCP ef인 패킷을 ‘CLASS_VOICE’로 만들고 대역폭을 200Kbyte 주도록 해보자. HTTP 패킷에 대해서는 대역폭을 100Kbyte를 주고 FTP 패킷에 대해서는 폴리싱을 적용하여 100Kbyte(100000byte)로 트래픽을 제한하도록 하자. 참고로 대역폭을 주는 ‘bandwidth’를 사용하면 단위가 ‘Kbyte’로 적용되지만 ‘policing’을 적용하면 단위는 ‘byte’로 적용되므로 유의해야 한다. 끝으로 나머지 패킷에 대해서는 기본적인 정책을 주면 되는데, 이때 별도의 클래스를 만들 필요없이 기본 클래스인 ‘class-default’ 클래를 주면 된다. 주의해야 할 점은 ‘class-default’는 반드시 소문자로 적어야 하며 절대 오타를 내지 않도록 주의해야 한다.

 

[폴리시맵 구성]

구분

명령어

클래스맵

access-list 110 permit tcp any any eq ftp-data

access-list 110 permit tcp any any eq ftp

!

access-list 120 permit tcp any any eq www           

!

class-map match-all CLASS_FTP

 match access-group 110

!

class-map match-all CLASS_HTTP

 match access-group 120

!

class-map match-any CLASS_VOICE

 match ip precedence 5

 match  dscp ef

폴리시맵

policy-map POLICY_CBWFQ

 class CLASS_VOICE

  bandwidth 200

 class CLASS_HTTP

  bandwidth 100

 class CLASS_FTP

   police 100000 conform-action transmit  exceed-action drop

 class class-default

  fair-queue

 

 

 

3) Service Policy

 

서비스 폴리시는 정책이 어디에서 구현될 것인가하는 것이다. 여기는 MQC의 마지막 단계로 앞서 정의한 폴리시맵을 인터페이스에 적용하게 된다. MQC상에서 한번 만들어진 폴리시맵은 여러 개의 인터페이스에서 공통적으로 적용이 가능한 장점이 있다. 서비스 폴리시는 인터페이스에 적용할 때 ‘input’ 또는 ‘output’ 명령어를 사용하여 방향을 지정해 줄 수 있다. 참고로 폴리시맵은 계층적 사용이 가능하므로 또 다른 폴리시맵을 불러들여올 수 있는데, 이때 상윗단에 위치한 폴리시맵을 부모격인 ‘parent’라 하고 불려들여진 폴리시맵을 자식격인 ‘child’라 한다.

 

[서비스 폴리시 설정]

구분

명령어

Input

interface FastEthernet0/0

service-policy input POLICY_CBWFQ

output

interface FastEthernet0/0

service-policy output POLICY_CBWFQ

 

앞서도 설명했지만, 트래픽의 폴리싱과 셰이핑을 적용할 경우에는 방향성에 유의해야 한다. 폴리싱의 경우 ‘input’‘output’ 모두 적용이 가능하지만 셰이핑의 경우는 ‘output’ 방향으로만 설정이 가능하기 때문이다.

 

지금까지 설정한 클래스맵, 폴리스맵, 서비스 폴리시가 정상적으로 동작하는지 확인해 보자. 여기서도 ‘show’ 명령어로 확인이 가능하며 아래의 표에서도 보여지듯이 현재 정상적으로 시스템에 적용되어 있음을 알 수 있다.

 

[폴리시맵 모니터링]

R1#show policy-map POLICY_CBWFQ

  Policy Map POLICY_CBWFQ

    Class CLASS_VOICE

      Bandwidth 200 (kbps) Max Threshold 64 (packets)

    Class CLASS_HTTP

      Bandwidth 100 (kbps) Max Threshold 64 (packets)

    Class CLASS_FTP

     police cir 100000 bc 3125

       conform-action transmit

       exceed-action drop

    Class class-default

      Flow based Fair Queueing

      Bandwidth 0 (kbps) Max Threshold 64 (packets)

 

이번에는 라우터의 인터페이스에서 MQC에 의해 정책이 잘 집행되고 있는지 확인해 보자. 아래에서 보여지듯이 클래스별가 정의된 이후에, 해당 클래스에 대해 적합한 정책이 집행되고 있음을 알 수 있다.

 

R1#show policy-map interface fastEthernet 0/0

 FastEthernet0/0

 

  Service-policy output: POLICY_CBWFQ

 

    Class-map: CLASS_VOICE (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: ip precedence 5

      Match:  dscp ef

      Queueing

        Output Queue: Conversation 265

        Bandwidth 200 (kbps) Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: CLASS_HTTP (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group 120

      Queueing

        Output Queue: Conversation 266

        Bandwidth 100 (kbps) Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: CLASS_FTP (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group 110

      police:

          cir 100000 bps, bc 3125 bytes

        conformed 0 packets, 0 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          drop

        conformed 0 bps, exceed 0 bps

 

    Class-map: class-default (match-any)

      6 packets, 1777 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      Queueing

        Flow Based Fair Queueing

        Maximum Number of Hashed Queues 256

        (total queued/total drops/no-buffer drops) 0/0/0

 


 

4) MQC를 활용한 NBAR 동작

 

시스코 라우터는 일반적으로 L3에서 동작을 한다. 그러나 오늘날의 네트워크에는 L3에서는 인지할 수 없는 L7 어플리캐이션 레벨의 다양한 웜이나 바이러스가 존재한다. 이러한 웜이나 바이러스로부터 네트워크를 보호하기 위해서는 어플리캐이션 기반의 IPS나 파이어월 제품이 필요하다. NBAR(Network-Based Application Recognition)는 별도의 외부 어플라이언스 없이 시스코 라우터상에서 어플리캐이션 레벨의 트래픽을 제어하기 위해 만들어진 IOS의 기능이다.

 

NBAR를 설정하면 CodeRed NIMDA같은 웜 이외에도 HTTP 패킷에 포함된 JPG, JPEG, 그리고 GIF 파일등에 대한 핸들링도 가능해 진다. NBAR는 시스코 라우터 상에서 MQC를 이용하여 구현할 수 있다. NBAR를 설정하기 위해서는 시스코 라우터상에서 ‘ip cef’ 명령어를 사용하여 ‘CEF(Cisco Express Forwarding)’ 기능이 활성화 시켜야 한다. 참고로 ‘ip cef’ 기능은 기본적으로 활성화 되어 있다.

 

명령은 위에도 설명했듯이 클래스맵을 먼저 만들어 관심 트래픽을 정의하면 되는데, ‘match protocol http url www.cisco.com과 같은 양식으로 URL을 지정하거나, ‘match protocol http url “*.jpg|*.jpeg|*.gif”로 특정 파일명을 지정해도 된다. 파이프(|) 명령어를 사용하면 한줄에 여러가지 조건을 동시에 나열할 수 있다. 이 경우 앞서도 설명했듯이 match 구문 뒤에 가로로 나열된 여러 조건에 대해서는 ‘match any’로 동작하게 되므로, 위의 경우는 파일의 확장자명이 jpg, jpeg, gif중 아무것이나 매치되면 조건에 만족된다는 의미이다. 마지막으로 폴리시맵에서 해당 관심 트래픽에 대한 폴리싱이나 셰이핑 등의 정책을 적용하면 된다. 물론 마지막은 MQC에 의거하여 인터페이스에 방향과 함께 적용해 주면 된다.


 

 

!======================================================================================

 

 

 

[출제유형 1 – NBAR 설정]

구분

내용

토폴로지

출제유형

NBAR를 사용하라. R2F0/1 인터페이스를 이용하여 R3 방향으로 다운로드 되어지는 HTTP 트래픽중에 URLwww.cisco.com이고 이미지명이 JPG 또는 JPEG 또는 GIF인 패킷에 대해 대역폭을 128Kbyte로 제한시켜라.

설명

NBAR를 이용한다.

ⓐ 관심 트래픽은 URLwww.cisco.com이고 이미지 파일들이 포함된 패킷에 한하여 적용된다.

ⓑ 다운로드를 의미하므로 방향은 F0/1 output 방향이다.

솔루션

[R2]

class-map match-all CLASS_NBAR

 match protocol http url "www.cisco.com"

 match protocol http url "*.jpg|*.jpeg*|*.gif"

!

policy-map POLICY_NBAR

 class CLASS_NBAR

   police 128000

!

interface FastEthernet0/1

 service-policy output POLICY_NBAR

결과값

[R2]

! NBAR 설정 결과

R2#show policy-map POLICY_NBAR

  Policy Map POLICY_NBAR

    Class CLASS_NBAR

     police cir 128000 bc 4000

       conform-action transmit

       exceed-action drop

 

! NBAR 인터페이스 적용 결과

R2#show policy-map interface fastEthernet 0/1 output

 FastEthernet0/1

 

  Service-policy output: POLICY_NBAR

 

    Class-map: CLASS_NBAR (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol http url "www.cisco.com"

      Match: protocol http url "*.jpg|*.jpeg*|*.gif"

      police:

          cir 128000 bps, bc 4000 bytes

        conformed 0 packets, 0 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          drop

        conformed 0 bps, exceed 0 bps

 

    Class-map: class-default (match-any)

      31 packets, 3178 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

 

 

- IP QoS 편 완료 -

 

 

 

- copy righted by CrazyWoo(우명하; woomha@naver.com)

Title
List of Articles
번호 제목 글쓴이 날짜 조회 수
공지 How To Install GNS3 on Ubuntu 10.04 LTS Hojung 2011.04.25 5751
50 Cisco SPAN Hojung 2013.04.17 1934
49 f/r setting on main interface Hojung 2011.05.03 2054
48 Reset configuration in router/switch Hojung 2011.05.03 2330
47 Basic Configuration (password, domain-lookup, hostname, timeout) Hojung 2011.05.03 2825
46 [Crazy4CCIE-R&S편]VII.Security Hojung 2011.04.27 4744
» [Crazy4CCIE-R&S편]VI. IP QoS (완료) Hojung 2011.04.27 8535
44 [Crazy4CCIE-R&S편]V.IP Multicast (완료) Hojung 2011.04.27 8119
43 [Crazy4CCIE R&S편]번외편 - 다이나밉스 운영 환경 최적화 Hojung 2011.04.27 4791
42 [Crazy4CCIE-R&S편]IV.IP and IOS Feature (완료) Hojung 2011.04.27 5964
41 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(3)-OSPFv3) Hojung 2011.04.27 4514
40 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(2)-RIPng) Hojung 2011.04.27 3207
39 [Crazy4CCIE-R&S편]II.IGP(9-IPv6-(1)-Concept) Hojung 2011.04.27 3042
38 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(3)-Red&Filter) Hojung 2011.04.27 2603
37 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(2)-Red&Metric) Hojung 2011.04.27 4694
36 [Crazy4CCIE-R&S편]II.IGP(8-Redistribute(재분배)-(1)-Concept) Hojung 2011.04.27 6610
35 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(3)-distribute-list-설정) Hojung 2011.04.27 3437
34 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(2)-labconfig) Hojung 2011.04.27 2312
33 [Crazy4CCIE-R&S편]II.IGP(7-Distribute-(1)-concept Hojung 2011.04.27 2166
32 [Crazy4CCIE-R&S편]II.IGP(6-Filtering-(1~5)access-list&prefix-list Hojung 2011.04.27 3646
31 [Crazy4CCIE-R&S편]II.IGP(5-EIGRP-(5)-Authentication) Hojung 2011.04.27 2580
Board Pagination ‹ Prev 1 2 3 Next ›
/ 3

Designed by sketchbooks.co.kr / sketchbook5 board skin

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5

Sketchbook5, 스케치북5