ARP broadcast flooding network dan penggunaan cpu tinggi

Berharap seseorang di sini mungkin memiliki wawasan tentang masalah yang kita hadapi. Saat ini kami memiliki Cisco TAC yang melihat kasus ini tetapi mereka berjuang untuk menemukan akar masalahnya.

Meskipun judul menyebutkan siaran ARP dan penggunaan CPU yang tinggi, kami tidak yakin apakah itu terkait atau tidak terkait pada tahap ini.

Masalah asli telah diposting di Komunitas Online INE

Kami telah menghapus jaringan ke satu tautan tanpa pengaturan redundansi, anggap saja sebagai topologi bintang.

Fakta:

• Kami menggunakan switch 3750x, 4 dalam satu tumpukan. Versi 15.0 (1) SE3. Cisco TAC mengkonfirmasi tidak ada masalah yang diketahui untuk bug cpu atau ARP tinggi untuk versi khusus ini.
• Tidak ada hub / sakelar yang tidak dikelola yang terhubung
• Core stack dimuat ulang
• Kami tidak memiliki rute default "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Menggunakan OSPF untuk routing.
• Kami melihat paket siaran besar dari VLAN 1, VLAN 1 yang digunakan untuk perangkat desktop. Kami menggunakan 192.168.0.0/20
• Cisco TAC mengatakan mereka tidak melihat ada yang salah dengan menggunakan / 20, selain itu kita akan memiliki domain broadcast yang besar tetapi harus tetap berfungsi.
• Wifi, manajemen, printer dll semua ada di VLAN yang berbeda
• Pohon spanning telah diverifikasi oleh individu yang memenuhi syarat Cisco TAC & CCNP / CCIE. Kami mematikan semua tautan yang berlebihan.
• Konfigurasi pada inti telah diverifikasi Cisco TAC.
• Kami memiliki batas waktu ARP default pada sebagian besar sakelar.
• Kami tidak menerapkan Tanya Jawab.
• Tidak ada switch baru yang ditambahkan (setidaknya tidak ada yang kita ketahui)
• Tidak dapat menggunakan inspeksi arp dinamis pada sakelar tepi karena ini adalah 2950
• Kami menggunakan show interface | inc line | broadcast untuk mencari tahu dari mana datangnya sejumlah besar siaran, namun baik Cisco TAC dan 2 insinyur lainnya (CCNP & CCIE) mengkonfirmasi ini adalah perilaku normal karena apa yang terjadi pada jaringan (seperti pada sejumlah besar mac flaps) menyebabkan siaran lebih besar). Kami memverifikasi bahwa STP berfungsi dengan benar pada sakelar tepi.

Gejala pada jaringan dan beralih:

• Sejumlah besar penutup MAC
• Penggunaan CPU tinggi untuk proses Input ARP
• Paket ARP dalam jumlah besar, meningkat dengan cepat dan terlihat
• Wiresharks menunjukkan bahwa 100-an komputer membanjiri jaringan dengan ARP Broadcast
• Untuk tujuan pengujian, kami menempatkan sekitar 80 mesin desktop vlan yang berbeda, namun kami menguji ini dan tidak membuat perbedaan yang terlihat pada input cpu atau arp tinggi
• Telah menjalankan berbagai AV / malware / spyware, tetapi tidak ada virus yang terlihat di jaringan.
• sh mac address-table count, menunjukkan kepada kita sekitar 750 alamat mac yang berbeda seperti yang diharapkan pada vlan 1.

#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

• Ran menunjukkan tabel alamat mac pada sakelar dan inti yang berbeda itu sendiri (pada intinya, misalnya, dicolokkan langsung ke desktop, desktop saya), dan kita dapat melihat beberapa alamat perangkat keras MAC yang berbeda didaftarkan ke antarmuka, meskipun antarmuka tersebut memiliki hanya satu komputer yang terpasang pada ini:

 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

• tunjukkan pemanfaatan platform 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

Kita sekarang berada pada tahap, di mana kita akan memerlukan sejumlah besar waktu henti untuk mengisolasi masing-masing area pada suatu waktu kecuali ada orang lain yang memiliki ide untuk mengidentifikasi sumber atau akar penyebab masalah aneh dan aneh ini.

Memperbarui

Terima kasih @MikePennington dan @RickyBeam atas tanggapan terperinci. Saya akan mencoba dan menjawab apa yang saya bisa.

• Seperti disebutkan, 192.168.0.0/20 adalah kekacauan bawaan. Namun, kami berniat untuk membagi ini di masa depan tetapi sayangnya masalah ini terjadi sebelum kami bisa melakukan ini. Saya pribadi juga setuju dengan mayoritas, di mana domain siarannya terlalu besar.
• Menggunakan Arpwatch jelas merupakan sesuatu yang bisa kita coba tetapi saya curiga karena beberapa port akses mendaftarkan alamat mac meskipun itu bukan milik port ini, kesimpulan dari arpwatch mungkin tidak berguna.
• Saya sepenuhnya setuju dengan tidak 100% yakin menemukan semua tautan yang mubazir dan sakelar yang tidak dikenal di jaringan, tetapi yang terbaik dari temuan kami, inilah yang terjadi sampai kami menemukan bukti lebih lanjut.
• Keamanan pelabuhan telah diperiksa, sayangnya manajemen telah memutuskan untuk tidak menggunakan ini karena berbagai alasan. Alasan umum adalah kita terus-menerus memindahkan komputer (lingkungan kampus).
• Kami telah menggunakan spanfast-tree portfast bersama dengan spanp Tree bpduguard secara default di semua port akses (mesin desktop).
• Kami tidak menggunakan switchport nonnegosiasi saat ini pada port akses, tetapi kami tidak mendapatkan serangan hopping Vlan apa pun memantul di seluruh Varian multitple.
• Akan memberikan pemberitahuan mac-address-table go, dan melihat apakah kita dapat menemukan pola.

"Karena kamu mendapatkan sejumlah besar MAC flap di antara switchports, sulit untuk menemukan di mana pelanggar itu berada (misalkan kamu menemukan dua atau tiga alamat mac yang mengirim banyak arps, tetapi sumber alamat mac terus mengepak di antara port)."

• Kami mulai dengan ini, memilih salah satu MAC flaps dan melanjutkan perjalanan kami melalui semua inti beralih ke distribusi untuk mengakses switch, tetapi apa yang kami temukan adalah sekali lagi, antarmuka port akses memonopoli banyak alamat mac sehingga mac flaps; jadi kembali ke titik awal.
• Pengendalian badai adalah sesuatu yang kami pertimbangkan, tetapi kami khawatir beberapa dari paket yang sah akan dibatalkan yang menyebabkan masalah lebih lanjut.
• Akan tiga kali lipat memeriksa konfigurasi VMHost.
• @ytti alamat MAC yang tidak dapat dijelaskan ada di belakang banyak port akses daripada seorang individu. Belum menemukan loop pada antarmuka ini. Alamat MAC juga ada pada antarmuka lain, yang akan menjelaskan sejumlah besar MAC flap
• @ RickyBeam saya setuju dengan alasan host mengirim begitu banyak permintaan ARP; ini adalah salah satu masalah yang membingungkan. Rouge wireless bridge adalah sesuatu yang menarik yang belum saya pikirkan, sejauh yang kami ketahui, nirkabel ada pada VLAN yang berbeda; tapi bajingan akan berarti itu mungkin pada VLAN1.
• @ RickyBeam, saya tidak benar-benar ingin mencabut semuanya karena ini akan menyebabkan banyak downtime. Namun ini adalah tempat yang mungkin menuju. Kami memiliki server Linux tetapi tidak lebih dari 3.
• @ RickyBeam, bisakah Anda menjelaskan probing server DHCP yang sedang digunakan?

Kami (Cisco TAC, CCIEs, CCNP) secara global setuju bahwa ini bukan konfigurasi sakelar tetapi host / perangkat yang menyebabkan masalah.

Terpecahkan.

Masalahnya adalah dengan SCCM 2012 SP1, sebuah layanan yang disebut: ConfigMrg Wake-Up Proxy . 'Fitur' tidak ada SCCM 2012 RTM.

Dalam waktu 4 jam mematikan ini dalam kebijakan, kami melihat penurunan yang stabil dalam penggunaan CPU. Pada saat 4 jam habis, penggunaan ARP hanya 1-2%!

Singkatnya, layanan ini melakukan spoofing alamat MAC! Tidak percaya berapa banyak kerusakan yang ditimbulkannya.

Di bawah ini adalah teks lengkap dari Microsoft Technet karena saya merasa penting untuk memahami bagaimana ini terkait dengan masalah yang diposting.

Bagi siapa saja yang tertarik, di bawah ini adalah rincian teknisnya.

Manajer Konfigurasi mendukung dua teknologi wake on local area network (LAN) untuk mengaktifkan komputer dalam mode tidur ketika Anda ingin menginstal perangkat lunak yang diperlukan, seperti pembaruan dan aplikasi perangkat lunak: paket bangun tradisional dan perintah pengaktifan AMT.

Dimulai dengan Configuration Manager SP1, Anda dapat menambah metode paket wake-up tradisional dengan menggunakan pengaturan klien proxy wake-up. Proxy wake-up menggunakan protokol peer-to-peer dan komputer terpilih untuk memeriksa apakah komputer lain pada subnet sudah aktif, dan membangunkannya jika perlu. Ketika situs dikonfigurasikan untuk Wake On LAN dan klien dikonfigurasikan untuk proxy wake-up, prosesnya bekerja sebagai berikut:

1. Komputer yang memiliki klien Configuration Manager SP1 diinstal dan yang tidak tertidur di subnet memeriksa apakah komputer lain di subnet tersebut terjaga. Mereka melakukan ini dengan saling mengirim perintah ping TCP / IP setiap 5 detik.

2. Jika tidak ada respons dari komputer lain, mereka dianggap tertidur. Komputer yang terjaga menjadi komputer manajer untuk subnet.

3. Karena ada kemungkinan bahwa komputer mungkin tidak merespons karena alasan selain tertidur (misalnya, dimatikan, dihapus dari jaringan, atau pengaturan klien bangun proxy tidak lagi diterapkan), komputer tersebut mengirim paket bangun setiap hari pukul 14:00 waktu setempat. Komputer yang tidak merespons tidak lagi dianggap tertidur dan tidak akan dibangunkan oleh proksi wake-up.

Untuk mendukung proksi wake-up, setidaknya tiga komputer harus sadar untuk setiap subnet. Untuk mencapai hal ini, tiga komputer secara non-deterministik dipilih menjadi komputer pengawal untuk subnet. Ini berarti bahwa mereka tetap terjaga, meskipun ada kebijakan daya yang dikonfigurasi untuk tidur atau hibernasi setelah periode tidak aktif. Komputer Guardian menerima perintah shutdown atau restart, misalnya, sebagai hasil dari tugas pemeliharaan. Jika ini terjadi, sisa komputer penjaga membangunkan komputer lain di subnet sehingga subnet terus memiliki tiga komputer pelindung.

Komputer manajer meminta saklar jaringan untuk mengalihkan lalu lintas jaringan ke komputer yang tidur itu sendiri.

Pengalihan dicapai oleh komputer manajer yang menyiarkan frame Ethernet yang menggunakan alamat MAC komputer yang tidur sebagai alamat sumber. Hal ini membuat saklar jaringan berperilaku seolah-olah komputer yang tidur telah pindah ke port yang sama dengan yang digunakan komputer manajer. Komputer manajer juga mengirim paket ARP untuk komputer yang tidur agar entri tetap segar di cache ARP. Komputer manajer juga akan menanggapi permintaan ARP atas nama komputer yang tidur dan membalas dengan alamat MAC komputer yang tidur.

Selama proses ini, pemetaan IP-ke-MAC untuk komputer yang tidur tetap sama. Proxy bangun berfungsi dengan memberi tahu sakelar jaringan bahwa adaptor jaringan yang berbeda menggunakan port yang didaftarkan oleh adaptor jaringan lain. Namun, perilaku ini dikenal sebagai penutup MAC dan tidak biasa untuk operasi jaringan standar. Beberapa alat pemantauan jaringan mencari perilaku ini dan dapat berasumsi bahwa ada sesuatu yang salah. Akibatnya, alat-alat pemantauan ini dapat menghasilkan peringatan atau menutup port ketika Anda menggunakan proxy bangun. Jangan gunakan proxy bangun jika alat dan layanan pemantauan jaringan Anda tidak mengizinkan MAC flap.

4. Ketika komputer manajer melihat permintaan koneksi TCP baru untuk komputer yang sedang tidur dan permintaannya adalah ke port yang didengarkan komputer tidur sebelum ia pergi tidur, komputer manajer mengirim paket bangun ke komputer yang tidur, dan kemudian berhenti mengarahkan lalu lintas untuk komputer ini.

5. Komputer yang tidur menerima paket bangun dan bangun. Komputer pengirim secara otomatis mencoba kembali koneksi dan kali ini, komputer terjaga dan dapat merespons.

Ref: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Terima kasih untuk semua orang yang telah memposting di sini dan membantu dengan proses pemecahan masalah, sangat dihargai.

ARP / Siaran badai

• Kami melihat paket siaran besar dari VLAN 1, VLAN 1 yang digunakan untuk perangkat desktop. Kami menggunakan 192.168.0.0/20 ...
• Wiresharks menunjukkan bahwa 100-an komputer membanjiri jaringan dengan ARP Broadcast ...

Proses Input ARP Anda tinggi, yang berarti saklar menghabiskan banyak waktu memproses ARP. Salah satu penyebab ARP flooding yang sangat umum adalah loop antara sakelar Anda. Jika Anda memiliki loop, maka Anda juga bisa mendapatkan flap mac yang Anda sebutkan di atas. Kemungkinan penyebab lain dari banjir ARP adalah:

• Kesalahan konfigurasi alamat IP
• Serangan layer2, seperti arp spoofing

Pertama, hilangkan kemungkinan kesalahan konfigurasi atau serangan layer2 yang disebutkan di atas. Cara termudah untuk melakukannya adalah dengan arpwatch pada mesin linux (bahkan jika Anda harus menggunakan livecd di laptop). Jika Anda memiliki kesalahan konfigurasi atau serangan layer2, maka arpwatch memberi Anda pesan seperti ini di syslog, yang mencantumkan alamat mac yang memperebutkan alamat IP yang sama ...
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)

Ketika Anda melihat "sandal jepit", Anda harus melacak sumber alamat mac dan mencari tahu mengapa mereka berebut IP yang sama.

• Sejumlah besar penutup MAC
• Pohon spanning telah diverifikasi oleh individu yang memenuhi syarat Cisco TAC & CCNP / CCIE. Kami mematikan semua tautan yang berlebihan.

Berbicara sebagai seseorang yang telah melalui ini lebih dari yang ingin saya ingat, jangan menganggap Anda menemukan semua tautan yang berlebihan ... buat saja switchport Anda berperilaku setiap saat.

Karena Anda mendapatkan sejumlah besar flap mac di antara switchports, sulit untuk menemukan di mana pelanggar berada (misalkan Anda menemukan dua atau tiga alamat mac yang mengirim banyak arps, tetapi sumber alamat mac terus mengepak di antara port). Jika Anda tidak menerapkan batasan keras pada mac-address per port tepi, sangat sulit untuk melacak masalah ini tanpa mencabut kabel secara manual (yang ingin Anda hindari). Switch loops menyebabkan jalur yang tidak terduga dalam jaringan, dan Anda bisa berakhir dengan ratusan mac yang dipelajari secara terputus-putus dari apa yang biasanya menjadi switchport desktop.

Cara termudah untuk memperlambat gerakan mac adalah dengan port-security. Pada setiap switchport akses di Vlan 1 yang terhubung ke satu PC (tanpa downstream switch), konfigurasikan perintah level antarmuka berikut pada cisco switch Anda ...

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

Dalam kebanyakan kasus banjir mac / ARP, menerapkan konfigurasi ini ke semua port switch tepi Anda (terutama yang dengan portfast) akan membuat Anda kembali ke keadaan waras, karena konfigurasi akan mematikan port apa pun yang melebihi tiga alamat mac, dan menonaktifkan secara diam-diam portfast port looped. Tiga mac per port adalah angka yang berfungsi baik di lingkungan desktop saya, tetapi Anda bisa menaikkannya menjadi 10 dan mungkin baik-baik saja. Setelah Anda melakukan ini, setiap loop layer 2 rusak, flap mac cepat akan berhenti, dan itu membuat diagnosis lebih mudah.

Sepasang perintah global lainnya yang berguna untuk melacak port yang terkait dengan badai siaran (mac-move) dan flooding (threshold) ...

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

Setelah Anda selesai, secara opsional lakukan clear mac address-tableuntuk mempercepat penyembuhan dari tabel CAM yang berpotensi penuh.

• Ran memperlihatkan tabel alamat mac pada sakelar dan inti yang berbeda (pada intinya, misalnya, dicolokkan langsung ke desktop, desktop saya), dan kita dapat melihat beberapa alamat perangkat keras MAC yang berbeda didaftarkan ke antarmuka, meskipun antarmuka tersebut memiliki hanya satu komputer yang terpasang pada ini ...

Seluruh jawaban ini mengasumsikan bahwa 3750 Anda tidak memiliki bug yang menyebabkan masalah (tetapi Anda memang mengatakan bahwa wireshark menunjukkan PC yang banjir). Apa yang Anda tunjukkan kepada kami jelas salah ketika hanya ada satu komputer yang terpasang pada Gi1 / 1/3, kecuali jika PC itu memiliki sesuatu seperti VMWare di atasnya.

Pikiran lain-lain

Berdasarkan percakapan obrolan yang kami lakukan, saya mungkin tidak perlu menyebutkan yang jelas, tetapi saya akan demi pengunjung masa depan ...

• Menempatkan pengguna di Vlan1 biasanya adalah ide yang buruk (saya mengerti Anda mungkin telah mewarisi kekacauan)
• Terlepas dari apa yang TAC katakan kepada Anda, 192.168.0.0/20 terlalu besar untuk dikelola dalam satu domain yang diaktifkan tanpa risiko serangan layer2. Semakin besar subnet mask Anda, semakin besar ekspos terhadap serangan layer2 seperti ini karena ARP adalah protokol yang tidak diautentikasi dan router setidaknya harus membaca ARP yang valid dari subnet itu.
• Kontrol badai pada port layer2 biasanya ide yang bagus juga; Namun, mengaktifkan kontrol badai dalam situasi seperti ini akan mengeluarkan lalu lintas yang baik dengan lalu lintas yang buruk. Setelah jaringan pulih, terapkan beberapa kebijakan pengendalian badai pada port tepi dan uplink Anda.

Pertanyaan sebenarnya adalah mengapa host mengirim begitu banyak ARP di tempat pertama. Sampai ini dijawab, saklar akan terus mengalami kesulitan berurusan dengan badai arp. Ketidakcocokan Netmask? Timer arp host rendah? Satu (atau lebih) host memiliki rute "antarmuka"? Jembatan nirkabel merah muda di suatu tempat? "arp serampangan" menjadi gila? Server DHCP "sedang digunakan" menyelidiki? Itu tidak terdengar seperti masalah dengan sakelar, atau lapisan 2; Anda memiliki host melakukan hal-hal buruk.

Proses debugging saya akan mencabut semuanya dan mengawasi dengan seksama ketika semuanya disambungkan kembali, satu port pada satu waktu. (Saya tahu itu bermil-mil dari ideal, tetapi pada titik tertentu Anda harus memotong kerugian Anda dan berusaha mengisolasi secara fisik segala sumber yang memungkinkan) Lalu saya akan berusaha memahami mengapa beberapa port tertentu menghasilkan beberapa arp.

(Apakah banyak host yang kebetulan merupakan sistem linux? Linux telah memiliki sistem manajemen cache ARP yang sangat bodoh. Fakta bahwa itu akan "memverifikasi kembali" entri hanya dalam hitungan menit, sudah rusak di buku saya Ini cenderung kurang menjadi masalah dalam jaringan kecil, tetapi / 20 bukanlah jaringan kecil.)

Ini mungkin atau mungkin tidak terkait dengan masalah Anda, namun saya pikir itu mungkin sesuatu yang setidaknya layak dibuang:

Saat ini kami memiliki beberapa 3750x yang ditumpuk di beberapa situs jarak jauh kami, sebagian besar berjalan 15.0.2 (SE0 hingga 4, ada beberapa bug FRU dengan SE0 yang secara perlahan saya pindah dari).

Selama pembaruan IOS rutin, dari 15.0.2 ke 15.2-1 (SE terbaru) kami melihat peningkatan CPU yang cukup signifikan, dari rata-rata sekitar 30% hingga 60% dan lebih tinggi selama masa off-peak. Saya telah meninjau konfigurasi dan log Ubah IOS, dan telah bekerja dengan Cisco's TAC. Menurut TAC, mereka tampaknya berada pada titik di mana mereka percaya ini adalah bug iOS 15.2-1.

Ketika kami terus menyelidiki peningkatan CPU, kami mulai melihat sejumlah besar lalu lintas ARP ke titik di mana tabel ARP kami terisi penuh dan menyebabkan ketidakstabilan jaringan. Kruk sementara untuk ini adalah untuk secara manual kembali timeout ARP kami dari default (14400) menjadi 300 pada vlan suara dan data kami.

Setelah mengurangi batas waktu ARP kami, kami stabil selama sekitar satu minggu, pada saat itu kami kembali ke iOS 15.0.2-SE4, dan menghapus batas waktu ARP non-standar kami. Pemanfaatan CPU kami kembali turun hingga ~ 30% dan masalah tabel ARP kami tidak ada.

Yang sederhana tapi mungkin diabaikan; apakah klien Anda memiliki gateway default yang valid, bukankah Anda melakukan banyak proxy proxy? Anda dapat mempertimbangkan untuk meniadakan fungsi arp proxy ip pada 3750 Anda?