This document provides an overview and agenda for a presentation on OpenStack networking. It begins with an overview of OpenStack architecture and services like Compute, Networking, Identity and Image services. It then discusses basic network components like controllers, compute nodes and networking plugins. Next, it covers networking process flows and dives deeper into the Neutron networking plugin, including the Modular Layer 2 plugin framework and drivers like Open vSwitch. It concludes with a planned demonstration of networking functionality in an OpenStack lab environment.

1. 2014.07.12 - KwonSun Bae

2. OpenStack
- Networking
We are Networker ~

3. Agenda
• OpenStack Overview
 Architecture
 Services
 Example Architecture
• Basic Services
 Controller
 Compute
 Network
• Process Flows
• Networking –Neutron
 Neutron Modular Layer 2 (ML2) Plug-in
 ML2 Overview
 ML2 Drivers
 OpenvSwitch Plug-in
 OVS Linux Bridge
 OVS Internals
 OVS Traffic Flows
 OVS Configure
• QnA

4. OpenStack Overview
• Cloud Software

5. Architecture
Docs -
http://docs.openstack.org/icehouse/install-
guide/install/apt/content/ch_overview.html#archit
ecture_conceptual-architecture

6. Services
• Basic Services
• Dashboard – Horizon
• Compute – Nova
• Networking – Neutron
• Identity – Keystone
• Image - Glance
• Optional Services
• Storage
• Swift (Object)
• Cinder (Block)
• Database – Trove
• Orchestration – Heat
• Telemetry – Ceilometer
• Supporting Services
• Database – MySQL
• Message Broker - RabbitMQ

7. Services
• Basic Services
• Dashboard – Horizon
• Compute – Nova
• Networking – Neutron
• Identity – Keystone
• Image - Glance
• Optional Services
• Storage
• Swift (Object)
• Cinder (Block)
• Database – Trove
• Orchestration – Heat
• Telemetry – Ceilometer
• Supporting Services
• Database – MySQL
• Message Broker - RabbitMQ

8. Example
Architecture
Three Nodes Architecture with Neutron.

9. Example
Architecture
Three Nodes Architecture with Neutron.
• Management network. Used for internal
communication between OpenStack
Components.
• Internal network. Used for VM data
communication within the cloud
deployment.
• External network. Used to provide VMs
with Internet access.
• Controller Node: Controller node contains
all OpenStack API services.
• Network Node: Network node contains
DHCP server and virtual routing.
• Compute Node: Network node contains
compute service and neutron plugin

10. Basic Services
• Openstack operation을 위한 필수 Services

11. Supporting
Services
• Database
• MySQL
• 각 Service들의 구성정보 저장
• Message Broker
• RabbitMQ
• 각 Service간의
Message전달,처리
• http://docs.openstack.org/training-
guides/content/module001-ch008-queues-
messaging.html

12. Keystone
For Identity Service.

13. Glance
For Image Provision, Store 등

14. Nova
Virtual Machine Management

15. Nova
The core components of Nova include the
following:
• The nova-api accepts and responds to end-
user compute API calls. It also initiates
most of the orchestration activities (such as
running an instance) as well as enforcing
some policies.
• The nova-compute process is primarily a
worker daemon that creates and
terminates virtual machine instances via
hypervisor APIs (XenAPI for
XenServer/XCP, libvirt for KVM or QEMU,
VMwareAPI for vSphere, etc.).
• The nova-scheduler process is conceptually
the simplest piece of code in OpenStack
Nova: it take a virtual machine instance
request from the queue and determines
where it should run (specifically, which
compute node it should run on).

16. Neutron
• plugin agent (quantum-*-agent):Runs
on each hypervisor to perform local
vswitch configuration. Agent to be run
depends on which plugin you are using,
as some plugins do not require an agent.
• dhcp agent (quantum-dhcp-
agent):Provides DHCP services to
tenant networks. This agent is the same
across all plugins.
• l3 agent (quantum-l3-agent):Provides
L3/NAT forwarding to provide external
network access for VMs on tenant
networks. This agent is the same across
all plugins.

17. Neutron
Use Case: Per-tenant Routers with Private
Networks
A more advanced router scenario in which
each tenant gets at least one router, and
potentially has access to the OpenStack
Networking API to create additional routers.
The tenant can create their own networks,
potentially uplinking those networks to a
router. This model enables tenant-defined
multi-tier applications, with each tier being
a separate network behind the router. Since
there are multiple routers, tenant subnets
can be overlapping without conflicting,
since access to external networks all
happens via SNAT or Floating IPs. Each
router uplink and floating IP is allocated
from the external network subnet.

18. Process Flows

19. AMQP
AMQP is the messaging technology chosen by the
OpenStack cloud. The AMQP broker, either
RabbitMQ or Qpid, sits between any two Nova
components and allows them to communicate in a
loosely coupled fashion. More precisely, Nova
components (the compute fabric of OpenStack) use
Remote Procedure Calls (RPC hereinafter) to
communicate to one another; however such a
paradigm is built atop the publish/subscribe
paradigm so that the following benefits can be
achieved:
• Decoupling between client and servant (such as
the client does not need to know where the
servant reference is).
• Full a-synchronism between client and servant
(such as the client does not need the servant to
run at the same time of the remote call).
• Random balancing of remote calls (such as if
more servants are up and running, one-way
calls are transparently dispatched to the first
available servant).

20. Networking
- Neutron

21. Neutron
ModularLayer 2
Plug-in (ML2)
http://docs.openstack.org/trunk/config
-reference/content/networking-options-
plugins-ml2.html
DRAFT - Document for Juno
Original Goal
• 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 datacenters.

22. ML2 “Drivers”
ML2 exposes two different types of drivers:
“Type” and “Mechanism”
ML2 Type Drivers:
• Maintain type-specific state
Provide tenant network allocation
Validate provider networks
Current TypeDrivers:
local, flat, VLAN, GRE, and VXLAN
ML2 Mechanism Drivers:
• Responsible for taking information sup
plied by TypeDrivers and ensuring it is
properly applied given the specific netw
orking mechanisms which have been en
abled
Current MechanismDrivers:
Arista, Cisco Nexus, Hyper-V, L2 Popula
tion, LinuxBridge, Open vSwitch, Tail-F
NCS

23. Agenda
• OpenStack Overview
 Architecture
 Services
 Example Architecture
• Basic Services
 Controller
 Compute
 Network
• Process Flows
• Networking –Neutron
 Neutron Modular Layer 2 (ML2) Plug-in
 ML2 Overview
 ML2 Drivers
 OpenvSwitch Plug-in
 OVS Linux Bridge
 OVS Internals
 OVS Traffic Flows
 OVS Configure
• QnA

24. OpenvSwitch
Linux Bridge
http://www.slideshare.net/rajdeep/ope
nvswitch-deep-dive
VM – OVS Connection

25. OVS
Internals
각각의 bridge들은 bridge별 ovs demon
을 소유

26. OVS
Traffic Flows
Compute Node to Network Node
L3-agent
• SNAT
• Floating IP Create
DHCP-agent
• Subnet based Dynamic IP Lease
• Each Subnet’s Gateway

27. Neutron
- Demo

28. Lab Overview
OpenStack installed on vSphere
• 1 Hosts
3 Node Install
• Controller
• Network
• Compute
향후 추가계획
• 호스트B 에 Compute node 추가
• 다른 Plug-in Test
• Nova – vSphere 연동
Bebe's Lab Topology

29. Lab Access and
Demo
Demo Scenario
• L3-Agent(Router) Create
• Network Create
• Network Subnet Create
• L3-Agent connect with Interfaces
• Gateway Network connect
• Instance attach
• Floating IP Create
• Floating IP Associate
• Ping Test
http://docs.openstack.org/admin-
guide-cloud/content/l3_workflow.html

30. QnA