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.