Коли / навіщо починати підмережу мережі?

За яких умов починає розглядатися підмережа в мережі?

Я шукаю декілька загальних правил, чи тригерів, заснованих на вимірюваних показниках, які роблять підмережу щось, що слід враховувати.

Цікаве запитання.

Історично до появи повністю комутованих мереж основна увага до розриву мережі на підмережі була пов'язана з обмеженням кількості вузлів в одному домі зіткнення. Тобто, якщо у вас було занадто багато вузлів, продуктивність вашої мережі досягла б свого піку і врешті-решт зазнала краху під великим навантаженням через надмірне зіткнення. Точна кількість вузлів, які можна було б розгорнути, залежала від безлічі факторів, але, загалом кажучи, ви не могли регулярно завантажувати домен зіткнення набагато більше 50% від загальної доступної пропускної здатності і все ще підтримуєте мережу стабільною весь час. 50 вузлів у мережі було багато вузлів у ті часи. Користувачі, які користуються інтенсивним користуванням, можливо, ви досягли 20 або 30 вузлів, перш ніж почати працювати з підмережами.

Звичайно, із повністю переключеними повнодуплексними підмережами зіткнення вже не викликають особливих проблем, і якщо припустити типових користувачів настільних типів, типово ти можеш розгорнути сотні вузлів в одній підмережі без будь-яких проблем. Наявність великого обсягу трансляційного трафіку, на який згадували інші відповіді, може викликати занепокоєння залежно від того, які протоколи / програми ви працюєте в мережі. Однак розумійте, що підмережа в мережі не обов'язково допомагає вам з проблемою вашого трансляційного трафіку. Багато протоколів використовують мовлення з причини - тобто коли всі вузли мережі насправді потребують бачити такий трафік, щоб реалізувати бажану функцію (рівня) додатків. Просто підмережа в мережі насправді нічого не купує, якщо трансляційний пакет також буде потрібно переадресовувати в іншу підмережу і транслюватись знову.

Взагалі кажучи, сьогодні основні причини мереж підмереж мають набагато більше стосунків щодо організаційних, адміністративних та межових питань безпеки, ніж будь-що інше.

Оригінальне запитання задає вимірювані показники, які викликають міркування підмереж. Я не впевнений, що є якісь конкретні цифри. Це значно залежатиме від залучених "додатків", і я не думаю, що насправді існують тригерні точки, які, як правило, застосовуються.

Відносно правил великого пальця при плануванні підмереж:

• Розгляньте підмережі для кожного різних організаційних відділів / підрозділів, тим більше, що вони мають нетривіальний розмір (50+ вузлів !?) за розміром.
• Розглянемо підмережі для груп вузлів / користувачів, що використовують загальний набір додатків, який відрізняється від інших користувачів або типів вузлів (розробники, пристрої VoIP, виробничий поверх)
• Розглянемо підмережі для груп користувачів, які мають різні вимоги до безпеки (забезпечення бухгалтерії, захист Wi-Fi)
• Розгляньте підмережі з точки зору спалаху вірусу, порушення безпеки та обмеження шкоди. Скільки вузлів піддаються / порушуються - що є прийнятним рівнем впливу для вашої організації? Цей розгляд передбачає правила обмеження маршрутизації (брандмауера) між підмережами.

З урахуванням сказаного, додавання підмереж додає певного рівня адміністративних накладних витрат і, можливо, спричиняє проблеми, пов'язані з тим, що вичерпано адреси вузлів в одній підмережі і занадто багато залишилося в іншому пулі тощо. Налаштування маршрутизації та брандмауера та розміщення загальних серверів у мережа і таке більше втягуються в таку річ. Безумовно, кожна підмережа повинна мати причину для існуючої, яка переважає надмірні витрати на підтримку більш складної логічної топології.

Якщо це один сайт, не бідайте, якщо у вас більше кількох десятків систем, і навіть тоді це, мабуть, непотрібне.

Ці дні, коли всі користуються щонайменше 100 Мбіт / с комутаторами і частіше 1 Гбіт / с, єдина причина, що стосується продуктивності, щоб сегментувати вашу мережу - це якщо ви страждаєте надлишковим трафіком (тобто> 2%, у верхній частині моєї голови)

Основна інша причина - безпека, тобто DMZ для серверів, що стоять перед громадськістю, інша підмережа для фінансів або окрема VLAN / підмережа для VoIP-систем.

Обмеження обсягу будь-яких вимог щодо відповідності (наприклад, PCI) є досить хорошим каталізатором для сегментації деяких ділянок вашої мережі. Сегментування системи прийому / обробки та фінансування платежів дозволяє заощадити гроші. Але в цілому підмережа невеликої мережі не набере багато ваших результатів.

Ще одна причина - якість обслуговування. Ми запускаємо голос і дані vlans окремо, щоб ми могли легко застосувати QoS до VoIP-трафіку.

Знаєте, я більше думав над цим питанням. Є безліч вагомих причин створити нову мережу, використовуючи різні мережі (продуктивність, безпека, QoS, обмеження областей DHCP, обмеження трансляційного трафіку (що може бути як безпекою, так і продуктивністю)).

Але коли я думав про метрику для перепроектування просто для підмережі, а також думав про мережі, з якими я мав оброблятись в минулому, все, що я можу придумати, це "ого, це довелося б одній дійсно заплутаній мережі, щоб зробити мене повністю переробленим це для підмережі ". Є багато інших причин - пропускна здатність, використання процесора встановлених пристроїв і т. Д. Але просто підмережа в чистій мережі передачі даних зазвичай не купує тонну продуктивності

Безпека та якість здебільшого (доки відповідний мережевий сегмент може, звичайно, підтримувати розглянуті вузли). Окрема мережа для трафіку принтера, голосу / телефону, відокремлених відділів, таких як IT Ops, і, звичайно, сегментів сервера, сегментів, орієнтованих на Інтернет (сьогодні популярний один на Інтернет-сервіс, а не лише "один dmz") тощо.

Якщо ви розраховуєте на збільшення масштабів (ви будуєте мережу, а не лише 5 серверів, і це ми будемо), почніть маршрутизацію якнайшвидше. Занадто багато мереж нестабільно і важко розвивати, оскільки вони органічно зростали та мають занадто багато матеріалів із шару 2.

Приклади:

• у вас є два сервери імен на одному мережевому сегменті. Тепер ви не можете перенести одну з них в інше місто, оскільки тоді вам доведеться розділити цю приємну / 24 або перенумерувати DNS. Набагато простіше, якби вони були в різних мережах. Я не обов'язково говорю про те, щоб вони стали окремими оголошеннями BGP для світу. Цей приклад може бути для загальнодержавного провайдера. Також зауважте, що деякі речі в області постачальника послуг не такі прості, як "просто зареєструйте новий DNS у реєстратора".
• Шаром 2 петлі смокчуть попку. Так само, як і охоплює дерево (і VTP). Коли розбивається дерево не виходить (і є багато випадків, коли це трапляється), воно зніме все з нього через повені, приймаючи процесор комутатора / маршрутизатора. Якщо OSPF або IS-IS виходять з ладу (або інші протоколи маршрутизації), він не вийде з ладу всієї мережі, і ви можете виправити один сегмент за один раз. Ізоляція несправностей.

Отже, коротко: коли ви визначаєте масштаб до того місця, де, на вашу думку, вам потрібне дерево, що охоплює, будь ласка, розгляньте маршрутизацію.

Особисто мені подобається брати сегментацію шару 3 якомога ближче до комутаторів доступу, тому що

• Мені не подобається Spanning Tree (ви можете змусити це робити дуже смішні речі, якщо ви злі)
• Особливо в мережах Windoze, трансляції - справжня проблема.
• У приватних мережах у вас дуже багато місця для IP-адреси :)
• Навіть дешевші комутатори на сьогоднішній день мають можливості швидкісного маршрутизації - чому б не використати їх?
• Полегшує життя, коли мова йде про безпеку (наприклад, Auth та ACL на egde тощо)
• Кращі можливості QoS для VoIP та реального часу
• Ви можете вказати місцезнаходження клієнта з його IP-адреси

Якщо мова йде про більш широкі / більш широкомасштабні мережі, де двох основних комутаторів / -рутерів недостатньо, нормальні механізми надмірності, такі як VRRP, мають багато недоліків (трафік проходить вгору кілька разів, ...) OSPF не має.

Напевно, існує маса інших причин, які підтримують використання невеликих доменів мовлення- підходу.

Я думаю, що сфера організації має велике значення. Якщо в мережі всього 200 хостів або менше, і трафік не потрібно сегментувати з будь-якої причини, навіщо додавати складність VLAN та підмереж? Але чим більший обсяг, тим більше це може мати сенс.

Розщеплення мереж, які зазвичай не потребують, може полегшити деякі речі. Наприклад, наші PDU, які постачають живлення серверам, перебувають у тій самій VLAN або підмережі, що і сервери. Це означає, що наша система сканування вразливості, що використовується на нашому сервері, також сканує PDU. Не велика справа, але нам не потрібні сканування PDU. Крім того, було б непогано DHCP PDU, оскільки вони важко налаштовувати, але оскільки вони перебувають у тій самій VLAN, що і сервери зараз, це не дуже можливо.

У той час як нам не потрібна інша VLAN для PDU, це може полегшити деякі речі. І це потрапляє в цілий аргумент більше проти менше VLAN, який триватиме назавжди.

Мені, я просто думаю, що є VLAN, де це має сенс. Якщо, наприклад, ми дали PDU-диски власним VLAN, це не означає, що ми завжди повинні давати невеликим групам пристроїв власну VLAN. Але скоріше в цьому випадку це може мати сенс. Якщо для групи пристроїв не потрібно мати власну VLAN, і немає ніяких переваг для цього, можливо, ви захочете розглянути можливість залишити речі такими, якими вони є.