Протокол IP : Dynamic Address Allocation and Resolution

Нулевая подсеть и подсеть с одними единицами

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (8 февраля 2010) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

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

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Нулевая подсеть

Если сетевой адрес разделен на подсети, первой подсетью, полученной после этого разделения, является нулевая подсеть.

Рассмотрим адрес класса B 172.16.0.0. По умолчанию адрес Класса B 172.16.0.0 имеет 16 битов, зарезервированных для представления части, относящейся к хосту, таким образом позволяя 65534 (216-2) допустимые адреса узла. Если сеть 172.16.0.0/16 разделена на подсети путем заимствования трех битов у части, относящейся к хосту, восемь (23), подсети получены. В следующей таблице приведен пример разделения адреса 172.16.0.0 на подсети с указанием масок подсетей, соответствующих широковещательных адресов и диапазона допустимых адресов узлов.

Адрес подсети Маска подсети Широковещательный адрес Допустимый диапазон узлов
172.16.0.0 255.255.224.0 172.16.31.255 172.16.0.1–172.16.31.254
172.16.32.0 255.255.224.0 172.16.63.255 172.16.32.1–172.16.63.254
172.16.64.0 255.255.224.0 172.16.95.255 172.16.64.1 – 172.16.95.254
172.16.96.0 255.255.224.0 172.16.127.255 172.16.96.1 – 172.16.127.254
172.16.128.0 255.255.224.0 172.16.159.255 172.16.128.1 – 172.16.159.254
172.16.160.0 255.255.224.0 172.16.191.255 172.16.160.1–172.16.191.254
172.16.192.0 255.255.224.0 172.16.223.255 172.16.192.1–172.16.223.254
172.16.224.0 255.255.224.0 172.16.255.255 172.16.224.1–172.16.255.254

В приведенном выше примере первая подсеть (подсеть 172.16.0.0/19) называется нулевой подсетью.

Класс сети, разделяемой на подсети, а также количество полученных подсетей не влияют на определение нулевой подсети. Это первая подсеть, полученная путем выделения подсетей из сетевого адреса. Также при записи адреса нулевой подсети в двоичном формате все биты подсети (в этом случае биты 17, 18 и 19) являются нулями. Нулевая подсеть также называется подсетью «все нули». .

Подсеть "все единицы"

При выделении подсетей из сетевого адреса последняя сеть называется подсетью «все единицы».

В примере, рассмотренном выше, последняя подсеть, полученная при разделении сети 172.16.0.0 (подсеть 172.16.224.0/19), является подсетью «все единицы».

Класс сети, разделяемой на подсети, а также количество полученных подсетей не влияют на определение подсети «все единицы». Также при записи адреса подсети «все единицы» в двоичном формате все биты подсети (в этом случае биты 17, 18 и 19) являются единицами, отсюда и название.

Неполадки, связанные с нулевой и последней подсетями

Традиционно рекомендовалось ни в коем случае не использовать нулевую подсеть и подсеть «все единицы» для адресации. Согласно RFC 950 leavingcisco.com, "Полезно сохранить и расширить интерпретацию их особенных (сеть и широковещание) адреса в подсетях. Это означает, что значения со всеми нулями и всеми единицами в поле подсети не должны присваиваться фактическим (физическим) подсетям»." Это - причина, почему проектировщики сети, требуемые для вычисления количества подсетей, полученных путем заимствования трех битов, вычислили бы 23-2 (6) а не 23 (8). Действие «– 2» выполняется с учетом того, что традиционно нулевая подсеть и подсеть «все единицы» не используются.

Нулевая подсеть

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

Вновь обратимся к рассмотренному выше примеру. Возьмем IP-адрес 172.16.1.10. Если вычислить адрес подсети, относящийся к этому IP-адресу, то получится подсеть 172.16.0.0 (нулевая подсеть). Обратите внимание, что этот адрес подсети идентичен сетевому адресу 172.16.0.0, который и был разделен на подсети, поэтому при выделении подсетей появляется сеть и подсеть (нулевая подсеть) с идентичными адресами. Раньше это приводило к путанице и недоразумениям.

До Cisco Выпуск ПО IOS� 12.0, маршрутизаторы Cisco, по умолчанию, не позволяли IP-адресу, принадлежащему команде subnet zero быть настроенным на интерфейсе. Однако, если проектировщик сети, работавший с ПО Cisco IOS версии младше 12.0, не видел препятствий для использования нулевой подсети, можно было воспользоваться командой ip subnet-zero в режиме глобальной конфигурации для отмены этого ограничения. С появлением ПО Cisco IOS версии 12.0 команда ip subnet-zero на маршрутизаторах Cisco стала применяться по умолчанию, однако если проектировщик сети не считает безопасным использование нулевой подсети, можно использовать команду no ip subnet-zero для отключения использования адресов нулевой подсети.

В версиях, предшествовавших ПО Cisco IOS версии 8.3, использовалась команда service subnet-zero.

Подсеть "все единицы"

Использование подсети «все единицы» для адресации ранее не рекомендовалось из-за возможных недоразумений, связанных с наличием сети и подсети с идентичными широковещательными адресами.

Если обратиться к рассмотренному выше примеру, широковещательным адресом для последней подсети (подсети 172.16.224.0/19) был адрес 172.16.255.255, идентичный широковещательному адресу сети 172.16.0.0, разделенной на подсети. Поэтому при выделении подсетей появляется сеть и подсеть (подсеть «все единицы») с идентичными широковещательными адресами. Другими словами, проектировщик сети мог настроить адрес 172.16.230.1/19 на маршрутизаторе, но впоследствии не мог отличить широковещательный адрес локальной подсети (172.16.255.255 (/19)) от широковещательного адреса всей сети класса B (172.16.255.255(/16)).

Хотя теперь подсеть «все единицы» может быть использована, неправильная конфигурация приведет к неполадкам. Чтобы понять возможные последствия, рассмотрим следующую ситуацию:

/image/gif/paws/13711/40a.gif

Примечание: Посмотрите Хост и Количества подсетей для подробных данных.

Маршрутизаторы со второго по пятый являются маршрутизаторами доступа, на каждом из которых имеется несколько входящих асинхронных подключений (или подключений ISDN). Сеть (195.1.1.0/24) разделена на четыре подсети для нужд входящих пользователей. Каждая подсеть передана каждому из маршрутизаторов доступа. Кроме того, асинхронные линии настроены как ip unnum e0. На маршрутизаторе 1 настроены статические маршруты, указывающие на соответствующие маршрутизаторы доступа, а на каждом маршрутизаторе доступа настроен маршрут по умолчанию, указывающий на маршрутизатор 1.

Таблица маршрутизации на маршрутизаторе 1 выглядит следующим образом:

C  195.1.2.0/24   E0
      S  195.1.1.0/26   195.1.2.2
      S  195.1.1.64/26  195.1.2.3
      S  195.1.1.128/26 195.1.2.4
      S  195.1.1.192/26 195.1.2.5

Маршрутизаторы доступа такой же связанный маршрут к Ethernet, такой же маршрут по умолчанию и несколько маршрутов узла для асинхронных линий (предоставляемых протоколом PPP).

Router 2 routing table:                  Router 3 routing table:                    
                                                                                
      C  195.1.2.0/24   E0                       C  195.1.2.0/24   E0           
      S  0.0.0.0/0      195.1.2.1                S  0.0.0.0/0      195.1.2.1    
      C  195.1.1.2/32   async1                   C  195.1.1.65/32   async1      
      C  195.1.1.5/32   async2                   C  195.1.1.68/32   async2      
      C  195.1.1.8/32   async3                   C  195.1.1.74/32   async3      
      C  195.1.1.13/32   async4                  C  195.1.1.87/32   async4      
      C  195.1.1.24/32   async6                  C  195.1.1.88/32   async6      
      C  195.1.1.31/32   async8                  C  195.1.1.95/32   async8      
      C  195.1.1.32/32   async12                 C  195.1.1.104/32   async12    
      C  195.1.1.48/32   async15                 C  195.1.1.112/32   async15    
      C  195.1.1.62/32   async18                 C  195.1.1.126/32   async18    
          
  Router 4 routing table:                  Router 5 routing table:                    
                                                                               
      C  195.1.2.0/24   E0                       C  195.1.2.0/24   E0          
      S  0.0.0.0/0      195.1.2.1                S  0.0.0.0/0      195.1.2.1   
      C  195.1.1.129/32   async1                 C  195.1.1.193/32   async1    
      C  195.1.1.132/32   async2                 C  195.1.1.197/32   async2    
      C  195.1.1.136/32   async3                 C  195.1.1.200/32   async3    
      C  195.1.1.141/32   async4                 C  195.1.1.205/32   async4    
      C  195.1.1.152/32   async6                 C  195.1.1.216/32   async6    
      C  195.1.1.159/32   async8                 C  195.1.1.223/32   async8    
      C  195.1.1.160/32   async12                C  195.1.1.224/32   async12   
      C  195.1.1.176/32   async15                C  195.1.1.240/32   async15   
      C  195.1.1.190/32   async18                C  195.1.1.252/32   async18

Что произойдет, если неправильно настроить хосты на асинхронных линиях, чтобы маска была 255.255.255.0, а не 255.255.255.192? Все будет работать должным образом.

Посмотрите, что происходит, когда один из этих хостов (195.1.1.24) производит локальную рентрансляцию (NetBIOS, WINS). Пакет выглядит следующим образом:

s: 195.1.1.24 d: 195.1.1.255

Пакет получен маршрутизатором 2. Маршрутизатор 2 отправляет его маршрутизатору 1, который отправляет его маршрутизатору 5. Последний отправляет пакет маршрутизатору 1, который отправляет его маршрутизатору 5, и так далее, пока не истечет срок действия пакета (TTL). .

Далее следует еще один пример (узел 195.1.1.240):

s: 195.1.1.240  d: 195.1.1.255

Этот пакет получен маршрутизатором 5. Маршрутизатор 5 отправляет его маршрутизатору 1, который отправляет его маршрутизатору 5. Последний отправляет пакет маршрутизатору 1, который отправляет его маршрутизатору 5, и так далее, пока не истечет срок действия пакета (TTL). . В этой ситуации может сложиться впечатление атаки с помощью имитации пакетов. Учитывая загрузку маршрутизатора 5, подобное предположение не является безосновательным.

В этом примере был создан цикл маршрутизации. Так как маршрутизатор 5 обрабатывает подсеть «все единицы», на него приходятся чрезмерные нагрузки. Маршрутизаторы со 2-го по 4-й получают «широковещательный» пакет только один раз. Маршрутизатор 1 также получает пакеты. Но что происходит, если используется маршрутизатор Cisco 7513, который в состоянии правильно обработать такое разделение на подсети? ? В этом случае на каждом узле понадобится указать правильную маску подсети.

Для защиты от неправильной настройки узлов создайте интерфейс обратной связи на каждом маршрутизаторе доступа со статическим маршрутом от 195.1.1.255 до адреса обратной связи. Для этого следует использовать интерфейс Null0, однако это приведет к созданию сообщений ICMP (Internet Control Message Protocol) о недоступности.

Использование нулевой подсети и сети с одними единицами

Следует отметить, что, несмотря на рекомендации не использовать нулевую подсеть и подсеть «все единицы», все адресное пространство, включая и рассматриваемые две подсети, всегда было доступно для использования. Использование подсети «все единицы» было явно разрешено, а явное разрешение на использование нулевой подсети появилось с выходом ПО Cisco IOS выпуска 12.0. Даже до Cisco IOS версии 12.0 нулевые подсети могли использоваться благодаря наличию команды ip subnet-zero глобальной конфигурации.

По вопросу об использовании нулевой подсети и подсети "все единицы", leavingcisco.comсостояний RFC 1878, "Эта практика (исключения "все нули" и подсетей "все единицы") является устаревшей. Современное программное обеспечение может использовать все определяемые сети. В настоящее время использование нулевой подсети и подсети «все единицы» в целом допустимо, и большинство производителей поддерживают их использование. Однако в некоторых сетях, особенно в тех, где используется устаревшее программное обеспечение, использование нулевой подсети и подсети «все единицы» может привести к неполадкам.

Связанные обсуждения сообщества поддержки Cisco

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


Дополнительные сведения


Document ID: 13711