Berapa banyak VLAN yang terlalu sedikit dan terlalu banyak?


23

Kami saat ini menjalankan netwok dari 800+ PC dan 20+ server, infrastruktur jaringan sejalan dengan Core Switch 10Gb-> Area Switch 2GB-> Local Switch 1GB-> Desktop. Semua menjalankan peralatan 3Com (1).

Kami memiliki 3 sakelar Area untuk empat area (A, B, C, D digabung dengan inti), masing-masing sakelar area akan memiliki antara 10 dan 20 sakelar lokal yang terhubung dengannya. Ada juga sakelar inti cadangan, yang bertenaga lebih rendah tetapi terhubung seperti sakelar inti utama.

Kami juga memiliki sistem telepon IP. Komputer / server dan swicthes berada pada kisaran ip 10x, telepon pada kisaran 192.168.x. Komputer umumnya tidak harus berbicara satu sama lain kecuali di laboratorium komputer, tetapi mereka harus dapat berbicara dengan sebagian besar server kami (AD, DNS, Exchange, Penyimpanan file, dll.)

Ketika kami mengatur, diputuskan bahwa kami akan memiliki 3 VLAN, satu untuk Switches & Komputer, satu untuk Telepon dan satu untuk replikasi server (ini bertentangan dengan saran insinyur 3Com). Jaringan telah stabil dan berfungsi sejak saat ini (2), tetapi kami sekarang telah mulai memutakhirkan ke SAN dan lingkungan Virtualisasi. Sekarang memecah infrastruktur baru ini menjadi VLAN terpisah masuk akal, dan mengunjungi kembali bagaimana VLAN kami diatur tampaknya masuk akal.

Saat ini sedang diusulkan bahwa VLAN harus diatur dalam ruangan berdasarkan kamar, yaitu lab komputer dengan 5+ PC harus VLAN itu sendiri, tetapi jika kita mengikuti model ini kita akan melihat setidaknya 25 VLAN "baru" , plus VLANS untuk SAN / server Virtual. Yang menurut saya akan menambah jumlah administrasi yang berlebihan, meskipun saya cukup senang terbukti salah.

Apa yang akan disarankan sebagai praktik terbaik? Apakah ada sejumlah PC yang disarankan untuk tidak melewati / di bawah dalam VLAN.

(1) 3Com mengganti (3870 & 8800) rute antara VLAN secara berbeda dengan cara beberapa orang lain melakukannya, itu tidak memerlukan router terpisah karena mereka layer3.

(2) Kami kadang-kadang mendapatkan tingkat pembuangan yang tinggi, atau perubahan STP, dan pada saat itu direktur Jaringan 3Com melaporkan bahwa sakelar kurang beban dan lambat untuk merespons ping, atau sakelar yang gagal mengatur untuk menjatuhkan jaringan (semua VLANS telepon & komputer! , sekali, tidak tahu kenapa)

Jawaban:


36

Sepertinya seseorang di organisasi Anda ingin membuat VLAN tanpa mengerti alasan mengapa Anda melakukannya dan pro / kontra yang terkait dengannya. Kedengarannya seperti Anda perlu melakukan beberapa pengukuran dan menemukan beberapa alasan nyata untuk melakukan ini sebelum bergerak maju, setidaknya dengan kekonyolan "VLAN untuk sebuah ruangan" yang gila.

Anda seharusnya tidak mulai memecah Ethernet LAN menjadi VLAN kecuali Anda memiliki alasan yang baik untuk melakukannya. Dua alasan terbaik adalah:

  • Mengurangi masalah kinerja. Ethernet LAN tidak dapat melakukan skala tanpa batas. Siaran yang berlebihan atau membanjiri frame ke tujuan yang tidak diketahui akan membatasi skalanya. Salah satu dari kondisi ini dapat disebabkan karena membuat domain siaran tunggal dalam LAN Ethernet terlalu besar. Lalu lintas siaran mudah dipahami, tetapi membanjiri frame ke tujuan yang tidak diketahui sedikit lebih kabur ( sedemikian rupa sehingga tidak ada poster lain di sini yang bahkan menyebutkannya!). Jika Anda mendapatkan begitu banyak perangkat sehingga tabel MAC switch Anda meluap, switch akan dipaksa membanjiri frame non-broadcast dari semua port jika tujuan frame tidak cocok dengan entri apa pun dalam tabel MAC. Jika Anda memiliki domain siaran tunggal yang cukup besar di LAN Ethernet dengan profil lalu lintas yang jarang berbicara (yaitu, jarang sekali entri mereka telah keluar dari tabel MAC pada sakelar Anda), maka Anda juga bisa mendapatkan membanjiri frame secara berlebihan. .

  • Keinginan untuk membatasi / mengontrol lalu lintas yang bergerak di antara host pada layer 3 atau lebih. Anda dapat melakukan beberapa peretasan memeriksa lalu lintas pada layer 2 (ala Linux ebtables) tetapi ini sulit untuk dikelola (karena aturan terikat dengan alamat MAC dan mengubah NIC mengharuskan perubahan aturan) dapat menyebabkan apa yang tampak sebagai perilaku yang benar-benar aneh (melakukan proxy transparan HTTP pada lapisan 2, misalnya, aneh dan menyenangkan, tetapi sama sekali tidak alami dan bisa sangat tidak intuitif untuk memecahkan masalah), dan umumnya sulit dilakukan pada lapisan bawah (karena alat lapisan 2 seperti tongkat) dan batu di berurusan dengan layer 3+ keprihatinan). Jika Anda ingin mengontrol lalu lintas IP (atau TCP, atau UDP, dll) di antara host, daripada menyerang masalah pada layer 2, Anda harus menggunakan subnet dan menempelkan firewall / router dengan ACL di antara subnet.

Masalah kelelahan bandwidth (kecuali jika disebabkan oleh paket broadcast atau membanjirnya frame) biasanya tidak diselesaikan dengan VLAN. Mereka terjadi karena kurangnya konektivitas fisik (terlalu sedikit NIC di server, terlalu sedikit port dalam grup agregasi, kebutuhan untuk naik ke kecepatan port yang lebih cepat) dan tidak dapat diselesaikan dengan men-subnetting atau menggunakan VLAN sejak menang dapat meningkatkan jumlah bandwidth yang tersedia.

Jika Anda tidak memiliki bahkan sesuatu yang sederhana seperti MRTG berjalan grafik statistik per-port lalu lintas di switch Anda yang benar-benar urutan pertama Anda bisnis sebelum Anda mulai berpotensi memperkenalkan kemacetan dengan segmentasi VLAN bermaksud baik tapi kurang informasi. Hitungan byte mentah adalah awal yang baik, tetapi Anda harus menindaklanjutinya dengan mengendus yang ditargetkan untuk mendapatkan detail lebih lanjut tentang profil lalu lintas.

Setelah Anda tahu bagaimana lalu lintas bergerak di LAN Anda, Anda dapat mulai berpikir tentang segmentasi LAN untuk alasan kinerja.

Jika Anda benar-benar akan mencoba dan menekan paket dan stream-level akses antara VLAN bersiaplah untuk melakukan banyak kerja keras dengan perangkat lunak aplikasi dan belajar / rekayasa balik cara berbicara melalui kabel. Membatasi akses oleh host ke server seringkali dapat dilakukan dengan fungsionalitas pemfilteran di server. Membatasi akses pada kabel dapat memberikan rasa aman yang salah dan administrator menidurkan ke dalam kepuasan di mana mereka berpikir "Yah, saya tidak perlu mengkonfigurasi aplikasi. Aman karena host yang dapat berbicara dengan aplikasi. Dibatasi oleh 'itu jaringan'." Saya mendorong Anda untuk mengaudit keamanan konfigurasi server Anda sebelum saya mulai membatasi komunikasi host-ke-host pada kabel.

Biasanya Anda membuat VLAN di Ethernet dan memetakan subnet IP 1-ke-1 ke dalamnya. Anda akan membutuhkan BANYAK subnet IP untuk apa yang Anda uraikan, dan berpotensi banyak entri tabel perutean. Rencanakan subnet dengan VLSM dengan lebih baik untuk merangkum entri tabel perutean Anda, eh?

(Ya, ya - ada beberapa cara untuk tidak menggunakan subnet terpisah untuk setiap VLAN, tetapi dengan tetap menggunakan dunia "vanilla biasa" yang Anda ingin buat VLAN, pikirkan subnet IP untuk digunakan dalam VLAN, tetapkan beberapa router alamat IP di VLAN itu, pasang router itu ke VLAN, baik dengan antarmuka fisik atau subinterface virtual pada router, sambungkan beberapa host ke VLAN dan berikan alamat IP di subnet yang Anda tentukan, dan rutekan traffic mereka di dan keluar dari VLAN.)


2
Ini adalah penjelasan yang bagus. Saya hanya akan menambahkan bahwa, dengan sebagian besar perangkat keras modern, segmentasi tidak rumit selama Anda menyadari bahwa VLAN perlu dialihkan antara. Tidak banyak manfaatnya bagi Anda untuk memiliki pengaturan VLAN super efisien yang menggunakan router yang terlalu sibuk pada tongkat untuk meneruskan lalu lintas antar segmen.
Greeblesnort

2

VLAN hanya sangat berguna untuk membatasi lalu lintas siaran. Jika sesuatu akan melakukan banyak penyiaran, maka pisahkan menjadi VLAN sendiri, kalau tidak saya tidak akan repot. Anda mungkin ingin memiliki duplikasi tervirtualisasi dari sistem live di jaringan yang sama dan ingin menggunakan rentang alamat yang sama, sekali lagi, yang mungkin bernilai VLAN terpisah.


Kami sedang menjalankan XP tanpa WINS saat ini - melakukan nbtstat -r sepertinya menyarankan kami mendapatkan jumlah lalu lintas siaran.
Tubs

1
Ukurlah dengan sesuatu seperti Wireshark dan lihat apa yang terjadi. MENANG bukanlah hal yang mengerikan. Jika Anda menemukan bahwa Anda mendapatkan banyak permintaan pencarian nama NetBIOS, cobalah dan dapatkan nama yang tepat di DNS untuk mencegah permintaan atau jalankan WINS.
Evan Anderson

2

VLAN bagus sebagai tingkat keamanan tambahan. Saya tidak tahu bagaimana 3Com menanganinya tetapi biasanya Anda dapat membagi kelompok-kelompok fungsional yang berbeda ke dalam VLAN yang berbeda (misalnya Akuntansi, WLAN, dll.). Anda kemudian dapat mengontrol siapa yang memiliki akses ke VLAN tertentu.

Saya tidak percaya ada kerugian kinerja yang signifikan jika ada banyak komputer di VLAN yang sama. Saya merasa tidak praktis untuk melakukan segmentasi LAN di sebuah ruangan berdasarkan ruangan, tapi sekali lagi, saya tidak tahu bagaimana 3Com menanganinya. Biasanya pedoman ini bukan ukuran, melainkan keamanan atau operasi.

Akibatnya saya tidak melihat alasan untuk menyegmentasikan LAN ke dalam VLAN yang berbeda jika tidak ada keamanan atau keuntungan operasional.


1

Kecuali jika Anda memiliki 25 kelompok uji dan pengembangan yang secara rutin membunuh jaringan dengan banjir siaran, 25 VLAN per-kamar adalah 24 terlalu banyak.

Jelas SAN Anda membutuhkan VLAN sendiri dan bukan VLAN yang sama dengan sistem virtual LAN dan akses Internet! Ini semua dapat dilakukan melalui port ethernet tunggal pada sistem host, jadi jangan khawatir tentang pemisahan fungsi-fungsi tersebut.

Jika Anda memiliki kinerja omong kosong, pertimbangkan untuk meletakkan Ponsel dan SAN Anda di perangkat keras jaringan yang terpisah, bukan hanya VLAN.


0

Akan selalu ada lalu lintas siaran, apakah itu siaran resolusi nama, siaran ARP, dll. Yang penting adalah memantau jumlah lalu lintas siaran. Jika melebihi 3 - 5% dari total lalu lintas maka itu menjadi masalah.

VLAN bagus untuk mengurangi ukuran domain broadcast (seperti yang dinyatakan David) atau untuk keamanan, atau untuk membuat jaringan cadangan khusus. Mereka tidak benar-benar dimaksudkan sebagai domain "manajemen". Selain itu, Anda akan menambahkan kompleksitas perutean dan overhead ke jaringan Anda dengan menerapkan VLAN.


Saya bersama Anda sampai Anda menyebutkan rute overhead. Ada biaya untuk routing, tetapi biasanya perangkat keras yang melakukan L2 / L3 akan meneruskan paket-paket dari satu vlan ke yang lain (dan dari satu port ke yang lain) pada kecepatan yang sama seolah-olah itu diteruskan melalui L2.
chris

Benar, saya tidak menangkap bagian dalam posting asli tentang switch 3COM yang dapat merutekan lalu lintas antara VLAN tanpa perlu router (jadi saya akan berasumsi bahwa mereka adalah switch L3). Terima kasih.
joeqwerty

Mereka mungkin bekerja pada kecepatan kawat, tetapi mereka masih router untuk mengkonfigurasi dan mengelola, bahkan jika mereka hanya lapisan 3 entitas di dalam switch. Jika mereka "beralih" paket pada layer 3 mereka adalah router.
Evan Anderson

0

Secara umum, Anda hanya ingin mempertimbangkan untuk menggunakan VLAN ketika Anda perlu mengkarantina perangkat (seperti area di mana pengguna dapat membawa laptop mereka sendiri, atau ketika Anda memiliki infrastruktur server kritis yang harus dilindungi) atau jika domain siaran Anda terlalu tinggi.

Broadcast domain biasanya sekitar 1000 perangkat besar sebelum Anda mulai melihat masalah pada jaringan 100Mbit, meskipun saya akan membawanya ke 250 perangkat jika Anda berurusan dengan area Windows yang relatif bising.

Sebagian besar, jaringan modern tidak membutuhkan VLAN kecuali Anda melakukan karantina ini (tentu saja dengan firewall yang menggunakan ACL) atau batasan siaran.


1
Mereka membantu untuk menjaga nugget dalam akuntansi dari mendirikan sebuah webcam dengan IP dari server email ...
chris

0

Mereka juga berguna untuk mencegah siaran DHCP untuk menjangkau perangkat jaringan yang tidak diinginkan.


1
Mengurangi masalah kinerja telah disebutkan, terima kasih.
Chris S
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.