Kapan / mengapa harus memulai subnetting jaringan?

Dalam kondisi apa seseorang mulai mempertimbangkan subnetting jaringan?

Saya mencari beberapa aturan umum, atau pemicu berdasarkan metrik yang dapat diukur yang membuat subnetting sesuatu yang harus dipertimbangkan.

Pertanyaan menarik.

Secara historis, sebelum munculnya jaringan yang sepenuhnya beralih, pertimbangan utama untuk memecah jaringan menjadi subnet harus dilakukan dengan membatasi jumlah node dalam domain tabrakan tunggal. Artinya, jika Anda memiliki terlalu banyak node, kinerja jaringan Anda akan mencapai puncaknya dan akhirnya akan runtuh di bawah beban berat karena tabrakan yang berlebihan. Jumlah pasti dari node yang dapat digunakan tergantung pada banyak faktor, tetapi secara umum Anda tidak dapat secara teratur memuat domain collision jauh melebihi 50% dari total bandwidth yang tersedia dan masih memiliki jaringan yang stabil sepanjang waktu. 50 node pada jaringan banyak node pada masa itu. Dengan pengguna yang banyak menggunakan, Anda mungkin telah mencapai puncak pada 20 atau 30 node sebelum harus mulai melakukan subnetting.

Tentu saja, dengan subnet dupleks penuh yang sepenuhnya beralih, tabrakan tidak lagi menjadi masalah dan dengan asumsi pengguna tipe desktop, Anda biasanya dapat menggunakan ratusan node dalam satu subnet tanpa masalah sama sekali. Memiliki banyak lalu lintas siaran, seperti yang disinggung oleh jawaban lain, mungkin menjadi perhatian tergantung pada protokol / aplikasi apa yang Anda jalankan di jaringan. Namun, pahami bahwa subnetting jaringan tidak selalu membantu Anda dengan masalah lalu lintas siaran Anda. Banyak protokol menggunakan penyiaran karena suatu alasan - yaitu, ketika semua node pada jaringan benar-benar perlu melihat lalu lintas tersebut untuk mengimplementasikan fitur level aplikasi yang diinginkan. Cukup subnetting jaringan tidak benar-benar membeli Anda apa pun jika paket yang disiarkan juga akan perlu diteruskan ke subnet lain dan disiarkan lagi.

Secara umum, hari ini, alasan utama untuk jaringan subnetting lebih terkait dengan pertimbangan batas organisasi, administrasi dan keamanan daripada yang lainnya.

Pertanyaan awal meminta metrik terukur yang memicu pertimbangan subnetting. Saya tidak yakin ada angka tertentu. Ini akan tergantung secara dramatis pada 'aplikasi' yang terlibat dan saya rasa tidak ada titik pemicu yang secara umum berlaku.

Relatif terhadap aturan praktis dalam merencanakan subnet:

• Pertimbangkan subnet untuk setiap departemen / divisi organisasi yang berbeda, terutama karena mereka menjadi non-sepele (50+ node !?) dalam ukuran.
• Pertimbangkan subnet untuk grup node / pengguna menggunakan set aplikasi umum yang berbeda dari pengguna lain atau tipe node (Pengembang, Perangkat VoIP, lantai pembuatan)
• Pertimbangkan subnet untuk grup pengguna yang memiliki persyaratan keamanan berbeda (mengamankan departemen akuntansi, Mengamankan Wifi)
• Pertimbangkan subnet dari wabah virus, pelanggaran keamanan dan perspektif penahanan kerusakan. Berapa banyak node yang terpapar / dilanggar - apa tingkat paparan yang dapat diterima untuk organisasi Anda? Pertimbangan ini mengasumsikan aturan routing ketat (firewall) antara subnet.

Dengan semua yang dikatakan, menambahkan subnet menambah beberapa tingkat overhead administrasi dan berpotensi menyebabkan masalah relatif terhadap kehabisan alamat node dalam satu subnet dan memiliki terlalu banyak yang tersisa di kumpulan lain, dll. Routing dan pengaturan firewall dan penempatan server umum di jaringan dan semacamnya lebih terlibat, hal semacam itu. Tentu saja, setiap subnet harus memiliki alasan yang ada yang melebihi biaya pemeliharaan topologi logis yang lebih canggih.

Jika ini adalah satu situs, jangan repot-repot kecuali Anda memiliki lebih dari beberapa lusin sistem, dan bahkan mungkin itu tidak perlu.

Saat ini dengan semua orang yang menggunakan sekurangnya 100 Mbps switch dan lebih sering 1 Gbps, satu-satunya alasan terkait kinerja untuk mensegmentasi jaringan Anda adalah jika Anda mengalami lalu lintas siaran berlebih (yaitu> 2%, jauh di atas kepala saya)

Alasan utama lainnya adalah keamanan, yaitu DMZ untuk server yang menghadap publik, subnet lain untuk keuangan, atau VLAN / subnet terpisah untuk sistem VoIP.

Membatasi ruang lingkup untuk semua persyaratan kepatuhan yang mungkin Anda miliki (yaitu PCI) adalah katalis yang cukup bagus untuk membagi segmen dari beberapa jaringan Anda. Mengelompokkan penerimaan pembayaran / pemrosesan dan sistem keuangan Anda dapat menghemat uang. Tetapi secara umum subnetting jaringan kecil tidak akan banyak membantu Anda dalam hal kinerja.

Alasan lain terkait dengan Kualitas Layanan. Kami menjalankan vlan suara dan data secara terpisah sehingga kami dapat dengan mudah menerapkan QoS ke lalu lintas voip.

Anda tahu, saya sudah lebih memikirkan pertanyaan ini. Ada satu ton alasan bagus untuk merancang jaringan baru menggunakan jaringan yang berbeda (kinerja, keamanan, QoS, membatasi cakupan DHCP, membatasi lalu lintas siaran (yang dapat terkait dengan keamanan dan kinerja)).

Tetapi ketika memikirkan metrik untuk mendesain ulang hanya untuk subnet, dan memikirkan jaringan yang harus saya tangani di masa lalu, yang bisa saya pikirkan adalah "wow, itu harus satu jaringan yang benar-benar kacau untuk membuat saya sepenuhnya mendesain ulang untuk subnetting ". Ada banyak alasan lain - bandwidth, pemanfaatan cpu dari perangkat yang diinstal, dll. Tapi hanya men-subnetting sendiri pada jaringan data murni biasanya tidak akan membeli banyak kinerja

Keamanan dan kualitas sebagian besar (selama segmen jaringan yang bersangkutan dapat mendukung node yang dimaksud tentu saja). Sebuah jaringan terpisah untuk lalu lintas printer, suara / telepon, departemen terisolasi seperti IT Ops dan tentu saja segmen server, segmen yang menghadap internet (satu per layanan yang menghadap internet populer saat ini, bukan hanya "satu dmz akan melakukan") dan seterusnya.

Jika Anda berharap untuk meningkatkan (Anda sedang membangun jaringan, bukan hanya 5 server dan itu akan kita) mulai routing secepat mungkin. Terlalu banyak jaringan yang tidak stabil dan sulit untuk tumbuh karena mereka tumbuh secara organik dan memiliki terlalu banyak lapisan 2.

Contoh:

• Anda memiliki dua server nama pada segmen jaringan yang sama. Sekarang Anda tidak dapat memindahkan salah satu dari mereka ke kota lain, karena Anda harus membagi yang bagus / 24 atau memberi nomor baru pada DNS. Jauh lebih mudah jika mereka berada di jaringan yang berbeda. Saya tidak perlu berbicara tentang ini menjadi pengumuman BGP terpisah kepada dunia. Contoh ini akan untuk ISP nasional. Perhatikan juga bahwa beberapa hal di area penyedia layanan tidak semudah "daftarkan saja DNS baru di registrar".
• Lapisan 2 loop menghisap pantat. Seperti halnya spanning tree (dan VTP). Ketika spanning tree gagal (dan ada banyak kasus ketika itu terjadi), itu akan mengambil semuanya dengan itu karena flooding taking switch / router CPU. Ketika OSPF atau IS-IS gagal (atau protokol perutean lainnya) itu tidak akan merusak seluruh jaringan, dan Anda dapat memperbaiki satu segmen pada suatu waktu. Isolasi kesalahan.

Jadi singkatnya: ketika Anda meningkatkan skala ke tempat yang menurut Anda perlu spanning tree, harap pertimbangkan rute sebagai gantinya.

Secara pribadi, saya suka mengambil segmentasi layer 3 sedekat mungkin dengan switch akses, karena

• Saya tidak suka Spanning Tree (Anda bisa membuatnya melakukan hal-hal yang sangat lucu jika Anda jahat)
• Khususnya pada jaringan Windoze, siaran adalah masalah nyata.
• Di jaringan pribadi, Anda memiliki banyak ruang IP untuk dihabiskan :)
• Bahkan sakelar yang lebih murah memiliki kemampuan routing kecepatan kawat sekarang - mengapa tidak menggunakannya?
• Membuat hidup lebih mudah ketika datang ke keamanan (mis. Auth dan ACL di egde, dll)
• Kemungkinan QoS yang lebih baik untuk VoIP dan hal-hal realtime
• Anda dapat mengetahui lokasi klien dari IP-nya

Jika menyangkut jaringan penyebaran yang lebih besar / lebih luas di mana dua sakelar inti / -ruter tidak mencukupi, mekanisme redundansi normal seperti VRRP memiliki banyak kelemahan (lalu lintas melewati tautan berulang kali, ...) OSPF tidak memiliki.

Mungkin ada banyak alasan lain untuk mendukung penggunaan-siaran-kecil-domain- pendekatan.

Saya pikir ruang lingkup organisasi sangat penting. Jika ada 200 host total atau kurang pada jaringan dan lalu lintas tidak perlu disegmentasi untuk alasan apa pun, mengapa menambahkan kompleksitas VLAN dan subnet? Tapi semakin besar cakupannya, semakin masuk akal.

Memisahkan jaringan yang biasanya tidak perlu bisa membuat beberapa hal lebih mudah. Misalnya, PDU kami yang memasok daya ke server berada di VLAN atau subnet yang sama dengan server. Ini berarti sistem pemindaian kerentanan kami yang digunakan pada jangkauan server kami juga memindai PDU. Bukan masalah besar, tetapi kita tidak perlu dipindai untuk diperiksa. Juga akan lebih baik untuk DHCP PDU karena mereka sulit untuk dikonfigurasikan, tetapi karena mereka berada di VLAN yang sama dengan server sekarang, itu sangat tidak layak.

Meskipun kita tidak memerlukan VLAN lain untuk PDU, itu dapat membuat beberapa hal lebih mudah. Dan ini masuk ke argumen VLAN lebih banyak vs lebih sedikit yang akan terus berlanjut selama-lamanya.

Saya, saya hanya berpikir memiliki VLAN mana masuk akal. Jika misalnya kita memberi PDU VLAN mereka sendiri, itu tidak berarti kita harus selalu memberikan kelompok kecil perangkat VLAN mereka sendiri. Namun dalam hal ini mungkin masuk akal. Jika sekelompok perangkat tidak perlu memiliki VLAN sendiri dan tidak ada keuntungan untuk melakukannya, maka Anda mungkin ingin mempertimbangkan untuk membiarkan saja apa adanya.