Networking architecture Before you deploy Networking, it helps to understand the Networking components and how these components interact with each other and other OpenStack services.
Overview Networking is a standalone service, just like other OpenStack services such as Compute, Image service, Identity service, or the Dashboard. Like those services, a deployment of Networking often involves deploying several processes on a variety of hosts. The Networking server uses the neutron-server daemon to expose the Networking API and to pass user requests to the configured Networking plug-in for additional processing. Typically, the plug-in requires access to a database for persistent storage (also similar to other OpenStack services). If your deployment uses a controller host to run centralized Compute components, you can deploy the Networking server on that same host. However, Networking is entirely standalone and can be deployed on its own host as well. Depending on your deployment, Networking can also include the following agents.
Networking agents
Agent Description
plug-in agent (neutron-*-agent) Runs on each hypervisor to perform local vSwitch configuration. The agent that runs depends on the plug-in that you use, and some plug-ins do not require an agent.
dhcp agent (neutron-dhcp-agent) Provides DHCP services to tenant networks. Some plug-ins use this agent.
l3 agent (neutron-l3-agent) Provides L3/NAT forwarding to provide external network access for VMs on tenant networks. Some plug-ins use this agent.
metering agent (neutron-metering-agent) Provides L3 traffic measurements for tenant networks.
These agents interact with the main neutron process through RPC (for example, rabbitmq or qpid) or through the standard Networking API. Further: Networking relies on the Identity service (Keystone) for the authentication and authorization of all API requests. Compute (Nova) interacts with Networking through calls to its standard API.  As part of creating a VM, the nova-compute service communicates with the Networking API to plug each virtual NIC on the VM into a particular network.  The Dashboard (Horizon) integrates with the Networking API, enabling administrators and tenant users to create and manage network services through a web-based GUI.
Place services on physical hosts Like other OpenStack services, Networking enables cloud administrators to run one or more services on one or more physical devices. At one extreme, the cloud administrator can run all service daemons on a single physical host for evaluation purposes. Alternatively the cloud administrator can run each service on its own physical host and, in some cases, can replicate services across multiple hosts for redundancy. For more information, see the OpenStack Configuration Reference. A standard architecture includes a cloud controller host, a network gateway host, and a set of hypervisors that run virtual machines. The cloud controller and network gateway can be on the same host. However, if you expect VMs to send significant traffic to or from the Internet, a dedicated network gateway host helps avoid CPU contention between the neutron-l3-agent and other OpenStack services that forward packets.
Network connectivity for physical hosts A standard Networking set up has one or more of the following distinct physical data center networks.
General distinct physical data center networks
Network Description
Management network Provides internal communication between OpenStack Components. IP addresses on this network should be reachable only within the data center.
Data network Provides VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the Networking plug-in that is used.
External network Provides VMs with Internet access in some deployment scenarios. Anyone on the Internet can reach IP addresses on this network.
API network Exposes all OpenStack APIs, including the Networking API, to tenants. IP addresses on this network should be reachable by anyone on the Internet. The API network might be the same as the external network, because it is possible to create an external-network subnet that is allocated IP ranges that use less than the full range of IP addresses in an IP block.