web-dev-qa-db-ja.com

ARPブロードキャストフラッディングネットワークと高いCPU使用率

ここの誰かが私たちが直面している問題について何らかの洞察を持っていることを願っています。現在、Cisco TACがケースを調査していますが、根本的な原因を見つけるのに苦労しています。

タイトルにはARPブロードキャストと高いCPU使用率が記載されていますが、この段階ではそれらが関連しているかどうかは不明です。

元の問題は INEオンラインコミュニティに投稿されました

ネットワークを冗長構成のない単一のリンクに落としました。これをスター型トポロジーと考えてください。

事実：

  • 3750xスイッチを使用し、4つを1つのスタックで使用します。バージョン15.0（1）SE3。 Cisco TACは、この特定のバージョンの高CPUまたはARPバグの既知の問題を確認していません。
  • ハブ/管理されていないスイッチが接続されていません
  • リロードされたコアスタック
  • デフォルトルート「Ipルート0.0.0.0 0.0.0.0 f1/0」はありません。ルーティングにOSPFを使用します。
  • VLAN 1、VLAN 1はデスクトップデバイスに使用されます。192.168.0.0/ 20を使用します。
  • Cisco TACによると、/ 20を使用しても何も問題がないとのことです。それ以外の場合は、大規模なブロードキャストドメインがあるはずですが、機能するはずです。
  • Wifi、管理、プリンターなどはすべて異なるVLAN上にあります
  • スパニングツリーは、Cisco TACおよびCCNP/CCIEの認定を受けた個人によって検証されています。すべての冗長リンクをシャットダウンします。
  • コアの設定はCisco TACで検証されています。
  • ほとんどのスイッチにデフォルトのARPタイムアウトがあります。
  • Q＆Qは実施しておりません。
  • 新しいスイッチは追加されていません（少なくとも、私たちが知っているスイッチはありません）
  • エッジスイッチは2950であるため、ダイナミックARPインスペクションを使用できません
  • Show interfacesを使用しました| inc line | broadcastは、多数のブロードキャストがどこから送信されているかを把握しますが、Cisco TACと2人の他のエンジニア（CCNP＆CCIE）の両方が、ネットワークで何が起こっているかにより（これは多数のmacフラップのように）正常な動作であることを確認しましたより大きな放送を引き起こす）。 STPがEdgeスイッチで正しく機能していたことを確認しました。

ネットワークとスイッチの症状：

  • 多数のMACフラップ
  • ARP入力プロセスのCPU使用率が高い
  • 膨大な数のARPパケット、急速に増加して見える
  • Wiresharksは、数百台のコンピューターがARPブロードキャストでネットワークに殺到していることを示しています
  • テストの目的で、約80台のデスクトップマシンに異なるVLANを配置しましたが、これをテストして、高CPUまたはARP入力に目に見える違いはありませんでした
  • 別のAV /マルウェア/スパイウェアを実行しましたが、ネットワーク上でウイルスは見えません。
  • sh macアドレステーブルカウントは、VLAN 1で予想される約750の異なるMACアドレスを示します。
#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri
  • さまざまなスイッチとコア自体（たとえば、デスクトップ上で直接プラグインされているコア上にあるコア）でMACアドレステーブルを実行すると、インターフェイスに登録されているにもかかわらず、いくつかの異なるMACハードウェアアドレスがインターフェイスに登録されていることがわかりますこれに接続されている1台のコンピューターのみ：
 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3
  • プラットフォームのTCAM使用率を表示する
 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

現在、この奇妙で奇妙な問題の原因または根本的な原因を特定するためのアイデアが他にない限り、各エリアを一度に分離するために大量のダウンタイムが必要になる段階にあります。

更新

詳細な回答をありがとう@MikePenningtonと@RickyBeam。私ができることを試して答えます。

  • 前述のように、192.168.0.0/20は継承された混乱です。ただし、将来的には分割する予定ですが、残念ながらこの問題が発生する前にこの問題が発生しました。私も個人的には多数派に同意します。これにより、ブロードキャストドメインが大きすぎます。
  • Arpwatchの使用は間違いなく試すことができるものですが、いくつかのアクセスポートはこのポートに属していなくてもMACアドレスを登録しているため、arpwatchの結論が役に立たない可能性があります。
  • ネットワーク上のすべての冗長リンクと不明なスイッチを100％確実に検出できないことに私は完全に同意します。
  • ポートセキュリティが調査されましたが、残念ながら、管理者はさまざまな理由でこれを使用しないことにしました。一般的な理由は、コンピューターを常に移動することです（大学環境）。
  • すべてのアクセスポート（デスクトップマシン）では、デフォルトでスパニングツリーbpduguardとともにスパニングツリーPortFastを使用しています。
  • 現在、アクセスポートではネゴシエートしないスイッチポートを使用していませんが、複数のVLAN間でバウンドするVLANホッピング攻撃は受けていません。
  • Mac-address-table通知を実行し、パターンが見つかるかどうかを確認します。

「スイッチポート間で多数のMACフラップが発生しているため、攻撃者の場所を見つけるのは困難です（大量のARPを送信する2つまたは3つのMACアドレスを見つけたが、送信元MACアドレスがポート間でフラッピングを続けると想定してください）。」

  • 私たちはこれから始めて、MACフラップを1つ選び、すべてのコアスイッチを経由してディストリビューションからアクセススイッチへと進みましたが、アクセスポートインターフェイスが複数のMACアドレスを占有しているため、MACフラップが発生しています。スクエアワンに戻ります。
  • ストーム制御は私たちが検討したことですが、正当なパケットの一部がドロップされてさらに問題が発生するのではないかと心配しています。
  • VMHost構成をトリプルチェックします。
  • 説明できないMACアドレスは、個人ではなく多くのアクセスポートの背後にあります。これらのインターフェースでループが見つかりませんでした。 MACアドレスは他のインターフェイスにも存在するため、多数のMACフラップが説明されます。
  • @RickyBeam私は、ホストが非常に多くのARP要求を送信する理由に同意します。これは不可解な問題の1つです。 Rougeワイヤレスブリッジは興味深いものです。私たちが知る限り、ワイヤレスは別のVLAN上にあります。ただし、ローグは明らかにVLAN1にある可能性があることを意味します。
  • @RickyBeam、私はすべてのプラグを抜きたくありません。これは大量のダウンタイムを引き起こすためです。しかし、これはまさにそれが向かっているかもしれないところです。 Linuxサーバーはありますが、3台以下です。
  • @ RickyBeam、DHCPサーバーの「使用中」のプローブについて説明できますか？

私たち（Cisco TAC、CCIE、CCNP）は、これがスイッチ構成ではなく、ホスト/デバイスが問題の原因であることに全面的に同意しています。

ciscoethernetarp
20
Cold T

解決しました。

問題はSCCM 2012 SP1、次のサービスと呼ばれます：ConfigMrg Wake-Up Proxyです。「機能」は存在しないSCCM 2012 RTM。

ポリシーでこれをオフにしてから4時間以内に、CPU使用率は着実に低下しました。 4時間経過するまでに、ARPの使用率は1〜2％にすぎませんでした。

要約すると、このサービスはMACアドレスのスプーフィングを行います！それがどれほどの大混乱を引き起こしたか信じられない。

これが投稿された問題とどのように関連しているかを理解することが重要だと思うので、以下はMicrosoft Technetからの全文です。

興味のある方のために、以下は技術的な詳細です。

Configuration Managerは、ソフトウェアの更新やアプリケーションなどの必要なソフトウェア（従来のウェイクアップパケットとAMTパワーオンコマンド）をインストールするときに、スリープモードでコンピューターをウェイクアップする2つのウェイクオンローカルエリアネットワーク（LAN）テクノロジをサポートしています。

Configuration Manager SP1以降、ウェイクアッププロキシクライアント設定を使用して、従来のウェイクアップパケット方式を補足できます。ウェイクアッププロキシは、ピアツーピアプロトコルと選択されたコンピューターを使用して、サブネット上の他のコンピューターがウェイクアップしているかどうかを確認し、必要に応じてウェイクアップします。サイトがWake On LAN用に構成され、クライアントがウェイクアッププロキシ用に構成されている場合、プロセスは次のように機能します。

  1. Configuration Manager SP1クライアントがインストールされていて、サブネット上でスリープしていないコンピューターは、サブネット上の他のコンピューターが起動しているかどうかを確認します。これは、5秒ごとにTCP/IP pingコマンドを相互に送信することによって行われます。

  2. 他のコンピュータからの応答がない場合、それらはスリープしていると見なされます。稼働中のコンピューターは、サブネットのマネージャーコンピューターになります。

  3. コンピューターがスリープ状態ではない（電源がオフになっている、ネットワークから削除されている、プロキシウェイクアップクライアント設定が適用されていないなど）ためにコンピューターが応答しない可能性があるため、コンピューターは毎日午後2時にウェイクアップパケットを送信現地時間。応答しないコンピュータは、スリープ状態であると見なされなくなり、ウェイクアッププロキシによってウェイクアップされません。

ウェイクアッププロキシをサポートするには、サブネットごとに少なくとも3台のコンピュータがウェイクアップしている必要があります。これを実現するために、3つのコンピューターがサブネットのガーディアンコンピューターとして非決定的に選択されます。これは、一定の非アクティブ状態の後にスリープまたはハイバネートするように構成された電源ポリシーにもかかわらず、それらが起きていることを意味します。 Guardianコンピューターは、例えば、保守タスクの結果として、シャットダウンまたは再起動コマンドを受け入れます。これが発生した場合、残りのガーディアンコンピュータはサブネット上の別のコンピュータを起動し、サブネットに引き続き3つのガーディアンコンピュータが存在するようにします。

マネージャコンピュータは、スリープ状態のコンピュータのネットワークトラフィックを自分自身にリダイレクトするようにネットワークスイッチに要求します。

リダイレクションは、スリープ状態のコンピューターのMACアドレスをソースアドレスとして使用するイーサネットフレームをブロードキャストするマネージャーコンピューターによって実現されます。これにより、ネットワークスイッチは、スリープ状態のコンピューターがマネージャーコンピューターと同じポートに移動したかのように動作します。また、マネージャーコンピューターは、スリープ状態のコンピューターにARPパケットを送信して、ARPキャッシュのエントリを最新の状態に保ちます。また、マネージャーコンピューターは、スリープ状態のコンピューターに代わってARP要求に応答し、スリープ状態のコンピューターのMACアドレスで応答します。

このプロセス中、スリープ状態のコンピューターのIPからMACへのマッピングは同じままです。ウェイクアッププロキシは、別のネットワークアダプターが別のネットワークアダプターによって登録されたポートを使用していることをネットワークスイッチに通知することで機能します。ただし、この動作はMACフラップと呼ばれ、標準のネットワーク操作では異常です。一部のネットワーク監視ツールは、この動作を探し、何かが間違っていると想定できます。その結果、これらの監視ツールは、ウェイクアッププロキシを使用するときにアラートを生成したり、ポートをシャットダウンしたりできます。ネットワーク監視ツールとサービスがMACフラップを許可しない場合は、ウェイクアッププロキシを使用しないでください。

  1. マネージャーコンピューターがスリープ状態のコンピューターの新しいTCP接続要求を認識し、その要求が、スリープ状態になる前にスリープ状態のコンピューターがリッスンしていたポートに対するものである場合、マネージャーコンピューターはウェイクパケットをスリープ状態のコンピューターに送信し、このコンピューターのトラフィックのリダイレクトを停止します。

  2. スリープ状態のコンピュータは、ウェイクアップパケットを受信して​​ウェイクアップします。送信側のコンピューターは自動的に接続を再試行し、今度はコンピューターが起動して応答できます。

参照： http://technet.Microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

ここに投稿し、トラブルシューティングプロセスを支援してくれた皆さん、ありがとうございました。

12
Cold T

ARP /ブロードキャストストーム

  • VLAN 1、VLAN 1はデスクトップデバイスに使用されます。192.168.0.0/ 20を使用します。
  • Wiresharksは、数百台のコンピューターがARPブロードキャストでネットワークに殺到していることを示しています...

ARP入力プロセスが高い。つまり、スイッチはARPの処理に多くの時間を費やしています。 ARPフラッディングの非常に一般的な原因の1つは、スイッチ間のループです。ループがある場合は、上記のMACフラップも取得できます。 ARPフラッドの他の考えられる原因は次のとおりです。

まず、上記の設定ミスやレイヤー2攻撃の可能性を排除します。これを行う最も簡単な方法は、Linuxマシンで arpwatch を使用することです（ラップトップで livecd を使用する必要がある場合でも）。設定ミスまたはレイヤー2攻撃がある場合、arpwatchは、syslogに次のようなメッセージを表示します。これは、同じIPアドレスを争っているMACアドレスをリストします...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

「フリップフロップ」が表示されたら、MACアドレスのソースを追跡し、それらが同じIPで争っている理由を理解する必要があります。

  • 多数のMACフラップ
  • スパニングツリーは、Cisco TACおよびCCNP/CCIEの認定を受けた個人によって検証されています。すべての冗長リンクをシャットダウンします。

私が思い出したいよりも何度もこれを経験している人と言えば、すべての冗長リンクが見つかったとは思わないでください。スイッチポートが常に動作するようにしてください。

スイッチポート間で多数のMACフラップが発生しているため、攻撃者の場所を見つけるのは困難です（大量のARPを送信する2つまたは3つのMACアドレスが見つかりましたが、送信元MACアドレスはポート間でフラッピングを続けていると想定しています）。エッジポートごとにMACアドレスにハード制限を適用しない場合、手動でケーブルを外さずにこれらの問題を追跡することは非常に困難です（これは避けたいことです）。スイッチループはネットワークに予期しないパスを引き起こし、通常はデスクトップスイッチポートであるはずのものから断続的に学習する何百ものMacで終了する可能性があります。

Mac-movesを遅くする最も簡単な方法は port-security 。単一のPC（ダウンストリームスイッチなし）に接続されているVLAN 1のすべてのアクセススイッチポートで、Ciscoスイッチで次のインターフェイスレベルのコマンドを構成します...

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

ほとんどのmac/ARPフラッディングのケースでは、この構成をすべてのエッジスイッチポート（特に、PortFastを使用するもの）に適用すると、正常な状態に戻ります。これは、3つのMACアドレスを超えるポートをシャットダウンし、密かに無効にするためです。ループPortFastポート。ポートあたり3つのMacは、私のデスクトップ環境で適切に機能する数ですが、10に上げると、おそらく問題ありません。これを実行すると、レイヤー2ループがすべて切断され、迅速なMACフラップが停止し、診断がはるかに容易になります。

ブロードキャストストーム（mac-move）とフラッディング（しきい値）に関連するポートを追跡するのに役立つグローバルコマンドの別のカップル...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

完了したら、オプションでclear mac address-table潜在的に完全なCAMテーブルからの修復を加速します。

  • さまざまなスイッチとコア自体（たとえば、デスクトップ上で直接プラグインされているコア上にあるコア）でMACアドレステーブルを実行すると、インターフェイスに登録されているにもかかわらず、いくつかの異なるMACハードウェアアドレスがインターフェイスに登録されていることがわかりますこれに接続されているコンピュータは1台だけ...

この全体の答えは、3750に問題の原因となるバグがないことを前提としています（ただし、wiresharkはPCがフラッディングしていることを示したと言いました）。コンピューターがVMWareのようなものを持っていない限り、Gi1/1/3に接続されているコンピューターが1台だけの場合、表示されている内容は明らかに間違っています。

その他の考え

私たちが行ったチャットの会話に基づいて、私はおそらく明白なことを言う必要はありませんが、将来の訪問者のために...

  • ユーザーをVlan1に配置することは、通常、悪い考えです（混乱を継承している可能性があることを理解しています）。
  • TACの指示に関係なく、192.168.0.0/20は大きすぎて、レイヤー2攻撃のリスクなしに単一のスイッチドメインで管理できません。 ARPは認証されていないプロトコルであり、ルーターは少なくともそのサブネットから有効なARPを読み取る必要があるため、サブネットマスクが大きいほど、このようなレイヤー2攻撃にさらされる可能性が高くなります。
  • レイヤー2ポートのストーム制御も通常は良い考えです。ただし、このような状況でストームコントロールを有効にすると、良好なトラフィックと不良なトラフィックが排除されます。ネットワークが回復したら、エッジポートとアップリンクにストーム制御ポリシーを適用します。
10
Mike Pennington

本当の問題は、ホストがそもそもなぜそれほど多くのARPを送信するのかということです。これが解決されるまで、スイッチはarpストームを処理するのに苦労し続けます。ネットマスクの不一致？ホストのarpタイマーが不足していますか？ 1つ（またはそれ以上）hosts「インターフェース」ルートがありますか？どこかに荒れ狂う無線ブリッジ？ 「無償のARP」が狂ってしまった？ DHCPサーバーの「使用中」のプロービング？スイッチやレイヤー2の問題のようには聞こえません。あなたは悪いことをしているホストを持っています。

私のデバッグプロセスでは、すべてのプラグを抜いて、一度に1ポートずつ、再接続されるのを注意深く監視します。 （私はそれが理想から数マイル離れていることを知っていますが、ある時点で損失を削減し、可能なソースを物理的に分離する必要があります）次に、選択ポートがいくつかのARPを生成している理由を理解するように努力します。

（これらのホストの多くはたまたまlinuxシステムでしょうか？Linuxは非常にd *** medの愚かなARPキャッシュ管理システムを持っていました。それがほんの数分でエントリを「再検証」するという事実は私の本では壊れています。 。小規模ネットワークでは問題が少ない傾向にありますが、/ 20は小規模ネットワークではありません）。

2
Ricky Beam

これはあなたの問題に関連しているかもしれないし、していないかもしれませんが、私はそれを少なくともそこに捨てる価値があるかもしれないと考えました：

現在、いくつかのリモートサイトにはかなりの数のスタックされた3750xがあり、主に15.0.2を実行しています（SE0から4まで、SE0からいくつかのFRUバグがあり、徐々に移行しています）。

定期的なIOSの更新中に、15.0.2から15.2-1（最新のSE）に移行すると、オフピーク時に平均で約30％から60％以上のかなりのCPUの増加に気づきました回。構成とIOS変更ログを確認し、シスコのTACと連携してきました。 TACによると、彼らは、これがIOS 15.2-1のバグであると信じる段階にあるようです。

CPUの増加を調査し続けると、ARPテーブルが完全にいっぱいになり、ネットワークが不安定になるまで、大量のARPトラフィックが発生し始めました。このための一時的な問題は、音声およびデータVLANでARPタイムアウトをデフォルト（14400）から300に手動で戻すことでした。

ARPタイムアウトを減らした後、1週間ほど安定しました。その時点でIOS 15.0.2-SE4に戻り、デフォルト以外のARPタイムアウトを削除しました。 CPU使用率は30％以下に戻り、ARPテーブルの問題は存在しません。

1
DoxTheFox

かなりシンプルなものですが、見過ごされているかもしれません。クライアントに有効なデフォルトゲートウェイがあるかどうか、多くのプロキシARPを実行しているコアではありませんか。 3750のIPプロキシARP機能を無効にすることを検討できますか？

0
user209