Difference between revisions of "Neutron/NEC OpenFlow Plugin"

Revision as of 15:25, 9 July 2015

[Note] In Kilo development cycle, Neutron community decides to move vendor specific codes into separate repositories. NEC OpenFlow plugin is now available at https://git.openstack.org/stackforge/networking-nec. More detail will be coming soon.

Project Links

• Git: https://github.com/stackforge/networking-nec
• Launchpad: https://launchpad.net/networking-nec
• PyPI: https://pypi.python.org/pypi/networking-nec

Abstract

NEC OpenFlow plugin talks to OpenFlow Controller and each Neutron would be mapped to an virtual layer-2 network slice on an OpenFlow enabled network. The interface between the Neutron plugin and OpenFlow Controller is RESTful API. This API is supported by two implementations:Trema Sliceable Switch (OSS) and NEC ProgrammableFlow Controller (NEC Commercial Product).

This plugin consists of two components: "Plugin" and "Agent".

• Plugin: It processes Neutron API calls and controls OpenFlow controller to handle logical networks on OpenFlow enabled network.
• Agent: It runs on each compute node. It gathers a mapping beween a VIF and a switch port from local Open vSwitch and reports it to the plugin.

Requirements

• OpenFlow Controller: Trema with Sliceable Switch (distributed under GPL2), or an OpenFlow Controller that has the same functionalities and REST API available at https://github.com/trema/apps/wiki/Sliceable-Network-Management-API .

How to run this plugin with DevStack

Kilo and later

During Kilo development cycle, the code/vendor code decomposition work has been done in Neutron. Along with this, DevStack external plugin mechanism was introduced for more flexibility. DevStack support of NEC OpenFlow plugin is provided at networking-nec repository. To use NEC plugin DevStack support,

 enable_plugin networking-nec https://git.openstack.org/stackforge/networking-nec

The detail is available at http://git.openstack.org/cgit/stackforge/networking-nec/plain/devstack/README.md .

Juno, Icehouse

Devstack support of NEC OpenFlow plugin is a part of the official devstack (http://github.com/openstack-dev/devstack) from Grizzly.

Detail instruction and sample devstack configuration examples (localrc) are available at https://github.com/nec-openstack/devstack-neutron-nec-openflow/wiki .

How to get

• Kilo or later : Neutron integration is available. After the core/vendor decomposition work, the main code is provided as a separate python module called networking-nec, and the shim code and configuration exist in the Neutron code tree.
  • The code is maintained at stackforge https://github.com/stackforge/networking-nec
  • The released versions of Python module is available at https://pypi.python.org/pypi/networking-nec. To install pip install networking-nec~=2015.1. Note that the version number like 2015.1 should match the corresponding OpenStack release version (e.g., 2015.1 for Kilo, 2015.2 for Liberty).
• Juno, Icehouse (Folsom or later) : Merged into the mainline of Neutron https://github.com/openstack/neutron

Configuration

This section describes the configurations of the releases maintained by OpenStack community (i.e., Juno and Icehouse) and under development (Kilo).

neutron.conf

• core_plugin: Needs to be configured to neutron.plugins.nec.nec_plugin.NECPluginV2 to use NEC OpenFlow plugin as core plugin.
  • core_plugin = neutron.plugins.nec.nec_plugin.NECPluginV2
• service_plugins: NEC OpenFlow plugin provides L3 router feature as part of the core plugin. Thus L3 router service plugin should NOT be contained in service_plugin. Other service plugins (LBaaS, FWaaS, VPNaaS, metering) are verified to work with NEC OpenFlow plugin.

plugin specific configuration

It is usually placed at /etc/neutron/plugins/nec/nec.ini.

Section "'[OFC]"' is particular configurations to NEC OpenFlow plugin. We describe [OFC] section first and then describe other sections.

[OFC] section

• North-bound REST API of OpenFlow controller
  • host: Host IP address of OpenFlow Controller where its north-bound REST API is listening to. Example: 127.0.0.1
  • port: Port number of OpenFlow Controller where its north0bound REST API is listening to. Example: 8888
  • driver: Shortcut name or full class path of OpenFlow controller driver. The appropriate driver needs to be specified depending on your back-end OpenFlow controller. The following drivers are available. The default value is trema.
    • NEC ProgrammableFlow OpenFlow controller
      • pfc : Alias for the latest ProgrammableFlow release. pfc_v51 in Icehouse, pfc_v5 in Havana.
      • pfc_v51 : ProgrammableFlow Controller V5.1. Supported in Icehouse
      • pfc_v5 : ProgrammableFlow Controller V5.0. Supported in Havana or later.
      • pfc_v4 : ProgrammableFlow Controller V4.0.
      • pfc_v3 : ProgrammableFlow Controller V3.0.
    • Trema Sliceable Switch
      • trema: Trema Slieable Switch. Alias for trema_port.
      • trema_port : Virtual networks are identified based on OpenFlow port. Each port of virtual network is identified by datapath_id, port_no and (optional) vlan_id.
      • trema_portmac : Similar to trema_port. In addition MAC address is also considered when identify a port of virtual network.
      • trema_mac : Virtual networks are identified based on received MAC address.
  • enable_packet_filter: Specified whether NEC plugin specific PacketFilter extension is enabled. This features is supported in all OpenStack releases for Trema Sliceable Switch and since Icehouse for ProgrammableFlow Controller. The default value is true.
  • support_packet_filter_on_ofc_router: Support packet filter features on OFC router interface. ProgrammableFlow Controller v5 does not support the packet filter on OFC router interface, so this parameter should be set to false. Otherwise it is recommended to set this to true. The default value is true. (Since Juno)
  • api_max_attempts (default: 3): Maximum attempts per OFC API request. NEC plugin retries API request to OFC when OFC returns ServiceUnavailable (503). The value must be greater than 0. (Since Icehouse)
  • path_prefix (default: empty string): Base URL of OpenFlow Controller REST API. It is prepended to a path of each API request. (Since Icehouse)
• SSL configuration for OpenFlow controller north bound API. It is only available for ProgrammableFlow Controller.
  • use_ssl (default: false): Specify whether SSL is used to connection a back-end OpenFlow controller or not.
  • key_file: Key file
  • cert_file: Certificate file
  • insecure_ssl (default: false): Disable SSL certificate verification. (Since Icehouse)

[ovs] section

• integration_bridge (default: br-int) : This is the name of the OVS integration bridge. There is one per hypervisor. The integration bridge acts as a virtual "patch port". All VM VIFs are attached to this bridge and then "patched" according to their network connectivity. Recommend not to change this parameter unless you have a good reason to.

[agent] section

• root_helper: Recommended to be configured to sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf. In Kilo, this parameter no longer has the meaning.
• polling_interval (default: 2): Agent's polling interval in seconds

[securitygroup] section

• firewall_driver: Firewall driver for realizing neutron security group function. Needs to configured to neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
• enable_security_group (default: true): Controls if neutron security group is enabled or not. It should be false when you use nova security group.

[provider] section

NEC OpenFlow plugin supported multiple back-end for router implementation.

• default_router_provider (default: l3-agent): Default router provider to use. l3-agent or openflow can be specified.
• router_providers (default: l3-agent,openflow): List of enabled router providers. If a configured OpenFlow backed does not support router implementation, openflow provider will be disabled automatically and all routers will be created using l3-agent.

Neutron service agent

Various neutron agents which plug interfaces to an integration bridge have a configuration parameter interface_driver. interface_driver and ovs_use_veth need to be configured to OVSInterfaceDriver to make NEC OpenFlow plugin work.

interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
ovs_use_veth = True

Such agents are:

• DHCP agent (/etc/neutron/dhcp_agent.ini)
• L3 agent (/etc/neutron/l3_agent.ini)
• LBaaS HAProxy agent (/etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini)
• Neutron Debug command neutron-debug (/etc/neutron/debug.ini)

Nova configuration

• No configuration specific to this plugin.

Design

Communication between plugin and agent

This plugin uses "common-rpc" in openstack-common for the agents to communicate with the plugin and will conform to the convention for scalable-agent-comms. The topic name for RPC will be set to "neutron.plugin" as proposed in the blueprint scalable-agent-comms.

Integration with Nova

There are no need for additional features in Nova. This implementation utilizes a current libvirt VIF driver and linux-net interface driver.

Related websites

• Github repositories of NEC OpenStack team : https://github.com/nec-openstack/
• Trema - Full-Stack OpenFlow Framework in Ruby and C : https://github.com/trema/trema
• Trema Sliceable Switch : https://github.com/trema/apps/tree/master/sliceable_switch

Contact: Akihiro Motoki (amotoki on freenode)