Cara terbaik untuk membagi lalu lintas, VLAN atau subnet?


13

Kami memiliki jaringan berukuran sedang sekitar 200 node dan saat ini sedang dalam proses mengganti sakelar berantai daisy lama dengan sakelar stack-mampu atau sakelar gaya sasis.

Saat ini, jaringan kami dipecah melalui subnet: produksi, manajemen, kekayaan intelektual (IP), dll., Masing-masing pada subnet terpisah. Apakah membuat VLAN dan bukannya subnet akan lebih bermanfaat?

Tujuan umum kami adalah mencegah kemacetan, memisahkan lalu lintas untuk keamanan, dan mengelola lalu lintas dengan lebih mudah.


1
mungkin vlan yang berbeda akan digunakan untuk memiliki subnet yang terpisah di dalamnya.
pQd

1
Anda mungkin menemukan Jawaban Evan untuk pertanyaan ini, saya bertanya beberapa waktu lalu, membantu: serverfault.com/questions/25907/…
Kyle Brandt

Jawaban:


16

VLAN dan subnet menyelesaikan berbagai masalah. VLAN berfungsi pada Layer 2 , sehingga mengubah domain broadcast (misalnya). Sedangkan subnet adalah Layer 3 dalam konteks saat ini

Satu saran adalah untuk benar-benar mengimplementasikan keduanya

Memiliki, misalnya, VLAN 10 - 15 untuk berbagai jenis perangkat Anda (Dev, Test, Production, Users, dll)

VLAN 10, Anda mungkin memiliki subnet 192.168.54.x / 24 VLAN 11, Anda mungkin memiliki subnet 192.168.55.x / 24

Dan seterusnya

Ini akan mengharuskan Anda memiliki router di jaringan Anda

Agak terserah Anda apa rute Anda turun (Anda tahu jaringan Anda lebih baik daripada aku akan pernah). Jika Anda berpikir bahwa ukuran domain siaran Anda akan menjadi semacam masalah, maka gunakan VLAN. Jika Anda berpikir bahwa ukuran domain manajemen jaringan Anda (misalnya, jaringan manajemen Anda) maka mungkin menggunakan jaringan yang lebih dekat ke / 16 di atas / 24

200 node Anda akan masuk ke dalam / 24, tapi itu jelas tidak memberi Anda banyak ruang untuk pertumbuhan

Dengan suara itu, Anda sudah menggunakan subnet yang berbeda untuk berbagai jenis perangkat. Jadi, mengapa tidak bertahan dengan itu? Anda bisa, jika mau, mengikat setiap subnet ke VLAN. Segmentasi lapisan 2 akan mengakibatkan perilaku jaringan Anda berubah dari bagaimana perilakunya saat ini

Anda harus menyelidiki dampak potensial dari hal itu


2
+1 - Mengatakan hampir semua yang saya inginkan. Jika Anda akan membatalkan desain subnetting saat ini yang Anda miliki, satu-satunya saran tambahan saya adalah menjelajahi pengaturan ruang alamat menggunakan / 22 atau / 23. Mungkin "hapus" bit jika Anda membutuhkan lebih banyak subnet. Bagaimanapun, kita tidak lagi terbatas pada / 16 atau / 24 lagi. Kemudian, letakkan setiap subnet di VLAN sendiri untuk mengurangi lalu lintas siaran.
romandas

13

(Aku sudah berada di jalan sepanjang hari dan melewatkan lompatan yang satu ini ... Tetap saja, terlambat ke permainan aku akan melihat apa yang bisa kulakukan.)

Biasanya Anda membuat VLAN di Ethernet dan memetakan subnet IP 1-ke-1 ke dalamnya. Ada beberapa cara untuk tidak melakukan ini, tetapi dengan tetap berada di dunia "vanilla biasa" yang ketat, Anda akan membuat 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 tetapkan alamat IP-nya di subnet yang Anda tentukan, dan rutekan traffic mereka masuk dan keluar dari VLAN.

Anda seharusnya tidak memulai subnetting Ethernet LAN kecuali Anda memiliki alasan yang bagus untuk melakukannya. Dua alasan terbaik adalah:

  • Mengurangi masalah kinerja. LAN Ethernet tidak dapat diskalakan tanpa batas. Siaran 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 tidak jelas. Jika Anda mendapatkan begitu banyak perangkat sehingga tabel MAC switch Anda beralih berlebihan akan dipaksa untuk membanjiri frame non-broadcast keluar semua port jika tujuan frame tidak cocok dengan entri dalam tabel MAC. Jika Anda memiliki domain siaran tunggal yang cukup besar di LAN Ethernet dengan profil lalu lintas yang jarang berbicara (yaitu,

  • 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 lapisan 2 (ala Linux ebtables) tetapi ini sulit untuk dikelola (karena aturan yang dikaitkan dengan alamat MAC dan mengganti 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 disebabkan oleh paket broadcast atau membanjirnya frame) tidak diselesaikan dengan VLAN dan subnetting biasanya. Mereka terjadi karena kurangnya konektivitas fisik (terlalu sedikit NIC pada 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 bermaksud baik tapi kurang informasi subnetting. 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 subnetting karena alasan kinerja.

Sejauh "keamanan" Anda akan perlu tahu banyak tentang perangkat lunak aplikasi Anda dan bagaimana itu berbicara sebelum Anda dapat melanjutkan.

Saya melakukan desain untuk LAN / WAN berukuran resonansi untuk Pelanggan medikal beberapa tahun yang lalu dan saya diminta untuk meletakkan daftar akses pada entitas layer 3 (modul supervisor Cisco Catalyst 6509) untuk mengontrol lalu lintas yang bergerak antara subnet dengan " Insinyur "yang memiliki sedikit pemahaman tentang jenis kerja keras apa yang sebenarnya dibutuhkan tetapi sangat tertarik pada" keamanan ". Ketika saya kembali dengan proposal untuk mempelajari setiap aplikasi untuk menentukan port TCP / UDP dan host tujuan yang diperlukan, saya mendapat respons yang mengejutkan dari "insinyur" yang menyatakan bahwa seharusnya tidak terlalu sulit. Yang terakhir yang saya dengar mereka menjalankan entitas layer 3 tanpa daftar akses karena mereka tidak bisa mendapatkan semua perangkat lunak mereka bekerja dengan andal.

Moral: Jika Anda benar-benar akan mencoba dan mengecilkan paket dan akses stream-level 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 penyaringan pada 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.


2
Saya senang melihat beberapa alasan setelah jawaban menyarankan untuk pergi / 16.
pQd

4
Anda dapat subnet menjadi subnet besar atau kecil secara sewenang-wenang. Jumlah host di domain subnet / broadcast adalah yang penting, bukan jumlah host yang mungkin (selama Anda memiliki ruang alamat yang cukup). Apa ungkapannya - bukan ukuran subnet Anda yang penting, melainkan bagaimana Anda menggunakannya? > tersenyum <
Evan Anderson

@ Evan Anderson: saya tahu itu. tetapi Anda harus mengakui bahwa 64k terlalu banyak, mungkin tidak akan pernah digunakan dan dapat menyebabkan masalah ketika perutean perlu diperkenalkan [misalnya untuk menghubungkan remote DC / kantor / dll].
pQd

1

99% dari waktu, sebuah subnet harus setara dengan VLAN (yaitu setiap subnet akses harus dipetakan ke satu dan hanya satu VLAN).

Jika Anda memiliki host dari lebih dari satu subnet IP dalam VLAN yang sama, Anda mengalahkan tujuan VLAN, karena dua (atau lebih) subnet akan berada pada domain broadcast yang sama.

Atau, jika Anda menempatkan satu subnet IP ke beberapa VLAN, host di subnet IP tidak akan dapat berkomunikasi dengan host di VLAN lain kecuali router Anda memiliki proxy ARP yang diaktifkan.


-1 - VLAN membagi domain siaran. Domain tabrakan dibagi oleh jembatan atau jembatan multi-port yang lebih dikenal sebagai sakelar. Subnet IP dan domain broadcast / collision tidak ada hubungannya satu sama lain dalam kasus umum. Dalam kasus spesifik IP over Ethernet, umum untuk subnet IP dipetakan ke domain broadcast tunggal (karena ARP, protokol yang digunakan untuk menyelesaikan alamat IP ke alamat perangkat keras Ethernet berbasis siaran), tetapi dimungkinkan untuk menggunakan tipuan pintar dengan proxy ARP memiliki subnet span beberapa domain broadcast.
Evan Anderson

@ Evan: poin bagus - itu akan mengajari saya untuk menulis jawaban pada dini hari. :) Saya mendukung poin yang tersisa; memiliki beberapa subnet dalam VLAN yang sama akan menyebabkan lalu lintas siaran L2 Anda menjangkau beberapa subnet; memiliki beberapa VLAN untuk subnet yang sama akan berfungsi, tetapi proxy ARP sebenarnya bukan sesuatu yang harus Anda gunakan jika Anda dapat menghindarinya.
Murali Suriar

-1 dihapus - Segala sesuatu yang Anda katakan pasti akurat. Saya setuju juga, re: proxy ARP - Saya tidak akan menggunakannya di "dunia nyata" kecuali saya memiliki alasan kuat yang sangat kuat.
Evan Anderson

"Subnet IP dan domain broadcast / collision tidak ada hubungannya satu sama lain dalam kasus umum." Tidak, mereka pasti melakukannya dalam kasus umum. Setiap subnet memiliki nomor jaringan dan alamat siaran yang terkait. Selain ARP, Anda memiliki paket siaran lainnya. Akan salah jika pernyataan ini tidak mengetahui apakah mereka memiliki lalu lintas multicast di jaringan mereka. Klien DHCP menggunakan siaran IP untuk mempelajari server DHCP.
Kilo

1
@ Evan Anderson Apa yang saya lewatkan di sini. Anda menarik -1 Anda. Domain collision tumpah oleh switch ports. Mengatakan 2 atau subnet dalam domain collision adalah omong kosong. Saya pikir maksudnya adalah 2 atau lebih subnet dalam domain siaran .
JamesBarnett

-5

Saya sebagian besar setuju dengan David Pashley :

  1. Saya menggunakan satu / 16 untuk semuanya.
    • tapi itu tersegmentasi pada beberapa VLAN, bergabung dengan jembatan perangkat lunak pada mesin Linux.
    • di jembatan ini, saya punya beberapa aturan iptables untuk memfilter akses antar grup.
    • tidak masalah bagaimana Anda melakukan segmentasi, gunakan rentang IP untuk pengelompokan, membuat restrukturisasi dan kasus khusus menjadi lebih mudah.

2
Kedengarannya seperti mimpi buruk untuk dihadapi!
Evan Anderson

2
-1 Anda tidak mengatakan seberapa besar jaringan yang Anda pertahankan, kecuali Anda berbicara tentang proyek penelitian, saya tidak bisa seumur hidup memikirkan alasan untuk menggunakan konfigurasi semacam itu. Secara definisi, subnet adalah "rentang IP" yang digunakan untuk pengelompokan. Sepertinya Anda menciptakan kembali layer 3 dengan menggunakan kotak Linux untuk melakukan perutean Anda pada layer 2. Kemungkinan akan menciptakan masalah yang disembunyikan oleh kompleksitas yang tidak dibutuhkan. Ini menciptakan sesuatu yang akan sulit bagi orang lain untuk mencari tahu apalagi memecahkan masalah.
Rik Schneider
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.