이 문서에서는 지연에 민감한 애플리케이션과 대역폭 집약적인 애플리케이션을 포함하여 여러 애플리케이션의 전송 역할을 하는 네트워크에서 QoS(Quality of Service)를 구현하기 위한 몇 가지 높은 수준의 지침을 제공합니다. 이러한 애플리케이션은 비즈니스 프로세스를 향상시키지만 네트워크 리소스를 확장할 수 있습니다. QoS는 네트워크의 지연, 지연 변화(지터), 대역폭 및 패킷 손실을 관리하여 이러한 애플리케이션에 안전하고, 예측 가능하며, 측정 가능하고, 보장되는 서비스를 제공할 수 있습니다.
첫째, 비즈니스에 중요하며 보호가 필요한 애플리케이션을 결정합니다. 네트워크 리소스를 확보하기 위해 경쟁하는 모든 애플리케이션을 검토해야 할 수도 있습니다. 이 경우 Netflow Accounting, NBAR(Network-based Application Recognition) 또는 QDM(QoS Device Manager)을 사용하여 네트워크의 트래픽 패턴을 분석합니다.
NetFlow Accounting은 네트워크 트래픽에 대한 세부 정보를 제공하며 각 흐름과 관련된 트래픽 분류 또는 우선 순위를 캡처하는 데 사용할 수 있습니다.
NBAR는 애플리케이션 레이어까지의 트래픽을 식별할 수 있는 분류 툴입니다. 인터페이스를 통과하는 각 트래픽 플로우에 대한 인터페이스별, 프로토콜별 및 양방향 통계를 제공합니다. NBAR는 하위 포트 분류도 수행합니다. 애플리케이션 포트를 넘어 더 많은 것을 확인하고 파악합니다.
QDM은 라우터에서 고급 IP 기반 QoS 기능을 구성하고 모니터링하기 위한 사용하기 쉬운 그래픽 사용자 인터페이스를 제공하는 웹 기반 네트워크 관리 애플리케이션입니다.
보호가 필요한 애플리케이션의 특성을 이해하는 것이 중요합니다. 일부 애플리케이션은 지연 또는 패킷 손실에 민감한 반면, 다른 애플리케이션은 과부하 상태이거나 대역폭을 많이 소비하므로 "공격적"으로 간주합니다. 애플리케이션이 과부하 상태인 경우, 일정한 과부하 또는 작은 과부하가 있는지 확인합니다. 애플리케이션의 패킷 크기가 큰 것인가요, 작은 것인가요? 애플리케이션이 TCP 또는 UDP를 기반으로 합니까?
특성 | 가이드라인 |
---|---|
지연 또는 손실에 민감한 애플리케이션입니다. (음성 및 실시간 비디오) | WRED(Weighted Random Early Detection), 트래픽 셰이핑, 프래그먼트화(FRF-12) 또는 폴리싱을 사용하지 마십시오. 이러한 종류의 트래픽에 대해서는 LLQ(Low Latency Queuing)를 구현하고 지연에 민감한 트래픽에 대해 우선순위 큐를 사용해야 합니다. |
애플리케이션의 과부하 상태가 지속되거나 대역폭을 많이 사용하는 애플리케이션. FTP 및 HTTP | 대역폭을 보장하려면 WRED, 폴리싱, 트래픽 셰이핑 또는 클래스 기반 CBWFQ(Weighted Fair Queueing)를 사용합니다. |
TCP 기반의 애플리케이션입니다. | WRED를 사용합니다. 손실된 패킷으로 인해 TCP가 뒤로 물러났다가 슬로우 스타트 알고리즘을 사용하여 다시 램프업하기 때문입니다. 트래픽이 UDP 기반이며 패킷이 삭제될 때 동작을 변경하지 않는 경우 WRED를 사용하지 마십시오. 애플리케이션을 속도 제한해야 하는 경우 Policing을 사용합니다. 그렇지 않으면 패킷이 tail-drop 상태가 됩니다. |
구현하려는 QoS 기능을 활용하기 위해 일부 디바이스에서는 IOS 업그레이드가 필요할 수 있습니다. 각 디바이스의 네트워크 토폴로지, 라우터 컨피그레이션 및 소프트웨어 버전의 다이어그램은 IOS 업그레이드가 필요한 디바이스 수를 예상하는 데 도움이 됩니다. 네트워크 다이어그램을 만들 수 있는 아이콘은 Cisco Icon Library를 참조하십시오.
바쁜 기간 동안 각 라우터의 CPU 사용률을 평가하여 로드를 공유하기 위해 디바이스 간에 QoS 기능을 배포하는 방법을 결정할 수 있도록 합니다.
업무상 중요한 트래픽 유형 및 이 트래픽이 통과할 인터페이스를 분류합니다. 네트워크의 QoS 목표를 실현하기 위해 생성할 우선 순위 그룹 또는 클래스를 결정합니다.
가장 중요한 애플리케이션에서 처리할 수 있는 최대 지연 시간을 파악하고 트래픽 조정기(트래픽 셰이퍼 또는 폴리서) 내의 버스트 매개변수를 조정하여 이러한 지연을 수용합니다.
각 인터페이스에서 어떤 속도가 지원되는지 알아보십시오. PVC 또는 하위 인터페이스를 사용하고 일치하는 대역폭을 구성합니다.
느린 링크를 식별하여 네트워크의 병목 지점이 어디에 있는지 확인하고 적절한 인터페이스에 링크 효율성 메커니즘을 적용하는 방법을 결정합니다.
비즈니스 크리티컬 트래픽을 전송할 각 미디어 유형에 대한 레이어 2 및 레이어 3 오버헤드를 계산합니다. 이렇게 하면 각 클래스에 필요한 정확한 대역폭을 계산하는 데 도움이 됩니다.
애플리케이션, IP 소스 및 대상 또는 둘 모두를 기반으로 트래픽을 보호할지 여부도 중요한 정보입니다.
미디어 유형 | 링크 레이어 헤더 |
---|---|
이더넷 | 14바이트 |
PPP | 6바이트 |
프레임 릴레이 | 4바이트 |
ATM | 5바이트/셀 |
어떤 애플리케이션에 QoS가 필요한지, 애플리케이션의 특성에 따라 분류 기준을 결정하면 이 정보를 기반으로 클래스를 생성할 수 있습니다.
각 트래픽 클래스를 적절한 우선 순위 값으로 표시하는 정책을 생성합니다(차등 서비스 제어 지점(DSCP) 또는 IP 우선 순위 사용). 트래픽은 인그레스 인터페이스의 라우터로 들어올 때 표시됩니다. 이 표시는 트래픽이 이그레스 인터페이스의 라우터를 떠날 때 트래픽을 처리하는 데 사용됩니다.
트래픽과 가장 가까운 라우터에서 코어를 향해 작업합니다. 라우터의 인그레스 인터페이스에 표시를 적용합니다. 아래 토폴로지에서 라우터 A는 네트워크 A에서 소싱되고 라우터 B로 향하는 데이터에 트래픽을 표시하고 정책을 적용할 수 있는 명백한 위치입니다. 트래픽은 라우터 A의 Ethernet0 인터페이스에 들어올 때 표시되고, QoS 정책은 라우터 A의 Serial0 인터페이스에서 라우터를 떠날 때 적용됩니다. 네트워크 B에서 시작하고 네트워크 A로 향하는 트래픽이 동일한 처리를 받도록 양방향으로 동일한 정책을 적용해야 하는 경우, 네트워크 B에서 들어오는 트래픽은 라우터 B의 이더넷1 인터페이스로 들어오고 Serial1 인터페이스의 라우터를 떠날 때 처리되도록 표시해야 합니다.
한 라우터의 인그레스 인터페이스에 트래픽이 표시된 후에는 여러 홉을 지나는 것과 동일한 표시를 유지 관리합니다(다시 표시하지 않는 한). 일반적으로 트래픽은 한 번만 표시하면 됩니다. 이러한 표시에 따라 추가 홉에 QoS 정책을 적용할 수 있습니다. 트래픽이 신뢰할 수 없는 도메인에서 오는 경우에만 다시 표시해야 합니다.
트래픽을 표시했으므로, 표시를 사용하여 정책을 구축하고 나머지 네트워크 세그먼트에서 트래픽 분류를 수행할 수 있습니다. 4개 이하의 클래스를 사용하여 정책을 단순하게 유지하는 것이 좋습니다.
가능하면 랩 환경에서 QoS 구현을 구현하고 테스트합니다. 결과에 만족하면 라이브 네트워크에 구축합니다.
적절한 방향으로 정책을 적용합니다. 정책을 한 방향으로 적용할지 아니면 두 방향으로 적용할지 결정합니다. 이 문서의 각 클래스를 표시하기 위한 정책 생성 섹션에 설명된 대로, 트래픽을 가능한 소스와 가까운 곳으로 표시하고 처리합니다.
사이트의 양쪽에서 도착하고 양쪽으로 향하는 트래픽을 필터링하려면 양방향으로 동일한 정책을 적용하는 것이 좋습니다. 즉, RouterA의 직렬 인터페이스와 RouterB의 직렬 인터페이스에 동일한 정책 아웃바운드를 적용해야 합니다.
QPM을 중앙 집중식 정책 제어 및 자동화된 안정적인 정책 구축을 위한 완전한 시스템으로 사용합니다.
아래는 QOS 범주 및 각 범주와 관련하여 가장 널리 사용되는 QOS 기능의 목록입니다.
카테고리 | 관련 QoS 기능 |
---|---|
QoS 서비스 모델 | 가능한 경우 프로비저닝된(Diffserv) QoS, 필요한 경우 시그널링된(RSVP). |
분류/마킹 | Diffserv 코드 포인트 또는 qos-group ID. |
혼잡 관리 | LLQ 또는 CBWFQ입니다. |
혼잡 회피 | Diffserv 호환 WRED. |
링크 효율성 | MLPPP, LFI, FRF.11, FRF.12, CRTP |
신호 | RSVP, QPPB |
트래픽 조절기/폴리싱 | 클래스 기반 폴리서 및 GTS(Generic Traffic Shaping) 또는 FRTS(Frame-Relay Traffic Shaping)입니다. |
컨피그레이션/모니터링 | QPM, 모듈형 QoS CLI(Command Line Interface), QDM |
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
10-Dec-2001
|
최초 릴리스 |