우선 순위 대기열 처리를 통한 출력 삭제 문제 해결
목차
소개
이 문서에서는 라우터 인터페이스의 우선순위 대기열 메커니즘 컨피그레이션에서 발생하는 출력 삭제를 트러블슈팅하는 방법에 대한 팁을 제공합니다.
사전 요구 사항
요구 사항
이 문서의 독자는 다음 개념에 익숙해야 합니다.
-
priority-group 또는 frame-relay priority-group - Cisco 레거시 우선순위 대기열 처리 메커니즘을 활성화합니다. 최대 4가지 수준의 우선순위 큐를 지원합니다.
-
ip rtp priority 또는 frame-relay ip rtp priority - VoIP 패킷을 캡슐화하는 RTP(Real-Time Protocol) 트래픽의 UDP 포트 번호에서 일치시키고 이러한 패킷을 우선순위 대기열에 넣습니다.
-
priority - Cisco의 LLQ(Low Latency Queuing) 기능을 활성화하고 모듈형 QoS CLI(Command Line Interface)의 명령 구조를 사용합니다.
라우터는 이러한 방법 중 하나가 구성된 경우 출력 삭제를 보고할 수 있지만, 각 경우 방법 및 삭제 사유 사이에 중요한 기능 차이가 있습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 명령을 사용하기 전에 어떤 명령의 잠재적인 영향을 이해해야 합니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.
표기 규칙
문서 표기 규칙에 대한 자세한 내용은 Cisco 기술 팁에 사용된 표기 규칙을 참조하십시오.
ip rtp 우선 순위 및 LLQ가 있는 삭제
Cisco IOS Configuration Guide는 다음과 같은 우선순위 대기열 처리 메커니즘으로 출력 삭제를 경고합니다.
-
ip rtp 우선순위: ip rtp priority 명령은 다른 트래픽보다 절대 우선 순위를 부여하므로 주의하여 사용해야 합니다. 혼잡이 발생할 경우 트래픽이 구성된 대역폭을 초과하면 초과 트래픽이 모두 삭제됩니다.
-
priority 명령 및 LLQ: 클래스에 대해 priority 명령을 지정하면 최대 대역폭을 제공하는 bandwidth 인수를 사용합니다. 정체 시 폴리싱은 대역폭을 초과할 때 패킷을 삭제하는 데 사용됩니다.
이 두 메커니즘은 기본 제공 폴리서를 사용하여 트래픽 흐름을 측정합니다. 폴리서의 목적은 대기열 스케줄러에서 다른 대기열을 서비스하도록 하는 것입니다. priority-group 및 priority-list 명령을 사용하는 Cisco의 원래 우선순위 대기열 처리 기능에서는 스케줄러가 항상 우선순위가 가장 높은 대기열을 먼저 서비스합니다. 우선 순위가 높은 대기열에 항상 트래픽이 있는 경우 우선 순위가 낮은 큐에는 대역폭이 부족하고 우선 순위가 낮은 큐로 이동하는 패킷이 부족했습니다.
레거시 우선순위 큐잉이 있는 삭제
PQ(Priority Queuing)는 cisco의 기존 우선순위 대기열 처리 메커니즘입니다. 아래 그림과 같이 PQ는 최대 4개의 대기열 레벨을 지원합니다. 높음, 보통, 보통, 낮음 등의 순서로 표시됩니다.
인터페이스에서 우선순위 큐잉을 활성화하면 출력 대기열 표시가 아래에 표시된 대로 변경됩니다. 이더넷 인터페이스에서 우선순위 큐잉 전에 기본 대기열 크기가 40패킷인 단일 출력 보류 대기열을 사용합니다.
R6-2500# show interface ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
Internet address is 42.42.42.2/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
239407 packets input, 22644297 bytes, 0 no buffer
Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
374436 packets output, 31095372 bytes, 0 underruns
0 output errors, 1 collisions, 13 interface resets
0 babbles, 0 late collision, 8 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
PQ를 활성화한 후에는 이더넷 인터페이스에서 대기열 제한이 다른 4개의 우선순위 대기열을 사용합니다(아래 출력에 표시됨).
R6-2500(config)# interface ethernet0
R6-2500(config-if)# priority-group 1
R6-2500(config-if)# end
R6-2500# show interface ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
Internet address is 42.42.42.2/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: priority-list 1
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
239411 packets input, 22644817 bytes, 0 no buffer
Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
374440 packets output, 31095658 bytes, 0 underruns
0 output errors, 1 collisions, 14 interface resets
0 babbles, 0 late collision, 8 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
priority-list {list-number} 명령은 트래픽 흐름을 특정 대기열에 할당하는 데 사용됩니다. 패킷이 인터페이스에 도달하면 해당 인터페이스의 우선순위 큐에서 우선 순위가 내림차순으로 패킷을 스캔합니다. 우선 순위가 높은 대기열이 먼저 검사된 다음 중간 우선 순위 대기열 등이 검사됩니다. 우선순위가 가장 높은 대기열의 헤드에 있는 패킷이 전송용으로 선택됩니다. 이 절차는 패킷을 전송할 때마다 반복됩니다.
각 대기열은 최대 길이 또는 대기열에서 보유할 수 있는 최대 패킷 수로 정의됩니다. 도착하는 패킷으로 인해 현재 대기열 깊이가 구성된 대기열 제한을 초과할 경우 패킷이 삭제됩니다. 따라서 위에서 설명한 것처럼 PQ가 있는 출력 삭제는 일반적으로 LLQ의 일반적인 경우와 같이 대기열 제한을 초과하고 내부 폴리서가 아니기 때문입니다. priority-list number queue-limit 명령은 우선순위 대기열의 크기를 변경합니다.
토큰 버킷을 사용한 트래픽 측정
LLQ 및 IP RTP Priority는 토큰 버킷을 트래픽 측정 시스템으로 사용하여 기본 제공 정책을 구현합니다. 이 섹션에서는 토큰 버킷 개념을 살펴봅니다.
토큰 버킷 자체에는 폐기 또는 우선순위 정책이 없습니다. 토큰 버킷 은유는 다음 줄을 따라 작동합니다.
-
토큰은 일정한 속도로 버킷에 입력됩니다.
-
각 토큰은 소스에서 특정 비트 수를 네트워크로 보낼 수 있는 권한을 나타냅니다.
-
패킷을 전송하려면 트래픽 조절기가 버킷에서 패킷 크기와 동일한 수의 토큰을 제거할 수 있어야 합니다.
-
버킷에 패킷을 전송할 수 있는 토큰이 충분하지 않은 경우, 패킷은 버킷에 충분한 토큰(쉐이퍼의 경우)이 있을 때까지 기다리거나, 패킷이 폐기되거나(폴리서의 경우) 아래로 표시됩니다.
-
버킷 자체에는 지정된 용량이 있습니다. 버킷이 용량에 도달하면 새로 도착하는 토큰은 폐기되며 향후 패킷에 사용할 수 없습니다. 따라서 애플리케이션이 네트워크로 전송할 수 있는 최대 버스트는 버킷 크기와 거의 비례합니다. 토큰 버킷은 버스트티를 허용하지만 그 범위를 제한합니다.
패킷 사용 예와 8000bps의 CIR(Committed Information Rate)을 살펴보겠습니다.
-
이 예에서 초기 토큰 버킷은 1000바이트에서 가득 찰 것입니다.
-
450바이트 패킷이 도착하면 conform token bucket에서 충분한 바이트를 사용할 수 있기 때문에 패킷이 일치됩니다. 패킷이 전송되고 토큰 버킷에서 450바이트가 제거되어 550바이트가 남습니다.
-
다음 패킷이 0.25초 후에 도착하면 토큰 버킷(0.25 * 8000)/8)에 250바이트가 추가되어 토큰 버킷에 700바이트가 남습니다. 다음 패킷이 800바이트이면 패킷이 초과되고 삭제됩니다. 토큰 버킷에서 가져온 바이트가 없습니다.
삭제를 진단하는 문제 해결 단계
1단계 - 데이터 수집
데이터 수집 단계는 아래와 같습니다.
-
다음 명령을 여러 번 실행하고 드롭이 얼마나 빨리 그리고 얼마나 자주 증가하는지 결정합니다. 출력을 사용하여 트래픽 패턴 및 트래픽 레벨의 기준을 설정합니다. 인터페이스에서 "일반" 드롭 비율이 어느 정도인지 확인합니다.
-
큐 인터페이스 표시
router# show queueing interface hssi 0/0/0 Interface Hssi0/0/0 queueing strategy: priority Output queue utilization (queue/count) high/12301 medium/4 normal/98 low/27415 -
show interface - 출력에 표시되는 로드 값을 모니터링합니다. 또한 show interface 출력의 대기열별 삭제 수 합계가 출력 삭제 수와 동일한지 확인합니다. show interface output drops 카운터는 WRED 버림, 버퍼 부족("버퍼 없음" 오류)으로 인한 버림, 온보드 포트 어댑터 메모리의 폐기 등 출력에 있는 모든 삭제의 총 합계를 표시해야 합니다.
router# show interface serial 4/1/2 Serial4/1/2 is up, line protocol is up Hardware is cyBus Serial Description: E1 Link to 60W S9/1/2 Backup Internet address is 169.127.18.228/27 MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 5d10h Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 Queueing strategy: priority-list 7 Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 5 minute input rate 959000 bits/sec, 419 packets/sec 5 minute output rate 411000 bits/sec, 150 packets/sec 144067307 packets input, 4261520425 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 69726448 packets output, 2042537282 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 46686454 output buffers swapped out 0 carrier transitions
참고: 일부 인터페이스에는 별도의 "txload" 및 "rxload" 값이 표시됩니다.
Hssi0/0/0 is up, line protocol is up Hardware is cyBus HSSI MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, reliability 255/255, txload 138/255, rxload 17/255 Encapsulation FRAME-RELAY IETF, crc 16, loopback not set Keepalive set (5 sec) LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface broadcasts 7651 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 06:31:58 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 Queueing strategy: priority-list 1 Output queue (queue priority: size/max/drops): high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 5 minute input rate 524000 bits/sec, 589 packets/sec 5 minute output rate 4080000 bits/sec, 778 packets/sec 11108487 packets input, 1216363830 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 15862186 packets output, 3233772283 bytes, 0 underruns 0 output errors, 0 applique, 1 interface resets 0 output buffer failures, 2590 output buffers swapped out 0 carrier transitions LC=down CA=up TM=down LB=down TA=up LA=down
-
show policy-map interface interface-name - "pkts discards" 카운터에 0이 아닌 값을 찾습니다.
Router# show policy-map interface s1/0 Serial1/0.1: DLCI 100 - output : mypolicy Class voice Weighted Fair Queueing Strict Priority Output Queue: Conversation 72 Bandwidth 16 (kbps) Packets Matched 0 (pkts discards/bytes discards) 0/0 Class immediate-data Weighted Fair Queueing Output Queue: Conversation 73 Bandwidth 60 (%) Packets Matched 0 (pkts discards/bytes discards/tail drops) 0/0/0 mean queue depth: 0 drops: class random tail min-th max-th mark-prob 0 0 0 64 128 1/10 1 0 0 71 128 1/10 2 0 0 78 128 1/10 3 0 0 85 128 1/10 4 0 0 92 128 1/10 5 0 0 99 128 1/10 6 0 0 106 128 1/10 7 0 0 113 128 1/10 rsvp 0 0 120 128 1/10참고: 다음 예제 출력에는 "packets" 및 "pkts matched" 카운터에 대한 일치 값이 표시됩니다. 이 상태는 많은 수의 패킷이 프로세스 스위칭되고 있거나 인터페이스가 극심한 혼잡을 겪고 있음을 나타냅니다. 이 두 조건 모두 클래스의 대기열 제한을 초과할 수 있으므로 조사해야 합니다.
router# show policy-map interface Serial4/0 Service-policy output: policy1 Class-map: class1 (match-all) 189439 packets, 67719268 bytes 5 minute offered rate 141000 bps, drop rate 0 bps Match: access-group name ds-class-af3 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 50 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 189439/67719268 (depth/total drops/no-buffer drops) 0/0/0
-
-
트래픽 흐름과 해당 흐름의 패킷을 분류합니다.
-
평균 패킷 크기는 얼마입니까?
-
MTU 크기의 프레임이 어느 방향으로 흐르는가? 많은 트래픽 흐름은 로드와 관련하여 비동기적입니다. 예를 들어 FTP 다운로드를 사용하면 대부분의 MTU 크기 패킷이 FTP 서버에서 클라이언트로 이동합니다. FTP 클라이언트에서 서버로의 패킷은 간단한 TCP ACK입니다.
-
패킷이 TCP 또는 UDP를 사용합니까? TCP를 사용하면 소스가 전송을 일시 중지하고 목적지가 전송된 패킷을 승인할 때까지 기다려야 하기 전에 각 흐름이 인증된 패킷 수를 전송할 수 있습니다.
-
-
Frame Relay를 사용하여 인터페이스 대기열에서 또는 VC별 대기열에서 드롭이 발생하는지 확인합니다. 다음 다이어그램은 프레임 릴레이 가상 회로를 통한 패킷 흐름을 보여줍니다.
-
우선 순위 큐잉은 최대 4개의 출력 대기열을 지원하며, 우선 순위 대기열 레벨당 하나씩, 각 대기열은 대기열 제한에 의해 정의됩니다. 큐잉 시스템은 패킷을 대기열에 배치하기 전에 구성된 대기열 제한에 대해 큐의 크기를 확인합니다. 선택한 큐가 가득 차면 라우터가 패킷을 삭제합니다. priority-list {#} queue-limit 명령을 사용하여 큐 크기를 늘리고 모니터링을 다시 시작해 보십시오.
2단계 - 충분한 대역폭 보장
LLQ를 사용하면 폴리싱을 통해 다른 클래스 기반 CBWFQ(Weighted Fair Queuing) 또는 WFQ 큐의 다른 데이터 패킷을 공정하게 처리할 수 있습니다. 패킷 삭제를 방지하려면 사용된 코덱의 유형 및 인터페이스 특성을 고려하여 우선 순위 대기열에 최적의 대역폭을 할당해야 합니다. IP RTP 우선 순위는 할당된 양을 초과하는 트래픽을 허용하지 않습니다.
알려진 필수 대역폭보다 약간 더 많은 대역폭을 우선순위 대기열에 할당하는 것이 항상 안전합니다. 예를 들어 음성 전송에 필요한 표준 양인 24kbps 대역폭을 우선순위 대기열에 할당했다고 가정합니다. 음성 패킷의 전송은 일정한 비트 속도로 이루어지므로 이 할당은 안전한 것으로 보입니다. 그러나 네트워크 및 라우터 또는 스위치는 일부 대역폭을 사용하여 지터와 지연을 생성할 수 있으므로 필요한 대역폭 양(예: 25kbps)보다 약간 더 많이 할당하면 일관성과 가용성이 보장됩니다.
우선순위 대기열에 할당된 대역폭에는 항상 레이어 2 캡슐화 헤더가 포함됩니다. CRC(순환 중복 검사)는 포함되지 않습니다. (IP에서 ATM CoS 대기열 처리로 계산되는 바이트 수 참조? 자세한 내용을 참조하십시오.) 단 몇 바이트에 불과하지만 트래픽 플로우에 더 많은 수의 작은 패킷이 포함되므로 CRC는 더 큰 영향을 미칩니다.
또한 ATM 인터페이스에서 우선순위 대기열에 할당된 대역폭에는 다음 ATM 셀 세금 오버헤드가 포함되지 않습니다.
-
패킷의 마지막 셀을 48바이트의 배수로 만들기 위한 SAR(segmentation and reassembly)의 패딩.
-
ATM Adaptation Layer 5(AAL5) 트레일러의 4바이트 CRC
-
5바이트 ATM 셀 헤더.
지정된 우선순위 클래스에 할당할 대역폭의 양을 계산할 때 레이어 2 헤더가 포함되었다는 사실을 고려해야 합니다. ATM을 사용할 때 ATM 셀 세금 오버헤드가 포함되지 않는다는 사실을 고려해야 합니다. 또한 음성 경로의 네트워크 디바이스에서 유입되는 지터가 발생할 가능성을 위한 대역폭을 허용해야 합니다. Low Latency Queuing 기능 개요를 참조하십시오.
우선순위 큐잉을 사용하여 VoIP 패킷을 전달하는 경우 Voice over IP - Per Call Bandwidth Consumption을 참조하십시오.
3단계 - 충분한 버스트 크기 확인
우선순위 큐를 통해 인터페이스를 떠나는 일련의 패킷의 처리는 패킷 크기와 토큰 버킷에 남아 있는 바이트 수에 따라 달라집니다. LLQ는 쉐이퍼가 아닌 폴리서를 사용하므로 우선 순위 큐로 전달되는 트래픽 흐름의 특성을 고려하는 것이 중요합니다. 폴리서는 다음과 같이 토큰 버킷을 사용합니다.
-
버킷은 클래스 속도를 기준으로 버스트 매개변수의 최대값에 해당하는 토큰으로 채워집니다.
-
토큰 수가 패킷 크기보다 크거나 같으면 패킷이 전송되고 토큰 버킷이 감소됩니다. 그렇지 않으면 패킷이 삭제됩니다.
LLQ의 토큰 버킷 트래픽 측정기의 기본 버스트 값은 구성된 대역폭 속도로 200밀리초로 계산됩니다. 경우에 따라, 특히 TCP 트래픽이 우선순위 큐로 이동하는 경우 기본값이 적합하지 않습니다. TCP 플로우는 일반적으로 버스트이며, 특히 느린 링크에서 대기열 시스템에 지정된 기본값보다 큰 버스트 크기가 필요할 수 있습니다.
다음 샘플 출력은 셀 속도가 128kbps인 ATM PVC에서 생성되었습니다. 대기열 시스템은 priority 명령으로 지정된 값이 변경될 때 버스트 크기를 조정합니다.
7200-17# show policy-map int atm 4/0.500
ATM4/0.500: VC 1/500 -
Service-policy output: drops
Class-map: police (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 90 (%)
Bandwidth 115 (kbps) Burst 2875 (Bytes)
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps.
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
7200-17# show policy-map int atm 4/0.500
ATM4/0.500: VC 1/500 -
Service-policy output: drops
Class-map: police (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 50 (%)
Bandwidth 64 (kbps) Burst 1600 (Bytes)
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps.
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
LLQ의 기능이 확장되어 대기 시간이 짧은 대기열 처리 기능의 버스트 크기 구성 기능을 사용하여 구성 가능한 커밋된 버스트(BC) 크기를 허용합니다. 이 새로운 기능을 통해 네트워크는 일시적인 트래픽 버스트를 수용하고 네트워크 트래픽을 더 효율적으로 처리할 수 있습니다.
버스트 매개 변수를 priority 명령과 함께 사용하여 버스트 값을 1600바이트에서 3200바이트로 늘립니다.
policy-map AV class AV priority percent 50 3200
참고: 값이 높으면 우선 순위 클래스에서 사용할 수 있는 유효 대역폭이 늘어나며, 우선 순위 클래스가 대역폭의 공평한 점유율보다 더 많은 것으로 나타날 수 있습니다.
또한 대기열 시스템은 원래 내부 대기열 제한인 64개의 패킷을 짧은 대기 시간 대기열에 할당했습니다. 경우에 따라 64개 패킷의 버스트가 우선순위 대기열에 도달하면 트래픽 측정기에서 버스트가 구성된 속도로 구성되었음을 확인하지만 패킷 수가 큐 제한을 초과했습니다. 그 결과 일부 패킷은 tail-dropped였습니다. Cisco 버그 ID CSCdr51979(등록된 고객만 해당)는 우선 순위 큐 크기가 트래픽 측정기에서 허용하는 만큼 크게 증가하도록 허용하여 이 문제를 해결합니다.
CIR이 56kbps인 프레임 릴레이 PVC에서 다음 출력이 캡처되었습니다. 첫 번째 샘플 출력 집합에서 c1 및 c2 클래스의 결합된 제공 속도는 76kbps입니다. 제공된 전송률에서 삭제 비율을 뺀 계산된 값은 실제 전송 속도를 나타내지 않으며 전송되기 전에 쉐이퍼에 있는 패킷을 포함하지 않기 때문입니다.
router# show policy-map int s2/0.1
Serial2/0.1: DLCI 1000 -
Service-policy output: p
Class-map: c1 (match-all)
7311 packets, 657990 bytes
30 second offered rate 68000 bps, drop rate 16000 bps
Match: ip precedence 1
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 90 (%)
Bandwidth 50 (kbps) Burst 1250 (Bytes)
(pkts matched/bytes matched) 7311/657990
(total drops/bytes drops) 2221/199890
Class-map: c2 (match-all)
7311 packets, 657990 bytes
30 second offered rate 68000 bps, drop rate 44000 bps
Match: ip precedence 2
Weighted Fair Queueing
Output Queue: Conversation 25
Bandwidth 10 (%)
Bandwidth 5 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 7310/657900
(depth/total drops/no-buffer drops) 64/6650/0
Class-map: class-default (match-any)
2 packets, 382 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
이 두 번째 출력 집합에서 show policy-map 인터페이스 카운터가 표준화되었습니다. 56kbps PVC에서 c1 클래스는 약 50kbps를 전송하고 c2 클래스는 약 6kbps를 전송합니다.
router# show policy-map int s2/0.1
Serial2/0.1: DLCI 1000 -
Service-policy output: p
Class-map: c1 (match-all)
15961 packets, 1436490 bytes
30 second offered rate 72000 bps, drop rate 21000 bps
Match: ip precedence 1
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 24
Bandwidth 90 (%)
Bandwidth 50 (kbps) Burst 1250 (Bytes)
(pkts matched/bytes matched) 15961/1436490
(total drops/bytes drops) 4864/437760
Class-map: c2 (match-all)
15961 packets, 1436490 bytes
30 second offered rate 72000 bps, drop rate 66000 bps
Match: ip precedence 2
Weighted Fair Queueing
Output Queue: Conversation 25
Bandwidth 10 (%)
Bandwidth 5 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 15960/1436400
(depth/total drops/no-buffer drops) 64/14591/0
Class-map: class-default (match-any)
5 packets, 1096 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
4단계 - 디버그 우선 순위
debug priority 명령은 우선순위 대기열에서 패킷이 삭제된 경우 우선순위 대기열 출력을 표시합니다.
주의: debug 명령을 사용하기 전에 디버그 명령에 대한 중요 정보를 참조하십시오. debug priority 명령은 프로덕션 라우터에 대량의 중단 디버그 출력을 인쇄할 수 있습니다. 금액은 혼잡 수준에 따라 다릅니다.
다음 샘플 출력이 Cisco 3640에서 생성되었습니다.
r3-3640-5# debug priority Priority output queueing debugging is on r3-3640-5# ping 10.10.10.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms r3-3640-5# 00:42:40: PQ: Serial0/1: ip -> normal 00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 00:42:40: PQ: Serial0/1: ip -> normal 00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 00:42:40: PQ: Serial0/1: ip -> normal 00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 00:42:40: PQ: Serial0/1: ip -> normal 00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 00:42:40: PQ: Serial0/1: ip -> normal 00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) r3-3640-5#no debug priority 00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) Priority output queueing debugging is off
다음 디버그 우선순위 출력에서 64는 패킷이 삭제되었을 때의 실제 우선순위 대기열 깊이를 나타냅니다.
*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64 *Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64
삭제의 기타 원인
LLQ와 함께 출력되는 다음과 같은 이유는 케이스 문제 해결 중에 Cisco TAC(Technical Assistance Center)에서 발견되었으며 Cisco 버그 보고서에 문서화되었습니다.
-
다른 클래스에 대한 WRED(Weighted Random Early Detection) 최대 임계값 증가 시 사용 가능한 버퍼가 소진되어 우선 순위 큐에서 삭제됩니다. 이 문제를 진단하는 데 도움이 되도록 우선 순위 클래스에 대한 "no-buffer drops" 카운터가 향후 IOS 릴리스에 대해 계획됩니다.
-
입력 인터페이스의 대기열 제한이 출력 인터페이스의 대기열 제한보다 작으면 패킷이 입력 인터페이스로 이동합니다. 이러한 증상들은 Cisco 버그 ID CSCdu89226에 설명되어 있습니다(등록된 고객만 해당). 입력 대기열과 출력 대기열의 크기를 적절하게 조정하여 입력 삭제를 방지하고 아웃바운드 우선순위 대기열 처리 메커니즘이 적용되도록 하여 이 문제를 해결합니다.
-
CEF-switched 또는 fast-switched 경로에서 지원되지 않는 기능을 활성화하면 많은 패킷이 프로세스 스위칭됩니다. LLQ에서는 프로세스 전환 패킷이 현재 인터페이스가 혼잡한지 여부에 관계없이 폴리싱됩니다. 즉, 인터페이스가 혼잡하지 않더라도 대기열 시스템은 프로세스 전환 패킷을 측정하고 제공된 로드가 priority 명령으로 구성된 대역폭 값을 초과하지 않도록 합니다. 이 문제는 Cisco 버그 ID CSCdv86818에 설명되어 있습니다(등록된 고객만 해당).
우선 순위 대기열 삭제 및 프레임 릴레이
Frame Relay는 우선 순위 대기열 폴리싱과 관련된 특수한 경우입니다. Low Latency Queueing for Frame Relay 기능 개요는 다음 주의 사항을 설명합니다. "PQ는 공정한 대기열에 대역폭이 부족하지 않도록 폴리싱됩니다. PQ를 구성할 때 해당 대기열에 사용할 수 있는 최대 대역폭 양을 kbps 단위로 지정합니다. 해당 최대값을 초과하는 패킷은 삭제됩니다." 즉, 원래 프레임 릴레이 맵 클래스에 구성된 서비스 정책의 우선순위 큐는 혼잡 및 비혼잡 기간 동안 폴리싱되었습니다. IOS 12.2는 이 예외를 제거합니다. PQ는 여전히 FRF.12로 폴리싱되지만, 기타 일치하지 않는 패킷은 정체 현상이 있는 경우에만 삭제됩니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
15-Feb-2008 |
최초 릴리스 |
피드백