Downloaded 96 times
Uploaded byCynthia Thomas
From Nova-Network to Neutron and Beyond: A Look at OpenStack Networking
This document provides an overview of the evolution of network virtualization and OpenStack networking. It describes how networking started with manually configured VLANs, moved to OpenFlow which required programming flows, and then to network overlays using software defined networking. It outlines the requirements for network virtualization. It also details the evolution of OpenStack networking from Nova network to Quantum/Neutron, including the transition to using overlays and supporting plugins. Key features of Neutron are summarized, as well as upcoming features planned for future OpenStack releases.
More Related Content
Similar to From Nova-Network to Neutron and Beyond: A Look at OpenStack Networking
![[OpenStack Day in Korea 2015] Track 3-6 - Archiectural Overview of the Open S...](https://cdn.slidesharecdn.com/ss_thumbnails/36-150213070342-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
From Nova-Network to Neutron and Beyond: A Look at OpenStack Networking
- 1. From Nova-‐Network to Neutron and Beyond: A Look at OpenStack Networking OpenStack LA MeetUp August 2014
- 2. Agenda ▪ Network VirtualizaFon Requirements ▪ Brief Overview of OpenStack ▪ EvoluFon of Neutron Networking ▪ Midokura Use Cases and Futures for NV 1
- 3. 2 Network Virtualization Requirements#
- 4. What is NetworkVirtualization (NV)? 3 Taking logical (virtual) networks and services, and decoupling them from the underlying network hardware. Well suited for highly virtualized environments. Any Application Virtual Networks Any Cloud Management Platform MidoNet VirtualizaFon PlaMorm Distributed Firewall Logical L2 Existing Network Hardware service Distributed Load Balancer ser Distributed VPN Service Logical L3 KVM, ESXi, Xen LXC
- 5. Requirements for NV 4 Requirements 4 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network
- 6. Requirements for NV 5 Requirements 5 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Isolated tenant networks (virtual data center)
- 7. Requirements for NV 6 Requirements 6 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 L3 Isolation (similar to VPC and VRF) Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network
- 8. Requirements for NV Redundant, optimized, and fault tolerant paths to to/ from external networks (e.g. via eBGP) 7 Requirements 7 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Fault-tolerant devices and links
- 9. Requirements for NV 8 8 Tenant/Project A Network A1 VM1 VM3 Network A2 VM5 Tenant/Project B Network B1 VM2 VM4 uplink Provider Virtual Router (L3) Tenant A Virtual Router Tenant B Virtual Router VM6 Virtual L2 Switch B1 Virtual L2 Switch A1 Virtual L2 Switch A2 TenantB office Tenant B VPN Router Office Network Fault-tolerant devices and links Fault tolerant devices and links
- 10. Requirements for NV 9 Device-agnostic networking services: • Load Balancing • Firewalls • Stateful NAT • VPN Networks and services must be fault tolerant and scalable
- 11. Requirements for NV 10 Single pane of glass to manage it all.
- 12. Bonus Requirements forNV 11 Integration with cloud or virtualization management systems. Optimize network by exploiting management configuration. Single virtual hop for networking services Fully distributed control plane (ARP, DHCP, ICMP)
- 13. Checklist for NetworkVirtualization 12 q Multi-tenancy q Scalable, fault-tolerant devices (or device-agnostic network services). q L2 isolation q L3 routing isolation • VPC • Like VRF (virtual routing and fwd-ing) q Scalable gateways q Scalable control plane • ARP, DHCP, ICMP q Floating/Elastic Ips q Stateful NAT • Port masquerading • DNAT q ACLs q Stateful (L4) Firewalls • Security Groups q Load Balancing with health checks q Single Pane of Glass (API, CLI, GUI) q Integration with management platforms • OpenStack, CloudStack • vSphere, RHEV, System Center q Decoupled from Physical Network
- 14. Evolution of NetworkVirtualization 13 INNOVATION IN NETWORKING AGILITY VLAN APPROACH Manual End-to-End VLAN configured on physical switches • Static • Manual • Complex • Tenant state maintained in physical network 13
- 15. Using VLANs forNV 14 q Multi-tenancy q Scalable, fault-tolerant devices (or device-agnostic network services). ü L2 isolation q L3 routing isolation • VPC • Like VRF (virtual routing and fwd-ing) q Scalable gateways q Scalable control plane • ARP, DHCP, ICMP q Floating/Elastic IPs q Stateful NAT • Port masquerading • DNAT q ACLs q Stateful (L4) Firewalls • Security Groups q Load Balancing with health checks q Single Pane of Glass (API, CLI, GUI) q Integration with management platforms • OpenStack, CloudStack • vSphere, RHEV, System Center q Decoupled from Physical Network
- 16. Evolution of NetworkVirtualization 15 INNOVATION IN NETWORKING AGILITY OPENFLOW REACTIVE APPOACH Reactive End-to-End Requires programming of flows • Limited scalability • Hard to manage • Impact to performance • Still requires tenant state in physical network VLAN APPROACH Manual End-to-End VLAN configured on physical switches • Static • Manual • Complex • Tenant state maintained in physical network 15
- 17. What is OpenFlow? 16 A communication protocol that gives access to the forwarding plane of a network switch over the network.
- 18. What is OpenFlow? 17 A centralized remote controller decides the path of packets through the switches
- 19. Using OpenFlow forNV 18 ü Multi-tenancy q Scalable, fault-tolerant devices (or device-agnostic network services). ü L2 isolation △ L3 routing isolation • VPC • Like VRF (virtual routing and fwd-ing) q Scalable gateways q Scalable control plane • ARP, DHCP, ICMP q Floating/Elastic IPs q Stateful NAT • Port masquerading • DNAT q ACLs q Stateful (L4) Firewalls • Security Groups q Load Balancing with health checks △ Single Pane of Glass (API, CLI, GUI) △ Integration with management platforms • OpenStack, CloudStack • vSphere, RHEV, System Center q Decoupled from Physical Network
- 20. Evolution of NetworkVirtualization 19 PROACTIVE INNOVATION IN NETWORKING AGILITY SOFTWARE OVERLAY Virtual Network Overlays Decoupling hardware and software • Cloud-ready agility • Unlimited scalability • Open, standards-based • No impact to physical network OPENFLOW REACTIVE APPOACH Reactive End-to-End Requires programming of flows • Limited scalability • Hard to manage • Impact to performance • Still requires tenant state in physical network VLAN APPROACH Manual End-to-End VLAN configured on physical switches • Static • Manual • Complex • Tenant state maintained in physical network 19
- 21. 20 How dooverlays achieve real network virtualization?
- 22. 21 Encapsulation andTunneling Provides isolation
- 23. 22 Stateless core.Stateful edge.
- 24. 23 Network processingat the edge Decoupled from the physical network
- 25. 24 Virtual networkchanges don’t affect the physical network
- 26. 25 Single virtualhop network services avoid “traffic trombones”
- 27. 26 Centralized stateand control for maximum agility
- 28. 27 Scalable, faulttolerant gateways to external networks
- 29. Using Overlays forNV 28 ü Multi-tenancy ü Scalable, fault-tolerant devices (or device-agnostic network services). ü L2 isolation ü L3 routing isolation • VPC • Like VRF (virtual routing and fwd-ing) ü Scalable Gateways ü Scalable control plane • ARP, DHCP, ICMP ü Floating/Elastic IPs ü Stateful NAT • Port masquerading • DNAT ü ACLs ü Stateful (L4) Firewalls • Security Groups ü Load Balancing with health checks ü Single Pane of Glass (API, CLI, GUI) ü Integration with management platforms • OpenStack, CloudStack • vSphere, RHEV, System Center ü Decoupled from Physical Network
- 30. 29 Sounds great,but when will it be a reality?
- 31. Network Virtualization OverlaysToday 30
- 32.
- 33.
- 34. OpenStack Releases # Release schedule: time-based scheme with major release ~ every 6 months# Codenames are alphabetical: # # • Austin: The first design summit took place in Austin, TX# • Bexar: The second design summit took place in San Antonio, TX (Bexar county).# • Cactus: Cactus is a city in Texas# • Diablo: Diablo is a city in the bay area near Santa Clara, CA# • Essex: Essex is a city near Boston, MA# • Folsom: Folsom is a city near San Francisco, CA# • Grizzly: Grizzly is an element of the state flag of California (design summit takes 33 place in San Diego, CA)# • Havana: Havana is an unincorporated community in Oregon# • Icehouse: Ice House is a street in Hong Kong# • Juno: Juno is a locality in Georgia# • Kilo: Paris (Sèvres, actually, but that's close enough) is home to the Kilogram, the only remaining SI unit tied to an artifact#
- 35. 34 Before Neutron: Nova Networking • Nova-Networking was the only option in OpenStack prior to Quantum/Neutron# • Original method from A release • No IPv6 in first release but eventually introduced# • Still available today as an alternative to Neutron, but will be phased out# # Options Available within nova-networking initially: • Only Flat • Flat DHCP # Limitations • No flexibility with topologies (no 3-tier) • Tenants can’t create/manage L3 Routers • Scaling limitations (L2 domain)# • No 3rd party vendors supported • Complex HA model#
- 36. 35 Nova-‐network slightly evolves Introduced VLAN DHCP mode Improvements: • L2 Isolation – each project gets a VLAN assigned to it # Limitations • Need to pre-configure VLANs on physical network • Scaling Limitations - VLANs • No L3 • No 3-tier topologies • No 3rd party vendors
- 37. 36 Nova-‐network slightly evolves C & D Releases had two general categories: • Flat Networking# • VLAN Networking# # Limitations • Need to pre-configure VLANs on physical network • Scaling Limitations - VLANs • No L3# • No 3-tier topologies • No 3rd party vendors#
- 38. Quantum 37 OpenStackNetworking branches out of the Nova project! ! • Tech Preview of Quantum appeared in D release# # • Brought ability to have a multi-tiered network, with isolated network segments for various applications or customers# • Quantum-server allowed for Python daemon to expose the OpenStack Networking API and passes requests to 3rd party plugins# • Officially released in Folsom Release#
- 39. Introducing Neutron 38 • Name Change from Quantum to Neutron was announced in April 2013# • Legal Agreement to phase out code name “Quantum” due to trademark of Quantum Corporation# OpenStack Networking as a First Class Service! • Pluggable Architecture • Standard API • Many choices# # Plugins Available! • MidoNet! • OVS Plugin • Linux Bridges • Flat DHCP • VLAN DHCP# • ML2# • More Services (LBaaS, VPNaaS) • Flexible network topologies# • NSX • Plumgrid# • Nuage# • Contrail • Ryu#
- 40. Evolution of Neutron 39 Release Name Release Date Included Components AusFn 21 October 2010 Nova, SwiZ Bexar 3 February 2011 Nova, Glance, SwiZ Cactus 15 April 2011 Nova, Glance, SwiZ Diablo 22 September 2011 Nova, Glance, SwiZ Essex 5 April 2012 Nova, Glance, SwiZ, Horizon, Keystone Folsom 27 September 2012 Nova, Glance, SwiZ, Horizon, Keystone, Quantum, Cinder Grizzly 4 April 2013 Nova, Glance, SwiZ, Horizon, Keystone, Quantum, Cinder Havana 17 October 2013 Nova, Glance, SwiZ, Horizon, Keystone, Neutron, Cinder Icehouse April 2014 Nova, Glance, SwiZ, Horizon, Keystone, Neutron, Cinder
- 41. Latest Neutron Features 40 Havana Release Brought:! • LBaaS: shipped an updated API and HAProxy driver support# • VPNaaS: VPN API supports IPSec and L3 agent ships with an OpenSwan driver# • FWaaS: enables tenant to configure security at the edge via the firewall API and on the VIF via the security group API# • New plug-in Modular Layer 2 (ML2): ML2 plugin supports local, flat, VLAN, GRE and VXLAN network types via a type drivers and different mechanism drivers # Icehouse Release:! • New vendor plugins, LBaaS drivers and VPNaaS drivers# • OVS plugin and Linux Bridge plugin are deprecated: The ML2 plugin combines OVS and Linux Bridge support into one plugin# • Neutron team has extended support for legacy Quantum configuration file options for one more release#
- 42. Upcoming Neutron Features 41 Expectations for Juno:! # • Provide Distributed Virtual Routing (DVR) functionality: Define API to create and deploy DVRs to improve the performance# • Group-based Policy Abstractions for Neutron: API extensions for easier consumption of the networking resources by separate organizations and management systems# • IPv6 advancements: # • Add RADVD to namespace to handle RAs, # • Stateful and stateless DHCP for IPv6# • LBaaS new API driver and object model improvement for complex cases# • Quotas extension support in MidoNet plugin# • Incubator system: # • Instead of only using the summit for developing new features, features can be developed and gestate over time#
- 43.
- 44. 43 MidoNet Network VirtualizaFon PlaMorm Logical L2 Switching -‐ L2 isolaFon and path opFmizaFon with distributed virtual switching Interconnect with VLAN enabled network via L2 Gateway Logical L3 RouFng – L3 isolaFon and rouFng between virtual networks No need to exit the soZware container -‐ no hardware required Distributed Firewall – Provides ACLs, high performance kernel integrated firewall via a flexible rule chain system Logical Layer 4 Load Balancer – Provides applicaFon load balancing in soZware form -‐ no need for hardware based firewalls VxLAN/GRE – Provides VxLAN and GRE tunneling Provides L2 connecFvity across L3 transport. This is useful when L2 fabric doesn’t reach all the way from the racks hosFng the VMs to the physical L2 segment of interest. MidoNet/Neutron API– Alignment with OpenStack Neutron’s API for integraFon into compaFble cloud management soZware Any Application OpenStack/Cloud Management System MidoNet Network VirtualizaFon PlaMorm v Distributed Firewall Layer 4 Load Balancer Logical L2 Logical L3 Any Network Hardware VxLAN/GRE Any Hypervisor NAT MidoNet / Neutron API NAT – Provides Dynamic NAT, Port masquerading
- 45. OpenStack IntegraFon 5 Easy integraFon with OpenStack: MidoNet provides a plugin for Neutron. MidoNet Plugin
- 46.
- 47. Use Cases Automated Provisioning Isolated Sandboxes Enhanced Security Enable Compliance Scale out L3 Gateway Bridge legacy VLANs Do it Faster Do it Bigger Val u e Agility Provide rapid provisioning of isolated network infrastructure for labs and devops. Logical Network Provisioning Control Network admins can better secure, control & view network traffic. Single Pane of Glass OpsTools Do it Better IaaS Cloud Build multi-tenant clouds with visibility into usage. Tenant Control Automated Self Service Metering Performance Improve network performance using edge overlay & complementary technologies. Single Hop Virtual Networking VXLAN Hardware Gateway Massive performance with 40Gb Support Scale Add virtual network infra & services simply & resiliently without hardware & bottlenecks. Distributed Logical Networking FW, LB, L2/3, NAT Limitless “VLANs” IPv6 Solution for OpenStack Networking Use MN to overcome limitations of Neutron for OpenStack users. Replaces OVS Plugin
- 48. 47 So what’snext for Network Virtualization?
- 49. 48 Get moreout of the physical network.
- 50. 49 Network Virtualization decouples the logical network from the physical network.
- 51. NVOs can’t ignorethe physical network 50 Dynamic changes to logical network are not dependent on the physical network configuration. Sharing state to and from the physical network can be supplementary. - Monitoring - Traffic Engineering
- 52. 51 Get moreintelligence out of your network
- 53. NVOs provide awealth of information 52 NVOs centralize information on your network We can start taking advantage of this information - Security - Compliance - Optimizing Networks
- 54. 53 Bridge physicaland virtual networks more efficiently
- 55. Midokura VTEP Solution 54 IP Fabric MidoNet MidoNet Virtual Any Cloud Management PlaLorm MidoNet Network State Database VM VM VM VM VM VM OVSDBc Server Storage Services Physical VM VM VTEP TCP/IP OVSDB VxLAN Tunnel Physical Connection Key OVSDBs
- 56. 55 Break throughperformance barriers of software networking
- 57. Performance 40Gb VxLAN Offloading: virtualized environments require high throughput infrastructure • IntegraFon with Mellanox provides 40 Gbps saturaFon • VxLAN offloading improves CPU uFlizaFon levels • Scale with performance through HW interconnect • Increase throughput with offloading where no offloading would otherwise have flat results • High bandwidth can now be achieved in soZware
- 58.
- 59. 58 MidoNet Advantages # Check out our blog: hkp://blog.midokura.com/ Follow us on Twiker: @midokura
- 60. Thank You CynthiaThomas @_techcet_ 59
Editor's Notes
- #34 Cloud platform launched 4 years ago by NASA and Rackspace It’s an open source cloud orchestration tool, with the main pillars being compute, storage, and networking (called Nova, Swift or Cinder, and Neutron for networking) - Used to deploy large-scale private or public clouds while leveraging the support of the open source community - Today we’ll be focusing on Neutron networking solutions
- #36 So focusing on networking within OpenStack, OpenStack networking has evolved since its original release. - It was originally just a flat network: no VLANs nor IP routing. Just a big broadcast domain.
- #37 Then Nova-networking slightly evolved by providing isolated L2 networks with DHCP, but it still required VLANs configured on the physical network.
- #38 Then Nova-networking slightly evolved by providing isolated L2 networks with DHCP, but it still required VLANs configured on the physical network.
- #39 Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet
- #40 Neutron was a re-architecture to a more modular design - became a core project in Folsom release, we’re now on the Icehouse release. OVS is the most deployed plugin according to the latest user survey, so we’ll cover this one along with MidoNet