/ 31 Двухточечные битовые маски


13

Когда целесообразно использовать сеть / 31 в производственной среде и считается ли это хорошей практикой? В двухточечной связи широковещательные рассылки не требуются, поэтому есть ли веские аргументы в пользу использования / 31 вместо / 30, так как кажется, что 30 все еще широко распространены и распространены. Это было определено в RFC 3021 .

Существуют ли варианты использования / 31, кроме как для сохранения адресного пространства? Приносит ли введение / 31s новый набор проблем, которых нет в / 30s?

/ 31 обычно видны только в публичном пространстве, особенно для интернет-провайдеров, или они также обычно используются в приватном пространстве как для интернет-провайдеров, так и для предприятий?


2
Голосование за закрытие, так как это кажется не реальным вопросом, а скорее созданием форума для обсуждения (чего мы хотим избежать). Я видел, как они довольно часто используются в производстве - независимо от того, работают они по назначению или нет, зависит от реализации поставщика.
Джон Дженсен

@JohnJensen позвольте мне перефразировать это тогда ....
knotseh

Я думаю, что вопрос здесь: «когда эта установка используется?»
Bulki

2
@ Майк-Пеннингтон Я должен не согласиться с тобой в этом (с уважением ofc). Я могу понять проблему с адресами / 31 на теоретическом уровне. Поскольку у вас нет адресной части, которая является исключительно адресом, а не широковещательной или подсетевой частью. Однако это может быть использовано, когда вы используете правильную маршрутизацию к этой сети и т. Д. Или двухточечное соединение. Вопросы «почему это возможно» или «когда это используется» - хорошие вопросы.
Bulki

1
Просто чтобы отметить здесь, Mikrotik не поддерживает / 31 или / 127. И они не собираются это исправить.
sdaffa23fdsf

Ответы:


11

Мы использовали / 31s в нашем ядре (Brocade, Juniper, Cisco) более трех лет без каких-либо проблем.

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


Действительно не отвечает на вопрос, делает ли это, «мы использовали это»
jwbensley

Уместно использовать его всякий раз , когда вы хотите, так как он не вызывает каких - либо проблем в производственной сети
mellowd

Так что
включите

6

Как уже было сказано, использование / 31-битных масок может работать и является хорошим способом сохранения доступного адресного пространства.

Что может быть важнее, при каких обстоятельствах вы не можете использовать / 31s? Какие протоколы или приложения могут работать неправильно или нарушаться из-за отсутствия широковещательного адреса ?

BootP и DHCP находятся в верхней части списка в соответствии с предыдущей статьей, но нас не интересуют те, что находятся на двухточечных каналах маршрутизатора. ARP использует широковещательный MAC-адрес, а не IP-адрес, поэтому здесь проблем быть не должно ... OSPF и EIGRP используют адреса многоадресной рассылки, хотя RIP v1 выглядит так, как будто это может быть проблемой.

Что еще зависит от широковещательного или сетевого адреса?


ИМХО это вопрос, а не ответ.
CVn

1
Согласовано. Первоначальный вопрос был сформулирован не очень хорошо, и вопрос был фактически закрыт голосованием. С тех пор, как этот пост был изначально создан, он был переформулирован и вновь открыт. (Надеюсь, это способствовало улучшению вопроса.)
Питер

5

Я использовал их внутри в лабораториях, где работает EIGRP, и пока не нашел никаких проблем.

Как я вижу, если / 24 выделен для диапазона P2P.

  1. / 30 битовая маска = 64 P2P-ссылки
  2. / 31 битовая маска = 128 P2P-ссылок

/ 23 распределение

  1. / 30 битовая маска = 128 P2P-ссылок
  2. / 31 битовая маска = 256 P2P-ссылок

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

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

Кстати, маршрутизаторы Cisco поддерживают эту функцию начиная с IOS 12.2 (2) T


так что вы задаете вопрос, а через 8 минут отвечаете сами ... кажется странным, не так ли? В любом случае, единственная реализация / 31, на мой взгляд, используется на брандмауэрах, где нужны только 2 WAN-адреса (а остальное сделает NAT).
Bulki

@Bulki согласен, что это странно - опубликовал это перед изменением вопроса, так как я искал больше структуры форума / дебатов, которую я не осознавал, что мы избегали.
knotseh

1
Я не думаю, что этот вопрос подходит, так как он очень субъективен. Обычно используется / 31, по крайней мере, у провайдеров. Нет причин не делать этого, потому что крупные поставщики поддерживали его целую вечность.
Даниэль Диб

Это довольно открытый, но сформированный как вопрос должен быть полезным. Возможно, вопрос должен звучать так: «есть ли причина не всегда запускать / 31 и / 127 для двухточечных ссылок», тогда мы могли бы получить интересные данные о поставщиках, где это не работает, или другую мотивацию не запускать их (я могу подумать, одного за / 127)
итти

7
@bulki Нет ничего плохого в том, чтобы опубликовать вопрос, а затем ответить на свой вопрос. Это буквально поощряется. meta.networkengineering.stackexchange.com/questions/4/…
Крейг Константин

2

Учитывая осторожность и важность сохранения адресов, общий подход к использованию / 31 должен быть «если он работает, используйте его» .

Конечно, вы могли бы пойти дальше и начать использовать личное пространство для двухточечных ссылок, но это, очевидно, может быть проблематично, если вы собираетесь запускать traceroutes через Интернет, а не в вашей собственной сети, хотя даже это можно несколько смягчить, настроив маршрутизатор на выдачу ошибок ICMP с определенным IP-адресом источника.

Короче говоря, делайте все возможное, чтобы тратить как можно меньше адресов (в пределах наилучшей практики и выполнимости, не начинайте разбрасывать концентраторы NAT везде)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.