openstack 官方文档配置 Open vSwitch

Open vSwitch

ConfigurationScenario 1: one tenant, two networks, one routerScenario 2: two tenants, two networks, two routersConfigure Open vSwitch tunneling

This section describes how the Open vSwitch plug-in implements the Networking abstractions.

Configuration

This example uses VLAN segmentation on the switches to isolate tenant networks. This configuration labels the physical network associated with the public network as

physnet1

, and the physical network associated
with the data network as

physnet2

, which leads to the following configuration options in

ovs_neutron_plugin.ini

:

Scenario 1: one tenant, two networks, one router

Scenario 1: Compute host configScenario 1: Network host config

The first scenario has two private networks (

net01

, and

net02

), each with one subnet (

net01_subnet01

: 192.168.101.0/24,

net02_subnet01

,
192.168.102.0/24). Both private networks are attached to a router that connects them to the public network (10.64.201.0/24).



Under the

service

tenant, create the shared router, define the public network, and set it as the default gateway of the router

$ tenant=$(keystone tenant-list | awk '/service/ {print $2}')
$ neutron router-create router01
$ neutron net-create --tenant-id $tenant public01 \
          --provider:network_type flat \
          --provider:physical_network physnet1 \
          --router:external True
$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
          --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp
$ neutron router-gateway-set router01 public01

Under the

demo

user tenant, create the private network

net01

and corresponding subnet, and connect it to the

router01

router. Configure it to use
VLAN ID 101 on the physical switch.

$ tenant=$(keystone tenant-list|awk '/demo/ {print $2}')
$ neutron net-create --tenant-id $tenant net01 \
          --provider:network_type vlan \
          --provider:physical_network physnet2 \
          --provider:segmentation_id 101
$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24
$ neutron router-interface-add router01 net01_subnet01

Similarly, for

net02

, using VLAN ID 102 on the physical switch:

$ neutron net-create --tenant-id $tenant net02 \
          --provider:network_type vlan \
          --provider:physical_network physnet2 \
          --provider:segmentation_id 102
$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24
$ neutron router-interface-add router01 net02_subnet01

Scenario 1: Compute host config

The following figure shows how to configure various Linux networking devices on the compute host:



Types of network devices

Note

There are four distinct type of virtual networking devices: TAP devices, veth pairs, Linux bridges, and Open vSwitch bridges. For an Ethernet frame to travel from eth0 of virtual machine vm01 to the physical network, it must pass through nine devices inside of the host: TAP vnet0 , Linux bridge qbrNNN , veth pair (qvbNNN , qvo NNN ), Open vSwitch bridge br-int , veth pair (int-br-eth1, phy-br-eth1) , and, finally, the physical network interface card eth1 .

A TAP device, such as

vnet0

is how hypervisors such as KVM and Xen implement a virtual network interface card (typically called a VIF or vNIC). An Ethernet frame sent to a TAP
device is received by the guest operating system.
A veth pair is a pair of directly connected virtual network interfaces. An Ethernet frame sent to one end of a veth pair is received by the other end of a veth pair. Networking uses veth pairs as virtual
patch cables to make connections between virtual bridges.
A Linux bridge behaves like a simple MAC learning switch: you can connect multiple (physical or virtual) network interfaces devices to a Linux bridge. The Linux bridge uses a MAC caching table to record
which interface on the bridge is used to communicate with a host on the link. For any Ethernet frames that come in from one interface attached to the bridge, the host MAC address and port on which the frame was received is recorded in the MAC caching table
for a limited time. When the bridge needs to forward a frame, it will check to see if the frame's destination MAC address is recorded in the table. If so, the Linux bridge forwards the frame through only that port. If not, the frame is flooded to all network
ports in the bridge, with the exception of the port where the frame was received.
An Open vSwitch bridge behaves like a virtual switch: network interface devices connect to Open vSwitch bridge's ports, and the ports can be configured much like a physical switch's ports, including VLAN
configurations.

Integration bridge

The

br-int

Open vSwitch bridge is the integration bridge: all guests running on the compute host connect to this bridge. Networking implements isolation across these guests by configuring the

br-int

ports.

Physical connectivity bridge

The

br-eth1

bridge provides connectivity to the physical network interface card,

eth1

. It connects to the integration bridge by a veth pair:

(int-br-eth1,
 phy-br-eth1)

.

VLAN translation

In this example, net01 and net02 have VLAN ids of 1 and 2, respectively. However, the physical network in our example only supports VLAN IDs in the range 101 through 110. The Open vSwitch agent is responsible for configuring flow rules
on

br-int

and

br-eth1

to do VLAN translation. When

br-eth1

receives a frame marked with VLAN ID 1 on the port associated with

phy-br-eth1

, it
modifies the VLAN ID in the frame to 101. Similarly, when

br-int

receives a frame marked with VLAN ID 101 on the port associated with

int-br-eth1

, it modifies the VLAN ID in the frame to 1.

Security groups: iptables and Linux bridges

Ideally, the TAP device

vnet0

would be connected directly to the integration bridge,

br-int

. Unfortunately, this isn't possible because of how OpenStack security groups are
currently implemented. OpenStack uses iptables rules on the TAP devices such as

vnet0

to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected
to an Open vSwitch port.
Networking uses an extra Linux bridge and a veth pair as a workaround for this issue. Instead of connecting

vnet0

to an Open vSwitch bridge, it is connected to a Linux bridge,

qbrXXX

.
This bridge is connected to the integration bridge,

br-int

, through the

(qvbXXX

, qvo

XXX

)veth
pair.

Scenario 1: Network host config

The network host runs the neutron-openvswitch-plugin-agent, the neutron-dhcp-agent, neutron-l3-agent, and neutron-metadata-agent services.
On the network host, assume that eth0 is connected to the external network, and eth1 is connected to the data network, which leads to the following configuration in the

ovs_neutron_plugin.ini

file:



The following figure shows the network devices on the network host:



As on the compute host, there is an Open vSwitch integration bridge (

br-int

) and an Open vSwitch bridge connected to the data network (

br-eth1

), and the two are connected by
a veth pair, and the neutron-openvswitch-plugin-agent configures the ports on both switches to do VLAN translation.
An additional Open vSwitch bridge,

br-ex

, connects to the physical interface that is connected to the external network. In this example, that physical interface is

eth0

.

	Note
While the integration bridge and the external bridge are connected by a veth pair (int-br-ex, phy-br-ex) , this example uses layer 3 connectivity to route packets from the internal networks to the public network: no packets traverse that veth pair in this example.

Open vSwitch internal ports

The network host uses Open vSwitch internal ports. Internal ports enable you to assign one or more IP addresses to an Open vSwitch bridge. In previous example, the

br-int

bridge
has four internal ports:

tapXXX

,

qr-YYY

,

qr-ZZZ

,
and

tapWWW

. Each internal port has a separate IP address associated with it. An internal port,

qg-VVV

,
is on the

br-ex

bridge.

DHCP agent

By default, the Networking DHCP agent uses a process called dnsmasq to provide DHCP services to guests. Networking must create an internal port for each network that requires DHCP services and attach a dnsmasq process to that port.
In the previous example, the

tapXXX

interface is on

net01_subnet01

, and the

tapWWW

interface
is on

net02_subnet01

.

L3 agent (routing)

The Networking L3 agent uses Open vSwitch internal ports to implement routing and relies on the network host to route the packets across the interfaces. In this example, the

qr-YYY

interface
is on

net01_subnet01

and has the IP address 192.168.101.1/24. The

qr-ZZZ

, interface is on

net02_subnet01

and
has the IP address

192.168.102.1/24

. The

qg-VVV

interface has the IP address

10.64.201.254/24

. Because
each of these interfaces is visible to the network host operating system, the network host routes the packets across the interfaces, as long as an administrator has enabled IP forwarding.
The L3 agent uses iptables to implement floating IPs to do the network address translation (NAT).

Overlapping subnets and network namespaces

One problem with using the host to implement routing is that one of the Networking subnets might overlap with one of the physical networks that the host uses. For example, if the management network is implemented on

eth2

and
also happens to be on the

192.168.101.0/24

subnet, routing problems will occur because the host can't determine whether to send a packet on this subnet to

qr-YYY

or

eth2

.
If end users are permitted to create their own logical networks and subnets, you must design the system so that such collisions do not occur.
Networking uses Linux network namespaces to prevent collisions between the physical networks on the network host, and the logical networks used by the virtual machines. It also prevents collisions across
different logical networks that are not routed to each other, as the following scenario shows.
A network namespace is an isolated environment with its own networking stack. A network namespace has its own network interfaces, routes, and iptables rules. Consider it a chroot jail, except for networking instead of for a file system.
LXC (Linux containers) use network namespaces to implement networking virtualization.
Networking creates network namespaces on the network host to avoid subnet collisions.



In this example, there are three network namespaces, as shown in the figure above:

qdhcp-AAA

: contains the

tapXXX

interface
and the dnsmasq process that listens on that interface to provide DHCP services for

net01_subnet01

. This allows overlapping IPs between

net01_subnet01

and any other subnets on the network host.

qrouter-BBBB

: contains the

qr-YYY

,

qr-ZZZ

,
and

qg-VVV

interfaces, and the corresponding routes. This namespace implements

router01

in our example.

qdhcp-CCC

: contains the

tapWWW

interface
and the dnsmasq process that listens on that interface, to provide DHCP services for

net02_subnet01

. This allows overlapping IPs between

net02_subnet01

and any other subnets on the network host.

Scenario 2: two tenants, two networks, two routers

Scenario 2: Compute host configScenario 2: Network host config

In this scenario, tenant A and tenant B each have a network with one subnet and one router that connects the tenants to the public Internet.



Under the

service

tenant, define the public network:

$ tenant=$(keystone tenant-list | awk '/service/ {print $2}')
$ neutron net-create --tenant-id $tenant public01 \
          --provider:network_type flat \
          --provider:physical_network physnet1 \
          --router:external True
$ neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
          --gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp

Under the

tenantA

user tenant, create the tenant router and set its gateway for the public network.

$ tenant=$(keystone tenant-list|awk '/tenantA/ {print $2}')
$ neutron router-create --tenant-id $tenant router01
$ neutron router-gateway-set router01 public01

Then, define private network

net01

using VLAN ID 101 on the physical switch, along with its subnet, and connect it to the router.

$ neutron net-create --tenant-id $tenant net01 \
          --provider:network_type vlan \
          --provider:physical_network physnet2 \
          --provider:segmentation_id 101
$ neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24
$ neutron router-interface-add router01 net01_subnet01

Similarly, for

tenantB

, create a router and another network, using VLAN ID 102 on the physical switch:

$ tenant=$(keystone tenant-list|awk '/tenantB/ {print $2}')
$ neutron router-create --tenant-id $tenant router02
$ neutron router-gateway-set router02 public01
$ neutron net-create --tenant-id $tenant net02 \
          --provider:network_type vlan \
          --provider:physical_network physnet2 \
          --provider:segmentation_id 102
$ neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24
$ neutron router-interface-add router02 net02_subnet01

Scenario 2: Compute host config

The following figure shows how to configure Linux networking devices on the compute host:

	Note
The compute host configuration resembles the configuration in scenario 1. However, in scenario 1, a guest connects to two subnets while in this scenario, the subnets belong to different tenants.

Scenario 2: Network host config

The following figure shows the network devices on the network host for the second scenario.



In this configuration, the network namespaces are organized to isolate the two subnets from each other as shown in the following figure.



In this scenario, there are four network namespaces (

qdhcp-AAA

,

qrouter-BBBB

,

qrouter-CCCC

,
and

qdhcp-DDDD

), instead of three. Because there is no connectivity between the two networks, each router is implemented by a separate namespace.

Configure Open vSwitch tunneling

Tunneling encapsulates network traffic between physical Networking hosts and allows VLANs to span multiple physical hosts. Instances communicate as if they share the same layer 2 network. Open vSwitch supports tunneling with the VXLAN
and GRE encapsulation protocols.

Figure 7.4. Example VXLAN tunnel



This diagram shows two instances running on separate hosts connected by a VXLAN tunnel. The required physical and virtual components are also illustrated. The following procedure creates a VXLAN or GRE tunnel between two Open vSwitches
running on separate Networking hosts:

Example tunnel configuration

Create a virtual bridge named OVS-BR0 on each participating host:

ovs-vsctl add-br OVS-BR0

Create a tunnel to link the OVS-BR0 virtual bridges. Run the ovs-vsctl command on HOST1 to create the tunnel and link it to the bridge on HOST2:
GRE tunnel command:

ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.11

VXLAN tunnel command:

ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.11

Run the ovs-vsctl command on HOST2 to create the tunnel and link it to the bridge on HOST1.
GRE tunnel command:

ovs-vsctl add-port OVS-BR0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.1.10

VXLAN tunnel command:

ovs-vsctl add-port OVS-BR0 vxlan1 -- set Interface vxlan1 type=vxlan options:remote_ip=192.168.1.10

Successful completion of these steps results in the two instances sharing a layer 2 network.