Working with Provider Networks
Networks can be categorized as either project networks or provider networks. Project networks are created by normal users and details about how they are physically realized are hidden from those users. Provider networks are created by Metacloud Support, specifying the details of how the network is physically realized, usually to match some existing network in the data center.
Provider networks enable administrators to create networks that map directly to the physical networks in the data center. This is commonly used to give projects direct access to a public network that can be used to reach the Internet. It might also be used to integrate with VLANs in the network that already have a defined meaning (for example, enable a VM from the marketing department to be placed on the same VLAN as bare-metal marketing hosts in the same data center).
The provider extension allows administrators to explicitly manage the relationship between Networking virtual networks and underlying physical mechanisms such as VLANs and tunnels. When this extension is supported, Networking client users with administrator privileges see additional provider attributes on all virtual networks and are able to specify these attributes in order to create provider networks.
The provider extension is supported by the Open vSwitch and Linux Bridge plug-ins. Configuration of these plug-ins requires familiarity with this extension.
A number of terms are used in the provider extension and in the configuration of plug-ins supporting the provider extension:
- Virtual Network—A Networking L2 network (identified by a UUID and optional name) whose ports can be attached as vNICs to Compute instances and to various Networking agents. The Open vSwitch and Linux Bridge plug-ins each support several different mechanisms to realize virtual networks.
- Physical Network—A network connecting virtualization hosts (such as compute nodes) with each other and with other network resources. Each physical network might support multiple virtual networks. The provider extension and the plug-in configurations identify physical networks using simple string names.
- Project Network—A virtual network that a project or an administrator creates. The physical details of the network are not exposed to the project.
- Provider Network—A virtual network created to map to a specific network in the data center, typically to enable direct access to non-Metacloud resources on that network. Projects can be given access to provider networks.
- VLAN Network—A virtual network implemented as packets on a specific physical network containing IEEE 802.1Q headers with a specific VID field value. VLAN networks sharing the same physical network are isolated from each other at L2 and can even have overlapping IP address spaces. Each distinct physical network supporting VLAN networks is treated as a separate VLAN trunk, with a distinct space of VID values. Valid VID values are 1 through 4094.
- Local Network—A virtual network that allows communication within each host, but not across a network. Local networks are intended mainly for single-node test scenarios, but can have other uses.
Currently Metacloud only supports VLAN networks.
Basic L3 Operations
External networks are visible to all users. Administrators can add existing external VLANs to the environment using the Dashboard. This network can be shared between multiple projects or constrained to a single project. Administrators can also configure Subnets using the Dashboard.
Working with Security Groups
Security groups and security group rules allow administrators and projects 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 in Networking 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, this group drops all ingress traffic and allows all egress. Rules can be added to this group in order to change the behavior.
When using the security group API through Compute, security groups are applied to all ports on an instance. The reason for this is that Compute security group APIs are instances based and not port based as Networking.
Basic Security Group Preparations
This table shows example neutron commands that enable you to complete basic security group operations:
Creates a security group for our web servers.
$ neutron security-group-create webservers --description "security group for webservers"
Lists security groups.
$ neutron security-group-list
Creates a security group rule to allow port 80 ingress.
$ neutron security-group-rule-create --direction ingress \ --protocol tcp --port_range_min 80 --port_range_max 80 SECURITY_GROUP_UUID
Lists security group rules.
$ neutron security-group-rule-list
Deletes a security group rule.
$ neutron security-group-rule-delete SECURITY_GROUP_RULE_UUID
Deletes a security group.
$ neutron security-group-delete SECURITY_GROUP_UUID
Creates a port and associates two security groups.
$ neutron port-create --security-group SECURITY_GROUP_ID1 --security-group SECURITY_GROUP_ID2 NETWORK_ID
Removes security groups from a port.
$ neutron port-update --no-security-groups PORT_ID