Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Let's assume that your compute node has interface eth0 connected to OVS bridge br-ex, then the network times act as follows: Flat: instance traffic is sent out of and received by eth0 untagged VLAN: instance traffic is sent out of and received by eth0 tagged with the VLAN tag as specified GRE: instance traffic is sent out of and received by eth0 GRE encapsulated VXLAN: instance traffic is sent out of and received by eth0 VXLAN encapsulated

The admin user can configure all supported network types and VLAN ID/VXLAN ID/GRE ID - regardless of what you configure in the neutron config. Unprovileged users can only pick the network types from what is allowed in neutron's configuration. If you do not specific a VLAN/VXLAN/etc. ID, then it is automatically picked from the range as specified in neutron's configuration.

If an instance spawns with the settings that you provided, then this means that you were allowed to configure it.

If you spawn an instance on a VXLAN, then a VXLAN tunnel is created between the compute node and the controller. You cannot directly ping the subnet that is within the VXLAN tunnel. You need to create a router (which is created on a controller / network node) and this router needs to be attached to a flat network or a VLAN type network. The ingress/egress point for traffic from the virtual networks now is not on the compute node, but on the controller/network node. Normally, you'd assign a floating IP to the instance; this floating IP is created on the controllers/network nodes. Otherwise, you need to make sure that ingress routing (towards the VXLAN subnet) is correctly configured. In any case, the instance needs to be able to route outbound (correct default route), with the first hop router being the controller/network node.

Let's assume that your compute node has interface eth0 connected to OVS bridge br-ex, then the network times act as follows: follows:

Flat: instance traffic is sent out of and received by eth0 untagged

VLAN: instance traffic is sent out of and received by eth0 tagged with the VLAN tag as specified specified

GRE: instance traffic is sent out of and received by eth0 GRE encapsulated encapsulated

VXLAN: instance traffic is sent out of and received by eth0 VXLAN encapsulated

The admin user can configure all supported network types and VLAN ID/VXLAN ID/GRE ID - regardless of what you configure in the neutron config. Unprovileged users can only pick the network types from what is allowed in neutron's configuration. If you do not specific a VLAN/VXLAN/etc. ID, then it is automatically picked from the range as specified in neutron's configuration.

If an instance spawns with the settings that you provided, then this means that you were allowed to configure it.

If you spawn an instance on a VXLAN, then a VXLAN tunnel is created between the compute node and the controller. You cannot directly ping the subnet that is within the VXLAN tunnel. You need to create a router (which is created on a controller / network node) and this router needs to be attached to a flat network or a VLAN type network. The ingress/egress point for traffic from the virtual networks now is not on the compute node, but on the controller/network node. Normally, you'd assign a floating IP to the instance; this floating IP is created on the controllers/network nodes. Otherwise, you need to make sure that ingress routing (towards the VXLAN subnet) is correctly configured. In any case, the instance needs to be able to route outbound (correct default route), with the first hop router being the controller/network node.

Let's assume that your compute node has interface eth0 connected to OVS bridge br-ex, then the network times types act as follows:

Flat: instance traffic is sent out of and received by eth0 untagged

VLAN: instance traffic is sent out of and received by eth0 tagged with the VLAN tag as specified

GRE: instance traffic is sent out of and received by eth0 GRE encapsulated

VXLAN: instance traffic is sent out of and received by eth0 VXLAN encapsulated

The admin user can configure all supported network types and VLAN ID/VXLAN ID/GRE ID - regardless of what you configure in the neutron config. Unprovileged users can only pick the network types from what is allowed in neutron's configuration. If you do not specific a VLAN/VXLAN/etc. ID, then it is automatically picked from the range as specified in neutron's configuration.

If an instance spawns with the settings that you provided, then this means that you were allowed to configure it.

If you spawn an instance on a VXLAN, then a VXLAN tunnel is created between the compute node and the controller. You cannot directly ping the subnet that is within the VXLAN tunnel. You need to create a router (which is created on a controller / network node) and this router needs to be attached to a flat network or a VLAN type network. The ingress/egress point for traffic from the virtual networks now is not on the compute node, but on the controller/network node. Normally, you'd assign a floating IP to the instance; this floating IP is created on the controllers/network nodes. Otherwise, you need to make sure that ingress routing (towards the VXLAN subnet) is correctly configured. In any case, the instance needs to be able to route outbound (correct default route), with the first hop router being the controller/network node.

Let's assume that your compute node has interface eth0 connected to OVS bridge br-ex, then the network types act as follows:

Flat: instance traffic is sent out of and received by eth0 untagged

VLAN: instance traffic is sent out of and received by eth0 tagged with the VLAN tag as specified

GRE: instance traffic is sent out of and received by eth0 GRE encapsulated

VXLAN: instance traffic is sent out of and received by eth0 VXLAN encapsulated

The admin user can configure all supported network types and VLAN ID/VXLAN ID/GRE ID - regardless of what you configure in the neutron config. Unprovileged users can only pick the network types from what is allowed in neutron's configuration. If you do not specific a VLAN/VXLAN/etc. ID, then it is automatically picked from the range as specified in neutron's configuration.

If an instance spawns with the settings that you provided, then this means that you were allowed to configure it.

If you spawn an instance on a VXLAN, then a VXLAN tunnel is created between the compute node and the controller. You cannot directly ping the subnet that is within the VXLAN tunnel. You need to create a router (which is created on a controller / network node) and this router needs to be attached to a flat network or a VLAN type network. The ingress/egress point for traffic from the virtual networks now is not on the compute node, but on the controller/network node. Normally, you'd assign a floating IP to the instance; this floating IP is created on the controllers/network nodes. Otherwise, you need to make sure that ingress routing (towards the VXLAN subnet) is correctly configured. In any case, the instance needs to be able to route outbound (correct default route), with the first hop router being a virtual router on the controller/network node.