Open vSwitch: Provider networks

updated: 2019-08-23 18:55
Contents

Open vSwitch: Provider networks

This architecture example provides layer-2 connectivity between instances and the physical network infrastructure using VLAN (802.1q) tagging. It supports one untagged (flat) network and up to 4095 tagged (VLAN) networks. The actual quantity of VLAN networks depends on the physical network infrastructure. For more information on provider networks, see プロバイダーネットワーク.

警告

Linux distributions often package older releases of Open vSwitch that can introduce issues during operation with the Networking service. We recommend using at least the latest long-term stable (LTS) release of Open vSwitch for the best experience and support from Open vSwitch. See http://www.openvswitch.org for available releases and the installation instructions for

前提

One controller node with the following components:

  • Two network interfaces: management and provider.
  • OpenStack Networking server service and ML2 plug-in.

Two compute nodes with the following components:

  • Two network interfaces: management and provider.
  • OpenStack Networking Open vSwitch (OVS) layer-2 agent, DHCP agent, metadata agent, and any dependencies including OVS.

注釈

Larger deployments typically deploy the DHCP and metadata agents on a subset of compute nodes to increase performance and redundancy. However, too many agents can overwhelm the message bus. Also, to further simplify any deployment, you can omit the metadata agent and use a configuration drive to provide metadata to instances.

アーキテクチャー

Provider networks using OVS - overview

The following figure shows components and connectivity for one untagged (flat) network. In this particular case, the instance resides on the same compute node as the DHCP agent for the network. If the DHCP agent resides on another compute node, the latter only contains a DHCP namespace with a port on the OVS integration bridge.

Provider networks using OVS - components and connectivity - one network

The following figure describes virtual connectivity among components for two tagged (VLAN) networks. Essentially, all networks use a single OVS integration bridge with different internal VLAN tags. The internal VLAN tags almost always differ from the network VLAN assignment in the Networking service. Similar to the untagged network case, the DHCP agent may reside on a different compute node.

Provider networks using OVS - components and connectivity - multiple networks

注釈

These figures omit the controller node because it does not handle instance network traffic.

設定例

Use the following example configuration as a template to deploy provider networks in your environment.

コントローラーノード

  1. Install the Networking service components that provide the neutron-server service and ML2 plug-in.

  2. neutron.conf ファイル:

    • 共通のオプションを設定します。

      [DEFAULT]
core_plugin = ml2
auth_strategy = keystone

[database]
# ...

[keystone_authtoken]
# ...

[nova]
# ...

[agent]
# ...

      See the Installation Tutorials and Guides and Configuration Reference for your OpenStack release to obtain the appropriate additional configuration for the [DEFAULT], [database], [keystone_authtoken], [nova], and [agent] sections.

    • Disable service plug-ins because provider networks do not require any. However, this breaks portions of the dashboard that manage the Networking service. See the Ocata Install Tutorials and Guides for more information.

      [DEFAULT]
service_plugins =

    • Enable two DHCP agents per network so both compute nodes can provide DHCP service provider networks.

      [DEFAULT]
dhcp_agents_per_network = 2

    • 必要であれば MTU を設定します。

  3. ml2_conf.ini ファイル:

    • ドライバーとネットワークタイプを設定します。

      [ml2]
type_drivers = flat,vlan
tenant_network_types =
mechanism_drivers = openvswitch
extension_drivers = port_security

    • ネットワークマッピングを設定します。

      [ml2_type_flat]
flat_networks = provider

[ml2_type_vlan]
network_vlan_ranges = provider

      注釈

      tenant_network_types オプションには何も値を指定しません。このアーキテクチャーでは、セルフサービスネットワークがサポートされないからです。

      注釈

      network_vlan_ranges オプションの provider 値に VLAN ID を指定しなかった場合、任意の VLAN ID を使用できます。

  4. データベースを展開します。

    # su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

  5. 以下のサービスを実行します。

    • サーバー

コンピュートノード

  1. Install the Networking service OVS layer-2 agent, DHCP agent, and metadata agent.

  2. Install OVS.

  3. In the neutron.conf file, configure common options:

    [DEFAULT]
core_plugin = ml2
auth_strategy = keystone

[database]
# ...

[keystone_authtoken]
# ...

[nova]
# ...

[agent]
# ...

    See the Installation Tutorials and Guides and Configuration Reference for your OpenStack release to obtain the appropriate additional configuration for the [DEFAULT], [database], [keystone_authtoken], [nova], and [agent] sections.

  4. In the openvswitch_agent.ini file, configure the OVS agent:

    [ovs]
bridge_mappings = provider:br-provider

[securitygroup]
firewall_driver = iptables_hybrid

  5. dhcp_agent.ini ファイルで DHCP エージェントを設定します。

    [DEFAULT]
interface_driver = openvswitch
enable_isolated_metadata = True
force_metadata = True

    注釈

    The force_metadata option forces the DHCP agent to provide a host route to the metadata service on 169.254.169.254 regardless of whether the subnet contains an interface on a router, thus maintaining similar and predictable metadata behavior among subnets.

  6. metadata_agent.ini ファイルでメタデータエージェントを設定します。

    [DEFAULT]
nova_metadata_ip = controller
metadata_proxy_shared_secret = METADATA_SECRET

    The value of METADATA_SECRET must match the value of the same option in the [neutron] section of the nova.conf file.

  7. 以下のサービスを実行します。

    • OVS

  8. Create the OVS provider bridge br-provider:

    $ ovs-vsctl add-br br-provider

  9. Add the provider network interface as a port on the OVS provider bridge br-provider:

    $ ovs-vsctl add-port br-provider PROVIDER_INTERFACE

    PROVIDER_INTERFACE は、 プロバイダーネットワークを処理するインターフェース名で置き換えます。例えば、 eth1 など。

  10. 以下のサービスを実行します。

    • OVS エージェント
    • DHCP エージェント
    • メタデータエージェント

サービスの動作検証

  1. 管理プロジェクトのクレデンシャルを読み込みます。

  2. エージェントが存在し、動作していることを確認します。

    $ openstack network agent list
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host     | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| 1236bbcb-e0ba-48a9-80fc-81202ca4fa51 | Metadata agent     | compute2 |                   | True  | UP    | neutron-metadata-agent    |
| 457d6898-b373-4bb3-b41f-59345dcfb5c5 | Open vSwitch agent | compute2 |                   | True  | UP    | neutron-openvswitch-agent |
| 71f15e84-bc47-4c2a-b9fb-317840b2d753 | DHCP agent         | compute2 | nova              | True  | UP    | neutron-dhcp-agent        |
| a6c69690-e7f7-4e56-9831-1282753e5007 | Metadata agent     | compute1 |                   | True  | UP    | neutron-metadata-agent    |
| af11f22f-a9f4-404f-9fd8-cd7ad55c0f68 | DHCP agent         | compute1 | nova              | True  | UP    | neutron-dhcp-agent        |
| bcfc977b-ec0e-4ba9-be62-9489b4b0e6f1 | Open vSwitch agent | compute1 |                   | True  | UP    | neutron-openvswitch-agent |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+

初期ネットワークの作成

The configuration supports one flat or multiple VLAN provider networks. For simplicity, the following procedure creates one flat provider network.

  1. 管理プロジェクトのクレデンシャルを読み込みます。

  2. フラットネットワークを作成します。

    $ openstack network create --share --provider-physical-network provider \
  --provider-network-type flat provider1
+---------------------------+-----------+-
| Field                     | Value     |
+---------------------------+-----------+
| admin_state_up            | UP        |
| mtu                       | 1500      |
| name                      | provider1 |
| port_security_enabled     | True      |
| provider:network_type     | flat      |
| provider:physical_network | provider  |
| provider:segmentation_id  | None      |
| router:external           | Internal  |
| shared                    | True      |
| status                    | ACTIVE    |
+---------------------------+-----------+

    注釈

    shared オプションを指定すると、すべてのプロジェクトがこのネットワークを使用できるようになります。プロバイダーネットワークへのアクセスを制限する方法は ロールベースアクセス制御 (RBAC) を参照してください。

    注釈

    To create a VLAN network instead of a flat network, change --provider:network_type flat to --provider-network-type vlan and add --provider-segment with a value referencing the VLAN ID.

  3. プロバイダーネットワークのIPv4サブネットを作成します。

    $ openstack subnet create --subnet-range 203.0.113.0/24 --gateway 203.0.113.1 \
  --network provider1 --allocation-pool start=203.0.113.11,end=203.0.113.250 \
  --dns-nameserver 8.8.4.4 provider1-v4
+-------------------+----------------------------+
| Field             | Value                      |
+-------------------+----------------------------+
| allocation_pools  | 203.0.113.11-203.0.113.250 |
| cidr              | 203.0.113.0/24             |
| dns_nameservers   | 8.8.4.4                    |
| enable_dhcp       | True                       |
| gateway_ip        | 203.0.113.1                |
| ip_version        | 4                          |
| name              | provider1-v4               |
+-------------------+----------------------------+

    注釈

    Enabling DHCP causes the Networking service to provide DHCP which can interfere with existing DHCP services on the physical network infrastructure.

  4. プロバイダーネットワークのIPv6サブネットを作成します。

    $ openstack subnet create --subnet-range fd00:203:0:113::/64 --gateway fd00:203:0:113::1 \
  --ip-version 6 --ipv6-address-mode slaac --network provider1 \
  --dns-nameserver 2001:4860:4860::8844 provider1-v6
+-------------------+------------------------------------------------------+
| Field             | Value                                                |
+-------------------+------------------------------------------------------+
| allocation_pools  | fd00:203:0:113::2-fd00:203:0:113:ffff:ffff:ffff:ffff |
| cidr              | fd00:203:0:113::/64                                  |
| dns_nameservers   | 2001:4860:4860::8844                                 |
| enable_dhcp       | True                                                 |
| gateway_ip        | fd00:203:0:113::1                                    |
| ip_version        | 6                                                    |
| ipv6_address_mode | slaac                                                |
| ipv6_ra_mode      | None                                                 |
| name              | provider1-v6                                         |
+-------------------+------------------------------------------------------+

    注釈

    The Networking service uses the layer-3 agent to provide router advertisement. Provider networks rely on physical network infrastructure for layer-3 services rather than the layer-3 agent. Thus, the physical network infrastructure must provide router advertisement on provider networks for proper operation of IPv6.

ネットワーク動作の検証

  1. On each compute node, verify creation of the qdhcp namespace.

    # ip netns
qdhcp-8b868082-e312-4110-8627-298109d4401c

  2. Source a regular (non-administrative) project credentials.

  3. Create the appropriate security group rules to allow ping and SSH access instances using the network.

    $ openstack security group rule create --proto icmp default
+------------------+-----------+
| Field            | Value     |
+------------------+-----------+
| direction        | ingress   |
| ethertype        | IPv4      |
| protocol         | icmp      |
| remote_ip_prefix | 0.0.0.0/0 |
+------------------+-----------+

$ openstack security group rule create --ethertype IPv6 --proto ipv6-icmp default
+-----------+-----------+
| Field     | Value     |
+-----------+-----------+
| direction | ingress   |
| ethertype | IPv6      |
| protocol  | ipv6-icmp |
+-----------+-----------+

$ openstack security group rule create --proto tcp --dst-port 22 default
+------------------+-----------+
| Field            | Value     |
+------------------+-----------+
| direction        | ingress   |
| ethertype        | IPv4      |
| port_range_max   | 22        |
| port_range_min   | 22        |
| protocol         | tcp       |
| remote_ip_prefix | 0.0.0.0/0 |
+------------------+-----------+

$ openstack security group rule create --ethertype IPv6 --proto tcp --dst-port 22 default
+------------------+-----------+
| Field            | Value     |
+------------------+-----------+
| direction        | ingress   |
| ethertype        | IPv6      |
| port_range_max   | 22        |
| port_range_min   | 22        |
| protocol         | tcp       |
+------------------+-----------+

  4. Launch an instance with an interface on the provider network. For example, a CirrOS image using flavor ID 1.

    $ openstack server create --flavor 1 --image cirros \
  --nic net-id=NETWORK_ID provider-instance1

    Replace NETWORK_ID with the ID of the provider network.

  5. Determine the IPv4 and IPv6 addresses of the instance.

    $ openstack server list
+--------------------------------------+--------------------+--------+------------------------------------------------------------+------------+
| ID                                   | Name               | Status | Networks                                                   | Image Name |
+--------------------------------------+--------------------+--------+------------------------------------------------------------+------------+
| 018e0ae2-b43c-4271-a78d-62653dd03285 | provider-instance1 | ACTIVE | provider1=203.0.113.13, fd00:203:0:113:f816:3eff:fe58:be4e | cirros     |
+--------------------------------------+--------------------+--------+------------------------------------------------------------+------------+

  6. On the controller node or any host with access to the provider network, ping the IPv4 and IPv6 addresses of the instance.

    $ ping -c 4 203.0.113.13
PING 203.0.113.13 (203.0.113.13) 56(84) bytes of data.
64 bytes from 203.0.113.13: icmp_req=1 ttl=63 time=3.18 ms
64 bytes from 203.0.113.13: icmp_req=2 ttl=63 time=0.981 ms
64 bytes from 203.0.113.13: icmp_req=3 ttl=63 time=1.06 ms
64 bytes from 203.0.113.13: icmp_req=4 ttl=63 time=0.929 ms

--- 203.0.113.13 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.929/1.539/3.183/0.951 ms

$ ping6 -c 4 fd00:203:0:113:f816:3eff:fe58:be4e
PING fd00:203:0:113:f816:3eff:fe58:be4e(fd00:203:0:113:f816:3eff:fe58:be4e) 56 data bytes
64 bytes from fd00:203:0:113:f816:3eff:fe58:be4e icmp_seq=1 ttl=64 time=1.25 ms
64 bytes from fd00:203:0:113:f816:3eff:fe58:be4e icmp_seq=2 ttl=64 time=0.683 ms
64 bytes from fd00:203:0:113:f816:3eff:fe58:be4e icmp_seq=3 ttl=64 time=0.762 ms
64 bytes from fd00:203:0:113:f816:3eff:fe58:be4e icmp_seq=4 ttl=64 time=0.486 ms

--- fd00:203:0:113:f816:3eff:fe58:be4e ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.486/0.796/1.253/0.282 ms

  7. インスタンスにアクセスします。

  8. Test IPv4 and IPv6 connectivity to the Internet or other external network.

ネットワークトラフィックフロー

The following sections describe the flow of network traffic in several common scenarios. North-south network traffic travels between an instance and external network such as the Internet. East-west network traffic travels between instances on the same or different networks. In all scenarios, the physical network infrastructure handles switching and routing among provider networks and external networks such as the Internet. Each case references one or more of the following components:

  • プロバイダーネットワーク 1 (VLAN)
    • VLAN ID 101 (タグ VLAN)
    • IP アドレス範囲 203.0.113.0/24 と fd00:203:0:113::/64
    • ゲートウェイ (物理ネットワーク環境経由)
      • IPアドレス203.0.113.1とfd00:203:0:113:0::1
  • プロバイダーネットワーク 2 (VLAN)
    • VLAN ID 102 (タグ VLAN)
    • IP address range 192.0.2.0/24 and fd00:192:0:2::/64
    • ゲートウェイ
      • IP アドレス 192.0.2.1 と fd00:192:0:2::1
  • インスタンス 1
    • IP アドレス 203.0.113.101 と fd00:203:0:113:0::101
  • インスタンス 2
    • IP アドレス 192.0.2.101 と fd00:192:0:2:0::101

ノース・サウス

  • インスタンスは、コンピュートノード 1 上にあり、プロバイダーネットワーク 1 を使用します。
  • インスタンスが内部ネットワーク上のホストにパケットを送信します。

以下の手順は、コンピュートノード 1 で行われます。

  1. The instance interface (1) forwards the packet to the security group bridge instance port (2) via veth pair.
  2. Security group rules (3) on the security group bridge handle firewalling and connection tracking for the packet.
  3. The security group bridge OVS port (4) forwards the packet to the OVS integration bridge security group port (5) via veth pair.
  4. The OVS integration bridge adds an internal VLAN tag to the packet.
  5. The OVS integration bridge int-br-provider patch port (6) forwards the packet to the OVS provider bridge phy-br-provider patch port (7).
  6. The OVS provider bridge swaps the internal VLAN tag with actual VLAN tag 101.
  7. The OVS provider bridge provider network port (8) forwards the packet to the physical network interface (9).
  8. The physical network interface forwards the packet to the physical network infrastructure switch (10).

以下の手順は、物理ネットワーク環境で行われます。

  1. The switch removes VLAN tag 101 from the packet and forwards it to the router (11).
  2. The router routes the packet from the provider network (12) to the external network (13) and forwards the packet to the switch (14).
  3. The switch forwards the packet to the external network (15).
  4. The external network (16) receives the packet.
Provider networks using Open vSwitch - network traffic flow - north/south

注釈

戻りのトラフィックは、同様の手順の逆順で処理されます。

East-west scenario 1: Instances on the same network

Instances on the same network communicate directly between compute nodes containing those instances.

  • インスタンス 1 はコンピュートノード 1 上にあり、プロバイダーネットワーク 1 を使用します。
  • インスタンス 2 はコンピュートノード 2 上にあり、プロバイダーネットワーク 1 を使用します。
  • インスタンス 1 がインスタンス 2 にパケットを送信します。

以下の手順は、コンピュートノード 1 で行われます。

  1. The instance 1 interface (1) forwards the packet to the security group bridge instance port (2) via veth pair.
  2. Security group rules (3) on the security group bridge handle firewalling and connection tracking for the packet.
  3. The security group bridge OVS port (4) forwards the packet to the OVS integration bridge security group port (5) via veth pair.
  4. The OVS integration bridge adds an internal VLAN tag to the packet.
  5. The OVS integration bridge int-br-provider patch port (6) forwards the packet to the OVS provider bridge phy-br-provider patch port (7).
  6. The OVS provider bridge swaps the internal VLAN tag with actual VLAN tag 101.
  7. The OVS provider bridge provider network port (8) forwards the packet to the physical network interface (9).
  8. The physical network interface forwards the packet to the physical network infrastructure switch (10).

以下の手順は、物理ネットワーク環境で行われます。

  1. スイッチは、コンピュートノード 1 からコンピュートノード 2 (11) へパケットを転送します

以下の手順は、コンピュートノード 2 で行われます。

  1. The physical network interface (12) forwards the packet to the OVS provider bridge provider network port (13).
  2. The OVS provider bridge phy-br-provider patch port (14) forwards the packet to the OVS integration bridge int-br-provider patch port (15).
  3. The OVS integration bridge swaps the actual VLAN tag 101 with the internal VLAN tag.
  4. The OVS integration bridge security group port (16) forwards the packet to the security group bridge OVS port (17).
  5. Security group rules (18) on the security group bridge handle firewalling and connection tracking for the packet.
  6. The security group bridge instance port (19) forwards the packet to the instance 2 interface (20) via veth pair.
Provider networks using Open vSwitch - network traffic flow - east/west scenario 1

注釈

戻りのトラフィックは、同様の手順の逆順で処理されます。

East-west scenario 2: Instances on different networks

Instances communicate via router on the physical network infrastructure.

  • インスタンス 1 はコンピュートノード 1 上にあり、プロバイダーネットワーク 1 を使用します。
  • インスタンス 2 はコンピュートノード 1 上にあり、プロバイダーネットワーク 2 を使用します。
  • インスタンス 1 がインスタンス 2 にパケットを送信します。

注釈

Both instances reside on the same compute node to illustrate how VLAN tagging enables multiple logical layer-2 networks to use the same physical layer-2 network.

以下の手順は、コンピュートノードで行われます。

  1. The instance 1 interface (1) forwards the packet to the security group bridge instance port (2) via veth pair.
  2. Security group rules (3) on the security group bridge handle firewalling and connection tracking for the packet.
  3. The security group bridge OVS port (4) forwards the packet to the OVS integration bridge security group port (5) via veth pair.
  4. The OVS integration bridge adds an internal VLAN tag to the packet.
  5. The OVS integration bridge int-br-provider patch port (6) forwards the packet to the OVS provider bridge phy-br-provider patch port (7).
  6. The OVS provider bridge swaps the internal VLAN tag with actual VLAN tag 101.
  7. The OVS provider bridge provider network port (8) forwards the packet to the physical network interface (9).
  8. The physical network interface forwards the packet to the physical network infrastructure switch (10).

以下の手順は、物理ネットワーク環境で行われます。

  1. The switch removes VLAN tag 101 from the packet and forwards it to the router (11).
  2. The router routes the packet from provider network 1 (12) to provider network 2 (13).
  3. The router forwards the packet to the switch (14).
  4. The switch adds VLAN tag 102 to the packet and forwards it to compute node 1 (15).

以下の手順は、コンピュートノードで行われます。

  1. The physical network interface (16) forwards the packet to the OVS provider bridge provider network port (17).
  2. The OVS provider bridge phy-br-provider patch port (18) forwards the packet to the OVS integration bridge int-br-provider patch port (19).
  3. The OVS integration bridge swaps the actual VLAN tag 102 with the internal VLAN tag.
  4. The OVS integration bridge security group port (20) removes the internal VLAN tag and forwards the packet to the security group bridge OVS port (21).
  5. Security group rules (22) on the security group bridge handle firewalling and connection tracking for the packet.
  6. The security group bridge instance port (23) forwards the packet to the instance 2 interface (24) via veth pair.
Provider networks using Open vSwitch - network traffic flow - east/west scenario 2

注釈

戻りのトラフィックは、同様の手順の逆順で処理されます。

updated: 2019-08-23 18:55
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug questions?