12000 Series 라우터에서 MDRR/WRED 이해 및 구성
목차
소개
이 문서에서는 Cisco 12000 Series Internet Router에서 Cisco IOS® Software 혼잡 관리 및 혼잡 방지 기능을 구성하는 방법을 살펴봅니다.
이 문서를 읽은 후에는 다음을 수행할 수 있어야 합니다.
-
코어 네트워크에서 MDRR(Modified Defense Round Robin) 및 WRED(Weighted Random Early Detection)를 구성하는 것이 중요한 이유를 알아보십시오.
-
Cisco 12000 Series에서 MDRR 및 WRED를 기반으로 구현된 내용을 이해합니다.
-
레거시 CoS(Class of Service) 구문 및 MQC(Modular QoS CLI)를 사용하여 MDRR 및 WRED를 구성합니다.
사전 요구 사항
요구 사항
이 문서의 독자는 다음 주제에 대해 알고 있어야 합니다.
-
Cisco 12000 Series Internet Router 아키텍처에 대한 일반적인 지식.
-
특히 대기열 처리 아키텍처와 이러한 용어를 인식하는 경우
-
ToFab(패브릭 방향) - 인바운드 라인 카드의 수신 측 대기열을 설명합니다.
-
FrFab(From the fabric) - 아웃바운드 라인 카드의 전송 측 대기열을 설명합니다.
-
참고: 또한 show controller ffab의 출력을 읽는 방법을 찾는 것이 좋습니다. | Cisco 12000 Series 인터넷 라우터의 tofab queue 명령.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
-
12008, 12012, 12016, 12404, 12406, 12406, 12410 및 12416을 포함하는 모든 Cisco 12000 플랫폼입니다.
-
Cisco IOS Software 릴리스 12.0(24)S1.
참고: 이 문서의 구성은 Cisco IOS Software Release 12.0(24)S1에서 테스트되었지만 Cisco 12000 Series 인터넷 라우터를 지원하는 모든 Cisco IOS 소프트웨어 릴리스를 사용할 수 있습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
배경 정보
대기열 처리 방법은 패킷 스케줄링 메커니즘 또는 패킷이 물리적 와이어에서 전송을 위해 인터페이스로 대기열에서 제거되는 순서를 정의합니다. 일정 관리기 기능에서 대기열을 서비스하는 순서 및 횟수를 기반으로, 대기열 처리 방법은 최소 대역폭 보증 및 낮은 레이턴시를 지원합니다.
패킷 스케줄링 메커니즘이 구현되는 스위칭 아키텍처를 지원하는지 확인해야 합니다. WFQ(Weighted Fair Queuing)는 버스 기반 아키텍처를 갖춘 Cisco 라우터 플랫폼에서 리소스를 할당하기 위해 잘 알려진 스케줄링 알고리즘입니다. 그러나 Cisco 12000 Series 인터넷 라우터에서는 지원되지 않습니다. 기존 Cisco IOS 소프트웨어 우선순위 큐잉 및 맞춤형 큐잉도 지원되지 않습니다. 대신 Cisco 12000 Series는 MDRR(Modified Defense Round Robin)이라는 특수한 형태의 큐잉을 사용하며, 이 큐잉은 상대적 대역폭 보장은 물론 낮은 레이턴시 대기열을 제공합니다. MDRR의 M은 "modified"를 의미합니다. 우선 순위 큐가 없는 DRR과 비교하여 우선 순위 큐를 추가합니다. MDRR에 대한 자세한 내용은 MDRR 개요 섹션을 참조하십시오.
또한 Cisco 12000 Series는 MDRR 큐 내에서 삭제 정책으로 WRED(Weighted Random Early Detection)를 지원합니다. 이러한 혼잡 회피 메커니즘은 기본 테일 드롭 메커니즘의 대안을 제공합니다. 이러한 혼잡은 통제된 드롭으로 막을 수 있습니다.
WRED 및 MDRR과 같은 혼잡 방지 및 관리 메커니즘은 LC(Channelized Line Card)와 같이 상대적으로 속도가 낮은 아웃바운드 인터페이스의 FrFab 대기열에서 특히 중요합니다. 고속 스위치 패브릭은 채널 그룹이 전송할 수 있는 것보다 훨씬 빠르게 채널 그룹에 패킷을 전달할 수 있습니다. 큐잉/버퍼가 물리적 포트 레벨에서 관리되므로 한 채널의 역압은 해당 포트의 다른 모든 채널에 영향을 줄 수 있습니다. 따라서 문제의 채널에 대한 역압력이 미치는 영향을 제한하는 WRED/MDRR을 통해 이러한 역압력을 관리하는 것이 매우 중요합니다. 아웃바운드 인터페이스 오버서브스크립션을 관리하는 방법에 대한 자세한 내용은 Cisco 12000 Series 인터넷 라우터의 Troubleshooting Ignored Packets and No Memory Drops를 참조하십시오.
MDRR 개요
이 섹션에서는 MDRR(Modified Defense Round Robin)에 대한 개요를 제공합니다.
MDRR이 대기열 처리 전략으로 구성되면 비어 있지 않은 대기열은 라운드 로빈 방식으로 차례로 제공됩니다. 큐가 제공될 때마다 고정된 양의 데이터가 대기열에서 제거됩니다. 그런 다음 알고리즘이 다음 대기열에 서비스를 제공합니다. 큐가 제공되면 MDRR은 구성된 값을 초과하여 대기열에서 제거된 데이터의 바이트 수를 추적합니다. 다음 단계에서는 큐가 다시 제공되면 이전에 제공된 초과 데이터를 보완하기 위해 대기열에서 제거된 데이터가 줄어듭니다. 따라서 대기열당 대기열에서 제거된 평균 데이터 양은 구성된 값에 근접하게 됩니다. 또한 MDRR은 우선 순위에 따라 제공되는 우선 순위 대기열을 유지 관리합니다. MDRR에 대해서는 이 섹션에서 자세히 설명합니다.
MDRR 내의 각 대기열은 두 가지 변수로 정의됩니다.
-
Quantum value - 각 라운드에서 제공되는 평균 바이트 수입니다.
-
Defense 카운터 - 큐가 각 라운드에서 전송된 바이트 수를 추적하는 데 사용됩니다. 양자 값으로 초기화됩니다.
손실률 카운터가 0보다 큰 경우 대기열의 패킷이 제공됩니다. 제공된 각 패킷은 바이트 길이와 같은 값으로 부족 카운터를 줄입니다. 손실률 카운터가 0이나 음수가 된 후에는 더 이상 대기열을 처리할 수 없습니다. 각각의 새 라운드에서는 비어 있지 않은 각 큐의 부족 카운터가 양자 값으로 증가합니다.
참고: 일반적으로 대기열의 양자 크기는 인터페이스의 MTU(최대 전송 단위)보다 작으면 안 됩니다. 이렇게 하면 스케줄러가 항상 비어 있지 않은 각 대기열에서 하나 이상의 패킷을 제공합니다.
각 MDRR 대기열에는 상대적 가중치를 지정할 수 있으며, 그룹의 대기열 중 하나가 우선순위 대기열로 정의됩니다. 가중치는 인터페이스가 혼잡할 때 각 대기열에 대해 상대 대역폭을 할당합니다. MDRR 알고리즘은 전송할 대기열에 데이터가 있는 경우 각 대기열의 데이터를 라운드 로빈 방식으로 대기열에서 빼냅니다.
모든 일반 MDRR 대기열에 데이터가 있으면 다음과 같이 처리됩니다.
0-1-2-3-4-5-6-0-1-2-3-4-5-6 ...
각 주기 동안 큐는 구성된 가중치에 따라 큐의 대기열에서 양자를 빼낼 수 있습니다. Engine 0 및 Engine 2 라인 카드에서 값 1은 인터페이스의 MTU 가중치를 제공하는 것과 같습니다. 1보다 큰 각 증가분에 대해 대기열의 가중치는 512바이트입니다. 예를 들어, 특정 인터페이스의 MTU가 4470이고 큐의 가중치가 3으로 구성된 경우 순환을 통해 매번 4470 + (3-1)*512 = 5494바이트가 대기열에서 제거될 수 있습니다. 두 개의 일반 DRR 대기열 Q0 및 Q1을 사용하는 경우 Q0은 가중치가 1이고 Q1은 가중치가 9로 구성됩니다. 두 대기열이 혼잡할 경우 순환을 통해 매번 Q0은 4470바이트를 보낼 수 있으며 Q1은 [4470 + (9-1)*512] = 8566바이트를 보낼 수 있습니다. 이렇게 하면 Q0으로 이동하는 트래픽과 Q1을 통과하는 트래픽은 대역폭의 약 2/3에 해당합니다.
참고: MDRR 대역폭 할당을 계산하는 데 사용되는 표준 대기열 제거 공식은 D = MTU + (weight-1)*512입니다. Cisco IOS 소프트웨어 릴리스 12.0(21) S/ST 이전 버전에서는 엔진 4 라인 카드가 다른 대기열 제거 공식을 사용했습니다. 올바른 대역폭 할당을 위해 MDRR 가중치를 구성하려면 12.0(21) S/ST 이후 버전의 Cisco IOS Software 릴리스를 실행해야 합니다.
참고: Engine 4+ 라인 카드에 대한 양자 수식은 (toFab 방향의 경우 FrFab의 경우 Quantum = BaseWeight + {BaseWeight * (QueueWeight - 1) * 512} / MTU에 대해 유효하지 않습니다. BaseWeight는 다음 수식을 사용하여 가져옵니다. BaseWeight = {(MTU + 512 - 1) / 512} + 5
참고: 모든 계산은 반올림됩니다. 즉, 모든 소수 자릿수가 무시됩니다.
참고: 특정 엔진 라인 카드가 MDRR을 지원하는지 확인하려면 엔진 유형별 MDRR 지원을 참조하십시오.
MDRR의 우선순위 대기열
Cisco 12000 Series는 MDRR 내에서 PQ(Priority Queue)를 지원합니다. 이 대기열은 VoIP(Voice over IP)와 같은 시간에 민감한 트래픽에 필요한 낮은 지연 및 낮은 지터를 제공합니다.
위에서 언급한 것처럼 Cisco 12000 Series는 WFQ(Weighted Fair Queuing)를 지원하지 않습니다. 따라서 MDRR 내의 PQ는 다른 플랫폼에서 사용할 수 있는 Cisco IOS 소프트웨어 LLQ(Low Latency Queuing) 기능과 다르게 작동합니다.
가장 큰 차이점은 표 1에 나와 있는 것처럼 MDRR 스케줄러가 두 가지 모드 중 하나로 PQ를 서비스하도록 구성하는 방법입니다.
표 1 - 두 가지 모드에서 PQ를 서비스하도록 MDRR 스케줄러를 구성하는 방법| 대체 모드 | 엄격한 우선 순위 모드 | |
|---|---|---|
| 장점 | 여기서 PQ는 다른 대기열 사이에 서비스됩니다. 다시 말해, MDRR 스케줄러는 PQ 및 구성된 다른 대기열을 서비스합니다. | 여기서 PQ는 비어 있지 않을 때마다 서비스됩니다. 이렇게 하면 일치하는 트래픽에 대해 가능한 가장 낮은 지연이 제공됩니다. |
| 단점 | 이 모드에서는 엄격한 우선순위 모드와 비교할 때 지터와 지연이 발생할 수 있습니다. | 이 모드에서는 다른 대기열이 중단될 수 있습니다. 특히 일치하는 흐름이 적극적인 발신자인 경우 더욱 그렇습니다. |
대체 모드에서는 지터 및 지연에 대한 제어력을 줄일 수 있습니다. MDRR 스케줄러가 데이터 대기열에서 MTU 크기의 프레임을 서비스하기 시작한 다음 음성 패킷이 PQ에 도착하면 대체 모드의 스케줄러는 해당 부족 카운터가 0에 도달할 때까지 우선순위 없는 대기열을 완전히 제공합니다. 이 시간 동안 PQ가 서비스되지 않으며 VoIP 패킷이 지연됩니다.
이와 달리 엄격한 우선순위 모드에서는 스케줄러 서비스가 현재 우선순위가 아닌 패킷만 제공하고 PQ로 전환합니다. 스케줄러는 PQ가 완전히 비어 있는 후에만 우선순위가 아닌 대기열의 서비스를 시작합니다.
대체 우선순위 모드의 우선순위 대기열은 순환에 두 번 이상 서비스되므로 동일한 명목상 가중치를 가진 다른 대기열보다 더 많은 대역폭을 사용합니다. 정의된 큐 수에 대한 기능은 얼마나 더 많습니까? 예를 들어, 대기열이 3개인 경우 대기 시간이 낮은 대기열은 다른 대기열보다 2배 자주 서비스되며, 주기당 가중치가 2배로 전송됩니다. 8개의 대기열을 정의하면 지연 시간이 짧은 대기열이 7배 더 자주 서비스되며 유효 가중치는 7배 더 높습니다. 따라서 대기열에서 사용할 수 있는 대역폭은 라운드 로빈당 제공되는 빈도와 관련이 있으며, 이는 전체 대기열 수에 따라 달라집니다. 대체 우선순위 모드에서 우선순위 대기열은 일반적으로 이러한 특정 이유로 작은 가중치로 구성됩니다.
예를 들어 4개의 대기열이 정의되었다고 가정합니다. 0, 1, 2 및 우선순위 대기열입니다. 대체 우선순위 모드에서 모든 대기열이 혼잡할 경우 다음과 같이 처리됩니다. 0, llq, 1, llq, 2, llq, 0, llq, 1,.... llq는 짧은 대기 시간을 의미합니다.
대기열이 서비스될 때마다 구성된 가중치까지 보낼 수 있습니다. 따라서 저지연 대기열의 최소 대역폭은 다음과 같습니다.
-
WL = 낮은 대기 시간 대기열의 가중치.
-
W0, W1, ... Wn = 일반 DRR 큐의 가중치입니다.
-
n = 이 인터페이스에 사용된 일반 DRR 큐 수입니다.
-
BW = 링크의 대역폭.
대체 우선순위 모드의 경우, 낮은 레이턴시 대기열의 최소 대역폭 = BW * n * WL / (n * WL + Sum(W0,Wn)).
가중치는 MDRR에서 구성할 수 있는 유일한 변수 매개변수입니다. 트래픽 클래스에서 사용할 수 있는 대역폭의 상대적 양 및 한 번에 전송되는 트래픽의 양에 영향을 줍니다. 더 큰 가중치를 사용하면 전체 주기가 더 길어지고 지연이 증가할 수 있습니다.
구성 지침
-
다른 클래스 중에서 지연과 지터를 최대한 낮게 유지하려면 대역폭 요구 사항이 가장 낮은 클래스의 가중치를 1로 구성하는 것이 좋습니다.
-
가능한 가장 낮은 가중치 값을 선택합니다. 대역폭이 가장 낮은 클래스에 대해 가중치가 1로 시작합니다. 예를 들어, 각 클래스에 대해 대역폭이 50%인 두 개의 클래스를 사용하는 경우 1과 1을 구성해야 합니다. 1을 선택할 때 성능에 영향을 주지 않으므로 10과 10을 사용하는 것이 적절하지 않습니다. 또한 가중치가 높을수록 더 많은 지터가 발생합니다.
-
LLQ의 낮은 가중치 값은 매우 중요합니다. 특히 다른 클래스에 너무 많은 지연 또는 지터를 추가하지 않으려면 대체 모드에서 사용합니다.
MDRR 예
이 섹션의 예는 Inside Cisco IOS® Software Architecture, Cisco Press에서 가져온 것입니다.
대기열이 3개 있다고 가정해 보겠습니다.
-
대기열 0 - 1500바이트의 양자 대체 모드에서 작동하도록 구성된 짧은 대기 시간 대기열입니다.
-
대기열 1 - 3000바이트의 양자
-
대기열 2 - 1500바이트의 양자
그림 1은 수신 및 대기열에 있는 일부 패킷과 함께 큐의 초기 상태를 보여줍니다.
그림 1 - MDRR 초기 상태 
큐 0이 먼저 서비스되고, 해당 양자가 250바이트인 Packet 1에 추가되고, 그 크기가 적자 카운터에서 공제됩니다. 큐 0의 부족 카운터가 0보다 크기 때문에(1500 - 250 = 1250), 패킷 2도 전송되고 해당 길이가 부족 카운터에서 공제됩니다. 큐 0의 부족 카운터가 이제 -250이므로 대기열 1이 다음에 서비스됩니다. 그림 2는 이 상태를 나타냅니다.
그림 2 - MDRR 후속 상태 
큐 1의 부족 카운터가 3000(0 + 3000 = 3000)으로 설정되고 패킷 4 및 5가 전송됩니다. 전송된 각 패킷에서 부족 카운터에서 패킷 크기를 빼므로, 큐 1의 부족 카운터가 0으로 줄어듭니다. 그림 3은 이 상태를 보여줍니다.
그림 3 - 대기열 1의 부족 카운터가 0인 경우 MDRR 상태 
대체 우선 순위 모드에서 서비스 큐 0으로 다시 돌아와야 합니다. 다시 quantum이 현재 부족 카운터에 추가되고 큐 0의 부족 카운터가 결과로 설정됩니다(-250 + 1500 = 1250). 이제 부족 카운터가 0보다 크고 큐 0이 비어 있으므로 패킷 3이 전송됩니다. 대기열을 비울 때 그림 4와 같이 적자 카운터가 0으로 설정됩니다.
그림 4 - 큐가 비울 때의 MDRR 상태 
대기열 2는 다음에 서비스됩니다. 해당 적자 카운터가 1500(0 + 1500 = 1500)으로 설정됩니다. 패킷 7~10이 전송되고, 500(1500 - (4*250) = 500으로 부족 카운터가 남습니다. 적자 카운터가 0보다 크므로 패킷 11도 전송됩니다.
패킷 11을 전송할 때, 대기열 2는 비어 있고, 그림 5와 같이 해당 부족 카운터가 0으로 설정됩니다.
그림 5 - 패킷 11이 전송될 때의 MDRR 상태 
Queue 0은 다음에 다시 서비스됩니다(대체 우선순위 모드이기 때문). 비어 있으므로, 다음으로 서비스 대기열 1을 제공하고 패킷 6을 전송합니다.
엔진 유형별 MDRR 지원
Cisco 12000 Series는 고유한 L3(Layer 3) 포워딩 엔진 아키텍처를 갖춘 5가지 라인 카드 모델을 지원합니다. MDRR에 대한 지원은 L3 엔진 유형 및 카드 유형에 따라 다릅니다. 예를 들어 Engine 0 ATM 라인 카드에는 MDRR 및 WRED를 지원하지 않습니다. show diag 명령을 사용하여 설치된 라인 카드의 L3 엔진 유형을 확인할 수 있습니다.
router#show diags | include (SLOT | Engine) !--- The regular expression is case-sensitive. ... SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps) SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps)
ToFab(Rx) 큐의 MDRR
"Legacy CoS Syntax" 또는 "Modular QoS Command Line Interface"를 사용하여 Cisco 12000 Series에서 MDRR을 구성할 수 있습니다. 이 문서의 뒷부분에서는 레거시 CoS 또는 모듈형 QoS로 MDRR을 구성하는 방법에 대해 설명합니다. MQC의 최신 구문을 지원하지 않으므로 레거시 CoS 구문으로 ToFab 큐를 구성해야 합니다. 자세한 내용은 표 2를 참조하십시오.
표 2 - ToFab(Rx) 큐의 MDRR 세부사항| 구현 위치 | MDRR에 전달 | 대체 PQ를 백업하려면 | ToFab 엄격한 PQ | ToFab WRED | |
|---|---|---|---|---|---|
| Eng0 | 소프트웨어 | 아니요** | 아니요** | 예 | 예 |
| 영어1 | - | 아니요 | 아니요 | 아니요 | 아니요 |
| 영어2 | 하드웨어 | 예 | 예 | 예 | 예 |
| 영어3 | 하드웨어 | 아니요 | 예 | 예 | 예 |
| 영어4 | 하드웨어 | 예 | 예 | 예 | 예 |
| 영어4+ | 하드웨어 | 예 | 예 | 예 | 예 |
** MDRR은 ToFab(Rx) 방향의 엔진 0 LC에서 지원되지만, 대체 우선순위 모드가 아닌 엄격한 우선순위 모드에서만 지원됩니다. 남은 7개의 대기열은 평소와 같이 지원됩니다.
인바운드 인터페이스는 대상 LC당 별도의 가상 출력 대기열을 유지합니다. 이러한 큐의 구현 방법은 L3 엔진 유형에 따라 달라집니다.
-
엔진 0 - 인바운드 LC는 대상 슬롯당 8개의 큐를 유지합니다. 따라서 최대 대기열 수는 16x8 = 128입니다. 각 대기열은 별도로 구성할 수 있습니다.
-
Engines 2, 3, 4 및 4+ - 인바운드 LC는 대상 인터페이스당 8개의 대기열을 유지합니다. 대상 슬롯 16개 및 슬롯당 인터페이스 16개가 있는 최대 대기열 수는 16x16x8 = 2048입니다. 대상 슬롯의 모든 인터페이스는 동일한 매개변수를 사용해야 합니다.
FrFab(Tx) 큐의 MDRR
FrFab 대기열의 MDRR은 하드웨어 또는 소프트웨어에 구현되었든 일관되게 작동합니다. 모든 L3 엔진 유형은 각 아웃바운드 인터페이스에 대해 8개의 클래스 대기열을 지원합니다. 자세한 내용은 표 3을 참조하십시오.
표 3 - FrFab(Tx) 큐의 MDRR 세부사항| 구현 위치 | FrFab 대체 PQ | FrFab Strict PQ | FrFab WRED | |
|---|---|---|---|---|
| Eng0 | 소프트웨어1 | 아니요 | 예 | 예 |
| 영어1 | - | 아니요 | 아니요 | 아니요 |
| 영어2 | 하드웨어 | 예2 | 예 | 예 |
| 영어3 | 하드웨어 | 아니요 | 예 | 예 |
| 영어4 | 하드웨어 | 예 | 예 | 예 |
| 영어4+ | 하드웨어 | 예 | 예 | 예 |
1 Engine 0 LC의 FrFab 대기열에서 MDRR 지원은 다음 버전의 Cisco IOS 소프트웨어에 도입되었습니다.
-
Cisco IOS Software 릴리스 12.0(10)S - 4xOC3 및 1xOC12 POS, 4xOC3 및 1xCHOC12/STM4.
-
Cisco IOS Software 릴리스 12.0(15)S - 6xE3 및 12xE3.
-
Cisco IOS Software 릴리스 12.0(17)S - 2xCHOC3/STM1.
2 레거시 CoS 구문을 사용하여 FrFab 방향의 대체 MDRR을 구성해야 합니다.
참고: 3xGE LC는 ToFab 대기열에서 MDRR을 지원하며, Cisco IOS Software Release 12.0(15)S와 마찬가지로 FrFab 대기열에서 고정 양자 및 각 인터페이스에 대한 단일 CoS 대기열이라는 두 가지 제한 사항이 있습니다. 우선 순위 대기열은 구성할 수 있는 양자 및 엄격한 우선 순위 모드와 대체 우선 순위 모드를 모두 지원합니다. 세 인터페이스 모두 하나의 PQ를 공유합니다.
참고: Cisco 12000 Series LC에서 지원되는 QoS 기능에 대한 최신 정보는 Cisco 12000 Series 라우터 릴리스 정보를 참조하십시오.
WRED 개요
WRED(Weighted Random Early Detection)는 인터페이스 혼잡이 네트워크 처리량에 미치는 해로운 영향을 방지하기 위해 설계되었습니다.
그림 6 - WRED 패킷 삭제 확률 
WRED 매개변수에 대한 자세한 내용은 Cisco 12000 Series 라우터의 Weighted Random Early Detection을 참조하십시오. 최소, 최대 및 표시 확률 매개변수는 실제 RED(Random Early Detection) 곡선을 설명합니다. 가중 대기열 평균이 최소 임계값 미만이면 패킷이 삭제되지 않습니다. 가중 대기열 평균이 최대 대기열 임계값을 초과하면 평균이 최대 임계값 아래로 떨어질 때까지 모든 패킷이 삭제됩니다. 평균이 최소 임계값과 최대 임계값 사이에 있을 경우, 패킷이 삭제될 확률을 최소 임계값에서 최대 임계값까지 직선으로 계산할 수 있습니다(삭제 확률을 0으로 함)(삭제 확률을 1/표시 확률 분모와 같음).
RED와 WRED의 차이점은 WRED는 인터페이스가 혼잡해지기 시작할 때 우선 순위가 낮은 트래픽을 선택적으로 폐기할 수 있으며, 다양한 CoS(Class of Service)에 대해 차별화된 성능 특성을 제공할 수 있다는 것입니다. 기본적으로 WRED는 각 가중치에 대해 다른 RED 프로파일을 사용합니다(IP 우선순위 - 8 프로파일). 중요한 패킷보다 덜 중요한 패킷을 더 공격적으로 삭제합니다.
WRED 매개변수를 조정하여 대기열 깊이를 관리하는 것은 복잡한 과제이며, 다음과 같은 여러 요소에 따라 달라집니다.
-
제공된 트래픽 로드 및 프로필
-
가용 용량에 대한 로드 비율입니다.
-
혼잡 발생 시 트래픽의 동작
이러한 요소는 네트워크마다 다르며, 그 다음에는 제공되는 서비스와 이러한 서비스를 사용하는 고객에 따라 달라집니다. 따라서 특정 고객 환경에 적용되는 권장 사항을 제공할 수 없습니다. 그러나 표 4에서는 일반적으로 링크의 대역폭을 기준으로 권장 값을 설명합니다. 이 경우, 서비스 클래스 간에 삭제 특성을 구별하지 않습니다.
표 4 - 링크의 대역폭을 기반으로 하는 권장 값| 대역폭 | 이론적 BW(kbps) | 물리적 BW1(kbps) | 최소 임계값 | 최대 임계값 |
|---|---|---|---|---|
| OC3 | 155000 | 149760 | 94 | 606 |
| OC12 | 622000 | 599040 | 375 | 2423 |
| OC48 | 2400000 | 239616 | 1498 | 9690 |
| OC192 | 10000000 | 9584640 | 5991 | 38759 |
1개의 물리적 SONET 속도
위의 임계값을 계산하는 데 몇 가지 제약 조건이 있습니다. 예를 들어, 평균 대기열 깊이를 최소화하면서 링크 사용률을 최대화하려면 최대 및 최소 사이의 차이는 2의 전력이어야 합니다(하드웨어 제한 때문에). 환경 및 시뮬레이션을 기반으로, RED에서 제어하는 대기열의 최대 순간 깊이는 2MaxTh 미만입니다. 0C48 이상, MaxTh 1개 등 그러나 이러한 값의 정확한 결정은 이 문서의 범위를 벗어납니다.
참고: 하드웨어 대기열 샘플링이 대신 사용되므로 Engine 2 이상 라인 카드에서 지수 가중치 상수 값을 구성할 필요가 없습니다. 엔진 0 LC의 경우 다음 값을 구성할 수 있습니다.
-
ds3 - 9
-
oc3 - 10
-
oc12 - 12
참고: WRED는 엔진 1 LC에서 지원되지 않습니다.
다음 섹션에서는 레거시 CoS 구문과 최신 MQC 구문을 모두 사용하여 WRED를 구성할 수 있습니다.
구성에 레거시 CoS 구문 사용
Cisco 12000 Series 레거시 CoS(Class of Service) 구문은 cos-queue-group 템플릿을 사용하여 CoS 정의 집합을 정의합니다. 그런 다음 인바운드 또는 아웃바운드 인터페이스의 ToFab 및 FrFab 대기열에 템플릿을 각각 적용합니다.
1단계: cos-queue-group 정의
cos-queue-group 명령은 MDRR 및 WRED 매개변수의 명명된 템플릿을 생성합니다. CLI에서 사용 가능한 컨피그레이션 매개변수는 다음과 같습니다.
Router(config)#cos-queue-group oc12
Router(config-cos-que)#?
Static cos queue commands:
default Set a command to its defaults
dscp Set per DSCP parameters, Engine 3 only
exit Exit from COS queue group configuration mode
exponential-weighting-constant Set group's RED exponential weight constant.
(Not used by engine 0, 1 or 2 line cards)
no Negate a command or set its defaults
precedence Set per precedence parameters
queue Set individual queue parmeters
random-detect-label Set RED drop criteria
traffic-shape Enable Traffic Shaping on a COS queue group
MDRR을 사용하면 IP 우선 순위를 MDRR 대기열에 매핑하고 특별 낮은 레이턴시 대기열을 구성할 수 있습니다. 이에 대해 cos-queue-group 명령 아래의 precedence 매개변수를 사용할 수 있습니다.
precedence <0-7> queue [ <0-6> | low-latency]
특정 IP 우선 순위를 일반 MDRR 큐(큐 0~6)에 매핑하거나 우선순위 큐에 매핑할 수 있습니다. 위의 명령을 사용하면 여러 IP 우선순위를 동일한 대기열에 매핑할 수 있습니다.
참고: 낮은 레이턴시 대기열에는 우선순위 5를 사용하는 것이 좋습니다. 우선순위 6은 라우팅 업데이트에 사용됩니다.
각 MDRR 대기열에 상대적 가중치를 지정할 수 있습니다. 그룹의 대기열 중 하나가 우선순위 대기열로 정의됩니다. cos-queue-group 아래의 queue 명령을 사용하여 다음을 수행할 수 있습니다.
queue <0-6> <1-2048> queue low-latency [alternate-priority | strict-priority] <1-2048> !--- The weight option is not available with strict priority.
cos-queue-group 명령을 사용하여 WRED 매개변수를 정의합니다.
random-detect-label
다음은 oc12라는 cos-queue-group의 예입니다. 다음 세 가지 트래픽 클래스를 정의합니다. 큐 0, 1 및 짧은 대기 시간입니다. IP 우선순위 값 0 - 3을 대기열 0에, 우선순위 값 4, 6 및 7을 대기열 1에, 우선순위 5를 지연 시간이 짧은 대기열에 매핑합니다. 대기열 1에 더 많은 대역폭이 할당되었습니다.
| 컨피그레이션 예시 |
|---|
cos-queue-group oc12 !--- Creation of cos-queue-group called "oc12". precedence 0 queue 0 !--- Map precedence 0 to queue 0. precedence 0 random-detect-label 0 !--- Use RED profile 0 on queue 0. precedence 1 queue 0 precedence 1 random-detect-label 0 precedence 2 queue 0 precedence 2 random-detect-label 0 precedence 3 queue 0 precedence 3 random-detect-label 0 !--- Precedence 1, 2 and 3 also go into queue 0. precedence 4 queue 1 precedence 4 random-detect-label 1 precedence 6 queue 1 precedence 6 random-detect-label 1 precedence 7 queue 1 precedence 7 random-detect-label 1 precedence 5 queue low-latency !--- Map precedence 5 to special low latency queue. !--- We do not intend to drop any traffic from the LLQ. We have an SLA !--- that commits not to drop on this queue. You want to give it all !--- the bandwidth it requires. Random-detect-label 0 375 2423 1 !--- Minimum threshold 375 packets, maximum threshold 2423 packets. !--- Drop probability at maximum threshold is 1. random-detect-label 1 375 2423 1 queue 1 20 !--- Queue 1 gets MDRR weight of 20, thus gets more Bandwidth. queue low-latency strict-priority !--- Low latency queue runs in strict priority mode. |
2단계 - ToFab 대기열에 대한 슬롯 테이블-cos 생성
Cisco 12000 Series의 인바운드 인터페이스는 HEAD 차단을 방지하기 위해 대상 슬롯당 가상 출력 대기열을 유지합니다. attach 명령을 사용하여 라인 카드로 이동하여 execute-on show controller tofab queue 명령을 실행하거나 execute-on slot 0 show controllers tofab queue 명령을 직접 입력하여 이러한 가상 출력 대기열을 확인합니다. LC 콘솔에서 직접 캡처한 샘플 출력이 아래에 나와 있습니다. show controller frb의 출력을 읽는 방법 참조 | Cisco 12000 Series 인터넷 라우터의 tofab queue 명령.
LC-Slot1#show controllers tofab queues
Carve information for ToFab buffers
SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100
33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s)
max buffer data size 9248 bytes, min buffer data size 80 bytes
40606/40606 buffers specified/carved
33249088/33249088 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
5 non-IPC free queues:
20254/20254 (buffers specified/carved), 49.87%, 80 byte data size
1 17297 17296 20254 65535
12152/12152 (buffers specified/carved), 29.92%, 608 byte data size
2 20548 20547 12152 65535
6076/6076 (buffers specified/carved), 14.96%, 1568 byte data size
3 32507 38582 6076 65535
1215/1215 (buffers specified/carved), 2.99%, 4544 byte data size
4 38583 39797 1215 65535
809/809 (buffers specified/carved), 1.99%, 9248 byte data size
5 39798 40606 809 65535
IPC Queue:
100/100 (buffers specified/carved), 0.24%, 4112 byte data size
30 72 71 100 65535
Raw Queue:
31 0 17302 0 65535
ToFab Queues:
Dest
Slot
0 0 0 0 65535
1 0 0 0 65535
2 0 0 0 65535
3 0 0 0 65535
4 0 0 0 65535
5 0 17282 0 65535
6 0 0 0 65535
7 0 75 0 65535
8 0 0 0 65535
9 0 0 0 65535
10 0 0 0 65535
11 0 0 0 65535
12 0 0 0 65535
13 0 0 0 65535
14 0 0 0 65535
15 0 0 0 65535
Multicast 0 0 0 65535
LC-Slot1#
slot-table-cos 명령을 사용하여 명명된 cos-queue-group을 대상 가상 출력 대기열에 매핑합니다. 모든 출력 대기열에 대해 고유한 cos-queue-group 템플릿을 구성할 수 있습니다.
Router(config)#slot-table-cos table1 Router(config-slot-cos)#destination-slot ? <0-15> Destination slot number all Configure for all destination slots Router(config-slot-cos)#destination-slot 0 oc48 Router(config-slot-cos)#destination-slot 1 oc48 Router(config-slot-cos)#destination-slot 2 oc48 Router(config-slot-cos)#destination-slot 3 oc48 Router(config-slot-cos)#destination-slot 4 oc12 Router(config-slot-cos)#destination-slot 5 oc48 Router(config-slot-cos)#destination-slot 6 oc48 Router(config-slot-cos)#destination-slot 9 oc3 Router(config-slot-cos)#destination-slot 15 oc48
주: 위 구성에서는 oc48, oc12 및 oc3라는 세 개의 템플리트를 사용합니다. oc12라는 cos-queue-group의 구성은 1단계와 같습니다. 마찬가지로 oc3 및 oc48을 구성합니다. 대역폭과 응용 프로그램을 기반으로 한 인터페이스 집합에 고유한 템플리트를 적용하는 것이 좋습니다.
3단계 - 인바운드 인터페이스에 slot-table-cos 적용
rx-cos-slot 명령을 사용하여 slot-table-cos를 LC에 적용합니다.
Router(config)#rx-cos-slot 0 ? WORD Name of slot-table-cos Router(config)#rx-cos-slot 0 table1 Router(config)#rx-cos-slot 2 table1
4단계 - 아웃바운드 인터페이스에 cos-queue-group 적용
Cisco 12000 Series는 아웃바운드 인터페이스당 별도의 대기열을 유지합니다. 이러한 대기열을 보려면 라인 카드 CLI에 연결합니다. attach 명령을 사용한 다음 아래와 같이 show controller frb queue 명령을 실행합니다.
LC-Slot1#show controller frfab queue
========= Line Card (Slot 2) =======
Carve information for FrFab buffers
SDRAM size: 16777216 bytes, address: 20000000, carve base: 2002D100
16592640 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s)
max buffer data size 9248 bytes, min buffer data size 80 bytes
20052/20052 buffers specified/carved
16581552/16581552 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
5 non-IPC free queues:
9977/9977 (buffers specified/carved), 49.75%, 80 byte data size
1 101 10077 9977 65535
5986/5986 (buffers specified/carved), 29.85%, 608 byte data size
2 10078 16063 5986 65535
2993/2993 (buffers specified/carved), 14.92%, 1568 byte data size
3 16064 19056 2993 65535
598/598 (buffers specified/carved), 2.98%, 4544 byte data size
4 19057 19654 598 65535
398/398 (buffers specified/carved), 1.98%, 9248 byte data size
5 19655 20052 398 65535
IPC Queue:
100/100 (buffers specified/carved), 0.49%, 4112 byte data size
30 77 76 100 65535
Raw Queue:
31 0 82 0 65535
Interface Queues:
0 0 0 0 65535
1 0 0 0 65535
2 0 0 0 65535
3 0 0 0 65535
tx-cos 명령을 사용하여 cos-queue-group 템플릿을 인터페이스 대기열에 적용합니다. 여기에서와 같이 매개변수 세트를 인터페이스에 직접 적용합니다. 테이블이 필요하지 않습니다. 이 예에서 pos48은 매개변수 세트의 이름입니다.
Router(config)#interface POS 4/0 Router(config-if)#tx-cos ? WORD Name of cos-queue-group Router(config-if)#tx-cos pos48
show cos 명령을 사용하여 컨피그레이션을 확인합니다.
Router#show cos !--- Only some of the fields are visible if MDRR is configured on Inbound !--- or Outbound interfaces. Interface Queue cos Group Gi4/0 eng2-frfab !--- TX-cos has been applied. Rx Slot Slot Table 4 table1 !--- rx-cos-slot has been applied. Slot Table Name - table1 1 eng0-tofab 3 eng0-tofab !--- slot-table-cos has been defined. cos Queue Group - eng2-tofab !--- cos-queue-group has been defined. Prec Red Label [min, max, prob] Drr Queue [deficit] 0 0 [6000, 15000, 1/1] 0 [10] 1 1 [10000, 20000, 1/1] 1 [40] 2 1 [10000, 20000, 1/1] 1 [40] 3 1 [10000, 20000, 1/1] 0 [10] 4 2 [15000, 25000, 1/1] 2 [80] 5 2 [15000, 25000, 1/1] 2 [80] 6 no drop low latency 7 no drop low latency
참고: 레거시 CLI는 MPLS(Multiprotocol Label Switching) 트래픽에 대한 우선순위 구문도 사용합니다. 라우터는 MPLS 비트를 IP Type of Service(ToS) 비트로 취급하고 적절한 패킷을 올바른 대기열에 넣습니다. 이는 MQC의 경우에는 전혀 사실이 아닙니다. MPLS QoS는 이 문서의 범위를 벗어납니다.
구성에 모듈형 QoS CLI(MQC) 사용
Cisco의 MQC(Modular QoS CLI)의 목적은 Cisco IOS Software QoS(Quality of Service) 기능의 컨피그레이션을 간소화하기 위해 서로 다른 모든 QoS 기능을 논리적으로 연결하는 것입니다. 예를 들어, 분류는 큐잉, 폴리싱 및 셰이핑과 별도로 수행됩니다. 템플릿 기반의 QoS를 위한 단일 컨피그레이션 프레임워크를 제공합니다. 다음은 MQC 컨피그레이션에 대해 기억해야 할 몇 가지 사항입니다.
-
인터페이스에 쉽게 적용 및 제거할 수 있습니다.
-
쉽게 재사용할 수 있습니다(동일한 정책을 여러 인터페이스에 적용할 수 있음).
-
QoS를 위한 단일 컨피그레이션 프레임워크를 제공하므로 손쉽게 프로비저닝, 모니터링 및 문제를 해결할 수 있습니다.
-
더 높은 수준의 추상화를 제공합니다.
-
플랫폼 독립적입니다.
Cisco 12000 Series에서는 레거시 CoS(Class of Service) 구문 대신 MQC 명령을 사용할 수 있습니다.
Cisco 12000 Series에 대한 MQC 지원은 Cisco 7500 Series와 같은 다른 플랫폼에서 사용할 수 있는 동일한 QoS 기능 집합을 이제 Cisco 12000에서 사용할 수 있음을 의미하지는 않습니다. MQC는 명령이 공유 기능 또는 동작으로 이어지는 공통 구문을 제공합니다. 예를 들어, bandwidth 명령은 최소 대역폭 보장을 구현합니다. Cisco 12000 Series는 MDRR을 스케줄링 메커니즘으로 사용하여 대역폭 예약을 수행하는 반면 Cisco 7500 Series는 WFQ를 사용합니다. 주도자 알고리즘은 특정 플랫폼을 보완합니다.
중요한 것은 FrFab 대기열만 MQC를 통해 QoS 기능의 컨피그레이션을 지원합니다. ToFab 대기열은 가상 출력 대기열이며 실제 입력 대기열이 아니므로 MQC에서 지원하지 않습니다. 레거시 CoS 명령으로 구성해야 합니다.
표 5는 L3 엔진 유형별 MQC 지원을 나열합니다.
표 5 - L3 엔진 유형에 대한 MQC 지원| L3 엔진 유형 | 엔진 0 | 엔진 1 | 엔진 2 | 엔진 3 | 엔진 4 | 엔진 4+ |
|---|---|---|---|---|---|---|
| MQC 지원 | 예 | 아니요 | 예 | 예 | 예 | 예 |
| IOS 릴리스 | 12.0(15)S | - | 12.0(15)S1 | 12.0(21)S | 12.0(22)S | 12.0(22)S |
1 엔진 0 및 2개의 라인 카드(LC)에서 MQC를 지원하는 경우 다음과 같은 예외 사항을 기억하십시오.
-
2xCHOC3/STM1 - 12.0(17)S에 도입됨
-
1xOC48 DPT - 12.0(18)S에 도입됨
-
8xOC3 ATM - 12.0(22)S로 예정
MQC는 다음 3단계를 사용하여 QoS 정책을 생성합니다.
-
class-map 명령을 사용하여 하나 이상의 트래픽 클래스를 정의합니다.
-
policy-map 명령으로 QoS 정책을 생성하고 명명된 트래픽 클래스에 대역폭 또는 우선순위와 같은 QoS 작업을 할당합니다.
-
아웃바운드 인터페이스의 FrFab 대기열에 정책 맵을 연결하려면 service-policy 명령을 사용합니다.
정책을 모니터링하려면 show policy-map interface 명령을 사용합니다.
자세한 내용은 Modular Quality of Service Command Line Interface 개요를 참조하십시오.
1단계 - 클래스 맵 정의
class-map 명령은 트래픽 클래스를 정의하는 데 사용됩니다. 내부적으로 Cisco 12000 Series에서 class-map 명령은 라인 카드의 특정 CoS 대기열에 클래스를 할당합니다(자세한 내용은 4단계 참조).
class-map 명령은 "match-any"를 지원하며, 이 경우 match 문 중 하나와 일치하는 패킷을 클래스에 배치하고, "match-all"은 모든 문이 true인 경우에만 패킷을 이 클래스에 배치합니다. 다음 명령은 "Prec_5"라는 클래스를 만들고 IP 우선 순위가 5인 모든 패킷을 이 클래스에 분류합니다.
Router(config-cmap)#match ? access-group Access group any Any packets class-map Class map destination-address Destination address 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 protocol Protocol qos-group Qos-group source-address Source address Router(config-cmap)#match ip precedence 5
표 6에는 각 L3 엔진 유형에 대해 지원되는 일치 기준이 나와 있습니다.
표 6 - L3 엔진에 대해 지원되는 일치 기준| 엔진 0, 2 | 엔진 3 | 엔진 4 | 엔진 4+ | |
|---|---|---|---|---|
| ip 우선 순위 | 예 | 예 | 예 | 예 1 |
| 액세스 그룹 | 아니요 | 예 | 아니요 | 아니요 |
| mpls exp | 아니요 | 예 | 아니요 | 예(12.0.26S) |
| ip dscp | 아니요 | 예 | 아니요 | 예(12.0.26S) |
| qos-group | 아니요 | 예 | 아니요 | 아니요 |
| 입력 인터페이스 POS 일치 x/y | 아니요 | 예(수신 정책에만 해당) | 아니요 | 아니요 |
12.0.26S 이후 인그레스/이그레스 1개
2단계 - 정책 맵 생성
policy-map 명령은 하나 이상의 정의된 클래스에 패킷 처리 정책 또는 작업을 할당하는 데 사용됩니다. 예를 들어, 대역폭 예약을 할당하거나 임의 삭제 프로필을 적용할 경우
Cisco 12000 Series는 L3 엔진의 고속 아키텍처를 기반으로 MQC 기능의 하위 집합을 지원합니다. 표 7에는 지원되는 명령이 나와 있습니다.
표 7 - 지원되는 명령| 명령을 사용합니다 | 설명 |
|---|---|
| 대역폭 | 혼잡 기간 동안 최소 대역폭 보장을 제공합니다. 링크 속도의 백분율 또는 절대 값으로 지정됩니다. 클래스가 예약된 kbps와 같은 대역폭을 사용하지 않거나 필요로 하는 경우 다른 대역폭 클래스에서 사용 가능한 대역폭을 사용할 수 있습니다. |
| 경찰, 모양 | 클래스가 전송할 수 있는 트래픽의 양을 제한합니다. 이러한 명령은 함수에서 약간 다릅니다. police 명령은 구성된 대역폭을 초과하는 트래픽을 식별하고 이를 삭제하거나 비웁니다. shape 명령은 초과 트래픽을 버퍼링하고 일정한 속도로 전송하도록 예약하지만 삭제 또는 언급하지는 않습니다. |
| 큐 제한 | 지정된 트래픽 클래스에 고정 대기열 길이를 할당합니다. 대기열에 보관할 수 있는 패킷 수로 지정할 수 있습니다. |
| 우선 순위 | 대기열을 짧은 대기 시간 대기열로 식별합니다. MQC는 PQ에 대해서만 엄격한 모드를 지원합니다. 대체 모드는 MQC를 통해 지원되지 않습니다. strict priority 모드를 활성화하려면 percentage 값 없이 priority 명령을 사용합니다. 참고: Cisco 1200 Series에서 priority 명령을 구현하면 Cisco IOS 소프트웨어를 실행하는 다른 라우터에서 구현되는 것과 다릅니다. 이 플랫폼에서 우선순위 트래픽은 혼잡 기간 동안 구성된 kbps 값으로 제한되지 않습니다. 따라서 police 명령을 구성하여 우선 순위 클래스가 사용할 수 있는 대역폭을 제한하고 다른 클래스에 적합한 대역폭을 확보해야 합니다. 현재 police 명령은 Engine 3 라인 카드에서만 지원됩니다. 다른 엔진 라인 카드에서는 우선순위 클래스를 구성할 때 class-default만 허용됩니다. |
| 임의 탐지 | WRED 프로필을 할당합니다. IP 우선순위 값당 기본이 아닌 WRED 값을 구성하려면 random-detect precedence 명령을 사용합니다. |
Engine 3 LC에서 MQC(Modular QoS CLI)로 FrFab 큐를 구성해야 합니다. 레거시 CLI(Command Line Interface)는 지원되지 않습니다.
bandwidth 명령을 구성할 때 Engine 0 및 2 LC는 6개의 대역폭 클래스만 지원합니다. 레이턴시가 낮은 서비스에 7번째 클래스를 사용할 수 있으며, 클래스 기본값인 8번째 클래스는 매칭되지 않는 모든 트래픽에 사용됩니다. 따라서 총 8개의 대기열이 있습니다. class-default는 우선 순위 클래스로 사용되지 않습니다.
Engine 3 LC에서 bandwidth percent 명령은 kbps 값으로 변환되며, 이는 기본 링크 속도에 따라 달라지며, 대기열에 직접 구성됩니다. 이 최소 대역폭 보증의 정밀도는 64kbps입니다.
bandwidth 명령을 사용하여 양자 값으로 변환할 수는 없지만 모든 대기열에는 양자량이 있습니다. Engine 3 LC에서는 인터페이스의 MTU(Maximum Transmission Unit)를 기반으로 내부 적으로 양자 값이 설정되고 모든 대기열에 대해 동일하게 설정됩니다. 이 양자 값을 직접 또는 간접적으로 수정하는 MQC CLI 메커니즘은 없습니다. 양자 값은 인터페이스 MTU보다 크거나 같아야 합니다. 내부적으로 양자 값은 512바이트의 단위입니다. 따라서 MTU가 4470바이트인 경우 MTU의 최소 양자 값은 9여야 합니다.
엔진 3 LC의 MDRR
이 섹션에서는 엔진 3 LC에 WRED 및 MDRR을 구현하기 위한 컨피그레이션 정보를 제공합니다.
-
CLI에 구성된 MDRR 대역폭은 L2에 해당하는 양으로 변환됩니다(예: L1 오버헤드가 제거됨). 그 양은 다음 64kbps까지 반올림되고 하드웨어로 프로그래밍됩니다.
-
한 클래스에 대해 세 가지 다른 WRED 프로파일이 지원됩니다.
-
WRED(최대 임계값 - 최소 임계값)는 가장 근접한 전력 2에 근접한 것입니다. 그런 다음 최대 임계값이 변경되지 않고 최소 임계값이 자동으로 조정됩니다.
-
표시 확률 값 1이 지원됩니다.
-
지수 가중치 상수 구성은 지원되지 않습니다.
-
IP 우선 순위, MPLS EXP 비트 및 DSCP 값이 지원됩니다.
참고: Tetra(4GE-SFP-LC= ) 또는 CHOC12/DS1-IR-SC= 동상 라인 카드에는 기본적으로 4개의 대기열이 할당됩니다. 4개의 대기열은 다음과 같이 구성됩니다.
-
LLQ(Priority Queue) 클래스 1개
-
기본 대기열 클래스 1개
-
일반 비우선순위 클래스 2개
이 네 개 이상의 클래스(1 HPQ, 2 LPQ 및 class-default)가 포함된 서비스 정책을 인터페이스에 적용할 경우 다음 오류가 보고됩니다.
라우터(config-if)#service-policy 출력 mdrr-policy
% 대기 리소스가 부족하여 요청을 충족할 수 없습니다.
12.0(26)S부터 4GE-SFP-LC= Tetra 라인 카드에 대한 명령이 추가되었으며 4개가 아닌 8개의 대기열/VLAN을 구성할 수 있습니다. 8개의 대기열은 다음과 같이 구성됩니다.
-
LLQ 1개
-
하나의 클래스 기본 대기열
-
6개의 일반 대기열
이 명령을 사용하려면 라인 카드의 마이크로코드 재로드가 필요하며, 1022 대신 508개의 VLAN만 구성할 수 있습니다. 명령 구문은 다음과 같습니다.
[no] hw module slot <slot#> qos 인터페이스 대기열 8
예를 들면 다음과 같습니다.
라우터(config)#hw-module slot 2 qos 인터페이스 대기열 8
경고: 이 명령을 적용하려면 라인 카드를 다시 로드하십시오.
라우터(config)#microcode 다시 로드 2
이 명령은 12.0(32)S의 CHOC12/DS1-IR-SC= Cronze linecard에 사용할 수 있습니다.
예 #1 - bandwidth percent 명령
이 예에서는 클래스 Prec_4 트래픽에 사용 가능한 대역폭의 20%, 클래스 Prec_3 트래픽의 트래픽에 30%를 할당합니다. 나머지 50%는 class-default 클래스로 유지됩니다.
또한 WRED를 모든 데이터 클래스에서 삭제 메커니즘으로 구성합니다.
| 예 #1 - 대역폭 퍼센트 |
|---|
policy-map GSR_EXAMPLE class Prec_4 bandwidth percent 20 random-detect random-detect precedence 4 1498 packets 9690 packets 1 !--- All data classes should have WRED configured. class Prec_3 bandwidth percent 30 random-detect random-detect precedence 3 1498 packets 9690 packets 1 class class-default !--- Class-default uses any leftover bandwidth. random-detect random-detect precedence 2 1498 packets 9690 packets 1 random-detect precedence 1 1498 packets 9690 packets 1 random-detect precedence 0 1498 packets 9690 packets 1 |
예 #2 - 대역폭 {kbps} 명령
이 예에서는 bandwidth 명령을 백분율 대신 절대 kbps 값으로 적용하는 방법을 보여 줍니다.
| 예 #2 - 대역폭 {kbps} |
|---|
policy-map GSR_EXAMPLE class Prec_4 bandwidth 40000 !--- Configures a minimum bandwidth guarantee of 40000 kbps or 40 Mbps in !--- times of congestion. Random-detect random-detect precedence 4 1498 packets 9690 packets 1 class Prec_3 bandwidth 80000 !--- Configures a minimum bandwidth guarantee of 80000 kbps or 80 Mbps in !--- times of congestion. Random-detect random-detect precedence 3 1498 packets 9690 packets 1 class class-default !--- Any remaining bandwidth is given to class-default. Random-detect random-detect precedence 2 1498 packets 9690 packets 1 random-detect precedence 1 1498 packets 9690 packets 1 random-detect precedence 0 1498 packets 9690 packets 1 |
예 #3 - priority 명령
이 예는 Cisco 12000 Series 라우터를 MPLS PE(provider edge) 라우터로 사용하고 PE 라우터와 CE(customer edge) 라우터 간의 링크에서 QoS 서비스 정책을 구성해야 하는 통신 사업자를 위해 고안되었습니다. IP 우선 순위 5 패킷을 우선 순위 대기열에 배치하고 해당 대기열의 출력을 64Mbps로 제한합니다. 그런 다음 나머지 대역폭의 일부를 대역폭 클래스에 할당합니다.
우선 순위가 아닌 모든 클래스 대기열은 WRED를 삭제 정책으로 사용하도록 random-detect 명령으로 구성됩니다. 모든 대역폭 클래스와 class-default는 명시적으로 WRED를 구성해야 합니다.
| 예 #3 - 우선순위 |
|---|
policy-map foo
class Prec_5
police 64000000 conform-action transmit exceed-action drop
!--- The police command is supported on Engine 3 line cards.
priority
class Prec_4
bandwidth percent 30
random-detect
random-detect precedence 4 1498 packets 9690 packets 1
class Prec_3
bandwidth percent 10
random-detect
random-detect precedence 3 1498 packets 9690 packets 1
class Prec_2
bandwidth percent 10
random-detect
random-detect precedence 2 1498 packets 9690 packets 1
class Prec_1
bandwidth percent 10
random-detect
random-detect precedence 1 1498 packets 9690 packets 1
class Prec_0
bandwidth percent 25
random-detect
random-detect precedence 0 1498 packets 9690 packets 1
class class-default
random-detect
random-detect precedence 6 1498 packets 9690 packets 1
random-detect precedence 7 1498 packets 9690 packets 1
|
3단계 - 아웃바운드 인터페이스 대기열에 정책 맵 할당
위에서 언급한 대로 MQC는 아웃바운드 인터페이스의 FrFab 대기열에서만 작동합니다. 정의된 정책 맵을 적용하려면 다음과 같이 service-policy output 명령을 사용합니다.
Router(config)#interface POS 0/0 Router(config-if)#service-policy ? history Keep history of QoS metrics input Assign policy-map to the input of an interface output Assign policy-map to the output of an interface Router(config-if)#service-policy output ? WORD policy-map name Router(config-if)#service-policy output GSR_EXAMPLE
4단계 - 서비스 정책 모니터링 및 확인
정책의 애플리케이션을 보려면 show policy-map interface 명령을 사용합니다. show policy-map interface 명령은 다음을 표시합니다.
-
구성된 대역폭 및 우선 순위 클래스 및 일치 기준
-
모든 WRED 프로파일
-
모양과 경찰 매개변수
-
트래픽 계정 관리 및 속도.
-
특정 클래스가 매핑된 내부 CoS 대기열입니다. 이러한 대기열은 show controller frb queue 명령의 출력에 사용되는 동일한 인덱스에서 참조됩니다.
다음은 전체 컨피그레이션과 정책을 모니터링하기 위한 show 명령의 예입니다.
| 구성 완료 |
|---|
class-map match-all class1
match ip precedence 1
class-map match-all class2
match ip precedence 2
!--- Step 1 - Configure traffic classes.
!
policy-map policy1e
Class class1
bandwidth percent 10
random-detect
random-detect precedence 1 375 packets 2423 packets 1
Class class2
bandwidth percent 20
random-detect
!--- Step 2 - Configure a policy-map.
!
interface POS6/0
ip address 12.1.1.1 255.255.255.0
no ip directed-broadcast
no keepalive
service-policy output policy1e
!--- Step 3- Attach policy-map to the interface.
|
구성된 모든 클래스와 함께 인터페이스에 구성된 정책을 보려면 show policy-map interface 명령을 사용합니다. 다음은 명령의 출력입니다.
Router#show policy-map int pos6/0
POS6/0
Service-policy output: policy1e (1071)
Class-map: class1 (match-all) (1072/3)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 1 (1073)
Class of service queue: 1
Tx Queue (DRR configured)
bandwidth percent Weight
10 1
Tx Random-detect:
Exp-weight-constant: 1 (1/2)
Precedence RED Label Min Max Mark
1 1 375 2423 1
Class-map: class2 (match-all) (1076/2)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 2 (1077)
Class of service queue: 2
Tx Queue (DRR configured)
bandwidth percent Weight
20 9
Tx Random-detect:
Exp-weight-constant: 1 (1/2)
Precedence RED Label Min Max Mark
Class-map: class-default (match-any) (1080/0)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any (1081)
0 packets, 0 bytes
5 minute rate 0 bps
혼잡 관리 및 회피 모니터링 명령
이 섹션에는 혼잡 관리 및 회피 정책을 모니터링하는 데 사용할 수 있는 명령이 나열되어 있습니다.
표 8에는 인그레스 및 이그레스 라인 카드에 대한 관련 명령이 나와 있습니다.
표 8 - 라인 카드에 대한 명령| 인그레스 라인 카드 | 이그레스 라인 카드 |
|---|---|
|
|
이러한 명령에 대해서는 이 섹션에서 설명합니다.
show interfaces 명령
이 명령을 사용하기 전에 올바른 "대기 전략"을 확인하십시오. 출력에 First In, First Out(FIFO)이 표시되면 service-policy 명령이 실행 중인 컨피그레이션에 나타나는지 확인합니다(MQC를 사용하여 MDRR을 구성한 경우).
이 인터페이스의 발신 트래픽에 대해 발생한 총 WRED FrFab 삭제 수를 나타내는 출력 삭제 수를 모니터링합니다. show interfaces 명령 출력의 출력 삭제 수는 show interfaces <number> random 명령 출력의 출력 삭제 수와 같거나 그보다 커야 합니다.
참고: Cisco 12000 Series 라우터에서 WRED 드롭이 업데이트된 후 인터페이스 출력이 업데이트됩니다. 도구를 사용하여 두 drop 카운터를 모두 쿼리하면 인터페이스 드랍이 아직 업데이트되지 않을 가능성이 낮습니다.
Router#show interfaces POS 4/0
POS4/0 is up, line protocol is up
Hardware is Packet over SONET
Description: link to c12f9-1
Internet address is 10.10.105.53/30
MTU 4470 bytes, BW 622000 Kbit, DLY 100 usec, rely 255/255, load 82/255
Encapsulation PPP, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
LCP Open
Open: IPCP, CDPCP, OSICP, TAGCP
Last input 00:00:02, output 00:00:05, output hang never
Last clearing of "show interface" counters 00:04:54
Queueing strategy: random early detection (WRED)
Output queue 0/40, 38753019 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 200656000 bits/sec, 16661 packets/sec
135 packets input, 6136 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 parity
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
7435402 packets output, 11182627523 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
show interfaces {number} random 명령
이 명령을 사용할 때 다음을 수행해야 합니다.
-
올바른 cos-queue-group 템플릿이 이 인터페이스에 적용되었는지 확인합니다.
-
MDRR 가중치를 확인합니다. 각 MDRR 대기열에 대해 대기열 길이 및 도달한 최대값(패킷)에 대한 가중 평균을 확인할 수 있습니다. 값은 가중 평균으로 계산되며 지금까지 도달했던 실제 최대 대기열 깊이를 반영하지 않아도 됩니다.
-
WRED 최소 및 최대 임계값을 확인합니다.
-
각 RED 레이블에 대한 임의 삭제 및 임계값 삭제 수를 확인합니다("To Fabric" 삭제는 모든 라인 카드의 이 레이블에 대한 총 삭제 양을 나타냅니다).
-
"TX-queue-limit drops" 카운터는 WRED를 지원하지 않는 엔진 1 LC에서만 사용됩니다. Engine 1 카드를 사용하면 TX-queue-limit interface 명령을 사용하여 MDRR 큐의 제한을 설정할 수 있습니다. WRED가 지원되는 경우 WRED 임계값은 MDRR 큐의 깊이를 결정합니다.
Router#show interfaces POS 4/0 random
POS4/0
cos-queue-group: oc12
RED Drop Counts
TX Link
To Fabric
RED Label Random Threshold Random Threshold
0 29065142 73492 9614385 0
1 0 0 0 0
2 0 0 0 0
3 0 0 0 0
4 0 0 0 0
5 0 0 0 0
6 0 0 0 0
TX-queue-limit drops: 0
Queue Lengths
TX Queue (DRR configured) oc12
Queue Average High Water Mark Weight
0 0.000 2278.843 1
1 0.000 0.000 73
2 0.000 0.000 10
3 0.000 0.000 10
4 0.000 0.000 10
5 0.000 0.000 10
6 0.000 0.000 10
Low latency 0.000 0.000 10
TX RED config
Precedence 0: 375 min threshold, 2423 max threshold, 1/1 mark weight
Precedence 1: not configured for drop
Precedence 2: not configured for drop
Precedence 3: not configured for drop
Precedence 4: 375 min threshold, 2423 max threshold, 1/1 mark weight
Precedence 5: not configured for drop
Precedence 6: 375 min threshold, 2423 max threshold, 1/1 mark weight
Precedence 7: not configured for drop weight 1/2
exec slot (y) show controller fab queue {port} 명령
이 명령은 지정된 슬롯의 지정된 포트에 대한 즉각적인 대기열 깊이를 표시합니다. 이 섹션의 샘플 출력에는 인터페이스 POS 4/1의 MDRR 대기열이 표시됩니다. 1964개 패킷 중 MDRR 대기열 1에 대한 대기열 깊이가 표시됩니다. 가중치는 이 큐에서 사용할 수 있는 바이트 수입니다. 이 가중치는 이 대기열에 지정할 대역폭의 비율을 결정합니다. 적자는 DRR 알고리즘에 여전히 몇 개의 패킷을 제공해야 하는지 알려주는 값입니다. LLQ(DRR 대기열 7)에 대기열에 있는 패킷이 없음을 확인할 수 있습니다.
Router#execute-on slot 4 show controllers frfab queue 1 ========= Line Card (Slot 4) ======= FrFab Queue Interface 1 DRR# Head Tail Length Average Weight Deficit 0 95330 40924 0 0.000 4608 0 1 211447 233337 1964 1940.156 41472 35036 2 0 0 0 0.000 9216 0 3 0 0 0 0.000 9216 0 4 0 0 0 0.000 9216 0 5 0 0 0 0.000 9216 0 6 0 0 0 0.000 9216 0 7 0 0 0 0.000 9216 0
이 명령은 특히 이그레스 라인 카드의 우선순위 대기열의 깊이를 모니터링하는 데 사용됩니다. 패킷이 이 이 LLQ에서 대기하기 시작하면 일부 VOIP(Voice over IP) 트래픽을 다른 이그레스 라인 카드로 전환해야 함을 나타내는 것이 좋습니다. 훌륭한 설계에서는 길이가 항상 0 또는 1이어야 합니다. 실제 네트워크에서는 음성 데이터에서도 트래픽 폭증을 경험하게 됩니다. 총 음성 로드가 짧은 시간 동안 이그레스 대역폭의 100%를 초과할 경우 추가 지연이 더 심각해집니다. 라우터는 허용된 트래픽보다 더 많은 트래픽을 와이어에 배치할 수 없으므로 음성 트래픽은 자체 우선순위 대기열에서 대기됩니다. 이렇게 하면 음성 트래픽 자체의 버스트로부터 유입되는 음성 레이턴시와 음성 지터가 생성됩니다.
Router#execute-on slot 4 show controllers frfab queue 0 ========= Line Card (Slot 4) ======= FrFab Queue Interface 0 DRR# Head Tail Length Average Weight Deficit 0 181008 53494 2487 2282.937 4608 249 1 16887 45447 7 0.000 41472 0 2 0 0 0 0.000 9216 0 3 0 0 0 0.000 9216 0 4 0 0 0 0.000 9216 0 5 0 0 0 0.000 9216 0 6 0 0 0 0.000 9216 0 7 107818 142207 93 0.000 9216 -183600
큐 7은 LLQ이며, 이 LLQ에 있는 패킷 수를 나타냅니다.
exec slot (y) show controller ffab QM stat 명령
LC의 패킷 메모리가 전체 용량에 도달하기 시작한다고 의심되는 경우 이 명령을 사용합니다. "no mem drop" 카운터의 값이 증가하면 WRED가 구성되지 않았거나 WRED 임계값이 너무 높게 설정되었음을 나타냅니다. 이 카운터는 정상적인 조건에서 증가해서는 안 됩니다. 자세한 내용은 Cisco 12000 Series 인터넷 라우터의 Troubleshooting Ignored Packets and No Memory Drops를 참조하십시오.
Router#execute-on slot 4 show controllers frfab QM stat ========= Line Card (Slot 4) ======= 68142538 no mem drop, 0 soft drop, 0 bump count 0 rawq drops, 8314999254 global red drops, 515761905 global force drops 0 no memory (ns), 0 no memory hwm (Ns) no free queue 0 0 1968 88 0 0 0 0 0 0 0 0 0 0 0 0 0 multicast drops TX Counts Interface 0 859672328848 TX bytes, 3908130535 TX pkts, 75431 kbps, 6269 pps Interface 1 86967615809 TX bytes, 57881504 TX pkts, 104480 kbps, 8683 PPS Interface 2 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
인바운드 혼잡 관리 모니터링
이 섹션에서는 인바운드 혼잡 관리를 모니터링하는 데 사용되는 명령에 대해 설명합니다.
show interfaces 명령
이 명령을 실행하기 전에 무시된 카운터의 값이 증가하는지 확인하십시오. ToFab 측의 메모리가 부족하거나 라인 카드에서 패킷을 충분히 빠르게 허용하지 않는 경우 무시된 패킷이 표시됩니다. 자세한 내용은 Cisco 12000 Series 인터넷 라우터의 입력 삭제 문제 해결을 참조하십시오.
Router#show interfaces POS 14/0
POS14/0 is up, line protocol is up
Hardware is Packet over SONET
Description: agilent 3b for QOS tests
Internet address is 10.10.105.138/30
MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 234/255, load 1/255
Encapsulation HDLC, crc 32, loopback not set
Keepalive not set
Scramble disabled
Last input never, output 00:00:03, output hang never
Last clearing of "show interface" counters 00:34:09
Queueing strategy: random early detection (WRED)
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 2231000 bits/sec, 4149 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
563509152 packets input, 38318622336 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 parity
166568973 input errors, 0 CRC, 0 frame, 0 overrun, 166568973 ignored, 0 abort
35 packets output, 12460 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
exec 슬롯(x) show controller tofab queue 명령
exec slot <x> show controller tofab queue 명령의 샘플 출력은 슬롯 3의 이그레스 라인 카드에 혼잡이 없을 때 캡처되었습니다.
Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers
!--- Output omitted.
ToFab Queues:
Dest
Slot
0 0 0 0 9690
1 0 0 0 9690
2 0 0 0 9690
3 11419 16812 0 9690
4 0 0 0 2423
5 0 0 0 9690
6 0 0 0 9690
7 0 0 0 262143
8 0 0 0 262143
9 0 0 0 606
10 0 0 0 262143
11 0 0 0 262143
12 0 0 0 262143
13 0 0 0 262143
14 0 0 0 262143
15 0 0 0 9690
Multicast 0 0 0 262143
슬롯 3에 혼잡이 있을 때 다음 출력이 캡처되었습니다.
Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers
!--- Output omitted.
ToFab Queues:
Dest
Slot
0 0 0 0 9690
1 0 0 0 9690
2 0 0 0 9690
3 123689 14003 1842 9690
4 0 0 0 2423
5 0 0 0 9690
6 0 0 0 9690
7 0 0 0 262143
8 0 0 0 262143
9 0 0 0 606
10 0 0 0 262143
11 0 0 0 262143
12 0 0 0 262143
13 0 0 0 262143
14 0 0 0 262143
15 0 0 0 9690
Multicast 0 0 0 262143
exec slot (x) show controller tofab queue (slot) (port) 명령
이 명령을 사용하여 ToFab 쪽에서 사용되는 메모리 양을 확인합니다. 특히 '#Qelem' 열의 숫자를 확인합니다. 다음 사항에 유의하십시오.
-
메모리를 사용하지 않으면 값이 가장 높습니다.
-
패킷이 버퍼링되면 "#Qelem" 열의 값이 감소합니다.
-
"#Qelem" 열이 0에 도달하면 모든 조각된 버퍼가 사용됩니다. Engine 2 LC에서 작은 패킷은 더 큰 패킷에서 버퍼 공간을 빌릴 수 있습니다.
또한 이 명령을 사용하여 가상 출력 대기열에서 대기 중인 패킷의 수를 확인할 수 있습니다. 이 예에서는 슬롯 4, 포트 1(POS 4/1)에 대해 이러한 대기열의 즉각적인 패킷 수를 슬롯 14에서 확인하는 방법을 보여줍니다. MDRR 큐 1에서 대기열에 있는 830개의 패킷이 표시됩니다.
Router# execute-on slot 14 show controllers tofab queue 4 1 ========= Line Card (Slot 14) ======= ToFab Queue Slot 4 Int 1 DRR# Head Tail Length Average Weight Deficit 0 0 0 0 0.000 4608 0 1 203005 234676 830 781.093 41472 37248 2 0 0 0 0.000 9216 0 3 0 0 0 0.000 9216 0 4 0 0 0 0.000 9216 0 5 0 0 0 0.000 9216 0 6 0 0 0 0.000 9216 0 7 0 0 0 0.000 9216 0
exec slot (x) show controller tofab QM stat 명령
이 명령을 사용하여 라인 카드당 ToFab 삭제 수를 확인합니다. 또한 증가하는 "no memory drop" 카운터도 확인합니다. 이 카운터는 ToFab 쪽에서 CoS가 구성되지 않은 경우 증가합니다.
Router#execute-on slot 13 show controllers tofab QM stat ========= Line Card (Slot 13) ======= 0 no mem drop, 0 soft drop, 0 bump count 0 rawq drops, 1956216536 global red drops, 6804252 global force drops 0 no memory (Ns), 0 no memory hwm (Ns) no free queue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Q status errors 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
사례 연구
이 사례 연구에서는 통신 사업자 환경의 네트워크 코어에 대한 일반적인 정책을 구성하는 방법을 보여줍니다. 대기열 명령을 적용하고 활성 대기열 관리에 MDRR/WRED를 사용할 수 있습니다. 에지 라우터의 QoS 정책은 일반적으로 트래픽 표시, 조정 등을 사용하여 코어의 라우터가 IP 우선 순위 또는 DSCP(DiffServ Code Point) 값을 기반으로 트래픽을 클래스로 정렬할 수 있도록 합니다. 이 사례 연구에서는 Cisco IOS 소프트웨어 QoS 기능을 사용하여 동일한 IP 백본의 엄격한 SLA(Service Level Agreement) 및 음성, 비디오 및 데이터 서비스에 대한 다양한 서비스 수준을 충족합니다.
이러한 접근 방식에서는 통신 사업자가 세 가지 트래픽 클래스를 구현했습니다. 가장 중요한 것은 LLQ 또는 Low Latency Queuing 클래스입니다. 음성 및 비디오의 등급입니다. 이 클래스는 최소 지연 및 지터를 경험해야 하며, 이 클래스의 대역폭이 링크 대역폭을 초과하지 않는 한 패킷 손실 또는 순서가 변경된 패킷을 경험해서는 안 됩니다. 이 클래스는 DiffServ 아키텍처에서 EF PHB(Shipped Forwarding Per-Hop Behavior) 트래픽이라고 합니다. ISP(Internet Service Provider)는 이 클래스가 링크 대역폭의 평균 로드 시 30%를 초과하지 않도록 네트워크를 설계했습니다. 나머지 두 클래스는 비즈니스클래스와 최선의 노력 등급입니다.
설계에서는 비즈니스 클래스가 항상 나머지 대역폭의 90%를 차지하고 최상의 작업 클래스는 10%를 얻을 수 있도록 라우터를 구성했습니다. 이 두 클래스는 시간에 민감한 트래픽을 덜 가지며 트래픽 손실, 더 높은 지연 및 지터를 경험할 수 있습니다. 설계에서는 엔진 2 라인 카드에 중점을 둡니다. 1xOC48 rev B, 4xOC12 rev B 및 8xOC3 라인 카드
Rev B 라인 카드는 레이턴시가 거의 발생하지 않는 수정된 ASIC 및 하드웨어 아키텍처 때문에 VoIP 트래픽을 전달하는 데 가장 적합합니다. 수정된 ASIC를 사용할 경우, 전송 FIFO 큐의 크기는 라인 카드 드라이버에 의해 카드의 최대 MTU의 약 2배로 조정됩니다. 부품 번호(예: OC48E/POS-SR-SC-B=)에 추가된 "-B"를 찾습니다.
참고: Engine 0 라인 카드에서 튜닝할 수 있는 FrFab 대기열과 tx-queue-limit 인터페이스 명령을 혼동하지 마십시오.
표 9에는 각 클래스에 대한 일치 기준이 나와 있습니다.
표 9 - 각 클래스에 대한 일치 기준| 클래스 이름 | 일치 기준 |
|---|---|
| 우선순위 대기열 - 음성 트래픽 | 우선 순위 5 |
| 비즈니스 대기열 | 우선 순위 4 |
| 최선형 대기열 | 우선 순위 0 |
OC48 라인 카드는 ToFab 대기열에 많은 수의 패킷을 대기열에 넣을 수 있습니다. 따라서 이그레스 인터페이스가 OC48과 같은 고속 인터페이스인 경우 ToFab 대기열에 MDRR/WRED를 구성하는 것이 중요합니다. 패브릭은 이론상 최대 3Gbps(1500바이트 패킷)의 속도로 트래픽을 수신 라인 카드로 전환할 수만 있습니다. 전송된 총 트래픽 양이 스위칭 패브릭에서 수신 카드로 전송할 수 있는 트래픽 양보다 크면 ToFab 대기열에서 많은 패킷이 대기됩니다.
Interface POS3/0 description OC48 egress interface ip address 10.10.105.53 255.255.255.252 no ip directed-broadcast ip router Isis encapsulation ppp mpls traffic-eng tunnels tag-switching ip no peer neighbor-route crc 32 clock source internal POS framing sdh POS scramble-atm POS threshold sf-ber 4 POS flag s1s0 2 TX-cos oc48 Isis metric 2 level-1 Isis metric 2 level-2 ip rsvp bandwidth 2400000 2400000 ! interface POS4/1 description OC12 egress interface ip address 10.10.105.121 255.255.255.252 no ip directed-broadcast ip router Isis encapsulation ppp mpls traffic-eng tunnels no peer neighbor-route crc 32 clock source internal POS framing sdh POS scramble-ATM POS threshold sf-ber 4 POS flag s1s0 2 TX-cos oc12 Isis metric 2 level-1 Isis metric 2 level-2 ip RSVP bandwidth 600000 60000 ! interface POS9/2 description OC3 egress interface ip address 10.10.105.57 255.255.255.252 no ip directed-broadcast ip router Isis crc 16 POS framing sdh POS scramble-ATM POS flag s1s0 2 TX-cos oc3 Isis metric 200 level-1 Isis metric 2 level-2 ! interface POS13/0 description agilent 3a for QOS tests - ingress interface. ip address 10.10.105.130 255.255.255.252 no ip directed-broadcast no ip route-cache cef no ip route-cache no ip mroute-cache no keepalive crc 32 POS threshold sf-ber 4 TX-cos oc48 ! interface POS14/0 description agilent 3b for QOS tests - ingress interface. ip address 10.10.105.138 255.255.255.252 no ip directed-broadcast no keepalive crc 32 POS threshold sf-ber 4 TX-cos oc48 ! interface POS15/0 description agilent 4A for QOS tests - ingress interface ip address 10.10.105.134 255.255.255.252 no ip directed-broadcast no ip mroute-cache no keepalive crc 32 POS threshold sf-ber 4 TX-CoS oc48 ! rx-cos-slot 3 StotTable rx-cos-slot 4 StotTable rx-cos-slot 9 StotTable rx-cos-slot 13 StotTable rx-cos-slot 14 StotTable rx-cos-slot 15 StotTable ! slot-table-cos StotTable destination-slot 0 oc48 destination-slot 1 oc48 destination-slot 2 oc48 destination-slot 3 oc48 destination-slot 4 oc12 destination-slot 5 oc48 destination-slot 6 oc48 destination-slot 9 oc3 destination-slot 15 oc48 ! cos-queue-groupoc3 precedence 0 random-detect-label 0 precedence 4 queue 1 precedence 4 random-detect-label 1 precedence 5 queue low-latency precedence 6 queue 1 precedence 6 random-detect-label 1 random-detect-label 0 94 606 1 random-detect-label 1 94 606 1 queue 0 1 queue 1 73 queue low-latency strict-priority !--- Respect the tight SLA requirements. !--- No packets drop/low delay and jitter for the priority queue. ! CoS-queue-groupoc12 precedence 0 random-detect-label 0 precedence 4 queue 1 precedence 4 random-detect-label 1 precedence 5 queue low-latency precedence 6 queue 1 precedence 6 random-detect-label 1 random-detect-label 0 375 2423 1 random-detect-label 1 375 2423 1 queue 0 1 queue 1 73 queue low-latency strict-priority ! CoS-queue-groupoc48 precedence 0 random-detect-label 0 precedence 4 queue 1 precedence 4 random-detect-label 1 precedence 5 queue low-latency precedence 6 queue 1 precedence 6 random-detect-label 1 random-detect-label 0 1498 9690 1 random-detect-label 1 1498 9690 1 queue 0 1 queue 1 73 queue low-latency strict-priority
VOIP 트래픽이 많을수록 더 많은 비즈니스 트래픽이 전달되기 전에 기다려야 할 것으로 예상됩니다. 그러나 이 문제는 엄격한 SLA에 패킷 드랍이 필요하지 않으며, 우선순위 큐의 레이턴시 및 지터가 매우 낮기 때문에 문제가 되지 않습니다.
관련 정보
- show controller frb의 출력을 읽는 방법 | Cisco 12000 Series 인터넷 라우터의 tofab queue 명령
- Cisco 12000 Series 인터넷 라우터에서 무시된 패킷 및 메모리 손실 문제 해결
- Cisco 12000 Series 인터넷 라우터의 입력 삭제 문제 해결
- Cisco 12000 Series 라우터의 가중 임의 조기 탐지
- 모듈식 QoS(Quality of Service) 명령줄 인터페이스 개요
- 12000 Series 인터넷 라우터 지원 페이지
- Technical Support - Cisco Systems
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
02-Dec-2013 |
최초 릴리스 |
피드백