オンライン診断の機能概要
オンライン診断では、スイッチが稼動中のネットワークに接続されている状態でスーパーバイザ エンジン、モジュール、およびスイッチのハードウェア機能をテストし、確認できます。
オンライン診断には、個別のハードウェア コンポーネントを確認して、データ パスおよび制御信号を検証するパケット スイッチング テストが含まれます。これには、中断を伴うオンライン診断テスト(Built In Self Test(BIST)や破壊モードのループバック テストなど)と中断を伴わないオンライン診断テスト(パケット スイッチング、ブートアップ中の実行、ライン カードの Online Insertion and Removal(OIR; ホットスワップ)、システム リセット)があります。中断を伴わないオンライン診断テストは、バックグラウンド ヘルス モニタリングの一部として、またはユーザ要求(オンデマンド オンライン診断)により実行されます。
オンライン診断では、次の分野の問題が検出されます。
• ハードウェア コンポーネント
• インターフェイス(Gigabit Interface Converter(GBIC; ギガビット インターフェイス コンバータ)、イーサネット ポートなど)
• コネクタ(コネクタのゆるみ、曲がったピンなど)
• はんだ接合
• メモリ(年数経過による故障)
オンライン診断は、ハイ アベイラビリティ機能要件の 1 つです。ハイ アベイラビリティは、ネットワーク上の装置障害による影響を制限しようとする品質規格です。ハイ アベイラビリティの重要な部分は、ハードウェア障害を検出し、スイッチが稼動中のネットワークで動作している間に修正措置を実行することです。ハイ アベイラビリティのオンライン診断では、ハードウェア障害を検出して、スイッチオーバーを判断するためにハイ アベイラビリティ ソフトウェアにフィードバックします。
オンライン診断はブートアップ、オンデマンド、スケジュール、またはヘルス モニタリング診断に分類されます。ブートアップ診断は、ブートアップ、モジュール OIR、バックアップ スーパーバイザ エンジンへのスイッチオーバーの進行中に実行する機能です。オンデマンド診断は CLI から実行します。スケジュール診断は、スイッチが稼動中のネットワークに接続している状態で、ユーザが指定した間隔や指定した時間に実行します。ヘルス モニタリング診断はバックグラウンドで実行します。
オンライン診断の設定
ここでは、オンライン診断の設定手順について説明します。
• 「ブートアップ オンライン診断レベルの設定」
• 「オンデマンド オンライン診断の設定」
• 「オンライン診断のスケジューリング」
ブートアップ オンライン診断レベルの設定
ブートアップ診断レベルは、最小または完全として設定できます。または、ブートアップ オンライン診断をまったく実行しないことも選択できます。すべての診断テストを実行するには、complete キーワードを入力します。スーパーバイザ エンジンに EARL テスト、スイッチのすべてのポートにループバック テストだけを実行するには、minimal キーワードを入力します。すべての診断テストを実行しない場合は、コマンドの no 形式を入力します。ブートアップ診断レベルのデフォルトは最小です。
(注) 診断レベルはスイッチ全体に適用されます。モジュール単位の設定はできません。
ブートアップ診断レベルを設定するには、次の作業を行います。
|
|
Router(config)# diagnostic bootup level {minimal | complete} |
ブートアップ診断レベルを設定します。 |
次に、ブートアップ オンライン診断レベルを設定する例を示します。
Router(config)# diagnostic bootup level complete
次に、ブートアップ オンライン診断レベルを表示する例を示します。
Router(config)# show diagnostic bootup level
オンデマンド オンライン診断の設定
CLI からオンデマンド オンライン診断テストを実行できます。障害の検出時にテストを中止する、またはテストを続行するのどちらかに設定できます。また、障害カウントを設定し、障害が設定数に達したあとでテストを中止するように設定できます。反復設定を使用して、複数回テストを実行するように設定できます。
メモリ テストの前にパケット スイッチング テストを実行してください。スーパーバイザ エンジンにメモリ テストを実行する前に、他のモジュールに対してメモリ テストを実行してください。
(注) 次に示すすべてのステップを完了するまで、diagnostic start all コマンドは使用しないでください。
一部のオンデマンド オンライン診断テストは、他のテストの結果に影響を及ぼすことがあります。したがって、各テストは次の順序で実行する必要があります。
1. 中断を伴わないテストを実行します。
2. 関連する機能分野に含まれるすべてのテストを実行します。
3. TestTrafficStress テストを実行します。
4. TestEobcStressPing テストを実行します。
5. 完全メモリ テストを実行します。
オンデマンド オンライン診断テストを実行するには、次の作業を行います。
ステップ 1 中断を伴わないテストを実行します。
使用可能なテストとその属性を表示し、中断を伴わないカテゴリに属するコマンドを判別するには、show diagnostic content コマンドを使用します。
ステップ 2 関連する機能分野に含まれるすべてのテストを実行します。
パケット スイッチング テストは、それぞれ特定の機能分野に分類されます。特定の機能分野で問題の発生が疑われる場合は、この機能分野に含まれるすべてのテストを実行します。各モジュール上にすべての機能分野があるわけではありません。テストの必要な機能分野を明確に特定できない場合、または使用可能なすべてのテストを実行するには、complete キーワードを使用します。
ステップ 3 TestTrafficStress テストを実行します。
これは、スーパーバイザ エンジンだけに使用できる中断を伴うパケット スイッチング テストです。このテストでは、ストレス テストとして、一組のポート間でパケットをラインレートでスイッチングします。このテストの実行中、すべてのポートはシャットダウンされ、リンク フラップが生じることもあります。リンク フラップは、テストの完了後に回復しません。このテストの完了には数分かかります。
このテストを実行する前に、no diagnostic monitor module module test all コマンドを使用して、テスト対象のモジュールに対するヘルス モニタリング テストをすべてディセーブルにしてください。
ステップ 4 TestEobcStressPing テストを実行します。
これは中断を伴うテストであり、モジュールの Ethernet over Backplane Channel(EOBC)接続をテストします。このテストの完了には数分かかります。このテストの実行後は、上記の各ステップに示したすべてのパケット スイッチング テストが実行できなくなります。ただし、このテストの実行後も、これ以降に説明する各テストは実行できます。
このテストを実行する前に、no diagnostic monitor module module test all コマンドを使用して、テスト対象のモジュールに対するヘルス モニタリング テストをすべてディセーブルにしてください。このテスト中は EOBC 接続が中断されるため、ヘルス モニタリング テストが失敗し、回復アクションが実行されます。
ステップ 5 完全メモリ テストを実行します。
すべてのモジュールに、実行可能な完全メモリ テストがあります。完全メモリ テストでは、スーパーバイザ エンジンが使用不能状態になり、テスト終了後にリブートが必要となります。したがって、最初に他のすべてのモジュールのテストを実行してください。完全メモリ テストのなかには、モジュールのメモリ サイズが大きいために、完了までに数時間かかるものもあります。
完全メモリ テストを実行する前に、完全メモリ テストの実行対象となるモジュールに対するヘルス モニタリング テストをすべてディセーブルにする必要があります。これは、ヘルス モニタリングがイネーブルになっているとテストが失敗し、回復アクションが実行されてしまうためです。ヘルス モニタリング診断テストをディセーブルにするには、no diagnostic monitor module module test all コマンドを使用します。
完全メモリ テストは、次の順序で実行します(モジュールにより、実行できないテストは飛ばしてもかまいません)。
1. TestFibTcamSSRAM
2. TestAclQosTcam
3. TestNetFlowTcam
4. TestAsicMemory
5. TestAsicMemory
完全メモリ テストの実行後は、スーパーバイザ エンジンをリブートして、動作可能な状態に戻す必要があります。完全メモリ テストの実行後は、スーパーバイザ エンジンまたはその他のモジュールに対して他のテストを実行できなくなります。設定値はテスト中に変更されているため、再起動時に設定を保存しないでください。モジュールを稼動状態に戻すためには、モジュールの電源を再投入する必要があります。モジュールがオンライン状態に戻ったら、diagnostic monitor module module test all コマンドを使用して、ヘルス モニタリング テストを再度イネーブルにします。
ブートアップ診断レベルを設定するには、次の作業を行います。
|
|
Router# diagnostic ondemand {iteration iteration_count } | { action-on-error {continue | stop }[ error_count ]} |
実行するオンデマンド診断テスト、実行回数(反復)、エラーを検出したときに実行する処置を設定します。 |
次に、オンデマンド テスト反復カウントを設定する例を示します。
Router# diagnostic ondemand iteration 3
次に、エラーを検出したときに実行する処置を設定する例を示します。
Router# diagnostic ondemand action-on-error continue 2
オンライン診断のスケジューリング
特定のモジュールに対して、指定日の指定時間、または毎日、毎週、毎月ベースでオンライン診断をスケジューリングできます。あるインターバルで 1 回だけ、または繰り返しテストを実行するようにスケジューリングできます。スケジュールを削除する場合は、コマンドの no 形式を使用します。
オンライン診断をスケジューリングするには、次の作業を行います。
|
|
Router(config)# diagnostic schedule { module num } test { test_id | test_id_range | all } [ port { num | num_range | all }] { on mm dd yyyy hh : mm } | { daily hh : mm } | { weekly day_of_week hh : mm } |
特定の日時のオンデマンド診断テスト、実行回数(反復)、エラーを検出したときに実行する処置をスケジューリングします。 |
次に、特定のモジュールおよびポートについて、特定の日時に診断テストを実行するようにスケジューリングする例を示します。
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 on january 3 2003 23:32
次に、特定のポートおよびモジュールについて、毎日一定の時間に診断テストを実行するようにスケジューリングする例を示します。
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 daily 12:34
次に、特定のポートおよびモジュールについて、毎週一定の曜日に診断テストを実行するようにスケジューリングする例を示します。
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 weekly friday 09:23
ヘルス モニタリング診断の設定
スイッチが稼動中のネットワークに接続されている状態で、特定のモジュールに対するヘルス モニタリング診断テストを設定できます。ヘルス モニタリング診断テストの実行間隔や、テストに障害が発生したときにシステム メッセージを生成するかどうかを設定できるほか、各テストをイネーブルまたはディセーブルに設定できます。テストをディセーブルにする場合は、このコマンドの no 形式を使用します。
ヘルス モニタリング診断テストを設定するには、次の作業を行います。
|
|
|
ステップ 1 |
Router(config)# diagnostic monitor interval { module num } test { test_id | test_id_range | all } [ hour hh ] [ min mm ] [ second ss ] [ millisec ms ] [ day day ] |
特定のモジュールに対する特定のテストについて、ヘルス モニタリングの実行間隔を設定します。このコマンドの no 形式は、間隔をデフォルトまたは 0 に変更します。 |
ステップ 2 |
Router(config)#[no] diagnostic monitor {module num } test { test_id | test_id_range | all} |
ヘルス モニタリング診断テストをイネーブルまたはディセーブルにします。 |
次に、2 分ごとに指定されたテストを実行するように設定する例を示します。
Router(config)#
diagnostic monitor interval module 1 test 1 min 2
次に、ヘルス モニタリングがそれまでイネーブル状態でない場合に、特定のモジュールに対してテストを実行する例を示します。
Router(config)#
diagnostic monitor module 1 test 1
次に、ヘルス モニタリング テストが失敗したときに Syslog メッセージを生成する例を示します。
Router(config)#
diagnostic monitor syslog
オンライン診断テストの実行
オンライン診断を設定したあと、診断テストを開始または中止したり、またはテスト結果を表示したりできます。また、各モジュールに設定されているテストや、すでに実行された診断テストを確認することもできます。
ここでは、オンライン診断テストを設定したあとに実行する例を示します。
• 「オンライン診断テストの開始および停止」
• 「オンライン診断テストおよびテスト結果の表示」
オンライン診断テストの開始および停止
スイッチまたは個々のモジュールに実行する診断テストを設定したあと、診断テストを開始または停止するには start および stop を使用します。
オンライン診断コマンドを開始または停止するには、次の作業を行います。
|
|
diagnostic start {module num } test { test_id | test_id_range | minimal | complete | basic | per-port | non-disruptive | all} [port { num | port#_range | all}] |
特定のモジュールおよびポートまたは一定範囲のポートに対する診断テストを開始します。 |
diagnostic stop {module num } |
特定のモジュールに対する診断テストを停止します。 |
次に、特定のモジュールに対する診断テストを開始する例を示します。
Router# diagnostic start module 1 test 5
Module 1:Running test(s) 5 may disrupt normal system operation
Do you want to run disruptive tests? [no]yes
00:48:14:Running OnDemand Diagnostics [Iteration #1] ...
00:48:14:%DIAG-SP-6-TEST_RUNNING:Module 1:Running TestNewLearn{ID=5} ...
00:48:14:%DIAG-SP-6-TEST_OK:Module 1:TestNewLearn{ID=5} has completed successfully
00:48:14:Running OnDemand Diagnostics [Iteration #2] ...
00:48:14:%DIAG-SP-6-TEST_RUNNING:Module 1:Running TestNewLearn{ID=5} ...
00:48:14:%DIAG-SP-6-TEST_OK:Module 1:TestNewLearn{ID=5} has completed successfully
次に、特定のモジュールに対する診断テストを停止する例を示します。
Router# diagnostic stop module 3
オンライン診断テストおよびテスト結果の表示
show コマンドを使用すると、特定のモジュールに対して設定されたオンライン診断テストを表示し、テスト結果を確認できます。
特定のモジュールに設定された診断テストを表示するには、次の作業を行います。
|
|
show diagnostic content [module num ] |
特定のモジュールに設定されているオンライン診断を表示します。 |
次に、特定のモジュールに設定されているオンライン診断を表示する例を示します。
Router# show diagnostic content module 7
Diagnostics test suite attributes:
M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/* - Basic ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
R/* - Power-down line cards and need reset supervisor / NA
K/* - Require resetting the line card after the test has completed / NA
ID Test Name Attributes (day hh:mm:ss.ms)
==== ================================== ============ =================
1) TestScratchRegister -------------> ***N****A** 000 00:00:30.00
2) TestSPRPInbandPing --------------> ***N****A** 000 00:00:15.00
3) TestTransceiverIntegrity --------> **PD****I** not configured
4) TestActiveToStandbyLoopback -----> M*PDS***I** not configured
5) TestLoopback --------------------> M*PD****I** not configured
6) TestNewLearn --------------------> M**N****I** not configured
7) TestIndexLearn ------------------> M**N****I** not configured
8) TestDontLearn -------------------> M**N****I** not configured
9) TestConditionalLearn ------------> M**N****I** not configured
10) TestBadBpdu ---------------------> M**D****I** not configured
11) TestTrap ------------------------> M**D****I** not configured
12) TestMatch -----------------------> M**D****I** not configured
13) TestCapture ---------------------> M**D****I** not configured
14) TestProtocolMatch ---------------> M**D****I** not configured
15) TestChannel ---------------------> M**D****I** not configured
16) TestFibDevices ------------------> M**N****I** not configured
17) TestIPv4FibShortcut -------------> M**N****I** not configured
18) TestL3Capture2 ------------------> M**N****I** not configured
19) TestIPv6FibShortcut -------------> M**N****I** not configured
20) TestMPLSFibShortcut -------------> M**N****I** not configured
21) TestNATFibShortcut --------------> M**N****I** not configured
22) TestAclPermit -------------------> M**N****I** not configured
23) TestAclDeny ---------------------> M**D****I** not configured
24) TestQoSTcam ---------------------> M**D****I** not configured
25) TestL3VlanMet -------------------> M**N****I** not configured
26) TestIngressSpan -----------------> M**N****I** not configured
27) TestEgressSpan ------------------> M**N****I** not configured
28) TestNetflowInlineRewrite --------> C*PD****I** not configured
29) TestFabricSnakeForward ----------> M**N****I** not configured
30) TestFabricSnakeBackward ---------> M**N****I** not configured
31) TestFibTcamSSRAM ----------------> ***D****IR* not configured
32) ScheduleSwitchover --------------> ***D****I** not configured
次に、特定のモジュールのオンライン診断結果を表示する例を示します。
Router# show diagnostic result module 5
Current bootup diagnostic level:minimal
Overall Diagnostic Result for Module 5 :PASS
Diagnostic level at card bootup:minimal
Test results:(. = Pass, F = Fail, U = Untested)
1) TestScratchRegister -------------> .
2) TestSPRPInbandPing --------------> .
4) TestActiveToStandbyLoopback:
6) TestNewLearn --------------------> .
7) TestIndexLearn ------------------> .
8) TestDontLearn -------------------> .
9) TestConditionalLearn ------------> .
10) TestBadBpdu ---------------------> .
11) TestTrap ------------------------> .
12) TestMatch -----------------------> .
13) TestCapture ---------------------> .
14) TestProtocolMatch ---------------> .
15) TestChannel ---------------------> .
16) TestIPv4FibShortcut -------------> .
17) TestL3Capture2 ------------------> .
18) TestL3VlanMet -------------------> .
19) TestIngressSpan -----------------> .
20) TestEgressSpan ------------------> .
21) TestIPv6FibShortcut -------------> .
22) TestMPLSFibShortcut -------------> .
23) TestNATFibShortcut --------------> .
24) TestAclPermit -------------------> .
25) TestAclDeny ---------------------> .
26) TestQoSTcam ---------------------> .
27) TestNetflowInlineRewrite:
28) TestFabricSnakeForward ----------> .
29) TestFabricSnakeBackward ---------> .
30) TestFibTcam - RESET -------------> U
次に、特定のモジュールの詳細なオンライン診断結果を表示する例を示します。
Router# show diagnostic result module 5 detail
Current bootup diagnostic level:minimal
Overall Diagnostic Result for Module 5 :PASS
Diagnostic level at card bootup:minimal
Test results:(. = Pass, F = Fail, U = Untested)
___________________________________________________________________________
1) TestScratchRegister -------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 330
Last test execution time ----> May 12 2003 14:49:36
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 12 2003 14:49:36
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
2) TestSPRPInbandPing --------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 660
Last test execution time ----> May 12 2003 14:49:38
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 12 2003 14:49:38
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 0
Last test execution time ----> n/a
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> n/a
Total failure count ---------> 0
Consecutive failure count ---> 0
________________________________________________________________________
スケジュール スイッチオーバー
スケジュール スイッチオーバー テストを使用すると、アクティブなスーパーバイザ エンジンが故障した場合やアウト オブ サービス状態になった場合にスタンバイのスーパーバイザ エンジンがテイクオーバーできるようになっているかどうかを確認できます。このテストは 1 回実行することも、また定期的に(毎日、毎週、毎月)実行するようにスケジューリングすることもできます。
(注) 両方のスーパーバイザ エンジンにスケジュール スイッチオーバーの時間を設定する場合は、スイッチオーバーが失敗した場合のシステムのダウンタイムを小さくするために、アクティブおよびスタンバイのスーパーバイザ エンジンのスイッチオーバーを 10 分以上あけてスケジューリングしてください。
スケジュール スイッチオーバーを設定するには、次の作業を行います。
|
|
|
ステップ 1 |
show diagnostic content [module num ] |
特定のモジュールに設定されているオンライン診断を表示します。このコマンドを使用すると、スケジュール スイッチオーバーのテスト ID を取得できます。 |
ステップ 2 |
Router(config)# diagnostic schedule module {num | active-sup-slot} test {test-id} {on mm dd yyyy hh:mm} | {daily hh:mm } | {weekly day-of-week hh:mm} |
特定のスーパーバイザ エンジンに対して、特定日時のスケジュール スイッチオーバーを設定します。 |
次に、アクティブ スーパーバイザ エンジンからのスイッチオーバーを毎週金曜日の午後 10:00 に実行し、その 10 分後に再びスタンバイ スーパーバイザ エンジンからアクティブ スーパーバイザ エンジンに切り替えるようにスケジューリングする例を示します。
Router(config)# diagnostic schedule module 5 test 32 weekly Friday 22:00
Router(config)# diagnostic schedule module 6 test 32 weekly Friday 22:10
メモリ テストの実行
大半のオンライン診断テストでは、特別なセットアップまたは設定は不要です。ただし、TestFibTcamSSRAM および TestLinecardMemory テストを含むメモリ テストの場合、テストを実行する前に必須の作業や推奨された作業をいくつか行う必要があります。
オンライン診断メモリ テストを実行する前に、次の作業を行います。
• 必須作業
– すべての接続ポートをディセーブルにして、ネットワーク トラフィックを分離します。
– メモリ テスト中はテスト パケットを送信しないでください。
– スーパーバイザ エンジンの Policy Feature Card(PFC; ポリシー フィーチャ カード)上の FIB TCAM および SSRAM をテストする場合は、すべてのスイッチング モジュールを取り外します。
– システムを正常な動作モードに戻すためには、テストするシステムまたはモジュールをリセットする必要があります。
(注) no diagnostic monitor module num test all コマンドを使用して、スーパーバイザ エンジンおよびスイッチング モジュールに対するバッグラウンドのヘルス モニタリング テストをすべてオフにしてください。
診断の健全性チェック
ネットワーク内の潜在的な問題領域を検出するため、診断の健全性チェックを実行できます。健全性チェックでは、想定される特定のシステム状態の組み合わせを使用した設定に対し、事前定義した一連のチェックを実行して、警告状況の一覧を生成します。このチェックの目的は、不適切な状態の要素がないかどうかを調べ、システムの健全性を維持するための支援を行うことです。
診断の健全性チェックを実行するには、次の作業を行います。
|
|
show diagnostic sanity |
Catalyst 6500 シリーズ スイッチのすべてのギガビット イーサネット WAN インターフェイスで、一連のテストを実行します。 |
次の例は、 show diagnostic sanity コマンドの結果として表示される可能性があるメッセージの例を示します。
Router# show diagnostic sanity
Pinging default gateway 10.6.141.1 ....
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.141.1, timeout is 2 seconds:
Success rate is 0 percent (0/5)
IGMP snooping disabled please enable it for optimum config.
IGMP snooping disabled but RGMP enabled on the following interfaces,
please enable IGMP for proper config :
Vlan1, Vlan2, GigabitEthernet1/1
Multicast routing is enabled globally but not enabled on the following
GigabitEthernet1/1, GigabitEthernet1/2
A programming algorithm mismatch was found on the device bootflash:
Formatting the device is recommended.
The bootflash: does not have enough free space to accomodate the crashinfo file.
Please check your confreg value : 0x0.
Please check your confreg value on standby: 0x0.
The boot string is empty. Please enter a valid boot string .
Could not verify boot image "disk0:" specified in the boot string on the
Invalid boot image "bootflash:asdasd" specified in the boot string on the
Please check your boot string on the slave.
UDLD has been disabled globally - port-level UDLD sanity checks are
The following ports have UDLD disabled. Please enable UDLD for optimum
The following ports have an unknown UDLD link state. Please enable UDLD
on both sides of the link:
The following ports have portfast enabled:
The following ports have trunk mode set to on:
The following trunks have mode set to auto:
The following ports with mode set to desirable are not trunking:
The following trunk ports have negotiated to half-duplex:
The following ports are configured for channel mode on:
Fa4/1, Fa4/2, Fa4/3, Fa4/4
The following ports, not channeling are configured for channel mode
The following vlan(s) have a spanning tree root of 32768:
The following vlan(s) have max age on the spanning tree root different from
The following vlan(s) have forward delay on the spanning tree root different
The following vlan(s) have hello time on the spanning tree root different
The following vlan(s) have max age on the bridge different from the
The following vlan(s) have fwd delay on the bridge different from the
The following vlan(s) have hello time on the bridge different from the
The following vlan(s) have a different port priority than the default
on the port FastEthernet4/1
The following ports have recieve flow control disabled:
The following inline power ports have power-deny/faulty status:
The following ports have negotiated to half-duplex:
The following vlans have a duplex mismatch:
The following interafaces have a native vlan mismatch:
interface (native vlan - neighbor vlan)
The value for Community-Access on read-only operations for SNMP is the same
as default. Please verify that this is the best value from a security point
The value for Community-Access on write-only operations for SNMP is the same
as default. Please verify that this is the best value from a security point
The value for Community-Access on read-write operations for SNMP is the same
as default. Please verify that this is the best value from a security point
Please check the status of the following modules:
Module 2 had a MINOR_ERROR.
The Module 2 failed the following tests:
The following ports from Module2 failed test1: