Neutron is able to utilize a set of backends called plugins that support a growing set of networking technologies. These plugins may be distributed separately or as part of the main Neutron release. OpenStack Networking (Neutron) is a virtual network service that provides an efficient API to define the network connectivity and addressing, which is used by devices from other OpenStack services (such as OpenStack Compute). The OpenStack Networking API utilizes virtual network, subnet, and port abstractions to describe networking resources. In the OpenStack networking ecosystem:

• A network is an isolated L2 segment similar to VLAN in physical networking.
• A block of IPv4 or IPv6 addresses and associated configuration states is a subnet.
• A connection point for attaching a single device, such as the NIC of a virtual server, to a virtual network is defined as a port. Also, a port describes the network configuration parameters (such as the MAC and IP addresses) associated with that port.

By creating and configuring networks and subnets, users can configure rich network topologies and then instruct other OpenStack services such as OpenStack Compute to connect virtual interfaces to ports on these networks. Neutron particularly supports each tenant having multiple private networks, and enables tenants to choose their own IP addressing scheme. The OpenStack Networking service:

• Provides advanced cloud networking scenarios, such as constructing multi-tiered web applications and enabling applications to be migrated to the cloud without IP address modifications.
• Enables cloud administrators to offer flexible and customized network offerings.
• Provides API extensions that lets cloud administrators expose additional API capabilities. These new capabilities are typically introduced as an API extension, and gradually will become part of the core OpenStack Networking API.

The original OpenStack Compute network implements a very simple model of traffic isolation through IP tables and Linux VLANs. OpenStack Networking introduces the notion of a plugin, which is a backend implementation of the OpenStack Networking API. A plugin can use different technologies to implement logical API requests. Some OpenStack Networking plugins might use basic Linux VLANs and IP tables, while others might use more advanced technologies, such as L2-in-L3 tunneling or OpenFlow, to provide similar capabilities.

The main module of the OpenStack Networking server is neutron-server, which is a Python daemon that exposes the OpenStack Networking API. It passes user requests to the configured OpenStack Networking plugin for extra processing. The plugin typically needs a database for persistent storage. If your deployment uses a controller host to run centralized OpenStack Compute components, you can deploy the OpenStack Networking server on that same host. However, OpenStack Networking is completely standalone and can be deployed on its own server. Based on deployment, OpenStack Networking also includes additional agents that might be required, which are as follows:

• A plugin agent (neutron-*-agent), which executes on each hypervisor to configure the local switch. Since some plugins do not actually require an agent, the agent to be run will depend on the selected plugin.
• A DHCP agent (neutron-dhcp-agent) provides DHCP services to tenant networks.
• An L3 agent (neutron-l3-agent) provides L3/NAT forwarding to facilitate external network access for VMs on tenant networks.

These agents interact with the core Neutron process through remote procedure call (RPC) or by utilizing the standard OpenStack Networking API. OpenStack Networking relies on Keystone for the authentication and authorization of all API requests. Nova interacts with OpenStack Networking through standard API calls. During the VM creation process, nova communicates with the OpenStack Networking API to plug each virtual network interface card on the VM into a particular network. Horizon integrates with the OpenStack Networking API, and enables tenant users and administrators to create and manage network services through the GUI of the OpenStack dashboard.

There are four distinct physical data center networks in a standard OpenStack Networking deployment, as depicted in the following diagram:

• Management network: It is used for internal communication between OpenStack components. IP address assignments on this network should be only reachable within the data center network.
• Data network: It is used for VM data communication within the cloud setup. Depending on the networking plugin used, the IP addressing requirements of this network vary.
• External network: It is used to provide internet access for VMs in some deployments. IP addresses on this network should be visible and reachable by any host on the internet.
• API network: It exposes all OpenStack APIs, including the OpenStack Networking API, to tenants. IP addresses on this network should be reachable by anyone on the internet.