Bagaimana saya bisa mendiagnosis loop bridging (ethernet)?

Mengingat spanning tree telah gagal (atau Anda tidak memiliki spanning tree) dan mendapatkan loop ethernet, apa cara terbaik untuk mendiagnosis di mana masalahnya?

Saklar mana ?, kabel apa? dan seterusnya.

OK, jadi anggap Anda memiliki topologi seperti:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Untuk beberapa alasan ada loop penghubung, STP dinonaktifkan atau seseorang menerapkan filter di tempat yang salah atau semacamnya.

PC A ingin berkomunikasi dengan PC B. Ini ARP pertama untuk MAC PC B, tujuannya adalah siaran dengan MAC ffff.ffff.ffff. Jadi frame pergi ke SW1 dan SW3. SRC MAC adalah PC A. SW1 kemudian membanjiri frame ke SW3 dan SW3 akan membanjiri frame yang berasal dari SW2 ke SW1.

SW1 dan SW3 mempelajari MAC PC ketika frame pertama masuk. Ketika yang kedua datang dari arah yang berlawanan, ia harus mempelajari kembali. Karena peristiwa ini terjadi sangat cepat dan berulang kali Anda akan melihat pesan log mengeluh tentang mengepakkan MAC. Sesuatu seperti "MAC FLAP 0000.0000.0001 mengepakkan antara Gi0 / 24 dan Gi0 / 23". Ini pertanda baik bahwa Anda memiliki perulangan.

Yang dapat Anda lakukan adalah mencoba melacak MAC ini. Coba cari di cache ARP perangkat di subnet yang sama dan lihat IP apa yang dimiliki perangkat ini. Jadi dengan MAC Anda bisa mencoba melacaknya dengan sh mac-address-table atau dengan IP mungkin Anda memiliki daftar dengan semua IP dan di mana mereka terhubung.

Jika host mendapatkan alamat IP dari server DHCP, Anda juga dapat mencoba di sana untuk menemukan dari mana host tersebut berasal. Jika Anda memiliki opsi 82 ​​diaktifkan itu akan sangat membantu.

Tanda-tanda lain adalah bahwa CLI akan sangat lamban. Beban CPU akan sangat tinggi. Switch melakukan hampir semua hal di ASIC jadi jika switch memiliki CPU load lebih dari 50%, itu mungkin tidak baik. Anda harus menerapkan pemantauan SNMP dan mengawasi beban CPU yang tinggi. Cari juga pesan flap MAC. Jika switch memiliki loop, LED mungkin akan berkedip seperti orang gila.

Hal-hal yang dapat Anda lakukan untuk melindungi dari loop:

• Aktifkan STP! (duh)
• Pemantauan SNMP dari beban CPU
• Aktifkan perangkap SNMP untuk acara tertentu seperti perubahan topologi STP
• Aktifkan kontrol badai di port untuk membatasi siaran
• Jangan terlalu banyak span VLAN Anda dalam topologi L2 Anda
• Aktifkan keamanan port dan batasi jumlah alamat MAC per port
• Aktifkan Option82 jika Anda menjalankan DHCP

Salah satu pengguna saya baru-baru ini meminjam sakelar desktop dari meja seseorang. Setelah mengembalikan sakelar, mereka menancapkan semua ujung ethernet longgar yang ada di dekatnya. Salah satu kabel pergi ke jaringan dan yang lain adalah dua ujung kabel yang sama. Saklar desktop dicolokkan ke jaringan dan juga dicolokkan ke dalam dirinya sendiri. Switch tidak memiliki STP, jadi siaran yang datang dari jaringan akan mengulangi kabel lain di kedua arah. Tentu saja, setiap kali siaran diterima pada port looped itu akan direplikasi kembali ke jaringan. Itu membuat HSRP benar-benar gila dan - karena desain yang buruk - itu juga mengakibatkan kegagalan kedekatan OSPF di seluruh kampus.

Indikasi pertama masalah adalah macflap diteruskan ke email saya. Ini segera membawa kami ke lemari kabel yang benar. Dari sana, itu adalah proses eliminasi berdasarkan LED port, pps antarmuka dan log. Tidak perlu dikatakan lagi, saya telah mengatur ulang seluruh kampus. Tindakan pencegahan terbaik mungkin adalah bpduguard. Saya telah menggunakan fitur ini dan itu cukup sederhana. Mendapatkan syslog yang dapat dihapus itu di email saya tidak ada salahnya.

Dengan sebagian besar peralatan, CPU menembak hingga 100% dan satu-satunya hal yang dapat Anda lakukan adalah memutus koneksi fisik yang berlebihan. Setelah CPU tenang, Anda bisa pasang kembali tautan satu per satu dan lihat mana yang menyebabkan loop berulang.

Untuk sasis besar (seperti 6500) saya harus mencabut semua bilah dan memasangnya kembali satu per satu. Setelah saya menemukan bilah mana, maka saya harus menarik semua tautan individual (16 GBIC) dan meletakkannya kembali satu per satu. Tidak pernah menyenangkan.

Beberapa peralatan yang lebih modern memiliki CPU yang dilindungi yang seharusnya membuat ini lebih mudah untuk ditangani - Anda masih dapat berinteraksi dengan kotak. Pada saat itu melihat penghitung lalu lintas dan semacamnya untuk menentukan tautan yang tidak berfungsi menjadi mungkin.

Saya baru-baru ini mulai di sebuah perusahaan di mana mereka menggunakan batas siaran di setiap port. Jika port melewati> 5% dari kapasitasnya sebagai siaran, switch akan membuatnya ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Ini telah menjadi penyelamat ketika satu kelompok cenderung untuk menghubungkan perangkat yang menjembatani jaringan nirkabel ke LAN.

Meskipun untuk pertanyaan Anda yang sebenarnya, saya selalu menganggapnya manual.

untuk IOS:

Anda mungkin akan memiliki alamat MAC yang berpindah-pindah antar port .. cari MAC_MOVE_NOTIFICATION(atau serupa) kesalahan di:

sh logg

Sekarang untuk menemukan port:

sh int g0/1 controller

mencari yang tidak biasa Multicastdan Broadcastangka. Setiap tabrakan adalah pertanda buruk.

Terakhir tetapi tidak kalah pentingnya, Anda tidak dapat masuk, karena CPU terpasang :)

sh proc cpu

Bagaimana saklar di sini? Jika ini hanya saklar L2, Anda tidak ingin apa pun di atas ~ 10%

Jika Anda belum mengelola, atau ekivalensi tidak terkelola (kurang detail login, atau pengetahuan tentang sistem operasi switch, dll), sakelar dan loop jembatan, saya jelaskan bagaimana saya akan menemukan loop secara manual. Ini juga membahas dasar mendasar dari pertanyaan awal, "Anda tidak memiliki STP".

Algoritma dasar untuk mencari kesalahan loop ini mirip dengan STP kecuali Anda tidak memiliki akses untuk mengirim BPDU dengan port ID di dalamnya.

• Pertama-tama, sambungkan perangkat yang mampu membuang / mengendus paket ke port di salah satu sakelar. Perangkat ini sekarang menjadi perangkat root pohon Anda.
  • Jika Anda harus mencari kesalahan di beberapa lokasi, misalnya di atas "kampus" atau serupa, Anda dapat memperolehnya dengan dapat login dari jarak jauh dengan klien ssh portabel ke mesin dumping paket.
    • Saya pribadi menggunakan laptop Linux saya dengan koneksi Internet dengan tcpdump di layar dan ssh ke dalamnya dari misalnya ipad atau telepon.
  • Jika Anda tidak dapat login sendiri dari jarak jauh, gunakan teman untuk memantau tcpdump secara visual, yang mungkin membanjiri dengan kecepatan tautan sehingga mudah untuk melihat perbedaan setiap kali jalur menuju perangkat sumber loop terputus.
• Selanjutnya, pada dasarnya Anda harus membuat ulang pohon, mulai dari sakelar root Anda.
  1. Dan karena Anda dapat memiliki skenario di mana Anda memiliki beberapa tautan looping yang masuk ke perangkat root Anda, Anda harus mulai dengan menghapus semua port yang terhubung secara bersamaan sekaligus.
  2. Sambungkan kembali port satu per satu dan jika suatu saat paket meledak muncul kembali, ikuti port ini ke sakelar yang terhubung di ujung yang lain.
  3. Ulangi langkah 1, sampai Anda menemukan port loop (s) dan tidak dapat mengulangi lebih jauh di pohon manual Anda.
  4. Setelah menyelesaikan situasi loop pada sakelar ini, kembali ke sakelar di atas pada susunan pohon dan lanjutkan langkah 2. Rekursi ini terus berlanjut hingga kabel final terhubung kembali ke sakelar root Anda.

Ini adalah pencarian manual yang sepenuhnya lengkap untuk port loop.

Biasanya hanya akan ada sepasang port yang dilingkarkan, yang berarti pencarian lengkap dan aman dengan menghapus semua port (tautan) pertama dan kemudian menghubungkannya kembali satu per satu tidak perlu. Jika hanya satu pasangan port di bawah 'pohon' dilingkarkan, Anda dapat menemukannya hanya dengan memutuskan satu port pada suatu waktu.

Namun demikian, umum, "bukti-busuk", metode, atau algoritma, menjadi apa yang saya jelaskan di atas.

Aduh. Tapi ok, saya bisa memikirkan dua cara saya akan di ini ...

Lihat itu: Jika switch memiliki indikator port, Anda harus dapat melihat port mana yang paling aktif. Itulah yang harus mulai dilihat pada awalnya. Semoga kabel diberi label sehingga Anda dapat mencari buah menggantung rendah menemukan dua port sibuk, pada dua sakelar dengan kabel yang sama.

Pemantauan SNMP: Jika Anda memiliki statistik penggunaan SNMP (atau yang serupa), cari sakelar tersibuk dan port tersibuk. Lalu pergi melihat kabel.

... jika Anda memiliki kabel yang tidak berlabel, mulailah melacak dan memberi label sebagai bagian dari Anda memeriksa port tersibuk.

Saya akan menjawab pertanyaan ini berdasarkan pemahaman bahwa ada pemadaman penuh untuk domain layer 2 yang bersangkutan, dan bahwa Anda tidak memiliki akses manajemen karena CPU semuanya dipatok.

Cara terbaik untuk memecahkan masalah bridging loop adalah mulai mencabut tautan naik hingga hilang. Katakanlah Anda memiliki lapisan akses sakelar standar dengan semua sakelar akses yang terhubung ke sepasang sakelar distribusi. Pergi ke sakelar akses pertama, dan cabut steker uplink, jika LED untuk sakelar berhenti mental, itu bukan sakelar itu, pasang kembali dan buka sakelar berikutnya. Ulangi sampai Anda tiba di saklar di mana Anda telah mencabut tautan dan LED terus berkedip cepat, ini adalah saklar Anda dengan loop.

Sekarang mulailah proses mencabut kabel pada port pengguna akhir sampai LED tenang, ketika mereka melakukannya, yang terakhir pada Anda mencabut adalah port masalah, melacak kabel dan menghukum pengguna dengan tepat.

Sejujurnya, jika Anda terhubung jarak jauh (atau melalui kabel konsol) ke perangkat, Anda akan melihat itu sangat lamban, akan ada penundaan dari saat Anda mengetikkan huruf yang muncul pada CLI.

Jika ini adalah switch Cisco, 2 yang mudah adalah melihat statistik antarmuka, itu akan menggunakan 100% (atau 255/255) penggunaan, terus-menerus. Dalam tahun-tahun saya berurusan dengan sakelar, saya belum pernah melihat port secara sah mencapai penggunaan 100%. Selain itu, periksa penggunaan CPU (biasanya "tunjukkan riwayat proses CPU"), antarmuka berliku biasanya akan menekan CPU Anda cukup keras kecuali jika Anda menjalankan saklar high-end.

STP harus benar-benar diaktifkan!

Saya mengalami masalah ini terjadi pada jaringan di ujung lain AS dan harus sedikit membantu beberapa analis tingkat satu melalui telepon dan link saya ke situs mereka. Masalahnya menjadi lebih rumit dengan fakta bahwa mereka memiliki beberapa merek sakelar yang perlahan-lahan ditambahkan ke jaringan selama bertahun-tahun. Ketika mereka memindahkan kantor, mereka menandai ke mana masing-masing pelabuhan pergi kemudian melampirkan kembali semuanya dengan cara yang sama persis di kantor baru dan memulai semuanya. Tak perlu dikatakan bahwa beberapa sakelar yang memiliki spanning tree yang berfungsi tidak menyatu dengan cara yang sama dan mereka memiliki semua jenis loop dan masalah. Pada saat saya selesai memperbaiki semuanya, tidak kurang dari tiga sakelar yang tidak dikelola ternyata telah terhubung dalam loop dengan seluruh infrastruktur.

Cara saya dapat melacak setiap sakelar yang tidak dikelola adalah dengan menggunakan alat yang disebut nedi (pada sakelar yang dapat dikelola saya mengaktifkan lldp / cdp). Saya pertama kali membuat peta dengan nedi. Kemudian di daerah di mana peta menunjukkan koneksi dari satu saklar ke yang lain lalu kembali ke saklar yang sama lagi saya memiliki teknisi jaringan di situs melacak garis secara manual. Saya secara manual mematikan antarmuka yang terlibat dengan loop atau meminta orang untuk mencabut kabel. Pada akhirnya saya bisa membuat jaringan berfungsi sebagaimana mestinya, terlepas dari semua saklar merek yang gila.

Satu hal yang dapat dilakukan di sini, adalah untuk melihat mesin apa yang terhubung ke sakelar menggunakan perintah show cdp neighboratau show lldp neighbor.

Jika perintah penjaga BPDU tidak digunakan, dan seseorang menghubungkan switch nakal dengan prioritas yang lebih rendah (atau alamat mac yang lebih lama), perangkat baru akan dinegosiasikan sebagai root Spanning Tree yang pasti akan menyebabkan masalah.

Dalam pengalaman saya, selalu kabel yang baru saja saya pasang, atau tidak ditutup, atau ditambahkan ke port-channel. Lebih sulit adalah ketika orang lain melakukannya dan tidak segera mengaku.

Menentukan loop sangat tergantung pada merek sakelar yang Anda miliki. Sebagai contoh, pada switch Extreme, saya dapat menjalankan elrp-client pada VLAN dan switch pada dasarnya akan mengirimkan frame broadcast pada semua port untuk VLAN itu dan melihat apakah ia kembali oleh salah satu dari mereka, jika demikian, ia memberitahu saya mana port (s) frame diterima kembali, sehingga mengungkapkan kandidat loop.

Pada Cisco, Anda dapat mengaktifkan kontrol badai, yang sedikit lebih merupakan instrumen tumpul karena pada dasarnya akan memblokir port untuk periode waktu sampai statusnya hilang (atau Anda menghapus negara yang dapat dihapus) - secara umum, bagaimanapun, jenis ini Hal itu hanya relevan ketika Anda menggunakan switch Cisco dalam topologi campuran perangkat yang tidak melakukan spanning tree atau meneruskan BPDU.

Tanpa ragu pendekatan tercepat yang saya temukan adalah dengan memonitor tingkat paket / detik dari antarmuka. Antarmuka tampilan cepat dengan filter CLI yang sesuai akan mencantumkan setiap antarmuka dan tingkat paket / detik. Untuk menemukan sumber loop lihatlah satu-satunya antarmuka dengan tingkat INPUT paket / detik tinggi yang gila. Dalam lingkungan perusahaan yang khas, dengan profil pemanfaatan yang khas, ini berfungsi setiap saat tanpa gagal. Pada 6500 dengan banyak antarmuka, tidak butuh waktu lama untuk menemukan sumbernya ...

Selama loop, untuk sejumlah besar lalu lintas siaran (mis. Permintaan ARP) di stasiun akhir juga dapat meningkatkan beban pada CPU (misalnya jika Anda menggunakan kartu realtek 100Mbit / s murah yang menghitung checksum pada CPU). Secara fisik mungkin untuk menemukan loop jika kabel terputus, tautan langsung hilang pada 2 port.