Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Important to understand when using VLAN isolation is: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of the provider network has to match a VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

where: - --provider-network-type = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS" - --provider-physical-network = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET" - --provider-segment = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important to understand when using VLAN isolation is: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of the provider network has to match a VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

where: - --provider-network-type where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS" - --provider-physical-network = name name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET" - --provider-segment in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important to understand when using VLAN isolation is: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of the provider network has to match a VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation is: isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of the provider network has to match a VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of the provider network has to match a VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

That's why the VLAN ID of As a VLAN ID is assigned to the provider network too, this VLAN ID has to match a the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network.network (here: 3909).

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909).

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to this provider network to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909).

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creatin creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909).

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909).3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation:isolation even provider networks get an VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get an a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID value.ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where:where the following PACKSTACK configuration directives come Info play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs Out of the range are used for project/tenant networks and their isolation.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come Info play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs Out out of the range are used for project/tenant networks and their isolation.isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come Info play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come Info play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come Info into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important: changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin!

plugin! An error will occur that prevents it! :-(

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via via "network set" after the network has has been created is not possible with the the used ML2 plugin! An error will occur occur that prevents it! :-(

  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges.ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!network! when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based VLAN untagged!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network! network!
  • when RDO is running virtualized on on VMware, the port group the vNIC for for north-south connectivity is bound to to has to be configured as trunk (=VLAN (=VLAN 4095) as the VMware vSwitch acts as as switch using port-based VLAN VLAN untagged!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based VLAN untagged!untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 bcn
<name_of_the_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_network>
<name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is used!typical!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one provider network is typical!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the used standard ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for project/tenant networks and their isolation and optionally additional isolated provider networks allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only one a single provider network is typical!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the standard ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for for:

  • project/tenant networks and their their isolation and and
  • optionally additional isolated provider networks isolated provider networks

allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only a single provider network is typical!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the standard ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as switch using port-based untagged VLAN!

Important to understand when using VLAN isolation: https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html

There, it is mentioned below "Self-service networks" that in case of VLAN isolation even provider networks get a tagged VLAN assigned:

Networking allows users to create multiple provider or project networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

As a VLAN ID is assigned to the provider network too, this VLAN ID has to match the VLAN ID used in the physical network to get north-south connectivity. When using PACKSTACK as deployment tool, the following configuration directive:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:<vlan_min>:<vlan_max>

has to offer a range containing the VLAN ID used in the physical network (here: 3909), e.g.:

CONFIG_NEUTRON_ML2_VLAN_RANGES=bcn:3900:3909

The other VLANs out of the range are used for:

  • project/tenant networks and their isolation and
  • optionally additional isolated provider networks

allowing overlapping IP ranges. In general, provider networks offering the floating IP address pool are set shared to be used by different projects/tenants. That's why normally only a single provider network is typical!

After the deployment, when creating the provider network, the VLAN ID used in the physical network has to be explicitly set to prevent an automatically assigned value that does not match the physical VLAN ID.

This can be achieved via:

openstack network create --provider-network-type vlan --provider-physical-network bcn --provider-segment 3909 <name_of_the_provider_network>

during network creation time where the following PACKSTACK configuration directives come into play:

  • "--provider-network-type" = "CONFIG_NEUTRON_ML2_TYPE_DRIVERS"
  • "--provider-physical-network" = name of physnet optionally given in "CONFIG_NEUTRON_OVS_EXTERNAL_PHYSNET"
  • "--provider-segment" = a VLAN ID out of "CONFIG_NEUTRON_ML2_VLAN_RANGES"

Important:

  • changing the provider-values via "network set" after the network has been created is not possible with the standard ML2 plugin! An error will occur that prevents it! :-(
  • the provider networks should be created first to prevent project/tenant networks automatically choosing a VLAN ID later explicitly set in a provider network!
  • when RDO is running virtualized on VMware, the port group the vNIC for north-south connectivity is bound to has to be configured as trunk (=VLAN 4095) as the VMware vSwitch acts as a switch using port-based untagged VLAN!