99%에서 실행되는 VIP CPU 및 Rx-Side 버퍼링 이해
목차
소개
이 문서에서는 VIP(Versatile Interface Processor) CPU가 99%에서 실행되는 이유와 Rx 측 버퍼에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
배경 정보
Rx-side 버퍼링은 아웃바운드 인터페이스에서 발생하는 프로세스입니다.
-
정체 상태입니다.
-
에서는 FIFO(First in, First Out) 대기열 처리 전략을 사용합니다.
인바운드 VIP(Versatile Interface Processor)는 패킷을 즉시 삭제하지 않습니다.대신 발신 인터페이스에 버퍼를 사용할 수 있을 때까지 패킷을 패킷 메모리에 버퍼링합니다.VIP 유형에 따라 패킷 메모리는 정적 RAM(SRAM) 또는 동기식 동적 RAM(SDRAM)일 수 있습니다.
Cisco 7500 Series 아키텍처 기본 사항
각 인터페이스 프로세서(레거시 IP 또는 VIP)는 CyBus라는 고속 확장 시스템 버스에 하나의 연결을 가집니다.RSP(Route/Switch Processor)가 2개의 CyBus에 연결되어 있습니다(그림 1 참조).
그림 1 - Cisco 7500 Series 아키텍처 
패킷 버퍼 유형
이 섹션에서는 다양한 유형의 패킷 버퍼에 대해 설명합니다.
-
RSP의 프로세서 메모리에 있는 시스템 버퍼
이러한 버퍼는 프로세스 전환 패킷에 사용됩니다.show interface(입력 및 출력 대기열) 및 show buffers 명령의 출력에서 이러한 버퍼를 볼 수 있습니다.Cisco 7500 Series 라우터는 많은 프로세스 스위칭을 수행하지 않아야 합니다.따라서 시스템 버퍼에 문제가 있으면 너무 많은 패킷이 프로세스 레벨로 전송됨을 의미합니다.이는 다음과 같은 여러 요인 때문일 수 있습니다.
-
방송 폭풍
-
라우팅 업데이트를 일으키는 네트워크의 불안정
-
"서비스 거부"(DoS) 공격
-
고속 스위칭 경로에서 지원되지 않는 기능(예: X.25)
-
옵션이 있는 IP 패킷
과도한 프로세스 스위칭을 해결하는 방법에 대한 자세한 내용은 다음 문서를 참조하십시오.
-
-
RSP(MEMD) 버퍼의 패킷 메모리
MEMD 크기는 RSP7000, RSP1, RSP2 및 RSP4에서 2MB로 고정되어 있습니다. RSP8 및 RSP16에서 MEMD 크기는 8MB입니다.MEMD는 부팅 시 OIR(Online Insertion and Removal), 마이크로코드 다시 로드, MTU(Maximum Transmission Unit) 변경 또는 CBUS 콤플렉스 간에 배포됩니다.버스 복잡성에 대한 자세한 내용은 "%RSP-3-RESTART의 원인:"버스 복합".show controllers cbus 명령을 사용하여 MEMD 버퍼의 상태를 확인할 수 있습니다.
MEMD가 할당되면 다음 구조가 생성됩니다.
-
A local free queue (lfreeq) - 각 인터페이스에 할당되며 이 인터페이스에서 수신된 패킷에 사용됩니다.
-
A global free queue (gfreeq)(전역 여유 대기열(gfreeq) - 또한 할당되며, 인터페이스가 일부 제한 내에서 해당 대기열로 다시 돌아갈 수 있습니다.
-
A transmit queue(txqueue 또는 txq)—각 인터페이스에 할당되며 이 인터페이스를 통해 전송되는 패킷에 사용됩니다.
-
transmit acculator(txacc) - 출력 인터페이스 전송 큐(txqueue)의 요소 수를 나타냅니다. 전송 누적기(txacc)가 전송 제한(txlimit)과 같으면 모든 버퍼가 해제됩니다.txacc가 0이면 큐가 가득 차므로 더 이상 큐잉이 허용되지 않습니다.
-
-
패킷 메모리
VIP에서 패킷 메모리는 VIP 인터페이스에서 수신하거나 VIP 인터페이스로 전송되는 패킷에 사용되는 패킷 버퍼(입자)를 포함합니다.그림 2는 패킷 흐름을 나타냅니다.
그림 2 - 패킷 흐름
이 섹션에서는 패킷이 이 이러한 유형의 스위칭 경로를 따를 때 일반적으로 Rx 측 버퍼링이 발생하기 때문에 분산 스위칭이 활성화된 VIP에 초점을 맞춥니다.다음과 같은 다양한 시나리오가 가능합니다.
시나리오 1:아웃바운드 인터페이스에 혼잡이 없는 경우
-
패킷은 PA(포트 어댑터)에서 수신되고 패킷 메모리의 패킷 버퍼로 이동됩니다.
-
VIP에서 패킷을 배포-전환할 수 없는 경우 패킷을 RSP에 전달하여 스위칭 결정을 내리게 합니다.
-
VIP가 스위칭 결정을 내릴 수 있고 발신 인터페이스가 동일한 VIP에 있는 경우 패킷은 아웃바운드 인터페이스에서 전송됩니다.패킷은 VIP에서 "로컬로 스위칭됨"이라고 하는데, 이는 버스를 통과하지 않기 때문입니다.
-
VIP가 스위칭을 결정할 수 있고 발신 인터페이스가 다른 슬롯에 있는 경우 VIP는 CBUS를 통해 패킷을 아웃바운드 인터페이스의 txqueue(MEMD)로 복사하려고 시도합니다.
-
그런 다음 패킷을 버스를 통해 발신(V)IP에 복사하고 회선에서 전송합니다.
시나리오 2:아웃바운드 인터페이스가 혼잡할 때
두 가지 가능성이 있습니다.
-
발신 인터페이스에서 큐잉이 구성된 경우 VIP는 패킷을 MEMD의 txqueue로 전송하고 패킷은 큐잉 코드에 의해 대기열에서 즉시 가져옵니다.
-
RSP 기반 큐잉이 구성된 경우 RSP의 프로세서 메모리의 시스템 버퍼에 패킷이 복사됩니다.
-
VIP 기반 큐잉이 사용되는 경우 패킷은 아웃바운드 VIP의 패킷 메모리에 복사됩니다.
-
-
아웃바운드 인터페이스의 대기열 처리 전략이 FIFO이면 인터페이스가 패킷을 즉시 삭제하지 않습니다(일반적으로 아웃바운드 인터페이스가 혼잡할 때 FIFO에서 발생). 대신 인바운드 VIP는 일부 버퍼를 발신 인터페이스에 다시 사용할 수 있을 때까지 패킷을 패킷 메모리에 버퍼링합니다.이를 Rx 측 버퍼링이라고 합니다.
-
show controllers vip accumulator 명령을 사용하여 Rx-side 버퍼링의 상태를 확인합니다.상태는 다음을 나타냅니다.
-
라우터에 있는 출력 인터페이스 수입니다.
-
VIP에 이러한 인터페이스에 대해 Rx-buffered가 있는 패킷 수입니다.
-
VIP에 Rx-buffered가 있는 이유
-
VIP에서 삭제된 패킷 수 및 그 이유
VIP가 99%의 CPU 사용률에서 실행
Rx 측 버퍼링의 결과 VIP는 99%의 CPU 사용률에서 실행됩니다.VIP는 아웃바운드 인터페이스의 txqueue 상태를 지속적으로 모니터링하며, 사용 가능한 버퍼가 있는 즉시 패킷을 cbus를 통해 txqueue에 복사합니다.
Rx-buffering이 발생할 때 VIP가 99%로 실행될 때 그 자체에는 아무런 경보성이 없습니다.VIP가 오버로드되었다는 의미는 아닙니다.VIP가 더 중요한 작업(예: 다른 스위치용 패킷)을 수신하면 CPU가 높은 영향을 받지 않습니다.
다음은 이 내용을 설명하기 위해 Lab에서 수행할 수 있는 간단한 테스트입니다.
직렬 2/0/0의 클럭 속도는 128Kbps이며 라인 레이트로 트래픽을 수신합니다.클럭 속도가 64Kbps인 Serial 10/0으로 트래픽이 전환되고 대기열 처리 전략은 FIFO입니다.유일한 옵션은 패킷을 삭제하는 것입니다.
router#show controller cbus MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0) RawQ 48000100, ReturnQ 48000108, EventQ 48000110 BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes) IpcbufQ 48000158 (24 items, 4096 bytes) IpcbufQ_classic 48000150 (8 items, 4096 bytes) 3570 buffer headers (48002000 - 4800FF10) pool0: 8 buffers, 256 bytes, queue 48000138 pool1: 2940 buffers, 1536 bytes, queue 48000140 pool2: 550 buffers, 4512 bytes, queue 48000160 pool3: 4 buffers, 4544 bytes, queue 48000168 slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192 software loaded from system IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) ROM Monitor version 122.0 Mx Serial(4), HW Revision 0x3, FW Revision 1.45 Serial2/0/0, applique is V.35 DCE received clockrate 2015232 gfreeq 48000140, lfreeq 480001D0 (1536 bytes) rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293 txq 48001A00, txacc 48001A02 (value 294), txlimit 294 Serial2/0/1, applique is V.35 DTE received clockrate 246 gfreeq 48000140, lfreeq 480001D8 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A08, txacc 48001A0A (value 6), txlimit 6 Serial2/0/2, applique is Universal (cable unattached) received clockrate 246 gfreeq 48000140, lfreeq 480001E0 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A10, txacc 48001A12 (value 6), txlimit 6 Serial2/0/3, applique is Universal (cable unattached) received clockrate 246 gfreeq 48000140, lfreeq 480001E8 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A18, txacc 48001A1A (value 6), txlimit 6 slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192 software loaded from system Serial10/0, applique is V.35 DTE gfreeq 48000140, lfreeq 48000208 (1536 bytes) rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1 txq 48000210, txacc 480000B2 (value 2), txlimit 294 Serial10/1, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000218 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000220, txacc 480000BA (value 6), txlimit 6 Serial10/2, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000228 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000230, txacc 480000C2 (value 6), txlimit 6 Serial10/3, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000238 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000240, txacc 480000CA (value 6), txlimit 6 Serial10/4, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000248 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000250, txacc 480000D2 (value 6), txlimit 6 Serial10/5, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000258 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000260, txacc 480000DA (value 6), txlimit 6 Serial10/6, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000268 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000270, txacc 480000E2 (value 6), txlimit 6 Serial10/7, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000278 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000280, txacc 480000EA (value 6), txlimit 6 router#
값 2는 두 개의 버퍼만 남아 있음을 의미합니다.txacc가 4보다 작으면 Rx-buffering이 MEMD의 패킷을 대기열에 넣지 않습니다.
VIP에서 show controllers vip 2 tech-support 명령은 CPU 99%에서 실행됨을 보여줍니다.
router#show controllers vip 2 tech-support show tech-support from Slot 2: ------------------ show version ------------------ Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Copyright (c) 1986-2000 by cisco Systems, Inc. Compiled Tue 18-Jul-00 22:03 by htseng Image text-base: 0x600108F0, data-base: 0x602E0000 ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes System returned to ROM by power-on Running default software cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory. Processor board ID 00000000 R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache 4 Serial network interface(s) Configuration register is 0x0 ... ------------------ show process cpu ------------------ CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69%
VIP는 128Kbps만 수신하더라도 CPU 사용률이 99%로 실행됩니다.이것은 CPU 사용률이 초당 패킷 수와 연결되지 않았음을 보여줍니다.이는 VIP 2가 이보다 많은 패킷을 전환할 수 있기 때문입니다.이것은 단순히 Rx 측 버퍼링의 표시입니다.
Rx 측 버퍼링이 수행하는 작업을 확인하려면 다음 명령을 실행합니다.
router#show controllers vip 2 accumulator
show vip accumulator from Slot 2:
Buffered RX packets by accumulator:
...
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x:
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
No MEMD acc: i in
Limit drops : j normal pak drops, k high prec pak drops
Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
Limit drops : o normal pak drops, p high prec pak drops
Buffer drops : q normal pak drops, r high prec pak drops
| 키 | 설명 |
|---|---|
| a | MEMD의 txacc 주소입니다.시스템의 각 txacc에 대해 Rx 측 버퍼 대기열이 1개 있습니다(최대 4096). |
| b | Rx 버퍼링된 패킷 수입니다. |
| c | VIP가 삭제한 패킷 수입니다.패킷 메모리 버퍼가 충분한 경우 VIP는 트래픽의 최대 1초까지 Rx 버퍼링을 수행할 수 있습니다.그러나 인터페이스가 계속 혼잡한 경우 삭제를 방지할 수 없습니다. |
| d | 현재 Rx-buffered인 패킷 수입니다. |
| e-메일 | 현재 Rx 버퍼링된 입자 수입니다.패킷은 여러 입자로 구성될 수 있습니다. |
| f | VIP 메모리가 낮을 때 최대 입자 수입니다. |
| g | 항상 사용할 수 있는 최대 입자 수입니다. |
| h | 보내는 인터페이스의 속도(kbps)입니다. |
| 난 | MEMD에서 사용할 수 있는 txacc가 없기 때문에 Rx 버퍼된 패킷 수입니다.즉, 출력 대기열이 혼잡합니다(tx-queue에서 사용 가능한 버퍼가 더 이상 없음). 이 문제의 해결 방법은 출력 인터페이스 대역폭을 늘리는 것입니다(가능한 경우). |
| j | MEMD acc가 없어 전송할 수 없는 6 또는 7 이외의 IP 우선 순위를 가진 패킷 수 및 입자의 소프트 또는 하드 제한에 도달하여 삭제됩니다. |
| k | j와 동일하지만 IP 우선 순위가 6 또는 7(인터네트워크 및 네트워크)인 패킷의 경우 |
| l | VIP가 Rx-buffer를 원하지만 패킷 메모리에 사용 가능한 버퍼가 없어 삭제된 IP 우선 순위가 6 또는 7이 아닌 패킷의 수.Cisco IOS Software 릴리스 12.0(13)S 및 12.1(4)에서 show controller vip [all / slot#] packet-memory-drops 명령을 사용하여 삭제된 패킷 수를 확인할 수도 있습니다.이 경우 패킷 메모리를 업그레이드하면 도움이 됩니다. |
| m | l과 동일하지만 IP 우선 순위가 6 또는 7(인터네트워크 및 네트워크)인 패킷의 경우 |
| n | MEMD 버퍼가 없으므로 VIP가 Rx-buffer를 시도하는 패킷 수입니다. 패킷 메모리 버퍼가 부족하여 이 작업을 수행할 수 없습니다.이 경우 패킷 메모리를 업그레이드합니다.Cisco IOS Software 릴리스 12.0(13)S 및 12.1(4)에서 show controllers [all / slot#] packet-memory-drops 명령을 사용하여 패킷이 삭제된 이유를 이해할 수도 있습니다. |
| o | 소프트(f) 또는 하드(g) 제한에 도달했기 때문에 삭제된 MEMD 버퍼가 없는 IP 우선 순위가 6 또는 7이 아닌 Rx 버퍼된 패킷 수입니다.이 경우 RSP16은 MEMD 메모리(RSP1, RSP2, RSP4 및 RSP7000의 경우 2MB와 8MB)가 더 많으므로 도움이 됩니다. 이 경우 일부 인터페이스(예: ATM, POS 또는 FDDI)의 MTU를 줄일 수도 있습니다.이러한 인터페이스에는 일반적으로 4470바이트 MTU가 있으며, 버퍼가 더 커야 하므로 할당할 수 있는 MEMD 버퍼가 더 적습니다. |
| p | o와 동일하지만 IP 우선 순위가 6 또는 7(인터네트워크 및 네트워크)인 패킷의 경우 |
| q | MEMD 버퍼가 없기 때문에 VIP가 Rx-buffer를 시도하는 6 또는 7을 제외한 IP 우선 순위를 가진 패킷 수입니다. 패킷 메모리 버퍼가 부족하여 이 작업을 수행할 수 없습니다.이 경우 패킷 메모리를 업그레이드하면 도움이 됩니다.Cisco IOS Software 릴리스 12.0(13)S 및 12.1(4)에서 show controllers [all / slot#] packet-memory-drops 명령을 사용하여 패킷이 삭제된 이유를 더 잘 이해할 수 있습니다. |
| r | q와 동일하지만 IP 우선 순위가 6 또는 7(인터네트워크 및 네트워크)인 패킷의 경우 |
라우터가 12.0(13)ST, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4) 12.1(4)AA 12.1(4)T 012.1(4)T 012.0(13) 또는 12.0(13) 또는 13(10) 또는 13)(12.0)10(13) 또는 12.0(13)10) SC는 show controller vip [all / slot#] 누적기의 출력에서 위의 버전을 간단하게 제공합니다.Rx 측 버퍼링 때문에 삭제된 패킷의 다른 IP 우선순위를 고려하지 않습니다.
출력은 다음과 같습니다.
Serial10/0: MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer No MEMD buf: 0 in, 0 limit drops, 0 no buffer Interface x: MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps No MEMD acc: i in, j+k limit drops, l+m no buffer No MEMD buf: n in, o+p limit drops, q+r no buffer
Rx측 버퍼의 예
예 1:슬롯 2의 VIP는 128Kbps의 트래픽을 수신하고 이를 직렬 10/0(64Kbps)으로 라우팅합니다.
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
-
여기서 544980 패킷은 성공적으로 Rx-buffered이고 2644182가 삭제됩니다.삭제된 2644182에서 80개의 패킷은 IP 우선 순위가 6 또는 7이었습니다.
-
126개의 패킷은 현재 Rx-buffered이며 378개의 입자를 사용합니다.
-
모든 패킷은 MEMD의 tx-queue에 사용 가능한 버퍼가 없기 때문에 Rx-buffered입니다.즉, 출력 인터페이스가 혼잡합니다.최대 Rx-buffered 패킷 수에 도달하기 때문에 드롭이 발생합니다.일반적인 솔루션은 아웃바운드 인터페이스 대역폭을 업그레이드하거나, 일부 트래픽을 다시 라우팅하여 아웃바운드 인터페이스가 덜 혼잡하도록 하거나, 일부 큐잉에서 덜 중요한 트래픽을 삭제할 수 있도록 하는 것입니다.
예 2:Rx 측 버퍼(삭제 제외).
ATM1/0:
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps
No MEMD acc: 85709 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 117795 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
-
이 예에서는 ATM 1/0이 혼잡하지만 패킷이 삭제되지 않으므로 85709 패킷이 Rx-buffered입니다.
-
VIP에서 MEMD 버퍼를 가져올 수 없으므로 117795 패킷이 Rx 버퍼링됩니다.삭제된 패킷이 없습니다.일반적인 해결책은 MTU 중 일부를 줄여 더 많은 MEMD 버퍼를 할당할 수 있도록 하는 것입니다.RSP8도 도움이 됩니다.
예 3:로컬 스위칭.
SRP0/0/0: local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps
로컬 txacc는 이 출력 인터페이스가 패킷이 수신되는 인터페이스와 동일한 VIP에 있음을 의미합니다.이러한 패킷은 로컬로 스위칭되지만 아웃바운드 인터페이스(이 경우 srp 0/0/0 )이 혼잡합니다.2529 패킷은 Rx-buffered이며 패킷은 삭제되지 않습니다.
예 4:대기열 전달.
router#show controllers vip 2 accumulator
Buffered RX packets by accumulator:
Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps
No MEMD buf: 142041 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 3 normal pak drops, 0 high prec pak drops
Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps
No MEMD buf: 68 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 414 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 46 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
일부 패킷은 배포 스위칭할 수 없습니다.이 경우 VIP는 패킷을 RSP의 원시 큐로 전달해야 하며, 이렇게 하면 스위칭이 결정됩니다.패킷을 MEMD로 즉시 복사할 수 없는 경우 VIP Rx는 패킷을 버퍼링하고 인바운드 인터페이스당 Rx 버퍼링된 패킷 수를 추적합니다.
정방향 대기열 0-7은 첫 번째 포트 어댑터(PA) 및 두 번째 PA의 경우 8-15입니다.
| 전달 대기열 번호 | ...에는 ...에서 수신된 Rx-buffered 패킷의 수가 나와 있습니다. |
|---|---|
| 0 | 첫 번째 포트 어댑터(PA)의 첫 번째 플러그 홀 |
| 8 | 두 번째 PA의 첫 번째 플러그 홀 |
| 9 | 두 번째 PA의 두 번째 플러그 홀 |
VIP에서 CPU 사용률이 높은 기타 원인
Rx 측 버퍼링이 비활성화된 경우 다음 요소 중 하나가 VIP에서 높은 CPU 사용률을 유발할 수 있습니다.
-
분산된 트래픽 셰이핑으로 인해 VIP에서 99% CPU 사용률
dTS(Distributed Traffic Shaping)가 구성된 경우, 하나의 패킷이 dTS 대기열에 진입하자마자 VIP CPU가 99%로 이동합니다.
이는 올바르고 예상되는 동작입니다.dTS가 구성되면 VIP CPU는 CPU가 사용 중이 아닌 경우(즉, 트래픽이 없는 경우) 다음 시간 간격(Tc)이 도착하는지 확인합니다. 그렇지 않은 경우 검증은 tx/rx 인터럽트 루틴에서 piggybacked됩니다.CPU는 사용 중이 아닌 경우에만 회전합니다.따라서 성능에 영향을 미치지 않습니다.
"다음 시간 간격"이 의미하는 것을 이해하려면 토큰 버킷이란 무엇입니까?
참고: 트래픽 셰이핑은 셰이핑 대기열에 패킷을 추가해야 하는 경우에만 활성화됩니다.즉, 트래픽 양이 셰이핑 속도를 초과할 경우따라서 dTS를 구성할 때 VIP CPU가 항상 99%는 아닌 이유를 알 수 있습니다.dTS에 대한 자세한 내용은 다음을 참조하십시오.
-
메모리 액세스 및 정렬 오류로 인해 VIP에서 높은 CPU 사용률
정렬 오류 및 잘못된 메모리 액세스는 VIP를 손상시키지 않고도 Cisco IOS 소프트웨어에 의해 수정된 소프트웨어 장애입니다.이러한 오류가 자주 나타나는 경우 운영 체제가 많은 수정을 수행하여 CPU 사용률이 높아질 수 있습니다.
정렬 오류 및 잘못된 메모리 액세스에 대한 자세한 내용은 잘못된 액세스 문제 해결, 맞춤 오류 및 잘못된 인터럽트 문제 해결을 참조하십시오.
잘못된 메모리 액세스 및 정렬 오류를 확인하려면 show alignment 명령을 사용합니다.이러한 오류의 예는 다음과 같습니다.
VIP-Slot1#show alignment No alignment data has been recorded. No spurious memory references have been recorded.
CPU 사용률이 높은 다른 원인은 활성화된 분산 기능의 양과 범위일 수 있습니다.이유가 될 수 있다고 생각되거나 이 문서에서 설명한 CPU 사용률 증가 원인을 확인할 수 없는 경우 Cisco TAC(Technical Assistance Center)에서 서비스 요청을 엽니다.
TAC 서비스 요청을 열 경우 수집할 정보
| 위의 트러블슈팅 단계를 수행한 후에도 지원이 필요한 경우 Cisco TAC에 서비스 요청(등록된 고객만 해당)을 열려면 다음 정보를 포함해야 합니다. |
|---|
참고: 위의 정보를 수집하기 전에(네트워크 작업을 복원하는 데 필요하지 않은 경우) 라우터를 수동으로 다시 로드하거나 전원을 껐다가 다시 켜지 마십시오. 이렇게 하면 문제의 근본 원인을 확인하는 데 필요한 중요한 정보가 손실될 수 있습니다. |
피드백