OVN, Bringing Native Virtual Networking to OVS

By Justin Pettit, Ben Pfaff, Chris Wright, and Madhu Venugopal

Today we are excited to announce Open Virtual Network (OVN), a new project that brings virtual networking to the OVS user community. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Just like OVS, our design goal is to have a production quality implementation that can operate at significant scale.

Why are we doing this? The primary goal in developing Open vSwitch has always been to provide a production-ready low-level networking component for hypervisors that could support a diverse range of network environments. As one example of the success of this approach, Open vSwitch is the most popular choice of virtual switch in OpenStack deployments. To make OVS more effective in these environments, we believe the logical next step is to augment the low-level switching capabilities with a lightweight control plane that provides native support for common virtual networking abstractions.

To achieve these goals, OVN’s design is narrowly focused on providing L2/L3 virtual networking. This distinguishes OVN from general-purpose SDN controllers or platforms.

OVN is a new project from the Open vSwitch team to support virtual network abstraction. OVN will put users in control over cloud network resources, by allowing users to connect groups of VMs or containers into private L2 and L3 networks, quickly, programmatically, and without the need to provision VLANs or other physical network resources. OVN will include logical switches and routers, security groups, and L2/L3/L4 ACLs, implemented on top of a tunnel-based (VXLAN, NVGRE, Geneve, STT, IPsec) overlay network.

OVN aims to be sufficiently robust and scalable to support large production deployments. OVN will support the same virtual machine environments as Open vSwitch, including KVM, Xen, and the emerging port to Hyper-V. Container systems such as Docker are growing in importance but pose new challenges in scale and responsiveness, so we will work with the container community to ensure quality native support. For physical-logical network integration, OVN will implement software gateways, as well as support hardware gateways from vendors that implement the “vtep” schema that ships with OVS.

Northbound, we will work with the OpenStack community to integrate OVN via a new plugin. The OVN architecture will simplify the current Open vSwitch integration within Neutron by providing a virtual networking abstraction. OVN will provide Neutron with improved dataplane performance through shortcut, distributed logical L3 processing and in-kernel based security groups, without running special OpenStack agents on hypervisors. Lastly, it will provide a scale-out and highly available gateway solution responsible for bridging from logical into physical space.

The Open vSwitch team will build and maintain OVN under the same open source license terms as Open vSwitch, and is open to contributions from all. The outline of OVN’s design is guided by our experience developing Open vSwitch, OpenStack, and Nicira/VMware’s networking solutions. We will evolve the design and implementation in the Open vSwitch mailing lists, using the same open process used for Open vSwitch.

OVN will not require a special build of OVS or OVN-specific changes to ovs-vswitchd or ovsdb-server. OVN components will be part of the Open vSwitch source and binary distributions. OVN will integrate with existing Open vSwitch components, using established protocols such as OpenFlow and OVSDB, using an OVN agent that connects to ovs-vswitchd and ovsdb-server. (The VTEP emulator already in OVS’s “vtep” directory uses a similar architecture.)

OVN is not a generic platform or SDN controller on which applications are built. Rather, OVN will be purpose built to provide virtual networking. Because OVN will use the same interfaces as any other controller, OVS will remain as flexible and unspecialized as it is today. It will still provide the same primitives that it always has and continue to be the best software switch for any controller.

The design and implementation will occur on the ovs-dev mailing list. In fact, a high-level description of the architecture was posted this morning. If you’d like to join the effort, please check out the mailing list.

Happy switching!

Ref: https://networkheresy.com/2015/01/13/ovn-bringing-native-virtual-networking-to-ovs/

Enable telnet in CentOS

​Install & configure service
# yum install telnet telnet-server -y
# vim /etc/xinetd.d/telnet
change to:
disable = no

Restart service
# service xinetd restart

​Allow auto-start service
# chkconfig telnet on
# chkconfig xinetd on

By default, telnet allows only standard user login.
Configure Telnet for root logins

Simply edit the file /etc/securetty and add the following to the end of the file:

pts/0
pts/1
pts/2
pts/3
pts/4
pts/5
pts/6
pts/7
pts/8
pts/9

This will allow up to 10 telnet sessions to the server as root.

Enjoy 🙂