Использование адресов 255.x.0.0/16 для overlay-подсетей в Docker

Использование адресов 255.x.0.0/16

А зачем?

Чтобы не использовать адреса из стандартных частных диапазонов, и не иметь конфликтов в интранетах и виртуальных окружениях в общем случае. Например, адреса 172.17+ используются самим Докером. 192.168.* - VirtualBox. Кроме того, все эти диапазоны активно используются для интранетов.

Теоретически может найтись софт, который знает, что 240.0.0.0/4 нельзя использовать для адресации хостов.

Скорее всего будут проблемы с динамическим роутингом.

Попробуй и расскажи об граблях которые тебе попались на этом пути.

240-254. - это класс E, который зарезервирован для опытов. А тут 255. Некоторые пишут, что это, типа, широковещательные адреса, но в RFC я про это ничего не нашел.

Если верить RFC 6890

240.0.0.0/4 - reserved

255.255.255.255/32 - Limited Broadcast 

IMHO проблемы модут быть только со старым сетевым софтом.

а почему бы тебе IPv6 не использовать

Это отдельный вопрос почему в Docker IPv6 по умолчанию выключен.

Кроме возможных проблем с конечным потребителем услуги не каких. Я имею ввиду программное обеспечение. С точки зрения маршрутизатора диапазон 255.0.0.0/8, а именно так он определён в прошлом, как один из блоков класса E, нечем не отличается от любого другого блока, за исключением запрета его маршрутизации в глобальной сети Интернет.

Но, почему не хотите использовать диапазон 10.0.0.0/8?

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

Но, почему не хотите использовать диапазон 10.0.0.0/8?

Потому же, почему и все остальные: он активно используется в интранетах.

Не понимаю проблему, если это корп сеть - спроси админа, какую сеть тебе взять, если админ это ты - озаботься IP планом сети. Если это домашняя сеть - или забей или относись к ней как к своей корп сети. Что значит «адреса 172.17+ используются самим Докером»!? Им самим ни чего не используется, юзай параметр --subnet и задавай сети как надо а не метайся между созданными как попало

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

С нашей подсетью никто не пересечется потому, что она внутри Докера, который обеспечивает виртуализацию в том числе и IP-адресов. В принципе, даже с вышеупомянутыми диапазонами локальных сетей проблема заключается только в том, что приложение в Докере не в состоянии получить доступ к ресурсам в этих подсетях, если тот же диапазон выбран для overlay-сети.

Что значит «адреса 172.17+ используются самим Докером»!?

Вот это: https://docs.docker.com/engine/userguide/networking/ Об остальном я выше написал анону.

Что «вот это»? Где там написано что нельзя использовать нужную тебе подсеть?

Что «вот это»?

Это ответ на твой вопрос.

Где там написано что нельзя использовать нужную тебе подсеть?

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

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

которым тебе скорее всего придется маршрутизировать свою подсеть

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

што?

Блок адресов 10.0.0.0/8 невероятно огромен, вы можете использовать любой агрегированный префикс, например 10.255.0.0/16, хотя я с трудом представляю, зачем вам такой короткий префикс /16. Какое количество узлов предполагается в вашей Overlay сети?

Технически нет не какой проблемы в том, чтобы обеспечить соединение двух подсетей с одинаковыми префиксами, как в IPv4 (NAT, Proxy ARP), так и в IPv6 (NAT66, ND Proxy).

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

Про план адресации и политику маршрутизации уже сказали выше без меня.

Ребят, af5 и ZANSWER, вы вообще в курсе как устроен Docker и для чего нужен? Такое впечатление, что я тут общаюсь с админами, которые только и умеют, что отшивать назойливых юзеров, мешающих им сёрфить интернеты. Я здесь не спрашиваю как мне настроить корпоративную сеть с блэкджеком и шлюхами VPN между офисами. Мне нужно настроить приложение для докера так, чтобы его не нужно было перенастраивать под каждого нового пользователя.

Используй 100.64.0.0/10

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

VRF, ip netns ....

А Docker по-твоему что такое?

Не один блок адресов в IPv4 протоколе, если он не выдан LIR/RIR не является уникальным.

Любые блоки, определённые, как локально используемые, не уникальны по определению.

Ваша задача на 100% не решаема, без применения выше озвученных техник. Docker вообще не имеет никакого отношения к overlay сетям или underlay сетям.

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

Это Carrier Grade NAT блок, его используют Интернет Сервис Провайдеры (ISP) в случае NAT444.

Используются для маршрутизации между CPE и BNG, могут ли они использоваться для реализации доступа к сервисам? Да, могут, включая и DNS.

попингуй 1.0.*.*

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

Спасибо, Кэп. А Docker и является системой управления этими (в частности) штуками. При этом от сабжевого вопроса никак не избавляет.

Docker вообще не имеет никакого отношения к overlay сетям

В таком случае ты просто не имеешь представления о том, что такое Docker.

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

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

Слава богам документация на Docker теперь открыта для всех, а не только для вас

Я даже давал выше ссылки на соответствующие места.

Значит вы можете предположить, что все их могли прочитать.

И вполне могут знать о том, что Docker использует VXLAN протокол RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.

Тем не менее, это не имеет не какого отношения к тому факту, что уникальных префиксов в IPv4 кроме выданных RIR/LIR нет и быть не может.

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

что все их могли прочитать.

Могли прочитать все, но ЛОР-Ъ себя этим не утруждают.

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

Мне на это плевать примерно так же, как администратору локальной сети плевать на то, что кто-то в другой локальной сети использует такой же блок адресов. Его сеть находится за NATом и ему важно чтобы все общедоступные ресурсы Интернета были доступны и в его локальной сети. С Докером похожая ситуация с той лишь разницей, что его overlay-сеть (тоже находящаяся за NATом) может быть поверх стандартной интранет-сети, находящейся за NATом по отношению к Интернету. В контексте этой темы важно, чтобы из докеровской overlay-сети были одинаково хорошо доступны как ресурсы Интернета, так и ресурсы этих стандартных интранетов. Вот для этого и нужен не используемый в стандартных окружениях блок адресов.

Это всё понятно, но, ещё раз, все не глобально маршрутизируемые блоки общие, а значит рано или поздно вы столкнётесь с тем, что ваш префикс пересечётся с таковым в локальной сети. В IPv4 нет префикса который бы был некем не использован, если это разрешено.

Кроме зарезервированного префикса, ранее относившегося к классу Е, о котором вы и так уже знаете.

Но, кто знает, может быть вы не один кто решил его использовать, по тем же самым соображениям.

В IPv4 нет префикса который бы был некем не использован, если это разрешено.
Кроме зарезервированного префикса, ранее относившегося к классу Е, о котором вы и так уже знаете.

А как насчёт 169.254/16?

По каким причинам к вашему докеру нельзя файл конфигурации прикрутить, чтобы указать диапазон для оверлей сети? Или скрипт, который при поднятии докера будет сам, раз уж пользователи в стадии терминальной деменции, проверять машрутизируемость нужной подсети?

Link-local адреса назначаются случайным образом, но широко используются в Windows и OS X/iOS по умолчанию.

В остальных системах это будет зависеть от настроек, но Windows и OS X/iOS клиенты назначают их себе сами, в случае если не удалось получить DHCPOFFER в ответ на DHCPDISCOVER.

По каким причинам к вашему докеру нельзя файл конфигурации прикрутить, чтобы указать диапазон для оверлей сети?

Он давно прикручен.

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

Это предложение выглядит почти так же элегантно и просто, как слова «искусственный интеллект». Но, допустим, мы его как-то написали. Вопрос: что этот скрипт должен будет сделать, если все private-префиксы оказались заняты?

Это что ж за сеть такая, в которой сервисов, требующих нетранслируемого ip-адреса, более 2^24? И даже в этом фантастическом случае, вы не готовы отказаться от доступа к малой части этих загадочных сервисов, но готовы отказаться от маршрутизации части белого интернета?

но готовы отказаться от маршрутизации части белого интернета

240/4 - не часть белого интернета.