Many people stumble into the networking pitfalls while learning OpenStack. From physical network devices to logical configurations, and even the architecture, one must be familiar with various concepts. For instance, understanding basic technologies such as VLAN, Flat, DHCP, Bridge (Linux bridge or OVS), NAT, and routing, as well as SDN is essential. This article outlines some commonly used knowledge.
OpenStack Networking Concepts
Bridge: A virtual device in Linux that connects different network devices. A traditional bridge in Linux acts like a hub, while an OVS-managed bridge functions more like a switch.
br-int: Bridge integration, a comprehensive bridge that implements the main internal network functions.
br-ex: Bridge external, usually indicates a bridge responsible for communicating with external networks.
GRE: General Routing Encapsulation, a method to create tunnels via encapsulation. In OpenStack, it is typically based on L3 GRE, i.e., original pkt/GRE/IP/Ethernet.
VETH: Virtual Ethernet interfaces that usually appear in pairs, where packets sent from one end are received by the other, forming a channel between two bridges.
qvb: Neutron VETH, Linux Bridge-side.
qvo: Neutron VETH, OVS-side.
TAP Device: Simulates a layer 2 network device capable of sending and receiving layer 2 packets.
TUN Device: Simulates a layer 3 network device capable of sending and receiving layer 3 packets.
iptables: A common firewall software on Linux that implements security policies.
VLAN: Virtual LAN, achieving isolation under the same physical LAN using tags, with identifiers ranging from 1-4094.
VXLAN: A set of overlay implementations that utilize UDP as the underlying transport protocol, generally regarded as an extension or alternative to VLAN technology.
Namespace: A mechanism for isolation, where resources in different namespaces are invisible to each other.
How are networks classified in OpenStack based on permissions?
Provider Network: A virtual network directly mapped to physical networks created by the administrator.
Tenant Network: A network created by tenant ordinary users, where the physical network is transparent to the creator, and its configuration is determined by Neutron based on the administrator’s settings in the system.
How are networks classified in OpenStack based on types?
Flat Network: A virtual network implemented based on a physical network that does not use VLANs. Each physical network can support only one virtual network.
Local Network: A virtual network that only allows communication within the same server, without cross-server communication, mainly used for testing on a single node.
VLAN Network: A virtual network implemented based on a physical VLAN network. Multiple VLAN networks sharing the same physical network are isolated from each other and can even use overlapping IP address spaces. Each physical network supporting VLAN networks can be viewed as a separate VLAN trunk, utilizing a set of exclusive VLAN IDs. The valid VLAN ID range is from 1 to 4094.
GRE Network: A virtual network that uses GRE encapsulation for packets. GRE encapsulated packets are routed based on the IP routing table, thus GRE networks are not bound to specific physical networks.
VXLAN Network: A virtual network based on VXLAN. Similar to GRE networks, the routing of IP packets in VXLAN networks is also based on the IP routing table and is not bound to specific physical networks.
What is the role of the integration bridge (br-int) in OpenStack compute nodes?
The integration bridge (br-int) performs VLAN tagging and untagging on traffic from instances running on compute nodes.
Packets leave the instance’s network interface using the virtual interface qvo through the Linux bridge (qbr). The qvb interface connects to the Linux bridge, while the qvo interface connects to the integration bridge. The qvo port on the integration bridge has an internal VLAN tag, which is applied to the packet header when the packet arrives at the integration bridge.
What is the role of the external OVS bridge (br-ex) in OpenStack?
The external OVS bridge forwards traffic to and from the network, allowing external access to instances. The br-ex connects to physical interfaces such as eth2, so that floating IP data from the user network is received from the physical network and routed to the user network port.
What is the role of the tunnel bridge (br-tun) in OpenStack compute nodes?
The tunnel bridge (br-tun) converts VLAN-tagged traffic from the integration bridge into tunnel IDs based on OpenFlow rules.
The tunnel bridge allows instances on different networks to communicate with each other. Tunnels facilitate the transmission of traffic encapsulated over non-secure networks, supporting two-layer networks, namely GRE and VXLAN.
How does network traffic flow in OpenStack, and does it go through the network controller?
Here we describe several scenarios (using the ovs-vlan mode):
Scenario 1: Virtual machines on the same physical machine accessing each other.
When vm1 and vm2 are in the same host, project, and subnet, traffic between the two virtual machines does not need to go through a switch, and can be forwarded directly through the OVS br-int bridge.
Scenario 2: Virtual machines on different physical machines accessing each other.
When vm1 and vm2 are on different hosts but in the same project and subnet, traffic between the two virtual machines needs to be forwarded through a physical switch.
The traffic from the VM first goes through the tap network card to the qbr bridge. The qbr bridge is a Linux-bridge bridge. In the past, OVS did not support the implementation of security groups, so OpenStack had to add a qbr bridge on top of it to implement security groups through iptables (this was removed in the Mitaka version since OVS can now implement it through OpenFlow). The traffic reaches br-int, where OVS rules forward it to br-eth0, and flow rules in br-eth0.Data frames entering through the patch port have their internal local_id modified to vlan_id before being sent out through the eth0 port.The traffic then reaches another compute node through the switch.
When eth0 receives the packet, it forwards the traffic to br-int based on OVS rules. br-int converts the vlan_id back to the corresponding local_id, then sends it through the veth port to qbr, and finally forwards it to the VM’s tap network card through the kernel.
Scenario 3: Accessing external networks.
This requires going through a network node, where the qrouter performs layer 3 forwarding, or it can directly use a physical switch.Communication between different subnets involves the VM sending traffic to the default gateway, which then reaches the network node’s qrouter for communication through layer 3 forwarding.
How to display all flow entries of a switch in OpenStack networking?
You can use the command ovs-ofctl dump-flows to view the flow entries of the switch.
Assuming we want to display all flow entries of the OVS integration bridge (br-int), we can use the following command:
ovs-ofctl dump-flows br-int
What is the role of OpenFlow rules in OpenStack networking?
OpenFlow rules are a mechanism that defines how a packet travels from source to destination. OpenFlow rules are stored in the flow table, which is a part of the OpenFlow switch.
When a packet arrives at the switch, it is checked against the first flow table. If it does not match any entries in the flow table, the packet will be dropped or forwarded to other flow tables.
The above content is compiled from the TWT community and the internet. For deeper learning, please visit the OpenStack official website. For problem-solving or technical exchanges, feel free to join the TWT community.
If you find this article useful, please share or click “view” to let more peers see it.
Recommended materials/articles:
-
Summary of OpenStack Debugging Methods (also applicable to other Python programs)
-
OpenStack Technical Introduction and Architecture Design | Materials
Welcome to follow the community OpenStack technology topic, where quality materials and articles will be continually updated. You can also raise difficult questions and exchange ideas with peers. Address: http://www.talkwithtrend.com/Topic/17591
Download the TWT Community Client App
Long press to recognize the QR code to download
Or search for “twt” in the app store.
Long press the QR code to follow the public account
*The content published by this public account only represents the author’s views and does not represent the community’s position.