Kiedy / dlaczego rozpocząć podsieć sieci?

W jakich warunkach zaczyna się rozważać podsieci sieci?

Szukam kilku ogólnych zasad lub wyzwalaczy opartych na mierzalnych metrykach, które sprawiają, że podsieci to coś, co należy rozważyć.

Interesujące pytanie.

Historycznie, przed nadejściem w pełni przełączanych sieci, główna uwaga związana z rozbiciem sieci na podsieci dotyczyła ograniczenia liczby węzłów w jednej domenie kolizyjnej. Oznacza to, że jeśli masz zbyt wiele węzłów, wydajność sieci osiągnie szczyt i ostatecznie spadnie pod dużym obciążeniem z powodu nadmiernych kolizji. Dokładna liczba węzłów, które można wdrożyć, zależała od wielu czynników, ale ogólnie mówiąc, nie można było regularnie ładować domeny kolizyjnej znacznie przekraczającej 50% całkowitej dostępnej przepustowości i nadal utrzymywać stabilność sieci przez cały czas. 50 węzłów w sieci było wtedy dużo węzłów. Przy intensywnym użytkowaniu użytkownicy mogliby zostać uzupełnieni o 20 lub 30 węzłów, zanim zaczną działać podsieci.

Oczywiście przy w pełni przełączonych podsieciach z pełnym dupleksem kolizje nie są już problemem, a przy typowych użytkownikach komputerów stacjonarnych można zazwyczaj wdrożyć setki węzłów w jednej podsieci bez żadnych problemów. Dużo ruchu rozgłoszeniowego, jak wspomniano w innych odpowiedziach, może stanowić problem w zależności od protokołów / aplikacji uruchomionych w sieci. Należy jednak pamiętać, że podsieci sieci niekoniecznie pomagają w rozwiązywaniu problemów związanych z transmisją. Wiele protokołów korzysta z rozgłaszania z jakiegoś powodu - to znaczy, gdy wszystkie węzły w sieci rzeczywiście muszą zobaczyć taki ruch, aby zaimplementować pożądane funkcje na poziomie aplikacji. Po prostu podsieć sieci nic nie kupuje, jeśli rozgłaszany pakiet będzie musiał zostać przesłany do innej podsieci i ponownie rozesłany.

Ogólnie rzecz biorąc, dzisiaj główne powody podsieci sieci mają znacznie więcej wspólnego z kwestiami organizacyjnymi, administracyjnymi i dotyczącymi bezpieczeństwa niż z czymkolwiek innym.

Pierwotne pytanie dotyczy mierzalnych wskaźników, które wyzwalają rozważania dotyczące podsieci. Nie jestem pewien, czy istnieją jakieś konkretne liczby. Będzie to drastycznie zależeć od zaangażowanych „aplikacji” i nie sądzę, aby naprawdę istniały jakieś punkty aktywacyjne, które ogólnie by miały zastosowanie.

W odniesieniu do praktycznych zasad planowania podsieci:

• Zastanów się nad podsieciami dla poszczególnych działów / działów organizacyjnych, zwłaszcza, że ​​stają się one nietrywialne (ponad 50 węzłów !?).
• Rozważ podsieci dla grup węzłów / użytkowników korzystających ze wspólnego zestawu aplikacji, który różni się od innych użytkowników lub typów węzłów (programiści, urządzenia VoIP, hala produkcyjna)
• Rozważ podsieci dla grup użytkowników o różnych wymaganiach bezpieczeństwa (zabezpieczanie działu księgowości, zabezpieczanie Wi-Fi)
• Rozważ podsieci z perspektywy epidemii wirusa, naruszenia bezpieczeństwa i ograniczenia szkód. Ile węzłów zostanie narażonych / naruszonych - jaki jest dopuszczalny poziom narażenia dla Twojej organizacji? Ta uwaga zakłada restrykcyjne reguły routingu (zapory) między podsieciami.

Biorąc to wszystko pod uwagę, dodawanie podsieci powoduje pewien poziom obciążenia administracyjnego i potencjalnie powoduje problemy związane z brakiem adresów węzłów w jednej podsieci i pozostawieniem zbyt wielu adresów w innej puli itp. Ustawienia routingu i zapory ogniowej oraz rozmieszczenie wspólnych serwerów w sieci i tym bardziej się angażują, tego typu rzeczy. Z pewnością każda podsieć powinna mieć powód istnienia, który przewyższa koszty utrzymania bardziej wyrafinowanej logicznej topologii.

Jeśli jest to jedna witryna, nie przejmuj się, chyba że masz więcej niż kilkadziesiąt systemów, a nawet wtedy prawdopodobnie nie jest to konieczne.

Obecnie wszyscy używają przełączników o szybkości co najmniej 100 Mb / s, a częściej 1 Gb / s, jedynym powodem segmentacji sieci związanym z wydajnością jest zbyt duży ruch nadawany (tj.> 2% z góry mojej głowy)

Innym głównym powodem jest bezpieczeństwo, tj. DMZ dla serwerów publicznych, inna podsieć dla finansów lub osobna sieć VLAN / podsieć dla systemów VoIP.

Ograniczenie zakresu wszelkich wymagań zgodności (np. PCI) jest dość dobrym katalizatorem do segmentacji niektórych części sieci. Segmentowanie systemów akceptacji / przetwarzania płatności i finansów może zaoszczędzić pieniądze. Ale ogólnie podsieci małej sieci nie zyskają wiele na wydajności.

Innym powodem byłaby jakość usługi. Prowadzimy osobno vlany głosu i danych, dzięki czemu możemy łatwo zastosować QoS do ruchu VoIP.

Wiesz, myślałem o tym pytaniu więcej. Istnieje mnóstwo dobrych powodów do zaprojektowania nowej sieci przy użyciu odrębnych sieci (wydajność, bezpieczeństwo, QoS, ograniczenie zakresów DHCP, ograniczenie ruchu rozgłoszeniowego (które mogą być związane zarówno z bezpieczeństwem, jak i wydajnością)).

Ale kiedy myślę o metodzie przeprojektowania tylko podsieci i myślach o sieciach, z którymi musiałem sobie poradzić w przeszłości, wszystko, co mogę wymyślić, to „wow, to musiałbym mieć jedną naprawdę pomieszaną sieć, aby całkowicie mnie przeprojektować to do podsieci ". Istnieje wiele innych powodów - przepustowość, wykorzystanie procesora przez zainstalowane urządzenia itp. Ale samo podsieci w czystej sieci danych zwykle nie wymagałoby dużej wydajności

Bezpieczeństwo i jakość głównie (o ile dany segment sieci może oczywiście obsługiwać dane węzły). Oddzielna sieć dla ruchu drukarek, głosu / telefonu, izolowane działy, takie jak IT Ops i oczywiście segmenty serwerów, segmenty internetowe (jeden na usługę dostępną w Internecie jest dziś popularny, nie tylko „jeden dmz zrobi”) i tak dalej.

Jeśli spodziewasz się skalowania (budujesz sieć, a nie tylko 5 serwerów i to nam zrobi), zacznij routing jak najszybciej. Zdecydowanie zbyt wiele sieci jest niestabilnych i trudnych do rozwoju, ponieważ rozwijały się organicznie i mają zbyt dużo elementów warstwy 2.

Przykłady:

• masz dwa serwery nazw w tym samym segmencie sieci. Teraz nie możesz przenieść jednego z nich do innego miasta, ponieważ wtedy będziesz musiał podzielić to ładne / 24 lub zmienić numer DNS. Znacznie łatwiej, gdyby były w różnych sieciach. Nie mówię koniecznie o tym, że staną się oddzielnymi ogłoszeniami BGP dla świata. Ten przykład dotyczyłby ogólnokrajowego dostawcy usług internetowych. Należy również pamiętać, że niektóre rzeczy w obszarze usługodawcy nie są tak łatwe, jak „wystarczy zarejestrować nowy DNS u rejestratora”.
• Pętle warstwy 2 ssą tyłek. Podobnie jak drzewo opinające (i VTP). Kiedy drzewo rozpinające zawiedzie (i jest wiele przypadków, gdy tak się dzieje), wszystko to zabierze ze względu na zalanie procesora przełącznika / routera. Gdy zawiedzie OSPF lub IS-IS (lub inne protokoły routingu), nie spowoduje to awarii całej sieci i możesz naprawić jeden segment na raz. Wadliwa izolacja.

Krótko mówiąc: kiedy przeskalujesz do miejsca, w którym uważasz, że potrzebujesz drzewa opinającego, rozważ zamiast tego routing.

Osobiście lubię segmentację warstwy 3 jak najbliżej przełączników dostępu, ponieważ

• Nie lubię Spanning Tree (możesz sprawić, by robił bardzo śmieszne rzeczy, jeśli jesteś zły)
• Zwłaszcza w sieci Windoze transmisje stanowią prawdziwy problem.
• W sieciach prywatnych masz dużo miejsca na IP do stracenia :)
• Nawet tańsze przełączniki mają teraz możliwości routingu z prędkością drutu - dlaczego ich nie użyć?
• Ułatwia życie, jeśli chodzi o bezpieczeństwo (np. Auth i ACL na egde itp.)
• Lepsze możliwości QoS dla VoIP i rzeczy w czasie rzeczywistym
• Możesz określić lokalizację klienta na podstawie jego adresu IP

Jeśli chodzi o większe / szersze sieci rozproszone, w których dwa przełączniki / routery rdzeniowe nie są wystarczające, normalne mechanizmy redundancji, takie jak VRRP, mają wiele wad (ruch przesyła łącza wielokrotne, ...) OSPF nie ma.

Prawdopodobnie istnieje wiele innych powodów, aby popierać podejście use-small-broadcast-domains .

Myślę, że zakres organizacji ma duże znaczenie. Jeśli w sieci znajduje się łącznie 200 hostów lub mniej, a ruch z jakiegokolwiek powodu nie musi być segmentowany, po co dodawać złożoność sieci VLAN i podsieci? Ale im większy zakres, tym bardziej może to mieć sens.

Podział sieci, które normalnie nie byłyby konieczne, może jednak ułatwić niektóre rzeczy. Na przykład nasze jednostki PDU zasilające serwery znajdują się w tej samej sieci VLAN lub podsieci, co serwery. Oznacza to, że nasz system skanowania w poszukiwaniu luk stosowany w naszym asortymencie serwerów skanuje również jednostki PDU. Nie jest to wielka sprawa, ale nie potrzebujemy skanować PDU. Byłoby również miło, aby DHCP PDU były kłopotliwe w konfiguracji, ale ponieważ są one teraz w tej samej sieci VLAN co serwery, nie jest to bardzo wykonalne.

Chociaż nie potrzebujemy innej sieci VLAN dla PDU, może to ułatwić niektóre rzeczy. I to przechodzi do całego argumentu VLAN „więcej kontra mniej”, który będzie trwał wiecznie.

Ja myślę, że po prostu mam sieci VLAN tam, gdzie ma to sens. Jeśli na przykład daliśmy PDU własną sieć VLAN, nie oznacza to, że zawsze musimy dać małym grupom urządzeń własną sieć VLAN. Ale raczej w tym przypadku może to mieć sens. Jeśli grupa urządzeń nie musi mieć własnej sieci VLAN i nie ma w tym żadnych korzyści, możesz rozważyć pozostawienie rzeczy takimi, jakie są.