Understanding OpenStack Networking Concepts in Horizon

OpenStack networking, powered by the Neutron service, provides flexible software-defined networking for your cloud infrastructure. Understanding how these networking components work together is essential for building secure, well-connected cloud environments. This guide explains the core networking concepts you'll encounter in the Horizon dashboard and how they relate to each other.

Understanding Networking in the Horizon Dashboard

The Horizon dashboard organizes networking features under the Project > Network menu. This section contains all the tools you need to manage your virtual network infrastructure.

1. Navigate to the Project menu in the left sidebar of the Horizon dashboard.
2. Expand the Network section to reveal the primary networking components: Networks, Routers, Security Groups, and Floating IPs.
3. Click on Networks to view your existing network infrastructure. Each network represents a virtual Layer 2 broadcast domain, similar to a physical network switch.
4. Select the Routers option to see the routing devices that connect different networks together. Routers operate at Layer 3 and enable traffic to flow between isolated networks.
5. Access Security Groups to manage firewall rules that control traffic to and from your instances. Security groups act as virtual firewalls at the instance level.
6. Use the Floating IPs section to manage public IP addresses that can be associated with instances to provide external connectivity.
7. Within the Network Topology view (Project > Network > Network Topology), observe the visual representation of how your networks, routers, and instances connect. This interactive diagram helps you understand the relationships between components.
8. Click on any individual network name to view its details, including associated subnets, ports, and DHCP settings. This detailed view shows how the network is configured and what resources are connected to it.

Understanding Networking via CLI

The OpenStack command-line interface provides detailed control over networking components. These commands help you inspect and manage your network infrastructure.

1. List all networks in your project to see available network resources:

1openstack network list
Copy

2. View detailed information about a specific network, including its subnets and status:

1openstack network show <network-name-or-id>
Copy

3. List all subnets to see the IP address ranges allocated within networks:

1openstack subnet list
Copy

4. Display router information to understand how traffic is being routed:

1openstack router list
2openstack router show <router-name-or-id>
Copy

5. View ports to see the connection points where instances attach to networks:

1openstack port list
Copy

6. List floating IP addresses and their associations:

1openstack floating ip list
Copy

7. Check security groups and their rules to understand traffic filtering:

1openstack security group list
2openstack security group show <security-group-name-or-id>
Copy

8. View the network topology and connections using detailed show commands:

1openstack router show <router-name> --fit-width
Copy

How OpenStack Networking is Organized

OpenStack networking is built on the Neutron service, which provides "networking as a service" capabilities. Neutron creates a software-defined network layer that abstracts physical networking hardware, allowing you to build complex network topologies entirely through software.

At the foundation, networks create isolated Layer 2 segments. Think of each network as a virtual switch that provides a broadcast domain for connected resources. Networks can be private (accessible only within your project) or external (providing connectivity to networks outside OpenStack, typically the internet).

Within each network, you define one or more subnets. A subnet represents an IP address range using CIDR notation, such as 192.168.1.0/24. Subnets provide the actual IP addressing scheme for resources connected to the network. Each subnet includes configuration for DNS servers, gateway addresses, and IP allocation pools.

Ports serve as the connection points between networks and resources. When you launch an instance, Neutron automatically creates a port on the selected network and assigns an IP address from the subnet's pool. Each port has a unique MAC address and can have multiple IP addresses assigned to it.

Routers connect different networks together and enable traffic to flow between them. A router typically connects your private project networks to an external network, allowing instances to reach the internet or other external networks. Routers maintain routing tables and perform Network Address Translation (NAT) when necessary.

The Project > Network Menu Structure

The Network section in Horizon's Project menu organizes networking components logically based on their function:

Networks is where you create and manage your virtual networks. This is the starting point for building network infrastructure. Here you define the Layer 2 segments that will contain your instances.

Routers contains the routing devices that interconnect networks. Without a router, networks remain isolated from each other. Routers are essential for both internal connectivity between project networks and external connectivity to the internet.

Security Groups manages the firewall rules that protect your instances. Security groups define allowed traffic patterns based on protocol, port, and source/destination IP addresses. All instances must belong to at least one security group.

Floating IPs provides the pool of public IP addresses that can be dynamically associated with instances. Floating IPs enable external access to instances that reside on private networks.

Relationship Between Networking Components

Understanding how networking components relate to each other is crucial for building functional network architectures.

A network serves as the container for subnets. You can have multiple subnets within a single network, though each subnet must use a different IP address range. Multiple subnets in one network can be useful for segmenting resources while keeping them on the same Layer 2 domain.

Subnets provide IP addresses to ports. When a port is created on a network, it receives an IP address from one of the network's subnet pools. The subnet's DHCP configuration determines how IP addresses are assigned and what additional network information (DNS, routes) is provided to instances.

Ports connect instances to networks. Each network interface on an instance corresponds to a port object in Neutron. Ports maintain the binding between an instance and a network, storing the MAC address and IP address assignments.

Routers connect networks by having interfaces in multiple networks. A router typically has one interface in a private network and a gateway connection to an external network. The router forwards packets between these networks based on its routing table.

Security groups attach to ports and control traffic at the instance level. Each port can be associated with one or more security groups, and the rules are applied in aggregate. Security groups are stateful, meaning return traffic for allowed outbound connections is automatically permitted.

Floating IPs provide a one-to-one NAT mapping between a public IP address and an instance's private IP address. The floating IP is associated with a port, and the router performs the translation between the public and private addresses.

Private vs External Networks

OpenStack distinguishes between private and external networks, each serving different purposes in your infrastructure.

Private networks are project-specific networks that you create and manage. These networks are isolated from other projects and from external networks by default. Instances attached to private networks receive IP addresses from RFC 1918 private address space (such as 10.0.0.0/8 or 192.168.0.0/16). Private networks are ideal for internal communication between instances without exposing services to the internet.

External networks are typically created by cloud administrators and marked as external in their configuration. These networks provide connectivity to networks outside your OpenStack environment, usually including internet access. External networks use publicly routable IP addresses or addresses routable within your organization's broader network infrastructure.

To enable instances on private networks to reach external networks, you must connect your private network to an external network using a router. The router's external gateway connects to the external network, while the router's internal interfaces connect to your private networks.

How Traffic Flows Through OpenStack Networks

Understanding the traffic flow path helps you troubleshoot connectivity issues and design efficient network architectures.

When an instance sends traffic to an external destination, the packet follows this path:

The packet originates from the instance's network interface. The instance has a default route pointing to the subnet's gateway address, which is typically an interface on a router.

The packet travels through the port associated with the instance. The port's security group rules are evaluated to determine if the outbound traffic is allowed. If the traffic matches an allowed rule, it proceeds.

The packet is forwarded to the subnet's gateway, which is an interface on a router. The subnet configuration determines this gateway address.

The router receives the packet on its internal interface and consults its routing table. For traffic destined to external networks, the router forwards the packet to its external gateway interface.

If the instance is using a floating IP, the router performs source NAT, replacing the instance's private IP address with the floating IP address. This translation allows return traffic to find its way back to the instance.

The packet exits through the external network and continues to its destination on the internet or external network.

Return traffic follows the reverse path. The router receives packets on its external interface, performs destination NAT to translate the floating IP back to the private IP, and forwards the packet to the appropriate internal subnet and port.

When You Need Each Resource Type

Different networking resources serve specific purposes in your cloud infrastructure:

You need a network whenever you want to create an isolated Layer 2 segment. At minimum, you need one network to launch instances. Most deployments use at least one private network per project.

You need a subnet to provide IP addressing within a network. Every network requires at least one subnet to assign IP addresses to connected instances. You may need additional subnets if you want to segment IP address ranges or use multiple IP versions (IPv4 and IPv6) on the same network.

You need a router when you want to connect networks together or provide external connectivity. If your instances need to reach the internet or communicate with instances on other networks, a router is essential. The router must have an external gateway set to the external network.

You need a port whenever an instance requires a network connection. Ports are typically created automatically when you launch instances, but you may create ports manually for advanced configurations such as pre-allocating specific IP addresses.

You need floating IPs when you want to make instances accessible from external networks. Floating IPs are essential for providing public access to web servers, jump hosts, or any service that external clients need to reach. Not all instances require floating IPs, only those that need to be externally accessible.

You need security groups to control traffic to and from instances. At minimum, you use the default security group, but production deployments typically create custom security groups with specific rules for different types of instances (web servers, database servers, application servers).

Conclusion

OpenStack networking provides a flexible and powerful framework for building virtual network infrastructures. By understanding how networks, subnets, ports, routers, and other components relate to each other, you can design secure, efficient network architectures for your cloud deployments. The Horizon dashboard provides an intuitive interface for managing these resources, while the CLI offers detailed control for advanced configurations. As you become more familiar with these concepts, you'll be able to build increasingly sophisticated network topologies that meet your specific requirements.