06QoS 튜토리얼QoS Tutorial

!튜토리얼 시나리오 *① Oxford — Security Management Server ② Cambridge — SmartConsole 클라이언트 ③ LAN(Engineering·Marketing) ④ London — QoS Security Gateway (4a eth2 199.199.199.32 / 4b eth1 199.32.43.32 / 4c eth0 199.32.32.32) ⑤ Web·FTP 서버가 있는 DMZ ⑥ 인터넷*

시나리오는 London·Oxford·Cambridge 세 곳에 사무실을 둔 조직입니다. QoS 게이트웨이는 London 에 있고 인터페이스가 셋(하나는 인터넷 연결), Management Server는 Oxford, SmartConsole은 Cambridge 에 있습니다. 내부망에는 Marketing과 Engineering 부서가 있습니다.

튜토리얼은 구성요소 설치·설정 → 새 QoS 정책 생성 → 정책 종류 선택 → 네트워크 객체 구성 → 서비스 구성 → 규칙 생성 → 게이트웨이에 정책 설치 순으로 흘러갑니다.

구성요소 설치

먼저 London 게이트웨이에 QoS·Firewall 등 블레이드를 켜 고, Oxford에 Management Server를, Cambridge PC에 SmartConsole을 설치합니다. 그다음 SmartConsole에서 Cambridge를 신뢰 클라이언트로 지정 하고, QoS 정책을 관리할 관리자를 정의하며, Oxford와 London 사이에 SIC 신뢰 가 맺어졌는지 확인합니다.

새 QoS 정책 만들기

게이트웨이에서 QoS 블레이드가 켜져 있는지 확인한 뒤, SmartConsole의 File > Manage Policies and Layers 에서 New 를 누릅니다. 정책 이름을 정하는데, 예약어·공백을 쓰면 안 되고, 숫자로 시작하거나 % # ' & * ! @ ? < > / \ : 같은 문자를 넣으면 안 되며, .pf·.W 로 끝나도 안 됩니다. 그다음 QoS 를 선택하고 Express(기본 정책) 또는 Recommended(전체 기능, 기본값) 를 고릅니다. OK 를 누르면 정책이 저장되고 SmartDashboard가 자동으로 열려 규칙을 짜기 시작할 수 있습니다.

좋은 정책을 짜려면 먼저 네트워크가 어떻게 쓰이는지 파악 해야 합니다. 트래픽 종류를 식별해 우선순위를 매기고, 사용자와 그 필요를 파악합니다. 이 예제의 방침은 HTTP는 RealAudio보다 많은 대역폭, Marketing은 Engineering보다 많은 대역폭 을 주는 것입니다.

게이트웨이 구성에서는 London 게이트웨이 객체와 Marketing·Engineering 서브넷 객체를 정의합니다. London 게이트웨이는 Gateways & Servers > New > Gateway > Classic Mode 로 만들고, 이름(London)·플랫폼·SIC(Communication 클릭)·버전(R82)·OS(Gaia)·IP를 채웁니다. 게이트웨이의 IP는 항상 외부 인터페이스 주소 를 씁니다. Network Security 탭에서 Firewall과 QoS를 켭니다.

인터페이스 정의

Network Management 에서 Get Interfaces 를 눌러 인터페이스를 가져온 뒤, 각 인터페이스(eth0/eth1/eth2)를 더블클릭해 주소·넷마스크·토폴로지·Anti-Spoofing을 설정합니다. 그리고 인터페이스 창의 QoS 탭 에서 Inbound Active·Outbound Active를 켜고, 둘 다 192000 — T1(1.5Mbps)로 전송률을 잡습니다.

서비스는 따로 만들 필요가 없습니다. 이 예제가 쓰는 HTTP와 RealAudio는 QoS에 이미 정의 되어 있습니다.

새 QoS 정책에는 항상 Default Rule이 자동으로 추가되며, 반드시 맨 마지막 에 있어야 합니다. 그러니 새 규칙은 모두 Default Rule 위 에 넣습니다. 이 예제에서는 SmartDashboard의 QoS 탭에서 Default 규칙을 고르고 Before current rule 아이콘으로 Web Rule 과 RealAudio Rule 두 개를 만듭니다.

서비스로 분류하기

규칙의 기본값을 다음처럼 바꿉니다 — Web Rule은 HTTP에 Weight 35, RealAudio Rule은 RealAudio에 Weight 5, Default는 Weight 10. Service 필드를 우클릭해 객체를 더하고, Action 필드를 더블클릭해 Rule Weight를 고칩니다. DNS·ARP 같은 "배경" 서비스는 보통 명시하지 않고 Default 규칙이 처리 합니다.

연결은 자기에게 적용되는 규칙의 가중치(우선순위) 비율만큼 대역폭 을 받습니다. 네 연결이 동시에 열린 경우를 보면 — HTTP는 35/50 = 70%, RealAudio는 5/50 = 10%, FTP·TELNET은 Default 공유로 각각 10/50 = 20% 를 받습니다. 핵심은 대역폭 배분이 연결이 열리고 닫힐 때마다 계속 바뀐다 는 점입니다. HTTP·FTP·TELNET이 모두 닫히면 RealAudio가 100%를 받고, TELNET·FTP만 닫히면 HTTP와 RealAudio가 풀린 대역폭을 나눠 갖습니다. 가중치가 아무리 작아도 그 트래픽이 굶지는 않는다 는 것이 WFQ의 성질입니다(두 연결만 열리면 RealAudio도 5/40 = 12.5%는 받음).

출발지로 분류하기

방침의 둘째 항목(Marketing > Engineering)은 출발지 기반 규칙으로 구현합니다 — Marketing Rule에 Weight 30, Engineering Rule에 Weight 20, Default에 Weight 10. 동작 원리는 서비스 기반과 같고, 배분 기준이 서비스가 아니라 출발지 라는 점만 다릅니다.

First Rule Match 원칙

이제 모든 규칙을 한 Rule Base에 모으면, 한 연결이 여러 규칙에 걸릴 수 있습니다. QoS는 First Rule Match(가장 먼저 매칭된 규칙) 원칙 으로 동작합니다 — 위에서부터 검사해 처음 매칭된 규칙의 Action만 적용 합니다.

그래서 Marketing 사용자가 HTTP를 열면 Web Rule과 Marketing Rule 둘 다에 걸리지만, 위에 있는 Web Rule이 적용되어 Weight 35 를 받습니다. HTTP를 출발지별로 다시 나누고 싶으면 Web Rule 아래에 서브 규칙을 둡니다.

가중치 말고 보장과 제한 으로도 대역폭을 정할 수 있습니다. Web Rule이 "가용 대역폭의 35%"를 받는다는 건 총 대역폭과 다른 규칙의 열린 연결 수에 따라 실제 양이 달라진다 는 뜻인데, 보장은 이를 절대값(Bytes/초)으로 못 박 습니다. 예를 들어 Web Rule에 Guarantee 20KBps 를 주면, 거기 매칭된 연결은 총 20KBps를 받고 남는 대역폭을 가중치대로 다시 나눠 갖습니다.

서브 규칙(Sub-Rule) 은 규칙 안에 중첩된 규칙 입니다. 예컨대 Web Rule(Weight 20) 아래에 Marketing HTTP(Weight 10)와 Default(Weight 1) 서브 규칙을 두면, Web Rule의 대역폭이 서브 규칙들에 10:1 비율 로 나뉩니다. 이때 서브 규칙의 Source·Destination·Service는 부모 규칙의 부분집합 이어야 하고, 서브 규칙 묶음에도 자체 Default가 자동 으로 생깁니다. 서브 규칙은 규칙 이름을 우클릭해 Add Sub-Rule 로 만듭니다.

규칙을 다 짰으면 설치합니다. SmartDashboard에서 Update 로 변경을 반영하고, SmartConsole에서 Install Policy 를 누른 뒤, 설치할 정책을 고르고 Policy Targets 에서 대상 게이트웨이를 선택해 Install 합니다.

설치가 실패하면 SmartConsole 왼쪽 아래 Task Information → Recent Tasks 에서 해당 작업의 Details 를 열고, Status 열의 ^ 아이콘으로 오류 메시지를 봅니다. 모든 오류를 해결해야 정책이 설치 됩니다.