ここで誰かが私たちが直面している問題に対する洞察を持っていることを望んでいます。現在、Cisco TACがケースを調査していますが、根本原因を見つけるのに苦労しています。
タイトルにはARPブロードキャストと高いCPU使用率が記載されていますが、この段階でそれらが関連しているかどうかはわかりません。
ネットワークを単一のリンクにまとめ、冗長性のないセットアップを行いました。スタートポロジと考えてください。
事実：
- 1つのスタックに4つの3750xスイッチを使用します。バージョン15.0（1）SE3。Cisco TACは、この特定のバージョンのCPUまたはARPの高いバグに関する既知の問題がないことを確認しています。
- ハブ/非管理スイッチが接続されていません
- リロードされたコアスタック
- デフォルトルート「Ip route 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がエッジスイッチで正しく機能していることを確認しました。
ネットワークおよびスイッチの症状：
- 多数のMACフラップ
- ARP入力プロセスのCPU使用率が高い
- 急速に増加し、目に見える膨大な数のARPパケット
- Wiresharksは、数百台のコンピューターがネットワークにARPブロードキャストを殺到していることを示しています
- テストの目的で、約80台のデスクトップマシンに異なるVLANを配置しましたが、これをテストし、高CPUまたはARP入力に目に見える違いはありませんでした
- さまざまなAV /マルウェア/スパイウェアを実行しましたが、ネットワーク上で目に見えるウイルスはありません。
- sh mac address-table countは、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％確実に見つけられないことに完全に同意しますが、私たちの発見としては、これはさらなる証拠を見つけるまで当てはまります。
- ポートセキュリティが調査されましたが、残念ながら管理者はさまざまな理由でこれを使用しないことにしました。一般的な理由は、コンピューターを常に移動していることです（大学環境）。
- すべてのアクセスポート（デスクトップマシン）で、デフォルトでスパニングツリーportfastをスパニングツリーbpduguardと組み合わせて使用しました。
- 現在、アクセスポートではスイッチポート非ネゴシエートを使用していませんが、複数のVLANをまたぐVlanホッピング攻撃はありません。
- mac-address-table通知を実行し、パターンを見つけることができるかどうかを確認します。
「スイッチポート間で多数のMACフラップが発生するため、攻撃者の場所を見つけるのは困難です（大量のarpを送信する2つまたは3つのMACアドレスを見つけたが、ソースMACアドレスはポート間でフラッピングし続けます）。
- これを開始し、任意の1つのMACフラップを選択し、すべてのコアスイッチからアクセススイッチへのディストリビューションに進みましたが、アクセスポートインターフェイスが複数のMACアドレスを占有しているため、MACフラップが見つかりました。正方形に戻ります。
- ストーム制御は私たちが考慮したものですが、正当なパケットの一部がドロップされてさらなる問題を引き起こすことを恐れています。
- VMHost構成をトリプルチェックします。
- @ytti説明できないMACアドレスは、個人ではなく多くのアクセスポートの背後にあります。これらのインターフェイスでループが見つかりませんでした。MACアドレスは他のインターフェイスにも存在するため、多数のMACフラップが説明されます。
- @RickyBeam私は、ホストが非常に多くのARP要求を送信している理由に同意します。これは不可解な問題の1つです。ルージュワイヤレスブリッジは、ワイヤレスが別のVLAN上にあることを認識している限り、私が考えていない興味深いブリッジです。しかし、不正は明らかにVLAN1に存在する可能性があることを意味します。
- @RickyBeam、これは大量のダウンタイムを引き起こすので、すべてを抜いたくありません。しかし、これはちょうどそれが向かっているところです。Linuxサーバーはありますが、3を超えていません。
- @ RickyBeam、DHCPサーバーの「使用中」プロービングについて説明できますか？
私たち（Cisco TAC、CCIE、CCNP）は、これがスイッチ構成ではなく、ホスト/デバイスが問題を引き起こしていることに世界的に同意しています。
1
私は注意します：ネットワークにループがない限り、macフラップは発生しません。他の唯一の論理的な理由は、同じMACを使用するVMになります。（または、同じMACを使用するように設定された複数のNICを持つボーンヘッド）
@ColdT、元の応答でいくつかのことを読み間違えたため、答えを更新しました。
—
マイクペニントン
多くのポートの背後で説明できないMACアドレスが多数発生していますか？ポートがループしていませんか？MACアドレスはそのポートの後ろにとどまりますか、それとも他のポートの後ろにも表示されますか？ARPのPCAPはありますか？多数のMACフラップは確かにまったく正常ではありません。これは、トポロジが変化し続けるか、ネットワークに管理されていないループがあることを意味します。
@ColdT、ポートセキュリティに関する管理者と再度関わり合うべきだと思います。具体的には、PCがスイッチポート間を移動できる構成を提供しました。
—
マイクペニントン
switchport port-security aging time 5そしてswitchport port-security aging type inactivity、5分間非アクティブになった後、またはポートセキュリティエントリを手動でクリアした場合、ステーションをポート間で移動できることを意味します。ただし、この構成では、ポートが異なるポートから同じmac-addressを任意に送信できないため、スイッチのアクセスポート間でmacフラップが防止されます。
また、同じIPアドレスに対して異なるARPが存在しない限り、arpwatchはフリップフロップを登録しないことに注意してください。理由に関係なく、いつそれが起こるかを知る必要があります。単なるMACフラッドでは、arpwatchを混乱させるには不十分です
—
マイクペニントン