vlan работает если enable_neutron_provider_networks: yes использовать в global.conf

нужен совет, куда копать

перечитал уже все что только возможно

2023.1

да, перепробовал все с yoga до 2023ю2, одна и та же проблема

что на виртуалках что на железе

Так и не могу завести L2 через control

А что есть "Завести L2"?

Экст-нет - flat?

Или как?

мне нужен только L2 , т.е внутри создаю VLAN, шлюз на внешнем FW

VLAN шлюз - у меня мозг взорвался. :(

момент

образно так, никаких роутеров внутри облака не нужно и плоских сетей тоже.

OVS

а как без него?

нет vxlan не нужен

честно говря не очень понял про ml2, это плагин управляет слоем L2

как без него?

так а разве указанием tenant_network_types = vlan не должно работать?

да все верно Project network types поддерживает типvlan

но оно не заводиться.

выше писал что если использовать enable_neutron_provider_networks: yes, т.е на прямую с compute тогда проблем нет, но без этого параметра, настройка использование vlan через control не работает.

вопрос, по какой причине?

выше писал что если использовать enable_neutron_provider_networks: yes, т.е на прямую с compute тогда проблем нет, но без этого параметра, настройка использование vlan через control не работает.

А ты понимаешь что эта настройка делает?

Покажи конфиг плагина из нейтрон конф

мл2

А ты понимаешь что эта настройка делает?

да, тут все прозрачно

Покажи конфиг плагина из нейтрон конф

type_drivers = flat,vlan tenant_network_types = vlan mechanism_drivers = openvswitch,l2population extension_drivers = port_security [ml2_type_vlan] network_vlan_ranges = physnet2:1000:3000 [ml2_type_flat] flat_networks = physnet2

penvswitch_agent.ini [agent] tunnel_types = vxlan l2_population = true arp_responder = true [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver [ovs] bridge_mappings = physnet2:br-ex datapath_type = system ovsdb_connection = tcp:127.0.0.1:6640 ovsdb_timeout = 10 local_ip = X.X.X.X

да, тут все прозрачно

Раз прозрачно, объясни. Я, может, не так понял тебя, но по описанию у тебя как раз есть сеть с vlan сегментацией, где есть какие-то роутеры. И виртуалки через эти роутеры должны ходить в интернет.

Это "провайдерская" сеть. Внешняя по отношению к опенстеку.

да, тут все прозрачно

при этой настройке, на compute ноде создается br-ex и мапиться на physnetX (ens2f1) настроенный в транке, соответственно трафик идет минуя control ноду. Далее чтобы попасть "наружу" попадает на FW где терминирован шлюз от туда уже куда разрешено.

или по другому

vcenter, внутри сети разруливаются через dswitch на котором куча сегментов. по сути мне нужно тоже самое.

ovs-vsctl show на ноде , там все сбриджевалось?

при этой настройке, на compute ноде создается br-ex и мапиться на physnetX (ens2f1) настроенный в транке, соответственно трафик идет минуя control ноду. Далее чтобы попасть "наружу" попадает на FW где терминирован шлюз от туда уже куда разрешено.

А тебе как нужно?

чтобы трафик ходил через control ноду

чтобы трафик ходил через control ноду

Зачем?

Чтобы иметь единую точку отказа и проблемы с масштабированием?

Чтобы иметь единую точку отказа и проблемы с масштабированием?

соглашусь с тобой, но обе схемы имеют право жить)

чтобы трафик ходил через control ноду

Создай роутер, дай ему выход в провайдер нетворк, все остальные тачки создавай в той же сети что и роутерё

соглашусь с тобой, но обе схемы имеют право жить)

Объясни для чего такая схема нужна. Пока как будто ты что-то недопонял и придумал сам себе проблему.

Создай роутер, дай ему выход в провайдер нетворк, все остальные тачки создавай в той же сети что и роутерё

Ну да, разве что, вот такой вариант.

у меня есть инстанс раздеплоенный через helm, все работает. А через ansible kolla с этими же настройка нет. конфиги один в один .

пробовал 4 разных версии, одно и тоже.

но должно работать!)

ovs-vsctl show на ноде , там все сбриджевалось?

Объясни для чего такая схема нужна. Пока как будто ты что-то недопонял и придумал сам себе проблему.

к сожалению или к счастью, но такая задача.

к сожалению или к счастью, но такая задача.

А что на "контрол ноде"? Чем необходимость обусловлена?

А что на "контрол ноде"? Чем необходимость обусловлена?

это как раз с контрола

с компьюта Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port br-int Interface br-int type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int}

openstack router list

создавай роутер - давай ему выход в провайдер нетворк с контрола, прикручивай виртуалки к роутеру

будет выход

роутера то нет

виртуальный роутер в опенстек

ок, т.е шлюз будет на виртуальном роутере?

по сути да

но тут тебе надо определиться точно ли норм такая схема потому что маштабируемость у тебя будет проблемой

по сути да

оно так работать не будет, шлюз терминирован на FW

но тут тебе надо определиться точно ли норм такая схема потому что маштабируемость у тебя будет проблемой

по другому никак, у меня варя по такому принципу живет.

но тут тебе надо определиться точно ли норм такая схема потому что маштабируемость у тебя будет проблемой

масштабируемость со стороны control?

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

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

Нормально себя будут вести. Ты чем больше пишешь тем меньше понятно в чем задумка и тем больше каажется что что-то перемудрил.

Нормально себя будут вести. Ты чем больше пишешь тем меньше понятно в чем задумка и тем больше каажется что что-то перемудрил.

задумка простая съехать в вари на stack

Что там может сломаться? ВМ останутся в том же бродкаст домене, fdb физических свитчей обновятся в тот же момент как на свитчи попадет трафик от смигрированной вм. При живой миграции пара пакетов потеряется, но на этом и всё. При холодной миграции никаких проблем.

задумка простая съехать в вари на stack

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

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

))

Что там может сломаться? ВМ останутся в том же бродкаст домене, fdb физических свитчей обновятся в тот же момент как на свитчи попадет трафик от смигрированной вм. При живой миграции пара пакетов потеряется, но на этом и всё. При холодной миграции никаких проблем.

глядя на то что с настройкой L2 такая ерунда, честно говоря ничему наверное не удивлюсь.

глядя на то что с настройкой L2 такая ерунда, честно говоря ничему наверное не удивлюсь.

Да никакой ерунды нет.

Да никакой ерунды нет.

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

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

Так она и будет работать если default gw указанный в настойках провайдерской сети будет на твоей контрол ноде. Но я так и не понял для чего это нужно. Это схема во всех отношениях плохая.

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

схема с контрол - без роутеров не должна работать

схема с контрол - без роутеров не должна работать

почему, если я буду использовать stack как приватное облако в качестве внутренней стенда под виртуалзацию.

ты мне на уровне Л2 - Л3 обьясни как у тебя трафик пойдет через контролы если там нет шлюза для виртуалки

без стека

просто в свитче хотя бы

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

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

ты мне на уровне Л2 - Л3 обьясни как у тебя трафик пойдет через контролы если там нет шлюза для виртуалки

В случае с контрол: на контрол ноде (br-ex, br-int, br-tun). на компьют (br-int, br-tun) - br-ex на ней нет. С компью вм в VLANXXXX от подключается tap интерфейсом к br-int — br-tun компьют — br-tun контрол — br-int — br-ex —physnet2(ensXXX в транке) дальше до физического коммутатора к которому подключен маршрутизатор в VLANXXX.