シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、ルータでの show interfaces コマンドの出力に示される入力キュー ドロップと出力キュー ドロップについて説明します。このドキュメントでは、これらのドロップの意味、それらが示す問題の種類、問題の原因のトラブルシューティング方法をついて説明しています。また、これらの問題を防ぐためのヒントについても説明しています。
注:ドロップは上位層プロトコルのフロー制御メカニズムをトリガーするため(たとえば、ドロップはTCPウィンドウサイズを小さくする)、便利です。
このドキュメントに関しては個別の要件はありません。
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
IP ネットワークでは、ルータはルーティング テーブルの内容に基づいて転送決定を行います。ルーティング テーブルの検索では、ルータは宛先 IP アドレスの最長一致を検索します。ルータはこの処理をプロセス レベルで実行します。したがって、検索プロセスは他のCPUプロセスの間でキューに入れられます。そのため、検索時間は予測不可能であり、非常に長くなる可能性があります。そのため、exact-match-lookupに基づくスイッチング方式がCisco IOS®ソフトウェアで導入されています。
完全一致検索法の最大の利点は、検索時間が決まっており、非常に短いことです。この処置により、ルータが転送決定を行うために必要な時間が大幅に短縮しました。そのため、検索を実行するルーチンを割り込みレベルで実装できます。つまり、パケットの到着により割り込みが生成されるので、CPU では他のタスクを後回しにしてパケットを処理できます。従来のパケット転送方法では、ルーティング テーブルで最もよく一致するものが検索されています。この方法は割り込みレベルでは実装できないので、プロセス レベルで実行する必要があります。このドキュメントでも一部説明していますが、多くの理由により「最長一致検索」方式を完全に放棄することはできないため、Cisco ルータでは、これら 2 つの検索方式が共存しています。この戦略は一般的なものとなっており、現在は IPX と AppleTalk にも適用されています。
Cisco IOS ソフトウェアのスイッチング パスの詳細は、『パフォーマンス チューニングに関する基本事項』を参照してください。
パケットがルータに到着すると、ルータはそれを割り込みレベルで転送しようとします。該当するキャッシュ テーブル内に一致するものが見つからない場合、そのパケットはプロセス処理のために入力インターフェイスの入力キューに入れられます。一部のパケットは常にプロセス処理されていますが、設定が適切でネットワークが安定していれば、プロセス処理されるパケットで入力キューがいっぱいになることはありません。入力キューがいっぱいになると、パケットは廃棄されます。
次に出力例を示します。
router#show interfaces ethernet 0/0 ... Input queue: 30/75/187/0 (size/max/drops/flushes); Total output drops: 0 Output queue :0/40 (size/max)...
この出力例で、どのパケットがドロップされたかを正確に知る方法はありません。入力キュー ドロップをトラブルシューティングするには、入力キューに入っているパケットを確認する必要があります。この例では、show interfaces ethernet 0/0 コマンドが発行された時点では、イーサネット 0/0 というインターフェイスの入力キューに 30 個のパケットがあります。キューの深さは 75 パケットであり、インターフェイス カウンタが最後にクリアされてから 187 個のドロップがありました。
インターフェイスに割り当てられているパケット バッファの数が使い切られるか最大しきい値に達すると、システムにより入力キュー ドロップがカウントされます。最大キュー値を増やすには、各インターフェイスのhold-queue <value>コマンドを使用します(キュー長の値は0 ~ 4096です。デフォルト値は75)。
注:共有メモリルータ(1600、2500、および4000シリーズ)では、ファストスイッチトラフィックにも入力キューを使用します。これらのプラットフォームで入力キュー ドロップがあった場合は、すべてのトラフィックで利用可能な最適のスイッチングパスが使用されていることを確認してください(『パフォーマンス チューニングに関する基本事項』を参照)。 一般に、パケットがプロセス スイッチングされると入力キュー ドロップが発生します。プロセス スイッチングが行われるということは、ルータでは、ファスト スイッチングや Cisco Express Forwarding(CEF)などのより望ましいルート キャッシュ方式を、転送決定の処理に使用できないということになります。入力ドロップが引き続き発生する場合は、単にトラフィックが多すぎる可能性があります。ハードウェアのアップグレードもしくはトラフィック ロードを減らすことを検討してください。
入力キュー ドロップ カウンタに対する条件は、次のとおりです。通常、これらの条件が発生するのは、ルータがバースト トラフィックを受信してすべてのパケットを制御できない場合です。
インターフェイス PHY およびインターフェイス DMA からアクセス可能な Rx FIFO がいっぱいの場合。このときに新しいフレームが到達すると、このフレームはドロップされ(通常は、オーバーフローと呼びます)、rx_overflow カウンタ(show controller interface-id で確認できます)が増分されます。rx_overflow カウンタが 1 増分された場合、これはドロップされたフレーム数ではなく、オーバーフロー条件が 1 回発生したことを示します。
インターフェイス DMA およびインターフェイス ドライバ コードからアクセス可能な Rx リングがいっぱいの場合。Rx リングに空きエントリがないため、この条件の場合は DMA からの新しいフレーム転送を続行できません。したがって、送信されたフレームはドロップされます(オーバーラン条件と呼びます)。 また、rx_int_drop カウンタ(show controller interface-id で確認できます)も 1 ずつ増分されます。ここでもまた、rx_int_drop が 1 増分された場合、これはオーバーラン条件が 1 回発生したことを示します。ドロップされたフレーム数は不明です。
入力待機キューのサイズは、デフォルトの 75 パケットより大きくできます。待機キューには、ネットワークから受信され、クライアントへの送信を待っているパケットが格納されます。非同期インターフェイスでは、キューのサイズが 10 パケットを超えないようにすることを推奨します。他のほとんどのインターフェイスでは、キューの長さは100を超えることはできません。入力保留キューは、1つのインターフェイスが入力パケットの数が多すぎるネットワークサーバをフラッディングするのを防ぎます。システムで未処理の入力パケットがインターフェイスに大量に存在する場合、後続の入力パケットは廃棄されます。
Router(conf-if)# hold-queue length in
Catalyst スイッチの場合は、デバイス上のすべての L3 インターフェイス(物理インターフェイスと VLAN インターフェイスの両方)に対し、この調整を行うことを推奨いたします。switchport コマンドを使用して設定されている L2 ポートは、デフォルト値のままにしておくことができます。
注:このコマンドを適用したら、インターフェイスカウンタをクリアしてから、ネットワークを監視する必要があります。
注意:待機キューが増加すると、ネットワーク ルーティングと応答時間に悪影響がもたらされることがあります。SEQ/ACK パケットを使用してラウンドトリップ時間を確認するプロトコルでは、出力キューは増加しません。パケットをドロップする代わりに、使用可能な帯域幅に合わせて転送速度を落とすよう、ホストに通知します。これは、大量の待機キューが発生する可能性のある、ネットワーク内で同一パケットの重複コピーを作成することよりも通常は優れています。
入力キュー ドロップのトラブルシューティングを正しく行うには、入力キューに絶えずパケットが到着する状態である必要があります。過去に発生した輻輳はトラブルシューティングできません。複数のルーティッド プロトコルがインターフェイスに設定されている場合は、まず、入力キューに輻輳を発生させているプロトコルを特定します。これを最も速く行うには、次のように行います。
疑いのあるプロトコルを特定します。<protocol>入力プロセスのCPU使用率を確認します。これは、show processes cpu exec コマンドを発行して確認してください。Cisco IOS ソフトウェア バージョン 12.1 以降がルータで稼働中の場合は、出力修飾子を使用することにより show processes CPU コマンドの出力を短縮できます。
router#show processes CPU | i ^PID|Input PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 10 8503 1713 4963 0.00% 0.00% 0.00% 0 ARP Input 24 69864 11429 6112 0.08% 0.11% 0.10% 0 Net Input 28 55099 8942 6161 26.20% 20.07% 19.26% 0 IP Input 37 4 2 2000 0.00% 0.00% 0.00% 0 SSCOP Input 40 8 2 4000 0.00% 0.00% 0.00% 0 ILMI Input 49 8 1 8000 0.00% 0.00% 0.00% 0 Probe Input 50 28209 4637 6083 0.00% 0.03% 0.04% 0 RARP Input 59 8 2 4000 0.00% 0.00% 0.00% 0 SPX Input 61 8 2 4000 0.00% 0.00% 0.00% 0 Tag Input 68 20803 3392 6132 0.00% 0.03% 0.00% 0 IPX Input 104 4 1 4000 0.00% 0.00% 0.00% 0 IPXWAN Input 107 8 1 8000 0.00% 0.00% 0.00% 0 AT Input
表 1 は、入力キューに輻輳を発生させる可能性のある入力プロセスとパケットの種類を示しています。
CPU サイクルを使用している入力プロセス | パケットの種類 |
---|---|
IP | IP |
AT | AppleTalk |
IPX、SPX、またはIPXWAN | IPX |
ARP | IP ARP |
その他の入力プロセスは、入力キューをいっぱいにするおそれはありません。
入力キューに輻輳を発生させているパケットがルータ宛のものか、ルータ経由で転送されるものかを調べます。show interfaces [type number] switching コマンドを exec モードで発行します。
注:show interfaces [type number] switchingコマンドは非表示で、「?」を使用しても表示されません。 またはコマンドラインインターフェイスでTabキーを使用します。コマンド全体をルータで入力してください。このコマンドは『コマンド リファレンス ガイド』には記載されていません。
router#show interfaces ethernet 0/0 switching Ethernet0/0 ... Protocol Path Pkts In Chars In Pkts Out Chars Out ... IP Process 12142 2211929 35 5169 Cache misses 10212 ...
プロセス処理された受信パケット数の後に表示されるキャッシュ ミスの数値が大きくなっていないかどうかを確認します。大きな数値が表示されている場合、入力キューに輻輳を発生させているパケットはルータ経由で転送されることを示しています。それ以外の場合、そのパケットの宛先はそのルータ自体です。
パケットがルータ宛の場合は、どの上位レイヤ プロトコルにより入力キューに輻輳が発生しているのかを確認します。そのためには、次の show traffic exec コマンドのいずれかを使用します。
show ip traffic
show ipx traffic
show appletalk traffic
注:これらのコマンドは、表1に示す入力プロセスのいずれかが疑われる場合にのみ適用されます。
入力キューに輻輳を発生させているパケットに関する情報をさらに取得します。そのためには、受信したパケットをデバッグする必要があります。有効にする必要がある debug コマンドは、前のステップの出力結果から判断願います。
注:前の手順を実行しなくても、これを直接実行できます。ただし、デバッグ時には、複数のメッセージが生成されるので判読が難しい場合があります。前記の手順すべてを実行すれば、デバッグ出力の何を見ればよいのかがわかります。
警告:デバッグには細心の注意を払ってください。そうしなければ、CPU 使用率が大幅に上昇する可能性があります。5 ~ 10 秒を超えてデバッグをオンにしないでください。デバッグ コマンドの使用方法については、『debug コマンドの使用方法』を参照してください。コンソール ログ、ターミナル ログ、および syslog サーバのログは無効にしないでください。バッファ ログを有効にして、ロギング バッファ サイズを増やしてください。ロギング バッファ サイズの推奨値は、128000 バイトです。次のコマンドを使用します。
no logging <host>
logging buffered 128000 debugging
この出力で問題の原因を十分に特定できます。デバッグ セッションを完了したら、show log コマンドでデバッグ出力を確認できます。表 2 には、入力キューに輻輳を発生させているパケットの種類に基づいて、どの debug コマンドを発行するかが示されています。
入力キューに輻輳を発生させているパケットの種類 | 使用するデバッグ コマンド |
---|---|
IP | debug ip packet |
AppleTalk | debug apple packet |
IPX | debug ipx packet |
ARP | debug arp |
詳細は、『Cisco IOS Debug コマンド リファレンス』を参照してください。
他の方法としては、show buffers input-interface [interface type] [interface number] header コマンドを使用して、入力キューに輻輳を発生させているパケットの種類を確認できます。
注:これは、入力キューに多数のパケットがある場合にのみ便利です。
Router#show buffers input-interface serial 0/0 Buffer information for Small buffer at 0x612EAF3C data_area 0x7896E84, refcount 1, next 0x0, flags 0x0 linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0 if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None) inputtime 0x0, outputtime 0x0, oqnumber 65535 datagramstart 0x7896ED8, datagramsize 728, maximum size 65436 mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0 network_start 0x7896ED8, transport_start 0x0 source: 212.176.72.138, destination: 212.111.64.174, id: 0xAAB8, ttl: 118, prot: 1 Buffer information for Small buffer at 0x612EB1D8 data_area 0x78A6E64, refcount 1, next 0x0, flags 0x0 linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0 if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None) inputtime 0x0, outputtime 0x0, oqnumber 65535 datagramstart 0x78A6EB8, datagramsize 728, maximum size 65436 mac_start 0x78A6EB8, addr_start 0x78A6EB8, info_start 0x0 network_start 0x78A6EB8, transport_start 0x0 source: 212.176.72.138, destination: 212.111.64.174, id: 0xA5B8, ttl: 118, prot: 1
ほとんどの場合、1 つの種類のパケット数に大きな値が表示されます。この例では、数個の Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)パケット(IP プロトコル 1)があります。
ルータの設定が正しくないという問題の場合(たとえば、ファスト スイッチングと Cisco Express Forwarding(CEF)の両方が無効になっている場合)、debug コマンドや show buffers input-interface コマンドには特定のパターンがないのが普通です。
入力キューに輻輳を発生させているパケットの種類を特定したら、次のステップで、その輻輳を防ぐことができるかどうかを調べます。
次のように、パケットにプロセス処理が必要になる理由がいくつかあります。
不適切なルータ設定:割り込みレベルで機能するスイッチング パスが該当インターフェイス上で無効になっている。
インターフェイスに設定されているスイッチングパスを確認するには、show <protocol> interface [type number]コマンドを実行します。
従来型のファスト スイッチングを有効にするには、出力インターフェイスにファスト スイッチングを設定します。
ネットフロー スイッチングを有効にするには、入力インターフェイスにネットフロー スイッチングを設定します。
Cisco Express Forwarding(CEF)を有効にするには、グローバル(ルータ全体)とローカル(入力インターフェイス上)で CEF を有効にする必要があります。
詳細は、『Cisco IOS スイッチング サービス コンフィギュレーション ガイド』を参照してください。
ローカルの宛先:パケットがルータ宛になっている。
安定したネットワークでは、ルーティング アップデートの数が過剰になることはありません。不安定なネットワークでは、大規模なルーティング テーブルの頻繁なアップデートにより入力キューに輻輳が発生する可能性があります。
過剰なトラフィックが(たとえば、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)、telnet、Trivial File Transfer Protocol(TFTP; トリビアル ファイル転送プロトコル)、ping などを使用して)ルータ自体に向けられたかどうかを調べます。 該当するプロトコルのパケットをデバッグしてパケットの送信元を特定します。送信元を特定したら、その送信元を排除します。
信頼性の高い Open System Interconnection(OSI)レイヤ 2 プロトコルが転送に使用される:X.25 プロトコル スイートではフロー制御が OSI のレイヤ 2 で実装されているため、X.25 カプセル化を使用してシリアル インターフェイスを通過するパケットにはプロセス処理が必要です。
ソフトウェア圧縮:ソフトウェア圧縮が設定されているインターフェイスを通じてパケットが着信するか転送する必要がある場合、そのパケットにはプロセス処理が必要です。
割り込みレベルでサポートされていない他の機能:この場合は、ルータで稼働している Cisco IOS ソフトウェアのリリースによって状況が大きく異なります。どの機能が割り込みレベルでサポートされているかは、リリース ノートで確認してください。たとえば、古い Cisco IOS ソフトウェア バージョンの場合、multilink PPP パケットはプロセス処理する必要があります。新しい Cisco IOS ソフトウェア バージョンの場合には、そのパケットはファストスイッチングするか CEF スイッチングすることができます。暗号化、local-area transport(LAT)変換、および data-link switching plus(DLSW+; データリンク スイッチング プラス)などの機能は、まだファストスイッチングされません。
各パケット ヘッダー内に異なる情報が意図的に使用されている過剰なトラフィックがルータを通過する:設定されたスイッチング パスに基づいて、ある宛先に対する最初のパケットまたはフロー内の最初のパケットは常にプロセス処理されます。このように処理されるのは、一致するエントリがキャッシュにないためです。非常に高いレートでデバイスがパケットを送信し、キャッシュ内に一致するエントリがない場合は、これらのパケットにより入力キューに輻輳が発生する可能性があります。
デバッグ セッションを経て、そのパケットの送信元が判明します。送信元アドレスが常に異なる場合、パケットの転送元の上流デバイスでトラブルシューティングを続ける必要があります。ルータのインターフェイスがブロードキャスト メディアに接続されている場合、送信元またはアップストリーム デバイスの Media Access Control(MAC; メディア アクセス制御)アドレスを特定できます。
ip accounting mac-address input インターフェイス設定コマンドで、インターフェイスに MAC アカウンティングを設定します。その後に、show interfaces mac-accounting exec コマンドを発行します。このコマンドによって、過度なレートでパケットを送信した MAC アドレスが判明します。
出力キューでの廃棄はインターフェイスの輻輳によって発生します。たとえば、発信インターフェイスのトラフィック レートでは、発信する必要があるすべてのパケットを受け入れられないような場合です。この問題を解決する最善の方法は、回線速度を上げることです。ただし、回線速度を上げたくない場合に、出力の廃棄を防止、減少、または制御する方法があります。出力廃棄の防止は、短時間のデータ バーストの結果として出力廃棄が発生している場合にだけ可能です。恒常的な高レートのフローによって出力の廃棄が引き起こされている場合、廃棄を防ぐことはできません。ただし、出力廃棄を制御することはできます。
パケットがプロセス処理される際には、出力インターフェイスの出力キューにパケットが送られます。show interfaces exec コマンドを実行すると、キューのサイズ、キューにある現在のパケット数、およびドロップ数が表示されます。インターフェイスの種類と設定されているキューイングの種類によっては、出力キュー ドロップ数が明確に表示されません。これは、出力ドロップ カウンタが、プロセス処理レベルと割り込みレベルで別々に出力ドロップ数を要約するためです。
router#show interfaces serial 0/0 ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) ... router#show interfaces serial 0/0 ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) ...
ただし、パケットのプロセス処理は、出力キューから回線にパケットを送信するよりも時間がかかります。そのため、割り込みレベルでのドロップが発生せずに、出力キュー ドロップ(プロセス レベルでのドロップ)が発生する可能性はほとんどありません。出力キュー ドロップが発生するのは、割り込みレベルでインターフェイスの輻輳がすでに発生しているために、出力キューがいっぱいになるまでは出力キューからパケットを取り出せない場合だけです。したがって、プロセス レベルでの出力ドロップ(出力キュー ドロップ)と割り込みレベルでの出力ドロップは必ず一緒に発生し、これら 2 つのカウンタを区別する必要は特にありません。
注:ただし、1 つ例外があります。出力キューが常にいっぱいで、インターフェイスからまったくパケットが送出されていない場合は、インターフェイスのハードウェア障害を調べる必要があります。
次の機能の設定を調整すれば、出力ドロップを減らすことができ、場合によっては防止できます。
デュプレックス モード:インターフェイスが半二重モードで動作している場合、(可能であれば)全二重で動作するように設定します。
レイヤ 2 ウィンドウ メカニズム:x.25 のカプセル化がインターフェイスに設定されている場合は、x.25 のウィンドウ サイズを増やします。詳細は、『デフォルト ウィンドウ サイズの設定』を参照してください。
分散スイッチング:Cisco 7500 ルータでは、シャーシに Versatile Interface Protocol(VIP)カードが取り付けられている場合、分散スイッチングを有効にします。この機能を有効にすると、発信インターフェイスで輻輳が発生している場合には、そのインターフェイスの最大 1 秒間のトラフィックが受信 VIP でバッファリングされます。この機能は rx サイド バッファリングと呼ばれます。
注:出力ドロップを防ぐために出力キューを増やさないでください。これによりパケットが出力キューに留まる時間が長くなりすぎると、TCP タイマーで期限切れが発生して再送信の原因となる場合があります。再送信されたパケットにより、出力インターフェイスの輻輳がさらに悪化するだけです。
推奨どおりにルータ設定のを調整しても、出力ドロップが引き続き発生する場合、出力ドロップの防止や削減は不可能です。ただし、出力ドロップを制御することはでき、防止するのと同じくらい効果的な場合があります。出力ドロップを制御するには、次の 2 つの方法があります。
輻輳管理
輻輳回避
両方ともトラフィックの分類に基づいた方法なので並行して使用できます。
輻輳管理は、適切な設定によって、リンクの輻輳が発生した場合に重要なパケットは必ず転送され、あまり重要でないパケットはドロップされるようにする方法です。輻輳管理は、次のような高度なキューイング メカニズムを利用して行います。
プライオリティキューイング
輻輳回避は、意図的なパケット ドロップに基づいて行います。TCP 接続時のウィンドウ サイズはラウンドトリップ時間によって異なります。そのため、意図的にパケットをドロップすると、送信元デバイスがパケットを送信する速度が遅くなります。輻輳回避では、重み付けランダム早期検出を使用しています。
これらのメカニズムを実装しても、まだ望ましくない出力ドロップが発生する場合には、回線速度を上げる必要があります。
次のコマンドを発行すれば、キューのドロップに関する詳細情報が得られます。
show interfaces switching
show interfaces stats
ip accounting mac-address
show interfaces mac-accounting
ご使用のシスコデバイスのshow interfacesコマンドの出力がある場合は、Cisco CLI Analyzerを使用して、潜在的な問題と修正を表示できます。Cisco CLI Analyzer を使用するには、登録ユーザとしてログインする必要があり、また、JavaScript を有効にする必要があります。
このコマンドは、インターフェイスで送受信されたパケットの数を、スイッチング パスごとに分類して表示します。これは隠しコマンドです。
show interfaces [type number] switching
Ethernet0/0 Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 0 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 86 Drops 0 Protocol Path Pkts In Chars In Pkts Out Chars Out Other Process 75 6728 79 4740 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 IP Process 142 11929 35 5169 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 AppleTalk Process 0 0 25 1635 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 DEC MOP Process 0 0 2 154 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 ARP Process 56 3580 13 780 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 CDP Process 90 26906 27 8900 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0
フィールド | 定義 |
---|---|
<protocol>プロセス | プロセス処理したパケットの数。この項目には、ルータ宛のパケットと、該当するスイッチング キャッシュ テーブル内にエントリがないパケットが含まれます。 |
Cache misses | プロセス レベルで転送されるパケット(ファスト スイッチング キャッシュ内にエントリがないもの)。 |
Fast | 割り込みレベルで転送されたパケット。 |
このコマンドは show interfaces switching コマンドと似ており、プロセス スイッチングされたパケット数、ファスト スイッチングされたパケット数(すべてのファスト スイッチング パス)、および分散スイッチングされたパケット数(VIP 対応プラットフォームの場合)に関する情報が表示されます。 これは隠しコマンドです。
show interfaces [type number] stats
Router#show interfaces stats FastEthernet8/0/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 64 38646 323 32790 Route cache 477985 611343050 14815 18948150 Distributed cache 0 0 3564 4558356 Total 478049 611381696 18702 23539296 Serial12/0/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 37 3783 36 2299 Route cache 14815 18800000 45118 59862772 Distributed cache 3450 4378520 0 0 Total 18302 23182303 45154 59865071 Interface Serial12/0/1 is disabled ...
これはインターフェイス設定コマンドです。受信または送信されたパケットのアカウンティングを、送信元または宛先 MAC アドレスごとに設定します。
ip accounting mac-address {input|output}
これは exec コマンドです。送受信されたパケットの数が、宛先と送信元 MAC アドレスごとに分類して表示されます。
show interfaces [type number] mac-accounting
router#show interfaces ethernet 0/0 mac-accounting Ethernet0/0 Input(494 free) 0000.0c5d.92f9(58 ): 1 packets, 106 bytes, last: 4038ms ago 0004.c059.c060(61 ): 0 packets, 0 bytes, last: 2493135ms ago 00b0.64bc.4860(64 ): 1 packets, 106 bytes, last: 20165ms ago 0090.f2c9.cc00(103): 12 packets, 720 bytes, last: 3117ms ago Total: 14 packets, 932 bytes Output (511 free) 0090.f2c9.cc00(103): 8 packets, 504 bytes, last: 4311ms ago Total: 8 packets, 504 bytes