Hey, 1. "As Infra1:enp11s0f1 is the only available port to Internet" -> I am even more confused now. So on your graph above I do see that computes are also connected to the same public network as infra1. So is the infra1 being the only host with access to it or not? 2. "Can't we just use something like plain NAT" -> so Floating IPs are implemented through SRC-DST (one-to-one) NAT. There is also an SRC NAT implemented on Logical Routers (L3 agents depending on the driver). So task of Logical Router is actually to accomplish this NAT (and some routing), as it's acting as a gateway for internal (geneve/vxlan) networks from tenant side, while each Logical Router also needs to have a connection and an IP address from the public network to do the NAT. 3. So `br-vxlan` we are using in documentation more as a "common approach" thing. It does not have to be a separate bridge. For vxlan/geneve networks to work, it's enough to have just an interface with an IP address from the "tunnel" network on it. So indeed you can simplify it by dropping br-vxlan itself and just leaving enp11s0f0.30 It feels I also need to add some clarity on "modern" setup with OVN, as I see you're using a lot of OVS/LXB terminology which can be confusing. So I will quickly describe the differences below. - Since 2023.1 (Antelope) we are using ml2.ovn driver for Neutron by default, instead of ml2.lxb (ml2.ovs is very alike to it as well) - OVN uses geneve protocol for encapsulation and implementation of tenant networks instead of vxlan. - Unlike to ovs/lxb drivers, which require L3 agents and spawn virtual routers in network namespaces, OVN does implement that with OpenFlow inside of OVS. So L3 Agent service is not used or deployed there. - OVN has finally a very good implementation for DVR, so you can serve FIPs from computes with VMs directly, without a need to have a dedicated network nodes. While you still can have them (and they're named as gateway nodes now), many smaller setups may benefit from not having them. One more thing I wanted to highlight, is that on your scheme I do not see a network, which will be used for access to the OpenStack APIs or Dashboard (Horizon/Skyline) from the "world". As usually we suggest having a separate "public" network for this purpose. As br-mgmt is mainly designed for internal usage by components. So ideally it should not be exposed or used for "external" connections. чт, 9 окт. 2025 г. в 09:44, <holywine@outlook.com>:
Dear Dmitriy,
Thanks a lot for informative instruction! Still need to spend some time to take in...
In the mean time, would it be possible that you take a look at below link which is the rough idea of networking? ( https://github.com/holywi/git-tutorial/blob/master/mmexport1759995429620.png )
1. As Infra1:enp11s0f1 is the only available port to Internet we will take the single port as the exit of the system no matter the setting is conventionally for production or for testing.
2. The network setting of Infra1, somewhere around Networking L2/L3 Agents, is the most confusing part for me. Can't we just use something like plain NAT? Anyway I totally have no idea on the setting. It would be favorite just to make it simple and straightforward.
3. Not sure if it is reasonble to attach br-vxlan to enp11s0f0, or is it a must to attach it to enp11s0f1 as in referenced link that you provide?
Thanks again!
Best Regards