Bir ağı alt ağa bağlamaya ne zaman / neden?

Hangi koşullar altında ağ alt ağ oluşturmaya karar verilir?

Birkaç genel kural ya da düşünülmesi gereken bir şeyi alt ağları oluşturan ölçülebilir ölçütlere dayalı tetikleyiciler arıyorum.

İlginç soru.

Tarihsel olarak, tamamen anahtarlamalı ağların ortaya çıkmasından önce, bir ağı alt ağlara bölmenin ana düşüncesi, tek bir çarpışma alanındaki düğüm sayısını sınırlamakla ilgiliydi. Yani, çok fazla düğümünüz olsaydı, ağ performansınız zirveye ulaşır ve sonunda aşırı çarpışmalar nedeniyle ağır yük altında çöker. Dağıtılabilecek düğüm sayısı kesin olarak birçok faktöre bağlıydı, ancak genel olarak konuşursanız, çarpışma alanını mevcut toplam bant genişliğinin% 50'sinden daha fazlasına düzenli olarak yükleyemediniz ve ağın her zaman istikrarlı olmasını sağlamışsınız. Ağda 50 düğüm o günlerde çok sayıda düğüm oldu. Yoğun kullanımlı kullanıcılarda, alt ağları başlatmaya gerek duymadan önce 20 veya 30 düğümde tepe yapmış olabilirsiniz.

Tabii ki, tamamen değiştirilmiş tam çift yönlü alt ağlarla, çarpışmalar artık bir sorun değil ve tipik masaüstü tipi kullanıcıları varsayarsak, genellikle tek bir alt ağda yüzlerce düğümü herhangi bir sorun olmadan dağıtabilirsiniz. Diğer cevapların bahsettiği gibi çok fazla yayın trafiğine sahip olmak, ağda hangi protokolleri / uygulamaları çalıştırdığınıza bağlı olarak endişe verici olabilir. Ancak, bir ağın alt ağının yayın trafiğiyle ilgili endişelerinizde size yardımcı olamayacağının farkında olun. Protokollerin birçoğu yayını bir nedenle kullanır - yani, ağdaki tüm düğümlerin gerçekte istenen uygulama düzeyi özelliklerini uygulamak için bu tür bir trafiği görmesi gerekir. Eğer yayınlanmış paketin diğer alt ağa yönlendirilmesi ve tekrar yayınlanması gerekiyorsa, basitçe ağın alt ağa alınması size bir şey almaz.

Genel olarak konuşursak, bugün, alt ağların temel nedenlerinin örgütsel, idari ve güvenlik sınırlarıyla ilgili her şeyden çok daha fazla ilgisi var.

Orijinal soru, alt ağ oluşturma düşüncelerini tetikleyen ölçülebilir ölçümler ister. Belirli numaralar açısından olduğundan emin değilim. Bu, büyük ölçüde ilgili 'uygulamalara' bağlı olacak ve genel olarak uygulanacak herhangi bir tetikleyici nokta olduğunu sanmıyorum.

Alt ağları planlamada başparmak kurallarına göre:

• Her önemsiz organizasyonel bölüm / bölüm için alt ağları göz önünde bulundurun, özellikle önemsiz olmalarından (50+ düğüm !?) büyüklük kazanıyorlar.
• Diğer kullanıcılardan veya düğüm türlerinden (ortak geliştiriciler, VoIP aygıtları, üretim katı) farklı olan ortak bir uygulama seti kullanan düğüm / kullanıcı grupları için alt ağları göz önünde bulundurun
• Farklı güvenlik gereksinimleri olan kullanıcı grupları için alt ağları göz önünde bulundurun (muhasebe bölümünü güvence altına alma, Wifi güvenliğini sağlama)
• Alt ağları bir virüs salgını, güvenlik ihlali ve hasar tutma perspektifinden ele alın. Kaç düğüm maruz kalıyor / ihlal ediliyor - kuruluşunuz için kabul edilebilir bir maruz kalma seviyesi nedir? Bu değerlendirme, alt ağlar arasında kısıtlayıcı yönlendirme (güvenlik duvarı) kuralları olduğunu varsayar.

Bununla birlikte, alt ağları eklemek, bir miktar genel yönetim ek yükü ekler ve potansiyel olarak bir alt ağdaki düğüm adreslerinin tükenmesi ve başka bir havuzda çok fazla kalmasıyla ilgili sorunlara neden olur, vb. Ağ ve böyle daha fazla dahil olmak, bu tür bir şey. Kuşkusuz, her bir alt ağ , daha sofistike mantıksal topolojiyi korumanın yüküne ağır basan bir nedene sahip olmalıdır .

Tek bir site ise, birkaç düzineden fazla sisteminiz olmadıkça zahmet etmeyin ve o zaman bile muhtemelen gereksizdir.

Bugünlerde herkes en az 100 Mbps anahtar ve daha sık 1 Gbps kullanan, ağınızı bölümlere ayırmak için performansla ilgili tek neden aşırı yayın trafiği çekiyorsanız (yani,% 2, başımın üstünde)

Bunun temel nedeni güvenlik, yani halka açık sunucular için DMZ, finans için başka bir alt ağ veya VoIP sistemleri için ayrı bir VLAN / alt ağdır.

Sahip olabileceğiniz tüm uyumluluk gereklilikleri için kapsamı sınırlamak (örneğin, PCI) ağınızın bazı bölümlerini ayırmak için oldukça iyi bir katalizördür. Ödeme kabul / işleme ve finans sistemlerinizi bölümlere ayırmak paradan tasarruf etmenizi sağlar. Ancak genel olarak küçük bir ağın alt ağda tutulması size performans konusunda pek bir şey kazandırmayacaktır.

Diğer bir neden ise Hizmet Kalitesi ile ilgili olacaktır. Ses ve veri alanlarını ayrı ayrı çalıştırıyoruz, böylece QoS'yi voip trafiğine kolayca uygulayabiliyoruz.

Biliyor musun, ben bu soruyu daha çok düşünüyorum. Farklı ağlar (performans, güvenlik, QoS, DHCP kapsamlarını sınırlandırmak, yayın trafiğini sınırlandırmak (hem güvenlik hem de performansla ilgili olabilir)) kullanarak yeni bir ağ tasarlamak için birçok neden vardır.

Ancak, sadece alt ağa yeniden tasarım yapmak için bir ölçüm yapmayı ve geçmişte ele almam gereken ağları düşünmeyi düşünürken, tek düşünebildiğim "vay, bu beni tamamen yeniden dizayn etmek için gerçekten dağılmış bir ağa bağlamalıydı" onun için subnetting ". Başka pek çok neden var - bant genişliği, takılan cihazların cpu kullanımı, vb.

Güvenlik ve kalite çoğunlukla (söz konusu ağ kesimi söz konusu düğümleri destekleyebildiği sürece). Yazıcı trafiği, ses / telefon, IT Ops ve tabii ki sunucu bölümleri, internete bakan bölümler (internete bakan servis başına bir tane, bugün sadece popüler olanıdır, sadece "bir dmz yapacak" gibi) için ayrı bir ağ vb.

Ölçeklendirmeyi umuyorsanız (bir ağ oluşturuyorsunuz, sadece 5 sunucu değil, biz de öyle yapacağız) en kısa sürede yönlendirmeye başlayın. Çok fazla ağ, kararsız ve büyümesi zor, çünkü organik olarak büyüdüler ve çok fazla katman 2'ye sahipler.

Örnekler:

• Aynı ağ segmentinde iki isim sunucunuz var. Şimdi onlardan birini başka bir şehre taşıyamazsınız, çünkü o zaman bu güzel / 24'ü ayırmanız veya DNS'i yeniden numaralandırmanız gerekir. Farklı ağlarda olsaydı çok daha kolay. Bunların mutlaka dünyaya ayrı BGP açıklamaları yapmalarından bahsetmiyorum. Bu örnek ülke çapında bir ISS için olacaktır. Ayrıca, servis sağlayıcı alanındaki bazı şeylerin "sadece yeni DNS'i kayıt defterine kaydetme" kadar kolay olmadığını unutmayın.
• Katman 2 döngüler emmek eşek. Yayılan ağaç (ve VTP) gibi. Yayılma ağacı başarısız olduğunda (ve olduğu zaman birçok durum vardır), anahtar / yönlendirici CPU alıp taşması nedeniyle her şeyi alacaktır. OSPF veya IS-IS başarısız olduğunda (veya diğer yönlendirme protokolleri) tüm ağa zarar vermez ve aynı anda bir segmenti düzeltebilirsiniz. Arıza izolasyonu.

Yani, kısaca: Yayılma ağacına ihtiyacınız olduğunu düşündüğünüz yere ölçeklenirken, bunun yerine yönlendirmeyi düşünün.

Şahsen, katman 3 segmentasyonunu erişim anahtarlarına mümkün olduğunca yakın tutmayı seviyorum, çünkü

• Spanning Tree'den hoşlanmıyorum (kötüyseniz çok komik şeyler yapmasını sağlayabilirsiniz)
• Özellikle Windoze ağlarında yayınlar gerçek bir problemdir.
• Özel ağlarda boşa harcanacak çok fazla IP alanınız var :)
• Daha ucuz anahtarların bile şimdiye kadar kablo hızında yönlendirme yetenekleri vardır - neden bunları kullanmıyorsunuz?
• Güvenlik söz konusu olduğunda hayatı kolaylaştırır (örneğin, egde'deki Auth ve ACL'ler, vb.)
• VoIP ve gerçek zamanlı şeyler için daha iyi QoS olanakları
• Bir müşterinin yerini IP’sinden öğrenebilirsiniz.

İki çekirdek anahtarın / yönlendiricinin yeterli olmadığı daha büyük / daha geniş yayılma ağları söz konusu olduğunda, VRRP gibi normal yedeklilik mekanizmalarının birçok dezavantajı vardır (trafik birden fazla kez üst üste gelir ...) OSPF'de yoktur.

-Küçük -yayın-etki alanları- yaklaşımını kullanmanın desteklenmesi için muhtemelen başka nedenler vardır .

Bence organizasyonun kapsamı çok önemli. Bir ağda toplam veya daha az toplam ana bilgisayar varsa ve trafiğin herhangi bir nedenle bölümlere ayrılması gerekmiyorsa, neden VLAN ve alt ağların karmaşıklığını eklemelisiniz? Ancak kapsam büyüdükçe, daha anlamlı olabilir.

Normalde olması gerekmeyen ağları ayırmak, bazı şeyleri daha kolaylaştırabilir. Örneğin, sunuculara güç sağlayan PDU'larımız sunucularla aynı VLAN veya alt ağdadır. Bu, sunucu yelpazemizde kullanılan güvenlik açığı tarama sistemimizin PDU’ları da taradığı anlamına gelir. Çok önemli bir şey değil, fakat taranacak PDU’lara ihtiyacımız yok. Ayrıca PDU'ların DHCP'yi yapılandırması çok acı verici oldukları için DHCP için iyi olurdu, ancak şu anda sunucularla aynı VLAN'da oldukları için bu pek mümkün değil.

PDU'lar için başka bir VLAN'a ihtiyacımız olmasa da, bazı şeyleri kolaylaştırabilir. Ve bu, çok daha uzun sürecek olan VLAN argümanına karşı daha fazla kazanıyor.

Ben, sadece anlam ifade ettiği yerde VLAN'lar olduğunu düşünüyorum. Örneğin, PDU'lara kendi VLAN'larını vermiş olsaydık, küçük cihaz gruplarına her zaman kendi VLAN'larını vermemiz gerektiği anlamına gelmez. Ancak bu durumda daha mantıklı olabilir. Bir grup cihazın kendi VLAN'ına sahip olması gerekmiyorsa ve bunu yapmanın avantajı yoksa, şeyleri olduğu gibi bırakmayı düşünebilirsiniz.