우선 순위 큐잉으로 출력 삭제 트러블슈팅
목차
소개
이 문서에서는 라우터 인터페이스의 우선순위 큐잉 메커니즘 컨피그레이션에서 발생하는 출력 삭제를 트러블슈팅하는 방법에 대한 팁을 제공합니다.
사전 요구 사항
요구 사항
이 문서의 독자는 다음 개념을 숙지해야 합니다.
-
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 Queueing) 기능을 활성화하고 모듈식 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 original priority queuing 기능에서 스케줄러는 항상 우선순위가 가장 높은 대기열을 먼저 서비스했습니다. 우선 순위가 높은 대기열에 항상 트래픽이 있을 경우 우선 순위가 낮은 대기열에는 대역폭이 부족하고 패킷이 우선 순위가 아닌 대기열로 이동했습니다.
레거시 우선 순위 큐잉과 함께 삭제
PQ(Priority Queueing)는 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 list-number queue-limit 명령은 우선순위 큐의 크기를 변경합니다.
토큰 버킷을 사용한 트래픽 측정
LLQ 및 IP RTP Priority는 토큰 버킷을 트래픽 측정 시스템으로 사용하여 내장 폴리서를 구현합니다. 이 섹션에서는 토큰 버킷 개념을 살펴봅니다.
토큰 버킷 자체에는 폐기 또는 우선순위 정책이 없습니다. 토큰 버킷 은유는 다음 라인에서 작동합니다.
-
토큰이 일정한 속도로 버킷에 담깁니다.
-
각 토큰은 소스에서 네트워크로 특정 비트 수를 전송할 수 있는 권한을 나타냅니다.
-
패킷을 전송하려면 트래픽 조정기가 패킷 크기와 동일한 수의 토큰을 버킷에서 제거할 수 있어야 합니다.
-
버킷에 패킷을 전송할 수 있는 토큰이 충분하지 않은 경우, 패킷은 버킷에 충분한 토큰이 있을 때까지(쉐이퍼의 경우) 기다리거나 패킷이 폐기되거나 아래로(폴리서의 경우) 표시됩니다.
-
버킷 자체에는 지정된 용량이 있습니다. 버킷의 용량이 차면 새로 도착하는 토큰은 폐기되고 향후 패킷을 사용할 수 없게 됩니다. 따라서 언제든지 애플리케이션이 네트워크로 전송할 수 있는 최대 버스트는 버킷의 크기에 거의 비례합니다. 토큰 버킷은 버스트를 허용하지만 이를 제한합니다.
패킷 및 8000bps의 CIR(Committed Information Rate)을 사용하는 예를 살펴보겠습니다.
-
이 예에서는 초기 토큰 버킷이 1000바이트에서 전체 상태로 시작됩니다.
-
450바이트 패킷이 도착하면 준수 토큰 버킷에서 사용 가능한 바이트가 충분하기 때문에 패킷이 준수됩니다. 패킷이 전송되고 토큰 버킷에서 450바이트가 제거되어 550바이트가 남습니다.
-
다음 패킷이 0.25초 후에 도착하면 토큰 버킷에 250바이트가 추가되어(0.25 * 8000)/8) 토큰 버킷에 700바이트가 남습니다. 다음 패킷이 800바이트이면 패킷이 초과되어 삭제됩니다. 토큰 버킷에서 가져온 바이트가 없습니다.
삭제 진단을 위한 트러블슈팅 단계
1단계 - 데이터 수집
데이터 수집 단계는 아래와 같습니다.
-
다음 명령을 여러 번 실행하고 삭제의 속도 및 빈도를 결정합니다. 출력을 사용하여 트래픽 패턴 및 트래픽 수준의 기준을 설정합니다. 인터페이스에서 "정상" 삭제 비율이 얼마인지 확인합니다.
-
show queueing interface
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별 대기열에서 발생하는지 확인합니다. 다음 다이어그램은 Frame Relay 가상 회로를 통한 패킷 흐름을 보여줍니다.
-
우선순위 큐잉은 최대 4개의 출력 대기열을 지원하며, 우선순위 대기열 레벨당 1개씩 각 대기열은 대기열 제한에 의해 정의됩니다. 큐잉 시스템은 패킷을 큐에 배치하기 전에 구성된 큐 제한에 대해 큐의 크기를 확인합니다. 선택한 대기열이 가득 차면 라우터가 패킷을 삭제합니다. priority-list {#} queue-limit 명령을 사용하여 큐 크기를 늘리고 모니터링을 다시 시작하십시오.
2단계 - 충분한 대역폭 확보
LLQ를 사용하면 폴리싱을 통해 다른 클래스 기반 CBWFQ(Weighted Fair Queuing) 또는 WFQ 큐의 다른 데이터 패킷을 공정하게 처리할 수 있습니다. 패킷 삭제를 방지하려면 사용된 코덱의 유형 및 인터페이스 특성을 고려하여 우선 순위 대기열에 최적의 대역폭을 할당해야 합니다. IP RTP Priority는 할당된 양을 초과하는 트래픽을 허용하지 않습니다.
알려진 필수 대역폭 양보다 약간 더 많은 대역폭을 우선 순위 큐에 할당하는 것이 항상 안전합니다. 예를 들어 음성 전송에 필요한 표준 양인 24kbps 대역폭을 우선순위 대기열에 할당했다고 가정합니다. 음성 패킷의 전송이 일정한 비트 속도로 발생하기 때문에 이 할당은 안전한 것으로 보입니다. 그러나 네트워크와 라우터 또는 스위치는 일부 대역폭을 사용하여 지터와 지연을 생성할 수 있으므로 필요한 대역폭(예: 25kbps)보다 약간 더 많이 할당하면 일관성 및 가용성이 보장됩니다.
우선순위 대기열에 할당된 대역폭은 항상 레이어 2 캡슐화 헤더를 포함합니다. 여기에는 CRC(Cyclic Redundancy Check)가 포함되지 않습니다. (IP에서 ATM CoS 큐잉으로 계산되는 바이트 참조? 을 참조하십시오.) 몇 바이트에 불과하지만 트래픽 플로우에 더 많은 수의 작은 패킷이 포함되기 때문에 CRC는 더 큰 영향을 미칩니다.
또한 ATM 인터페이스에서 우선순위 대기열에 할당된 대역폭에는 다음과 같은 ATM 셀 세금 오버헤드가 포함되지 않습니다.
-
패킷의 마지막 셀을 48바이트의 배수로 만들기 위한 SAR(Segmentation and Reassembly)에 의한 패딩.
-
ATM Adaptation Layer 5(AAL5) 트레일러의 4바이트 CRC.
-
5바이트 ATM 셀 헤더.
지정된 우선순위 클래스에 할당할 대역폭의 양을 계산할 때 레이어 2 헤더가 포함된다는 사실을 고려해야 합니다. ATM을 이용하는 경우 ATM 셀 과세 오버헤드가 포함되지 않는다는 점을 고려해야 한다. 또한 네트워크 디바이스가 음성 경로에 지터를 유입할 가능성에 대한 대역폭도 허용해야 합니다. 저지연 대기열 기능 개요를 참조하십시오.
우선순위 큐잉을 사용하여 VoIP 패킷을 전달하는 경우 VoIP(Voice over IP) - 통화별 대역폭 소비를 참조하십시오.
3단계 - 버스트 크기가 충분한지 확인합니다.
우선순위 대기열을 통해 인터페이스를 떠나는 일련의 패킷의 처리는 패킷의 크기 및 토큰 버킷에 남아 있는 바이트 수에 따라 달라집니다. LLQ는 셰이퍼가 아닌 폴리서를 사용하므로 우선 순위 큐로 향하는 트래픽 흐름의 특성을 고려해야 합니다. 폴리서는 다음과 같이 토큰 버킷을 사용합니다.
-
버킷에는 최대 버스트 매개변수에 대한 클래스 속도를 기반으로 하는 토큰이 채워집니다.
-
토큰 수가 패킷 크기보다 크거나 같으면 패킷이 전송되고 토큰 버킷이 감소합니다. 그렇지 않으면 패킷이 삭제됩니다.
LLQ의 토큰 버킷 트래픽 측정기의 기본 버스트 값은 구성된 대역폭 속도에서 트래픽의 200밀리초로 계산됩니다. 경우에 따라 기본값이 부적절하며, 특히 TCP 트래픽이 우선순위 큐로 이동하는 경우 더욱 그렇습니다. TCP 플로우는 일반적으로 버스트 처리되며 특히 느린 링크에서 대기열 시스템이 할당한 기본값보다 큰 버스트 크기가 필요할 수 있습니다.
하기 샘플 출력은 128 kbps의 지속 세포 속도를 갖는 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의 기능은 Configuring Burst Size in Low Latency Queueing 기능으로 구성 가능한 Committed Burst (Bc) 크기를 허용하도록 확장되었습니다. 이 새로운 기능을 통해 네트워크에서 일시적으로 급증하는 트래픽을 수용하고 네트워크 트래픽을 더 효율적으로 처리할 수 있습니다.
burst 매개 변수를 priority 명령과 함께 사용하여 버스트 값을 1600바이트에서 3200바이트로 늘립니다.
policy-map AV class AV priority percent 50 3200
참고: 값이 높으면 우선 순위 클래스에서 사용할 수 있는 유효 대역폭이 증가하고 우선 순위 클래스가 대역폭의 공평한 점유율보다 더 많이 얻는 것처럼 보일 수 있습니다.
또한 대기열 시스템은 원래 저지연 대기열에 64개 패킷의 내부 대기열 제한을 할당했습니다. 64개 패킷의 버스트가 우선순위 대기열에 도착한 경우 트래픽 측정기는 버스트가 구성된 속도에 부합하지만 패킷 수가 대기열 제한을 초과했음을 확인합니다. 그 결과 일부 패킷이 테일 드롭되었습니다. Cisco 버그 ID CSCdr51979(등록된 고객만 해당)는 우선순위 큐 크기가 트래픽 측정기에서 허용하는 범위 내에서 확장되도록 하여 이 문제를 해결합니다.
다음의 출력은 CIR 56 kbps로 구성된 Frame Relay PVC에서 캡처되었습니다. 샘플 출력의 첫 번째 세트에서 c1 및 c2 클래스의 결합된 제공률은 76 kbps이다. 그 이유는 제공된 비율에서 드롭 비율을 뺀 계산된 값이 실제 전송 속도를 나타내지 않으며 전송하기 전에 쉐이퍼에 있는 패킷을 포함하지 않기 때문입니다.
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 명령에 대한 중요한 정보를 참조하십시오. 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) 최대 임계값을 늘리면 사용 가능한 버퍼가 고갈되어 우선순위 큐가 중단되었습니다. 이 문제를 진단하는 데 도움이 되도록 IOS의 향후 릴리스에서 우선 순위 클래스에 대한 "no-buffer drops" 카운터가 계획되었습니다.
-
입력 인터페이스의 큐 제한이 출력 인터페이스의 큐 제한보다 작으면 패킷 삭제는 입력 인터페이스로 이동합니다. 이러한 증상은 Cisco 버그 ID CSCdu89226(등록된 고객만 해당)에 문서화되어 있습니다. 입력 삭제를 방지하고 아웃바운드 우선순위 대기열 메커니즘을 적용할 수 있도록 입력 대기열과 출력 대기열의 크기를 적절하게 조정하여 이 문제를 해결합니다.
-
CEF 스위치드 또는 고속 스위치드 경로에서 지원되지 않는 기능을 활성화하면 많은 수의 패킷이 프로세스 스위치됩니다. LLQ에서는 인터페이스가 혼잡한지 여부에 관계없이 프로세스 전환 패킷이 현재 폴리싱됩니다. 즉, 인터페이스가 혼잡하지 않더라도 큐잉 시스템은 프로세스 전환 패킷을 측정하여 제공된 로드가 priority 명령으로 구성된 대역폭 값을 초과하지 않도록 보장합니다. 이 문제는 Cisco 버그 ID CSCdv86818(등록된 고객만 해당)에 문서화되어 있습니다.
우선 순위 대기열 삭제 및 프레임 릴레이
Frame Relay는 우선순위 큐 폴리싱과 관련된 특수 케이스입니다. Low Latency Queueing for Frame Relay 기능 개요에서는 다음 사항에 유의합니다. "PQ는 공정 대기열에 대역폭이 부족하지 않도록 감시됩니다. PQ를 구성할 때 해당 대기열에 사용 가능한 최대 대역폭의 양을 kbps 단위로 지정합니다. 최대값을 초과하는 패킷은 삭제됩니다." 즉, 원래 Frame Relay 맵 클래스에 구성된 서비스 정책의 우선순위 큐는 혼잡 및 비혼잡 기간 동안 폴리싱되었습니다. IOS 12.2에서는 이 예외를 제거합니다. PQ는 여전히 FRF.12에서 폴리싱되지만, 다른 비준수 패킷은 혼잡이 있는 경우에만 삭제됩니다.
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
27-Nov-2001
|
최초 릴리스 |
피드백