Сообщения типа этот:
В настоящее время большая часть трафика в корпоративной локальной сети передается от клиента к серверу, и не очень хорошо настроенный маршрутизатор становится узким местом И SPOF. и 200+ клиентов в подсети не было реальной проблемой 10 лет назад и не будет сейчас, вы все равно можете читать все широковещательные сообщения с помощью (не промискового) tcpdump, не размываясь - крошечный по сравнению с пропускной способностью . И работа ARP для клиентов в наши дни тоже не должна быть проблемой. - rackandboneman 21 мая '12 в 19:34
...и этот:
Если у вас всего 50 клиентов, то не имеет значения, была ли подсеть / 8 или / 24. То же количество клиентов, такой же объем трафика. В любом случае разделение вашей сети на подсети на самом деле основано не на количестве компьютеров, а на необходимости разделения систем на основе требований безопасности, изоляции трафика и т. Д.
... вместе, похоже, противоречат совету, который мне дал специалист по сетям, который сказал мне, что моя текущая подсеть 10.0.0.0/8 (примерно с 20 клиентами и 2 серверами, подключенными к одному коммутатору) уязвима для перегрузки в случае клиент может быть скомпрометирован вредоносным ПО, потому что широковещательный трафик будет на порядок выше, чем, скажем, в подсети 192.168.0.0/24. Возможно, это то, о чем имел в виду плакат с приведенной выше цитатой? Или совет устарел?
В связи с этим вопросом возникает множество "в зависимости от обстоятельств".
Безопасность
Широковещательные штормы, наводнения и тому подобное, безусловно, вызывают беспокойство, если вы используете потребительское сетевое оборудование. Однако у большинства корпоративного сетевого оборудования есть способы справиться с этим. В зависимости от вашего поставщика у вас могут быть опции для «Контроль бури». Как и все остальное, эти параметры требуют тестирования и также могут иметь собственное рабочее поведение (как хорошее, так и плохое).
Другой аспект безопасности связан с возможностью разделять системы по ролям и изолировать трафик. Эта концепция также развивается со временем, особенно в отношении SDN, виртуализации и т. Д. Сегментация VLAN сама по себе может быть или не может быть достаточной изоляцией безопасности, в зависимости от потребностей вашей организации. В вашей организации слишком много условий, чтобы ответить на этот вопрос правильно.
Размер сети
A / 8 для 20 хостов немного великоват, но технически ничто не мешает вам это сделать. Меня беспокоит рост сети. В какой-то момент вы можете захотеть подключить эту сеть к другим сетям, центрам обработки данных, офисам и т. Д. Используя весь / 8 в вашем местоположении, вам придется преобразовывать весь свой трафик в другие сети в 10/8. Обычно люди выбирают размер своих сетей так, чтобы они могли выделить подсеть «стандартного размера» для каждого местоположения и использовать сетку WAN или VPN для их соединения, имея правила брандмауэра в каждом месте, которые позволяют определенным службам достигать определенных пунктов назначения в зависимости от ролей, и т.п.
Если вы действительно начинаете заполнять большую локальную сеть, в какой-то момент вам нужно будет увеличить лимиты на ваших серверах и рабочих станциях, чтобы разрешить большие таблицы ARP и минимизировать сбор мусора записей ARP, чтобы избежать чрезмерных обновлений ARP. То же самое верно для всех коммутаторов доступа и распределения в вашей сети. Каждая ОС сервера / рабочей станции и каждый поставщик сети будут вести себя по-разному, когда вы начнете заполнять очень большой широковещательный домен.
Мой собственный опыт работы с большими VLAN
Самой крупной полностью населенной сетью, в которой я работал, была a / 22. Единственными проблемами, с которыми мы столкнулись, были службы, которые зависели от быстрого ответа от многоадресного трафика. Даже увеличения ограничений ARP на серверах было недостаточно для решения этой проблемы. Нам пришлось изменить размер наших сетей на более мелкие VLAN и изменить конфигурацию наших приложений, чтобы они меньше зависели от многоадресной рассылки.
Прошло некоторое время с тех пор, как я работал в сфере сетевого администрирования, но вот что я думаю по этому поводу:
200+ клиентов в подсети не было проблемой 10 лет назад и не будет, вы все еще можете читать все трансляции
Это более или менее верно. Еще до переключения технологии подсети для учета общего объема широковещательного трафика было серьезной проблемой. Однако в наши дни коммутаторы намного более эффективны с точки зрения общей архитектуры по сравнению с концентраторами (т. Е. Они не перенаправляют КАЖДЫЙ пакет в КАЖДЫЙ порт), и они лучше справляются с имеющимся у них широковещательным трафиком.
я слышал WAG По оценкам, 500 клиентов на подсеть - это пример того, с чего вам следует начать рассматривать разделение на подсети, основываясь исключительно на проблемах трафика и широковещательного домена, но я не удивлюсь, если коммутационное оборудование корпоративного уровня сможет справиться с гораздо большим. Очевидно, тестируйте и тестируйте снова, поскольку рабочая нагрузка у всех разная.
вы по-прежнему можете читать все трансляции с помощью tcpdump (не промискового), не превращая его в размытость
Если ваша IDS / IPS требует, чтобы вы считывали широковещательный трафик вручную, вам, вероятно, следует взглянуть на другой продукт IDS / IPS. На самом деле я не считаю это серьезным беспокойством при принятии решения о том, каким должен быть размер вашей подсети.
Если у вас всего 50 клиентов, то не будет иметь значения, будет ли подсеть / 8 или / 24. То же количество клиентов, такой же объем трафика.
Мне кажется логичным. Если не брать в расчет сетевое пространство, у вас ограниченное количество клиентов, и они могут производить только определенный объем трафика.
Моя текущая подсеть 10.0.0.0/8 (примерно с 20 клиентами и 2 серверами, подключенными к одному коммутатору) была уязвима для перегрузки, если клиент был скомпрометирован вредоносным ПО, потому что широковещательный трафик был бы на порядки выше, чем, скажем, на 192.168.0.0/24 подсеть
Вот это да. Я бы подобрал размер вашей подсети прямо сейчас!
Я собираюсь скопировать / вставить это из своего другого ответа, но здесь он очень актуален: вы не управляете сотнями хостов. Сложность вашего решения должна отражать сложность окружающей среды. Не поддавайтесь искушению быть слишком умным. Вы поблагодарите себя позже.
Во-вторых, я не уверен, как было бы больше vulnerable to overloading Что касается широковещательного трафика, так как вещать нужно всего 20 клиентам. Когда вы думаете о широковещательной атаке или широковещательных разветвлениях, ограничивающим фактором, как правило, является не широковещательный домен, а узлы, генерирующие трафик, поэтому, если ваши 20 узлов пытаются транслировать на 252 IP-адреса или 16 777 212 IP-адресов (16 777 192 из которых не заняты ) выходит столько же передач. Теперь, если вредоносная программа выполняет какую-то усиленную атаку, когда начинает создавать IP-адреса, да, вы дали злоумышленнику гораздо больше возможностей для игры. Может, это то, к чему ваш охранник имел в виду. Информационная безопасность - это сложно, и у меня есть только поверхностные знания в этой области, поэтому, если вы хотите изучить этот вопрос более подробно, возможно, Безопасность.SE было бы более уместно.