Должен ли я разделить свою сеть передачи данных на 2 отдельные VLAN?


9

В настоящее время я использую 10.54.0.0 / 19 для всех моих настольных клиентов и принтеров. У нас есть около 550 клиентов / принтеров.

Помимо пропускной способности, которая почти не используется, есть ли какая-либо другая причина разделить мою сеть передачи данных или перейти в меньшую подсеть, чем / 19, который я сейчас использую?


4
... почему / 19? / 16 или / 24 было бы гораздо проще, без каких-либо дополнительных затрат.
Массимо

/ 24 не разместили бы 550 клиентов и принтеров.
Алекс Берри

@ Алекс Берри - /24не может получить доступ к 550 устройствам, это правда; но иметь несколько /24сетей можно (одна для принтеров, одна для бухгалтерии, одна для HR и т. д.)
Уоррен

@ Warren, это правда, однако я подумал, что это будет подразумеваться в его вопросе с использованием различных VLAN.
Алекс Берри

Кроме того, почему /19вместо /21?
Уоррен

Ответы:


11

Наличие настольных клиентов в / 19 дает вам невероятно большой широковещательный домен. Это означает, что запросы DHCP, arp, mDNS, netbios, обнаружение принтера IPP и т. Д. Пакеты с одного хоста получают репликацию 550x. Как правило, / 24 - это самая большая подсеть, в которую вы хотите поместить фактические хосты. Поскольку вы находитесь в пространстве RFC1918 , вы можете использовать разные /24(или любые другие) для каждого логического деления, которое вы можете найти.

Реальный вопрос, который вы должны задать, заключается в том, должны ли вы использовать меньшие подсети. Ответ на который "вероятно". Если вы решите реализовать это с VLAN или нет, это действительно ортогонально.


5
Почему / 24 является самой большой подсетью, в которую вы хотите поместить фактические хосты? Существует ли метрика, которая может быть объективно оценена для обоснования этого вывода, например, если (Broadcast Packets / All other пакетов)> .25, то вам следует подсеть?
Крис Магнусон

1
Вы, конечно, можете придумать метрики, например, какой процент вашей полосы пропускания вы хотите позволить использовать для средней широковещательной нагрузки? Чем больше подсеть, тем больше хостов может быть затронуто одним ненадлежащим образом хостов. Представьте, что компания с целым рядом 500 поставлена ​​на колени, потому что все ее хосты находятся в / 8, и один из них выполняет широковещательный поток ... Кроме того, у вас есть Учтите, что не все сети представляют собой группу компьютеров, подключенных к дешевому коммутатору GIGE. Для бизнеса довольно распространено иметь несколько офисов, соединенных соединениями MOE или WAN. 1 Мбит / с не может быть много на
локальной сети,

Для меня / 24 имеют больше смысла для беспроводной связи. Вы можете стать намного больше в коммутируемых сетях без особых проблем. Определенно имеет смысл, чтобы отдельные концы каналов MOE / WAN находились в разных подсетях.
Джоэл Коэль

Я согласен с тем, что 550 хостов не являются абсолютно необоснованными в одной подсети, но в большинстве сценариев стоит значение / 19 (8K IP). Он специально отметил, что у него есть рабочие столы в его единственной подсети.
Джошуа Хоблитт

4

Поскольку ваша сеть используется недостаточно и у вас есть только несколько хостов, единственной причиной, по которой разделить / 19 на более мелкие префиксы, будет безопасность. Это означает, что вы будете использовать VLAN и маршрутизатор для разрешения / фильтрации связи между VLAN.

Оцените, сколько времени потребуется для изменения IP-адресов и приложений, использующих эти IP-адреса, и посмотрите, стоит ли переходить на другие префиксы. С меньшими ресурсами вы можете найти и устранить ненужные генераторы широковещательной рассылки, если они влияют на ваш сетевой трафик.

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

Если вы разбили свою сеть на более мелкие префиксы, но не используете VLAN, вы не уменьшите широковещательный трафик и не сделаете свою сеть более безопасной. Даже если вы разделите свою сеть на VLAN, но будете транспортировать VLAN на всех коммутаторах (например, вы не используете сокращение VLAN), широковещательный трафик повлияет на все коммутаторы.

Некоторые устройства, такие как коммутаторы Cisco , также могут ограничивать вещание (по скорости или по типу).

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


+1 за информацию о том, что происходит, когда таблица MAC или таблица ARP заполняется
dunxd

3

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

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


Любая рекомендация о том, какое количество хостов не может быть рассмотрено, и, возможно, какая-то метрика, которая может быть оценена, которая указала бы, когда вам следует подсеть специально для изоляции широковещательных доменов?
Крис Магнусон

@obligatory - это сложный вопрос, чтобы ответить. Каждая среда немного отличается. Я могу сказать, что 550 хостов не так уж и опасны в большинстве сред. Если есть избыточные трансляции из-за какого-то LOB-приложения, это может полностью изменить ситуацию. В основном все зависит.
Джейсон Берг
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.