При каких условиях следует рассматривать разбиение сети на подсети?
Я ищу несколько общих практических правил или триггеров, основанных на измеримых показателях, которые делают разбиение на подсети чем-то, что следует учитывать.
Интересный вопрос.
Исторически до появления полностью коммутируемых сетей основное внимание при разбиении сети на подсети было связано с ограничением количества узлов в одном домене коллизий. То есть, если у вас будет слишком много узлов, производительность вашей сети достигнет пика и в конечном итоге упадет под большой нагрузкой из-за чрезмерных коллизий. Точное количество узлов, которые можно было бы развернуть, зависело от множества факторов, но, вообще говоря, вы не могли регулярно загружать домен конфликтов, намного превышающий 50% от общей доступной полосы пропускания, и при этом сеть все время была стабильной. В те дни 50 узлов в сети были большим количеством узлов. С интенсивно используемыми пользователями вам, возможно, пришлось бы увеличить количество узлов до 20 или 30, прежде чем возникнет необходимость в разбиении на подсети.
Конечно, с полностью коммутируемыми полнодуплексными подсетями конфликты больше не являются проблемой, и, предполагая типичных пользователей настольного типа, вы обычно можете развернуть сотни узлов в одной подсети вообще без каких-либо проблем. Наличие большого количества широковещательного трафика, как упоминалось в других ответах, может вызывать беспокойство в зависимости от того, какие протоколы / приложения вы используете в сети. Однако следует понимать, что разделение сети на подсети не обязательно поможет вам решить проблемы с широковещательным трафиком. Многие протоколы используют широковещательную рассылку по какой-то причине - то есть, когда все узлы в сети действительно нуждаются в таком трафике для реализации желаемых функций уровня приложения. Простое разделение сети на подсети на самом деле ничего вам не даст, если транслируемый пакет также необходимо будет пересылать в другую подсеть и транслировать снова. Фактически, это фактически добавляет дополнительный трафик (и задержку) в обе подсети, если вы хорошо обдумаете это.
Вообще говоря, сегодня основные причины разделения сетей на подсети гораздо больше связаны с организационными, административными соображениями и соображениями безопасности, чем с чем-либо еще.
Исходный вопрос требует измеримых показателей, которые вызывают рассмотрение подсетей. Я не уверен, что есть какие-то конкретные цифры. Это будет сильно зависеть от задействованных «приложений», и я не думаю, что есть какие-то триггерные точки, которые обычно применимы.
Относительно правил планирования подсетей:
С учетом всего сказанного, добавление подсетей добавляет некоторый уровень административных накладных расходов и потенциально вызывает проблемы, связанные с исчерпанием адресов узлов в одной подсети и слишком большим количеством оставшихся в другом пуле и т. Д. Настройка маршрутизации и брандмауэра, а также размещение общих серверов в сети и так далее, вовлекаются в подобные вещи. Разумеется, каждая подсеть должен есть причина для существования, которая перевешивает накладные расходы на поддержку более сложной логической топологии.
Ограничение объема любых требований соответствия, которые могут у вас возникнуть (например, PCI), является довольно хорошим катализатором для сегментации некоторых частей вашей сети. Сегментирование систем приема / обработки платежей и финансирования может сэкономить деньги. Но, как правило, разбиение небольшой сети на подсети не принесет вам большого выигрыша в производительности.
Если это один сайт, не беспокойтесь, если у вас не более нескольких десятков систем, и даже тогда это, вероятно, не нужно.
В наши дни, когда все используют коммутаторы со скоростью не менее 100 Мбит / с и чаще 1 Гбит / с, единственная причина, связанная с производительностью для сегментации вашей сети, - это если вы страдаете от избыточного широковещательного трафика (то есть> 2%, не в моей голове)
Другая основная причина - безопасность, т.е. DMZ для общедоступных серверов, другая подсеть для финансов или отдельная VLAN / подсеть для систем VoIP.
Другая причина может быть связана с качеством обслуживания. Мы запускаем виртуальные локальные сети для голоса и данных отдельно, чтобы мы могли легко применять QoS к трафику VoIP.
Вы знаете, я больше думал об этом вопросе. Существует множество веских причин для разработки новой сети с использованием отдельных сетей (производительность, безопасность, QoS, ограничение области DHCP, ограничение широковещательного трафика (что может быть связано как с безопасностью, так и с производительностью)).
Но когда я думаю о метрике для редизайна только для подсети, и думая о сетях, с которыми мне приходилось работать в прошлом, все, о чем я могу думать, это «вау, это должна была бы одна действительно испорченная сеть, чтобы заставить меня полностью перепроектировать» это для подсети". Есть много других причин - пропускная способность, загрузка ЦП установленных устройств и т. Д. Но просто разбиение на подсети в чистой сети передачи данных обычно не дает большой производительности.
В основном безопасность и качество (если, конечно, рассматриваемый сегмент сети может поддерживать рассматриваемые узлы). Отдельная сеть для трафика принтеров, голоса / телефона, изолированные отделы, такие как ИТ-службы, и, конечно же, серверные сегменты, сегменты с выходом в Интернет (сегодня популярна одна служба с выходом в Интернет, а не просто «подойдет один DMZ») и т.
Если вы ожидаете масштабирования (вы строите сеть, а не только 5 серверов, и мы это сделаем), начните маршрутизацию как можно скорее. Слишком много сетей нестабильны и их трудно развивать, потому что они выросли органически и содержат слишком много вещей уровня 2.
Примеры:
Вкратце: когда вы увеличиваете масштаб до того места, где, по вашему мнению, вам нужно связующее дерево, лучше подумайте о маршрутизации.
Лично мне нравится делать сегментацию уровня 3 как можно ближе к коммутаторам доступа, потому что
Если дело доходит до более крупных сетей, где двух основных коммутаторов / маршрутизаторов недостаточно, обычные механизмы резервирования, такие как VRRP, имеют множество недостатков (трафик проходит через восходящие каналы несколько раз, ...) OSPF не имеет.
Вероятно, есть много других причин для поддержки использовать малые широковещательные домены-подходить.
Я думаю, что масштаб организации имеет большое значение. Если в сети всего 200 хостов или меньше и трафик не нужно сегментировать по какой-либо причине, зачем увеличивать сложность виртуальных локальных сетей и подсетей? Но чем больше масштаб, тем больше в этом смысла.
Однако разделение сетей, которые обычно не нужны, может упростить некоторые вещи. Например, наши PDU, которые обеспечивают питание серверов, находятся в той же VLAN или подсети, что и серверы. Это означает, что наша система сканирования уязвимостей, используемая на наших серверах, также сканирует PDU. Ничего страшного, но нам не нужно сканировать PDU. Также было бы неплохо использовать DHCP для PDU, поскольку их сложно настроить, но поскольку они сейчас находятся в той же VLAN, что и серверы, это не очень возможно.
Хотя нам не нужна другая VLAN для PDU, это может упростить некоторые вещи. И это приводит к спору о большем и меньшем количестве виртуальных локальных сетей, который будет продолжаться вечно.
Я просто думаю, что есть VLAN там, где это имеет смысл. Если, например, мы предоставили PDU их собственную VLAN, это не значит, что мы всегда должны предоставлять небольшим группам устройств их собственную VLAN. Но в данном случае это могло иметь смысл. Если группе устройств не требуется собственная VLAN и в этом нет никаких преимуществ, то вы можете просто оставить все как есть.