Cisco インターフェイスとモジュール : Cisco 多用途インターフェイス プロセッサ

利用率 99 % で動作する VIP CPU および Rx サイド バッファリングについて

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 3 月 1 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、Versatile Interface Processor(VIP)CPU が 99 %で動作する理由と、Rx サイド バッファについて説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

Rx サイドバッファリングはアウトバウンドインターフェイス時プロセスです発生する:

  • 混雑させます。

  • 戦略を並べる First In First Out (FIFO; 先入れ先出し)を使用します。

受信 Versatile Interface Processor (VIP)はパケットをすぐに廃棄しません。 その代り、それはバッファが発信インターフェイスに利用できるまでパケットメモリのパケットをバッファリングします。 VIP の種類に基づいて、パケットメモリはスタティックRAM (SRAM)または同期ダイナミックRAM (SDRAM)のどれである場合もあります。

Cisco 7500 シリーズ アーキテクチャの基礎

各インターフェイスプロセッサ(レガシー IP か VIP)は CyBus と呼ばれる高速拡張システムバスへの 1 つの接続を備えています。 Route/Switch Processor (RSP)は 2 CyBuses に接続されます(図を 1)参照して下さい。

図 1 – Cisco 7500 シリーズ アーキテクチャ

buffering_rx1.gif

buffering_rx2.gif

パケットバッファ の タイプ

このセクションはさまざまなパケットバッファ の タイプを記述します。

Rx サイドバッファリングのステータスをチェックする show controllers vip accumulator コマンドを使用して下さい。 ステータスは示します:

  • アウトプットインターフェイスの数はルータで示します。

  • 何パケット VIP にこれらのインターフェイスのための Rx-buffered があるか。

  • VIP に Rx-buffered がなぜあるか。

  • VIP がドロップしたパケットの数、およびその理由

99% CPU稼働率の VIP 実行

Rx サイドバッファリングにより、最終的に VIP が 99% の CPU 利用率で動作します。 VIP は絶えずアウトバウンドインターフェイスの txqueue のステータスを監察し、解放されたバッファがあるとすぐ、txqueue に cbus 上のパケットをコピーします。

Rx バッファリングが発生するとき VIP が 99% で動作するときそれ自体警告する何もありません。 VIP が過負荷になっていないことを意味します。 VIP がより優先度の高いもの(たとえば、スイッチングすべき別のパケット)を受信した場合、高 CPU 稼働率の影響は受けません。

これを説明するためにラボですることができる簡単 な テストはここにあります:

シリアル 2/0/0 に 128 キロビット/秒のクロック レートがあり、行比率でトラフィックを受信します。 トラフィックはシリアル 10/0 にクロック レートが 64 キロビット/秒である、キューイング 戦略は 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 つのバッファだけ残されることを値 2 は意味します。 Rx バッファリングは txacc が 4.より小さいとき MEMD のパケットをキューに入れません。

VIP からの show controllers vip 2 tech-support コマンドは 99% CPU で動作することを示します:

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 は 99% CPU稼働率で 128 キロビット/秒だけ受け取るのに動作します。 これは 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 に 1 つの Rx サイドバッファ キューがあります(最大 4096)。
b パケットの数 Rx-buffered である。
c VIP が廃棄したパケットの数。 パケットメモリバッファが十分ある場合、VIP は Rxバッファ トラフィックの 1秒までできます。 しかし、インターフェイスが継続的に輻輳状態にある場合、ドロップを回避することは不可能です。
d 現在 Rx バッファリングされているパケットの数。
e 現在 Rx バッファリングされているパーティクルの数。 パケットには複数のパーティクルが含まれる場合があります。
f VIP メモリが低い時パーティクルの最大数であるソフト制限。
g いつでも使用できるパーティクルの最大数であるハードな制限。
h 出力インターフェイスのスピード(kbps)。
i MEMD で txacc が使用できなかったために Rx バッファリングされたパケットの数。 これは出力キューが混雑したことを意味します(これ以上の解放されたバッファは tx-queue で利用できません)。 この問題へのソリューションはアウトプットインターフェイス 帯域幅を増加することです(もし可能なら)。
j MEMD acc がないので送信できなかった 7 か 6 以外の IP 優先順位のパケットの数は、およびパーティクルのソフトかハードな制限が達したので廃棄されます。
k IP 優先順位 6 または 7 のパケットのための j と同じ、しかし(インターネットワークおよびネットワーク)。
l VIP は Rxバッファにほしいと思う 7 か 6 以外の IP 優先順位の解放されたバッファの欠如によるパケットの数、パケットメモリのドロップ。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、また廃棄されるパケットの数を見る show controller vip [すべて/slot#] packet-memory-drops コマンドを使用し。 この場合、パケット メモリのアップグレードが役立ちます。
m IP 優先順位 6 または 7 のパケットのための l と同じ、しかし(インターネットワークおよびネットワーク)。
n MEMDバッファがない試みたり、しかしパケットメモリの不足バッファがそう原因ですることができないので VIP が Rxバッファにパケットの数。 パケットメモリをこの場合アップグレードして下さい。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、またパケットがなぜ廃棄されたか理解する show controllers vip [すべて/slot#] packet-memory-drops コマンドを使用し。
o MEMDバッファ無しの 6 かソフト(f)かハードな(g)制限が達したので廃棄される 7 以外の IP 優先順位の Rx-buffered パケットの数。 この場合、RSP16 はそれ以上の MEMD メモリ(RSP1、RSP2、RSP4 および RSP7000 のための 2 MB と比較される 8 MB)があるので助けます。 またいくつかのインターフェイスの MTU を(ATM、POS、または FDDI のような)この場合減らすことができます。 これらのインターフェイスに通常 4470 バイト MTU があり、バッファがより大きくなければならないので少数の MEMD バッファは割り当てることができます。
p IP 優先順位 6 または 7 のパケットのための o と同じ、しかし(インターネットワークおよびネットワーク)。
q MEMDバッファがないので VIP が Rxバッファに試みる 7 か 6 以外の IP 優先順位のパケットの数は、しかしパケットメモリの不足バッファがそう原因ですることができません。 パケットメモリのアップグレードはこの場合助けます。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、またよりよくパケットがなぜ廃棄されたか理解する show controllers vip [すべて/slot#] packet-memory-drops コマンドを使用し。
r IP 優先順位 6 または 7 のパケットのための q と同じ、しかし(インターネットワークおよびネットワーク)。

ルータが 12.0(13)ST 以前の Cisco IOS ソフトウェア バージョンを実行する場合 12.1(04)DB、12.1(04)DC、12.0(13)S、12.1(4) 12.1(4)AA 12.1(4)T 012.0(13)、または 12.0(13)SC は、show controllers vip [すべて/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 のパケットに 6 か 7.の IP 優先順位がありました。

  • 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 
  • この例では、85709 のパケットは ATM 1/0 が混雑するが、パケットが廃棄されないので Rx-buffered です。

  • 117795 のパケットは VIP が MEMDバッファを得ることができないので Rx-buffered です。 パケットは廃棄されません。 典型的なソリューションはより多くの MEMD バッファが割り当てることができるようにいくつかの MTU を減少させることです。 また 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 の rawキューにパケットを転送しなければなりません。 パケットが MEMD にすぐにコピーすることができないとき VIP Rx バッファはそれらインバウンドインターフェイスごとの Rx-buffered は何パケットであるか把握し。

フォワーディング キュー 0~7 は第 1 ポート アダプタ(PA)用、8~15 は第 2 PA 用です。

フォワーディング キュー番号 …で…受信される Rx-buffered パケットの数を示します
0 1番目の ポート アダプタ(PA)の第 1 プラグホール
8 2番目のPA の第 1 プラグホール
9 2番目のPA の第 2 プラグホール

VIP においてCPU 利用率が高い数値を示す他の原因

Rx サイドバッファリングが非アクティブであるために確認されているときこれらのファクタの 1 により VIP の CPU使用率が高い状態を引き起こす場合があります:

  • Distributed Traffic Shaping によって引き起こされる VIP の 99% CPU稼働率

    Distributed Traffic Shaping (DTS)が設定されるとき、VIP CPU は 99% に 1 パケットが dTS キューを入力するとすぐ跳びます。

    これは正しいおよび予期された動作です。 dTS が設定されるときチェックするために、トラフィックがないとき) CPU が使用中ではないと間隔(Tc)が着く時次に VIP CPU はかどうか回ります(すなわち。 さもなければ、確認は tx/rx 割り込みルーチンで便乗されます。 使用中のときだけ 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 Technical Assistance Center (TAC)とのサービス リクエストを開きなさい。

TAC のサービスリクエストをオープンする場合に収集すべき情報

上記のトラブルシューティング の 手順に従った、Cisco TAC のサービス リクエスト登録ユーザのみ)を開きたいと思う後更にアシスタンスを必要としたらこの情報を含むこと確実でであって下さい:
  • show controllers vip [すべて/slot#]アキュムレータ コマンドからの出力
  • 関連した RSP および VIP からの show technical-support コマンドからの出力
収集したデータは、圧縮しないプレーン テキスト形式(.txt)でサービス リクエストに添付してください。 情報をサービス リクエストに添付するには、TAC Service Request Tool登録ユーザ専用)を使用してアップロードします。 Service Request Tool にアクセスできない場合サービス リクエストに関連情報を一緒に送ることができメッセージの件名にサービス リクエスト数を記入して attach@cisco.com にそれを送信 します。

これが問題の根本的な原因を判別するために必要である重要な情報を失います場合があるので(リストア ネットワーク オペレーションに必要とされて)上の情報を収集する前に手動で ルータをリロードしましたり、またはパワーサイクルを行わないで下さい。


関連情報


Document ID: 12810