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.
1
Saya akan mencatat: kecuali ada loop dalam jaringan, mac flap seharusnya tidak terjadi. Satu-satunya alasan logis lainnya adalah para VM menggunakan MAC yang sama. (atau beberapa orang bodoh memiliki beberapa nics diatur untuk menggunakan MAC yang sama)
@ ColdT, saya memperbarui jawaban saya ketika saya salah membaca beberapa hal dalam tanggapan asli saya.
—
Mike Pennington
Apakah Anda mengalami sejumlah besar alamat MAC yang tidak dapat dijelaskan di balik banyak port atau hanya satu port? Bisakah port di-loop? Apakah alamat MAC tetap di belakang port itu atau muncul di belakang port lain juga? Apakah kita memiliki PCAP untuk ARP? Sejumlah besar MAC flaps tentu tidak normal sama sekali, ini menyiratkan apakah topologi terus berubah atau Anda memiliki loop yang tidak dikelola dalam jaringan.
@ ColdT, saya pikir Anda harus kembali terlibat dengan manajemen tentang keamanan pelabuhan; Saya secara khusus memberi Anda konfigurasi yang memungkinkan PC untuk berpindah antar switchports.
—
Mike Pennington
switchport port-security aging time 5dan switchport port-security aging type inactivityberarti bahwa Anda dapat memindahkan stasiun antar port setelah 5 menit tidak aktif, atau jika Anda menghapus entri keamanan port secara manual. Namun, konfigurasi ini mencegah mac flaps antara port akses switch karena port tidak dapat secara sewenang-wenang mengambil sumber alamat mac yang sama dari port yang berbeda.
perlu juga disebutkan bahwa arpwatch tidak mendaftarkan flip flop kecuali ada ARP yang berbeda untuk alamat IP yang sama. Apa pun alasannya, Anda perlu tahu kapan itu terjadi. Hanya banjir mac tidak cukup untuk membingungkan arpwatch
—
Mike Pennington