スイッチポートおよびインターフェイスの問題のトラブルシューティング
内容
はじめに
このドキュメントでは、ポートやインターフェイスで発生する問題の原因を特定する方法について説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントは、Cisco IOS® システムソフトウェアを実行する Catalyst スイッチに適用されます。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
物理層のトラブルシューティング
LED を使用したトラブルシューティング
スイッチに物理的にアクセスできる場合は、 save ポートLEDを見て、リンクステータスを確認するか、エラー状態（赤またはオレンジの場合）を示すことができます。次の表で、イーサネット モジュールまたは固定構成スイッチの LED ステータスについて説明します。
| Platform | URL |
| Catalyst 6000 シリーズ スイッチ |
|
| Catalyst 4000 シリーズ スイッチ |
|
| Catalyst 3750 シリーズ スイッチ |
|
| Catalyst 3550 シリーズ スイッチ |
|
| Catalyst 2950/2955 シリーズ スイッチ |
|
| Catalyst 2900/3500XL シリーズ スイッチ |
|
| Catalyst 1900 および 2820 シリーズ スイッチ |
両側でリンクが確立していることを確認します。ワイヤが 1 つ切断されている、またはポートが 1 つシャットダウンされている場合、一方の側ではリンク ライトが点灯しますが、もう一方では点灯しません。
リンク ライトはケーブルが完全に機能していることを保証するものではありません。ケーブルは、物理的な負荷により限界点付近で機能している場合があります。通常、このような状態になると、ポートではパケット エラーが頻繁に発生したり、フラッピング（リンクを一度失ってから再び取り戻す状態）が継続的に発生したりします。
ケーブルの確認および接続の両側の確認
ポートのリンク ライトが点灯しない場合は、次の可能性を検討します。
| 考えられる原因 | 是正アクション |
| ケーブルが接続されていない |
ケーブルをスイッチから動作確認済みのデバイスに接続します。 |
| ポートが正しくない |
ケーブルの両端が正しいポートに接続されていることを確認します。 |
| デバイスの電源が入っていない |
両方のデバイスの電源を入れます。 |
| ケーブルのタイプが正しくない |
正しいケーブルを選択しているかどうかを確認します。『Catalyst スイッチのケーブル ガイド』を参照してください。 |
| ケーブル不良 |
疑わしいケーブルを確認済みの良品ケーブルと交換します。コネクタで破損または欠落したピンがないか確認します。 |
| 接続が緩んでいる |
接続が緩んでいないかチェックします。ケーブルがジャックに差し込まれているように見えても、きちんと差し込まれていない場合があります。ケーブルを抜き、再度挿入してください。 |
| パッチパネルの障害 |
障害のあるパッチパネル接続を排除します。可能であれば、バイパスを設けてそのパッチパネルを回避します。 |
| メディア コンバータの障害 |
障害のあるメディアコンバータ（ファイバから銅など）を排除します。可能であれば、バイパスを設けてそのメディア コンバータを回避します。 |
| 不良または不適切なギガビット インターフェイス コンバータ（GBIC） |
疑わしい GBIC を確認済みの良品 GBIC と交換します。ハードウェアおよびソフトウェアでこのタイプの GBIC がサポートされていることを確認します。 |
| イネーブルでないポート不良またはモジュールのポートまたはインターフェイスまたはモジュール |
疑わしいポートまたはモジュールの問題をトラブルシューティングするには、確認済みの正常なポートにケーブルを移します。Cisco IOSでshow interfaceコマンドを使用して、errdisable、disable、またはshutdownのステータスを探します。show module コマンドでは faulty と表示される場合があり、これはハードウェアの問題を示している可能性があります。詳細は、このドキュメントの「ポートおよびインターフェイスの一般的な問題」の項を参照してください。 |
イーサネットで使用する銅ケーブルと光ファイバ ケーブル
希望する接続タイプに適した正しいケーブルであることを確認します。カテゴリ 3 の銅ケーブルは、10 Mbps シールドなしツイストペア（UTP）接続に使用できますが、10/100 または 10/100/1000 Mbps UTP 接続には使用できません。10/100 または 10/100/1000 Mbps UTP 接続には、カテゴリ 5、カテゴリ 5e、またはカテゴリ 6 UTP ケーブルが必要です。
光ファイバに関しては、適用される距離と使用されているファイバ ポートのタイプに適したケーブルがあることを確認します。シングルモードファイバ（SMF）とマルチモードファイバ（MMF）の 2 つのオプションがあります。また、一緒に接続されるデバイスのポートが両方ともシングルモードであるか、または両方ともマルチモードであることを確認してください。
イーサネットとファスト イーサネットの最大伝送距離
| トランシーバの速度 | ケーブル タイプ | デュプレックスモード | ステーション間の最大距離 |
| 10 Mbps |
カテゴリ 3 UTP |
全二重/半二重 |
100 m（328 ft） |
| 10 Mbps |
MMF |
全二重/半二重 |
1.2 マイル（2 km） |
| 100 Mbps |
カテゴリ 5 UTP カテゴリ 5e UTP |
全二重/半二重 |
100 m（328 ft） |
| 100 Mbps |
カテゴリ 6 UTP |
全二重/半二重 |
100 m（328 ft） |
| 100 Mbps |
MMF |
ハーフ |
400 m（1312 ft） |
| Full |
1.2 マイル（2 km） |
||
| 100 Mbps |
SMF |
ハーフ |
400 m（1312 ft） |
| Full |
10 km（6.2 マイル） |
ケーブル/コネクタの種類、ケーブル要件、光学的要件（距離、タイプ、パッチケーブルなど）、各種ケーブルの接続方法、およびほとんどのシスコスイッチおよびモジュールで使用されているケーブルの詳細については、 『Catalyst スイッチケーブルガイド』を参照してください。
ギガビットイーサネットのトラブルシューティング
ギガビット リンク上でデバイス A がデバイス B に接続されているのに、リンクが確立されない場合は、次の手順に従ってください。
手順
-
デバイス A とデバイス B で、短波長（SX）、長波長（LX）、ロングホール（LH）、超長距離（ZX）、または銅 UTP（TX）のうちの同じ GBIC が使用されていることを確認します。リンクを確立するには、両方のデバイスが同じタイプの GBIC を使用する必要があります。SX GBIC は SX GBIC と接続する必要があります。SX GBIC は LX GBIC とはリンクしません。詳細は、『モード調整パッチ コード インストレーション ノート』を参照してください。
-
下の表に従い、GBIC ごとに距離と使用ケーブルを確認します。
1000BASE-T ポートと 1000BASE-X ポートのケーブル接続の仕様
| GBIC |
波長(nm) |
銅/ファイバ タイプ |
コアサイズ1（ミクロン） |
モード帯域幅（MHz/km） |
ケーブル長 2 |
| WS-G5483 1000Base-T（銅） |
カテゴリ 5 UTP カテゴリ 5e UTP カテゴリ 6 UTP |
100 m（328 ft） |
|||
| WS-G54841000BASE-SX3 |
850 |
MMF |
62.5 62.5 50.0 50.0 |
160 200 400 500 |
220 m（722 フィート）275 m（902 フィート）500 m（1640 フィート）550 m（1804 フィート） |
| WS-G54861000BASE-LX/LH |
1310 |
MMF4SMF |
62.5 50.0 50.0 8.3/9/10 |
500 400 500 - |
550 m（1804 フィート）550 m（1804 フィート）550 m（1804 フィート）10 km（6.2 マイル） |
| WS-G54871000BASE-ZX5 |
1550 |
MMF SMF6 |
8.3/9/10、8.3/9/10 |
70 km（43.5 マイル）7100 km（62.1 マイル） |
-
マルチモード光ファイバ ケーブルに付けられている番号は、そのケーブルのコア径を示します。シングルモード光ファイバ ケーブルの場合は、8.3 ミクロンがケーブルのコア径を示します。9 ミクロンと 10 ミクロンの値は、モードフィールド径（MFD）を指します。これは、ファイバ内の光を伝搬する部分の直径です。この領域は、ファイバコアと、クラッドを覆う小さな部分で構成されます。MFD は、コア径、レーザー波長、およびコアと被覆の屈折率差から求められます。
-
ケーブル距離は、ファイバの損失に基づいて算出されたものです。複数のファイバを接合したり、規格外の光ファイバケーブルを使用すると、ケーブル距離は短くなります。
-
MMF 以外は使用できません。
-
LX/LH GBIC で 62.5 ミクロン径の MMF を使用する場合、リンクの送信側と受信側の両端で、GBIC と MMF ケーブルの間にモード調整パッチコード（CAB-GELX-625 または同等のもの）をインストールする必要があります。モード調整パッチコードは、リンク距離が 328 フィート（100 m）未満または 984 フィート（300 m）を超える場合に必要とされます。モード コンディショニング パッチ コードは、距離の短い MMF ではレシーバの酷使を防ぎ、距離の長い MMF では差動モード遅延を減らします。詳細は、『モード調整パッチ コード インストレーション ノート』を参照してください。
-
SMF 以外は使用できません。
-
分散シフト型シングルモード光ファイバ ケーブル
-
ZX GBIC の最小リンク長は、リンクの両端に 8-dB 減衰器を設置した場合で 6.2 マイル（10 km）です。減衰器を設置しない場合は、最小リンク長は 24.9 マイル（40 km）となります。
3.いずれかのデバイスに複数のギガビットポートがある場合は、ポートを相互に接続します。こうすると、各デバイスをテストして、ギガビット インターフェイスが正常に機能していることが確認できます。たとえば、2 つのギガビット ポートを持つスイッチがあるとします。ギガビット ポート 1 をギガビット ポート 2 に接続してみてください。リンクは確立したでしょうか。確立した場合、ポートは正常に機能しています。STP（スパニング ツリー プロトコル）を使用することでポート上のループがブロックされ、ループの発生が回避されます（ポート 1 の受信（RX）からポート 2 の送信（TX）へ、ポート 1 の TX からポート 2 の RX へ）。
4. SCコネクタを使用した単一接続またはステップ3に失敗した場合は、ポートをそれ自体にループバックします（ポート1のRXがポート1のTXに向かいます）。ポートは活動化するでしょうか。活動化しない場合は、ポートに障害がある可能性があります。TAC にお問い合せください。
5.ステップ3と4が成功しても、デバイスAとデバイスB間の接続が確立できない場合は、2つのデバイスに隣接するケーブルでポートをループします。ケーブル不良がないことを確認します。
6.各デバイスがギガビットオートネゴシエーションの802.3z仕様をサポートしていることを確認します。ギガビット イーサネットには、10/100 イーサネットで使用されているものよりも機能拡張されたオートネゴシエーション手順が搭載されています（ギガビット オートネゴシエーションの仕様：IEEE Std 802.3z-1998）。リンク ネゴシエーションをイネーブルにすると、フロー制御、デュプレックス モード、リモート障害情報のネゴシエーションがシステムによって自動的に行われます。リンクの両端でリンク ネゴシエーションを有効または無効にする必要があります。リンクの両端で同じ値に設定する必要があります。このようにしないと、リンクが接続しません。IEEE 802.3z 規格が承認されるよりも前に製造されたデバイスに接続する場合には、問題が発生しています。一方のデバイスがギガビット オートネゴシエーションをサポートしていない場合、ギガビット オートネゴシエーションをディセーブルにすると強制的にリンクがアップします。カード ファームウェアは、10/100/1000BASE-TX リンク/ポートのダウンをソフトウェアに通知するのに、300 ミリ秒かかります。300 ミリ秒というデフォルトのデバウンス タイマーの値は、300 ミリ秒ごとに行われる、ファームウェアによるラインカードのポーリングの間隔に由来します。このリンクが 1G（1000BASE-TX）モードで実行されている場合は、10 ミリ秒間隔で発生するギガビット同期により、リンクのダウンはより早く検出されます。銅線上でギガビットイーサネットを実行する場合と、ファイバ上でギガビットイーサネットを実行する場合では、リンク障害の検出回数が異なります。この検出回数の相違は、IEEE 標準に基づいています。
ギガビットイーサネットのシステム要件は、ギガビットインターフェイスコンバータ(GBIC)、低密度波長分割多重(CWDM)、および着脱可能小型フォームファクタ(SFP)のシステム要件と同様、次のドキュメントを参照してください。
一般的な設定情報とトラブルシューティング方法の追加情報については、『イーサネット 10/100/1000 MB 半二重/全二重オートネゴシエーションの設定とトラブルシューティング』を参照してください。
Connected と Notconnected
ほとんどのシスコスイッチには、notconnect（未接続）状態のポートがあります。これは、現在はどこにも接続されていなせんが、別の動作中のデバイスに適切に接続された場合は接続できることを意味します。良品ケーブルを notconnect ステータスの 2 つのスイッチ ポートに接続すると、両方のポートのリンク表示が緑になり、ポートのステータスが connected になります。これは、レイヤ 1（L1）で接続されている限り、ポートがアップ状態であることを意味します。
Cisco IOS では、show interfaces コマンドを使用して、インターフェイスが up, line protocol is up (connected) かどうかを確認できます。最初の up は、インターフェイスの物理層のステータスを示します。 line protocol up メッセージは、インターフェイスのデータリンク層のステータスを示し、インターフェイスがキープアライブを送受信できることを意味します。
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)!--- Reasons: In this case, !--- 1) A cable is not properly connected or not connected at all to this port. !--- 2) The connected cable is faulty. !--- 3) Other end of the cable is not connected to an active port or device. !--- Note: For gigabit connections, GBICs need to be matched on each !--- side of the connection. !--- There are different types of GBICs, depends on the cable and !--- distances involved: short wavelength (SX), !--- long-wavelength/long-haul (LX/LH) and extended distance (ZX). !--- An SX GBIC needs to connect with an SX GBIC; !--- an SX GBIC does not link with an LX GBIC. Also, some gigabit !--- connections require conditioning cables, !--- that depend on the lengths involved.
Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is up, line protocol is down (notconnect)
!--- The interface is up (or not in a shutdown state), but line protocol down. !--- Reason: In this case, the device on the other side of the wire is a !--- CatOS switch with its port disabled.
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 notconnect 1 auto auto 10/100BaseTX
show interfacesで「up/line protocol up (connected)」と表示されているのに、いずれかのコマンドの出力でエラーの増加が認められる場合は、このドキュメントの「ポートおよびインターフェイスの一般的な問題」のセクションを参照してアドバイスを受けてください。
Cisco IOS で一般的に使用するポートおよびインターフェイスのトラブルシューティング コマンド
この表は、スーパーバイザ上で Cisco IOS システムソフトウェアを実行しているスイッチのポートまたはインターフェイスの問題をトラブルシューティングするために使用される、最も一般的なコマンドを示しています。
サポートされるコマンドのシスコデバイスからの出力がある場合、Cisco CLI アナライザを使用して問題や修正の候補を表示できます。
| Cisco IOS コマンド | 説明 |
| show version |
このコマンドは、ソフトウェアイメージ名、バージョン情報、システムメモリサイズなど、シスコルータと同様の出力を表示します。ソフトウェア/ハードウェアの非互換性(リリースノートまたはSoftware Advisorを使用)およびバグ(Bug Search Toolを使用)の検索に役立ちます。 
注：シスコの内部ツールおよび情報にアクセスできるのは、登録ユーザのみです。 |
| show module |
このコマンドは、スイッチに存在するカード、それらが実行しているソフトウェアのバージョン、およびモジュールの状態（ok、faulty など）を表示します。これは、モジュールまたはポートのハードウェアの問題を診断するのに役立ちます。show moduleコマンドを使用してハードウェアの問題をトラブルシューティングする方法の詳細については、このドキュメントの「ポートまたはインターフェイスのステータスがdisabledまたはshutdown」または「ハードウェアの問題」の項を参照してください。 |
| show run-config |
このコマンドは、スイッチの現在のコンフィギュレーション ファイルを表示します。変更は次のとおりです |
| show interfaces |
show interface コマンドは、スイッチポートの管理ステータスと動作ステータス、入出力パケット、バッファ障害、エラーなどを表示します。 |
| clear counters |
clear countersコマンドを使用してトラフィックカウンタとエラーカウンタの値をゼロに戻し、問題が一時的なのか、またはカウンタの値が増加し続けるかを確認します。
注:Catalyst 6500/6000シリーズスイッチでは、clear countersコマンドではインターフェイスのビットカウンタはクリアされません。これらのスイッチでビット カウンタをクリアする方法は、リロードを実行する以外にありません。 |
| show interfaces counters |
これは、Catalyst 6000、4000、3550、2950、および 3750 シリーズで使用するコマンドです。 |
| show counters interface show controllers ethernet-controller |
show counters interfaceコマンドは、Catalyst 6000シリーズだけでソフトウェアバージョン12.1(13)Eに導入され、32ビットおよび64ビットのエラーカウンタを表示します。2900/3500XL、2950/2955、3550、2970および3750シリーズスイッチ上のCisco IOSでは、show controllers Ethernet-controllerコマンドを使用すると、廃棄フレーム、遅延フレーム、アラインメントエラー、コリジョンなどが表示されます。 |
| show interfaces counters |
これは、Catalyst 6000、4000、3550、2950、および 3750 シリーズで使用するコマンドです。 |
| show diagnosticのshow post |
Catalyst 6000シリーズでは12.1(11b)Eでshow diagnostic（隠しコマンド）が導入され、Catalyst 4000シリーズではshow diagnostics(末尾にsが付く)が導入されました。2900/3500XL、2950/2955、3550、2970、および3750シリーズのスイッチでは、これに相当するコマンドはshow postであり、スイッチのPOST結果が表示されます。Catalyst スイッチのハードウェア関連エラーのトラブルシューティングの詳細については、このドキュメントの「ハードウェアの問題」セクションを参照してください。 |
Cisco IOS の特定のポートおよびインターフェイスカウンタの出力について
ほとんどのスイッチには、パケット、およびポートやインターフェイス上で発生するエラーを追跡する手段があります。この種の情報を検索するために一般的に使用されるコマンドについては、このドキュメントの「Cisco IOS で一般的に使用するポートおよびインターフェイスのトラブルシューティング コマンド」セクションを参照してください。
通常、特定のカウンタでの過度のエラーは、なんらかの問題があることを示しています。半二重設定で動作している場合、Frame Check Sequence（FCS; フレーム チェック シーケンス）、アライメント、ラント、およびコリジョンのカウンタでデータリンクエラーが増加することは問題ありません。一般的に、半二重接続の場合、総トラフィックに対してエラーの比率が 1 パーセントであれば許容されます。入力パケットに対するエラーの比率が 2 % や 3 % よりも大きいと、パフォーマンスの低下に気づく場合があります。
半二重環境では、スイッチおよび接続されたデバイスの両方がワイヤを検出し、全く同時に送信を行い、コリジョンが発生する可能性があります。フレームがワイヤに完全にコピーされず、フラグメント化されたフレームが生じると、コリジョンにより、ラント、FCS、およびアライメントのエラーが発生する可能性があります。
全二重で動作している場合は、FCS、Cyclic Redundancy Check（CRC; サイクリック冗長性検査）、アライメント、およびラントのカウンタのエラー数は最小限になります。リンクが全二重で稼働している場合、コリジョン カウンタはアクティブではありません。FCS、CRC、アライメント、またはラントのカウンタが増加しているときは、デュプレックス ミスマッチを確認してください。デュプレックス ミスマッチとは、スイッチが全二重で動作しているのに、接続デバイスは半二重で動作している状況、あるいはその逆の状況です。デュプレックス ミスマッチの結果、極端なパフォーマンス低下、断続的な接続、および接続の喪失が発生します。全二重におけるデータリンク エラーのその他の原因としては、ケーブル不良、スイッチ ポートの故障、または NIC ソフトウェア/ハードウェアの問題が考えられます。詳細は、このドキュメントの「ポートおよびインターフェイスの一般的な問題」の項を参照してください。
Cisco IOS のインターフェイスの表示
show interfaces card-type{slot/port} コマンドは、スーパーバイザ上の Cisco IOS にエラーカウンタと統計情報を表示させるために使用するコマンドです。（Catalyst 6000、4000、3550、2970、2950/2955、および3750シリーズスイッチの場合）このコマンドを代替するコマンドには、インターフェイスのエラーカウンタだけを表示するshow interfacescard-type <slot/port> counters errorsコマンドがあります。 エラー カウンタの出力の説明は、表 1 を参照してください。
Router#sh interfaces fastEthernet 6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:36, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
次に、ここまでの show interfaces コマンドの出力について、順番に説明します。
-
up, line protocol is up (connected)：最初の up は、インターフェイスの物理層のステータスを示します。 line protocol up メッセージは、インターフェイスのデータリンク層のステータスを示し、インターフェイスがキープアライブを送受信できることを意味します。
-
MTU：Maximum Transmission Unit（MTU; 最大伝送ユニット）は、イーサネットではデフォルトで 1500 バイトです（フレームの最大データ部の場合）。
-
Full-duplex, 100Mb/s：全二重および 100Mbps は、インターフェイスの現在の速度とデュプレックス設定です。これを実現するためにオートネゴシエーションが使用されたかどうかは示されません。これを表示するには、show interfaces fastEthernet 6/1 statusコマンドを使用します。
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
!--- Autonegotiation was used to achieve full-duplex and 100Mbps.
-
Last input, output - 最後のパケットがインターフェイスによって正常に受信または送信されてから経過した時間、分、および秒数。この情報は、デッドインターフェイスでいつ障害が発生したかを把握する場合に役立ちます。
-
Last clearing of show interface counters：スイッチが最後にリブートされてから最後にclear countersコマンドが発行された時刻。clear counters コマンドはインターフェイスの統計をリセットする場合に使用します。
-
Input queue：入力キュー内のパケット数。Size/max/drops=キュー内の現在のフレーム数/フレームの廃棄を開始するまでにキューが保持できる最大フレーム数/最大キューサイズを超えたために廃棄された実際のフレーム数。Flushesは、Cisco IOSが稼働するCatalyst 6000シリーズでのSelective Packet Discard（SPD；選択パケット廃棄）廃棄のカウントに使用されます（flushesカウンタは使用できますが、Cisco IOSが稼働するCatalyst 4000シリーズでは増加しません）。 SPDは、CPUが過負荷状態になると、優先順位の低いパケットをすばやくドロップして、
save優先度の高いパケット用の一部のプロセス容量。show interface コマンド出力では、Selective Packet Discard（SPD）の一環で flushes カウンタが増加しており、その場合、ルータの IP プロセス キューで選択的パケット廃棄ポリシーが実行されています。そのため、これが適用されるのはプロセス スイッチのトラフィックだけです。SPD の目的は、IP 入力キューがいっぱいになったときにもルーティング更新やキープアライブなどの重要な制御パケットが廃棄されないことを保証することです。IP 入力キューのサイズが最小しきい値と最大しきい値の間に収まっている場合、通常の IP パケットは特定の廃棄確率に基づいて廃棄されます。このランダムな廃棄は SPD フラッシュと呼ばれます。
-
Total output drops：出力キューのオーバーフローによって廃棄されたパケットの数です。一般的な原因は、高帯域幅リンクからのトラフィックが低帯域幅リンクに切り替えられること、または複数の着信リンクからのトラフィックが単一の発信リンクに切り替えられることです。たとえば、大量のトラフィックフローがギガビットインターフェイスで受信され、100Mbps インターフェイスに切り替えられた場合、100Mbps インターフェイスで出力ドロップが増加する可能性があります。これは、着信側の帯域幅と送信側の帯域幅との間で速度のミスマッチがあるため、インターフェイスの出力キューが過度のトラフィックでオーバーフローするためです。
-
Output queue：出力キュー内のパケットの数です。Size/max はそれぞれ、キュー内の現在のフレーム数 / フレームのドロップが開始するまでにキューが保持できる最大フレーム数を示します。
-
5 minute input/output rate：最近の 5 分間でインターフェイスによって確認された入力レートおよび出力レートの平均です。正確な読み取りを行うために、より短い時間を指定します(たとえば、トラフィックバーストをより適切に検出するために、load-interval <seconds> インターフェイスコマンドを発行します)。
エラー カウンタの出力の説明は、表 1 を参照してください。
!--- ...show interfaces command output continues.
1117058 packets input, 78283238 bytes, 0 no buffer
Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
285811 packets output, 27449284 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
show interfaces <card-type> <slot/port> counters errorsコマンドは、インターフェイスエラーの出力だけを表示するためにCisco IOSで使用されます。エラー カウンタの出力の説明は、表 1 を参照してください。
Router#show interfaces fastEthernet 6/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa6/1 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Fa6/1 0 0 0 0 0 0 0
表1. show interfacesまたはshow interfacesに対するCisco IOSエラーカウンタの出力 < card-type> <x/y>は、Catalyst 6000および4000シリーズのエラーをカウンタします。
| カウンタ（アルファベット順） | 問題およびエラーカウンタが増える一般的な原因 |
| Align-Err |
説明：show interfaces counters errors。アライメントエラーは、偶数のオクテットで終わらず不正な巡回冗長検査(CRC)を持つ、受信されたフレームの数のカウントです。一般的な原因：これらは通常、デュプレックスのミスマッチまたは物理的な問題（配線、ポートの不良、またはNICの不良など）が原因です。初めてケーブルをポートに接続した際に、このようなエラーが生じる場合があります。また、ハブがポートに接続されている場合は、ハブ上の別のデバイスとの間でコリジョンが起きてエラーが生じる場合があります。プラットフォームの例外：アラインメントエラーは、Catalyst 4000 シリーズ スーパーバイザ I（WS-X4012）またはスーパーバイザ II（WS-X4013）ではカウントされません。 |
| babbles |
説明：show interfaces カウンタは、送信 Jabber タイマーが期限切れになったことを示します。Jabber は 1518 オクテット（フレームビットは除外、FCS オクテットを含む）よりも長いフレームであり、偶数のオクテットで終了しない（アライメントエラー）、または FCS エラーがあります。 |
| Carri-Sen |
説明：show interfaces counters errors。Carri-Sen（キャリア検知）カウンタは、イーサネットコントローラが半二重接続でデータを送信するたびに増加します。コントローラはワイヤを検知し、送信前にビジーかどうかをチェックします。一般的な原因：これは、半二重イーサネットセグメントでは正常です。 |
| コリジョン |
説明：show interfaces カウンタ。インターフェイスによってフレームがメディアに正常に送信されるまでに衝突が発生した回数です。一般的な原因：コリジョンは半二重設定のインターフェイスでは正常ですが、全二重インターフェイスでは発生しません。コリジョンが劇的に増加した場合は、リンクの使用率が高いか、または接続されたデバイスとのデュプレックスが一致していない可能性があります。 |
| CRC |
説明：show interfaces カウンタ。トラフィックの送信元である LAN ステーションまたは遠端デバイスで生成された CRC が、受信データから算出されたチェックサムと一致しない場合に増加します。一般的な原因：通常、LAN インターフェイスまたは LAN 自体にノイズまたは伝送上の問題があります。通常は、CRC の数の増加はコリジョンが原因です。ただし、物理的な問題（配線、インターフェイス不良、または NIC 不良など）や、デュプレックスのミスマッチが原因である可能性もあります。 |
| deferred |
説明：show interfaces カウンタ。メディアがビジー状態であったために、待機した後で正常に送信されたフレームの数です。一般的な原因：これは通常、フレームを送信しようとしたときにキャリアがすでに使用されている半二重環境で見られます。 |
| pause input |
説明：show interfaces カウンタ。pause input カウンタの増加は、接続されたデバイスが、受信バッファでオーバーフローが発生しそうになった際に、トラフィックの一時停止を要求していることを示しています。一般的な原因：フレームはスイッチに受け入れられるため、このカウンタの増加は情報提供を目的としています。接続されたデバイスでトラフィックの受信が可能になると、パケットの一時停止は終了します。 |
| input packets with dribble condition |
説明：show interfaces カウンタ。フレームがやや長すぎることを示すドリブルビットエラーです。一般的な原因：フレームはスイッチに受け入れられるため、このフレームエラーカウンタの増加は情報提供を目的としています。 |
| Excess-Col |
説明：show interfaces counters errors。過度のコリジョンが生じたことによって、特定のインターフェイス上で送信が失敗したフレームのカウントです。16 回連続してパケットのコリジョンが発生すると、過度のコリジョンと見なされます。パケットはこの後廃棄されます。 一般的な原因：過剰コリジョンは、通常、セグメントの負荷を複数のセグメントに分割する必要があることを示すものですが、接続されているデバイスとのデュプレックスの不一致を示している可能性もあります。全二重に設定されたインターフェイスでコリジョンが発生する状態は異常です。 |
| FCS-Err |
説明：show interfaces counters errors。フレームチェックシーケンス（FCS）エラーはあるが、フレームエラーはない有効なサイズのフレームの数。 一般的な原因：通常は物理的な問題（ケーブル接続、ポートの不良、ネットワーク インターフェイス カード（NIC）の不良など）ですが、デュプレックスの不一致を示している場合もあります。 |
| フレーム |
説明：show interfaces カウンタ。CRC エラーおよび総ビット数が 8 の整数倍でないため、正常に受信されなかったパケット数です。 一般的な原因：これは通常、コリジョンまたは物理的な問題（ケーブル接続、不良ポートまたは NIC など）の結果として生じますが、デュプレックスの不一致を示している場合もあります。 |
| 大きい |
説明：show interfaces および show interfaces counters errors。最大 IEEE 802.3 フレームサイズ（非ジャンボイーサネットの場合は 1518 バイト）よりも大きく、フレーム チェック シーケンス（FCS）が正しくない受信フレーム。一般的な原因：多くの場合、これは不良 NIC の結果生じます。問題のデバイスを特定し、そのデバイスをネットワークから取り除きます。 プラットフォームの例外：Cisco IOSが稼働するCatalyst Cat4000シリーズのソフトウェアバージョン12.1(19)EWより前では、フレームが1518バイトを超えるとジャイアントカウンタが増加していました。12.1(19)EW 以降、show interfaces のジャイアントは、FCS が不良で 1518 バイトを超えるフレームを受信した場合にのみ増分します。 |
| 無視 |
説明：show interfaces カウンタ。インターフェイスのハードウェアの内部バッファでの動作が低速なため、インターフェイスで無視された受信パケットの数です。 一般的な原因：ブロードキャストストームやノイズのバーストによって、ignored のカウントが増分する場合があります。 |
| 入力エラー |
説明：show interfaces カウンタ。 一般的な原因：ラント、ジャイアント、バッファなし、CRC、フレーム、オーバーラン、および無視されたカウントが含まれます。入力に関連するその他のエラーで入力エラーの数が増加する場合があります。また、エラーが複数あるデータグラムの可能性もあります。そのため、この合計値が上記の入力エラー カウントの合計とつりあわない場合があります。「レイヤ 2 スイッチポートに接続されたレイヤ 3 インターフェイスでの入力エラー」の項も参照してください。 |
| Late-Col |
説明:show interfacesおよびshow interfaces counterserors。 送信処理の終盤に、特定のインターフェイス上でコリジョンが検知された回数です。10 Mbit/s ポートの場合、これはパケット送信が始まってから 512 ビット時間後よりも遅くなります。512 ビット時間は、10 Mbit/s システム上の 51.2 マイクロ秒に相当します。一般的な原因：このエラーは、特にデュプレックスの不一致を示す可能性があります。デュプレックスの不一致のシナリオでは、レイトコリジョンは半二重側で見られます。半二重側が送信すると、全二重側は順番を待たずに同時に送信するため、レイトコリジョンが発生します。レイト コリジョンは、イーサネット ケーブルまたはセグメントが長すぎることを示す可能性もあります。全二重に設定されたインターフェイスでコリジョンが発生する状態は異常です。 |
| lost carrier |
説明：show interfaces カウンタ。送信中にキャリアが失われた回数です。 一般的な原因：ケーブル不良をチェックします。両側で物理的な接続を確認します。 |
| Multi-Col |
説明：show interfaces counters errors。インターフェイスによってフレームがメディアに正常に送信されるまでに、複数の衝突が発生した回数。 一般的な原因：コリジョンは半二重設定のインターフェイスでは正常ですが、全二重インターフェイスでは発生しません。コリジョンが劇的に増加した場合は、リンクの使用率が高いか、または接続されたデバイスとのデュプレックスが一致していない可能性があります。 |
| no buffer |
説明：show interfaces カウンタ。受信されたにもかかわらず、バッファ スペースがないために廃棄されたパケットの数です。一般的な原因：ignored カウントと比較します。ブロードキャスト ストームがこれらのイベントの原因になっている場合がよくあります。 |
| no carrier |
説明：show interfaces カウンタ。送信中にキャリアが検出されなかった回数です。一般的な原因：ケーブル不良をチェックします。両側で物理的な接続を確認します。 |
| Out-Discard |
説明：エラーは検出されなかったものの、破棄するように選択されたアウトバウンドパケットの数。一般的な原因：このようなパケットを廃棄する理由の1つは、バッファスペースを解放することです。 |
| output buffer failures output buffers swapped out |
説明：show interfaces カウンタ。障害が発生したバッファの数と交換されたバッファの数です。一般的な原因：ポートにスイッチングされるトラフィックレートが高く、トラフィックの量を処理できない場合、ポートはパケットを Tx バッファにバッファリングします。ポートでは Tx バッファがオーバーフローするとパケットの廃棄を開始して、underruns と output buffer failure カウンタを増加します。output buffer failure カウンタの増加は、ポートが稼働している速度とデュプレックス（またはそのどちらか）が不良であるか、または、そのポートを通過するトラフィックが多すぎることを示しています。例として、1 ギガのマルチキャスト ストリームが 24 の 100 Mbps ポートに転送されるシナリオを考えてみます。出力インターフェイスへの送信が過剰になった場合、Out-Discard とともに output buffer failure が増加するのは正常です。トラブルシューティング情報については、このドキュメントの「遅延フレーム（Out-Lost または Out-Discard） 」セクションを参照してください。 |
| 出力エラー |
説明：show interfaces カウンタ。最終的にインターフェイスからのデータグラムの送信ができなかった原因となるエラーの合計数です。一般的な原因：この問題は、出力キューのサイズが小さいことが原因です。 |
| overrun |
説明：受信側ハードウェアが受信データをハードウェアバッファに渡すことができなかった回数。一般的な原因:トラフィックの入力レートが、受信側のデータ処理能力を上回ったことが原因です。 |
| packets input/output |
説明：show interfaces カウンタ。そのインターフェイス上で送受信された、エラーのないパケットの合計数です。トラフィックがインターフェイスを適切に通過しているかどうかを判断するのに役立つため、これらのカウンタの増分を監視します。バイト カウンタには、システムで送受信されたエラーのないパケットに含まれるデータと MAC カプセル化の両方が反映されます。 |
| Rcv-Err |
説明:Catalyst 6000シリーズの場合のみ：show interfaces counters error。一般的な原因:「プラットフォームの例外」を参照してください。プラットフォームの例外: Catalyst 5000シリーズrcv-err =受信バッファの障害。たとえば、runt、giant、または FCS-Err の値による rcv-err カウンタの増加はありません。5000 シリーズでは、rcv-err カウンタが増加するのは、トラフィックが過剰になった場合だけです。Catalyst 4000 シリーズ：rcv-err はすべての受信エラーの合計を示します。つまり、Catalyst 5000 とは異なり、runt、giant、または FCS-Err などのエラーを受け取ると、rcv-err カウンタが増加します。 |
| ラント |
説明：show interfaces および show interfaces counters errors。最小のIEEE 802.3フレームサイズ（イーサネットの場合は64バイト）よりも小さく、CRCの不正な受信フレーム。一般的な原因：デュプレックスのミスマッチや、接続デバイスでのケーブル、ポート、またはNICの不良などの物理的な問題が原因である可能性があります。 プラットフォーム例外:Cisco IOSが稼働するCatalyst 4000シリーズソフトウェアバージョン12.1(19)EWより前では、undersizeを意味します。undersize とは、サイズが 64 バイト未満のフレームです。runt カウンタが増加するのは、64 バイト未満のフレームを受信した場合だけです。12.1(19)EW 以降では、ラントはフラグメントを意味します。フラグメントとは、サイズが 64 バイト未満で、不正な CRC を持つフレームです。その結果、現在のバージョンでは、サイズが 64 バイト未満で不正な CRC を持つフレームが受信されると、show interfaces counters errors の fragments カウンタとともに、show interfaces の runt カウンタが増加します。Cisco IOS 12.1(19)EA1より前のリリースのCisco Catalyst 3750シリーズスイッチでは、Catalyst 3750のトランクインターフェイスでdot1qが使用されている場合、show interfacesの出力にラントが表示されます。これは、カプセル化された有効なdot1qパケット（61 ～ 64バイト、qタグを含む）が、正しく転送されていても、Catalyst 3750ではアンダーサイズとしてカウントされるためです。さらに、これらのパケットは、受信統計情報でも適切なカテゴリ（unicast、multicast、または broadcast など）で報告されません。この問題は、Cisco IOS リリース 12.1(19)EA1 または 12.2(18)SE 以降では解決されています。 |
| Single-Col |
説明：show interfaces counters errors。インターフェイスによってフレームがメディアに正常に送信されるまでに衝突が発生した回数です。 一般的な原因：コリジョンは半二重設定のインターフェイスでは正常ですが、全二重インターフェイスでは発生しません。コリジョンが劇的に増加した場合は、リンクの使用率が高いか、または接続されたデバイスとのデュプレックスが一致していない可能性があります。 |
| 抑制 |
説明：show interfaces。おそらくバッファまたはプロセッサの過負荷により、ポート上で受信側がディセーブルにされた回数。throttles カウンタの値にアスタリスク（*）が付いている場合、そのコマンドが実行された際にインターフェイスがディセーブルにされたことを示しています。 一般的な原因：プロセッサの過負荷を増加させる可能性のあるパケットには、オプション付きの IP パケット、期限切れの TTL、非ARPA カプセル化、フラグメンテーション、トンネル、ICMP パケット、MTU チェックサムエラー、RPF エラー、IP チェックサムおよび長さのエラーのあるパケットが含まれます。 |
| Underruns |
説明：トランスミッタが、スイッチが処理可能な速度よりも高速だった回数。 一般的な原因：これは、他の多数のインターフェイスから、大量のトラフィックバーストがインターフェイスに一度に集中する、スループットの高い状況で発生する可能性があります。アンダーランが発生して、インターフェイスがリセットされる場合があります。 |
| アンダーサイズ |
説明：show interfaces counters errors。IEEE 802.3 フレームの最小サイズである 64 バイト（フレームビットは除くが、FCS オクテットは含む）よりは小さいが、それ以外の形式は良好な受信フレーム。 一般的な原因：これらのフレームを送信するデバイスを確認します。 |
| Xmit-Err |
説明：show interfaces counters errors。これは、内部の送信（Tx）バッファがいっぱいであることを示します。一般的な原因：Xmit-Err の一般的な原因は、高帯域幅リンクからのトラフィックが低帯域幅リンクに切り替えられること、または複数の着信リンクからのトラフィックが単一の発信リンクに切り替えられることです。たとえば、大量のトラフィックバーストがギガビットインターフェイスで受信され、100Mbps インターフェイスに切り替えられた場合、100Mbps インターフェイスで Xmit-Err が増加する可能性があります。これは、着信側の帯域幅と送信側の帯域幅との間の速度のミスマッチにより、インターフェイスの出力バッファが過度のトラフィックでオーバーフローするためです。 |
Cisco IOS のインターフェイスカウンタの表示
ユニキャスト、マルチキャスト、およびブロードキャスト トラフィックについて、次の出力で表示されるポートのインバウンドおよびアウトバウンド トラフィックを監視します。show interfaces card-type {slot/port} counters コマンドは、スーパーバイザ上で Cisco IOS が稼働している場合に使用します。
Router#show interfaces fas 6/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Fa6/1 47856076 23 673028 149 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Fa6/1 22103793 17 255877 3280 Router#
!--- Cisco IOS counters used to monitor inbound and outbound unicast, multicast !--- and broadcast packets on the interface.
Cisco IOS のカウンタインターフェイスの表示
show counters interface card-type {slot/port}コマンドは、Catalyst 6000シリーズだけでCisco IOSソフトウェアバージョン12.1(13)Eに導入されました。このコマンドでは、ポートとインターフェイスに関するさらに詳細な統計情報が提供されます。このコマンドは、ポートまたはインターフェイスごとに32ビットおよび64ビットのエラーカウンタを表示します。
Cisco IOS の Show Controller Ethernet-Controller コマンド
Catalyst 3750、3550、2970、2950/2955、2940、および2900/3500XLスイッチの場合は、show controller ethernet-controllerコマンドを使用して、トラフィックカウンタとエラーカウンタの出力を表示します。これらの出力は、Catalyst 6000シリーズスイッチの出力と似ています。
3550-1#show controller ethernet-controller fastEthernet 0/1
!--- Output from a Catalyst 3550.
Transmit FastEthernet0/1 Receive
0 Bytes 0 Bytes
0 Unicast frames 0 Unicast frames
0 Multicast frames 0 Multicast frames
0 Broadcast frames 0 Broadcast frames
0 Discarded frames 0 No dest, unicast
0 Too old frames 0 No dest, multicast
0 Deferred frames 0 No dest, broadcast
0 1 collision frames
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames
0 14 collision frames 0 Flooded frames
0 15 collision frames 0 Overrun frames
0 Excessive collisions 0 VLAN filtered frames
0 Late collisions 0 Source routed frames
0 Good (1 coll) frames 0 Valid oversize frames
0 Good(>1 coll) frames 0 Pause frames
0 Pause frames 0 Symbol error frames
0 VLAN discard frames 0 Invalid frames, too large
0 Excess defer frames 0 Valid frames, too large
0 Too large frames 0 Invalid frames, too small
0 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames
0 511 byte frames
0 1023 byte frames
0 1518 byte frames
3550-1#
!--- See the next table for additional counter output for 2900/3500XL Series switches.
| カウンタ | 説明 | 考えられる原因 |
| 送信されたフレーム |
||
| 廃棄フレーム |
リソース不足のために送信の試行が中止されたフレームの合計数。この合計には、すべての宛先タイプのフレームが含まれます。 |
インターフェイスにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。このフィールドのパケット数が増加している場合は、インターフェイスのトラフィック負荷を減らします。 |
| フレームが古すぎます |
スイッチを通過するのに 2 秒を超えたフレームの数。このことが原因で、フレームはスイッチで廃棄されました。この状態が発生するのは、過度の高ストレス状態でだけです。 |
このスイッチにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。このフィールドのパケット数が増加している場合は、スイッチの負荷を減らします。スイッチへのトラフィック負荷を軽減するために、ネットワーク トポロジの修正が必要になる場合があります。 |
| 据え置きフレーム |
ネットワーク メディア上のトラフィックのために最初の送信の試行が遅延したフレームの数。この合計には、その後エラーなしで、コリジョンの影響を受けずに送信されたフレームのみが含まれます。 |
このスイッチにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。このフィールドのパケット数が増加している場合は、スイッチの負荷を減らします。スイッチへのトラフィック負荷を軽減するために、ネットワーク トポロジの修正が必要になる場合があります。 |
| Collision frames |
collision frames カウンタは、パケット送信に失敗したが、次の試行で成功するまでの試行回数です。つまり、collision frames カウンタが 2 増加している場合、そのスイッチはパケット送信の試行に二度失敗して、三度目で成功したということです。 |
インターフェイスにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。これらのフィールドでパケット数が増加している場合は、インターフェイスのトラフィック負荷を減らします。 |
| 過剰コリジョン |
16 回連続してレイト コリジョンが発生した回数。パケットの送信が 16 回試行されると、そのパケットは廃棄されて、カウンタが増加します。 |
このカウンタが増加している場合、配線の問題、ネットワークへの過剰な負荷、またはデュプレックスのミスマッチが原因である可能性があります。ネットワークに過剰な負荷がかかる原因としては、共有イーサネット上のデバイス数が多すぎることが考えられます。 |
| 送信中コリジョン |
レイト コリジョンは、2 台のデバイスが送信を同時に行い、どちらの側もコリジョンを検出しない時に発生します。これが発生する理由は、信号をネットワークの一方の端から別の端へ伝播する時間が、パケット全体がネットワーク上にある時間よりも長いためです。レイトコリジョンを引き起こす 2 台のデバイスでは、相手が送信していることはパケット全体がネットワークに入るまで認識されません。最初の 64 バイトのスロット時間が経過するまで、トランスミッタでレイト コリジョンは検出されません。レイト コリジョンが検出されるのは、64 バイトを超える長さのパケットが転送される場合のみです。 |
レイト コリジョンの原因は、不適切なケーブル接続や、ネットワーク内にあるハブの数が規格を超えていることです。NIC の不良によってレイト コリジョンが起きる場合もあります。 |
| Good (1 coll) frames |
1 回だけコリジョンが発生してから正常に送信されたフレームの合計。 |
半二重環境では、衝突が発生するのは正常です。 |
| Good (>1 coll) frames |
2 ～ 15 回コリジョンが発生してから正常に送信されたフレームの合計。 |
半二重環境では、衝突が発生するのは正常です。このカウンタの上限まで増加しているフレームでは、コリジョンの回数が 15 回を超えると過剰コリジョンとしてカウントされる可能性があります。 |
| VLAN discardframes |
CFI ビットが設定されているためにインターフェイス上で廃棄されたフレームの数。 |
イーサネットの正規のフレーム形式に対しては、802.1q フレームの TCI で CFI（Canonical Format Indicator）のビットが 0 に設定されます。CFI ビットが 1 に設定されている場合、RIF（ルーティング情報フィールド）またはトークン リングの正規外のフレームが存在していて削除されたことを意味します。 |
| 受信されたフレーム |
||
| 帯域幅のフレームがありません |
2900/3500XL のみ。ポートがネットワークからパケットを受信したが、このパケットを受信するためのリソースがスイッチになかった回数。この状態は、ストレス状態でだけ発生しますが、複数のポートでのトラフィックのバーストによって発生する場合があります。したがって、No bandwidth frames が少なくても問題ありません（受信するフレームの 1 % よりもかなり小さい値である必要があります）。 |
インターフェイスにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。これらのフィールドでパケット数が増加している場合は、インターフェイスのトラフィック負荷を減らします。 |
| バッファフレームがありません |
2900/3500XL のみ。ポートがネットワークからパケットを受信したが、このパケットを受信するためのリソースがスイッチになかった回数。この状態は、ストレス状態でだけ発生しますが、複数のポートでのトラフィックのバーストによって発生する場合があります。したがって、No buffers frames が少なくても問題ありません（受信するフレームの 1 % よりもかなり小さい値である必要があります）。 |
インターフェイスにかかる過剰なトラフィック負荷が原因でフレームが廃棄されます。これらのフィールドでパケット数が増加している場合は、インターフェイスのトラフィック負荷を減らします。 |
| 宛先ユニキャストはありません |
No destination unicast は、そのポートから他のポートへ転送されなかったユニキャスト パケットの数です。 |
どのような場合に No dest（unicast、multicast、broadcast）カウンタが増加するかについて、簡単に説明します。
|
| 宛先マルチキャストはありません |
No destination multicast は、他のポートへ転送されなかったマルチキャスト パケットの数です。 |
|
| No dest, broadcast |
そのポートから他のポートへ転送されなかったブロードキャスト パケットの数。 |
|
| アラインメントエラー |
アラインメント エラーは、偶数のオクテットで終わらず不正な CRC を持つ、受信されたフレームの数です。 |
アライメントエラーは、フレームがワイヤに完全にコピーされず、フラグメント化されたフレームが生じることが原因で発生します。アライメントエラーは、半二重でのコリジョン、デュプレックスの不一致、障害のあるハードウェア（NIC、ケーブル、またはポート）、または接続されたデバイスがオクテットで終わらず不正な FCS を持つフレームを生成した結果発生します。 |
| FCSエラー |
FCS エラー カウントは、イーサネット フレーム内の不正なチェックサム（CRC 値）とともに受信されたフレームの数です。これらのフレームは廃棄され、他のポートに伝播されません。 |
FCS エラーは、半二重でのコリジョン、デュプレックスの不一致、障害のあるハードウェア（NIC、ケーブル、またはポート）、または接続されたデバイスがオクテットで終わらず不正な FCS を持つフレームを生成した結果発生します。 |
| 過小フレーム |
これらは、長さが 64 オクテット未満（フレームビットを除き、FCS を含む）で、正常な FCS 値を持つ、受信されたパケットの合計数です。 |
エラー フレームが接続デバイスによって生成されたことを示します。接続されたデバイスが正常に動作していることを確認します。 |
| 過大フレーム |
ポートでネットワークから受信した 1514 バイトを超えるパケットの数。 |
これは、障害のあるハードウェア、dot1q、または ISL トランキングの設定の問題を示している可能性があります。 |
| コリジョンフラグメント |
長さが 64 オクテット未満（フレームビットを除き、FCS を含む）で、FCS 値が正しくないフレームの総数。 |
このカウンタが増加する場合、そのポートは半二重に設定されています。デュプレックスを全二重に設定します。 |
| 超過フレーム |
受信側のハードウェアが、受信したデータのハードウェア バッファへの引き渡しに失敗した回数。 |
トラフィックの入力レートが、受信側のデータ処理能力を上回ったことが原因です。 |
| VLAN filtered frames |
フレーム内の VLAN 情報のタイプのために、フィルタされたフレームの合計数。 |
802.1Q タグ付きフレームをフィルタするように、ポートを設定できます。802.1Q タグを含むフレームが受信されると、そのフレームがフィルタされ、このカウンタが増加します。 |
| Source routed frames |
送信元ルートのビットがネイティブフレームの送信元アドレスの中に設定されていたために廃棄された、受信されたフレームの合計数。 |
この種の送信元ルーティングは、トークン リングおよび FDDI に対してだけ定義されます。IEEE のイーサネットの仕様では、このビットをイーサネット フレームで設定することはできません。そのため、このようなフレームはスイッチによって廃棄されます。 |
| Valid oversize frames |
長さがシステム MTU よりも大きいが FCS の値は正常な、受信されたフレームの合計数。 |
この統計情報では、設定されているシステム MTU よりも大きいフレームがカウントされます。ただし、これらのフレームは、Q-in-Q または MPLS のカプセル化を行うために 1518 バイトから増加されている場合もあります。 |
| Symbol error frames |
ギガビット イーサネット（1000 Base-X）では、MAC サブレイヤ（レイヤ 2）の 8 ビット データは、8B/10B 符号化によって 10 ビットの記号に変換されて、ネットワーク上で送信されます。ポートで記号が受信されると、受信された 10 ビットの記号から 8 ビットのデータが抽出されます。 |
シンボル エラーは、インターフェイスで未定義の（無効な）記号が受信されたことを示します。シンボル エラーの件数が少ない場合には、無視してかまいません。シンボル エラーが大量に発生している場合は、デバイス、ケーブル、またはハードウェアに障害がある可能性があります。 |
| Invalid frames, too large |
ジャイアント フレーム、または IEEE 802.3 フレームの最大サイズ（非ジャンボ イーサネットの場合は 1518 バイト）を超えていて、不良 Frame Check Sequence（FCS）を持つ受信フレーム。 |
多くの場合、これは NIC 不良が原因です。問題のデバイスを特定し、そのデバイスをネットワークから取り除きます。 |
| Invalid frames, too small |
ラント フレーム、または 64 バイト未満（FCS ビットを含み、フレーム ヘッダーを除く）で、FCS エラーまたはアライメント エラーを持つフレーム。 |
二重モードのミスマッチや、ケーブル、ポート、または接続されているデバイス上の NIC の障害といった物理的な問題が原因である可能性があります。 |
一般的なシステム エラー メッセージ
Cisco IOSシステムメッセージの形式については、使用しているソフトウェアリリースの『メッセージと回復手順ガイド』を参照してください。たとえば、Cisco IOSリリースの「メッセージと回復手順」を参照できます。
%AMDP2_FE-3-UNDERFLO
このエラー メッセージは、フレームが送信されて、コントローラ チップのローカル バッファが不十分なデータを受信したときに発生します。データが、出力レートに対応できるだけの速度でチップに転送されていません。通常は、システム内部の一過性のピーク負荷の状態にもよりますが、こうした状況は一時的なものです。ファスト イーサネット インターフェイスによって過度のトラフィックが処理されたときに、この問題が発生します。トラフィック レベルがおよそ 2.5 Mb に達したときに、エラー メッセージが表示されます。このトラフィック レベルの上限は、ハードウェアの制限によります。そのため、Catalyst スイッチに接続されたデバイスでは、パケットがドロップされる可能性があります。
通常は、システムによって自動的に回復されます。必要な操作はありません。スイッチがイーサネット インターフェイスに負荷をかけている場合は、速度とデュプレックスの設定を確認してください。また、スニファプログラムを使用して、ルータのファスト イーサネット インターフェイスで送受信されているパケットを分析します。Catalyst スイッチに接続されたデバイスでのパケット ドロップを避けるために、スイッチに接続されたファスト イーサネット インターフェイスで ip cef コマンドを実行します。
%INTR_MGR-DFC1-3-INTR: Queueing Engine (Blackwater) [1]: FIC Fabric-A Received Unexpected Control Code
このエラー メッセージが表示される原因は、パケットのファブリック ヘッダーの CRC 値が、Blackwater ASIC の Fabric Interface Controller（FIC; ファブリック インターフェイス コントローラ）サブブロックに基づいて算出された CRC 値と一致しなかったためです。これは、転送中にパケットの破損が発生し、Blackwater が破損したパケットを受信したことを意味します。
Command Rejected: [Interface] not a Switching Port
L3インターフェイスとL2スイッチポートの両方をサポートするスイッチでは、レイヤ3インターフェイスとして設定されているポートでレイヤ2に関連するコマンドを入力しようとすると、「Command rejected: [interface] not a switching port」というメッセージが表示されます。
インターフェイスをレイヤ 3 モードからレイヤ 2 モードに変更するには、インターフェイス設定コマンドの switchport を発行します。このコマンドを発行してから、ポートを任意のレイヤ 2 プロパティに設定してください。
ポートおよびインターフェイスの一般的な問題
ポートまたはインターフェイスのステータスが disable または shutdown
スイッチ上の設定が誤っているためにポートで接続障害が発生している場合、障害の原因は明白であるにもかかわらず、見過ごされることがあります。ポートでオレンジの信号が点灯している場合は、ユーザ インターフェイスまたは内部プロセスを介して、スイッチ内のソフトウェアによってポートがシャットダウンされたことを示します。
何かの理由でポートやモジュールがディセーブルになっていないこと、または電源が切れていないことを確認します。リンクの一方の側でポートやモジュールを手動でシャットダウンした場合、そのポートを再度イネーブルにするまで、リンクは活動化しません。両側でポート ステータスを確認します。show run interfaceコマンドを使用して、インターフェイスがshutdown状態になっているかどうかを確認します。
Switch#show run interface fastEthernet 4/2 ! interface FastEthernet4/2 switchport trunk encapsulation dot1q switchport mode trunk shutdown duplex full speed 100 end
!--- Use the no shut command in config-if mode to re-enable this interface.
スイッチのリブート直後にポートが shutdown モードになる場合、原因はおそらくポートのセキュリティ設定です。ポートでユニキャスト フラッディングがイネーブルにされていると、リブート後にポートがシャットダウンされます。シスコでは、ユニキャストのフラッディングを無効にすることを推奨していますが、これにより、ポートで MAC アドレスの制限に達した際にフラッディングが発生しないことも保証されます。
ポートまたはインターフェイスのステータスが errdisable
デフォルトでは、スイッチ内のソフトウェア プロセスによって特定のエラーが検出されると、ポートまたはインターフェイスがシャットダウンされる場合があります。
Cisco IOSのshow interfacecard-type {slot/port} status コマンドを調べると、次のようになります。
Router#show interface fastethernet 2/4 status Port Name Status Vlan Duplex Speed Type Gi2/4 err-disabled 1 full 1000 1000BaseSX
!--- The show interfaces card-type {slot/port} status command for Cisco IOS !--- displays a status of errdisabled. !--- The show interfaces status errdisabled command shows all the interfaces !--- in this status.
Cisco IOSのshow loggingコマンドでは、errdisable状態に関連するエラーメッセージ（正確なメッセージ形式は異なります）も表示されます。
errdisable の結果としてポートまたはインターレースがシャットダウンされた場合、Cisco IOS では causes と呼ばれます。この原因として、EtherChannel の設定ミスに起因する PAgP フラッピング、デュプレックスの不一致、BPDU ポートガードと PortFast の同時設定、UDLD による単方向リンクの検出などがあります。
errdisable回復オプションを設定しない限り、ポートまたはインターフェイスをerrdisable状態から回復させるには、手動で再度イネーブルにする必要があります。Cisco IOSソフトウェアでは、errdisable状態になってから設定可能な時間が経過した後に、ポートを自動的に再イネーブルにできます。ここで重要なのは、インターフェイスを errdisable から回復するように設定したとしても、根本的な原因が解明されない限り、同じ問題が再発するということです。
この表は、スイッチの errdisable ステータスの確認とトラブルシューティングを設定するために使用されるコマンドの例を示しています。コマンドの詳細については、『Cisco IOS プラットフォームでの Errdisable ポート状態からの回復』リンクを参照してください。
| アクション | Cisco IOS errdisable コマンド |
|---|---|
| 設定 | errdisable detect cause |
| 設定 | errdisable recovery cause |
| 設定 | errdisable recovery interval <timer_interval_in_seconds> |
| 検証とトラブルシューティング | show errdisable detect |
| 検証とトラブルシューティング | show interfaces status err-disabled |
ポートまたはインターフェイスのステータスが inactive
Cisco IOS を実行しているスイッチでポートが非アクティブになる一般的な原因の 1 つに、そのポートが属する VLAN の消失があります。これは、switchport コマンドを使用してインターフェイスがレイヤ2スイッチポートとして設定されている場合に発生する可能性があります。
レイヤ 2 スイッチ内の各ポートは、1 つの VLAN に属しています。レイヤ 3 スイッチ上の、L2 スイッチポートとして設定されている各ポートも、1 つの VLAN に属している必要があります。その VLAN が削除されると、ポートまたはインターフェイスは非アクティブになります。
確認するには、show interfaces card-type {slot/port} switchport コマンドとshow vlan を使用します。
Router#show interfaces fastEthernet 4/47 switchport Name: Fa4/47Switchport: Enabled Administrative Mode: static access Operational Mode: static access Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 11 ((Inactive))
!--- FastEth 4/47 is inactive. Router#show vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi1/1, Gi2/1, Fa6/6 10 UplinkToGSR's active Gi1/2, Gi2/2
!--- VLANs are displayed in order and VLAN 11 is not available.
30 SDTsw-1ToSDTsw-2Link active Fa6/45
VLAN を削除したスイッチがその VTP ドメインの VTP サーバの場合、この VLAN は、ドメイン内のすべてのサーバおよびクライアント スイッチの VLAN テーブルから削除されます。この VLAN を VTP サーバ スイッチから VLAN テーブルに戻すと、この復旧した VLAN に所属するドメイン内のスイッチのポートは、再びアクティブになります。VLAN それ自体が削除されても、ポートにはそれ自身が割り当てられた VLAN が記憶されています。 VTP についての詳細は、『VLAN トランク プロトコル（VTP）の説明と設定』を参照してください。
アップリンク ポートまたはインターフェイスのステータスが inactive
Catalyst 4510R シリーズ スイッチでは、10 ギガビット イーサネットとギガビット イーサネットの両方の SFP アップリンクのポートをイネーブルにするための、オプションの設定があります。10 ギガビット イーサネットとギガビット イーサネットの SFP インターフェイスを並列に有効にするには、hw-module uplink select all コマンドを発行します。このコマンドを発行してからスイッチなどをリブートすると、show interface status module <module number>コマンドの出力には、アップリンクポートが非アクティブと表示されます。
Cisco IOS ソフトウェア リリース 12.2(25)SG では、Catalyst 4500 スイッチでの 10 ギガビット イーサネットとギガビット イーサネットの SFP インターフェイスの同時使用がサポートされています。
Catalyst スイッチインターフェイスの遅延カウンタの増加
このスイッチにかかる過剰なトラフィック負荷が原因でフレームが廃棄されるのが、この問題の原因です。通常、deferred frames（遅延フレーム）は、メディアがビジー状態であったため、メディアを待機した後で正常に送信されたフレームの数です。これは通常、フレームを送信しようとしたときにキャリアがすでに使用されている半二重環境で見られます。一方、全二重環境でこの問題が発生するのは、スイッチに送られる負荷が過剰な場合です。
回避策は次のとおりです。
-
ネゴシエーションの不一致を回避するように、リンクの両端を全二重にハードコーディングする。
-
ケーブルとパッチ パネル コードを交換して、確実にケーブルとパッチ コードに欠陥がないようにする。
vlan [vlan 番号] からのタイマー [値] の設定で散発的に発生する障害
Encoded Address Recognition Logic（EARL）で VLAN 用の CAM エージング時間を必要な秒数に設定できない場合に、この問題が発生します。この場合、VLAN のエージング時間は fast aging に設定済みです。
VLAN が fast aging になっていると、EARL では VLAN を fast aging に設定できず、エージング タイマーの設定プロセスはブロックされます。デフォルトの CAM エージング時間は 5 秒で、スイッチでは学習された MAC アドレスのテーブルが 5 秒ごとに消去されることになります。これにより、MAC アドレス テーブル（CAM テーブル）には常に最新のエントリが入っていることが保証されます。
fast aging では、CAM エージング時間はユーザが指定した秒数に設定され、Topology Change Notification（TCN）プロセスとともに使用されます。トポロジが変更された場合、CAM テーブルを迅速に消去して、トポロジの変更を補償するにはこの値が必要になるというのが、これの考え方です。
スイッチの CAM エージング時間を調べるには、show cam aging コマンドを発行します。TCN と fast aging は、それほど頻繁に発生するものではありません。結果的に、このメッセージの重要度は 3 になっています。もし VLAN で頻繁に fast aging が行われる場合は、その原因を調べてください。
TCN の最もよくある原因は、スイッチに直接接続されたクライアント PC です。PC の電源オン/オフを行う際に、スイッチ ポートの状態が変わり、スイッチで TCN プロセスが開始されます。スイッチでは接続されたデバイスが PC であることは認識されていないことが、この原因です。スイッチではポートが状態を変化させたことだけが認識されます。
この問題を解決するため、シスコではホスト ポート用の PortFast 機能を開発いたしました。PortFast 機能により、ホスト ポートの TCN が抑制されることがメリットです。
トランキング モードのミスマッチ
リンクの両側のトランキング モードをチェックします。両側が同じモードであることを確認してください（両方が ISL または 802.1q の同じトランキング モードであるか、または両方が非トランキング モードであること）。一方のポートでトランキング モードを on（auto または desirable ではなく）にした場合に、他方のポートでトランキング モードが off に設定されていると、これらのポートは通信できません。トランキングによって、パケットのフォーマットが変更されます。ポートでは、リンク上で使用するフォーマットが一致する必要があります。一致しないと、相互に認識されません。
Cisco IOS の場合、show interfaces card-type {mod/port} trunk コマンドを使用して、トランキングの設定とネイティブ VLAN を確認します。
Router#show interfaces fastEthernet 6/1 trunk Port Mode Encapsulation Status Native vlan Fa6/1 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa6/1 1-4094 !--- Output truncated.
さまざまなトランキングのモード、ガイドライン、制限事項についての詳細は、次のドキュメントを参照してください。
ジャンボ、ジャイアント、およびベビー ジャイアント
データ部の Maximum Transmission Unit（MTU; 最大伝送ユニット）は、イーサネット フレームではデフォルトで 1500 バイトです。送信されるトラフィックの MTU がサポートされている MTU を越えた場合、そのパケットはスイッチから転送されなくなります。また、その結果、ハードウェアやソフトウェアによっては、スイッチのプラットフォームによってポートおよびインターフェイスのエラー カウンタが増加する場合があります。
-
ジャンボ フレームは、IEEE イーサネット標準の中で定義されておらず、ベンダーに依存しています。イーサネットの標準フレームサイズである 1518 バイト（L2 ヘッダーと Cyclic Redundancy Check（CRC）を含む）よりも大きなフレームのことを、このように呼びます。ジャンボには、さらに大きなサイズのフレーム（通常、9000 バイト以上）が含まれます。
-
ジャイアント フレームとは、イーサネットの最大フレーム サイズを上回る（1518 バイト以上）、不正な FCS を持つフレームのことです。
-
ベビー ジャイアント フレームとは、イーサネットの最大フレーム サイズを少しだけ上回る大きさのフレームのことです。通常、1600 バイト以下のフレームをこのように呼びます。
Catalyst スイッチにおけるジャンボ、およびベビー ジャイアントに対するサポートは、スイッチのプラットフォームや、場合によってはスイッチ内のモジュールごとに異なります。また、ソフトウェア バージョンによって異なることもあります。
ジャンボおよびベビージャイアントに関するシステム要件、設定、およびトラブルシューティングの詳細については、『Catalystスイッチでのジャンボ/ジャイアントフレームサポートの設定例』を参照してください。
エンド デバイスに ping を実行できない
最初に、直接接続されているスイッチから送信された ping を使用してエンドデバイスをチェックし、接続できない原因となっている箇所を突き止めるまで、ポートごと、インターフェイスごと、トランクごとに段階的にさかのぼって調べます。各スイッチの連想メモリ（CAM）テーブル内に、エンドデバイスの MAC アドレスが存在していることを確認します。
show mac address-table dynamic コマンドを使用するか、interface キーワードを置き換えます。
Router#show mac-address-table interface fastEthernet 6/3 Codes: * - primary entry vlan mac address type learn qos ports ------+----------------+--------+-----+---+-------------------------- * 2 0040.ca14.0ab1 dynamic No -- Fa6/3
!--- A workstation on VLAN 2 with MAC address 0040.ca14.0ab1 is directly connected !--- to interface fastEthernet 6/3 on a switch running Cisco IOS.
スイッチが実際に CAM テーブルのデバイスの MAC アドレスを持っていることを確認したら、このデバイスが ping を実行しようとしている VLAN と同じ VLAN 上にあるか、または別の VLAN 上にあるかを判断します。
エンドデバイスが ping を実行しようとしている VLAN とは異なる VLAN 上にある場合は、デバイスが通信できるように L3 スイッチまたはルータを設定する必要があります。エンド デバイス上や、ルータまたは L3 スイッチ上で、L3 アドレスが正しく設定されていることを確認します。IP アドレス、サブネットマスク、デフォルトゲートウェイ、ダイナミック ルーティング プロトコルの設定、スタティックルートなどを確認します。
スイッチポートホストを使用した起動遅延の修正
ステーションがスイッチを介して接続されているときにプライマリサーバーと通信できない場合、この問題が、物理層のリンクがアップした後でスイッチポートがアクティブになろうとするときに、スイッチポートの遅延を引き起こす可能性があります。場合によっては、50 秒もの遅延が発生することもあります。一部のワークステーションは、サーバーを発見するのにこれほど長く待つことができず、あきらめてしまいます。これらの遅延は、STP、トランキング ネゴシエーション（DTP）、および EtherChannel ネゴシエーション（PAgP）に起因します。これらのプロトコルはすべて、必要のないアクセス ポートに対してはディセーブルにしておくことができるため、スイッチ ポートやインターフェイスがパケットの転送を開始するのは、隣接デバイスとのリンクが確立してから数秒後になります。
Cisco IOSでは、switchport hostコマンドを使用してチャネリングを無効にし、スパニングツリーPortFastを有効にします。また、switchport nonegotiateコマンドを使用してDTPネゴシエーションパケットをオフにします。複数のインターフェイスで同時にこの処理を実行するには、interface-range コマンドを使用します。
Router6k-1(config)#interface range fastEthernet 6/13 - 18 Router6k-1(config-if-range)#switchport Router6k-1(config-if-range)#switchport host switchport mode can be set to access spanning-tree portfast can be enabled channel group can be disabled !--- Etherchannel is disabled and portfast is enabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#switchport nonegotiate !--- Trunking negotiation is disabled on interfaces 6/13 - 6/18. Router6k-1(config-if-range)#end Router6k-1#
Cisco IOS には、グローバル コマンドである global spanning-tree portfast default を使用して、PortFast を自動的に、レイヤ 2 アクセス スイッチポートとして設定されている任意のインターフェイスに適用するというオプションがあります。使用しているソフトウェア リリースのコマンド リファレンスを参照して、このコマンドが使用可能かどうかを確認してください。インターフェイスごとに spanning-tree portfast コマンドを使用することもできますが、これには、ワークステーションの始動遅延を固定化するためにトランキングと Etherchannel を別々にオフにする必要があります。
速度/デュプレックス、自動ネゴシエーション、または NIC の問題
アライメント エラー、FCS エラー、またはレイト コリジョンが大量に発生する場合は、次の問題がある可能性があります。
-
デュプレックスの不一致
-
不良または破損したケーブル
- NIC カードの問題
デュプレックスの不一致
2 台のスイッチ間、スイッチとルータ間、またはスイッチとワークステーション間、あるいはスイッチとサーバー間で、デュプレックス設定が一致していないと、速度とデュプレックス関連の問題がよく発生します。この状況は、速度やデュプレックスを手動でハードコーディングした場合や、2 つのデバイス間の自動ネゴシエーションに問題がある場合に発生することがあります。
Cisco Discovery Protocol（CDP）がイネーブルになっている 2 台の Cisco デバイス間でミスマッチが発生した場合、両方のデバイスのコンソールまたはロギング バッファに CDP エラー メッセージが表示されます。CDP は、隣接する Cisco デバイス上のポートやシステムの統計情報、およびエラーの検出に便利です。CDP はシスコ独自のプロトコルであり、既知の MAC アドレス 01-00-0C-CC-CC-CC にパケットを送信する場合に機能します。
次の例は、Cisco IOSが稼働する2台のCatalyst 6000シリーズスイッチ間のデュプレックスのミスマッチが原因で発生するログメッセージを示しています。通常、ミスマッチの内容とミスマッチの発生している場所が、これらのメッセージからわかります。
Jun 2 11:16:45 %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet6/2 (not half duplex), with TBA04251336 3/2 (half duplex).
show cdp neighbors card-type <slot/port> detail コマンドを使用して、隣接するCiscoデバイスのCDP情報を表示します。
Router#show cdp neighbors fastEthernet 6/1 detail ------------------------- Device ID: TBA04251336 Entry address(es): IP address: 10.1.1.1 Platform: WS-C6006, Capabilities: Trans-Bridge Switch IGMP Interface: FastEthernet6/1, Port ID (outgoing port): 3/1 Holdtime : 152 sec Version : WS-C6006 Software, Version McpSW: 6.3(3) NmpSW: 6.3(3) Copyright (c) 1995-2001 by Cisco Systems !--- Neighbor device to FastEth 6/1 is a Cisco Catalyst 6000 Switch !--- on port 3/1 running CatOS. advertisement version: 2 VTP Management Domain: 'test1' Native VLAN: 1 Duplex: full !--- Duplex is full. Router#
速度およびデュプレックスを一方の側で自動に、他方の側で 100/全二重に設定した場合も設定ミスになり、デュプレックスの不一致が発生する可能性があります。スイッチポートで多数のレイトコリジョンを受信する場合は、通常、デュプレックスの不一致の問題を示しており、結果としてポートが errdisable ステータスになる可能性があります。半二重側は、常時ではなく特定の時間にのみパケットを予期するため、誤った時間に受信されたパケットはコリジョンとしてカウントされます。デュプレックスの不一致以外にもレイトコリジョンの原因はありますが、最も一般的な原因の 1 つはデュプレックスの不一致です。必ず接続の両側で速度とデュプレックスを自動ネゴシエーションに設定するか、または接続の両側で速度とデュプレックスを手動で設定します。
show interfaces <card-type> <slot/port> statusコマンドを使用して、速度とデュプレックスの設定、およびその他の情報を表示します。インターフェイス設定モードで speed コマンドと duplex コマンドを使用して、必要に応じて、ハードコードで両側を 10 または 100、および半二重または全二重に設定します。
Router#show interfaces fastEthernet 6/1 status Port Name Status Vlan Duplex Speed Type Fa6/1 connected 1 a-full a-100 10/100BaseTX
statusオプションを指定せずにtheshow interfacesコマンドを使用すると、速度とデュプレックスの設定は表示されますが、この速度とデュプレックスがオートネゴシエーションで設定されたものかどうかはわかりません。
Router#show interface fas 6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
!--- Full-duplex and 100Mbps does not tell you whether autoneg was used to achieve this.
!--- Use the sh interfaces fas 6/1 status command to display this.
不良または破損したケーブル
限界に近い状態の故障や障害がないかどうかを、常に確認します。ケーブルは、物理層を接続するだけのものと考えられますが、配線やコネクタがわずかな障害を受けたためにパケットが壊れてしまうこともあります。銅ケーブルまたは光ファイバケーブルを、確認または交換します。ファイバ接続では、GBIC を交換します（着脱可能である場合）。送信元と宛先の間にある、不良なパッチ パネルおよびメディア コンバータを排除します。使用できる場合は別のポートやインターフェイスで使用しているケーブルを試してみて、同じ問題が発生するかどうかを確認します。
自動ネゴシエーションと NIC カードの問題
Cisco スイッチを特定のサードパーティ製 NIC カードと一緒に使用すると、問題が発生する場合があります。デフォルトでは、Catalyst スイッチのポートおよびインターフェイスは、自動ネゴシエーションに設定されています。ラップトップのようなデバイスや、自動ネゴシエーション設定を行うその他のデバイスで、自動ネゴシエーションに関する問題が発生する場合があります。
自動ネゴシエーションの問題をトラブルシューティングするには、両側でハードコードを試みることが推奨されます。自動ネゴシエーションとハードコード設定のどちらも機能していないように見える場合は、NIC カードのファームウェアまたはソフトウェアに問題がある可能性があります。NIC カードのドライバをベンダーの Web サイトで公開されている最新バージョンにアップグレードして、これを解決してください。
速度とデュプレックスおよびオートネゴシエーションの問題の解決方法についての詳細は、『イーサネット10/100/1000 Mb半二重/全二重オートネゴシエーションの設定とトラブルシューティング』を参照してください。
サードパーティ製 NIC の問題を解決する方法についての詳細は、『Cisco Catalyst スイッチと NIC との互換性に関する問題のトラブルシューティング』を参照してください。
スパニング ツリーのループ
スパンニング ツリー プロトコル（STP）のループによって、一見ポートやインターフェイスの問題のように見える、パフォーマンスの重大な問題が引き起こされる可能性があります。この場合は、同じフレームによって帯域幅が繰り返し使用されることにより、正当なトラフィックが使用する余地がほとんどなくなります。
STP ループ ガード機能では、レイヤ 2 の転送ループ（STP ループ）に対する防御が追加で提供されます。STP ループは、冗長なトポロジにおいて STP ブロックポートが誤ってフォワーディングステートに移行すると発生します。こうした移行は通常、物理的に冗長なトポロジのポートの 1 つ（STP ブロックポートとは限らない）が STP BPDU を受信しなくなることが原因で起こります。STP の動作は、ポートのロールに基づく BPDU の継続的な送受信に依存しています。指定ポートでは BPDU が送信され、指定ポート以外のポートでは BPDU が受信されます。
物理的に冗長化されたトポロジのいずれかのポートで BPDU が受信されなくなると、STP ではトポロジにループがないと判断されます。結果的に、代替ポートまたはバックアップポートのブロックポートが指定ポートになり、フォワーディングステートに移行します。この状況により、ループが発生してしまいます。
ループ ガード機能では、追加チェックが行われます。指定ポート以外で BPDU が受信されず、ループガードが有効になっている場合、そのポートは、リスニング/ラーニング/フォワーディングステートに移行するのではなく、STP ループ不整合ブロックステートに移行します。Loop Guard 機能がない場合、ポートは、指定ポートのロールを担ってしまいます。ポートは、STP フォワーディング ステートに移行し、ループが発生します。ループガード機能についての詳細は、『ループガードとBPDUスキュー検出によるSTPの設定』を参照してください。
このドキュメントでは、STP が失敗する原因、問題の原因を特定するために必要な情報、および STP のリスクを最小化するための設計の種類について説明しています。
ループは、単方向のリンクが原因で発生する場合もあります。詳細については、このドキュメントの「UDLD：単方向リンク」セクションを参照してください。
UDLD：一方向リンク
単方向リンクとは、トラフィックが一方向に送信されていて、入力方向のトラフィックが受信されないリンクです。スイッチはリンクの入力方向に不良があることを認識できません（ポートはリンクがアップで動作していると判断します）。
こうした単方向だけのコミュニケーションは、光ファイバ ケーブルの破損や、ケーブルやポートに関するその他の問題によっても発生する可能性があります。このようにリンクが部分的にしか機能しない場合、リンクが部分的に切断されていることが関係するスイッチに認識されないことが原因で、STP ループが発生することがあります。UDLD によって単方向リンクが検出されると、ポートが errdisable ステータスになるように UDLD を設定できます。Cisco IOS を実行しているスイッチでは、単方向リンクが許容されないスイッチ間のポイントツーポイント接続用に udldaggressive-mode コマンドを設定できます（このコマンドを使用できるかどうかは、リリースノートを確認してください）。この機能を使用すると、見つけるのが困難な単方向リンクの問題を識別しやすくなります。
UDLDの設定情報については、「UDLDプロトコル機能の設定」を参照してください。
遅延フレーム（Out-Lost または Out-Discard）
多数の遅延フレームまたは Out-Discard（一部のプラットフォームでは Out-Lost とも呼ばれます）がある場合は、スイッチの出力バッファがいっぱいになったため、スイッチがこれらのパケットをドロップする必要があったことを意味します。これは、セグメントが実行されている速度とデュプレックス（またはそのどちらか）が不良であるか、または、そのポートを通過するトラフィックが多すぎることを示している可能性があります。
OutDiscardsを調べるには、show interfaces counters errorコマンドを使用します。
Router#show interfaces counters error Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Fa7/47 0 0 0 0 0 0 Fa7/48 0 0 0 0 0 2871800 Fa8/1 0 0 0 0 0 2874203 Fa8/2 103 0 0 103 0 2878032 Fa8/3 147 0 0 185 0 0 Fa8/4 100 0 0 141 0 2876405 Fa8/5 0 0 0 0 0 2873671 Fa8/6 0 0 0 0 0 2 Fa8/7 0 0 0 0 0 0
!--- The show interfaces counters errors command shows certain interfaces !--- that increment in large amounts OutDiscards while others run clean.
出力バッファの障害の一般的な原因は次のとおりです。
速度/二重モードがトラフィック量に見合わない場合
ネットワークがこのポートを介して送信しているパケットが多すぎるため、ポートの現在の速度/デュプレックス設定では処理できない可能性があります。これは、複数の高速ポートから 1 つの（通常はより低速の）ポートにパケットが流れている場合に起こります。このポートでハングしているデバイスを、別のもっと早いメディアに移動することを検討してください。たとえば、このポートが 10 Mbps である場合、デバイスを 100 Mbps ポートまたはギガビット ポートに移動します。トポロジを変更して、フレームを別のやり方でルーティングするという方法もあります。
輻輳の問題：セグメントが非常に混雑している場合
セグメントが共有されている場合、このセグメントの他のデバイスによって、スイッチが送信できないほど大量のトラフィックが送信される場合があります。デイジーチェーンのハブは、できる限り避ける必要があります。輻輳によってパケットが失われる場合があります。パケット損失が原因でトランスポート層における再送信が発生すると、アプリケーション レベルでの遅延が起こります。可能であれば、10Mbpsリンクを100Mbpsリンクまたはギガビットイーサネットリンクにアップグレードできます。いくつかのデバイスを、混雑したセグメントから空きのあるセグメントに移動させるという方法もあります。輻輳回避をネットワーク上での優先事項としてください。
アプリケーション
使用しているアプリケーションのトラフィックの伝送特性が原因で、出力バッファの問題が発生する場合があります。この種の問題を引き起こす可能性のあるアプリケーション設定の一例として、ユーザー データグラム プロトコル（UDP）を使用するギガビット接続サーバーから 32K ウィンドウサイズで NFS ファイルを転送する場合があります。このドキュメント内の他の個所での推奨事項（速度とデュプレックスのチェック、リンク上に物理的なエラーが存在しないこと、すべてのトラフィックが正常で有効であることの確認など）を確認または試行している場合は、アプリケーションによって送信されるユニットのサイズを縮小することで、この問題を改善できる場合があります。
ソフトウェアの問題
異常としか考えられない動作が見られる場合は、その動作を特定のボックスに切り離して、ここまでに記載されている推奨事項をすべて試してみます。そうすることで、その動作の原因がソフトウェアの問題なのか、ハードウェアの問題なのかを判断できます。通常、ハードウェアをアップグレードするよりも、ソフトウェアをアップグレードする方が簡単です。まず最初にソフトウェアを変えてみてください。
現在のソフトウェアバージョンを確認するには、show versionコマンドを使用します。このとき、dir flash：コマンド（プラットフォームによって異なる）またはdir bootflash：コマンド（プラットフォームによって異なる）を使用して、アップグレードに使用できるフラッシュメモリの容量を確認します。
Router#show version Cisco Internetwork Operating System Software Cisco IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-IS-M), Version 12.1(13)EW, EA RLY DEPLOYMENT RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Fri 20-Dec-02 13:52 by eaarmas Image text-base: 0x00000000, data-base: 0x00E638AC ROM: 12.1(12r)EW Dagobah Revision 71, Swamp Revision 24 trunk-4500 uptime is 2 weeks, 2 days, 6 hours, 27 minutes System returned to ROM by redundancy reset System image file is "bootflash:cat4000-is-mz.121-13.EW.bin"
!--- Typical Cisco IOS show version output. Router#dir bootflash: Directory of bootflash:/ 1 -rw- 8620144 Mar 22 2002 08:26:21 cat4000-is-mz.121-13.EW.bin 61341696 bytes total (52721424 bytes free)
!--- Verify available flash memory on switch running Cisco IOS.
ソフトウェアのアップグレード方法
シスコスイッチのソフトウェアをアップグレードする方法については、リンクに移動し、プラットフォームを選択して、「ソフトウェアの設定」セクションを参照してください。
ハードウェアとソフトウェアの非互換性
ソフトウェアとハードウェアに互換性がない場合があります。この問題は、新しいハードウェアが登場したときに、そのハードウェアに対して、ソフトウェアによる特殊なサポートが必要な場合に起こります。ソフトウェアの互換性の詳細について参照するには、Software Advisor ツールを使用してください。
ソフトウェア バグ
オペレーティング システムに不具合がある場合もあります。この場合、より新しいソフトウェアのバージョンをロードすると、不具合を修正できる場合が多々あります。Software Bug Toolkit を使用して、既知のソフトウェアの不具合を検索することができます。
イメージの破損
イメージが破損している可能性があります。破損したイメージからの回復に関する情報については、プラットフォームスイッチを選択し、「トラブルシューティング」セクションを参照してください。
ハードウェアの問題
Cisco IOSが稼働するCatalyst 6000および4000シリーズスイッチに対するshow moduleの結果をチェックします。
スイッチの POST の結果で、スイッチのいずれかの部分に関して障害が示されていないか確認します。モジュールまたはポートのテストが失敗すると、テスト結果として「F」が表示されます。
Cat6000などのモジュラスイッチ上のCisco IOSの場合は、show diagnosticsコマンドを使用します。モジュールごとのPOST結果を表示するには、show diagnostics module <module>コマンドを使用します。
ecsj-6506-d2#sh diagnostic module 3
Current Online Diagnostic Level = Minimal
!--- The diagnostic level is set to minimal which is a shorter,
!--- but also less thorough test result.
!--- You may wish to configure diagnostic level complete to get more test results.
Online Diagnostic Result for Module 3 : MINOR ERROR
Online Diagnostic Level when Line Card came up = Minimal
Test Results: (. = Pass, F = Fail, U = Unknown)
1 . TestLoopback :
Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
. . . . . . . . . . . . . . . . . . F F F F F F
!--- Notice the MINOR ERROR test result and failed loopback test which means
!--- these ports are currently unusable.
!--- Use the hw-module{mod}reset command or, if necessary, physically reseat the
!--- module to try and fix this problem.
!--- If these steps fail, open a case with Cisco Technical Support.
Cisco IOSが稼働するCatalystスイッチのハードウェア問題をトラブルシューティングする方法の詳細については、Ciscoスイッチに関するサポートページに移動し、使用しているプラットフォームを選択して、 Troubleshooting > Hardware 。Field Notice に関連する問題については、LAN と ATM スイッチを対象にした Field Notice を参照してください。
レイヤ 2 スイッチポートに接続されたレイヤ 3 インターフェイスでの入力エラー
デフォルトでは、すべてのレイヤ 2 ポートは dynamic desirable モードになっており、レイヤ 2 ポートではトランクの形成を試行して、リモート デバイスに DTP パケットを送出します。レイヤ 3 インターフェイスはレイヤ 2 スイッチポートに接続されると、フレームの解釈ができず、その結果、入力エラー、WrongEncap エラー、入力キューの廃棄が発生します。
これを解決するには、要件に応じて、スイッチのモードを static access か trunk に切り替えます。
Switch2(config)#interface fastEthernet1/0/12 Switch2(config-if)#switchport mode access
または
Switch2(config)#interface fastEthernet1/0/12
Switch2(config-if)#switchport trunk encapsulation dot1q
Switch2(config-if)#switchport mode trunk
Rx-No-Pkt-Buff カウンタと入力エラーの急速な増加
WS-X4448-GB-RJ45、WS-X4548-GB-RJ45、WS-X4548-GB-RJ45V のようなブレードがあると、ポートで Rx-No-Pkt-Buff カウンタが増加する場合があります。また、一部のパケットドロップの増加は正常であり、トラフィックバーストの結果です。
特に、リンクを通過するトラフィックが多かったり、インターフェイスにサーバのようなデバイスが接続されていると、このタイプのエラーは急激に増加します。このトラフィックの高負荷によりポートがオーバーサブスクラブの状態になり、入力バッファが使い果たされて、Rx-No-Pkt-Buff カウンタと入力エラーが急激に増加します。
スイッチがアウトオブパケット バッファになったためにパケットを完全には受信できなくなると、このカウンタは各廃棄パケットに対して 1 回増加されます。このカウンタは、スーパーバイザ上のスイッチング ASIC の内部状態を示すもので、必ずしもエラー状態を示しているわけではありません。
ポーズ フレーム
ポートの受信側（Rx）で Rx FIFO キューがいっぱいになり、高水準点に達すると、そのポートの送信側（Tx）ではインターバル値が指定されたポーズ フレームが生成され始めます。リモート デバイスでは、ポーズ フレームに指定されたインターバルに従って、パケットの転送を停止したり、削減することになります。
Rx で Rx キューのクリアか、インターバル内での低水準点への到達が可能な場合は、Tx から、インターバルをゼロ（0x0）に指定する特殊なポーズ フレームが送出されます。これにより、リモート デバイスではパケットの転送を開始できるようになります。
Rx でキューの操作が続いている場合は、インターバルの時間が経過すると、Tx からは、再度、新しいインターバル値を指定する新しいポーズ フレームが送出されます。
Rx-No-Pkt-Buff がゼロであるか、増加しておらず、さらに TxPauseFrames カウンタが増加している場合、スイッチでポーズ フレームが生成され、リモート エンドがこれに従っていることを示しています。これにより、Rx FIFO キューは空きができます。
Rx-No-Pkt-Buff が増加して、TxPauseFrames も増加している場合、リモート エンドでポーズ フレームが無視されていて（フロー制御がサポートされておらず）、ポーズ フレームにもかかわらずトラフィックが送信され続けていることを示しています。この状況を克服するには、フロー制御をディセーブルにするだけでなく、手動でスピードとデュプレックスを設定します。
インターフェイスでのこのタイプのエラーは、ポートがオーバーサブスクライブされたことによるトラフィックの問題に関連するものです。WS-X4448-GB-RJ45、WS-X4548-GB-RJ45、WS-X4548-GB-RJ45V スイッチング モジュールには 48 のオーバーサブスクライブされたポートがあり、次のように各 8 ポートの 6 グループに分けられています。
-
ポート 1、2、3、4、5、6、7、8
-
ポート 9、10、11、12、13、14、15、16
-
ポート 17、18、19、20、21、22、23、24
-
ポート 25、26、27、28、29、30、31、32
-
ポート 33、34、35、36、37、38、39、40
-
ポート 41、42、43、44、45、46、47、48
各グループに含まれる 8 ポートは共通回線を使用し、内部スイッチファブリックへの単一のノンブロック全二重ギガビットイーサネット接続として効率的に多重化されます。8 ポート グループごとに、受信したフレームはバッファリングされて共通のギガビット イーサネット リンクに、続いて内部スイッチ ファブリックに送信されます。ポートに対して受信したデータ量がバッファ容量を超え始めた場合、フロー制御はポーズ フレームをリモート ポートに送信してトラフィックを一時的に停止し、フレーム損失を防ぎます。
グループの受信フレームが 1 Gbps の帯域幅を超えると、フレームが廃棄され始めます。このような廃棄は実際のインターフェイスではなく内部 ASIC で発生するので、明白ではありません。これにより、デバイスでのパケットのスループットの低下が発生する可能性があります。
Rx-No-Pkt-Buff は、全体的なトラフィック レートにより左右されるものではありません。このカウンタは、モジュール上の ASIC の Rx FIFO バッファに保存されるパケットの総量に依存しています。このバッファのサイズは、16 KB に過ぎません。一部のパケットがこのバッファを満たすと、トラフィックフローの短いバーストとしてカウントされます。このため、WS-X4548-GB-RJ45 が 8:1 オーバーサブスクライブド モジュールになってからは、各ポートでの Rx-No-Pkt-Buff は、この ASIC ポート グループのトラフィック総量が 1 Gbps を超過した際にカウントされる可能性があります。
インターフェイスを介して大量のトラフィックを搬送する必要のあるデバイスを使用している場合は、各グループでポートを 1 つ使用することを検討してください。このようにすると、単一のグループを共有する共通回路が、このトラフィック量の影響を受けることはありません。ギガビット イーサネット スイッチング モジュールが十分に活用されていない場合は、ポートグループ間でポート接続のバランスをとって、利用可能な帯域幅を最大化できます。たとえば、WS-X4448-GB-RJ45 10/100/1000 スイッチング モジュールでは、ポート 1、2、3、4、5、6、7、8 などの同じグループからポートを接続する前に、ポート 4、12、20、30（順不同）などの別のグループからポートを接続できます。これで問題を解決できない場合は、モジュールにはポートのオーバーサブスクリプション（加入過多）はないものと見なす必要があります。
不明なプロトコルで廃棄を理解します
不明なプロトコルのドロップがインターフェイス カウンタです。これは、ルータ/スイッチによって認識されていないプロトコルによってトリガーされます。次のshow run interfaceコマンドの例では、GigabitEthernet 0/1インターフェイスでのunknown protocol dropsが示されています。
Switch#show run interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:05, output 00:00:03, output hang never
Last clearing of "show interface" counters 16:47:42
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
3031 packets input, 488320 bytes, 0 no buffer
Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 63107 multicast, 0 pause input
0 input packets with dribble condition detected
7062 packets output, 756368 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
2015 unknown protocol drops
4762 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
不明なプロトコルのドロップは、これらのパケットが受信されたインターフェイスがプロトコルのタイプ用に設定されていない、またはルータが認識しないのはどのプロトコルですので、ドロップされます。 たとえば、2台のルータに接続されており、一つのルータ インターフェイス上でCDPをディセーブルにする場合は、そのインターフェイスの未知のプロトコルが低下します。CDPパケットは、認識されず、ドロップされます。
スイッチとルータ間でのトランキング
スイッチとルータ間のトランク リンクにより、スイッチポートがダウンになる場合があります。スイッチポートをいったんディセーブルにしてからイネーブルにすると、アップにできますが、結果的には、スイッチポートは再度ダウンになる可能性があります。
この問題を解決するには、次の手順を実行します。
-
スイッチとルータ間で Cisco Discovery Protocol（CDP）が実行されていて、スイッチとルータがどちらもお互いを認識できることを確認します。
-
ルータのインターフェイスでキープアライブを無効にします。
-
両方のデバイスで、トランク カプセル化を再設定します。
キープアライブがディセーブルにされると、CDP により、リンクが正常に動作できるようになります。
オーバーサブスクリプション（加入過多）による接続性の問題
WS-X6548-GE-TX モジュールか WS-X6148-GE-TX モジュールを使用している場合、個々のポートの使用率により、周囲のインターフェイスで接続性の問題やパケットの喪失が発生する可能性があります。オーバーサブスクリプション（加入過多）についての詳細は、『インターフェイスやモジュールの接続の問題』を参照してください。
SPA モジュールのサブインターフェイス
SPA モジュールでは、802.1Q でサブインターフェイスを作成した後にスイッチ上で同じ VLAN を使用することはできません。サブインターフェイスで dot1q をカプセル化すると、6500 または 7600 が VLAN を内部的に割り当て、そのサブインターフェイスを唯一のメンバーにするため、システムでその VLAN を使用できなくなります。 この問題を解決するには、サブインターフェイスの代わりにトランクポートを作成します。その方法では、すべてのインターフェイスで VLAN が認識されます。
出力キュー ドロップのトラブルシューティング
出力ドロップが発生するのは通常、QoS が設定されており、この QoS では特定クラスのパケットに十分な帯域幅を提供できない場合です。また、ハードウェアがオーバーサブスクリプションに達したときにも発生します。
たとえば、これがCatalyst 6500シリーズ スイッチのインターフェイスGigabitEthernet 8/9の膨大出力の低下を参照:
Switch#show interface GigabitEthernet8/9
GigabitEthernet8/9 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0013.8051.5950 (bia 0013.8051.5950)
Description: Connection To Bedok_Core_R1 Ge0/1
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 18/255, rxload 23/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is SX
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:28, output 00:00:10, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/3/0 (size/max/drops/flushes); Total output drops: 95523364
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 94024000 bits/sec, 25386 packets/sec
5 minute output rate 71532000 bits/sec, 24672 packets/sec
781388046974 packets input, 406568909591669 bytes, 0 no buffer
Received 274483017 broadcasts (257355557 multicasts)
0 runts, 0 giants, 0 throttles
3 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
749074165531 packets output, 324748855514195 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
この問題を分析するには、次のコマンドの出力を収集します。
-
show fabric utilization detail
-
、背面のエラー
-
show platform hardware capacity
-
show catalyst6000 traffic-meter
-
プラットフォーム ハードウェアのリライト エンジンのドロップを指定します
show interfaceコマンド出力の入力は持続させないでください
show interfaceコマンドの例でTenGigabitEthernet1/15インターフェイスの入力は表示されません。
Switch#show interface TenGigabitEthernet1/15
TenGigabitEthernet1/15 is up, line protocol is up (connected)
Hardware is C6k 10000Mb 802.3, address is 0025.84f0.ab16 (bia 0025.84f0.ab16)
Description: lsnbuprod1 solaris
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Gb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:17, output hang never
Last clearing of "show interface" counters 2d22h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 46000 bits/sec, 32 packets/sec
52499121 packets input, 3402971275 bytes, 0 no buffer
Received 919 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
118762062 packets output, 172364893339 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
インターフェイスによって最後にパケットが正常に受信され、ルータ上でローカルに処理されてから経過した時間、分、秒が表示されます。これは、応答のないインターフェイスでいつ障害が起こったかを知るのに役立ちます。このカウンタは、パケットが高速スイッチングのパケットがプロセス スイッチド場合にだけ更新されます。 最後の入力は、他のエンドポイントまたは端末への正常なインターフェイスのパケット転送がなかったことを意味します。通常、のこの方法は、パケット転送するエンティティではありません。
関連情報
- 「Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues（Cisco Catalyst スイッチと NIC との互換性に関する問題のトラブルシューティング）」
- PortFast と他のコマンドを使用したワークステーションの接続始動遅延の修復
- イーサネット 10/100/1000 Mbps 半二重/全二重自動ネゴシエーションの設定とトラブルシューティング
- Catalyst スイッチにおけるソフトウェアイメージのアップグレードとコンフィギュレーション ファイルの操作
- テクニカル サポートとドキュメント - Cisco Systems
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
03-Nov-2023 |
再認定 |
1.0 |
04-Dec-2001 |
初版 |
フィードバック