Networking in Openstack - Neutron 101

Networking in Openstack - Neutron 101
Mochamad Taufik Romdony
Cloud Network & Datacenter Engineer
Openstack Indonesia - Meetup #6
Bandung, 2019::10:26

Agenda
• History of cloud computing
• Openstack Introduction
• About Openstack
• Openstack Core Service
• Openstack Neutron
• Neutron Architecture
• Neutron plugin & service

The History of cloud computing
Openstack Indonesia Meetup #6
Bandung, 26/10/2019

The History of cloud computing
1950
Mainframe
1969
J.C.R.
Licklider
developed the
ARPANET
1970
IBM
released
VMs
1960
John McCarthy,
Douglas Parkhill
“idea of time-
sharing
computing”
1980 - 1990
● Apple launches Macintosh,
Microsoft launches Windows
● FOSS, GNU/Linux
● CERN launches WWW
● Web hosting service provider
began intern infrastructure
2006
AWS launches
S3 & EC2
1999 - 2005 Server Virtualization
- 1999, VMware introduced the x86 virtualization
- 2000, Xen the open-source x86 hypervisor,
- 2005, Intel released two models of Pentium 4 as
the first Intel processors to support VT-x
- 2007, the Kernel-based Virtual Machine (KVM)
hypervisor created included in the Linux kernel
2010
Rackspace Hosting and NASA, launched the
open source cloud initiative OpenStack
Now
Public cloud, big data, machine learning, IOT,
software defined everything and more

Openstack Introduction
Bandung, 26/10/2019

Openstack History
https://www.nasa.gov/home/hqnews/2010/jul/HQ_10-172_Nebula_Initiative.html

What is Openstack?
OpenStack is a cloud operating system that
controls large pools of compute, storage,
and networking resources throughout a
datacenter, all managed and provisioned
through APIs with common authentication
mechanisms.

Openstack Landscape
OpenStack is broken
up into services to
allow you to plug and
play components
depending on your
needs. The openstack
map gives you an “at
a glance” view of the
openstack landscape
to see where those
services fit and how
they can work
together

Network as a service in Openstack
Bandung, 26/10/2019

History of Openstack Networking
● In the first openstack release Austin (Oct 2010) the
networking functionality was hard-coded into Nova
● Networking and compute features could not be updated
independently
● Quantum was added as a separate networking service as
part of the Folsom (Sept 2012) release
● The name of networking project was changed to Neutron
as part Havana (Oct 2013) release
● The name change was due to a trademark conflict
● With Neutron, Networking became modular and could
evolve independently

What is Neutron?
● Neutron is networking-as-a-service project in openstack
● Neutron has a server component running on the controller
node
● Neutron has a set of APIs, Plugins, SQL DB and
authentication software
● Neutron has several distributed agent programs
● Neutron enables network devices and technologies to
work together in IaaS environment

Neutron Configuration Overview
Virtual Router
Floating IP/SNAT
Virtual L2 Network
Virtual Subnet
Virtual Port
Virtual Interface
(VIF)
Virtual Server
Namespace

Basic functions of Neutron
● L2 network
Create L2 network between multiple Nova
Compute
● L3 network
Virtual network routing, external network
connection, SNAT, Floating IP
● DHCP server
DHCP server that assigns IP addresses to
virtual machines
● Metadata
Acts as a proxy for the metadata server

Basic functions of Neutron - Cont
● L2 network
Create L2 network between multiple Nova
Compute
● L3 network
Virtual network routing, external network
connection, SNAT, Floating IP
● DHCP server
DHCP server that assigns IP addresses to
virtual machines
● Metadata
Acts as a proxy for the metadata server

Type of Network Traffic
● Management
Internal communication
between services
● API
Exposes Openstack APIs
to users of the cloud
● Guest
A network dedicated to
instance traffic
● External
Provides neutron routers
with network access

Neutron Plugin
● Open vSwitch Plugin
● Cisco UCS/Nexus Plugin
● Cisco Nexus1000v Plugin
● Linux Bridge Plugin
● Modular Layer 2 Plugin (ML2 Plugin)
● Nicira Network Virtualization Platform (NVP) Plugin
● Ryu OpenFlow Controller Plugin
● NEC OpenFlow Plugin
● Big Switch Controller Plugin
● Brocade Neutron Plugin Brocade Neutron Plugin
● Cloudbase Hyper-V Plugin
● OpenContrail/Tungsten Fabric Plugin
● Nuage Networks Plugin
● CPLANE NETWORKS CPLANE NETWORKS
● IBM SDN-VE Plugin
● Embrane Neutron Plugin
● Mellanox Neutron Plugin Mellanox Neutron Plugin
● PLUMgrid Plugin

ML2 Plugin
Bandung, 26/10/2019

What is ML2 Plugin?
The Modular Layer 2 (ml2) plugin
is a framework allowing
OpenStack Networking to
simultaneously utilize the variety of
layer 2 networking technologies
found in complex real-world data
centers.

Neutron ML2 Plugin
● Type Driver
○ Flat
○ VLAN
○ GRE
○ VXLAN
● Mechanism Driver
○ Open vSwitch
○ Linux Bridge
○ L2 Population
○ Specialized (opensource &
vendor)
ML2 Plugin
Type drivers Mechanism drivers
F
L
A
T
V
L
A
N
V
X
L
A
N
G
R
E
OpenvSwitch
LinuxBridge
L2Population
Specialized

Neutron ML2 Plugin - Cont
● Type Driver : which tells it what type of L2 technology to use when implementing the networking. For
example, there is an option of using VLANs, VXLAN, or GRE Tunneling
○ Local: A local network is a network that can only be realized on a single host. This is only used in proof-
of-concept or development environments, because just about any other OpenStack environment will
have multiple compute hosts and/or a separate network host
○ Flat: A flat network is a network that does not provide any segmentation options. A traditional L2
ethernet network is a "flat" network. Any servers attached to this network are able to see the same
broadcast traffic and can contact each other without requiring a router. flat networks are often used to
attach Nova servers to an existing L2 network (this is called a "provider network")
○ VLAN: In a VLAN network, tenants are separated because each is assigned to a VLAN. In OpenVSwitch
plugin (or ML2 with OVS driver), OVS will in the virtual switches allocate an internal VLAN for each
tenant
○ GRE: GRE tunnels encapsulate isolated layer 2 network traffic in IP packets that are routed between
compute and networking nodes using the hosts' network connectivity and routing tables
○ VXLAN: gre and vxlan networks are very similar. They are both "overylay" networks that work by
encapsulating network traffic. Like vlan networks, each network you create receives a unique tunnel id
● Mechanism Driver: which specifies what driver to use to implement the technology. You can use the
default Open vSwitch driver (which is what we will cover).

Process of Instance creation
1
Sending
API
Request
2
Authentication
request
3
Authentication ACK & validates if
provided data is correct
4
6
5
Update DB
7
Select compute host
8
Update DB
9
Request glance
image
11 Create port (Mac - iP)
10
Glance image
download
12 Notify L2 agent
13 Configure local VLAN and Flows
14 send port up notification (RPC: L2 agent to neutron)
15 port up (RPC: Neutron to NOVA)
16 Instance Booted
L2 Agent
Openstack Nova compute
Openstack glance API
Openstack glance registry
Neutron Server
Neutron L3 Agent
Neutron DHCP agent

Network Troubleshooting
Bandung, 26/10/2019

Debugging network issues
● ip a shows status of all physical and virtual devices
● ovs-vsctl show shows interfaces and bridges in thevirtual switch
● ovs-dpctl show shows datapaths on the switch
● Tcp dump
○ tcpdump -n -i <interface> -w <filename>
○ Set interface to vnet device, instance eth0, bridge device, or host ethernet
device to see where packets are not getting through
○ -i any for all interfaces
● iptables -L to check iptables rules
● ip netns list – lists all known network namespaces
● ip netns exec <namespace id> route -n
○ Shows routing table inside specific namespace
○ Execute arbitrary commands (incl. ssh, ping)

Debugging networking issues: DHCP
Scenario: Instance is not getting IP address
Step 1: nova console-log <instance name>, DHCP request sent, no reply received
Step 2: Verify neutron-dhcp-agent is running
Step 3: Check host logs (/var/log/messages and
/var/log/neutron/*)
Step 4: If host is not seeing DHCP traffic: tcpdump -i
all | grep -i dhcp

Debugging networking issues:
Access/routingScenario: I can't SSH into an instance
Step 1: Security groups: port 22 TCP & all ICMP
allowed?
Step 2: Is floating IP address routable from client?
● route -n on client
● Verify that public subnet in OpenStack is accessible from client (eg. for local
LAN, that it matches 192.168.0.0/24)
Step 3: Bridges OK?

Closing
Doing nothing at all vs. making very small consistent efforts

Networking in Openstack - Neutron 101

Networking in Openstack - Neutron 101

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Networking in Openstack - Neutron 101

Semelhante a Networking in Openstack - Neutron 101 (20)

Último

Último (20)

Networking in Openstack - Neutron 101