Ask Your Question

Provider network types

asked 2017-05-04 23:17:42 -0600

sanjana gravatar image

image description

The admin tab in horizon allows the creation of Networks. In the provider_network_type there are several options: flat, vlan, vxlan so on. What setting is required to be able to create each of these network?

I followed an openstack install using the self-service networks. But when i try to create an external network in horizon with provider_type_network= vxlan, the VMs have ssh issues. However if i change the provider_network_type= flat, the ssh issues are resolved. As i followed self-service network steps for installation, i assume the creation of external network with vxlan must be allowed. Correct me if i am wrong. I just want to know in simple terms when to create these networks and how.

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2017-05-06 16:27:37 -0600

akaris gravatar image

updated 2017-05-06 16:29:26 -0600

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.

edit flag offensive delete link more


Thanks for the simple explanation. So from the horizon view i can create an external network with any provider_network_type u mean? Could you also tell me the difference incase i use linux bridge as my mechanism driver?

sanjana gravatar imagesanjana ( 2017-05-07 22:46:28 -0600 )edit

But based on my setting, when i launch an external network with provider_network_type=vxlan, my VMs are not able to ping the external nodes(controller)

sanjana gravatar imagesanjana ( 2017-05-07 22:48:39 -0600 )edit

Linux bridge or OVS doesn't make a difference from the conceptual level. The difference is that with ML2/OVS, you'll have openvswitch which configures the bridges, VLAN tagging and VXLAN tunnels. With ML2/linux bridge, all will be done with linux bridges, linux vlans and VXLANs

akaris gravatar imageakaris ( 2017-05-09 12:12:44 -0600 )edit

To troubleshoot, go to the controllers, run ip netns. This will show the namespaces for dhcp and l3 agents. neutron net-list will give the UUID of the network, neutron router-list the UUID of the router, and you can do ip netns | grep <UUID> to grep for those UUIDS

akaris gravatar imageakaris ( 2017-05-09 12:13:52 -0600 )edit

Then, do ip netns exec <namespace name> ip a to display the ip addresses in the namespace. You can also use tcpdump withn the namespace `ip netns exec <namespace name=""> tcpdump <tcpdump parameters="">. Additionally, you can use tcpdump on the physical interfaces to verify that traffic goes in/out.

akaris gravatar imageakaris ( 2017-05-09 12:16:21 -0600 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2017-05-04 23:17:42 -0600

Seen: 1,483 times

Last updated: May 06 '17