Являются ли подсети всегда смежными 1с? [Дубликат]

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

11111111 . 11111111 . 00000000 . 00000000

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

11111111 . 00010001 . 11111111 . 00000000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC 950 говорит в главе 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 с пакетом обновления 1 (SP1) невозможно установить такую ​​маску подсети:

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

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

Я согласен с ответом @Sami Кухмонен:

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

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

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