The workaround is adding NeutronNetworkType: 'vlan' in network-environment.yaml No need to use --neutron-network-type in CLI
Hey, I managed to deploy vlan over bonds on my HA setup(bm). I created a network with 2 instances(each on a different compute) and ping instanceB from instanceA: network-environment.yaml: resource_registry: OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/nic-configs/cinder-storage.yaml OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/nic-configs/compute.yaml OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/nic-configs/controller.yaml OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/nic-configs/swift-storage.yaml OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/nic-configs/ceph-storage.yaml parameter_defaults: InternalApiNetCidr: 10.35.174.0/24 StorageNetCidr: 172.18.0.0/24 StorageMgmtNetCidr: 172.19.0.0/24 TenantNetCidr: 172.16.0.0/24 ExternalNetCidr: 10.35.180.0/24 InternalApiAllocationPools: [{'start': '10.35.174.10', 'end': '10.35.174.100'}] StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}] StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}] TenantAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}] ExternalAllocationPools: [{'start': '10.35.180.10', 'end': '10.35.180.50'}] InternalApiNetworkVlanID: 189 DnsServers: ["10.35.28.28","8.8.8.8"] StorageNetworkVlanID: 202 StorageMgmtNetworkVlanID: 203 TenantNetworkVlanID: 201 ExternalNetworkVlanID: 195 ExternalInterfaceDefaultRoute: 10.35.180.254 BondInterfaceOvsOptions: "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true" ControlPlaneSubnetCidr: "24" ControlPlaneDefaultRoute: 192.0.2.1 EC2MetadataIp: 192.0.2.1 NeutronExternalNetworkBridge: "''" NeutronNetworkType: 'vlan' deploy command: openstack overcloud deploy -e /home/stack/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml --templates --control-scale 3 --compute-scale 3 --neutron-network-vlan-ranges datacentre:203:212 --ntp-server clock.redhat.com neutron net-show d0567303-0a0c-4140-996c-c0b371d9874c +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | d0567303-0a0c-4140-996c-c0b371d9874c | | mtu | 0 | | name | net1 | | provider:network_type | vlan | | provider:physical_network | datacentre | | provider:segmentation_id | 208 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | 9fb8ecdd-8b55-4a1a-be38-aa2a8a416fe1 | | tenant_id | 8200d88531e74ccd8e88923a0c145a07 | +---------------------------+--------------------------------------+ [root@overcloud-compute-2 ~]# ovs-vsctl show 45773287-880b-46f0-9d30-f4d642c6ad72 Bridge br-int fail_mode: secure Port "qvofe1ed7d3-c2" tag: 1 Interface "qvofe1ed7d3-c2" Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Bridge br-ex Port "bond1" Interface "enp4s0f0" Interface "enp4s0f1" Port "vlan189" tag: 189 Interface "vlan189" type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port br-ex Interface br-ex type: internal Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan202" tag: 202 Interface "vlan202" type: internal Bridge br-tun fail_mode: secure Port "vxlan-ac10000e" Interface "vxlan-ac10000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.16.0.10", out_key=flow, remote_ip="172.16.0.14"} Port "vxlan-ac10000b" Interface "vxlan-ac10000b" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.16.0.10", out_key=flow, remote_ip="172.16.0.11"} Port "vxlan-ac10000f" Interface "vxlan-ac10000f" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.16.0.10", out_key=flow, remote_ip="172.16.0.15"} Port br-tun Interface br-tun type: internal Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac10000d" Interface "vxlan-ac10000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.16.0.10", out_key=flow, remote_ip="172.16.0.13"} Port "vxlan-ac10000c" Interface "vxlan-ac10000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.16.0.10", out_key=flow, remote_ip="172.16.0.12"} ovs_version: "2.4.0" [root@overcloud-compute-2 ~]# [root@overcloud-compute-2 ~]# tcpdump -vvvnei enp4s0f0 |grep 208 tcpdump: WARNING: enp4s0f0: no IPv4 address assigned tcpdump: listening on enp4s0f0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:01:04.992953 fa:16:3e:34:03:24 > fa:16:3e:0a:19:88, ethertype 802.1Q (0x8100), length 102: vlan 208, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 21238, offset 0, flags [none], proto ICMP (1), length 84) 10:01:05.993212 fa:16:3e:34:03:24 > fa:16:3e:0a:19:88, ethertype 802.1Q (0x8100), length 102: vlan 208, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 21239, offset 0, flags [none], proto ICMP (1), length 84)
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Since this has a workaround and resources are limited, moving to 11.
All the --neutron-* command line options have been removed from the CLI, so this is not relevant any more.