Metacloud Neutron Networking Overview

When you purchase your private cloud, there are three network configurations available: Customer Managed Network, Cisco Managed Network, and Cisco Managed Gateway Network. Both Cisco Managed network configurations let you create and manage network objects using the Netutron Service and the Networking APIs. As of the Metacloud 4.1 release, project members as well as administrators can create and manage network objects.

In Cisco Managed Networks, the Metacloud Support team fully manages your Metacloud Network Platform. A Cisco Managed Network ensures that your Metacloud network and Metacloud environment are managed and monitored by Metacloud Support Team.

In Customer Managed Network, Metacloud customers manage all aspects of the Metacloud Network Platform. The Metacloud team does not manage any aspects of the Metacloud Network Platform but will notify the customer when network issues are detected.

These network objects include networks, subnets, and ports which other Metacloud OpenStack services can use. Neutron, the networking service, provides and API and CLI that lets you define network connectivity including Layer 3 forwarding and Network Address Translation (NAT), and addressing in the cloud. For more information on the Cisco Managed deployment methodologies and use cases, see: Supported Networking Use Cases and Limitations

Cisco Managed Network

Cisco Managed Network

Cisco Managed Gateway Network

Cisco Managed Gateway

Neutron, the networking service, includes the following components:

API server—The Metacloud Neutron Networking API includes support for Layer 2 networking and IP address management (IPAM), as well as an extension for a Layer 3 router construct that enables routing between Layer 2 networks and gateways to external networks.

OpenStack Networking plug-in and agents—Metacloud supports the Cisco ML2 + Linux bridge agent and the Cisco ASR1k plug-in for Layer 3 networking services, if configured.

Messaging—Neutron uses OpenStacks’s messaging platform to accept and route RPC neutron networking requests between Metacloud services to complete API operations.

Read more in the OpenStack Networking Guide.

To configure network topologies, administrators can create and configure networks and subnets and instruct other services, like Compute, to attach virtual devices to ports on these networks. Refer to the Metacloud Controller Installation Guide for networking diagrams.

Compute is a prominent consumer of networking resources to provide connectivity for its instances. Networking supports each tenant having multiple private networks and enables tenants to choose their own IP addressing scheme, even if those IP addresses overlap with those that other tenant use. There are two types of networks, project and provider networks. It is possible to share any of these types of networks among tenants as part of the network creation process.

Tenant Networks

A Tenant Network is the network that provides connectivity to a project. An Administrator can create, delete and modify tenant networks. Each tenant network is isolated from other tenant networks by a VLAN. Administrators are allowed to create multiple provider or tenant networks using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers, and other networking infrastructure on the same layer 2 VLAN.

Provider Networks

Provider networks map to existing physical networks in the data center.

Networking services like Compute connect to provider networks by requesting virtual ports. Networking supports each tenant having multiple private networks and enables tenants to choose their own IP addressing scheme, even if those IP addresses overlap with those that other tenants use.

To add a provider network to your existing configuration, you must contact Metacloud Support and file a Change-Maintenence Support ticket to edit your configuration files. Include your network configuration settings and the IP addresses for included routers.


Subnets contain a block of IP addresses and associated configuration state. This is also known as the native IPAM (IP Address Management) provided by the networking service for both tenant and provider networks. Subnets are used to allocate IP addresses when new ports are created on a network.


A port is 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.


This is a logical component that forwards data packets between networks. It also provides L3 and NAT forwarding to provide external network access for VMs on tenant networks.

Security Groups

A security group acts as a virtual firewall for your compute instances to control inbound and outbound traffic. Security groups act at the port level, not the subnet level. Each port in a subnet could be assigned to a different set of security groups. If you don’t specify a particular group at launch time, the instance is automatically assigned to the default security group for that network.

Security groups and security group rules give administrators and tenants the ability to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a port. A security group is a container for security group rules. When a port is created, it is associated with a security group. If a security group is not specified, the port is associated with a ‘default’ security group. By default, the default group allows all ingress traffic for all other instances in the same tenant that are assigned to the default group and allows all egress. Rules can be added to this group to change the behavior.