The Networking service, code-named 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 NAT to load balancing, edge firewalls, and IPsec VPN.
For a detailed description of the Networking API abstractions and their attributes, see the OpenStack Networking API v2.0 Reference.
If you use the Networking service, do not run the Compute
nova-network service (like you do in traditional Compute deployments).
When you configure networking, see the Compute-related topics in this
Networking is a virtual network service that provides a powerful API to define the network connectivity and IP addressing that devices from other services, such as Compute, use.
The Compute API has a virtual server abstraction to describe computing resources. Similarly, the Networking API has virtual network, subnet, and port abstractions to describe networking resources.
|Network||An isolated L2 segment, analogous to VLAN in the physical networking world.|
|Subnet||A block of v4 or v6 IP addresses and associated configuration state.|
|Port||A connection point for attaching a single device, such as the NIC of a virtual server, to a virtual network. Also describes the associated network configuration, such as the MAC and IP addresses to be used on that port.|
To configure rich network topologies, you can create and configure networks and subnets and instruct other OpenStack services like Compute to attach virtual devices to ports on these networks.
In particular, Networking supports each project having multiple private networks and enables projects to choose their own IP addressing scheme, even if those IP addresses overlap with those that other projects use.
The Networking service:
OpenStack Networking supports SSL for the Networking API server. By
default, SSL is disabled but you can enable it in the
Set these options to configure SSL:
use_ssl = True
ssl_cert_file = PATH_TO_CERTFILE
ssl_key_file = PATH_TO_KEYFILE
ssl_ca_file = PATH_TO_CAFILE
tcp_keepidle = 600
retry_until_window = 30
backlog = 4096
Load-Balancer-as-a-Service (LBaaS) enables Networking to distribute incoming requests evenly among designated instances. This distribution ensures that the workload is shared predictably among instances and enables more effective use of system resources. Use one of these load balancing methods to distribute incoming requests:
|Monitors||LBaaS provides availability monitoring with the
|Management||LBaaS is managed using a variety of tool sets.
The REST API is available for programmatic
administration and scripting. Users perform
administrative management of load balancers
through either the CLI (
|Connection limits||Ingress traffic can be shaped with connection limits. This feature allows workload control, and can also assist with mitigating DoS (Denial of Service) attacks.|
|Session persistence||LBaaS supports session persistence by ensuring incoming requests are routed to the same instance within a pool of multiple instances. LBaaS supports routing decisions based on cookies and source IP address.|
For information on Firewall-as-a-Service (FWaaS), please consult the Networking Guide.
Allowed-address-pairs enables you to specify
mac_address and ip_address(cidr) pairs that pass through a port regardless
of subnet. This enables the use of protocols such as VRRP, which floats
an IP address between two instances to enable fast data plane failover.
Currently, only the ML2, Open vSwitch, and VMware NSX plug-ins support the allowed-address-pairs extension.
Basic allowed-address-pairs operations.
Create a port with a specified allowed address pair:
$ openstack port create port1 --allowed-address \ ip-address=<IP_CIDR>[,mac_address=<MAC_ADDRESS]
Update a port by adding allowed address pairs:
$ openstack port set PORT_UUID --allowed-address \ ip-address=<IP_CIDR>[,mac_address=<MAC_ADDRESS]
The VPNaaS extension enables OpenStack projects to extend private networks across the internet.
VPNaas is a service. It is a parent object that associates a VPN with a specific subnet and router. Only one VPN service object can be created for each router and each subnet. However, each VPN service object can have any number of IP security connections.
The Internet Key Exchange (IKE) policy specifies the authentication and encryption algorithms to use during phase one and two negotiation of a VPN connection. The IP security policy specifies the authentication and encryption algorithm and encapsulation mode to use for the established VPN connection. Note that you cannot update the IKE and IPSec parameters for live tunnels.
You can set parameters for site-to-site IPsec connections, including peer CIDRs, MTU, authentication mode, peer address, DPD settings, and status.
The current implementation of the VPNaaS extension provides:
The VPNaaS driver plugin can be configured in the neutron configuration file. You can then enable the service.