Advanced features through API extensions¶

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 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 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 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 project 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.

$ openstack network create public --external
$ openstack subnet create --network public --subnet-range 172.16.1.0/24 subnetname

$ openstack network list --external

$ openstack network create net1
$ openstack subnet create --network net1 --subnet-range 10.0.0.0/24 subnetname1
$ openstack network create net2
$ openstack subnet create --network net2 --subnet-range 10.0.1.0/24 subnetname2
$ openstack router create router1
$ openstack router add subnet router1 subnetname1
$ openstack router add subnet router1 subnetname2

$ openstack router set --external-gateway EXT_NET_ID router1
$ openstack router set --route destination=172.24.4.0/24,gateway=172.24.4.1 router1

$ openstack router list

$ openstack router show ROUTER_ID

$ openstack port list --router  ROUTER_ID
$ openstack port list --router  ROUTER_NAME

$ openstack port list -c ID -c "Fixed IP Addresses" --server INSTANCE_ID

$ openstack floating ip create EXT_NET_ID
$ openstack floating ip add port FLOATING_IP_ID --port-id INTERNAL_VM_PORT_ID

$ openstack floating ip create EXT_NET_ID --subnet SUBNET_ID

$ openstack floating ip create --port INTERNAL_VM_PORT_ID EXT_NET_ID

$ openstack floating ip list

$ openstack floating ip list --port INTERNAL_VM_PORT_ID

$ openstack floating ip remove port FLOATING_IP_ID

$ openstack floating ip delete FLOATING_IP_ID

$ openstack router unset --external-gateway router1

$ openstack router remove subnet router1 SUBNET_ID

$ openstack router delete router1

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.

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.

$ openstack security group create webservers \
 --description "security group for webservers"

$ openstack security group list

$ openstack security group rule create --ingress \
  --protocol tcp SECURITY_GROUP_UUID

$ openstack security group rule list

$ openstack security group rule delete SECURITY_GROUP_RULE_UUID

$ openstack security group delete SECURITY_GROUP_UUID

$ openstack port create port1 --security-group SECURITY_GROUP_ID1 \
  --security-group SECURITY_GROUP_ID2 --network NETWORK_ID

$ openstack port set --no-security-group 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 the 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

$ openstack network create public --external --provider-network-type l3_ext \
--provider-physical-network L3_GATEWAY_SERVICE_UUID

$ openstack network create public --external --provider-network-type l3_ext \
--provider-physical-network L3_GATEWAY_SERVICE_UUID --provider-segment 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 project, all virtual routers in this project are associated with this label.

$ openstack network meter label create LABEL1 \
  --description "DESCRIPTION_LABEL1"

$ openstack network meter label list

$ openstack network meter label show LABEL_UUID
$ openstack network meter label show LABEL1

$ openstack network meter label delete LABEL_UUID
$ openstack network meter label delete LABEL1

$ openstack network meter label rule create LABEL_UUID \
  --remote-ip-prefix CIDR \
  --direction DIRECTION --exclude

$ openstack network meter label rule create label1 \
  --remote-ip-prefix 10.0.0.0/24 --direction ingress
$ openstack network meter label rule create label1 \
  --remote-ip-prefix 20.0.0.0/24 --exclude

$ openstack network meter label rule list

$ openstack network meter label rule show RULE_UUID

$ openstack network 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