Openstack VLAN Networking Overview
Networking In Openstack
OpenStack Networking is an open source, scalable and API-driven system for producing a cluster of networking services in a manageable environment. Openstack is similar to AWS. Openstack a leading community software for today’s private cloud. Openstack Networking offers software-defined networking, which can create multiple networks in a networking environment without using hardware switches and routers. Openstack community creates different projects to manage networking as a service such as Nova and Neutron. Nova service is used for both networking and computing, but neutron is made solely for networking purpose. Let’s discuss some networking related factors.
Why software defined networking?
Our traditional network architectures are not able to meet the current demand. There are many factors that cannot be provided by traditional networks, such as effective utilization of monetary value, flexibility and so forth. We struggle to manage a dynamic networking environment by using traditional networking technologies. Hence the importance of software defined networking arises.
Software defined networking is an approach or concept of computer networking that gives us ability to manage network services through different levels of functionality in an abstract manner. In Software defined networking, the network control and forward functions are independent. In Software defined networking, network control to become programmable and the hardware infrastructure abstracted from networking services and corresponding application, this approach gives us affordable, easily manageable and suitable for the dynamic nature of today’s applications.
Abbreviation
- VLAN – Virtual Local Area Network
- GRE -Generic Routing Encapsulation
- ML2-Modular Layer 2
- OVS-Open Virtual Switch
Openstack Networking
In openstack networking has implemented using two services Nova and Neutron. Mostly we use the Neutron service for openstack networking. Because Nova supports only flat and VLAN networking technology, but neutron offers different type of networking technologies as a dedicated service for networking.
Plugins
Neutron support different type of backends called “plugins” that work with a growing diversity of networking technologies.There are different type of plugins available for neutron, such as ML2, VMware NSX, Cisco, Big Switch / Floodlight… etc.
Official documents of openstack give more support to ML2 plugin. ML2 Plugin is a type drivers to support multiple networking technologies and mechanism drivers to facilitate the access to the networking configuration. ML2 plugin support following networking technology in openstack, such as: Flat networking, GRE Networking,VLAN and VXLAN Networking.
Different networking technologies have implemented on Ml2 plugin by using different mechanism drivers such as OVS, Linux Bridge and l2 population (for creating overlay network).
The GRE is offered by the OVS mechanism driver, it gives more flexible and requires less up front configuration; however, the encryption and encapsulation of packets used by GRE will degrade performance. The VLAN option requires more upfront configuration and design. The VLAN is offered by both OVS and Linuxbridge and VXLAN also offered by both mechanism driver.
In the large production environment, most commonly using VLAN networks. Because, we can create a huge number networks using VLAN than GRE or Flat networking technology. So, I’m intending to explain more about VLAN than other networking technologies. Let’s talk about VLAN.
VLAN(Virtual Local Area Network)
In VLAN the switch creates different independent zones by adding tags to each frame as an ID that numbered from 1 to 4096 commonly called as VLAN ID. It allows users to create 4095 tenant networks. In IEEE standards VLAN is represented as IEEE 802.1Q. Commonly First ID used as the native VLAN. This not used for creating network. The only purpose is to handle untagged frames received on a trunk port.
You can know much about VLAN and VLAN, these links may helpful:
https://en.wikipedia.org/wiki/Virtual_LAN
http://www.firewall.cx/networking-topics/vlan-networks/219-vlan-tagging.html
Here, I ‘m try to talk about VLAN implementation using ML2 plugins. There are two common practices of VLAN implementation is VLAN Using Linux Bridge and the other is VLAN Using Open Virtual Switch (OVS). We can use other plugins such as VMware NSX, Cisco, Big Switch / Floodlight … etc, instead of ML2 plugin.
In this blog gives a brief introduction to the openstack VLAN. So, I have utilized a simple openstack structure as below
Let start talk about Linux Bridge and OVS Mechanism Driver using VLAN networking technology.
VLAN Using Linux Bridge Mechanism Driver
VLAN using linux bridge is a traditional networking mechanism which gives more reliability and throughput. A Linux bridge is more powerful than a hardware bridge because we can shape the network. We cannot consider Linux bridge as a hub, because it is a full featured bridge with forwarding table, frame ageing and even spanning tree support. In production Linux bridge ensures less admin overhead with great throughput efficiency. In Linux bridge each ethernet segments connected together in a protocol as an independent way
VLAN Implementation on ML2 plugin
We have used ML2 plugin for the implementation VLAN. We must configure both Compute and Controller nodes, If a Network node exists it also. Here, I will try to illustrate basic diagram to how Controller and Compute is configured using Linux Bridge VLAN on ML2 plugin. Below example, physical network supports VLAN.
Compute Node
Tap device: Interface of vim eg: eth0 attached to vm’s.
Linux Bridge: It acts as a hub. We can connect multiple interface to Linuxbridge. It transmitted frame coming from one interface to all other interfaces.
Security Groups: Set of IP filter rules that applied in networking of each instance.
Explanation
Each VLAN device is associated with a VLAN tag attaches to a VLAN interface device and adds or removes VLAN tags. Vans are created on Compute Node, here above example, VLAN ID 10 associated with VLAN interface eth0.10 is attached with interface eth0.Packets received from the outside by eth0. Packet which has tagged with VLAN ID10 will be passed to device eth0.10. On eth0.10, strip off the tags and passed to corresponding machine. On compute node Linux Bridge act as a hub for all tap devices for each VLAN ID.
Controller Node
Tap device: Interface of vm eg: eth0 attached to vm’s
Linux Bridge: It acts as a hub. We can connect multiple interface to Linuxbridge. It transmitted frame coming from one interface to all other interfaces
qdhcp: The dnsmasq process that listens on that interface, to provide DHCP services
Security Groups: Set of IP filter rules that applied in networking of each instance.
Explanation
In Controller node (including Network node) provides DHCP service for each vm’s in the corresponding namespace. Example shows, DHCP gives IP’s to the vm’s included in the same namespace was distinguished by corresponding VLAN ID. In our example, we have used VLAN ID 10 for representing each namespace.
Sample ML2 configuration
Sample configuration Linux Bridge on ML2 plugin.
#/etc/neutron/plugins/ml2/ml2_conf.ini
You can know much about Linux Bridge VLAN, these links may helpful:
https://ask.openstack.org/en/question/59878/neutron-linux-bridge-and-vlans/
http://docs.openstack.org/kilo/config-reference/content/networking-plugin-linuxbridge_agent.html
https://wiki.openstack.org/wiki/Neutron-Linux-Bridge-Plugin
http://robhirschfeld.com/2013/10/16/openstack-neutron-using-linux-bridges-technical-explanation/
VLAN Using Open Virtual Switch (OVS) Mechanism Driver
Open vSwitch is a programmable virtual switch that supports multilayer networks. It is designed to establish effective network automation and virtualization. Currently OVS supporting standard management interfaces and protocols such as NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, GRE, VLAN, VXLAN, double tagged VLAN, Geneve Tunnels etc.
VLAN Implementation on ML2 plugin
We have used ML2 plugin for the implementation VLAN, we must configure both Compute and Controller nodes, If a Network node exists it also. Here, I will try to illustrate basic diagram to how Controller and Compute is configured using OVS VLAN on ML2 plugin. The Physical network of our examples supports VLAN.
Compute Node
Tap device: Interface of vm.
Linux Bridge: It acts as a hub. We can connect multiple interface to Linuxbridge. It transmitted frame coming from one interface to all other interfaces.
br-int: The br-int OVS is the integration bridge. All guest instances in the compute node are connected to this bridge.
br-ex: This bridge provides connectivity to the physical network interface card, eth0.
Security Groups: Set of IP filter rules that applied in networking of each instance.
Explanation
The OVS is responsible for configuring forward rules on br-int and br-ex for VLAN networking. When br-ex receives a frame marked with VLAN ID 100 on the port associated with physical port phy-br-eth1, it modifies the VLAN ID in the frame to 101. Similarly, when br-int receives a frame marked with VLAN ID 100 on the port associated with int-br-eth1, it modifies the VLAN ID in the frame to 10. Then at the veth0.10 port associated with the tap device strip off the tag before passing the frame to the corresponding vm. The figure below shows internal communication between br -ex and br-int.
Controller Node
Tap device: Interface of vm
Linux Bridge: It acts as a hub. We can connect multiple interface to Linuxbridge. It transmitted frame coming from one interface to all other interfaces.
br-int: Thebrin -t OVS is the integration bridge. All guests in compute node are connected to this bridge.
br-ex: This bridge provides connectivity to the physical network interface card, eth0.
qdhcp: The dnsmasq process that listens on that interface, to provide DHCP services.
Security Groups: Set of ip filter rules that applied in networking of each instance.
Explanation
In controller node, packet came from VLAN network receives on eth0 port. OVS responsible for packet flow between br-ex and br-int(Integration bridge). Stripping the tag done same as compute Node. Controller node (including Network node) provides DHCP services for each vm’s in the corresponding namespace.
Sample ML2 configuration
Sample configuration OVS VLAN on ML2 plugin.
#/etc/neutron/plugins/ml2/ml2_conf.ini
You can know much about OVS VLAN, these links may helpful:
http://docs.openstack.org/developer/neutron/devref/openvswitch_agent.html
https://visibilityspots.org/vlan-flat-neutron-provider.html
https://www.rdoproject.org/networking/neutron-with-ovs-and-vlans/
http://techbackground.blogspot.in/2013/07/the-open-vswitch-plugin-with-vlans.html
http://docs.openstack.org/liberty/install-guide-rdo/neutron.html
Conclusion
Both OVS and Linux Bridge have their own advantage and disadvantages. OVS intentionally designed to be compatible with modern switch in chipsets. OVS and Linux bridge, allowing us to take same flexibility and control of the physical infrastructure as virtual infrastructure.
According Rackspace survey Linux Bridge VLAN has more throughput than OVS. They SCP 10G file through network and Linux Bridge VLAN gain Higher throughput than other mechanism driver such as OVS.
While OVS gives more kernel panic than Linux Bridge, because of the compression and encapsulation of packets makes more CPU overhead. OVS gives more network virtualization than Linux Bridge, but it is difficult to troubleshoot in a heavy traffic environment.
In a production environment, we were looking for reliability and stability, easier to troubleshoot, maximum throughput and simplicity makes Linux Bridge VLAN more admin friendly than OVS VLAN.
Reference Links
https://wiki.openstack.org/wiki/Neutron-Linux-Bridge-Pluginhttps://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Cloud_Administrator_Guide/section_networking-scenarios.html
http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/
Posted November 30, 2015 by Jossy Watson