Advanced features through API extensions¶

Provider networks¶

Networks can be categorized as either tenant networks or provider networks. Tenant networks are created by normal users and details about how they are physically realized are hidden from those users. Provider networks are created with administrative credentials, specifying the details of how the network is physically realized, usually to match some existing network in the data center.

Provider networks enable cloud administrators to create Networking networks that map directly to the physical networks in the data center. This is commonly used to give tenants 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 administrative 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.

L3 routing and NAT¶

The Networking API provides abstract L2 network segments that are decoupled from the technology used to implement the L2 network. Networking includes an API extension that provides abstract L3 routers that API users can dynamically provision and configure. These Networking routers can connect multiple L2 Networking networks and can also provide a gateway that connects one or more private L2 networks to a shared external network. For example, a public network for access to the Internet. See the OpenStack Configuration Reference for details on common models of deploying Networking L3 routers.

The L3 router provides basic NAT capabilities on gateway ports that uplink the router to external networks. This router SNATs all traffic by default and supports floating IPs, which creates a static one-to-one mapping from a public IP on the external network to a private IP on one of the other subnets attached to the router. This allows a tenant to selectively expose VMs on private networks to other hosts on the external network (and often to all hosts on the Internet). You can allocate and map floating IPs from one port to another, as needed.

# neutron net-create public --router:external True
$ neutron subnet-create public 172.16.1.0/24

$ neutron net-list -- --router:external True

$ neutron net-create net1
$ neutron subnet-create net1 10.0.0.0/24
$ neutron net-create net2
$ neutron subnet-create net2 10.0.1.0/24
$ neutron router-create router1
$ neutron router-interface-add router1 SUBNET1_UUID
$ neutron router-interface-add router1 SUBNET2_UUID

$ neutron router-gateway-set router1 EXT_NET_ID

$ neutron router-list

$ neutron router-show ROUTER_ID

$ neutron router-port-list ROUTER_ID
$ neutron router-port-list ROUTER_NAME

$ neutron port-list -c id -c fixed_ips -- --device_id INSTANCE_ID

$ neutron floatingip-create EXT_NET_ID
$ neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID

$ neutron floatingip-create --port_id INTERNAL_VM_PORT_ID EXT_NET_ID

$ neutron floatingip-list

$ neutron floatingip-list -- --port_id ZZZ

$ neutron floatingip-disassociate FLOATING_IP_ID

$ neutron floatingip-delete FLOATING_IP_ID

$ neutron router-gateway-clear router1

$ neutron router-interface-delete router1 SUBNET_ID

$ neutron router-delete router1

Security groups¶

Security groups and security group rules allows 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 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.

To use the Compute security group APIs or use Compute to orchestrate the creation of ports for instances on specific security groups, you must complete additional configuration. You must configure the /etc/nova/nova.conf file and set the security_group_api=neutron option on every node that runs nova-compute and nova-api. After you make this change, restart nova-api and nova-compute to pick up this change. Then, you can use both the Compute and OpenStack Network security group APIs at the same time.

$ neutron security-group-create webservers --description "security group for webservers"

$ neutron security-group-list

$ neutron security-group-rule-create --direction ingress \
  --protocol tcp --port_range_min 80 --port_range_max 80 SECURITY_GROUP_UUID

$ neutron security-group-rule-list

$ neutron security-group-rule-delete SECURITY_GROUP_RULE_UUID

$ neutron security-group-delete SECURITY_GROUP_UUID

$ neutron port-create --security-group SECURITY_GROUP_ID1 --security-group SECURITY_GROUP_ID2 NETWORK_ID

$ neutron port-update --no-security-groups PORT_ID

Basic Load-Balancer-as-a-Service operations¶

This list shows example neutron commands that enable you to complete basic LBaaS operations:

• Creates a load balancer pool by using specific provider.

  --provider is an optional argument. If not used, the pool is created with default provider for LBaaS service. You should configure the default provider in the [service_providers] section of neutron.conf file. If no default provider is specified for LBaaS, the --provider parameter is required for pool creation.

  $ neutron lb-pool-create --lb-method ROUND_ROBIN --name mypool
  --protocol HTTP --subnet-id SUBNET_UUID --provider PROVIDER_NAME
  

• Associates two web servers with pool.

  $ neutron lb-member-create --address  WEBSERVER1_IP --protocol-port 80 mypool
  $ neutron lb-member-create --address  WEBSERVER2_IP --protocol-port 80 mypool
  

• Creates a health monitor that checks to make sure our instances are still running on the specified protocol-port.

  $ neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3
  

• Associates a health monitor with pool.

  $ neutron lb-healthmonitor-associate  HEALTHMONITOR_UUID mypool
  

• Creates a virtual IP (VIP) address that, when accessed through the load balancer, directs the requests to one of the pool members.

  $ neutron lb-vip-create --name myvip --protocol-port 80 --protocol
  HTTP --subnet-id SUBNET_UUID mypool
  

Plug-in specific extensions¶

Each vendor can choose to implement additional API extensions to the core API. This section describes the extensions for each plug-in.

$ neutron queue-create --min 10 --max 1000 myqueue

$ neutron net-create network --queue_id QUEUE_ID

$ neutron queue-create --default True --min 10 --max 2000 default

$ neutron queue-list

$ neutron queue-delete QUEUE_ID_OR_NAME'

$ neutron net-create public --router:external True --provider:network_type l3_ext \
--provider:physical_network L3_GATEWAY_SERVICE_UUID

$ neutron net-create public --router:external True --provider:network_type l3_ext \
--provider:physical_network L3_GATEWAY_SERVICE_UUID --provider:segmentation_id VLAN_ID

$ neutron router-update ROUTER_UUID --router_rules type=dict list=true\
source=any,destination=any,action=permit \
source=external,destination=10.10.10.0/24,action=deny

$ neutron router-update ROUTER_UUID --router_rules type=dict list=true\
source=any,destination=any,action=permit \
source=10.10.10.0/24,destination=any,action=permit,nexthops=10.10.10.254+10.10.10.253

$ neutron router-update ROUTER_UUID --router_rules type=dict list=true\
source=any,destination=any,action=permit \
source=10.10.10.0/24,destination=10.20.20.20/24,action=deny

L3 metering¶

The L3 metering API extension enables administrators to configure IP ranges and assign a specified label to them to be able to measure traffic that goes through a virtual router.

The L3 metering extension is decoupled from the technology that implements the measurement. Two abstractions have been added: One is the metering label that can contain metering rules. Because a metering label is associated with a tenant, all virtual routers in this tenant are associated with this label.

$ neutron meter-label-create LABEL1 --description "DESCRIPTION_LABEL1"

$ neutron meter-label-list

$ neutron meter-label-show LABEL_UUID
$ neutron meter-label-show LABEL1

$ neutron meter-label-delete LABEL_UUID
$ neutron meter-label-delete LABEL1

$ neutron meter-label-rule-create LABEL_UUID CIDR --direction DIRECTION
  excluded

$ neutron meter-label-rule-create label1 10.0.0.0/24 --direction ingress
$ neutron meter-label-rule-create label1 20.0.0.0/24 --excluded

$ neutron meter-label-rule-list

$ neutron meter-label-rule-show RULE_UUID

$ neutron meter-label-rule-delete RULE_UUID

$ ceilometer sample-list -m SNMP_MEASUREMENT

$ ceilometer sample-list -m hardware.network.bandwidth.bytes
$ ceilometer sample-list -m hardware.network.incoming.bytes
$ ceilometer sample-list -m hardware.network.outgoing.bytes
$ ceilometer sample-list -m hardware.network.outgoing.errors