Когда / зачем начинать подсеть в сети?

При каких условиях можно начинать рассматривать подсеть в сети?

Я ищу несколько общих эмпирических правил или триггеров, основанных на измеримых метриках, которые делают подсети чем-то, что следует учитывать.

Интересный вопрос.

Исторически, до появления полностью коммутируемых сетей, основное внимание к разделению сети на подсети было связано с ограничением количества узлов в одной области коллизий. То есть, если бы у вас было слишком много узлов, производительность вашей сети достигла бы пика и в конечном итоге рухнула бы под большой нагрузкой из-за чрезмерных коллизий. Точное количество узлов, которые могут быть развернуты, зависит от множества факторов, но, вообще говоря, вы не сможете регулярно загружать домен коллизий, превышающий 50% от общей доступной пропускной способности, и при этом сеть будет стабильной все время. 50 узлов в сети было много узлов в те времена. Если вы интенсивно пользуетесь пользователями, вам, возможно, потребовалось подключиться к 20 или 30 узлам, прежде чем начинать подсеть.

Конечно, с полностью коммутируемыми полнодуплексными подсетями коллизии больше не являются проблемой, и при условии, что обычные пользователи настольного типа, вы обычно можете развернуть сотни узлов в одной подсети без каких-либо проблем. Наличие большого количества широковещательного трафика, как упоминалось в других ответах, может быть проблемой в зависимости от того, какие протоколы / приложения вы используете в сети. Однако следует понимать, что создание подсетей в сети не обязательно поможет вам с проблемами вещательного трафика. Многие из протоколов используют широковещательную рассылку по какой-то причине, то есть когда все узлы в сети действительно должны видеть такой трафик для реализации желаемых функций уровня приложения. Простая подсеть в сети на самом деле ничего не покупает, если широковещательный пакет также нужно будет переадресовать в другую подсеть и снова транслировать.

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

Первоначальный вопрос требует измеримых метрик, которые вызывают соображения подсетей. Я не уверен, что есть какие-то конкретные цифры. Это будет сильно зависеть от вовлеченных «приложений», и я не думаю, что на самом деле есть какие-то триггерные точки, которые обычно применяются.

Относительно правил превью при планировании подсетей:

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

С учетом всего сказанного, добавление подсетей добавляет некоторый уровень административных издержек и потенциально вызывает проблемы, связанные с нехваткой адресов узлов в одной подсети и слишком большим количеством оставшихся в другом пуле и т. Д. Настройка маршрутизации и брандмауэра и размещение общих серверов в сеть и тому подобное становятся более вовлеченными, такие вещи. Конечно, каждая подсеть должна иметь причину существования, которая перевешивает издержки на поддержание более сложной логической топологии.

Если это один сайт, не беспокойтесь, если у вас не более нескольких десятков систем, и даже в этом, вероятно, нет необходимости.

В наши дни, когда каждый использует коммутаторы со скоростью не менее 100 Мбит / с и чаще всего 1 Гбит / с, единственная причина, связанная с производительностью, для сегментирования вашей сети - это если у вас избыточный широковещательный трафик (т. Е.> 2%, не в моей голове)

Основной другой причиной является безопасность, то есть DMZ для общедоступных серверов, другая подсеть для финансов или отдельная VLAN / подсеть для систем VoIP.

Ограничение области для любых требований соответствия, которые вы можете иметь (например, PCI), является довольно хорошим катализатором для сегментирования некоторых частей вашей сети. Сегментирование ваших систем приема / обработки платежей и финансирования может сэкономить деньги. Но в целом подсеть в небольшой сети не сильно повысит производительность.

Еще одна причина связана с качеством обслуживания. Мы запускаем голосовые и информационные сети отдельно, чтобы мы могли легко применять QoS к VoIP-трафику.

Вы знаете, я больше думал об этом вопросе. Существует множество веских причин для проектирования новой сети с использованием различных сетей (производительность, безопасность, QoS, ограничение областей DHCP, ограничение широковещательного трафика (который может быть связан как с безопасностью, так и с производительностью)).

Но когда я думаю о метрике для редизайна только для подсети и о сетях, с которыми мне приходилось сталкиваться в прошлом, все, о чем я могу думать, это «вау, мне нужна одна действительно испорченная сеть, чтобы я полностью изменил дизайн» это для подсетей ". Есть много других причин - пропускная способность, загрузка процессора установленными устройствами и т. Д. Но просто подсеть себя в чистой сети передачи данных обычно не покупает тонну производительности.

Безопасность и качество в основном (при условии, что рассматриваемый сегмент сети может поддерживать рассматриваемые узлы, конечно). Отдельная сеть для трафика принтеров, голосовой связи / телефона, изолированные отделы, такие как ИТ-отделы и, конечно, сегменты серверов, сегменты с выходом в интернет (сегодня популярна одна услуга на выход в интернет, а не просто «один dmz будет делать») и так далее.

Если вы рассчитываете увеличить масштаб (вы строите сеть, а не только 5 серверов, и это будет у нас), начните маршрутизацию как можно скорее. Слишком много сетей нестабильны и их трудно вырастить, потому что они выросли органически и имеют слишком много вещей второго уровня.

Примеры:

• у вас есть два сервера имен в одном сегменте сети. Теперь вы не можете переместить один из них в другой город, потому что тогда вам придется разделить этот хороший / 24 или перенумеровать DNS. Гораздо проще, если бы они были в разных сетях. Я не говорю обязательно о том, что они станут отдельными анонсами BGP для всего мира. Этот пример будет для общенационального интернет-провайдера. Также обратите внимание, что некоторые вещи в области поставщиков услуг не так просты, как «просто зарегистрировать новый DNS у регистратора».
• Слой 2 петли сосут задницу. Как и связующее дерево (и VTP). Когда связующее дерево терпит неудачу (и во многих случаях это происходит), оно сносит все вместе с ним из-за переполнения, принимающего ЦП коммутатора / маршрутизатора. В случае сбоя OSPF или IS-IS (или других протоколов маршрутизации) не произойдет сбой всей сети, и вы сможете исправить один сегмент за раз. Неисправность изоляции.

Итак, вкратце: когда вы масштабируетесь до того места, где, по вашему мнению, вам нужно связующее дерево, рассмотрите возможность маршрутизации.

Лично мне нравится относиться к сегментации уровня 3 как можно ближе к коммутаторам доступа, потому что

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

Если речь идет о сетях с большим / более широким распространением, в которых двух основных коммутаторов / маршрутизаторов недостаточно, то обычные механизмы избыточности, такие как VRRP, имеют много недостатков (трафик проходит по восходящим каналам несколько раз, ...) OSPF не имеет.

Вероятно, есть много других причин для поддержки подхода use-small-broadcast-domains .

Я думаю, что сфера деятельности организации имеет большое значение. Если в сети всего 200 хостов или меньше, и трафик не нужно сегментировать по какой-либо причине, зачем добавлять сложность VLAN и подсетей? Но чем больше сфера, тем больше это может иметь смысл.

Разделение сетей, которые обычно не нужны, может сделать некоторые вещи проще. Например, наши блоки распределения питания, которые обеспечивают питание серверов, находятся в той же VLAN или подсети, что и серверы. Это означает, что наша система сканирования уязвимостей, используемая в нашем диапазоне серверов, также сканирует PDU. Не так уж и много, но нам не нужно сканировать PDU. Также было бы хорошо для DHCP PDU, поскольку их очень сложно настроить, но поскольку они сейчас находятся в той же VLAN, что и серверы, это не очень выполнимо.

Хотя нам не нужна другая VLAN для PDU, это может упростить некоторые вещи. И это входит в аргумент «больше против меньшего количества VLAN», который будет продолжаться вечно.

Я просто думаю, что есть VLAN, где это имеет смысл. Например, если мы предоставили PDU собственную VLAN, это не значит, что мы всегда должны предоставлять небольшим группам устройств собственную VLAN. Но скорее в этом случае это может иметь смысл. Если группе устройств не требуется собственная VLAN, и в этом нет никаких преимуществ, вы можете оставить все как есть.