Рекомендации по планированию адресного пространства IPv4

Недавний вопрос от Крейга Константина касался IPv6, но многие люди еще не находятся на переднем крае с IPv6 и все еще отвечают за новые или улучшенные развертывания IPv4.

Я хотел бы проверить свое собственное корпоративное планирование адресного пространства IPv4 по любым общедоступным документам или руководствам, приведенным здесь. У адресации есть некоторые уникальные потребности между ДК и Кампусом, которые в идеале должны быть рассмотрены.

Я специально хочу посмотреть, какие существуют лучшие практики для планирования частных (RFC1918) назначений IP-пространства для регионов, городов, кампусов, зданий, этажей, каналов связи, глобальных сетей, шлейфов и т. Д. Проводная и беспроводная связь. Внутренние сети против гостевых сетей. * Я знаю, что это само по себе может быть чем-то вроде открытого вопроса, поэтому я ищу конкретные ссылки или примеры для проверенных и хорошо продуманных планов аналогично ответам на IPv6. Предлагаемые блоки CIDR будут полезны, так как пространство будет выделено.

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

Находясь в небольшой компании, мы несколько либерально сломали нашу частную сеть:

/ 24 на Vlan / 16 на место

Вланы разложены, пропуская 10 / 24сек. Номер Vlan соответствует третьему октету. Местоположения последовательные, начиная с 10/16 с.

т.е.

• 10.10.1.0/24 - Местоположение A, Управление Vlan 1

• 10.10.11.0/24 - Местоположение A, Wireless Vlan 11

• 10.11.11.0/24 - Местоположение B, Wireless Vlan 11

• 10.11.81.0/24 - Местоположение B, SAN Vlan 81

• 10.11.101.0/24 - Местоположение B, Проводной офис Vlan 101

Примеры Vlan:

• 1 - управление

• 2 - управление по беспроводной связи

• 11 - беспроводной доступ

• 21 - гости

• 31 - мобильные устройства

• 41 - заводское оборудование

• 51 - САН

• 61 - VoIP

• 71 - Проводной доступ

И так далее.

Преимущества, которые мы видели с этим:

• Легко ссылаться на все местоположение через / 16. Мы используем это довольно часто для ACL VPN.

• Легко группировать типы устройств вместе для веб-фильтрации.

• Любой Vlan в течение следующих 10/24 принадлежит к тому же типу, что и предыдущий корень.

  • Так, например, заводское оборудование ... Vlan 31, для некоторых поставщиков, которые имеют удаленный доступ 24/7, мы предоставили им свои собственные Vlan, 32 или 33 или 34, до 40. Их VPN-доступ ограничивает их оборудованием, которое они поддержка без получения детализации по IP / ACE. Если производственной команде нужно добавить больше оборудования, нам не нужно обновлять списки ACL VPN. Это также включает ACL / ACE доступа между Vlans.

  • Другой пример: SAN Vlans, мы используем как минимум два из них для резервирования. Так что им всегда 81 и 82.

  • Последний пример: управление беспроводными сетями осуществляется на собственном Vlan, 2. Мы делаем это потому, что у нас достаточно точек доступа, для которых требуется контроллер WLAN, но нет бюджета на контроллеры. Этот Vlan использует параметры tftp и dhcp для автоматической настройки и загрузки AP из репозитория с центральной конфигурацией, и мы не хотим, чтобы другое оборудование, которое может автоматически загружаться, получало настройки беспроводной сети.

Эта настройка дает нам простой способ посмотреть на IP и узнать местоположение и тип оборудования, к которому он принадлежит. Это означает, что для нас меньше ACL / ACE в файлах конфигурации, особенно для пользователей с ограниченными VPN. У нас также есть простор для расширения в случае, если у нас закончились IP-адреса в Vlan или потому, что нам нужно дополнительно разделять трафик. А поскольку мы небольшая компания, мы еще не разбили трехзначную нумерацию. Много места для роста.

Учитывая, что IPv4 существует так долго, существуют миллионы различных способов распределения своего пространства IPv4.

Для нас (интернет-провайдера) мы используем наименьший размер подсети, возможный на чисто транзитных каналах (обычно / 30), а затем с точки зрения клиентов это зависит от их потребностей, из-за того, насколько коротким является каждый на IPv4, что означает, что вместо использования Общее правило: вы должны воспринимать каждого клиента как отдельную сущность и соответствующим образом собирать его требования.

Это все, конечно, если вы имели в виду пространство PUBLIC IPv4, с точки зрения внутреннего материала RFC1918, то планируйте свои ассигнования так, чтобы вы строили пространство для расширения (например, в здании всего 50 человек, не давайте им просто 26). потому что это подсеть следующего размера, но, возможно, дайте им / 24 для расширения.

Другой хорошей практикой является выделение для агрегирования, то есть если у вас есть здание с 10 этажами, выделите / 20 (или больше) для здания, а затем выделите подсети для каждого этажа / отдела из этого / 20, таким образом, вы можете объявляйте только / 20 остальной части вашей сети, а не все отдельные подсети для каждого этажа.