12/10/2017 Openstack Neutron: Introduction Arie Bregman

Openstack Neutron: Introduction

JANUARY 4, 2016 / BREGMAN / 6 COMMENTS

Note: this introduction based on the great presentations: Introduction to OpenStack

Neutron by Assaf Amuller & Virtual Networking in OpenStack: Neutron 101 byMark
McClain and Kyle Mestery. So I highly recommend to watch those. If you dont have
the time or prefer reading, you have it gathered here. Enjoy

Neutron Core Concepts

Neutron three core concepts ( aka core resources) are:

Port A port is a connection point for attaching a single device, such as the NIC of
a virtual server, to a virtual network. The port also describes the associated
network con guration, such as the MAC and IP addresses to be used with this
port.

Network a virtual isolated layer-2 broadcast domain which is typically reserved

to the tenant who created it, unless the network has been explicitly con gured to
be shared.

Subnet A block of IP addresses and associated con guration state. Subnets are
used to allocate IP addresses when new ports are created on a network.

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 1/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

virtual neutron core concepts

The virtual port in the drawing, can be connected to vif port that managed by Nova.

Routers
Neutron allows you to create virtual routers and manage routing using L3 agent that
is is usually installed on the network node. Routing is possible between networks in
your OpenStack environment or between your instances and the external network.

Below, in the drawing you can see there is a virtual router on the network node
making routing possible between Host_A and Host_B to Host_c. The Router has
internal and external network ports. But in order for it to work it will also need to use
NAT and oating IPs.

NAT
Network Address Translation is used for modifying the source or destination IP
address. Whenever your instance is trying to the reach Host_C on the public
network, the NAT protocol will translate your instance IP address from 192.168.1.x
http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 2/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

address to a routable address that can be used outside of OpenStack environment,

on the public network. This process takes place on the Network node, using the
virtual router.

The same goes for Host_C, trying to reach the instances in your tenant.

There several NAT types, but well leave that for anther post =)

Floating IP
Allows public connectivity to your OpenStack instances from the outside. The
internal address of your instances is not known for hosts on the external network
hence, the 192.180.1.2 address cant be used by Host_C to reach Host_A.

To allow such connectivity you would use Floating IP. The oating ip would be
allocated on provider network range. So based on the above drawing, for Host_C to
reach Host_A, it would have to use the address 190.40.10.2.

Types of Network Traf c

Guest/VM data Actual instances traf c ( Green lines in the drawing below ).

External Similar to VM data traf c but with access to the public network (
Orange lines in the drawing below ).

API Access to the API OpenStack services. Services like horizon, neutron, nova,
glace. It should be accessible from public network ( Purple lines in the drawing
below ).

Management Internal communication between services. Services like the

different agents (L3, metadata, dhcp), routers. The communication between
services is done via RPC ( Blue lines in the drawing ).

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 3/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

Network Node
Network node get data moved between networks and to the external world.

Neutron Services & Agents

Neutron deployment in your environments could look similar to this:

neutron-server

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 4/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

It provides the REST API. Normally you would nd it installed on the controller. It
receiving API calls like creating network, delete subnet, delete router and manages
the SQL database accordingly, making the it persistent in the database.

It also uses the Messaging broker ( green circle in the drawing ) to forward
noti cations to the different agents resides on the different nodes over RPC.

One short work ow for example: neutron-server receives API call for creating router
-> Make it persistent in the database -> Forward noti cation message to the L3 agent
that resides on the network node.

PLUGIN is an important component of neutron-server. The plugin can be a monolithic

plugin or modular plugin like ML2 plugin which also includes mechanism drivers for
using variety of technologies. You can nd more information about it later in
dedicated section.

message queue
Used for interaction (messages/noti cations) between services. Common
implementations are qpid, rabbitmq, amqp.

DHCP agent

In charge of IP address allocation. It receives delete/create network noti cations

from neutron server and then it using dsnmasq technology as a dhcp server. When
you boot vm, it will send dhcp request using the guest/vm data network. The request
will reach the network node, speci cally the dnsmasq instace of this network that
will send a reply back to the instance with the IP address.

L3 agent
An extension in neutron. It Receives noti cations from neutron-server to to manage
routers. It resides on the network node. So it manages routing and also oating IPs.

L3 uses linux network namespace. It provides isolated copy of network stack. You get
your own private loopback and the scope is limited to namespace which allows you to

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 5/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

reuse addresses. You can also spawn processes with namespace. You can have
multiple DHCP servers with overlapping IPs.

You can setup HA by using L3 on anther network node with separate namespace and
sync the states between them using vrrp.

L2 agent
L2 agent runs on hypervisor and and communicates with neutron server using RPC.
Normally will be installed on the network and compute nodes. Its main job is to watch
and notify when devices added or removed and to con gure the network on the host
accordingly. It can handle linux bridges, OVS and security group rules.

One common example for its usage would be new created vm with single nic that
must be connected to some network. The actual connection is done by L2 agent that
makes sure it connected to the right network. It also handles OVS ows, Linux
bridges, VLAN tagging and security groups.

OVS L2 agent
Openvswitch L2 agent con gured to work with OVS, using ovsdb. It supports Tenant
Isolation ( VLAN, GRE, VXLAN). The way it works with tunnel networks is that its
actually con gures two bridges on the host and the tunnel networks are con gured
between the hosts. On the host itself it using local vlans to segregate traf c.

Metadata agent
Proxy to nova metadata service. Provides any own information requested by the
instances. for example: IP address, hostname, tenants. Normally installed on network
node.

Neutron Nova Interaction

Here is an example of Neutron-Nova interaction, using simple vm creation work ow:

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 6/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

Tap device virtual device that represents the virtual nic on the virtual machine. It
simulates a link layer device and it used to create linux bridge. You can think of it as a
cable that one end of of it connected to network X and the other end connected to
the virtual nic of the virtual instace.

Plugins
In the previous sections you saw that neutron can handle a variety protocols . It
accomplished by using plugins. Neutron API is pluggable, meaning you can write and
use any plugin you want to use new features and technologies as L2, L3 and QoS for
example. Each plugin implements API differently.

Plugins can be monolithic or modular. Monolithic means they include full

implementation of core resources, allowing you direct control or proxy. An example
for modular plugin would be the popular ML2 which implements v2 API. It delegates
the calls to the different drivers. There are mechanism drivers and type drivers. Types
are types of segmentation like VLAN, gre, vxlan. Mechanism drivers suppose to
ensure that the type driver properly applied given the speci c networking
mechanisms that have been enabled.
http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 7/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

The plugin code of neutron is executed as part of neutron server service. The plugins
are classi ed into two categories coreplugins andservice plugins. Core plugin
implements the core API (port, network, subnet). ML2 is an example to core plugin
which is an integral part of neutron today. It handles a variety of L2 technologies.

L3 (routing) is an example for widely used service plugin. Additional examples of

service plugins you can use are:

Firewall as a service Filter traf c at router level.

VPN as a service Extend your tenant network off-site

Load Balancer as a service Distribute incoming messages to a pool of VMs.

Extensions
Neutron support extensions to the REST API to extend the core resources. Common
extensions are security groups, L3, DHCP, binding. You can access those by using the
url: $serverUrl/v2.0/extensions.

Common Features
The common features that youll nd for every implementation are:

Support for overlapping IPs You could use the same networks for different
tenants

Floating IPs

Metadata con guration

Tenant isolation
Tenant network isolation is achieved by using VLANs or GRE / VXLAN tunnels.
Historically speaking, tunneling was less mature and used to ood broadcast
information to know where the vm is located. Since l2 population implemented, peer
to peer tunnels are now being done in much more intelligent way. This is an important
part of neutron and it will be covered in much more detail on separate post.

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 8/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

Share this:

28

Related

Openstack Neutron: Openstack Neutron: L2 & L3 InfraRed: Deploying and

troubleshooting and solving agents Testing Openstack just made
common problems January 3, 2016 easier!
January 6, 2016 In "Openstack" March 20, 2017
In "Openstack" In "Openstack"

Openstack

AGENT DHCP EXTENSION FLOATING IP L2 L3 NAT NETWORK NODE

NEUTRON NEUTRON-SERVER OPENSTACK PLUGIN TENANT ISOLATION

PREVIOUS POST NEXT POST

Openstack Neutron: L2 & L3 agents Openstack Neutron: troubleshooting and

solving common problems

6 Comments

Vishal
FEBRUARY 8, 2016 AT 2:19 AM

Good, I nd its a great post. I am following your website now.

thanks

REPLY

fulda19d
http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 9/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman
MARCH 15, 2016 AT 12:55 AM

I agree well done! thx man

REPLY

hammad
APRIL 20, 2016 AT 10:40 AM

Great

REPLY

ijaz ahmad khan

JUNE 19, 2016 AT 9:16 AM

Nice overview. Great work.

REPLY

vISHV
SEPTEMBER 26, 2016 AT 4:08 PM

Nice . Thanks a lot!!

REPLY

bhr
MAY 30, 2017 AT 11:43 AM

Hi abregman,

Thanks for such nice explanation. I have one doubt regarding ip allocation to the
vm.

In the diagram, as per step7 neutron server will allocate the ip and inform to dhcp
agent to update dnsmasq about the ip which is contradicting the dhcp agent
de nition In charge of IP address allocation. It receives delete/create network
noti cations from neutron server and then it using dsnmasq technology as a dhcp
server. When you boot vm, it will send dhcp request using the guest/vm data
network. The request will reach the network node, speci cally the dnsmasq

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 10/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

instace of this network that will send a reply back to the instance with the IP
address.

Could you please explain ?

REPLY

Leave a Reply
Your email address will not be published.

Name

Email

Website

Post Comment

Notify me of follow-up comments by email.

Notify me of new posts by email.

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 11/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

Search form SEARCH

RECENT POSTS

Algorithms: Basic Exercises Part 1

Linear Programming: Graphical Method

jQuery Datatable Ajax: Change cells HTML after data is processed

Python: Working with Jinja2 templates

Ajax Datatable: changing row color based on the data

RECENT COMMENTS

Satya on Ansible: write and run your rst playbook

vamshi on Ansible: write and run your rst playbook

Viju on Ansible: write and run your rst playbook

Martin on Python: Objects comparison

Justin C. on Linux: Ulimit And Maximum Number Of Open Files

2017 ARIE BREGMAN UP

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 12/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 13/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 14/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 15/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 16/17
12/10/2017 Openstack Neutron: Introduction Arie Bregman

http://abregman.com/2016/01/04/openstack-neutron-introduction/#more-170 17/17