Мы начали небольшую дискуссию в офисе, и я подошел к моменту, когда у меня больше нет технических знаний, чтобы продолжить.
Есть ли слишком много IP-адресов? Я не предлагаю использовать все частные 10. * Класс A, но я не понимаю, почему мы не могли бы этого сделать, если бы захотели.
Я честно считаю, что «фрагментация подсети» - устаревший способ мышления, но я хочу продолжить техническое обсуждение.
В настоящее время наша основная маска подсети настроена на использование 4 классов B, что является излишним с точки зрения огромного количества доступных IP-адресов для нашего малого бизнеса.
Но вопрос в том, какие проблемы (если таковые имеются) создает широкое пространство частных IP-адресов?
Единственная проблема - возможные конфликты при подключении к партнерским сетям или при слияниях / поглощениях. Некоторые из этих проблем можно устранить, используя NAT источника и назначения на пограничных устройствах. Кроме того, то, что вы используете 10.1.0.0/24, не означает, что вы не столкнетесь с теми же проблемами.
Соблюдение различных стандартов станет невозможным, защита сетей станет сложнее, вирус будет распространяться легче, качество обслуживания ухудшится, таблицы MAC / CAM заполнятся.
Сложить все в одно ведро до сих пор есть масса проблем.
Также не забывайте, что по мере увеличения скорости в локальных сетях увеличивается и количество пользователей. Особенно если речь идет о дата-центре. Многие предприятия работают с загрузкой стволов на 50 +%. Я видел некоторые, которые постоянно работают выше 65% на соединительных линиях 10 гигабайт. Скажите этим людям добавить ненужный трафик.
Использование больших подсетей без каких-либо причин, кроме «вы можете», нормально, когда вы находитесь в крошечном месте, которому действительно не нужно более двух VLAN. Как только вы покинете мир малого бизнеса, вы обнаружите, что вещи немного усложняются.
Другой очевидной причиной было бы остановить заполнение ваших таблиц CAM, что может быть причиной сбоя в зависимости от реализации в прошивке того, как все обрабатывается с заполнением таблицы переключателей.
Не совсем - до тех пор, пока вы ограничиваете количество реальных устройств тем, что сеть будет обрабатывать ... но опять же, зачем иметь такое огромное количество возможных узлов в этой сети, если вы не будете использовать их все?
Сегментирование сетей полезно для многих вещей, включая обеспечение логической структуры и обзора, усиление безопасности путем разделения ролей и / или местоположений на разные сети и т.д.
Одна вещь, о которой люди обычно не думают, - это разделение принтеров и других очень уязвимых и незащищенных сетевых устройств в их собственную сеть - с доступом только к определенному серверу печати. А еще есть все обычные, зависящие от требований информационной безопасности вашей организации.
Безопасность имеет уровни, сегментация сети - одна из многих, которые помогают сделать вещи менее уязвимыми для проблем безопасности (= доступ, целостность и доступность).
Проблема, которую я вижу в том, что многие IP-адреса не ограничивают широковещательный домен. С другой стороны, с коммутаторами 1 ГБ я не могу сказать, что это имеет большое значение, если только вы не пытаетесь копаться в журналах коммутаторов и брандмауэра.
Кроме потенциальных конфликтов с партнерскими сетями, подключенными через VPN, никаких проблем.
Я обычно рекомендую в любом случае использовать / 24 куска, независимо от диапазона, из которого вы их разделяете. Итак, допустим, вы назначаете 10.27.1 / 24 офису, 10.27.2 / 24 - подсети БД в центре обработки данных, 10.27.3 / 24 - подсети приложений в центре обработки данных, 10.27.100 / 24 для VPN. клиенты и так далее.
В зависимости от размера вашей подсети широковещательные рассылки могут быть проблемой, хотя в зависимости от скорости вашей сети они могут не возникать.
Однако одним из недостатков является то, что вы ограничиваете свои возможности расширения в будущем. Сейчас вам может понадобиться только одна подсеть, но кто сказал, что вам не понадобится больше в будущем? Вы можете расширить, вы можете захотеть настроить отдельные подсети для некоторых частей вашей сети и так далее.
Я бы также отказался от "классного" мышления и использовал CIDR для ваших подсетей. Классы больше не существуют вне университетских курсов и учебников по истории, а CIDR просто дает вам гораздо больше гибкости.
Хорошее практическое правило в отношении этих вещей - взять то, что, по вашему мнению, вам нужно, и удвоить его, поэтому, если у вас есть 50 хостов (и не забудьте включить сюда серверы, принтеры, коммутаторы и т. Д.), 25-битную сетевую маску (дающую вам 128 хостов (минус 2 для сети и широковещательной передачи) покрывают все, что вам нужно, и дают вам некоторый запас.
Что ж, коммутатор, подключенный к вашему серверу Uber-IP, имеет ограниченное количество записей, доступных в таблице ARP. Также вы увидите много бесплатного ARP на своем Broadcast Domin.
Ничего такого, о чем я могу думать, кроме того, что его немного сложнее настроить (и, возможно, администрировать). Кроме того, существует проблема уменьшения количества IP-адресов (до IPV6).
Одна сеть, которую я унаследовал, была заполнена / 16 ... т.е. 10.1.x.x, 10.2.x.x ..
Было приятно сгруппировать диапазоны IP-адресов, и вы могли посмотреть IP-адрес и точно знать, что это было ... О, 10.4.20.X - это все базы данных и т.д ... НО ...
В конце концов нам пришлось его очистить, и найти все случайные IP-адреса было рутиной.
Намного проще выполнить сканирование nmap ping с / 24, чем с / 16.
В редизайне остановились на / 22с. (1024 дюймов в секунду)
Я думаю, что общее правило выделения для того, что вам нужно сегодня, со здоровыми накладными расходами для роста, является хорошей практикой.
Я бы начал с максимального количества устройств, которые когда-либо были бы в сети, удвоил или утроил его, а затем посмотрел, достаточно ли у меня сетей. Используя сеть TEN, нетрудно найти баланс. Например, допустим, что 100 устройств - это макс. Если вы выберете / 22 в качестве маски, у вас будет 16 384 сети, в которых может быть 1022 устройства:
Mask:255.255.252.0 Host/Net - 1022
Network Broadcast
10.0.0.0 10.0.3.255
10.0.4.0 10.0.7.255
10.0.8.0 10.0.11.255
10.0.12.0 10.0.15.255
10.0.16.0 10.0.19.255
10.0.20.0 10.0.23.255
10.0.24.0 10.0.27.255
10.0.28.0 10.0.31.255
10.0.32.0 10.0.35.255
10.0.36.0 10.0.39.255
10.0.40.0 10.0.43.255