Всегда ли подсети являются смежными единицами?

Всегда ли подсети являются смежными единицами?

Я понимаю основную предпосылку масок подсетей, таких как 255.255.255.0. Но все примеры подсетей, которые я видел, были (слева направо) смежными единицами (HI битами). Например, 255.255.0.0( /16) преобразуется в следующие октеты:

11111111 . 11111111 . 00000000 . 00000000

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

11111111 . 00010001 . 11111111 . 00000000
  • Произойдет ли это когда-нибудь? Или подсети не могут существовать без смежных единиц? Если да, то почему?
  • В противном случае, если это возможно, зачем бы вы это сделали (несколько конкретных примеров)?

решение1

Раздел 3.1 вЗапрос на предложение (РФК)показывает разрешенные маски в бесклассовой междоменной маршрутизации. Биты должны быть смежными для правильной работы маршрутизации.

Кроме того, если рассуждать логически, то не имеет смысла иметь странные случайные сетевые маски.

решение2

Да, проще всего думать об этом так: маски подсети всегда начинаются с 1. Если индикатор размера подсети не имеет 1 в начале двоичного представления, то я бы сказал, что индикатор размера подсети не является правильной «маской подсети», используя современные стандарты.

RFC1219утверждает, что более ранний RFC 950 допускает несмежную битовую последовательность. Фактически,RFC 950 страница 15(раздел 3) явно содержит пример, который «иллюстрирует несмежные биты подсети». Однако нет способа преобразовать такие подсети в нотацию CIDR. Нотация в стиле CIDR — это то, что использовал IPv6 (по крайней мере с тех пор, какRFC 1884, страница 7, первое предложение раздела 2.4), поэтому несмежные биты никогда широко не поддерживались в сетях IPv6.RFC1219Метод определяет, что «биты подсети (маска = 1) назначаются от наиболее значимого бита к наименее значимому». (RFC 4632 раздел 3.1(О котором упоминает ответ Сами, говорится в официальном стандарте, обсуждающем нотацию CIDR.)

RFC 1878 страница 2показывает стандартную нотацию «маски подсети» для всех подсетей IPv4, за исключением /0.

Однако я собираюсь немного подробнее остановиться на ответе Сами, разобравшись с вопросом «почему» (с конкретным примером, как и требовалось в вопросе)...

Некоторое профессиональное оборудование Cisco поддерживает нечто, называемое «маска подстановочных знаков», которая инвертирует биты. Таким образом, обычная подсеть может быть представлена ​​чем-то, называемым 00000000.00000000.00000000.11111111.

С масками подстановочных знаков Cisco не было правила, что все нули должны идти первыми. Так что вы могли использовать 00000000.00000000.00000000.11111110.

В результате будет создана группа, содержащая все четные IP-адреса.

На самом деле это было важно знать, поскольку обучение в Cisco охватывало это, и поэтому в процессе экзамена на получение профессиональной сертификации Cisco мог возникнуть вопрос о чем-то подобном.

Однако, я думаю, что это было в основном бесполезно. Вместо того, чтобы делить сеть пополам, используя четные или нечетные адреса, вы могли бы просто разделить сеть пополам, используя адреса с низкими и высокими номерами, создавая обычные подсети, которые в два раза меньше.

Маски подстановочных знаков с несмежными битами не были особенно полезны и могли быть более сложными в работе. Смысл бита маски подсети, установленного в 1, заключается в том, что этот бит помогает определить, в какой подсети находится устройство. Нет никаких веских причин распределять эти биты по всему адресу, вместо того чтобы просто аккуратно группировать их в начале адреса. В результате поддержка этих типов масок была дополнительной сложностью без существенной выгоды.

Полагаю, в конечном итоге Cisco согласилась, что в таких нетрадиционных масках подсети нет смысла, поскольку в конечном итоге они отказались от поддержки «шаблонных масок». Старые межсетевые экраны Pix поддерживают «шаблонные маски», но новые устройства ASA вместо этого используют стандартные «маски подсети».

Я бы даже не пытался создать сеть с несмежными «битами подсети» в маске, потому что много программного обеспечения будет следовать новым тенденциям/стандартам и отвергнет такую ​​конструкцию сети. Даже если бы я использовал старое программное обеспечение, я бы, вероятно, хотел, чтобы моя сеть могла быть легко модифицирована для использования нового программного обеспечения без необходимости перепроектирования сети. Поэтому непрерывные «биты подсети» — это единственный выход.

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

решение3

RFC950В главе 2.2 говорится:

 To support subnets, it is necessary to store one more 32-bit
  quantity, called my_ip_mask.  This is a bit-mask with bits set in
  the fields corresponding to the IP network number, and additional
  bits set corresponding to the subnet number field.
 The code then becomes:
   IF bitwise_and(dg.ip_dest, my_ip_mask)
                               = bitwise_and(my_ip_addr, my_ip_mask)
         THEN
             send_dg_locally(dg, dg.ip_dest)
         ELSE
             send_dg_locally(dg,
                    gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

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

В 1985 году возможности процессора и памяти были гораздо более ограниченными, поэтому любые более сложные операции просто не укладывались в отведенное время.

В главе 3 это становится еще более явным:

и что в сети используется 3-битное поле подсети (01011000), то есть маска адреса 255.255.255.88.

Однако эти RFC, похоже, устарели. Например, в Windows 7 SP1 невозможно задать такую ​​маску подсети:

В Windows 7 требуется непрерывная маска подсети

Даже в Windows XP SP2 это было уже невозможно:

Маска подсети Windows XP SP2

Однако клон Windows 98 ReactOS позволяет устанавливать «странную» сетевую маску:

Маска подсети ReactOS

решение4

Я согласен с ответом @Sami Kuhmonen:

Раздел 3.1 в RFC показывает разрешенные маски в бесклассовой междоменной маршрутизации. Биты должны быть смежными, чтобы маршрутизация работала правильно. Кроме того, если рассуждать логически, то не имело бы смысла иметь странные случайные сетевые маски.

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

Я проверял это много лет назад на Win 2000, это работает. На обоих компьютерах была маска 255.160.0.0. Они были в локальной сети без маршрутизатора, поэтому я не могу сказать о поведении маршрутизатора (обычно вы можете задать маску маршрутизатора только в его веб-интерфейсе, который ее отклонит).
Вы также не можете ввести такую ​​«недопустимую» маску подсети в соответствующее поле сетевых настроек; GUI отказывается ее принимать. Но вы можете схитрить, изменив ее напрямую в реестре. После этого перезагрузите или отключите+включите сетевую карту, чтобы изменения вступили в силу.
Цель всего этого: гм, вероятно, никакой.

Связанный контент