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

ну или frr развернуть на виртуалке и на неё кидать

Внешние интерфейсы роутеров на лифы приходят в разных vrf. Public раздает FIP из Public IP только ограниченному числу инстансов, внутрянка нужна каждому инстансу.

Вопрос именно в том, что несколько FIP мапятся в один и тот же порт в опенстеке, где используется OVN с distributed FIP. Могут ли всплыть проблемы на стороне опенстека?

на стороне опенстека как раз проблем не будет, проблемы будут на слое cloud-init

почему ? dhcp отдаст маршрут и всё ок

получится слоеный пирожочек с flow, ну то есть у нас на один тарочек будет 2 неймспейса с фипами qrouter и докучи dhcp:)

Звучит как план

надежный как швейцарские часы

А главное - дебажить это будет весьма увлекательно

Какая загадочная схема…

Там просто ТСПУ забыли сбоку дорисовать

Просто вот интересно, для чего такая архитектура вообще может потребоваться :)

Глупый наверно вопрос, а где и как задаются креды для доступа в horizon? Под admin говорит не верно:( или ткните хотя бы где в доках это:(

смотря чем деплоили

Ставил через apt install openstack-dashboard

horizon знать не знает про креды (и не должен), всем рулит keystone

Значит надо смотреть юзеры и прочее в keystone?

Просто вот интересно, для чего такая архитектура вообще может потребоваться :)

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

Ощущение, что вы хотите трафик E-W, но рисуете его через S-N. По крайней мере с Ваших слов я вижу это так

Ощущение, что вы хотите трафик E-W, но рисуете его через S-N. По крайней мере с Ваших слов я вижу это так

По отношению к опенстеку это s-n трафик, так как shared services не часть опенстека

Если нужен просто доступ к каким-то сервисам из внешней сети, почему не прицепишь общую сеть и в ней через DHCP опцию 121 не раздашь маршруты к сервису? Зачем сюда статику или, уж тем более, NAT мешать?

По-моему проще сделать ip-fabric, nat тут как мне кажется вообще не нужен

в доке написано build, resize, snapshot, migrate, rescue, unshelve, но мало ли

Если нужен просто доступ к каким-то сервисам из внешней сети, почему не прицепишь общую сеть и в ней через DHCP опцию 121 не раздашь маршруты к сервису? Зачем сюда статику или, уж тем более, NAT мешать?

Трафик выходит через нетворк ноды, не используется DVR.

Трафик выходит через нетворк ноды, не используется DVR.

И тем более непонятно тогда зачем делать fip вместо прямого подключения к внешней сервисной сети.

Тенанту нужно попадать в интенет и другую внешнюю сеть по отношению к опенстеку. Плюс попадать из интернета в вм.

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

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

Все линуксы и винда, какие видел, обрабатывают корректно. Если, конечно, это не экзотическая древность старше 10 лет)

Могут быть специфические блекбоксы в виде образа. Это будет публик, что клиент развернет никто не знает.

Могут быть специфические блекбоксы в виде образа. Это будет публик, что клиент развернет никто не знает.

гос ?

Документация лжёт. Читайте код

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

Ну вот ты прицепил к вируталке одну сеть self-service, в которой инстансу раздается маршрут по-умолчанию, специфичные маршруты до днсов и всё такое. А вторым интерфейсом прицепил внешнюю сеть в которой тоже работает dhcp, но раздает только адреса и маршруты к вашему сервису внешнему. Весь трафик идет через виртуальный роутер к которому подключена self-service сеть, трафик к вашему внешнему сервису идет напрямую, потому что по dhcp получены специфичные маршруты.

Это в целом наш основной вариант, который понятно как работает. Но в нем есть несколько минусов - если использовать общую провайдер нетворк для всех тенантов, то они будут находиться в общем L2 домене, что сильно не нравится безопасникам. Если для каждого тенанта отдельную сетку делать, то все эти сетки надо растягивать на сети между всеми компьют хостами, что не нравится сетевикам ) P.s. проект не в РФ, все совпадения случайны )