Open Cloud Blog

Openstack. Contrail and more

OpenStack Liberty Neutron Deployment (Part 2 Network Infrastructure)

The physical network

A cloud needs an „physical“ network using real „switching routers“ to transport data between the physical nodes.

The physical network has the following layout:

Physical set up

Physical set up

Each floating pool is implemented using one vlan on the physical network infrastructure. Each flat network requires also one vlan on the physical network. VXLAN requires also one vlan on the physical network.

VXLAN adds additional headers (IP and UDP) to packets. You must increase the mtu of the transport VXLAN vlan to a higher value, let’s take 1600. Do not follow the „recommendations“ to reduce the MTU of VMs using the DHCP server. Such a „recommendation“ only leads to big problems in a production environment — do not use a reduced MTU!

The configuration of the physical switching router could be (using a pseudo config language):

The network set up of the nodes

The basic network set up of compute and network nodes is exactly the same. On the nodes, a basic network configuration of the Operating system must be provided by the user. This configuration connects the transport network for VMs on the nodes to the physical network. The network setup of a node is shown in the drawing below:

Openvswitch Bridges on the Nodes

Openvswitch Bridges on the Nodes

The cool part of the network setup is, that only ONE physical interface (or a LACP bundle) is used to transport VM traffic. This interface is connected to br-uplink. If you read the Openstack manuals and believe in everything which is written there, you would end up using FOUR physical interfaces:

  • one physical interface for VXLAN transport. This is not true – VXLAN transport requires an IP address in the default network namespace of the operating system. We choose an Openvswitch internal port on the Openvswitch bridge br-uplink and attach an IP address to it. The default MTU must be set to a higher value. We use 1600.
  • one link to the physical network via br-vlan (or br-eth1 in the Openstack documentation) using a physical interface for the Openstack ML2 „vlan“ type driver. This is not true – we take an Openvswitch patch port as the uplink. This port connects br-vlan to be use by the Openstack ML2 mechanism driver to br-uplink.
  • two interfaces to map the two floating pools to two L3 agents, each using an Openvswitch bridge, which is connected to the physical network using a physical ethernet interface. This is not true – L3 agents are clever enough to avoid the usage of any additional bridges. And one L3 agent may manage multiple floating pools (or external networks if you are talking „Openstack“).

A part of the network configuration must be provided by the admin of the nodes during system startup. This configuration must be placed in the network configuration of the Operating system. The configuration depends on the Linux distribution.

The shell code for the network setup is (the management network is omitted):

Do not enable ip_forwarding on any of the nodes. This is not necessary, even if the Openstack documentation declares this as a prerequisite.

Neutron in Openstack Liberty does not require to use br-ex to get a functional L3 agent providing router services. The default setup in the Openstack documentation is using br-ex, but there are other ways to implement networking, e.g. the one shown in this article series.

Continue reading (part 3) the Openstack Neutron setup

Updated: 17/01/2016 — 12:05
Open Cloud Blog © 2013-2015 Impressum Frontier Theme