Description of problem: I am trying to use routed provider networks with OVN and distributed compute nodes in 16.0-RC. In my setup, I have a primary physnet for the central site (datacentre) and a physnet for the edge site (edge1) to prevent issues with VLAN ID overlap. When creating an additional network segment using the edge1 physnet and the same VLAN ID, OVN does not create an additional provnet port and attempts to bind one with the 'datacentre' physnet on the edge node which does not have mappings for datacentre. This appears to be the result of networking-ovn creating a single logical switch for all segments of a network (and thus a single provnet port per VLAN ID). Since that provnet port has the datacentre physnet from the initial network creation, binding fails on the edge nodes for the provnet port. Version-Release number of selected component (if applicable): 16.0 RC Steps to Reproduce: 1. Deploy RHOSP 16 RC in a central stack with the default OVN SDN configuration, except define two physnet VLAN ranges (i.e. datacentre:2:1000,edge1:2:1000). The central stack uses the default bridge mapping of datacentre:br-ex 2. Deploy an edge stack tied to the central stack with the same physnet VLAN range configuration and a bridge mapping of edge1:br-ex 3. Create a provider network and subnet using a VLAN network from the central site 4. Create a network segment on that provider network using the same VLAN ID on the edge1 physnet that matches a network in the edge site 5. Map hosts to the appropriate host aggregates in Nova for the network segments 6. Create an instance on the provider network in the central site AZ 7. Create an instance on the provider network in the edge site AZ Actual results: 1. The central site instance works normally and can communicate with the outside world on the provider network. 2. The edge site instance gets DHCP and metadata, but cannot communicate with the outside world. 3. Binding errors for the provnet port appear in the OVN log on the edge node. Expected results: Both instances should be able to communicate with the outside world. Additional info: A lab with this DCN setup deployed can be made available for inspection if needed.
Hi Andrew, I have a question to the VM port configuration. You've written: >> 7. Create an instance on the provider network in the edge site AZ and then: >> 2. The edge site instance gets DHCP and metadata, but cannot communicate with the outside world. Can you please write how this happened? The instance shouldn't get metadata if has only one port from provider network. Has the instance more than one port? Are you using provider network directly attached to instances, or via FIP? Thanks, Maciej
(In reply to Maciej Józefczyk from comment #4) > Hi Andrew, > > I have a question to the VM port configuration. You've written: > >> 7. Create an instance on the provider network in the edge site AZ > and then: > >> 2. The edge site instance gets DHCP and metadata, but cannot communicate with the outside world. > > Can you please write how this happened? The instance shouldn't get metadata > if has only one port from provider network. > Has the instance more than one port? > Are you using provider network directly attached to instances, or via FIP? > > > Thanks, > Maciej Hi Maciej, The instances in question have one port on a VLAN provider network handled by OVN with OVN's distributed DHCP and metadata services.
Removing Target Milestone; please replan
Can you complete the acks for this, it needs a QE ack to be included in the errata at release.
According to our records, this should be resolved by python-networking-ovn-7.4.2-2.20210601204825.el8ost.11. This build is available now.