Chapter 1. Networking overview

download PDF

The OpenStack Networking service (codename neutron) is the software-defined networking component of Red Hat OpenStack Platform 13.

Network administrators can use software-defined networking (SDN) to manage network services through abstraction of lower-level functionality. While server workloads have been migrated into virtual environments, they are still just servers that look for a network connection to send and receive data. SDN meets this need by moving networking equipment (such as routers and switches) into the same virtualized space. If you are already familiar with basic networking concepts, then it is easy to consider that these physical networking concepts have now been virtualized, just like the servers that they connect.

1.1. How networking works

The term networking refers to the act of moving information from one computer to another. At the most basic level, this is performed by running a cable between two machines, each with network interface cards (NICs) installed. In the OSI networking model, the cable represents layer 1.

Now, if you want more than two computers to get involved in the conversation, you would need to scale out this configuration by adding a device called a switch. Enterprise switches have multiple Ethernet ports where you can connect additional machines. A network of multiple machines is called a Local Area Network (LAN).

Because they increase complexity, switches represent another layer of the OSI model, layer two. Each NIC has a unique MAC address number assigned to the hardware, and this number enables machines connected to the same switch to find each other. The switch maintains a list of which MAC addresses are plugged into which ports, so that when one computer attempts to send data to another, the switch knows where they are both situated, and adjusts entries in the CAM (Content Addressable Memory), which monitors of MAC-address-to-port mappings.

1.1.1. VLANs

You can use VLANs to segment network traffic for computers running on the same switch. This means that you can logically divide your switch by configuring the ports to be members of different networks — they are basically mini-LANs that you can use to separate traffic for security reasons.

For example, if your switch has 24 ports in total, you can assign ports 1-6 to VLAN200, and ports 7-18 to VLAN201. As a result, computers connected to VLAN200 are completely separate from those on VLAN201; they cannot communicate directly, and if they wanted to, the traffic must pass through a router as if they were two separate physical switches. Firewalls can also be useful for governing which VLANs can communicate with each other.

1.2. Connecting two LANs together

If you have two LANs running on two separate switches, and you want them to share information with each other. You have two options for configuring this communication:

  • Use 802.1Q VLAN tagging to configure a single VLAN that spans across both physical switches:

    You must connect one end of a network cable to a port on one switch, connect the other end to a port on the other switch, and then configure these ports as 802.1Q tagged ports (sometimes known as trunk ports). These two switches act as one big logical switch, and the connected computers can find each other.

    The downside to this option is scalability. You can only daisy-chain a limited number of switches until overhead becomes an issue.

  • Obtain a router and use cables to connect it to each switch:

    The router is aware of the networks configured on both switches. Each end of the cable plugged into the switch receives an IP address, known as the default gateway for that network. A default gateway defines the destination where traffic is sent when it is clear that the destination machine is not on the same LAN as the source machine. By establishing a default gateway, each computer can send traffic to other computers without knowing specific information about the destination. Each computer sends traffic to the default gateway, and the router determines which destination computer receives the traffic. Routing works on layer 3 of the OSI model, and is where the familiar concepts like IP addresses and subnets operate.

1.2.1. Firewalls

Firewalls can filter traffic across multiple OSI layers, including layer 7 (for inspecting actual content). Firewalls are often situated in the same network segments as routers, where they govern the traffic moving between all the networks. Firewalls refer to a predefined set of rules that prescribe which traffic can enter a network. These rules can become very granular, for example:

"Servers on VLAN200 may only communicate with computers on VLAN201, and only on a Thursday afternoon, and only if they are sending encrypted web traffic (HTTPS) in one direction".

To help enforce these rules, some firewalls also perform Deep Packet Inspection (DPI) at layers 5-7, whereby they examine the contents of packets to ensure that the packets are legitimate. Hackers can exfiltrate data by having the traffic masquerade as something it is not. DPI is one of the means that you can use to mitigate that threat.

1.3. Red Hat OpenStack Network Flow Matrix

The network flow matrix is a comma separated values (CSV) file that describes flows to and from OpenStack services.

NOTE: The network flow matrix describes common traffic flows. It does not describe every possible flow. Some flows that are not described in this matrix might be critical to operation. For instance, if you block all traffic and then selectively open only the flows described here, you might unintentionally block a necessary flow. That could cause issues that are difficult to troubleshoot.

The matrix describes flows in the following columns.

The OpenStack service.
Transmission protocol.
Dest. Port
Destination port.
Source Object
Source of data.
Dest. Object
Destination of data.
Source/Dest Pairs
Valid source and destination pairs.
Dest. Network
Destination network.
ServiceNetMap Parent
Determines the network type used for each service.
Traffic Description
Notes about the traffic flow.

Download the network flow matrix file from the following location:

Red Hat OpenStack Network Flows.

1.4. Working with OpenStack Networking (neutron)

These same networking concepts apply in OpenStack, where they are known as Software-defined networking (SDN). The OpenStack Networking (neutron) component provides the API for virtual networking capabilities, and includes switches, routers, and firewalls. The virtual network infrastructure allows your instances to communicate with each other and also externally using the physical network. The Open vSwitch bridge allocates virtual ports to instances, and can span across the network infrastructure to the physical network for incoming and outgoing traffic.

1.5. Working with CIDR format

IP addresses are generally first allocated in blocks of subnets. For example, the IP address range - with a subnet mask of 255.555.255.0 allows for 254 IP addresses (the first and last addresses are reserved).

These subnets can be represented in a number of ways:

  • Common usage:

    Subnet addresses are traditionally displayed using the network address accompanied by the subnet mask:

    • Network Address:
    • Subnet mask:
  • CIDR format:

    The subnet mask is shortened into its total number of active bits.

    For example, in, /24 is a shortened representation of, and is a total of the number of flipped bits when converted to binary.

    Also, CIDR format can be used in ifcfg-xxx scripts instead of the NETMASK value:

Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.