Catalyst 6500 スイッチで問題が発生しており、ARP キャッシュが破損していると思われます。次のような症状が現れます。
以前に解決されていないシステムに ping を実行しようとすると、最初の ping 応答はタイムアウトし、それ以降の応答はそれぞれ成功します: foo.network.com [xxx.xx.xx.xx] に 32 バイトのデータで ping を実行しています: 要求がタイムアウトしました。xxx.xx.xx.xx からの応答: バイト数 = 32、時間 = 5 ミリ秒、TTL = 55、xxx.xx.xx.xx からの応答: バイト数 = 32、時間 = 3 ミリ秒、TTL = 55、xxx.xx.xx.xx からの応答: バイト数 = 32、時間 = 3 ミリ秒、TTL = 55
破損の問題が発生すると、1 回おきの ping がタイムアウトします。32 バイトのデータで foo.network.com [xxx.xx.xx.xx] に ping を実行しています: xxx.xx.xx.xx からの応答: バイト数 = 32、時間 = 5 ミリ秒、TTL = 55、要求がタイムアウトしました。xxx.xx.xx.xx からの応答: バイト数 = 32、時間 = 5 ミリ秒、TTL = 55、要求がタイムアウトしました。
ARP キャッシュをクリアすると、問題は一時的に解決します。ARP キャッシュをクリアするには、次のコマンドを使用します: clear arp cache clear ip cache これで問題は解決しますが、必ず再発します。
スイッチの詳細:
IOS (tm) s72033_rp ソフトウェア (s72033_rp-PK9SV-M)、バージョン 12.2(17d)SXB8、リリース ソフトウェア (fc2)
cisco WS-C6509-E (R7000) プロセッサ (リビジョン 1.1)
ご協力いただければ幸いです。
説明: 当社が管理するネットワークがあり、それを企業ネットワークに接続しています。当社が管理するネットワーク内のマシンへのリクエストはすべて正常に動作します。問題が発生しているのは、他のネットワーク上のマシンのみです。
答え1
Cisco にケースを開くことをお勧めします。Cisco
は、お使いの IOS バージョンで既知のバグをチェックし、ここで公開したくない設定の詳細を尋ねます。(ただし、必要であれば、sh tech の結果をどこかに載せていただければ、役に立つかもしれません)
また、再起動後に追加されますか、それとも長時間の稼働後に破損し始めましたか?
答え2
スイッチの CLI からの PING またはスイッチに接続された PC からの PING でこの問題が発生していますか?
このスイッチはレイヤー 3 (ルーティング) 機能を提供していますか?
表示されている PING は、同じサブネット上の 2 つのデバイス間、またはサブネット間で問題が発生しているのでしょうか?
スイッチのログ (「show log hist」だと思います) に何か異常は表示されていますか?
この問題は、数台のデバイスへのパケット配信にのみ影響を及ぼしていますか、それとも多数のデバイスに影響を及ぼしていますか?
数年前、顧客サイトでこれに似た問題が発生しました。問題が発生する前と問題が発生している最中に「show mac-」の出力をキャプチャし、停止開始前と停止後に異なるポートにあると思われるデバイスを比較しました。
LAN 上に組み込みデバイス (この場合はクロック) があり、このデバイスが「偽装」された送信元アドレスを持つ一連のフレームを定期的に送信し、スイッチのブリッジング テーブルを混乱させ、しばらくの間、スイッチが間違ったポートからフレームを送信する原因になっていることがわかりました。ポートを変更すべきではないデバイスがポートを変更しているように見えることに気付き、「show mac-」出力でそれを確認することができました。
トラブルシューティングは楽しそうですね！私もそこにいられたらいいのに... >smile<
編集：
コメントありがとうございます。
「show log hist」は永続的なログを表示します。ログをクリアしない限り、スイッチの ARP キャッシュをクリアした後も、そこに報告されたメッセージはそのまま残ります。
6509 と、問題のあるデバイスが存在する企業データセンターの間に他のルーターはありますか?
動的ルーティング プロトコルを使用していますか?
私の直感はこうです:
障害が発生する前と、障害が発生したときに再度、「show mac-」と「show arp」のコピーを保存することを強くお勧めします (PuTTY などでキャプチャするのに少ししかかからないため、arp キャッシュをすぐにクリアできます)。
これらのキャプチャをここに簡単に投稿することはできないことは承知していますが、スプレッドシートまたはデータベースにキャプチャを入れて、1 つのレポートで MAC アドレスとポートを照合し、別のレポートで MAC アドレスと IP アドレスを照合することをお勧めします。「前」と「中」を比較すると、いくつかの違いがわかると思います。
6509 と企業のデータ センターの間にルーターがあると仮定すると、そのルーターの MAC アドレスがポート間で「移動」しているか、IP アドレスが MAC アドレス間で移動していることが分かると思います。
ルータがなく、企業のデータセンターのマシンがレイヤー 2 でこの 6509 と通信している場合、デバイス自体でポート間の「移動」や MAC アドレス間の IP アドレスの移動が発生する可能性があると予測されます。
答え3
ping されているクライアントでスニファーを実行すると、すべての ping が表示されますか、それとも半分だけが表示されますか?
6500 上の異なるインターフェイスから ping を送信するとどうなりますか? 6500 がデフォルト ゲートウェイとなっているホストでも発生しますか?
MAC アドレス テーブルはどのようになっていますか? traceroute はどうですか? 'ping -r9 ' はどうですか?
IOS のバグの可能性も否定できませんが、他にもさまざまな原因が考えられます...
答え4
Peter と Evan の意見に賛成です。これはキャッシュ攻撃というよりは、ルート/ポートのバウンスに似ています。特に 65xx ではそうです。Evan のコメントを補足すると、(動作中の) ARP テーブルを必ず取得してください。ただし、実際に必要なエントリはネクスト ホップ ルーターだけです。マルチパスの問題は除外しましたか? 動的ルーティング プロトコル (またはフローティング スタティック ルートを持つ複数のゲートウェイ) を実行しているかどうかを尋ねる人がいましたが、回答は見ていません。幸運を祈ります!