Download - Open stack networking_101_part-1
© 2011 VMware Inc. All rights reserved
OpenStack Networking Introduction
Yves Fauser, System Engineer VMware NSBU
10/10/2013
2
Agenda
§ Traditional Networking - refresher § OpenStack integrated projects big picture § Why OpenStack Networking is called Neutron now
§ Networking before Neutron § Nova-Networking § Drawbacks of Nova-Networking that led to Neutron
§ OpenStack Networking with Neutron
§ Neutron Overview § Available Plugins § Neutron Demo
§ Neutron – State of the Nation
© 2011 VMware Inc. All rights reserved
Traditional Networking Refresher Traditional Networking Refresher
4
Traditional Networking - Refresher
§ Layer 2 Network Connection à Direct Ethernet connection with no Routing hops (e.g. 192.168.1.10 to 192.168.1.11)
§ Layer 3 Network Connection à Endpoint can reach each other only through multiple routing hops
§ VLAN – A way to carve up a physical switch into multiple L2 Networks (segments)
VLAN 10 VLAN 20
Access Port “untagged”
§ Access Port – An Ethernet Port that can only access one VLAN that is statically configured on the physical switch (no VLAN tag/id – ‘untagged’)
§ Trunk Port – An Ethernet Port that carries multiple VLANs (with VLAN tag/id – ‘untagged’) and connects to other Switches and possibly Hypervisors
VLAN “Trunk” Port / “tagged”
VM VM VM VM Hypervisor
Switch
© 2011 VMware Inc. All rights reserved
OpenStack Projects & Networking
6
Integrated (aka ‘Core’) projects (Grizzly release)
Image repo
(glance)
Object Storage (Swift)
Network (Neutron)
Block Storage (cinder)
Identity (keystone)
Dashboard (horizon)
Provides UI for other projects
Provides Authentication and Service Catalog for other
Projects
Compute (nova)
Provides Images
Stores Images
as Objects
Provides volumes
Provides network
connectivity
7
Why is OpenStack Networking called Neutron?
§ Before June 19th 2013, OpenStack Networking was named “Quantum”, hence all the services, APIs, CLI commands hold the name “Quantum”
§ Unfortunately there were trademark issues with the name “Quantum” (see “Quantum corporation”), therefore all references to “Quantum” need to be changed in all the Docs, Services Names, APIs, CLI Commands, etc.
§ The new name for OpenStack Networking is now Neutron!
© 2011 VMware Inc. All rights reserved
Networking before Neutron Nova-Networking
Drawbacks of Nova-Networking that led to Neutron
9
OpenStack Networking before Neutron
nova-api (OS,EC2,Admin)
nova-console (vnc/vmrc)
nova-compute
Nova DB
nova-scheduler
nova-consoleauth
Hypervisor (KVM, Xen,
etc.)
Queue
nova-cert
Libvirt, XenAPI, etc.
nova-metadata
§ Nova has its own networking service – nova-network. It was used before Neutron
§ Nova-network is still present today, and can be used instead of Neutron
nova-network
nova-volume
Network-Providers (Linux-Bridge or OVS with
brcompat, dnsmasq, IPTables)
Volume-Provider (iSCSI, LVM, etc.)
§ Nova-network does -
§ base L2 network provisioning through Linux Bridge (brctl)
§ IP Address management for Tenants (in SQL DB)
§ configure DHCP and DNS entries in dnsmasq
§ configure fw-policies and NAT in IPTables (nova-compute)
§ Nova-network only knows 3 basic Network-Models;
§ Flat & Flat DHCP – direct bridging of Instance to external eth. Interface with and w/o DHCP
§ VLAN based – Every tenant gets a VLAN, DHCP enabled
Inspired by
10
Nova-Networking – Drawbacks that lead to develop Neutron
§ Nova-Networking is missing an well defined API for consuming networking services (tenant API for defined topologies and addresses)
§ Nova-Networking only allows for the 3 simple models; Flat, Flat/DHCP and VLAN/DHCP, all of those are limited in scale and flexibility – e.g. max. 4094 VLAN ID limit
§ Closed solution; No ability to use network services from 3rd parties and/or to integrate with Network vendors or overcome the limitations of Nova-Network
§ No support for: § Advanced OpenVSwitch features like Network Virtualization
(IP-Tunnels instead of VLANs)
§ Multiple user configurable networks per project
§ User configurable routers (L3 Devices)
© 2011 VMware Inc. All rights reserved
Network Virtualization Overview Network/Server Virtualization Analogy
Network Virtualization – a technical definition
Network Virtualization – Key components
12
Key Concepts – Decouple, Reproduce, Automate
General Purpose Server Hardware
Server Hypervisor Requirement: x86
Virtual Machine
Virtual Machine
Virtual Machine
Application Application Application
x86 Environment
Decoupled
Hardware
Software
Network Hypervisor Requirement: IP Transport
Virtual Network
Virtual Network
Virtual Network
Workload Workload Workload
L2, L3, L4-7 Network Services
General Purpose IP Hardware
13
Network Virtualization – A technical definition
Network virtualization is: § A reproduction of physical networks:
§ Q: Do you have L2 broadcast / multicast, so apps do not need to be modified?
§ Q: Do you have the same visibility and control over network behavior?
§ A fully isolated environment: § Q: Could two tenants decide to use the same RFC 1918 private IP space?
§ Q: Could you clone a network (IPs, MACs, and all) and deploy a second copy?
§ Physical network location independent: § Q: Can two VMs be on the same L2 logical network, while in different physical L2 networks?
§ Q: Can a VM migrate without disrupting its security policies, packet counters, or flow state?
§ Physical network state independent: § Q: Do physical devices need to be updated when a new network/workloads is provisioned?
§ Q: Does the application depend on a feature in the physical switch specific to a vendor?
§ Q: If a physical device died and was replaced, would application details need to be known?
§ Network virtualization is NOT: § Running network functionality in a VM (e.g., Router or Load-balancer VM)
14
What are the key components of network virtualization?!
© 2011 VMware Inc. All rights reserved
OpenStack Networking with Neutron Neutron Overview
Available Plugins
16
OpenStack Neutron – Plugin Concept
Neutron Core API"
Neutron Service""
• L2 network abstraction definition and management, IP address management
• Device and service attachment framework • Does NOT do any actual implementation of
abstraction "
Plugin API"
"Vendor/User Plugin"
• Maps abstraction to implementation on the Network (Overlay e.g. NSX or physical Network) • Makes all decisions about *how* a network is to be implemented • Can provide additional features through API extensions. • Extensions can either be generic (e.g. L3 Router / NAT), or Vendor Specific
"
Neutron API Extention"
Extension API implementation is optional
17
Plugins available in the market (incomplete list)
§ OVS Plugin
§ Supports GRE based Overlays, NAT/Security groups, etc.
§ Linux Bridge Plugin
§ Limited to L2 functionality, L3, floating IPs and provider networks. No support for Overlays
§ VMware NSX (aka Nicira NVP) Plugin
§ Network Virtualization solution with centralized controller + OpenVSwitch (Details follow in the next few slides)
§ Cisco UCS / Nexus 5000 Plugin
§ Provisions VLANs on Nexus 5000 switches and on UCS Fabric-Interconnect as well as UCS B-Series Servers network card (palo adapter)
§ Can use GRE and only configure OVS, but then there’s no VLAN provisioning
§ NEC and Ryu Plugin
§ Openflow Hop-by-Hop implementations with NEC or Ryu controller
§ Other Plugins from Midokura, Juniper (Contrail), Big Switch, Brocade, etc. are in various stages of development (see links below for details)
© 2011 VMware Inc. All rights reserved
Neutron Demo It’s Demo time! … (Sorry, no Connection L)
19
Neutron – State of the Nation – What came with Grizzly
§ Multiple new Plugins: Big Switch, Brocade VCS, Midokura, Hyper-V, Plumgrid, ML2
§ Great Horizon integration (topology map, NIC selection, router mgmt.)
§ LBaaS reference Implementation using HAProxy
§ New Metadata implementation that allows for overlapping IP space
20
Neutron – State of the Nation – What will be in Havana
§ More services integration; § Integrating external Firewalls § More Load-Balancing with external Load-Balancers instead of
HAProxy reference implementation § VPN reference implementation
§ Improved support for
§ IPv6 (feature parity with IPv4), bare metal PXE boot § More and new vendor plugins § Nova-Networking migration options
https://blueprints.launchpad.net/neutron/havana
You can find a recording of this session, as well as the second part (technical Deep Dive) on the OpenStack
Foundation Youtube Channel:
http://www.youtube.com/watch?v=ascEICz_WUY&list=PLKqaoAnDyfgrHcZI2nOlD022p2TG8F2_b
http://www.youtube.com/watch?
v=CRx43Iou1V8&list=PLKqaoAnDyfgrHcZI2nOlD022p2TG8F2_b