OpenStack Summit May 2014 Atlanta

This panel will bring together a group of industry and thought leaders to look back on where OpenStack Neutron has gone and discuss networking can evolve in the future. The panel will explore topics such as:

• Neutron vs Nova network
• Support for new APIs and policy models
• Requirements for network services
• Interactions with Open Daylight
• Network operational requirements

Panelists will include:

* Kyle Mestery - Neutron Core and Principal Engineer at Cisco

* Chris Wright - Red Hat SDN Team leader

* Dan Conde - Director of Products at Midokura

* Nils Swart - Director of Business Development and Strategy at Plexxi

It is rather well known that Neutron comes with a built-in networking backend made of several agents which interact with the ML2 plugin. They are:

• The Openvswitch and Linuxbridge agents, which manage L2 connectivity
• The DHCP agent, which is responsible for managing IP leases
• The L3 agent, which takes care of L3 forwarding, Source NAT for externally-bound traffic and Floating IPs
• The metadata agent, which connects Neutron networks to the Nova metadata server
• And last but not least, the agents for managing advanced services such as Load Balancing, Firewalling, and VPN

However, the choice of Open Source solution which can be used as a Neutron backend is actually wider; deployers are therefore able to choose the backend which better fits their architectural model. The aim of this talk is therefore to

• explore these backends, and briefly look at their capabilities and architecture
• analyze how they integrate with Neutron, and how they mix & match with the various neutron agents
• see them in action (*) and discuss pro and cons

This talk will look at both backends which are in the Neutron source code tree and backends which are not yet there (**)
(*) at least some of them as the allocated time slot would hardly allow for showing all
(**) support for some backends such as ODL and OpenContrail is currently under review and might or might not be merged by the time of the summit.

Neutron provides a rich set of logical constructs to develop a full featured virtual network deployment. In this talk, we will dive into a basic Neutron setup and examine the role and architecture of each functional component. Additionally, the interactions between components will be examined to give new code contributors and/or operators insights into how the component communicate.

OpenDaylight is an open platform for network programmability to enable SDN and create a solid foundation for NFV for networks at any size and scale. OpenDaylight is licensed under the Eclipse Public License, and recently had its first release, code-named Hydrogen. The OpenDaylight and OpenStack Neutron teams have collaborated to integrate the two projects such that OpenDaylight can provide virtual tenant networking for OpenStack tenants. This talk will show you how to use OpenDaylight with OpenStack, including setup and debug of the environment. We will walk through technical details of the implementation and show examples of the benefits of using OpenDaylight to scale virtual tenant networks with OpenStack Neutron. Additionallly, we will cover future directions of OpenDaylight integration with OpenStack Neutron. Attendees will leave this session with a clear understanding of how OpenDaylight integrates with OpenStack Neutron to provide virtual networks for OpenStack tenants.

To provide public connectivity to virtual machines, you can install the Neutron L3 Agent which aims to connect your VM to external networks (Internet for example) through virtual routers and also connect VM between internal private networks.


Also, your VMs could be reachable from outside by using floating IP, thanks to NAT process to reach the VM. The L3 Agent was multi-node ready from Grizzly release, but if you lost an L3 agent node, you also lost virtual routers and then the external connectivity for virtual machines.
Until Icehouse, there was not proper way to bring L3 connectivity highly available without losing the agent scalability.


This talk will provide a view of the work which has been made on the L3 agent and the virtual routers during the last release regarding to the high availability. The High Availability of the L3 agent will ensure there will be no downtime between external and internal networks and between internal networks connectivity, even with the lost of one or more l3 nodes.
We will also see the new features that could be brought in the next release, which will improve routing scalability, especially for the east-west traffic.

Many folks find they way Neutron builds virtual networks a mystery. For those of us who have set up OpenStack and created a virtual machine that didn't get an IP or couldn't communicate out its network interface, this session will be for you.

In this session we will look at many of the tools available in Linux that can be used to troubleshoot problems in Neutron networking. We will then use the tools to troubleshoot a real world problem, communicating with a VM by tracing the packet flow through a Neutron-created network until we find a repair the problem. Come and be ready to learn the secrets of working on software-defined networks.

Title :
Software Defined Networking Performance and Architecture Evaluation
Presenters :
Brian Chong
Audience :
Cloud/Network Architects that are using a Overlay Model to create their Virtualized Network Fabrics
Objective :
This presentation will cover architectural and performance characteristics of what a Overlay network is compared to a straight VLAN based environment on a cluster size of 100+ nodes.

Over the last 3 months, Symantec has run extensive performance and diagnostics tests across multiple overlay providers as well as against the base Neutron VLAN configurations and have come to several insights into CPU penalities, Network design issues at scale as well as performance comparisons using different encapslation techniques.

We will explain what our architectural design was, the results of our testing as well as our design insights into how Symantec’s cloud will be affected by the outcome of the evaluation.

Running an OpenStack cloud at scale requires a highly-available cluster of network nodes to run L3 and DHCP agents. At HP Cloud, we use Corosync and Pacemaker to manage the cluster of network nodes, and to shut down specific agents in the event of node failure, as well as migrating and rescheduling the routers and networks across the remaining nodes.

In the process of doing this, we have discovered some interesting quirks about Neutron in a HA configuration.

In this presentation I will discuss the Neutron high availability architecture as deployed by HP Cloud. Specifically discussing the integration between Pacemaker, the agents, and the Neutron database. I will also talk about issues we have encountered with the HA solution, such as failover time, DHCP network renumbering and DNS failures, Pacemaker exuberance, namespace and router load, and lost tokens.

AT&T and Ericsson would like to co-present a keynote on the topic of leveraging OpenStack to Solve Telco / Cable Company's needs, with an introduction to NFV (Network Function Virtualization ) and SDN (Software Defined Networks).
By providing this basis inforomation, we'd like to drum up support for making OpenStack cover these unique requirements and to kick off building a community around driving Telco/Cable company requirements/blueprints into openstack.

OpenStack networking can be challenging and many of the biggest deployments such as HP, ANL, and CERN use their own customized network drivers. That’s because default OpenStack networking models don’t make sense in a modern datacenter. We designed our own layer-3 (L3) nova-network plugins to Open Cloud System (OCS) 3.0 that replaced the default networking model in an extensible and best practices manner. By removing nova-network from the data path, we delivered a fully scale out networking model that can support 100s of racks in a single cloud with incredibly high performance. This is similar to the approach taken HP, CERN, and others.
We’ll look in detail at the network architecture, examine our “Layer-3” (L3) plugin, discuss the challenges in writing a custom network driver, and talk about how we solved the NAT and DHCP challenges.
OpenStack networking can be challenging and many of the biggest deployments such as HP, ANL, and CERN use their own customized network drivers. That’s because default OpenStack networking models don’t make sense in a modern datacenter. We designed our own layer-3 (L3) nova-network plugins to Open Cloud System (OCS) 3.0 that replaced the default networking model in an extensible and best practices manner. By removing nova-network from the data path, we delivered a fully scale out networking model that can support 100s of racks in a single cloud with incredibly high performance. This is similar to the approach taken HP, CERN, and others.
We’ll look in detail at the network architecture, examine our “Layer-3” (L3) plugin, discuss the challenges in writing a custom network driver, and talk about how we solved the NAT and DHCP challenges.

IPv6 has become an important topic in the network world as IPv4 pools diminish and the use of application-breaking NAT rises. The Neutron IPv6 Sub-team was formed to provide feature-parity between IPv4 and IPv6, and to extend OpenStack's capabilities where IPv6 provides new features. Join Sean Collins, John Jason Brzozowski and Anthony Veiga for a discussion of the current state of IPv6 in OpenStack, where it's going, and why it's important to provide IPv6 support.

Open vSwitch is the default software switch used by OpenStack Neutron. In this talk, we will discuss advanced operations that can be achieved due to its location at the edge of the network. With its unique position, it has greater context and the ability to enforce policies early. We will explore the effects on networking and security, and dive into specific examples that can be best handled with an intelligent edge.
Topics include:

• Guest introspection
• Inferring state from the edge
• Implementing efficient security policies
• Elephant flow detection and handling

High-bandwidth, high-availability server farms present OpenStack with some unique issues as their scale grows. This talk will present some techniques that can allow such installations flexibility in growth and management of their networks to large scale without a concomitant increase in complexity. These aren't solutions for everyone -- they are best suited for a private cloud, with or without a large public-facing surface.
Basic to our approach is the use of topology-based scheduling with clusters spread over multiple layer-2 domains deployed in a regular pattern. On its own this sacrifices flexibility -- IP address mobility isn't readily provided -- but we'll discuss ways of overcoming this deficit through load-balancing, intelligent scheduling, and (optionally) application design. We'll also discuss some data-center management issues (such as maintenance and upgrades) and how they are both impacted and facilitated by these methods.

When it comes to networking with OpenStack, there is a significant portion of users using both of the current option:

• Nova-network or
• Neutron

We will discuss the benefits of Neutron over Nova-network, and even try to have an open discussion between production users of both Nova-network & OpenStack Neutron so that the audience can understand the their networking options and in an OpenStack deployment.
We will have Neutron Core participants to take the feedback from nova-networking users to see what are the gaps that need to be addressed for Neutron to be adopted.

Openstack is growing immensely and now we look beyond the borders of the Data Center. This presentation shows how Ericsson utilises Openstack and SDN technologies for interconnecting Enterprise Networks to the Data Center and how traditional Enterprise CPE equipment is virtualised and provisioned via Openstack and connecting the Enterprise to the Data Center via VPN technologies under an advanced modification of Openstack and underlying layers.

This presentation demonstrates how to achieve this by taking a vanilla Openstack distro and building extensions to this a real world deployment solution to extend Openstack beyond the traditional Data Center track and look towards the Telco Cloud.

Alice In Wonderland - Devops and Openstack Networking
Around 6 years ago I started working with some tools that focused on software engineering collaboration and automation for operations. At the time products like CFEngine and Puppet were the two main tools promoting this new way of doing operations and sharing within operations and software development. A year later Chef was born and I was fortunate enough to join Opscode as the 9th employee as an evangelist preaching this disruptive form of collaboration and automation. At the time a majority of IT infrastructure was managed by what I called the “Bob’s” of the world. Bob’s scripts, Bob’s directories and Bob to death do us part. Trying to explain to Bob the benefits of collaboration and software engineering principles was a hard fought battle over the years. One of the compelling events that helped propel these ideas (what we now call Devops) was cloud computing in the form of IaaS for compute resources. Fast forward to 2014 and these infrastructure automation and collaboration battles still exist but the battles are far less bloody. Now a new war is emerging in the network operations and engineering space. The same argument for network operations adopting these principles is the same as system ops; however, now the new compelling events are network virtualization and Software Defined Networks in cloud infrastructures. Cloud engineers and network operations are dealing with the complexities of managing a new breed of software based network gear like Arista, Cumulus and Insieme along with virtualized network infrastructure like Openvswitch, Openflow, OpenDaylight and NSX. Configuration tools are starting to get more sophisticated on these virtualized networks doing things like automated VLAN to Port mapping and basic system hardening. Chef and Puppet both have introduced primitives supporting platforms like Arista and Cumulus Networks. Help me start the discussion of what Devops and Openstack Networking really could mean.

John Willis
@botchagalupe

A new set of application centric network abstractions are being developed in the form of the Neutron Group Policy extension. In this model, networking requirements of applications are expressed as network policies. On the other hand, there have been significant work on defining network services (*aaS), service insertion and service chaining in the Neutron community. More recently work on Network Function Virtualization and a framework for advanced services in virtual machines have been getting attention.

In this talk, we first discuss the state of the work in implementing the Neutron Group Policy extension and show how a more application-centric view of networking resources can be used to specify and deploy applications. In particular, we demonstrate the use of network policies as defined in a Heat template to specify and deploy an application. We then explore how the Neutron Group Policy extension can take advantage of advances in defining network services and functions and bring about a truly application centric view of networking resources. We show how this view impacts different layers of the stack from end to end and discuss the future directions of the Neutron Group Policy extension.

Network Functions Virtualization (NFV) [1], as described by the ETSI NFV Industry Specification Group (ISG), involves the implementation of network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in, various locations in the network as required, without the need for installation of new equipment. Network functions such as Load balancing, Firewall, DPI, WAN optimization, etc. can now be virtualized and deployed along with the actual application workloads in private clouds or public clouds. The NFV technology is embraced by the network operators who aim to benefit with reduced OPEX costs through reduced equipment costs and power consumption, greater flexibility to scale up or down, and quick deployment of newer network services, to name a few benefits. In this talk, we focus on the deployment of these NFV services in multiple NFV Data Centers (DCs) interconnected by MAN/WAN using a cluster of OpenStack instances. The problem of achieving network efficiency and simultaneously energy efficiency with NFV DC deployments comprises of the following steps 1) Choosing the right set of energy efficient physical servers in the NFV DC 2) Consolidating Virtual Machines (VMs) used by a NFV network function such as virtual CDN into a minimal set of servers 3) Optimizing network distance while being of aware of application characteristics. We have already proposed constraint-based SolverSchedulers in the Openstack compute project Nova [2], where we can specify varied constraints and cost metrics to optimize and thus enable optimal compute placements. Using this SolverScheduler, we can model the NFV placement problem as a constraint optimization problem achieving increased network and energy efficiency by optimally placing NFV VMs in OpenStack Clouds.
References:
[1]

In this session, we will discuss the operational issues that Rackspace has encountered during and after implementing Neutron at a large scale. Neutron at scale required a significant amount of development and operations effort, some of which resulted in deviations from upstream code. Finally, our team would like to discuss our solutions and our upstream differences for Neutron and OpenStack that we believe are necessary so that it can be more performant at scale.

As a relatively young and highly active Openstack project, Neutron has experienced explosive development and growth over the last couple of years. With growth has come growing pains, where developers and operators alike have faced challenges in achieving reliable service deployments at scale.
As a developer and operator, HP Public Cloud faced many of these same challenges. In this talk, we will discuss specific reliability, performance and scalability issues faced in our deployment of Neutron, issues that spanned from the Neutron server to the agents on the compute servers to the DHCP and L3 agents and the metadata proxy. We will share the results of our experiences, the lessons learned and the resulting fixes and enhancements to the Openstack Neutron code base.

SDN is the hot topic in cloud networking. Overlay networks and VXLAN in particular are the de facto standard to implement virtual networking for clouds, due to wide support in the Linux kernel and the latest switches from leading networking vendors.

We will be describing how Neutron and other OSS tools can be used to provide L2 connectivity to VMs via VXLAN over a non-blocking ECMP IP fabric. We will also be demonstrate how a simple service node script can eliminate the need for multicast in the physical network. Additionally we will have a Broadcom Trident 2 based switch on hand running Cumulus Linux 2.0, with which we will demonstrate the use of an extension of the existing Linux Switch ml2 plugin we demoed in Hong Kong to connect physical network devices (routers, firewalls, load balancers, etc) into VXLAN based virtual networks.