Cara terbaik untuk menghubungkan beberapa switch secara bersamaan

11

Kami saat ini memiliki lima 24 port 3com switch yang tidak dikelola. Empat di antaranya adalah switch 100Mb tanpa port gigabit (port MDI Uplink 100Mb). Kelima adalah switch gigabit penuh yang kami gunakan untuk semua server kami. Mereka daisy dirantai bersama pada saat ini, seperti ini:

teks alternatif

Pada waktu-waktu tertentu, kinerja jaringan menjadi mengerikan. Kami telah memverifikasi bahwa ini tidak ada hubungannya dengan kapasitas server, jadi kami pergi dengan mempertimbangkan kemacetan jaringan I / O. Kami berharap dapat menyambungkan setiap sakelar 100 MB langsung ke sakelar gigabit sehingga setiap pengguna hanya berjarak 1 sakelar dari server ... seperti ini:

teks alternatif

Saat ini terhubung, semua lalu lintas jaringan berhenti. Apakah ini cara yang salah untuk melakukannya? Kami memverifikasi bahwa tidak ada loop, dan memverifikasi bahwa kami tidak memiliki kabel crossover (semua switch memiliki Auto-MDI). Power cycling 5 switch juga tidak melakukan apa-apa.

networking switch small-business

— Bip bip
sumber

Membeli, Meminjam, Mengemis, atau Mencuri switch dikelola tunggal murah untuk peran "gigabit penuh" benar-benar bukan pilihan? Beberapa ratus membeli Anda misalnya HP JE006A (yang dirancang 3com btw) saat ini, dan Anda akan memiliki banyak cara yang lebih baik untuk men-debug ketika masalah itu berulang (dan karena itu hanya muncul tanpa mengambil upaya untuk membuatnya muncul, itu mungkin akan ).

— rackandboneman

17

Mungkin switch hanya kagum dengan topologi Anda yang menakjubkan?

Namun serius, jika Anda dapat meluangkan waktu, lakukan lagi, tetapi hanya sambungkan satu sakelar pada sakelar Gb, dan verifikasi konektivitas dan fungsi di setiap langkah.

Ketika jaringan akhirnya berhenti, lepaskan semua sakelar, dan coba sambungkan sakelar itu terlebih dahulu. Jika berhasil lagi, putuskan semua yang ada di sakelar itu dan tambahkan kembali, satu per satu untuk menemukan tautan yang tidak bahagia.

Jika tidak mati, tambahkan sakelar sampai mati. Jika gagal setelah menambahkan lebih banyak sakelar, mungkin salah satu sakelar tidak dapat menangani ukuran tabel alamat MAC, dan Anda memerlukan sakelar yang lebih besar?

— Matt Simmons
sumber

3

Juga jika gagal lagi, perhatikan lampu aktivitas pada sakelar - apakah sudah mati?

— Zypher

@ Zypher - poin bagus, kami akan meluangkan waktu berjam-jam (selama hari mereka selalu gila, kami memiliki banyak lalu lintas jaringan).

— Bip bip

2

Tidak memiliki sakelar yang dikelola membuat masalah seperti ini sulit dilacak karena Anda kurang dapat melihat jaringan. Tetapi pendekatan Matt seharusnya membantu Anda mempersempitnya dengan cepat.

— 3dinfluence

1

@ Matt: titik minor, sakelar tidak memiliki tabel ARP. Kecuali mereka adalah saklar L3, dalam hal ini mereka harus disebut router. :)

— Murali Suriar

2

Pendekatan Matt adalah pendekatan yang baik, seperti perubahan topologi Anda (rantai daisy yang paling buruk). Ada berbagai hal tidak jelas lainnya yang dapat menyebabkan masalah Anda, yang sulit dilacak pada peralatan jaringan yang tidak dikelola. Saya telah melihat perilaku serupa dengan server "satu arah" - seperti server syslog yang terkunci, yang hanya menerima log tetapi tidak pernah berbicara. Itu menyebabkan alamat MAC-nya kehabisan waktu di meja switch, dan semua lalu lintas ke server itu akan membanjiri semua port. Masalah serupa dengan clustering atau VRRP ...

— Geoff

3

Saya pasti akan mencoba untuk membuat topologi yang terakhir berfungsi (dengan petunjuk diagnostik Matt Simmons sebagai panduan), karena ini akan memberikan latensi yang lebih baik (selalu hanya berjarak satu hop). Juga, mengingat kapasitas interkoneksi Anda yang sangat terbatas, cobalah untuk:

letakkan mesin yang sering berbicara satu sama lain pada sakelar yang sama (sehingga interkonek tidak harus membawa banyak lalu lintas); dan
kaitkan mesin yang memiliki NIC gigabit dan bicaralah dengan banyak mesin lain di sakelar gigabit secara langsung (sehingga mereka dapat memasukkan datanya ke jaringan seefisien mungkin).

Namun, pada akhirnya, Anda tidak dapat memasukkan kalkun seberat 10 pon dalam kantong lima pound, dan saya akan menulis rencana untuk membeli seperangkat sakelar gigabit terkelola, berdasarkan uraian Anda tentang jaringan yang sudah banyak digunakan.

— womble
sumber

"kamu tidak bisa memasukkan kalkun seberat 10 pon dalam kantong lima pon" - bagus Tapi bagaimana jika kita lakban dua kantong lima pound bersama-sama? Itu bekerja sejauh =)

— Bip bip

1

Saya kira etherchannel akan menjadi setara dengan lakban ... memerlukan switch yang dikelola, meskipun.

— womble

0

Sakelar yang tidak dikelola membatasi jumlah lalu lintas yang dapat dipindah secara efektif - tidak seperti yang Anda harapkan. Anda mungkin mendapatkan pertentangan badai / bus siaran yang menyebabkan hal-hal menjadi buruk karena terlalu banyak paket atau klien berusaha menggunakan jaringan pada satu waktu. Beralih ke switch terkelola (kami menggunakan netgear 24 port yang berjalan sekitar $ 250-300 per pop) akan memberi Anda lebih banyak kapasitas switching dan kemampuan untuk port QOS jika Anda perlu mengelola prioritas dengan lebih baik.

Secara empiris kami mencoba tata letak bawah satu kali dan itu hanya berjalan buruk. Saya yakin CNE yang sebenarnya akan memberi tahu kami alasan sebenarnya, tetapi saya selalu terjebak dengan konfigurasi teratas hanya untuk menjaga kabel tetap sederhana, bersih dan berfungsi. Pikiran Anda, kami bisa saja memiliki lingkaran lingkaran dan tidak menyadarinya pada saat itu.

— MikeJ
sumber

4

Sakelar yang dikelola memiliki batas yang sama dengan sakelar yang tidak dikelola. Sakelar yang dikelola hanya memberi Anda lebih banyak kontrol dan visibilitas tentang apa yang terjadi di jaringan.

— 3dinfluence

2

@ 3d: Meskipun Anda benar bahwa tidak ada perbedaan intrinsik antara kapasitas sakelar yang dikelola versus yang tidak dikelola, dalam praktiknya sakelar yang dikelola cenderung mengarah ke ujung kualitas pasar yang lebih tinggi, dan karenanya cenderung memiliki kain pengganti yang lebih baik, yang memungkinkan mereka untuk beralih lebih banyak lalu lintas di sekitar.

— womble

@ Womble ... tidak diragukan lagi tetapi hampir semua switch yang tidak dikelola "non blocking" setidaknya sejauh menyangkut backplane. Apakah cpu dapat mengikuti paket yang terpecah-pecah dan masalah tcp lainnya adalah pertanyaan lain. Switch yang dikelola juga cenderung memiliki lebih banyak cache di setiap port daripada saudara yang tidak dikelola.

— 3dinfluence

0

Beberapa ide lagi tentang berbagai hal dapat terjadi:

Negosiasi otomatis mungkin memilih pengaturan kecepatan / dupleks yang tidak sesuai. Pastikan untuk mengatur port secara manual untuk 100 / Penuh
Konvergensi Spanning-Tree tidak diragukan lagi terjadi ketika Anda melakukan perubahan. Ini bisa memakan waktu cukup lama untuk diselesaikan, tergantung pada berbagai timer Anda. Jika Anda tidak menunggu setidaknya 2 menit, itu mungkin memengaruhi tes Anda.

— Wade Williams
sumber

1

Anehnya, jika kita menetapkan klien ke 100 / Penuh atau 100 / Setengah, banyak dari mereka melambat secara signifikan. Satu-satunya cara ia terus mengirim lebih cepat dari 10MB adalah dengan mengaturnya untuk melakukan negosiasi otomatis. Tidak masuk akal sama sekali, tetapi banyak dari klien kami adalah Win98 (aplikasi lawas yang tidak dapat kami ganti untuk satu tahun lagi), jadi kami tidak mengacaukannya.

— Beep beep

Saya berbicara tentang koneksi antara switch yang dikonfigurasikan secara manual untuk 100 / Full. Jika dua sakelar dari pabrikan yang sama tidak berfungsi ketika tautan dikonfigurasikan secara manual, ada sesuatu yang sangat salah dan saya akan menggunakan telepon dengan dukungan teknis mereka.

— Wade Williams

Ah. Ini adalah sakelar yang tidak dikelola, dan tidak memungkinkan untuk mengubah kecepatan port.

— Bip bip

Sebenarnya, perilaku itu masuk akal, dan dalam spec. Jika satu sisi (switch) diatur ke otomatis, dan yang lainnya hardcoded ke Full / 100, switch akan mencoba bernegosiasi dan gagal, karena klien tidak bernegosiasi kembali. Agar Full / 100 berfungsi, baik otomatis di kedua sisi, atau hardcode di kedua sisi, jangan campur otomatis dengan hardcoded.

— Geoff

0

Fakta bahwa Anda menggunakan saklar daisy secara bersamaan adalah sumber masalah Anda di sana. Saya akan menyarankan melihat paling tidak membeli switch yang dikelola. Pendekatan yang baik untuk bisnis kecil dan juga yang hemat biaya adalah dengan mengimplementasikan desain inti yang runtuh dengan vlan. Dengan cara ini Anda dapat mensegmentasi domain broadcast / collision dan mengontrol kinerja jaringan Anda.

— Lee
sumber

2

Pengaturan yang ia coba implementasikan bukan rantai daisy.

— rackandboneman

0

Tampak seperti badai arp ketika beberapa sakelar yang tidak dikelola disambungkan dalam ring seperti topologi atau serupa.

ALASAN: Siaran arp di semua port akan menyelesaikan jalur, tetapi beberapa arp sendiri akan bangkit kembali yang menyebabkan badai. Pada situasi seperti itu kecepatan tautan jenuh hingga 100% di semua port dan lalu lintas macet. Gunakan sakelar yang dikelola untuk mengatasi masalah ini.

— Arpan Dubey
sumber

-2

Sesuatu yang perlu dipertimbangkan: Apakah Anda menggunakan crossover atau kabel langsung? Anda harus selalu menggunakan kabel cross-over saat menghubungkan perangkat sejenis. Menggunakan kabel langsung pada port normal akan memperlambat sakelar yang terhubung ke perayapan kecuali sakelar itu dirancang untuk mengoreksi secara otomatis untuk perbedaan kabel. (Some Do).

— specba
sumber

3

Jelas salah. Jika port tidak merasakan otomatis, menggunakan kabel lurus tidak akan berfungsi sama sekali . Dan jika itu adalah penginderaan otomatis, itu tidak akan membuat perbedaan.

— Massimo

Saya akan tidak setuju dengan -2 karena pertanyaannya adalah 2009, tetapi jawabannya datang pada 2012? Saya setuju dengan suara. : P Sekarang-a-hari, tidak masalah jika cross-wired atau tidak.

— Chris K