Vlan Analysis of openstack Network Mode

Openstack neutron defines four network modes:

# Tenant_network_type = local

# Tenant_network_type = vlan

# Example: tenant_network_type = gre

# Example: tenant_network_type = vxlan

This document uses vlan as an example and uses local to analyze the network mode of openstack in detail.

1. local Mode

This mode is mainly used for testing and can only be deployed on a single node (all-in-one). This is because the traffic in this network mode cannot flow out through the real physical Nic, that is to say, the integration bridge of neutron is not mapping with the real physical Nic. It can only ensure that the vm on the same host is connected. For details, see the configuration files of RDO and neutron.

(1) RDO configuration file (answer. conf)

The following red configuration item is used. The default value is null.

CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS

The default bridge ing of openswitch, that is, the br-int ing. Because the br-int Is not mapped to any bridge or interface, it can only be connected between virtual machines on the br-int.

CONFIG_NEUTRON_OVS_BRIDGE_IFACES

Which physical network card does the traffic flow from?

# Type of network to allocate for tenant networks (eg. vlan, local,

# Gre)

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE = local

# A comma separated list of VLAN ranges for the Neutron openvswitch

# Plugin (eg. physnet1: 1: 4094, physnet2, physnet3: 3000: 3999)

CONFIG_NEUTRON_OVS_VLAN_RANGES =

# A comma separated list of bridge mappings for the Neutron

# Openvswitch plugin (eg. physnet1: br-eth1, physnet2: br-eth2, physnet3

#: Br-eth3)

CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS =

# A comma separated list of colon-separated OVS bridge: interface

# Pairs. The interface will be added to the associated bridge.

CONFIG_NEUTRON_OVS_BRIDGE_IFACES =

(2) neutron configuration file (/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini)

[Ovs]

# (StrOpt) Type of network to allocate for tenant networks.

# Default value 'local' is useful only for single-box testing and

# Provides no connectivity between hosts. You MUST either change this

# To 'vlan 'and configure network_vlan_ranges below or change this

# 'G' or 'vxlan' and configure tunnel_id_ranges below in order

# Tenant networks to provide connectivity between hosts. Set to 'None'

# To disable creation of tenant networks.

#

Tenant_network_type = local

RDO configures the open vswitch configuration file in neutron as local according to the local configuration in answer. conf.

2. vlan Mode

If you are familiar with VLANs, you will not go into details. You can directly view the configuration files of RDO and neutron.

(1) RDO configuration file

# Type of network to allocate for tenant networks (eg. vlan, local,

# Gre)

CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE = vlan // specify the network mode as vlan

# A comma separated list of VLAN ranges for the Neutron openvswitch

# Plugin (eg. physnet1: 1: 4094, physnet2, physnet3: 3000: 3999)

CONFIG_NEUTRON_OVS_VLAN_RANGES = physnet1: 100: 200 // set the vlan ID value to 100 ~ 200

# A comma separated list of bridge mappings for the Neutron

# Openvswitch plugin (eg. physnet1: br-eth1, physnet2: br-eth2, physnet3

#: Br-eth3)

CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS = physnet1: br-eth1 // set to map the br-int to the bridge br-eth1 (the phy-br-eth1 and int-br-eth1 are automatically created to connect to the br-int and br-eth1)

# A comma separated list of colon-separated OVS bridge: interface

# Pairs. The interface will be added to the associated bridge.

CONFIG_NEUTRON_OVS_BRIDGE_IFACES = br-eth1: eth1 // set the eth0 bridge to be connected to the br-eth1, that is, the final network traffic flow out of eth1 (the ovs-vsctl add br-eth1 eth1 will be automatically executed)

Between the bridge and the bridge described in this configuration, the ing and connection relationship between bridges and NICs can be combined with the network device topology of computing nodes in vlan mode and the network device topology of network nodes in vlan mode. to understand.

Thinking: Many may encounter a scenario where a physical machine has only one network card or two network cards, but only one network card is connected with a network card.

In this case, you can configure the following:

(2) single NIC:

CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS = physnet1: br-eth0 // set to map br-int to bridge br-eth10

# A comma separated list of colon-separated OVS bridge: interface

# Pairs. The interface will be added to the associated bridge.

CONFIG_NEUTRON_OVS_BRIDGE_IFACES = // The configuration is empty.

The meaning of this configuration is to map the br-int to the br-eth0, but the br-eth0 is not bound to the real physical Nic, which requires you to advance on all compute nodes (or network nodes) create a br-eth0 Bridge in advance, add eth0 to the br-eth0, and then configure the ip on the br-eth0, then RDO during installation, as long as the connection between the br-int and the br-eth0 is established, the entire network will be connected.

In this case, if the network node is also a single Nic, you may not be able to use the float ip function.

(3) Dual Nic, single network cable

CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS = physnet1: br-eth1 // set to map br-int to bridge br-eth1

# A comma separated list of colon-separated OVS bridge: interface

# Pairs. The interface will be added to the associated bridge.

CONFIG_NEUTRON_OVS_BRIDGE_IFACES = eth1 // The configuration is empty.

Or are all configured on eth1 by default, and then the eth1 traffic is forwarded to eth0 through iptables (no tests have been conducted and you are not sure whether it is feasible)

3. vlan network Modes

Figure 1 network device topology of computing nodes in vlan Mode

First, we analyze the topology of virtual network devices on computing nodes in the vlan network mode.

(1) qbrXXX and Other Devices

As mentioned above, the main reason is that the network ACL rules cannot be configured on the vnet0 of the tap device.

(2) qvbXXX/qvoXXX and Other Devices

This is a pair of veth pair devices used to connect the bridge device and switch. I guess from the name: q-quantum, v-veth, B-bridge, o-open vswitch (legacy of the quantum age ).

(3) int-br-eth1 and phy-br-eth1

This is also a pair of veth pair devices, used to connect the br-int and br-eth1, In addition, vlan ID conversion is also executed here, such as packets from the int-br-eth1, its vlan id = 101 will be converted to 1, similarly, from the phy-br-eth1 out of packets, its vlan id will be converted from 1 to 101

(4) br-eth1 and eth1

Packets to enter the physical network and finally get the real physical network adapter eth1, so add eth1 to THE br-eth1, the entire Link is fully connected

Figure 2 network device topology of network nodes in vlan Mode

Compared with the computing node, the network node has more external network, L3 agent, and dhcp agent.

(1) network namespace

Each L3 router corresponds to a private network, but how can we ensure that each private ip address can be overlapping without affecting each other? This uses the network namespace of linux kernel.

(2) devices such as qr-YYY and qg-VVV (q-quantum, r-router, g-gateway)

Qr-YYY obtains an internal ip address, qg-VVV is an external ip address, and NAT ing is performed through iptables rules.

Thinking: What are the scenarios of phy-br-ex and int-br-ex?

Adhere to the idea that "All packages must pass through physical lines before they can pass through". Although the NAT ing established between qr-YYY and qg-VVV must eventually pass through a physical link, then, the physical link is established between the phy-br-ex and int-br-ex.