IOS 소프트웨어 플랫폼의 큐 제한 및 출력 삭제 이해

소개

이 문서에서는 Cisco IOS® 소프트웨어 플랫폼 및 레거시 액세스 라우터의 대기열 제한 및 출력 삭제에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco IOS® Quality of Service 솔루션 컨피그레이션 가이드

• QoS - HQF(Hierarchical Queueing Framework)

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 버전을 기반으로 합니다.

• HQF 이전: Cisco IOS Software 릴리스 12.3(26)을 실행하는 Cisco 라우터

• HQF의 경우: Cisco IOS Software 릴리스 12.4(22)T를 실행하는 Cisco 라우터

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

배경 정보

이 문서는 Cisco IOS® 소프트웨어 플랫폼에만 적용되며, 여기에는 일반적으로 Cisco 7200VXR 및 Cisco ISR 3800, 2800, 1800 Series 라우터가 포함되며, 레거시 Cisco 액세스 라우터에는 3700, 3600, 2600, 1700 Series 라우터가 포함됩니다.

클래스 기반 가중치 공정 대기열 처리 기본 요소

HQF 이전 Cisco IOS 이미지에서는 일반적으로 bandwidth 명령이 있는 모든 클래스에 대해 대역폭 또는 클래스 가중치에 따라 우선 순위가 없는 클래스에 대해 우선 순위를 지정할 수 있습니다. CBWFQ(Class-Based Weighted Fair Queueing) 스케줄링 알고리즘을 이해하려면 먼저 가중치 개념을 이해해야 합니다. 이 가중치 개념은 플로우 기반 공정 대기열에 대한 플로우별 및 클래스 기반 가중치 공정 대기열 내의 개별 클래스 기반 대기열에 대한 클래스별 순서입니다.

플로우 기반 공정 대기열에 대한 가중치를 도출하는 공식은 다음과 같습니다.

32384 / (IP Prec + 1)

클래스 기반 Weighted Fair 큐 내의 사용자 정의 클래스는 클래스 기반 큐에 있는 모든 대역폭 클래스의 SUM의 비율로 클래스에 구성된 bandwidth 명령 함수로 각각의 가중치를 파생시킵니다. 정확한 공식은 독점 기술입니다.

HQF 이미지에서는 사용자 정의 클래스에서 구성 가능한 플로우 기반 공정 대기열과 공정 대기열이 있는 클래스 기본값이 모두 동일하게(가중치 대신) 예약됩니다. 또한 HQF에서 클래스 기반 큐의 예약 우선 순위는 클래스의 레거시 가중치 공식이 아니라 HQF 스케줄러를 기반으로 결정됩니다.

참고: 이 섹션에서는 클래스 기반 대기열 처리 작업에 대한 포괄적인 동작 분석을 다루지 않습니다. CBWFQ에서 큐 제한과 출력 삭제를 적용하는 방법에 대한 설명입니다.

큐 제한 및 출력 삭제 이해

Priority 명령으로 구성된 사용자 정의 클래스

priority MQC 사용자 정의 클래스는 priority, priority <kbps>및 priority percent포함된 모든 명령 변형으로 구성됩니다.

HQF 이전 동작

기술적으로 볼 수 있는 CLI가 없고 구성할 수 없지만 모든 우선순위 클래스 데이터가 공유하는 숨겨진 시스템 대기열이 있습니다. 이는 우선 순위 데이터를 분류한 후 혼잡 인식 폴리서의 허가를 받은 후 임시 저장소의 역할을 합니다. LLQ 패킷은 수신 인터럽트 중에 이그레스 인터페이스 전송 링에 직접 배치할 수 없는 경우 이 숨겨진 시스템 대기열에 배치됩니다. 이를 기능 혼잡이라고 합니다. 이 경우 기능적 혼잡이 존재하기 때문에 수신 인터럽트 전체에서 패킷이 LLQ 조건부 폴리서를 기준으로 평가되며 수신 인터페이스 드라이버가 패킷을 소유합니다. LLQ 조건부 폴리서에서 패킷을 삭제하지 않으면 이 숨겨진 LLQ 시스템 대기열에 배치되고 수신 인터럽트가 해제됩니다. 따라서 이 숨겨진 시스템 대기열에 있는 모든 패킷은 LLQ 혼잡 인식 폴리서에 일치하며 LLQ/CBWFQ 스케줄러에 의해 즉시 이그레스 인터페이스 전송 링으로 디큐잉될 수 있습니다.

이 큐가 존재함에도 불구하고 이 큐의 패킷은 LLQ/CBWFQ 스케줄러에 의해 전송 링으로 즉시 배출될 수 있기 때문에 추가 대기열 지연 시간(전송-링 지연 시간 이상)이 발생할 수 없다는 점에서 비 LLQ 데이터(예: fair-queue 및 bandwidth queue)에 대해 생성된 Cisco IOS 큐와 다릅니다. 수신 인터럽트 동안 조건부 폴리서가 우선순위 클래스 패킷을 삭제하지 않으면 이 LLQ 패킷이 이그레스 인터페이스의 전송 링으로 대기열에서 빼기 전에 잠시 숨겨진 시스템 대기열에 있을 수 있습니다. 이 경우 LLQ/CBWFQ 스케줄러는 패킷을 이그레스 인터페이스 전송 링에 즉시 제공할 수 있습니다. 조건부 폴리서는 패킷을 LLQ/CBWFQ에 승인하기 전에 실행되었으므로 구성된 우선순위 속도로 LLQ를 제한합니다.

요약하면, LLQ의 기본 구성 요소인 추가 큐잉 레이턴시를 발생시키는 것보다 혼잡 시 우선 순위 비율을 초과하는 LLQ 데이터를 삭제하는 것이 좋습니다. 이 조건부 폴리싱 메커니즘은 엄격한 우선순위 대기열을 허용하며, 우선순위 대기열이 전체 인터페이스 PLIM을 독점하도록 허용하지 않습니다. 이는 Cisco IOS의 레거시 우선순위 대기열 기능에 비해 향상된 기능입니다.

• Pre-HQF 큐 제한: NA

• Pre-HQF priority + random-detect behavior: NA, WRED는 LLQ에서 허용되지 않습니다.

• Pre-HQF priority + fair-queue" 동작: NA, LLQ에서는 fair-queue를 사용할 수 없습니다.

• Pre-HQF priority + random-detect + fair-queue behavior: NA, LLQ에서는 fair-queue 또는 random-detect가 모두 지원되지 않습니다.

HQF 동작

숨겨진 대기열이 더 이상 숨겨지지 않고 queue-limit이 구성 가능하며 기본값은 64패킷이라는 점을 제외하면 Pre-HQF와 동일합니다.

• HQF 큐 제한: 64개 패킷

• HQF 우선순위 + 임의 탐지 동작: NA, WRED는 LLQ에서 허용되지 않습니다.

• HQF 우선순위 + 공정 대기열 동작: NA, 공정 대기열은 LLQ에서 허용되지 않습니다.

• HQF priority + random-detect + fair-queue behavior: NA, LLQ에서는 fair-queue 또는 random-detect가 모두 지원되지 않습니다.

Bandwidth 명령으로 구성된 사용자 정의 클래스

bandwidth MQC 사용자 정의 클래스는 bandwidth <kbps> , bandwidth percent 및 bandwidth remaining percent포함된 명령의 모든 변형으로 구성됩니다.

HQF 이전 동작

queue-limit 기본값은 64패킷이며, 조정 가능합니다. 수신 인터럽트 중에 패킷을 큐에 넣어야 할 경우, 큐에 64개 이상의 패킷이 있으면 패킷이 테일 드롭됩니다.

• Pre-HQF queue-limit: 64개의 패킷으로, queue-limit을 통해 조정 가능합니다.

• Pre-HQF 대역폭 + "임의 탐지" 동작:

예:

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

임의의 변형 대역폭이 임의의 변형 random-detect와 함께 구성된 경우 클래스의 모든 버퍼 제한을 효과적으로 제거하는 모든 queue-limit CLI를 무시합니다. 즉, 임의 탐지 및 대기열 제한은 사전 HQF 이미지에서 상호 배타적입니다. 임의 탐지 as 삭제 전략을 사용하면 현재 대기열 크기가 제한되지 않으며 이론적으로 클래스 기반 공정 대기열에 할당된 모든 버퍼를 차지할 수 있습니다. 여기서 클래스 기반 공정 대기열에 할당된 버퍼 수는 서비스 정책 연결 지점을 기준으로 파생됩니다.

• 물리적 인터페이스: 1,000개 패킷, 인터페이스 CLI 보류 대기열 출력 시 조정 가능

• ATM PVC: 500개의 패킷, PVC CLI vc-hold-queue로 튜닝 가능

• Frame-Relay map-class: 600개 패킷, tunable with frame-relay map-class CLI frame-relay hold-queue

• (sub)interface(pre-HQF)에 적용되는 클래스 기반 셰이핑 정책: 1000개의 패킷, MQC 클래스 CLI 셰이프 max-buffers로 튜닝 가능.

참고: 모든 프레임 릴레이 및 클래스 기반 쉐이핑 예에서는 쉐이퍼의 합이 인터페이스 클럭 속도를 초과하지 않는다고 가정합니다.

참고: HQF 이전 이미지의 경우 클래스 기반 셰이핑 정책이 (하위) 인터페이스에 적용될 때 기본 물리적 인터페이스의 속도를 주의하십시오. 인터페이스 <2Mbps는 Weighted Fair Queue로, 인터페이스 >2Mbps는 FIFO로 기본 설정할 수 있습니다. Pre-HQF에서 쉐이핑 큐는 쉐이핑 정책이 하위 인터페이스에 연결되었는지 또는 물리적 인터페이스 레벨에 연결되었는지 여부에 관계없이 인터페이스 보류 큐를 공급할 수 있습니다.

수신 인터럽트 중에 패킷이 인터페이스 출력 대기열에 대한 후보가 될 때마다 WRED 평균 대기열 크기가 다음 공식으로 계산됩니다.

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

결과 평균 대기열 크기가 다음과 같은 경우:

• WRED min-threshold보다 작은 경우 패킷을 큐에 넣고 수신 인터럽트를 해제합니다.
• WRED min-threshold와 WRED max-threshold 사이에 있으며, 평균 대기열 크기가 WRED max-threshold에 가까워질수록 확률이 높아지는 패킷을 삭제할 수 있습니다. Average Queue Size(평균 큐 크기)가 WRED max-threshold(WRED 최대 임계값)와 정확히 같으면 표시 확률 분모에 따라 패킷이 삭제됩니다. 표시 확률 분모는 평균 대기열 제한이 WRED max-threshold와 정확히 같지는 않지만 WRED min-threshold보다 높을 때 삭제할 수 있는 패킷의 비율을 결정하는 기준선의 역할도 합니다. 다음은 그래픽 예입니다.

평균 큐 제한은 WRED 최대 임계값과 같지 않지만 WRED 최소 임계값보다 높습니다.

• • 패킷이 삭제되면 수신 인터럽트가 해제되고 임의 삭제가 증가합니다. 패킷이 삭제되지 않으면 패킷이 대기열에 추가되고 수신 인터럽트가 해제됩니다.

  • WRED max-threshold보다 높으면 패킷을 삭제하고 수신 인터럽트를 해제하고 Tail Drop을 증가시킵니다.

참고: IP Precedence based(기본값) 및 DSCP 기반 WRED에서는 최소 임계값, 최대 임계값 및 표시 확률 분모를 서로 다른 값에 대해 다르게 정의할 수 있습니다. 여기서 Random Early Detection의 Weighted 구성 요소가 분명합니다. 상대 임계값을 조정하고 확률 분모를 표시할 때 특정 ToS 값을 다른 값과 비교하여 보호할 수 있습니다.

임의 탐지 및 대역폭이 함께 구성된 경우, 특정 시점의 Current Queue Size(현재 큐 크기)는 WRED max-threshold(WRED 최대 임계값)보다 클 수 있습니다. 이는 WRED 최소 및 최대 임계값이 평균(현재 아님) 대기열 크기에만 따라 작동하기 때문입니다. 이렇게 하면 클래스 기반 큐에 할당된 모든 버퍼를 만료할 수 있습니다. 그러면 클래스 기반 공정 큐 내의 아무 곳에서나 버퍼가 삭제되지 않을 수 있습니다(Cisco 버그 ID CSCsm94757 참조).

• Pre-HQF 대역폭 + Fair-Queue 동작: NA, Fair-Queue는 대역폭 클래스에서 허용되지 않습니다.

• Pre-HQF 대역폭 + 임의 감지 + 공정 대기열 동작: NA, 공정 대기열은 대역폭 클래스에서 허용되지 않습니다.

HQF 동작

이 동작은 Pre-HQF 섹션에 설명된 내용과 동일합니다.

• HQF queue-limit: 64개 패킷, queue-limit을 통해 조정 가능.

이는 pre-HQF의 경우와 동일합니다.

• HQF 대역폭 + 임의 탐지 동작:

예:

policy-map HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   queue-limit 512
   random-detect

참고: queue-limit 기본값은 64패킷입니다.

이 동작은 동일한 HQF 이전의 섹션과 동일하며, 한 가지 중요한 예외가 있습니다. HQF 이미지에서 random-detect 및 queue-limit은 동일한 사용자 정의 클래스(또는 클래스 클래스-default)에 공존할 수 있으며 queue-limit을 활성화하고 기본 컨피그레이션에서 64개의 패킷으로 튜닝할 수 있습니다. 따라서 queue-limit은 임의 탐지 클래스의 최대 현재 대기열 크기 역할을 할 수 있으므로, 동등한 pre-HQF 섹션에서 설명하는 버퍼 없는 삭제를 제한하는 메커니즘을 제공할 수 있습니다. 따라서 구성된 queue-limit은 최소한 random-detect max-threshold만큼 커야 합니다. 여기서 random-detect max-threshold는 기본적으로 40개의 패킷으로 설정되거나 그렇지 않으면 파서가 컨피그레이션을 거부할 수 있습니다.

이렇게 하면 WRED 클래스의 current-queue-limit 검사가 도입됩니다. 즉, Average Queue Depth 계산이 max-threshold보다 작은 경우에도 Current(not Average) Queue Size가 queue-limit보다 큰 경우 패킷을 삭제하고, 수신 인터럽트를 해제하고, Tail Drop을 기록할 수 있습니다. queue-limit이 클래스 기반 큐의 집계 대기열 버퍼를 모두 소진할 수 있도록 충분히 높게 튜닝된 경우 버퍼 삭제는 발생하지 않을 수 있습니다. HQF에 대한 집계 대기열 버퍼는 다음과 같이 정의됩니다.

• 물리적 인터페이스: 1,000개 패킷, 인터페이스 CLI 보류 대기열 출력으로 튜닝 가능

• ATM PVC: 500개의 패킷, PVC CLI vc-hold-queue로 튜닝 가능

• Frame-Relay map-class: 600개 패킷, frame-relay map-class CLI frame-relay hold-queue로 튜닝 가능

• HQF 코드의 물리적 인터페이스에 적용되는 클래스 기반 셰이핑 정책: 1000개 패킷으로, 인터페이스 CLI 보류 대기열 출력 및 하위 정책 대기열 제한 조합으로 조정 가능합니다. 여기서 하위 정책 대기열 제한은 인터페이스 보류 대기열 출력의 상한을 가집니다.

• HQF 코드의 하위 인터페이스에 적용되는 클래스 기반 셰이핑 정책: 512개 패킷, 조정 불가능(NSSTG QoS 플랫폼 팀으로 조사, 조정 가능해야 함).

참고: 모든 프레임 릴레이 및 클래스 기반 쉐이핑 예에서는 쉐이퍼의 합이 인터페이스 클럭 속도를 초과하지 않는다고 가정합니다.

실제 사례는 다음과 같습니다.

policy-map JACKLYN
 class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

이 출력에서는 인터페이스를 통해 트래픽이 생성되지 않습니다.

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

이 시점에서 트래픽이 시작됩니다. 스트림은 400PPS에서 버스트 상태가 아니며 1000바이트 프레임으로 구성됩니다.

F340.11.25-7200-5_LAC#show policy-map interface | i queue
  queue limit 500 packets
  (queue depth/total drops/no-buffer drops) 461/387641/0

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

  Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 363/387919/0 

!--- 363 is Current_q_depth and it is falling compared to last 
!--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets 
!--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop 
!--- in addition to random-drop. 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 199/388263/0 
 Mean queue depth: 312 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 303/388339/0 
 Mean queue depth: 276 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 325/388498/0 
 Mean queue depth: 314 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 298/390075/0 
 Mean queue depth: 300 packets  

결국 비 버스트 스트림에서 WRED Average Queue Depth가 Current Queue Depth와 같아지게 됩니다. 이는 예상되는 동작입니다.

• HQF 대역폭 + 공정 대기열 동작:

HQF 사용자 정의 클래스에 대역폭과 Fair-Queue를 함께 적용하면 각 플로우 기반 대기열에 0.25*queue-limit와 같은 queue-limit이 할당됩니다. 기본 queue-limit는 64패킷이므로, fair-queue의 각 흐름 기반 대기열은 16패킷을 할당할 수 있습니다. 4개의 플로우가 이 클래스를 통과하는 경우 기본적으로 각 플로우 대기열에는 16개의 패킷이 있으므로 총 패킷이 >64(4 *16)로 큐에 추가되지는 않을 것입니다. 개별 flow-queue의 모든 tail drop은 flow-drop으로 기록됩니다. flow-queue 수가 queue-limit와 같이 상당히 많으면 버퍼 없는 삭제의 또 다른 기회가 발생합니다. 예를 들어, 정책 연결 지점이 물리적 인터페이스라고 가정할 경우, 여기서 1000개의 종합 버퍼가 할당됩니다.

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

이 컨피그레이션에서는 모든 플로우 대기열의 주목할 만한 트래픽이 집계 인터페이스 버퍼를 부족하게 만들고 다른 사용자 정의 클래스에서 버퍼 없는 삭제를 초래할 수 있습니다(Cisco 버그 ID CSCsw98427 참조). 각각 패킷 큐 제한이 32개인 1024개의 플로우 큐는 1000개의 집계 인터페이스 클래스 기반 큐 버퍼 할당을 쉽게 오버서브스크립션할 수 있기 때문입니다.

• HQF 대역폭 + 임의 감지 + 공정 대기열 동작:

예:

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

WRED Average Queue Size(WRED 평균 큐 크기)를 제외한 섹션의 대역폭 및 Fair-Queue와 동일하게 패킷이 도착할 때마다 계산되어 패킷이 무작위로 삭제되어야 하는지 또는 테일 삭제되어야 하는지를 결정합니다. pre-HQF와 마찬가지로 모든 플로우 대기열은 WRED 임계값의 인스턴스를 공유할 수 있습니다. 즉, 모든 플로우 대기열에 넣은 모든 패킷을 사용하여 WRED 평균 대기열 깊이를 계산한 다음 삭제 결정을 통해 모든 플로우 대기열의 종합 패킷에 대해 WRED 최소 및 최대 임계값을 적용합니다. 그러나 WRED 임계값의 한 인스턴스가 모든 플로우 기반 큐에 적용되므로, 개별 플로우 큐의 큐 제한(.25 * "큐 제한")은 무시되고 대신 현재 큐 제한 확인에 대한 클래스 집계 큐 제한을 따릅니다.

클래스 기본 동작

HQF 이전 동작

Pre-HQF에서 Class Default는 fair-queue로 기본 설정되고 모든 flow-queue는 클래스에 대한 queue-limit을 공유하며(기본값은 64) 대역폭 예약은 없습니다. 즉, 모든 플로우 대기열에 삽입된 총 패킷 수는 queue-limit을 초과할 수 없습니다. 각 플로우 대기열에 넣은 패킷의 양은 플로우 대기열의 계산된 가중치에 따라 달라질 수 있습니다. 반대로, class-default에서 fair-queue 및 random-detect가 함께 사용되는 경우 queue-limit을 무시하고 모든 flow-queue가 동일한 WRED 임계값을 공유할 수 있습니다. 따라서 모든 플로우 대기열에 현재 대기열에 있는 모든 패킷을 사용하여 WRED 평균 대기열 크기를 계산할 수 있습니다. 이 컨피그레이션에서 Current Queue Size(현재 큐 크기)에 상한이 없으므로 버퍼 없는 삭제의 기회가 높습니다(Cisco 버그 ID CSCsm94757 참조).

• 대역폭이 class-default에 추가되면 Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth" Command 섹션에 설명된 동작이 발생할 수 있습니다.

• 대역폭 및 임의 탐지가 클래스 클래스 클래스 default에 추가되면 "bandwidth" 명령으로 구성된 Pre-HQF Behavior - User Defined Classes의 Pre-HQF bandwidth + random-detect behavior 섹션에 설명된 동작이 발생할 수 있습니다.

참고: pre-HQF에서는 class-default에서 대역폭이 fair-queue와 공존할 수 없습니다.

HQF 동작

HQF에서 Class Default(클래스 기본값)는 FIFO 대기열을 기본값으로 설정하며 사용자 정의 클래스에서 남은 할당을 기반으로 의사 대역폭 예약을 할당합니다. 따라서 HQF 클래스 기본 동작은 HQF 동작 - "bandwidth" 명령 섹션으로 구성된 사용자 정의 클래스를 참조하십시오. HQF 이미지의 class-default는 컨피그레이션과 상관없이 항상 사용자 정의 클래스에서 사용하지 않는 인터페이스 대역폭과 동일한 암시적 대역폭 예약을 가질 수 있습니다. 기본적으로 class-default 클래스는 인터페이스 또는 상위 셰이프 대역폭의 최소 1%를 수신합니다. 클래스 기본값에서 대역폭 CLI를 명시적으로 구성할 수도 있습니다.

• Class-Default 클래스에 fair-queue가 구성된 경우 동작은 HQF Behavior - User Defined Classes의 HQF bandwidth + fair-queue behavior 섹션("bandwidth" 명령으로 구성된 클래스)과 일치합니다.

• Class-Default에서 Fair-queue 및 Random-detect가 함께 구성된 경우 동작은 HQF Behavior - "bandwidth" 명령으로 구성된 사용자 정의 클래스의 HQF 대역폭 + Random-detect + Fair-queue 동작 섹션과 일치합니다.

관련 정보

• Cisco IOS Quality of Service 솔루션 컨피그레이션 가이드, 릴리스 12.2SR
• QoS - HQF(Hierarchical Queueing Framework) [지원되지 않음]
• 라우터 지원
• Cisco 기술 지원 및 다운로드