Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

A. MarkelovCertified OpenStack Administrator Study Guide Certification Study Companion Serieshttps://doi.org/10.1007/978-1-4842-8804-7_6

6. OpenStack Networking

Andrey Markelov¹

(1)

Stockholm, Sweden

This chapter covers 30% of the Certified OpenStack Administrator exam requirements. It is one of the most impotent topics in the book. Without a solid knowledge of the network components, you will be unable to perform most exam tasks.

Neutron’s Architecture and Components

Neutron is one of the most complicated OpenStack services. Let’s start by looking at its architecture and general concepts. Figure 6-1 shows the objects in OpenStack’s networking service.

Figure 6-1
Logical objects in OpenStack’s networking service

The following describes the most important components.

A tenant network is a virtual network that provides connectivity between entities. The network consists of subnets, and each subnet is a logical subdivision of an IP network. A subnet can be private or public. Virtual machines can get access to an external world through the public subnet. If a virtual machine is connected only to the private subnet, then only other virtual machines from this network can access it. Only a user with an admin role can create a public network.
A router is a virtual network device that passes network traffic between different networks. A router can have one gateway and many connected subnets.
A security group is a set of ingress and egress firewall rules that can be applied to one or many virtual machines. It is possible to change a Security Group at runtime.
A floating IP address is an IP address that can be associated with a virtual machine so that the instance has the same IP from the public network each time it boots.
A port is a virtual network port within OpenStack’s networking service. It is a connection between the subnet and vNIC or virtual router.
A vNIC (virtual network interface card) or VIF (virtual network interface) is an interface plugged into a port in a network.

Let’s continue this discussion by learning more about Neutron architecture (see Figure 6-2).

Figure 6-2
Neutron’s architecture (OVS example)

Upstream documentation from docs.openstack.org defines several types of OpenStack nodes. Neutron is usually spread across three of them. API service usually exists at the control node. Open vSwitch and client-side Neutron agents are usually started at the hypervisor or compute node. And all server-side components of OpenStack’s networking service work on network nodes, which can be gateways to an external network.

Neutron consists of several services that are implemented as standard GNU/Linux daemons.

neutron-server is the main service of Neutron. Accepts and routes API requests through message bus to the OpenStack networking plug-ins for action.
neutron-openvswitch-agent receives commands from neutron-server and sends them to Open vSwitch (OVS) for execution. The neutron-openvswitch-agent uses the local GNU/Linux commands for OVS management.
neutron-l3-agent provides routing and network address translation (NAT) using standard GNU/Linux technologies like Linux Routing and Network Namespaces.
neutron-dhcp-agent manages dnsmasq services, which is a lightweight Dynamic Host Configuration Protocol (DHCP) and caching DNS server. Also, neutron-dhcp-agent starts proxies for the metadata server.
neutron-metadata-agent allows instances to get information such as hostname, SSH keys, and so on. Virtual machines can request HTTP protocol information such as http://169.254.169.254 at boot time. Usually, this happens with scripts like cloud-init (https://launchpad.net/cloud-init). An agent acts as a proxy to nova-api for retrieving metadata.

Neutron also uses Open vSwitch. Its configuration is discussed in the next section of this chapter. Some modern OpenStack distributions migrated to Open Virtual Networking (OVN) instead of OVS. OVN includes a DHCP service, L3 routing, and NAT. It replaces the OVS ML2 driver and the Neutron agent with the OVN ML2 driver. OVN does not use the Neutron agents at all. In OVN-enabled OpenStack, the ovn-controller service implements all functionality. Some gaps from ML2/OVS are still present (see https://docs.openstack.org/neutron/yoga/ovn/gaps.html). Note that the current OpenStack installation guide refers to OVS, but if you install the last version of DevStack or PackStack, you get OVN.

You will not be tested on this knowledge on the exam. You may directly jump to the “Manage Network Resources” section. From an exam point of view, your experience should be the same.

Table 6-1 lists what type of node (compute, network, or control) services are started and the location of their configs.

Table 6-1

OpenStack Neutron Services and Their Placement

Service	Node Type	Configuration Files
neutron-service	Control	/etc/neutron/neutron.conf
neutron-openvswitch-agent	Network and Compute	/etc/neutron/plugins/ml2/openvswitch_agent.ini
neutron-l3-agent	Network	/etc/neutron/l3_agent.ini
neutron-dhcp-agent	Network	/etc/neutron/dhcp_agent.ini
neutron-metadata-agent	Network	/etc/neutron/metadata_agent.ini
Modular Layer 2 agent (it is not run as a daemon)	Network	/etc/neutron/plugins/ml2/ml2_conf.ini and /etc/neutron/plugin.ini (symbolic link to ml2_conf.ini)

Opening vSwitch’s Architecture

OVS is an important part of networking in the OpenStack cloud. The website for OVS with documentation and source code is https://www.openvswitch.org/. Open vSwitch is not a part of the OpenStack project. However, OVS is used in most implementations of OpenStack clouds. It has also been integrated into many other virtual management systems, including OpenQRM, OpenNebula, and oVirt. Open vSwitch can support protocols such as OpenFlow, GRE, VLAN, VXLAN, NetFlow, sFlow, SPAN, RSPAN, and LACP. It can operate in distributed configurations with a central controller.

Open vSwitch by itself consists of several components.

openswitch_mod.ko is a GNU/Linux kernel module that plays the role of ASIC (application-specific integrated circuit) in hardware switches. This module is an engine of traffic processing.
ovs-vswitchd is a daemon in charge of management and logic for data transmitting.
ovsdb-server is a daemon used for the internal database. It also provides RPC (remote procedure call) interfaces to one or more Open vSwitch databases (OVSDBs).

You will likely not need to manage Open vSwitch at the exam time, but commands can be useful. Let’s look at examples of using the ovs-vsctl management utility for interacting with OVS. First, let’s check for the version of Open vSwitch.

# ovs-vsctl -V

ovs-vsctl (Open vSwitch) 2.4.0

Compiled Oct 7 2015 18:01:06

DB Schema 7.12.1

You can create a new bridge and delete it with the help of the following commands.

# ovs-vsctl add-br br-new

# ovs-vsctl del-br br-new

The same with adding or removing a physical interface to or from the bridge.

# ovs-vsctl add-port br-ex enp0s3

# ovs-vsctl del-port br-ex enp0s3

The most interesting command is ovs-vsctl show. The output of this command is printed from the lab environment with three nodes.

# ovs-vsctl show

22a0e0a2-7ac2-493a-9398-65e5683835e9

Bridge br-int

fail_mode: secure

Port br-int

Interface br-int

type: internal

Port "tap7fd27c60-32"

tag: 1

Interface "tap7fd27c60-32"

type: internal

Port patch-tun

Interface patch-tun

type: patch

options: {peer=patch-int}

Port int-br-ex

Interface int-br-ex

type: patch

options: {peer=phy-br-ex}

Port "qr-8d2a382b-01"

tag: 1

Interface "qr-8d2a382b-01"

type: internal

Bridge br-ex

Port "eth1"

Interface "eth1"

Port br-ex

Interface br-ex

type: internal

Port "qg-dbd535f0-05"

Interface "qg-dbd535f0-05"

type: internal

Port phy-br-ex

Interface phy-br-ex

type: patch

options: {peer=int-br-ex}

Bridge br-tun

fail_mode: secure

Port "gre-c0a87ad2"

Interface "gre-c0a87ad2"

type: gre

options: {df_default="true", in_key=flow, local_ip="10.0.2.15", out_key=flow, remote_ip="10.0.2.20"}

Port br-tun

Interface br-tun

type: internal

Port patch-int

Interface patch-int

type: patch

options: {peer=patch-tun}

Port "gre-c0a87ad7"

Interface "gre-c0a87ad7"

type: gre

options: {df_default="true", in_key=flow, local_ip="10.0.2.15", out_key=flow, remote_ip="10.0.2.30"}

ovs_version: "2.4.0"

As you can see, three bridges exist.

br-int is the integration bridge. There is one on each node. This bridge acts as a virtual switch where all virtual network cards from all virtual machines are connected. OVS Neutron agent automatically creates the integration bridge.
br-ex is the external bridge for interconnection with external networks. In our example, the eth1 physical interface is connected to this bridge.
br-tun is the tunnel bridge. It is a virtual switch like br-int. It connects the GRE and VXLAN tunnel endpoints. As you can see in our example, it connects the node with the IP address 10.0.2.15 and two others with IP 10.0.2.20 and 10.0.2.30. In our example, a GRE tunnel was used.

Here is an example of the code from a config file for neutron-openvswitch-agent.

# grep -o '^[^#]*' /etc/neutron/plugins/ml2/openvswitch_agent.ini

[DEFAULT]

[agent]

tunnel_types =vxlan,gre

vxlan_udp_port = 4789

l2_population = False

drop_flows_on_start = False

[ovs]

integration_bridge = br-int

tunnel_bridge = br-tun

local_ip = 10.0.2.15

enable_tunneling=True

[securitygroup]

firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

The Tip in Chapter 5 explains how RegEx can be used in the grep command.

Opening Virtual Networking (OVN)

OVN is an open source project launched by the Open vSwitch team. Open vSwitch (OVS) includes OVN starting with version 2.5. OVN has been released as a separate project since version 2.13.

Instead of the Neutron agents, it uses ovn-controller and OVS flows to support all functions.

The OVN northbound (NB) database stores the logical configuration, which it gets from the OVN ML2 plug-in. The plug-in runs on the controller nodes and listens on port 6641/TCP.

The northbound service converts the logical network configuration from the northbound database to the logical path flows. The ovn-northd service populates the OVN southbound database with the logical path flows. The service runs on the controller nodes.

The southbound (SB) database listens on port 6642/TCP. The ovn-controller connects to the Southbound database to control and monitor network traffic. This service runs on all compute nodes.

The OVN metadata agent runs the HAProxy instances. These instances manage the HAProxy instances, OVS interfaces, and namespaces. It runs on all compute nodes.

The OpenFlow protocol configures Open vSwitch and defines how network traffic will flow. OpenFlow can dynamically rewrite flow tables, allowing it to add and remove network functions as required.

Table 6-2 contrasts some differences between ML2 using OVS and OVN.

Table 6-2

Differences Between OVS and OVN

Area	OVS	OVN
DHCP Service	Provided by dnsmasq service per dhcp-xxx namespaces	OpenFlow rules by ovn-controller
High availability of dataplane	Implemented via creating qrourer namespace	OpenFlow rules by ovn-controller
Communication	RabbitMQ broker	Ovsdb protocol
Components of data plane	Veth, iptables, namespaces	OpenFlow rules
Metadata service	DHCP namespaces on controller nodes	Ovnmeta-xxx namespace on compute nodes

$ openstack network agent list

+--------------------------------------+----------------------+----------------+-------+-------+----------------------------+

+--------------------------------------+----------------------+----------------+-------+-------+----------------------------+

+--------------------------------------+----------------------+----------------+-------+-------+----------------------------+

$ openstack network agent list

+------+--------------------+------------------------+---------+-------+-------+---------------------------+

+------+--------------------+------------------------+---------+-------+-------+---------------------------+

| 02.. | Metadata agent | network.test.local | None | :-) | UP | neutron-metadata-agent |

| 25.. | Open vSwitch agent | network.test.local | None | :-) | UP | neutron-openvswitch-agent |

| 40.. | L3 agent | network.test.local | nova | :-) | UP | neutron-l3-agent |

| 59.. | DHCP agent | network.test.local | nova | :-) | UP | neutron-dhcp-agent |

+------+--------------------+------------------------+---------+-------+-------+---------------------------+

Managing Network Resources

Now let’s go through the process of creating all the necessary network resources for connecting an instance to the external world. For that, you can use the openstack or neutron command. Both commands have built-in help. Keep in mind that the Neutron CLI is deprecated and will be removed in the coming versions of OpenStack. This book only uses the OpenStack CLI. First, let’s create a flat external network. You should have an admin role before doing that.

$ source keystonerc_demo

$ openstack network create --share --external --provider-physical-network provider --provider-network-type flat ext-net

+---------------------------+--------------------------------------+

| Field | Value |

+---------------------------+--------------------------------------+

| admin_state_up | UP |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2022-07-17T17:43:17Z |

| description | |

| dns_domain | None |

| id | 5f18929b-70f6-4729-ac05-7bea494b9c5a |

| ipv4_address_scope | None |

| ipv6_address_scope | None |

| is_default | False |

| is_vlan_transparent | None |

| mtu | 1500 |

| name | ext-net |

| port_security_enabled | True |

| project_id | 27cdeded89d24fb49c11030b8cc87f15 |

| provider:network_type | flat |

| provider:physical_network | provider |

| provider:segmentation_id | None |

| qos_policy_id | None |

| revision_number | 1 |

| router:external | External |

| segments | None |

| shared | True |

| status | ACTIVE |

| subnets | |

| tags | |

| updated_at | 2022-07-17T17:43:17Z |

+---------------------------+--------------------------------------+

Tip

If you can’t create a network with type flat, add flat to the type_drivers option in the /etc/neutron/plugins/ml2/ml2_conf.ini config file. After changes, you need to restart the Neutron service.

The next step is to create a subnet for this network. It is an existing external network. You need to disable DHCP for this network.

$ openstack subnet create --network ext-net --no-dhcp --allocation-pool start=192.168.122.200,end=192.168.122.220 --gateway 192.168.122.1 --subnet-range 192.168.122.0/24 ext-subnet

+----------------------+--------------------------------------+

| Field | Value |

+----------------------+--------------------------------------+

| allocation_pools | 192.168.122.200-192.168.122.220 |

| cidr | 192.168.122.0/24 |

| created_at | 2022-07-17T17:56:32Z |

| description | |

| dns_nameservers | |

| dns_publish_fixed_ip | None |

| enable_dhcp | False |

| gateway_ip | 192.168.122.1 |

| host_routes | |

| id | d065c027-bb60-4464-9619-7d9754535c5c |

| ip_version | 4 |

| ipv6_address_mode | None |

| ipv6_ra_mode | None |

| name | ext-subnet |

| network_id | 5f18929b-70f6-4729-ac05-7bea494b9c5a |

| project_id | 27cdeded89d24fb49c11030b8cc87f15 |

| revision_number | 0 |

| segment_id | None |

| service_types | |

| subnetpool_id | None |

| tags | |

| updated_at | 2022-07-17T17:56:32Z |

+----------------------+--------------------------------------+

If you use Horizon for net and subnet creation, go to Project ➤ Network ➤ Networks, and click the Create Network button. You then see the window shown in Figure 6-3. Click the Next button to go to the Subnet tab.

Figure 6-3
Net creating dialog in Horizon

Now it is possible to check the work that has already been done. First, let’s check the list of all networks.

$ openstack network list

+--------------------------------------+---------+--------------------------------------+

| ID | Name | Subnets |

+--------------------------------------+---------+--------------------------------------+

| 5f18929b-70f6-4729-ac05-7bea494b9c5a | ext-net | d065c027-bb60-4464-9619-7d9754535c5c |

+--------------------------------------+---------+--------------------------------------+

Then you may want to check the details of ext-net.

$ openstack network show ext-net

+---------------------------+--------------------------------------+

| Field | Value |

+---------------------------+--------------------------------------+

| admin_state_up | UP |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2022-07-17T17:43:17Z |

| description | |

| dns_domain | None |

| id | 5f18929b-70f6-4729-ac05-7bea494b9c5a |

| ipv4_address_scope | None |

| ipv6_address_scope | None |

| is_default | False |

| is_vlan_transparent | None |

| mtu | 1500 |

| name | ext-net |

| port_security_enabled | True |

| project_id | 27cdeded89d24fb49c11030b8cc87f15 |

| provider:network_type | flat |

| provider:physical_network | provider |

| provider:segmentation_id | None |

| qos_policy_id | None |

| revision_number | 2 |

| router:external | External |

| segments | None |

| shared | True |

| status | ACTIVE |

| subnets | d065c027-bb60-4464-9619-7d9754535c5c |

| tags | |

| updated_at | 2022-07-17T17:56:32Z |

+---------------------------+--------------------------------------+

The corresponding Networks screen from Horizon is shown in Figure 6-4.

Figure 6-4
Properties of the chosen network in Horizon

You can do the rest of the work as a demo user from the demo project. The only action where you need an admin role is when you name the network as external. Now let’s create the tenant network.

$ source keystonerc_demo

$ openstack network create demo-net

+---------------------------+--------------------------------------+

| Field | Value |

+---------------------------+--------------------------------------+

| admin_state_up | UP |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2022-07-17T18:12:02Z |

| description | |

| dns_domain | None |

| id | 5ee4e933-de9b-4bcb-9422-83cc0d276d33 |

| ipv4_address_scope | None |

| ipv6_address_scope | None |

| is_default | False |

| is_vlan_transparent | None |

| mtu | 1442 |

| name | demo-net |

| port_security_enabled | True |

| project_id | 9e0c535c2240405b989afa450681df18 |

| provider:network_type | None |

| provider:physical_network | None |

| provider:segmentation_id | None |

| qos_policy_id | None |

| revision_number | 1 |

| router:external | Internal |

| segments | None |

| shared | False |

| status | ACTIVE |

| subnets | |

| tags | |

| updated_at | 2022-07-17T18:12:02Z |

+---------------------------+--------------------------------------+

You also need a subnet for your network.

$ openstack subnet create --network demo-net --gateway 172.16.0.1 --subnet-range 172.16.0.0/24 demo-subnet

+----------------------+--------------------------------------+

| Field | Value |

+----------------------+--------------------------------------+

| allocation_pools | 172.16.0.2-172.16.0.254 |

| cidr | 172.16.0.0/24 |

| created_at | 2022-07-17T18:14:52Z |

| description | |

| dns_nameservers | |

| dns_publish_fixed_ip | None |

| enable_dhcp | True |

| gateway_ip | 172.16.0.1 |

| host_routes | |

| id | 18736455-80f6-4513-9d81-6cedbfe271fe |

| ip_version | 4 |

| ipv6_address_mode | None |

| ipv6_ra_mode | None |

| name | demo-subnet |

| network_id | 5ee4e933-de9b-4bcb-9422-83cc0d276d33 |

| project_id | 9e0c535c2240405b989afa450681df18 |

| revision_number | 0 |

| segment_id | None |

| service_types | |

| subnetpool_id | None |

| tags | |

| updated_at | 2022-07-17T18:14:52Z |

+----------------------+--------------------------------------+

You then need to create a virtual router for routing traffic.

$ openstack router create demo-router

+-------------------------+--------------------------------------+

| Field | Value |

+-------------------------+--------------------------------------+

| admin_state_up | UP |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2022-07-17T18:16:19Z |

| description | |

| external_gateway_info | null |

| flavor_id | None |

| id | 3daad728-4075-49a4-ad05-3b279de738fa |

| name | demo-router |

| project_id | 9e0c535c2240405b989afa450681df18 |

| revision_number | 0 |

| routes | |

| status | ACTIVE |

| tags | |

| updated_at | 2022-07-17T18:16:19Z |

+-------------------------+--------------------------------------+

Now connect the router with the tenant subnet from one side.

$ openstack router add subnet demo-router demo-subnet

And from the other side, you need to set ext-net as a gateway for the router.

$ openstack router set --external-gateway ext-net demo-router

You can create a virtual router in Horizon by going to Project ➤ Network ➤ Router tab. An example of the router properties is shown in Figure 6-5.

Figure 6-5
Properties of a virtual router in Horizon

Now you can check all of the ports. Remember, it is the connection between a subnet and vNIC (or a virtual router).

$ source keystonerc_admin

$ openstack port list

+--------------------------------------+------+-------------------+----------------------------------------+--------+

+--------------------------------------+------+-------------------+----------------------------------------+--------+

+--------------------------------------+------+-------------------+----------------------------------------+--------+

Then you can get information about any chosen port.

$ openstack port show 5bcc90fc-9a54-4c91-9e6a-988ac0a4a4a8

+-------------------------+-----------------------------------------------+

| Field | Value |

+-------------------------+-----------------------------------------------+

| admin_state_up | UP |

| allowed_address_pairs | |

| binding_host_id | |

| binding_profile | |

| binding_vif_details | |

| binding_vif_type | unbound |

| binding_vnic_type | normal |

| created_at | 2022-07-17T18:17:36Z |

| data_plane_status | None |

| description | |

| device_id | 3daad728-4075-49a4-ad05-3b279de738fa |

| device_owner | network:router_interface |

| device_profile | None |

| dns_assignment | None |

| dns_domain | None |

| dns_name | None |

| extra_dhcp_opts | |

| fixed_ips | ip_address='172.16.0.1', subnet_id='18736455-80f6-4513-9d81-6cedbfe271fe' |

| id | 5bcc90fc-9a54-4c91-9e6a-988ac0a4a4a8 |

| ip_allocation | None |

| mac_address | fa:16:3e:2d:7b:4d |

| name | |

| network_id | 5ee4e933-de9b-4bcb-9422-83cc0d276d33 |

| numa_affinity_policy | None |

| port_security_enabled | False |

| project_id | 9e0c535c2240405b989afa450681df18 |

| propagate_uplink_status | None |

| qos_network_policy_id | None |

| qos_policy_id | None |

| resource_request | None |

| revision_number | 3 |

| security_group_ids | |

| status | ACTIVE |

| tags | |

| trunk_details | None |

| updated_at | 2022-07-17T18:17:37Z |

+-------------------------+-----------------------------------------------+

At this stage, you can start the instance and get an overall picture of a configured network by going to Project ➤ Network ➤ Network Topology. It is shown in Figure 6-6.

Figure 6-6
Network Topology tab in Horizon

At this point, you have only one missing part. Your instances within the tenant network can connect to each other, but none of the instances can reach out to an external network. You need to add a floating IP from ext-net to the virtual machine.

First, let’s create the floating IP. The default quota for the number of floating IPs is 10, which can be adjusted by anyone with admin capacity.

$ openstack floating ip create ext-net

+---------------------+--------------------------------------+

| Field | Value |

+---------------------+--------------------------------------+

| created_at | 2022-07-17T18:35:34Z |

| description | |

| dns_domain | |

| dns_name | |

| fixed_ip_address | None |

| floating_ip_address | 192.168.122.215 |

| floating_network_id | 5f18929b-70f6-4729-ac05-7bea494b9c5a |

| id | e41419bf-7642-4cc5-9569-cd7d546e0f62 |

| name | 192.168.122.215 |

| port_details | None |

| port_id | None |

| project_id | 9e0c535c2240405b989afa450681df18 |

| qos_policy_id | None |

| revision_number | 0 |

| router_id | None |

| status | DOWN |

| subnet_id | None |

| tags | [] |

| updated_at | 2022-07-17T18:35:34Z |

+---------------------+--------------------------------------+

Take a moment to locate the IP of the new floating IP from the output. You will need this IP soon. Next, determine which current IP is associated with the virtual machine.

$ openstack server list

+--------------------------------------+-------------+--------+-----------------------+--------------------------+---------+

+--------------------------------------+-------------+--------+-----------------------+--------------------------+---------+

+--------------------------------------+-------------+--------+-----------------------+--------------------------+---------+

Now you can associate the floating IP with the server.

$ openstack server add floating ip apressinst1 192.168.122.215

Let’s confirm that the VM got the new IP. The following shows the second external IP and the virtual machine properties.

$ openstack server list

+--------------------------------------+-------------+--------+----------------------------------------+--------------------------+----------+

+--------------------------------------+-------------+--------+----------------------------------------+--------------------------+----------+

+--------------------------------------+-------------+--------+----------------------------------------+--------------------------+----------+

You can find information about floating IPs in Horizon by going to Project ➤ Network ➤ Floating IPs (see Figure 6-7).

Managing Project Security Group Rules

Security groups are firewall rules that can filter ingress and egress traffic for virtual machines. In OVS, they are implemented by ML2 with iptables rules. The iptables rules could only be applied using a Linux bridge and were connected to the kernel using a tap device. OVN uses the conntrack module to implement them. Again, there are no differences between the user’s point of view and the exam’s point of view. To create the security group, use the following command.

$ openstack security group create apress-sgroup

+-----------------+-------------------------------------------------------+

| Field | Value |

+-----------------+-------------------------------------------------------+

| created_at | 2022-07-18T09:05:16Z |

| description | apress-sgroup |

| id | 7ec1083a-05c9-4df9-8b8e-941f0718e7b8 |

| name | apress-sgroup |

| project_id | 27cdeded89d24fb49c11030b8cc87f15 |

| revision_number | 1 |

| rules | created_at='2022-07-18T09:05:16Z', direction='egress', ethertype='IPv4', id='4a5c9c50-e8f2-4196-8d20-bf66435de42e', standard_attr_id='47', tenant_id='27cdeded89d24fb49c11030b8cc87f15', updated_at='2022-07-18T09:05:16Z' |

| | created_at='2022-07-18T09:05:16Z', direction='egress', ethertype='IPv6', id='7481b436-eabb-4358-8b72-968290929722', standard_attr_id='48', tenant_id='27cdeded89d24fb49c11030b8cc87f15', updated_at='2022-07-18T09:05:16Z' |

| stateful | True |

| tags | [] |

| updated_at | 2022-07-18T09:05:16Z |

+-----------------+-------------------------------------------------------+

Then you can add a rule. It provides SSH access (TCP port 22).

$ openstack security group rule create --protocol tcp --dst-port 22 apress-sgroup

+-------------------------+--------------------------------------+

| Field | Value |

+-------------------------+--------------------------------------+

| created_at | 2022-07-18T09:55:23Z |

| description | |

| direction | ingress |

| ether_type | IPv4 |

| id | 87291f07-420d-4b99-8eb2-edc3f8fd5082 |

| name | None |

| port_range_max | 22 |

| port_range_min | 22 |

| project_id | 27cdeded89d24fb49c11030b8cc87f15 |

| protocol | tcp |

| remote_address_group_id | None |

| remote_group_id | None |

| remote_ip_prefix | 0.0.0.0/0 |

| revision_number | 0 |

| security_group_id | 7ec1083a-05c9-4df9-8b8e-941f0718e7b8 |

| tags | [] |

| tenant_id | 27cdeded89d24fb49c11030b8cc87f15 |

| updated_at | 2022-07-18T09:55:23Z |

+-------------------------+--------------------------------------+

And you can also apply security groups to instances at boot time.

$ openstack server create --image cirros-0.5.2-x86_64 --flavor m1.tiny --network demo-net --security-group apress-sgroup apressinst2

+-----------------------------+-------------------------------------------+

| Field | Value |

+-----------------------------+-------------------------------------------+

| OS-DCF:diskConfig | MANUAL |

| OS-EXT-AZ:availability_zone | |

| OS-EXT-STS:power_state | NOSTATE |

| OS-EXT-STS:task_state | scheduling |

| OS-EXT-STS:vm_state | building |

| OS-SRV-USG:launched_at | None |

| OS-SRV-USG:terminated_at | None |

| accessIPv4 | |

| accessIPv6 | |

| addresses | |

| adminPass | 47Fcbt3ZiCxv |

| config_drive | |

| created | 2022-07-18T10:13:02Z |

| flavor | m1.tiny (1) |

| hostId | |

| id | b031aa84-ca26-4a17-b302-8929bb18f647 |

| image | cirros-0.5.2-x86_64 (7ffe1b43-7e86-4ad0-86b6-9fffa38b3c20) |

| key_name | None |

| name | apressinst2 |

| progress | 0 |

| project_id | 9e0c535c2240405b989afa450681df18 |

| properties | |

| security_groups | name='7748dc9f-1573-4225-a51e-8fc6328aafc0' |

| status | BUILD |

| updated | 2022-07-18T10:13:02Z |

| user_id | a20b5a5995b740ff90034297335b330a |

| volumes_attached | |

+-----------------------------+-------------------------------------------+

You can add or remove a security group on the fly.

$ openstack server add security group apressinst1 apress-sgroup

$ openstack server remove security group apressinst1 apress-sgroup

The following command lists the rules.

$ openstack security group rule list apress-sgroup

+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+

+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+

| fa9b7ece-2370-4060-9c2d-649dd3b13064 | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | None | None |

+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+

You can find information about security groups in Horizon by going to Project ➤ Network ➤ Security Groups, as shown in Figure 6-8.

Figure 6-8
Security Groups tab in Horizon

Managing Quotas

A quota limits the number of available resources. The default number of resources allowed per project can be retrieved by an admin using the openstack quota list command. Here is an example.

$ openstack quota list --network --detail

+----------------------+--------+----------+-------+

+----------------------+--------+----------+-------+

| floating_ips | 1 | 0 | 50 |

| networks | 1 | 0 | 100 |

| ports | 1 | 0 | 500 |

| rbac_policies | 2 | 0 | 10 |

| routers | 0 | 0 | 10 |

| subnets | 1 | 0 | 100 |

| subnet_pools | 0 | 0 | -1 |

| security_group_rules | 7 | 0 | 100 |

| security_groups | 2 | 0 | 10 |

+----------------------+--------+----------+-------+

The corresponding section of the Horizon interface is presented in Figure 6-9. You can find it by clicking Admin ➤ System ➤ Defaults and then selecting the Network Quotas tab.

Regular users can get their project quotas with the openstack quota show and openstack quota show --default commands.

$ openstack quota show

+-----------------------+-------------------------------------------------+

| Field | Value |

+-----------------------+-------------------------------------------------+

| backup-gigabytes | 1000 |

| backups | 10 |

| cores | 20 |

| fixed-ips | -1 |

| floating-ips | 50 |

| gigabytes | 1000 |

| gigabytes___DEFAULT__ | -1 |

| gigabytes_iscsi | -1 |

| groups | 10 |

| injected-file-size | 10240 |

| injected-files | 5 |

| injected-path-size | 255 |

| instances | 10 |

| key-pairs | 100 |

| location | Munch({'cloud': '', 'region_name': 'RegionOne', 'zone': None, 'project': Munch({'id': '9e0c535c2240405b989afa450681df18', 'name': 'demo', 'domain_id': None, 'domain_name': 'Default'})}) |

| networks | 100 |

| per-volume-gigabytes | -1 |

| ports | 500 |

| project | 9e0c535c2240405b989afa450681df18 |

| project_name | demo |

| properties | 128 |

| ram | 51200 |

| rbac_policies | 10 |

| routers | 10 |

| secgroup-rules | 100 |

| secgroups | 10 |

| server-group-members | 10 |

| server-groups | 10 |

| snapshots | 10 |

| snapshots___DEFAULT__ | -1 |

| snapshots_iscsi | -1 |

| subnet_pools | -1 |

| subnets | 100 |

| volumes | 10 |

| volumes___DEFAULT__ | -1 |

| volumes_iscsi | -1 |

+-----------------------+-------------------------------------------------+

Admins can do the same, but only for any project by adding the project’s name. If an admin needs to change the quotas for a particular project, the openstack quota set command is used.

$ openstack quota set

usage: openstack quota set [-h] [--class] [--cores <cores>] [--fixed-ips <fixed-ips>] [--injected-file-size <injected-file-size>]

[--injected-path-size <injected-path-size>] [--injected-files <injected-files>] [--instances <instances>]

[--key-pairs <key-pairs>] [--properties <properties>] [--ram <ram>] [--server-groups <server-groups>]

[--server-group-members <server-group-members>] [--backups <backups>] [--backup-gigabytes <backup-gigabytes>]

[--gigabytes <gigabytes>] [--per-volume-gigabytes <per-volume-gigabytes>] [--snapshots <snapshots>] [--volumes <volumes>]

[--floating-ips <floating-ips>] [--secgroup-rules <secgroup-rules>] [--secgroups <secgroups>] [--networks <networks>]

[--subnets <subnets>] [--ports <ports>] [--routers <routers>] [--rbac-policies <rbac-policies>]

[--subnetpools <subnetpools>] [--volume-type <volume-type>] [--force] [--check-limit]

$ openstack quota set --secgroups 99 apress

Admins can manage quotas on a per-project basis in Horizon by going to Identity ➤ Projects ➤ Modify Quotas through the drop-down menu to the right of the project’s name. Part of the network’s Edit Quotas page is shown in Figure 6-10. A user can check the overall limits, including Neutron quotas, in Horizon by going to Project ➤ Compute ➤ Overview tab.

Verifying the Operation of the Network Service

Neutron consists of several components. Its configuration files were listed at the beginning of this chapter. The Neutron API service is bound to port 9696. The log file for the Neutron server is available at /var/log/neutron/server.log.

You can check the supported extension for Neutron with the following command.

$ openstack extension list --network

+--------------------------------------------------------------------------------+---------------------------------------------+---------------------------------------------------------------------------------+

| Name | Alias | Description |

| Address group | address-group | Support address group |

| Address scope | address-scope | Address scopes extension. |

| agent | agent | The agent management extension. |

| Allowed Address Pairs | allowed-address-pairs | Provides allowed address pairs |

| Auto Allocated Topology Services | auto-allocated-topology | Auto Allocated Topology Services. |

| Availability Zone | availability_zone | The availability zone extension. |

| Default Subnetpools | default-subnetpools | Provides ability to mark and use a subnetpool as the default. |

| DNS Integration | dns-integration | Provides integration with DNS. |

| dns_domain for ports | dns-domain-ports | Allows the DNS domain to be specified for a network port. |

| DNS domain names with keywords allowed | dns-integration-domain-keywords | Allows to use keywords like <project_id>, <project_name>, <user_id> and <user_name> as DNS domain name |

| Neutron external network | external-net | Adds external network attribute to network resource. |

| Neutron Extra DHCP options | extra_dhcp_opt | Extra options configuration for DHCP. For example PXE boot options to DHCP clients can be specified (e.g. tftp-server, server-ip-address, bootfile-name) |

| Neutron Extra Route | extraroute | Extra routes configuration for L3 router |

| Filter parameters validation | filter-validation | Provides validation on filter parameters. |

| Floating IP Port Details Extension | fip-port-details | Add port_details attribute to Floating IP resource |

| Neutron Service Flavors | flavors | Flavor specification for Neutron advanced services. |

| Floating IP Pools Extension | floatingip-pools | Provides a floating IP pools API. |

| Neutron L3 Router | router | Router abstraction for basic L3 forwarding between L2 Neutron networks and access to external networks via a NAT gateway. |

| Neutron L3 Configurable external gateway mode | ext-gw-mode | Extension of the router abstraction for specifying whether SNAT should occur on the external gateway |

| Multi Provider Network | multi-provider | Expose mapping of virtual networks to multiple physical networks |

| Network MTU | net-mtu | Provides MTU attribute for a network resource. |

| Network MTU (writable) | net-mtu-writable | Provides a writable MTU attribute for a network resource. |

| Network Availability Zone | network_availability_zone | Availability zone support for network. |

| Network IP Availability | network-ip-availability | Provides IP availability data for each network and subnet. |

| Pagination support | pagination | Extension that indicates that pagination is enabled. |

| Port device profile | port-device-profile | Expose the port device profile (Cyborg) |

| Neutron Port MAC address regenerate | port-mac-address-regenerate | Network port MAC address regenerate |

| Port NUMA affinity policy | port-numa-affinity-policy | Expose the port NUMA affinity policy |

| Port Resource Request | port-resource-request | Expose resource request to Port |

| Port Resource Request Groups | port-resource-request-groups | Support requesting multiple groups of resources and traits from the same RP subtree in resource_request |

| Port Binding | binding | Expose port bindings of a virtual port to external application |

| Port Bindings Extended | binding-extended | Expose port bindings of a virtual port to external application |

| Port Security | port-security | Provides port security |

| project_id field enabled | project-id | Extension that indicates that project_id field is enabled. |

| Provider Network | provider | Expose mapping of virtual networks to physical networks |

| Quality of Service | qos | The Quality of Service extension. |

| Direction for QoS bandwidth limit rule | qos-bw-limit-direction | Allow to configure QoS bandwidth limit rule with specific direction: ingress or egress |

| Ingress direction for QoS minimum bandwidth rule | qos-bw-minimum-ingress | Allow to configure QoS minumum bandwidth rule with ingress direction. |

| QoS default policy | qos-default | Expose the QoS default policy per project |

| Floating IP QoS | qos-fip | The floating IP Quality of Service extension |

| QoS port network policy ID | qos-port-network-policy | Adds a the QoS network ID to the port definition |

| QoS minimum packet rate rule | qos-pps-minimum | Allow to configure QoS minimum packet rate rule. |

| QoS minimum packet rate rule alias | qos-pps-minimum-rule-alias | API to enable GET, PUT and DELETE operations on QoS minimum packet rate rule without specifying policy ID |

| QoS Rule Type Packet per Second Extension | qos-pps | Add QoS Rule Type Packet per Second |

| Details of QoS rule types | qos-rule-type-details | Expose details about QoS rule types supported by loaded backend drivers |

| Quality of Service rules alias API | qos-rules-alias | API to enable GET, PUT and DELETE operations on QoS policy rules without specifying policy ID |

| Quota engine limit check | quota-check-limit | Support for checking the resource usage before applying a new quota limit |

| Quota management support | quotas | Expose functions for quotas management per project |

| Quota details management support | quota_details | Expose functions for quotas usage statistics per project |

| RBAC Policies | rbac-policies | Allows creation and modification of policies that control tenant access to resources. |

| Add address_scope type to RBAC | rbac-address-scope | Add address_scope type to RBAC |

| Add security_group type to network RBAC | rbac-security-groups | Add security_group type to network RBAC |

| If-Match constraints based on revision_number | revision-if-match | Extension indicating that If-Match based on revision_number is supported. |

| Resource revision numbers | standard-attr-revisions | This extension will display the revision number of neutron resources. |

| Router Availability Zone | router_availability_zone | Availability zone support for router. |

| Normalized CIDR field for security group rules | security-groups-normalized-cidr | Add new field with normalized remote_ip_prefix cidr in SG rule |

| Remote address group id field for security group rules | security-groups-remote-address-group | Add new field of remote address group id in SG rules |

| Security group filtering on the shared field | security-groups-shared-filtering | Support filtering security groups on the shared field |

| security-group | security-group | The security groups extension. |

| Neutron Service Type Management | service-type | API for retrieving service providers for Neutron advanced services |

| Sorting support | sorting | Extension that indicates that sorting is enabled. |

| standard-attr-description | standard-attr-description | Extension to add descriptions to standard attributes |

| Stateful security group | stateful-security-group | Indicates if the security group is stateful or not |

| Subnet DNS publish fixed IP | subnet-dns-publish-fixed-ip | Support choosing to publish DNS records for IPs from a subnet |

| Subnet service types | subnet-service-types | Provides ability to set the subnet service_types field |

| Subnet Allocation | subnet_allocation | Enables allocation of subnets from a subnet pool |

| Tag support for resources with standard attribute: port, subnet, subnetpool, network, security_group, router, floatingip, policy, trunk, network_segment_range | standard-attr-tag | Enables to set tag on resources with standard attribute. |

| Resource timestamps | standard-attr-timestamp | Adds created_at and updated_at fields to all Neutron resources that have Neutron standard attributes. |

| Trunk Extension | trunk | Provides support for trunk ports |

| Trunk port details | trunk-details | Expose trunk port details |

And you can check the state of the running agents with the following command.

$ openstack network agent list

+--------------------------------------+----------------------+----------------+-------------------+-------+-------+----------------------------+

+--------------------------------------+----------------------+----------------+-------------------+-------+-------+----------------------------+

+--------------------------------------+----------------------+----------------+-------------------+-------+-------+----------------------------+

Summary

It is essential to study this chapter’s material to pass the exam. You may not need to dig into the differences between OVS and OVN, but you must know the practical aspects of using a network in OpenStack.

The next chapter covers OpenStack’s compute services.

Review Questions

1.
Which service provides routing and NAT in OVS-enabled OpenStack?
1. A.
  neutron-server
2. B.
  neutron-openvswitch-agent
3. C.
  neutron-l3-agent
4. D.
  neutron-metadata-agent
2.
Which checks the status of running Neutron agents?
1. A.
  neutron agent-list
2. B.
  openstack network agent show
3. C.
  openstack network agent list
4. D.
  neutron agents-list
3.
Which is the Neutron API service config?
1. A.
  /etc/neutron/neutron.conf
2. B.
  /etc/neutron.conf
3. C.
  /etc/neutron/plugin.ini
4. D.
  /etc/neutron/api-server.conf
4.
Which correctly adds a new rule to an existing security group?
1. A.
  openstack security group rule create --protocol tcp --dst-port 22 apress-sgroup
2. B.
  openstack sgroup rule create --protocol tcp --dst-port 22 apress-sgroup
3. C.
  openstack sgroup rule create apress-sgroup --protocol tcp --dst-port 22
4. D.
  openstack security-group rule create --protocol tcp --dst-port 22 apress-sgroup
5.
Where is the Neutron API log file located?
1. A.
  /var/log/neutron/neutron.log
2. B.
  /var/log/neutron/server.log
3. C.
  /var/log/neutron/api.log
4. D.
  /var/log/neutron/api-server.log

Answers

1.
B
2.
B
3.
A
4.
A
5.
B

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 6. OpenStack Networking

Create new playlist

Sign In

Sign Up

6. OpenStack Networking

Neutron’s Architecture and Components

Opening vSwitch’s Architecture

Opening Virtual Networking (OVN)

Managing Network Resources

Managing Project Security Group Rules

Managing Quotas

Verifying the Operation of the Network Service

Summary

Review Questions

Answers

Table of Contents for
6. OpenStack Networking