Neutron has an extensible architecture, so that it has the ability to be extended and customized through the application of third-party plug-ins (including core and service plug-ins) and drivers. Neutron can also use additional agents that might be required depending on your deployment. Agents are responsible, for example, for providing Dynamic Host Configuration Protocol (DHCP) services to tenant networks, and for L3/Network Address Translation (NAT) forwarding to provide external network access.

Neutron does it's job by handling some major networking constructs through restuful APIs for things like:

1. Networks
2. Subnets
3. Security groups
4. IPAM
5. Floating IPs
6. and more

Why Openstack neutron?

The Networking service (neutron), provides an API that lets you define network connectivity and addressing in the cloud. The Networking service enables operators to leverage different networking technologies to power their cloud networking. The Networking service also provides an API to configure and manage a variety of network services ranging from L3 forwarding and Network Address Translation (NAT) to load balancing, perimeter firewalls, and virtual private networks.

The exact networking implementation differs based on which plugin is being used to provide the networking services.

Neutron Service Components:

Basically neutron is a distributed service that is comprised of multiple components and rely on other services to perform its job (e.g: keystone for authentication, Nova as a consumer).

Neutron includes the following main components:

• API server: defines the API endpoints and data structures for various network constructs.
• Network plugins and Agents: The chosen plugin defines the implementation of the networking services.
• Messaging queue: Used for routing RPC requests between neutron components.

Openstack Self Service Networks:

These networks are entirely virtual and require virtual routers to interact with provider and external networks such as the Internet. Self-service networks also usually provide DHCP and metadata services to instances.

In most cases, self-service networks use overlay protocols such as VXLAN or GRE because they can support many more networks than layer-2 segmentation using VLAN tagging (802.1q). Furthermore, VLANs typically require additional configuration of physical network infrastructure to provide inter-network or intra-network connectivity accross hosts.

For interacting with external networks an external network construct needs to be created and attached to a router that also has interfaces attached to internal networks. Public IPs or NAT could be used to provide access to internal networks inbound and outbound.

Here is a sample topology where the internal virtual networks 1&2 are using the help of the network node (virtual router) to provide inter-communication between the two networks and the physical provider network.

As shown in the diagram above a typical neutron setup consists of multiple services and agents running on one or multiple nodes. Each of these services provide some of the networking or API services. Among those of special interest are:

1. The neutron-server that provides API endpoints and serves as a single point of access to the database. It usually runs on the controller nodes.
2. Layer2 agent that can utilize Open vSwitch, Linux Bridge or other vendor-specific technology to provide network segmentation and isolation for project networks. The L2 agent should run on every node where it is deemed responsible for wiring and securing virtual interfaces (usually both compute and network nodes).
3. Layer3 agent that runs on network node and provides east-west and north-south routing plus some advanced services such as FWaaS or VPNaaS.

It's worth mentioning that there are different flavors to creating such setup and providing connectivity between the instances based on the chosen implementation.

This was a just a quick overview introduction to what openstack neutron service is and what are the major components. In future posts we will be describing more details about different deployment models and traffic flow. Stay tuned.