CL110 - ch03s05

Bookmark this page

Implementing Tenant, Provider and External Networks

Objectives

After completing this section, you should be able to describe and compare the network types available to self-service cloud users, including tenant, external and provider networks.

OpenStack Networking

A domain operator can select between tenant, router, provider, and external networks. This section describes these network type differences.

The OpenStack networking service (Neutron) provides software-defined networking (SDN). SDN provides the ability to define and manage networks and subnets in the software layer, without having to change hardware settings. Network namespaces allow these networks to overlap (for example, two networks using the same 192.168.0.0/24 subnet can be defined) without conflict.

Project Networking

Self-service, or tenant, networks are a common network type in many OpenStack installations. Tenant networks contain only virtual components. Only instances within the project can use project tenant networks. Projects are not concerned with the underlying physical network because tenant networks are isolated by default. Tenant networks can be connected to each other or to an external network through a router.

The following diagram shows three separate projects all with their own network. Each project has a router joined to the external network providing access to the public network.

Figure 3.10: The self-service tenant networking scenario

Tenant networks are created by default with the external parameter set to no, and the shared parameter set to no. A user with administrator privileges can share tenant networks. In that case the external parameter is set to no and the shared parameter is set to yes.

Instances that require external access must be created on a network with a router that provides access to the public network. A floating IP address must be added to instance because the fixed IP address assigned at creation cannot be used on the public network. NAT provides the translation between the fixed IP address and the floating IP address. Floating IPs, routing and NAT will be explained in more detail later in the course.

Systems protected from all public access, for example database servers, are deployed in a tenant with no router providing external access. These systems are accessed by other application VMs over a shared tenant network.

The following diagram shows multi-project networking and GENEVE tunneling. A packet sent from an instance in Project A, on Network A1 on the local platform to the same project on the remote platform would be assigned the VLAN ID 101 as it left the tenant network. The packet is sent to the local router, over the WAN to the remote router. The tunnel bridge on the remote platform reads the VLAN-ID of 101 and sends the packet to Network A1 on the remote platform. The packet is then sent to the correct instance within Project A. OVN implements a single distributed OVN layer 2 switch across all compute nodes. This simplifies the overall network architecture.

Figure 3.11: The self-service tenant networking scenario using tunneling to remote overcloud nodes

Provider Networks

Provider networks, or Data Center networks, are created on physical network VLANs in the data center. The default overlay protocol in Red Hat OpenStack is GENEVE. Provider networks use addresses taken directly from the physical network infrastructure, and rely on the physical network routers to operate as their default gateway. They generally do not implement DHCP because it would conflict with data center DHCP servers. Instead, the appropriate administrator would assign an allocation pool to be used by the provider network. Provider networks can only be created by OpenStack administrators and are shared with tenant projects.

Provider networks can also be of type flat or VLAN. A VLAN provider network only needs one NIC and uses 802.1Q tagging. The VLAN ID is stored in the provider:segmentation_id parameter. A flat network requires one NIC per provider network and does not use tagging.

Tenant networks allow address scope overlap by using routers and NAT tables to isolate the internal fixed addresses from floating IP addresses. Provider network instances do not require a floating IP address or router for external access. Only instances within tenant networks require that extra configuration for external access.

Figure 3.12: The provider networking scenario using a data center provided hardware switch with VLANs.

Attaching an instance to a provider network allows the instance to have a layer 2 connection to the upstream networks in the organization. An instance attached to a tenant network can only connect to the organization's upstream network if the tenant network is attached to an OpenStack router that has an external network connected.

Provider networks can be external networks by setting the external parameter to yes, and the shared parameter to no at creation. Provider networks that are not external have the external parameter set to yes, and the shared parameter also set to yes. External networks created by a user with administrator privileges requires a floating IP address pool.

Provider networks cannot be created by normal cloud users or the domain operator. They are normally created when the cloud is first built.

Viewing Network and Subnet Parameters

View the network parameters to determine the network types that are in use.

Tenant Networks and Subnets

Use the openstack network show command to show network details. Use the --max-width option to make the output readable. In this example, the network type is geneve, no physical network is attached, the segmentation ID is 55, the router is Internal, and it is not shared.

[user@demo ~(admin)]$ openstack network show demo-network1 \
> --max-width 80
+---------------------------+--------------------------------------------------+
| Field                     | Value                                            |
+---------------------------+--------------------------------------------------+
...output omitted...
|                           | project.name=, region_name='regionOne', zone=    |
| mtu                       | 1442                                             |
| name                      | demo-network1                                    |
| port_security_enabled     | True                                             |
| project_id                | da15c1dc193d49c3b26a824d129cdf7c                 |
| provider:network_type     | geneve                                           |
| provider:physical_network | None                                             |
| provider:segmentation_id  | 55                                               |
| qos_policy_id             | None                                             |
| revision_number           | 2                                                |
| router:external           | Internal                                         |
| segments                  | None                                             |
| shared                    | False                                            |
| status                    | ACTIVE                                           |
| subnets                   | bf18c042-4d70-4404-9103-fa63a6210319             |
| tags                      |                                                  |
| updated_at                | 2020-06-10T09:28:17Z                             |
+---------------------------+--------------------------------------------------+

Each network requires a subnet for addressing. View the subnet for demo-network1 using either the subnet name or ID. The subnet ID is found using the openstack network show command.

In this example, the allocation_pools parameter was not defined when the subnet was created. Without a defined pool, a subnet is assigned a default pool for the entire CIDR network minus the broadcast and gateway addresses. In our example, 192.168.1.2-192.168.1.254. Note the DNS name server, the IP version, and that DHCP is enabled.

[user@demo ~(admin)]$ openstack subnet show \
> bf18c042-4d70-4404-9103-fa63a6210319 --max-width 80
+-------------------+----------------------------------------------------------+
| Field             | Value                                                    |
+-------------------+----------------------------------------------------------+
| allocation_pools  | 192.168.1.2-192.168.1.254                                |
| cidr              | 192.168.1.0/24                                           |
| created_at        | 2020-06-10T09:28:17Z                                     |
| description       |                                                          |
| dns_nameservers   | 172.25.250.254                                           |
| enable_dhcp       | True                                                     |
| gateway_ip        | 192.168.1.1                                              |
| host_routes       |                                                          |
| id                | bf18c042-4d70-4404-9103-fa63a6210319                     |
| ip_version        | 4                                                        |
| ipv6_address_mode | None                                                     |
| ipv6_ra_mode      | None                                                     |
| location          | cloud='', project.domain_id=, project.domain_name=,      |
|                   | project.id='da15c1dc193d49c3b26a824d129cdf7c',           |
|                   | project.name=, region_name='regionOne', zone=            |
| name              | demo-subnet1                                             |
| network_id        | 97869871-708a-40f1-9850-350f5d2fdccb                     |
| prefix_length     | None                                                     |
| project_id        | da15c1dc193d49c3b26a824d129cdf7c                         |
| revision_number   | 0                                                        |
| segment_id        | None                                                     |
| service_types     |                                                          |
| subnetpool_id     | None                                                     |
| tags              |                                                          |
| updated_at        | 2020-06-10T09:28:17Z                                     |
+-------------------+----------------------------------------------------------+

Provider Networks

The following example shows a provider network and subnet. The provider network has no network type, there is no physical network, the router type is External, and it is shared.

[user@demo ~(admin)]$ openstack network show \
> provider-datacentre --max-width 80
+---------------------------+--------------------------------------------------+
| Field                     | Value                                            |
+---------------------------+--------------------------------------------------+
...output omitted...
| name                      | provider-datacentre                              |
| port_security_enabled     | True                                             |
| project_id                | b04181074c884a89acc6469595599083                 |
| provider:network_type     | None                                             |
| provider:physical_network | None                                             |
| provider:segmentation_id  | None                                             |
| qos_policy_id             | None                                             |
| revision_number           | 2                                                |
| router:external           | External                                         |
| segments                  | None                                             |
| shared                    | True                                             |
| status                    | ACTIVE                                           |
| subnets                   | 655df137-b2e3-4e3d-9b52-98221b7abf24             |
| tags                      |                                                  |
| updated_at                | 2020-04-19T11:05:12Z                             |
+---------------------------+--------------------------------------------------+

Using the subnet ID from the output of the provider network, show the details of the subnet. Note the allocation_pools. If a user creates a floating IP address it will come from this allocation pool. Note that the DNS name server and the gateway have the same IP address. DHCP is switched off.

[user@demo ~(admin)]$ openstack subnet show \
> 655df137-b2e3-4e3d-9b52-98221b7abf24 --max-width 80
+-------------------+----------------------------------------------------------+
| Field             | Value                                                    |
+-------------------+----------------------------------------------------------+
| allocation_pools  | 172.25.250.101-172.25.250.189                            |
| cidr              | 172.25.250.0/24                                          |
| created_at        | 2020-04-19T11:05:12Z                                     |
| description       |                                                          |
| dns_nameservers   | 172.25.250.254                                           |
| enable_dhcp       | False                                                    |
| gateway_ip        | 172.25.250.254                                           |
| host_routes       |                                                          |
| id                | 655df137-b2e3-4e3d-9b52-98221b7abf24                     |
| ip_version        | 4                                                        |
...output omitted...
| name              | provider-subnet-172.25.250                               |
...output omitted...

Use the ovs-vsctl command on the controller node to list the bridges. here is a patch port linking br-int to the br-ex bridge for the provider network. The ID of that port matches the provider-datacentre provider network. On br-int the tunnel type for the interface is geneve.

If you do not see patch ports in this listing, it is because you have not created routers that need the access. You must create a router with an external gateway set, causing OVN to create the patch ports automatically for the external access. Routers are covered in detail in a later chapter.

[root@controller0 ~]# ovs-vsctl show
...output omitted...
Bridge br-ex
    fail_mode: standalone
    Port br-ex
         Interface br-ex
              type: internal
    Port "eth2"
        Interface "eth2"
    Port "patch-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798-to-br-int"
        Interface "patch-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798-to-br-int"
             type: patch
             options: {peer="patch-br-int-to-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798"}

Bridge br-int
    fail_mode: secure
    Port "ovn-0102a3-0"
        Interface "ovn-0102a3-0"
             type: geneve
             options: {csum="true", key=flow, remote_ip="172.24.2.12"}
   Port "patch-br-int-to-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798"
       Interface "patch-br-int-to-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798"
             type: patch
             options: {peer="patch-provnet-ef95203b-7c9f-46c0-b328-e51aa7729798-to-br-int"}
   Port "ovn-1af225-0"
       Interface "ovn-1af225-0"
            type: geneve
            options: {csum="true", key=flow, remote_ip="172.24.2.6"}
   Port "o-hm0"
       Interface "o-hm0"
            type: internal
   Port "ovn-a643d0-0"
       Interface "ovn-a643d0-0"
            type: geneve
            options: {csum="true", key=flow, remote_ip="172.24.2.2"}
...output omitted...

There are three IP addresses on br-int, the ports for compute1, compute0, and computehci0. This can be verified by listing the installed hypervisors.

[user@demo ~(admin)]$ openstack hypervisor list \
> -c "Hypervisor Hostname" -c "Host IP"
+-----------------------------------+-------------+
| Hypervisor Hostname               | Host IP     |
+-----------------------------------+-------------+
| compute0.overcloud.example.com    | 172.24.1.2  |
| computehci0.overcloud.example.com | 172.24.1.6  |
| compute1.overcloud.example.com    | 172.24.1.12 |
+-----------------------------------+-------------+

Viewing the Networks using the Dashboard

You can view the same information from the Dashboard about tenant and provider networks. The Network Topology page provides a simple layout of the entire network. It is useful when troubleshooting networking issues.

Navigate to Project+Network → Network Topology.

Click each element of the infrastructure: networks, routers, and instances. Clicking on a tenant network displays the Overview page with important information. For a tenant network the Shared status is No, the External Network is no, the Provider Network type is geneve, and the Segmentation ID is displayed.

Figure 3.13: Network description in the Dashboard

Click Subnets and then click the name of the subnet. On the page that opens you can see the Name, the IP Allocation Pools, Gateway IP, and whether or not DHCP is enabled.

Figure 3.14: Subnet description in the Dashboard

Go back to the network and click Ports. On this page you can see the fixed IP address, MAC address, any attached devices, and the status of the port.

Clicking on a provider network will provide the same information as a tenant network. In our example, you can see that the Shared status is Yes, the External Network is Yes, and the Provider Network Type is flat. There is also no Segmentation ID.

Figure 3.15: Provider network description in the Dashboard

In the Subnets section notice that the provider network does not have a Subnet Pool. However, there is an IP Allocation Pool and a Gateway IP. DHCP is not enabled.

Figure 3.16: Provider subnet description in the Dashboard

In the Ports section, if there are floating IPs created for the provider network, each one will show up as a different port in the list.

Figure 3.17: Floating IP list in the Dashboard

References

Further information is available in multiple sections of the Networking Guide for Red Hat OpenStack Platform at https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/networking_guide/index/

Further information is available in the Deployment Scenarios section of the Networking Guide for OpenStack at https://docs.openstack.org/

Discuss Red Hat OpenStack Administration I: Core Operations for Domain Operators

Go to community

Red Hat OpenStack Administration I: Core Operations for Domain Operators (CL110)

Haley_Ruccio

1 sie 2023

Learn to operate a Red Hat® OpenStack Platform private cloud and manage domain resources to secure and deploy modern, scalable cloud applications, networks and storageRed Hat OpenStack Administration I: Core Operations for Domain Operators (CL110) teaches you how to operate and manage a production Red Hat OpenStack Platform (RHOSP) single-site overcloud. You will learn how to create secure project environments in which to provision resources and manage security privileges that cloud users need to deploy scalable cloud applications. You will learn about OpenShift integration with load balancers, identity management, monitoring, proxies, and storage. You will also develop more troubleshooting and Day 2 operations skills in this course.This course is based on Red Hat OpenStack Platform 16.1.Course content summaryStudents in the Red Hat OpenStack Administration I: Core Operations for Domain Operators (CL110) course will focus on performing both routine and specialized tasks that are necessary to manage a production OpenStack overcloud domain. Students will manage OpenStack using both web-based and command-line interfaces. Essential skills covered in the course include the following:Launch instances to satisfy various use case examples.Manage domains, projects, users, roles, and quota in a multitenant environment.Manage networks, subnets, routers, and floating IP addresses.Manage instance security with group rules and access keys.Create and manage block, object and shared storage within OpenStack.Perform instance launch customization with cloud-init.Deploy scalable applications using stack templates.Audience for this courseThis course is designed for cloud users who deploy application instances and stacks, domain operators who manage resources and security for cloud users, and any other cloud personnel interested in, or responsible for, maintaining applications on private or hybrid OpenStack clouds. Any cloud persona, or personnel with roles that include performing technology evaluation, should attend this course to learn RHOSP operation and application deployment methods.Prerequisites for this courseBecome a Red Hat Certified System Administrator (RHCSA) or demonstrate equivalent experienceIf you are not a RHCSA, you can take a skill assessment to gauge your level of knowledge.

Welcome to the Red Hat OpenStack Administration I (CL110) group in the Red Hat Learning Community!

Syed

31 lip 2023

We are excited to launch a space dedicated to the Red Hat Training course CL110! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to CL110.Read more about Red Hat OpenStack Administration I: Core Operations for Domain Operators here.

Revision: cl110-16.1-4c76154