已解决问题
怎么查看自己的IP 网关 网络掩码 DNS1 DNS2 个是多少啊
浏览次数：10027
用手机阿里扫一扫
最满意答案
该答案已经被保护
win7&点左下角&在运行框输入&CMD回车，打开一个窗口，输入&config&/all&&查看你的适配器对应显示的内容就有了（会出来很多数据，找开头显示的那些）
答案创立者
以企业身份回答&
正在进行的活动
生意经不允许发广告，违者直接删除
复制问题或回答，一经发现，拉黑7天
快速解决你的电商难题
店铺优化排查提升2倍流量
擅长&nbsp 店铺优化
您可能有同感的问题
扫一扫用手机阿里看生意经
问题排行榜
当前问题的答案已经被保护，只有知县（三级）以上的用户可以编辑！写下您的建议，管理员会及时与您联络！
server is ok网关DNS自动切换器 V2.1绿色免费版
- 软件下载 - 绿茶软件园|33LC.com
&&&&&&&&&&&&网关DNS自动切换器 V2.1绿色免费版
网关DNS自动切换器 V2.1绿色免费版
软件大小：1.2305MB
软件语言：简体中文
软件授权：共享版
软件类别：网络其它
软件等级：
更新时间：
官方网站：www.33LC.com
应用平台：/WinXP/Server/Win7/Vista/
1.自动切换内网IP、子网掩码、网关、首选DNS、备选DNS
2.可以自己设定密码，防止别人乱改设置
3.提示当前所使用的线路
4.服务器可以随时控制客户端
5.客户端可以不用一台台更新配置
还有很多了，大家自己找吧。
本类推荐本类排行
热门软件热门标签Single-page HTML
Red Hat OpenStack Platform 9OpenStack Networking 高级指南OpenStack Documentation Team摘要
执行常见 OpenStack Networking 任务的实用手册。
OpenStack Networking（neutron）是 Red Hat OpenStack Platform 9 中的一个软件定义的网络组件。
1. OpenStack Networking 和 SDN
软件定义的网络（Software-defined Networking，简称 SDN）是一个用来描述虚拟网络功能的术语。虚拟环境中的服务器和物理服务器一样，仍然需要网络连接来接收和发送数据。SDN 通过把网络设备（如路由器和交换机）移到相同的虚拟空间来满足服务器对网络连接功能的要求。如果您熟悉基本的网络概念，则对了解网络功能的虚拟化不会有太多困难。
本文档中的第 1 部分向管理员介绍了基本的管理和故障排除任务，第 2 部分以实用手册的形式展示了 OpenStack Networking 的高级功能。如果您对网络的基本概念已有了解，则可以从第 1 部分开始阅读；如果您需要了解网络的基本概念，序言部分提供了相关的内容。
1.1. 本文档中包括的主题
序言 - 介绍了在一个大型机构中实施 SDN 可能要涉及到的“政治因素”，并包括了对常规网络概念的简单介绍。
第 1 部分 - 包括了常见管理任务和基本故障排除的步骤：
添加和删除网络资源
基本的网络故障排除
租户网络的故障排除
第 2 部分 - 以实用手册的形式展示了 OpenStack Networking 的高级功能。包括：
为虚拟路由配置 3 层高可用性功能
配置 SR-IOV、DVR 以及其它 Neutron 功能
2. 虚拟网络的“政治因素”
通过 SDN，工程师可以基于 OpenStack 或 RHEV 在虚拟环境中实施虚拟路由器和交换机。另外，SDN 还会改变计算机间的数据包传输的处理方式。在没有使用 SDN 以前，处理网络数据的路由器和交换机都是物理设备，并需要使用各种网线把在这些物理设备进行连接。在使用 SDN 时，部署和操作这些网络功能只需点几个按钮。
在任何大型虚拟环境中使用 SDN 都可能会在不同部门间产生一些“矛盾”。虚拟系统工程师可能并不了解一些高级的网络概念，而他们却需要在云环境中管理虚拟路由器和交换机，并需要考虑 IP 地址分配、VLAN 隔离以及子网等与网络相关的问题。同时，网络工程师会发现，原来由他们所负责的技术成为了其它部门讨论的话题，并由此产生种种不适，甚至感到自己的工作稳定性受到了威胁。另外，这还会把故障排除的过程复杂化：当系统出现问题，或系统间无法进行网络连接时，虚拟系统工程师可能会需要网络工程师的介入来查看数据包是否在物理交换设备间出现了问题。
当把您的虚拟网络看做为物理网络的一个扩展部分时，以上问题可能就会变得简单。默认网关、路由、子网这些概念的含义和作用都是相同的，虚拟网络仍然使用 TCP/IP、VLAN 和 MAC 地址。通常情况下，虚拟交换机是基于物理交换机上的 VLAN 配置的，它们只是物理网络的一个扩展。
除了做好各部门间的协调外，还可以使用一些已有技术来帮助解决以上问题。例如，Cisco’s Nexus 系列产品允许 OpenStack 操作者部署运行已被大众熟悉的 Cisco NX-OS 的虚拟路由器。这样，网络工程师就可以使用和登录到 Cisco 物理网络设备同样的方式登录并管理虚拟网络端口。如果网络工程师不需要管理虚拟网络，在开始设计虚拟网络时邀请他们介入也会是一个好的做法。OpenStack 节点需要使用物理网络架构、IP 地址需要被分配、物理交换机的接口需要进行配置来支持 VLAN。另外，除了故障排除外，在其它一些情况下也需要虚拟系统团队和网络团队的合作。例如，在调整虚拟机的 MTU 大小时，包括虚拟和物理交换机和路由器在内的所有端点都需要进行设置，这将需要两个团队间的密切合作。
在您的虚拟环境中，网络工程师仍然非常重要，特别是在您使用 SDN 技术时。因为 SDN 的复杂性，网络工程师在网络方面的专业知识对您系统的正常运行会大有益处。
第 1 章 网络概述1.1. 网络如何工作
Networking（网络）这个术语被用来代表在一个计算机和另外一个计算机间进行的信息传递。在一个最基本的层面上，它是通过在分别安装了网卡（NIC）的两个机器间的网线上实现的。
在 OSI 网络模型中，它是第 1 层。
如果您需要把多于两个的计算机进行连接，则需要添加一个交换机。企业级的交换机都会带有多个以太网端口用来连接额外的机器。现在，您就有了一个“局域网”（Local Area Network，简称 LAN）。
交换机位于 OSI 模型的第 2 层，它会比第 1 层更智能一些：每个 NIC 都有一个与硬件关联的唯一 MAC 地址，连接到同一个交换机的设备可以通过 MAC 地址相互进行通讯。交换机会管理一个记录了哪些 MAC 地址连接到哪个端口的信息列表。当一个设备需要和另外一个设备进行通讯时，交换机就可以根据这个列表中的信息正确处理网络数据，并调整用来记录 MAC 地址到端口的映射信息的 FIB（Forwarding Information Base）中的数据。
1.2. 连接两个 LAN
当您有两个分别运行于两个相互独立的交换机上的 LAN，并需要在它们之间共享信息时，您有两个选择可以实现这个功能：
选择一：使用“主干网线（trunk cable）”把两个交换机连接在一起。您需要把网线的两端分别插入到两个交换机的各一个端口中，然后把这些端口配置为主干端口（trunk port）。通过这些配置，您实际上把这两个交换机配置为一个大的逻辑交换机，连接到这两个交换机上的所有设备就可以相互进行通讯。这个方案会带来扩展性问题，当所连接的交换机数量太多时，相应的工作负载会成为一个问题。
选择二：使用网线把所有交换机连接到一个路由器设备，从而可以使路由器知道每个交换机的配置。连接到交换机的一端会被分配一个 IP 地址，它被称为默认网关。默认网关定义了，当所发送数据的目的地没有位于同一个 LAN 时，它需要先被发送到的地址。当数据被发送到这个默认网关所定义的地址上后，路由器会处理以后需要发送的地址。因为路由器知道哪些网络位于哪些端口的信息，它可以把数据发送到正确的目的地。路由功能位于 OSI 模型的第 3 层，IP 地址和子网也都在这一层上实现。
互联网本身就是通过这个概念进行工作的。不同机构的独立网络通过交换机和路由器连接到一起，通过相关的默认网关，网络数据就可以被发送到正确的地址。
1.2.1. VLAN
使用 VLAN 可以对连接到同一个网络交换机上的计算机进行分离。换句话说，您可以通过配置端口来把交换机上的网络进行逻辑分割，从而形成多个“迷你” LAN，达到通过分隔网络数据实现数据安全的目的。例如，您的交换机共有 24 个端口，您可以把端口 1-6 配置为属于 VLAN200，把端口 7-18 配置为属于 VLAN201。连接到 VLAN200 中的计算机将和连接到 VLAN201 中的计算机完全分离，它们将无法直接进行通讯。如果您需要这两个网络中的计算机进行相互通讯，则需要通过一个路由器（这和使用两个独立的物理交换机的情况一样）。在这种情况下，防火墙就可以被用来监控 VLAN 间的网络通讯。
1.2.2. 防火墙
防火墙和 IP 路由操作位于同一个 OSI 层中，但在管理基于 TCP/UDP 端口号的网络数据时它也可以在第 4 层工作。防火墙通常会和路由器处于相同的网段中来处理所有网络间的通讯。防火墙代表了一组预定义的规则，这些规则指定了哪些网络流量可以进入网络，以及哪些网络流量不能进入网络。这些规则可以高度“颗粒化”，例如：
"VLAN200 中的服务器只可以和 VLAN201 中的计算机进行通讯，并且只能在周四下午进行，并且只允许单向传输加密的网络数据（HTTPS）"。
为了保证这些规则的有效性，一些防火墙还会在第 5 层到第 7 层中执行深度包检测（Deep Packet Inspection，简称 DPI）。网络黑客通常会使用网络数据伪装的手法来对系统的安全性进行破坏，而 DPI 会检查数据包中的实际内容来确定它们的真实性，从而降低网络安全被破坏的可能性。
1.3. OpenStack 中的网络
以上概念在 OpenStack 中完全适用，只是在 OpenStack 中被称为软件定义的网络（SDN）。虚拟交换机（使用 Open vSwitch）和虚拟路由器（l3-agent）提供了在实例间进行通讯的功能，并可以为实例提供与外部网络进行通讯的能力。Open vSwitch 网桥会为实例分配虚拟端口，并可以使入站和出站的网络数据分散到相关的物理网络中。
1.4. 高级 OpenStack 网络概念1.4.1. 第 3 层高可用性
OpenStack Networking 在一个中央化的网络节点（一个专门用于运行虚拟网络组件的物理服务器）上运行虚拟路由器。这些虚拟路由器被用来处理发送到虚拟机或从虚拟机发出的网络数据，因此它们是保证整个环境的网络正常运行的重要元素。因为物理机可能会出现故障（这种情况是不可避免的），所以当网络节点出现故障时，您的虚拟机将无法正常工作。
OpenStack Networking 使用第 3 层高可用性功能来帮助减少以上问题的出现。它通过实现业界标准的 VRRP 协议来保护虚拟路由器和浮动 IP 地址。在启用了第 3 层高可用性功能后，租户的虚拟路由器会被随机地在多个网络节点上进行分配，其中的一个路由器被指定为“活跃的”路由器，其它路由器作为“备份”路由器。当运行活跃路由器的网络节点出现故障时，备份路由器会作为活跃路由器使用。
这里的"第 3 层"代表了 OSI 模型中的第 3 层，因此它会保护 OSI 模型第 3 层中提供的网络功能，包括路由和 IP 地址。
如需了解更多相关信息，请参阅"配置第 3 层高可用性"一章。
1.4.2. HAproxy
作为高可用性（HA）解决方案的一部分，HAProxy 是一个用来在所有可用控制器间分配连接的内建负载均衡程序（与 LBaaS 不同）。因为 HAProxy 是基于分配给每个服务的 UDP/TCP 端口号的，所以它需要在第 4 层中工作。VRRP 会决定连接要被初始发送到哪个 HAProxy 实例，然后 HAProxy 会把连接分配到后端的服务器。这种配置可以被认为是高可用性的负载均衡服务，这与以下介绍的 LBaaS 有所不同。
1.4.3. 负载均衡既服务（LBaaS）
负载均衡即服务（Load Balancing-as-a-Service，简称 LBaaS）使 OpenStack Networking 可以在相关的实例中平均分配入站的网络流量。这保证了入站的网络流量所带来的工作负载以可预测的方式在多个实例中共享，从而达到有效使用系统资源的目的。入站的网络流量以下面的方法之一进行分配：
轮转（Round robin） - 在多个实例间均匀轮转分配请求。
源 IP（Source IP） - 从同一个源 IP 地址发送的请求会被分配到同一个实例。
最少连接数量（Least connections） - 把请求分配到有最少活跃连接数量的实例。
如需了解更多相关信息，请参阅"配置负载均衡既服务（LBaaS）"。
1.4.4. IPv6
OpenStack Networking 支持在租户网络中使用 IPv6，这意味着您可以为虚拟机动态地分配 IPv6 地址。OpenStack Networking 也可以集成物理路由器上的 SLAAC，从而使虚拟机可以从您已有的 DHCP 系统中获得 IPv6 地址。
如需了解更多相关信息，请参阅"在租户网络中使用 IPv6" 一章。
1.4.5. CIDR 格式
IP 地址通常首先会在子网的地址段中进行分配。例如，子网掩码为 255.555.255.0 的 IP 地址段 192.168.100.0 - 192.168.100.255 可以提供 254 个 IP 地址（第一个和最后一个地址会被保留）。
这些子网可以使用多种形式代表：
常规形式：子网地址的传统表示方法是使用网络地址和子网掩码。例如：
网络地址：192.168.100.0
子网掩码：255.255.255.0
CIDR 格式：这种格式把子网掩码缩短为使用实际的位数进行代表。例如，192.168.100.0/24。其中的 /24 代表了 255.255.255.0（这个子网掩码的二进制形式共有 24 位 1）。在 ifcfg-xxx 脚本中可以使用 CIDR 格式来替代 NETMASK 值：
#NETMASK=255.255.255.0
PREFIX=24第 2 章 OpenStack Networking 概念
OpenStack Networking 具有一系列系统服务用来管理关键服务（如路由、DHCP 和元数据），这些服务构成了网络节点这一概念。网络节点是分配给一个物理服务器的概念性角色。通常，网络节点角色会分配给一个物理服务器，这个服务器专门用于处理与实例相关的第 3 层网络流量。在 OpenStack Networking 中，您可以为多个物理服务器分配这个角色，从而可以在出现硬件故障时实现容错的功能。如需了解更多相关信息，请参阅第 3 层高可用性一章。
2.1. 安装 OpenStack Networking（neutron）2.1.1. 安装方式
在 Red Hat OpenStack Platform 9（Mitaka）中，OpenStack Networking 组件作为 RHEL OpenStack director 实施的一部分被安装。请参阅 RHEL OpenStack director 安装指南来获取更多相关信息。
2.2. OpenStack Networking 示意图
这个示意图显示了一个 OpenStack Networking 实施示例，它带有一个专用的 OpenStack Networking 节点来提供 L3 路由和 DHCP 功能，并运行 FWaaS 和 LBaaS 服务。另外，还有两个 Compute 节点运行 Open vSwitch（ovs-agent），每个上面有两个物理网卡，一个用来处理租户网络数据，一个用来管理网络连接。OpenStack Networking 节点还带有第 3 个网卡用来处理供应商网络流量：
2.3. 安全组
安全组和相关规则根据网络数据的类型和传送方向过滤发送到特定 neutron 端口的网络流量，它在 Compute 实例的防火墙规则之外提供了额外的安全层。安全组是带有一个或多个安全规则的容器项，它可以管理到多个 Compute 实例的网络流量。那些为浮动 IP 地址、OpenStack Networking LBaaS VIP、路由器接口以及实例所创建的端口都需要与一个安全组相关联。如果没有指定，端口会使用默认的安全组，它会拒绝所有入站的网络流量，而只允许出站的网络流量。如果需要，可以为默认的安全组添加额外的规则，或创建新的安全组。Open vSwitch、Linux Bridge、VMware NSX、NEC 和 Ryu 网络插件当前都支持安全组功能。
和 Compute 的安全组不同，OpenStack Networking 的安全组是基于一个端口的，而不是基于一个实例的。
2.4. Open vSwitch
Open vSwitch（OVS）是一个用来替代 Linux 软件网桥的 SDN 虚拟交换机。OVS 为虚拟网络提供了网络数据交换服务，并支持业界标准的 NetFlow、OpenFlow 和 sFlow。Open vSwitch 同时也可以和使用第 2 层功能（STP、LACP 和 802.1Q VLAN tagging）的交换机进行集成。Open vSwitch 版本 1.11.0-1.el6 或更新版本支持 Open vSwitch 隧道（tunneling）功能。
不要在 LACP 中使用基于 OVS 的绑定，因为这个配置会出现问题，而且不被支持。可以使用 bond_mode=balance-slb 作为替代来实现相关的功能。另外，您仍然可以使用带有 Linux 绑定的 LACP。
2.5. Modular Layer 2（ML2）
ML2 是从 OpenStack 的 Havana 发行版本开始提供的一个新的 OpenStack Networking 核心插件。ML2 取代了以前的单插件模式，而支持同时使用混合的网络技术。Open vSwitch 和 linuxbridge 插件已过时，并将不会包括在以后的发行版本中。它们的功能已在 ML2 中实现。
ML2 是默认的 OpenStack Networking 插件，它使用 Open vSwitch 作为默认的机制驱动。
2.5.1. 使用 ML2 的原因
在以前，OpenStack Networking 只能使用在部署时所选择的插件。例如，运行 Open vSwitch 插件的系统只能使用 Open vSwitch，而不能使用其它插件（如 linuxbridge）。这会在一个有多种要求的环境中造成相关的限制。
2.5.2. ML2 网络类型
多种网络段类型可以同时运行。另外，这些网络段还可以使用 ML2 对多段网络的支持功能进行相互的连接。端口会自动与相关的网络段相关联，而不需要把它们与特定网络端绑定。根据所使用的驱动，ML2 支持以下网络端类型：* flat * GRE * local * VLAN * VXLAN
不同的类型驱动在 ml2_conf.ini 文件中的 ML2 项中指定：
type_drivers = local,flat,vlan,gre,vxlan2.5.3. ML2 机制
现在，插件以带有通用代码库的机制被重新实现。使用这个机制，可以重复使用通用的代码，从而简化了维护和测试代码的复杂性。
如需获得支持的机制驱动信息，请参阅 。
不同的机制驱动在 ml2_conf.ini 文件中的 ML2 项中指定。例如：
mechanism_drivers = openvswitch,linuxbridge,l2population
如果使用 Red Hat OpenStack Platform director 进行部署，则这些设置会由 puppet 进行管理，而不应该被手工修改。
2.6. OpenStack 的网络后端
Red Hat OpenStack 提供了两个不同的网络后端：Nova networking 和 OpenStack Networking（neutron）。Nova networking 在 OpenStack 技术的发展规划中已过时，但当前仍然被提供；而 OpenStack Networking 被看作为一个 OpenStack 发展规划中的核心 SDN 组件，并在不断被开发完善。请注意，当前还没有在 Nova networking 和 OpenStack Networking 间进行迁移的方案，如果您计划先使用 Nova networking，然后再升级到 OpenStack Networking，这一点将会是一个非常重要的考虑因素。当前，如需在这两种技术间进行迁移，则需手工进行，并需要一定的停机时间。
Nova networking 不能使用 Red Hat OpenStack Platform Director 部署。
2.6.1. 使用 OpenStack Networking（neutron）
如果您需要一个覆盖网络（overlay network）解决方案：OpenStack Networking 支持使用 GRE 或 VXLAN 隧道（tunneling）来对虚拟机的网络流量进行隔离。当使用 GRE 或 VXLAN 时，在网络 fabric 上不需要 VLAN 的配置，对物理网络的唯一要求就是在节点间提供 IP 连接。另外，在理论上，VXLAN 或 GRE 对 ID 数量的限制是一千六百万（16,000,000），这远远超过了 802.1q VLAN ID 的最大数量 - 4094。Nova networking 是基于 802.1q VLAN 实现网络隔离的，它不支持 GRE 或 VXLAN 隧道功能。
如果不同的租户需要使用相互重叠的 IP 地址：OpenStack Networking 使用 Linux 内核的网络命名空间，它允许不同的租户在同一个 Compute 节点上使用相同的子网范围（例如 192.168.1/24），而不会造成相互间的影响。相反，Nova networking 只提供扁平化的网络拓扑结构，在为所有租户分配子网时必须十分小心。
如果需要一个经过红帽认证的第三方 OpenStack Networking 插件：在默认情况下，Red Hat OpenStack Platform 8 使用带有Open vSwitch（OVS）机制驱动的开源 ML2 内核插件。因为 OpenStack Networking 具有可插入式的构架，所以用户可以基于物理网络 fabric 和其它的网络要求，使用第三方的 OpenStack Networking 插件替代默认的 ML2/Open vSwitch 驱动配置。红帽一直不断致力于通过我们的合作伙伴计划为 Red Hat OpenStack Platform 认证更多的 OpenStack Networking 插件。如需了解更多与认证计划相关的信息，以及已认证的 OpenStack Networking 插件，请访问 。
如果需要 Firewall-as-a-service（FWaaS）或 Load-Balancing-as-a-service（LBaaS）：只有 OpenStack Networking 提供这些服务，Nova networking 不提供这些服务。租户可以在不通过管理员的情况下，使用 dashboard 来管理这些服务。
2.6.2. 使用 Nova Networking
如果您需要扁平化（untagged）网络或 VLAN（802.1q tagged）网络：这涉及到对可扩展性的要求（在理论上，最大的 VLAN ID 数量是 4094，而物理交换机实际支持的数量可能远远少于这个数量），以及对管理和部署的要求。在物理网络上需要进行特定的配置来在节点间分配 VLAN。
如果不同的租户不需要相互重叠的 IP 地址：这通常只适用于小的、私用的环境。
如果您不需要 SDN 解决方案，或不需要和物理网络 fabric 进行交互。
如果您不需要自服务的 VPN、防火墙或负载均衡服务。
2.7. L2 Population
L2 Population 驱动支持使用广播、多播和单播方式在覆盖网络中进行扩展。在默认情况下，Open vSwitch GRE 和 VXLAN 会复制广播到包括那些没有运行目标网络的每个代理。这种设计导致了大量的网络和处理负载。而 L2 Population 驱动使用了另外一种设计观念，它为 ARP 解析以及 MAC 地址学习功能提供了一个部分的网状网络（mesh），网络数据会被打包作为目标单波只发送到相关的代理上。为了启用 L2 population，您需要把它添加到机制驱动列表中。另外，您还需要最少启用一个隧道（tunneling）驱动（GRE、VXLAN 或两个都启用）。在 ml2_conf.ini 文件中添加适当的配置：
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,linuxbridge,l2population
在 ovs_neutron_plugin.ini 文件中启用 L2 population。这需要在所有运行 L2 agent 的节点上都启用：
l2_population = True2.8. OpenStack Networking 服务
OpenStack Networking 集成了多个组件来为您的环境提供网络功能：
2.8.1. L3 Agent
L3 agent 是 openstack-neutron 软件包的一部分，它的功能是作为一个虚拟的第 3 层路由器来处理网络流量，并为第 2 层网络提供网关服务。L3 agent 所在节点的网络接口不能带有手工配置的、连接到一个外部网络的 IP 地址。它需要具有一组可以被 OpenStack Networking 使用的、来自于外部网络的 IP 地址，这些 IP 地址会分配给用来连接内部网络和外部网络的路由器。这组地址的规模需要足够大来为每个路由器分配 IP 地址，并可以分配相关的浮动 IP。
DHCP Agent - OpenStack Networking DHCP agent 可以为在网络中运行的虚拟机分配 IP 地址。如果这个 agent 被启用，并在创建子网时运行，则 DHCP 功能会在子网中默认启用。
Plug-in Agent - 许多网络插件都可以利用它们自己的 agent（包括 Open vSwitch 和 Linux Bridge）。针对于特定插件的 agent 会在每个管理网络流量的节点上运行，包括所有计算节点，以及运行专用 agent（neutron-dhcp-agent 和 neutron-l3-agent）的节点。
2.9. 租户和供应商网络
下图展示了租户网络和供应商网络的类型，以及它们如何在整个 OpenStack Networking 拓扑中工作：
2.9.1. 租户网络
租户网络（Tenant network）是用户创建的、用来在项目中提供连接功能的网络，它们在默认情况下被完全分离，并且不会和其它项目进行共享。OpenStack Networking 支持以下网络类型：
Flat（扁平化） - 所有实例都位于同一个网络中。这个网络可以被主机共享，并且没有 VLAN tagging 或其它网络分离功能。
VLAN（虚拟局域网） - OpenStack Networking 允许用户使用 VLAN ID （802.1Q tagged）在物理网络中创建多个供应商（provider）或租户（tenant）网络。这将使实例可以和环境中的其它实例进行通讯，并可以和位于同一个第 2 层 VLAN 中的专用服务器、防火墙、负载均衡设备以及其它网络基础设施进行通讯。
您也可以为租户网络配置 QoS 策略。如需了解更多相关信息，请参阅 。
2.9.2. VXLAN 和 GRE 隧道
VXLAN 和 GRE 使用网络覆盖（network overlay）来支持实例间的私人通讯。如果要进行到 GRE 或 VXLAN 租户网络外的网络通讯，则需要一个 OpenStack Networking 路由器。另外，如果需要连接到和外部网络（包括 Internet）直接连接的租户网络时，也需要一个路由器，路由器提供了使用浮动 IP 地址从一个外部网直接连接到实例的功能。
2.9.3. 供应商网络
供应商网络（Provider network）由 OpenStack 管理员创建，并直接映射到数据中心中存在的一个物理网络上。这个网络的网络类型包括 flat（untagged）和 VLAN（802.1Q tagged）。作为网络创建的一部分，供应商网络可以被租户共享。
2.9.3.1. 扁平化供应商网络
您可以使用扁平化（flat） 供应商网络直接把实例连接到外部网络。当有多个物理网络（例如，physnet1 和 physnet2），而且有独立的物理接口（eth0 - & physnet1 和 eth1 → physnet2），并需要把每个 Compute 节点和 Network 节点连接到它们的外部网络时使用这个网络类型。如果您需要使用在一个接口上的多个 vlan-tagged 接口连接到多个供应商网络，请参阅 。
2.9.3.2. 配置控制器节点
1. 编辑 /etc/neutron/plugin.ini（它是到 /etc/neutron/plugins/ml2/ml2_conf.ini 文件的 symbolic link），把 flat 添加到已存在的值列表中，把 flat_networks 设置为 *：
type_drivers = vxlan,flat
flat_networks =*
2. 创建一个外部网络作为 flat 网络，并把它和配置的 physical_network 进行关联。如果把它作为一个共享网络创建（使用 --shared），将允许其它用户在其中直接创建实例。
neutron net-create public01 --provider:network_type flat --provider:physical_network physnet1 --router:external=True --shared
3. 使用 neutron subnet-create 或 Dashboard 创建一个子网。
# neutron subnet-create --name public_subnet --enable_dhcp=False --allocation_pool start=192.168.100.20,end=192.168.100.100 --gateway=192.168.100.1 public 192.168.100.0/24
4. 重启 neutron-server 服务以使所做的改变生效：
systemctl restart neutron-server2.9.3.3. 配置 Network 节点和 Compute 节点：
在 network 节点和 compute 节点上进行这些操作。这将把节点连接到外部网络，并使实例可以直接和外部网络进行通讯。
1. 创建一个外部网桥（br-ex），并为它添加一个相关联的端口（eth1）：
在 /etc/sysconfig/network-scripts/ifcfg-br-ex 中创建外部网桥：
DEVICE=br-ex
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
在 /etc/sysconfig/network-scripts/ifcfg-eth1 中，把 eth1 配置为与 br-ex 相连：
DEVICE=eth1
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
重启节点或网络服务以使所做的修改生效。
2. 在 /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini 中配置物理网络，把网桥映射到相关的物理网络：
bridge_mappings = physnet1:br-ex
如需了解更多与网桥相关的信息，请参阅 。
3. 在 Network 节点和 Compute 节点上重启 neutron-openvswitch-agent 服务以使所做改变生效：
systemctl restart neutron-openvswitch-agent2.9.3.4. 配置网络节点
1. 把 /etc/neutron/l3_agent.ini 文件中的 external_network_bridge = 设为空值。
以前，当只使用一个网桥连接到外部网络时，OpenStack Networking 会使用 external_network_bridge。现在，这个值可以是一个空字符串，这将允许多个外部网桥，OpenStack Networking 会为每个到 br-int 的网桥创建一个 patch。
# Name of bridge used for external network traffic. This should be set to
# empty value for the linux bridge
external_network_bridge =
2. 重启 neutron-l3-agent 以使所做的修改生效。
systemctl restart neutron-l3-agent
如果有多个 flat 供应商网络，每个网络都需要有独立的物理网络接口和网桥来与外部网络连接。请正确配置 ifcfg-* 脚本，并在 bridge_mappings 中设置网络映射（使用一个由逗号分隔的网络列表）。如需了解更多与网络映射相关的信息，请参阅。
2.10. 第 2 层和第 3 层网络
在设计网络时，您需要考虑多数网络流量在哪里进行。因为在不同逻辑网络间传递数据需要经过路由器，所以在同一个网络中传递网络数据比在不同网络间传递数据的速度要快。
下图展示了在独立 VLAN 中的实例间进行网络数据传输的过程。
即使在这种配置中使用高性能的硬件路由器，仍然会造成额外的速度延迟。
2.10.1. 尽量使用网络交换
网络数据交换的操作发生在更低的网络层上（第 2 层），因此它的速度比在第 3 层上的数据路由要快很多。在设计网络时，您需要考虑把经常要进行通讯的系统放置到临近的位置。例如，下图展示了一个包括了两个物理节点的交换网络，这就使其中两个实例可以在不需要进行网络路由的情况下就可以直接进行通讯。您可以注意到，实例共享相同的子网，这代表它们在同一个逻辑网络中：
为了使独立节点上的实例可以象在同一个逻辑网络中一样进行通讯，需要使用“隧道（tunnel）”技术，如 VXLAN 或 GRE。我们推荐您考虑调整端点上的 MTU 的设置，从而可以处理隧道头所包括的额外数据，否则网络性能可能会因为网络被分隔受到负面影响。另外，您还可以使用支持的、带有 VXLAN offload 功能的硬件来进一步提高 VXLAN 隧道的性能。如需了解这些硬件的完整列表，请参阅
部分 I. 常见任务
常见的管理任务以及基本的故障排除步骤。
第 3 章 常见的管理任务
OpenStack Networking（neutron）是一个软件定义的 Red Hat OpenStack Platform 网络组件。通过虚拟网络的基本架构，实例和外部物理网络就可以进行网络连接。
本节介绍了常见的管理任务，如根据您的 Red Hat OpenStack Platform 部署添加、删除子网和路由器。
3.1. 创建网络
通过创建网络，您的实例间将可以进行通讯，并可以使用 DHCP 获得 IP 地址。网络也可以和您的 Red Hat OpenStack Platform 部署或其它部署中的外部网络（如物理网络）进行集成。通过集成，您的实例将可以和外部系统进行交流。如需了解把您的网络和外部物理网络进行集成的信息，请参阅 “桥接物理网络”。
在创建网络时，一个重要因素您需要进行考虑：网络可以包括多个子网。这一点对于需要在同一个网络中提供相互独立的不同系统的环境非常重要。例如，您可以使 webserver 的网络流量只在一个子网中有效，而数据库网络流量在另外的子网中有效。每个子网都独立于其它子网，如果实例需要和其它子网进行通讯，必须经过一个网络路由器。您可以考虑把相互间需要进行大量网络通讯的系统放置在同一个子网中，这将会尽量避免网络路由，从而提高网络的性能。
1. 在 dashboard 中选择项目 & 网络 & 网络。
2. 点 +创建网络并设置以下项：
3. 点下一步按钮，在子网标签页中指定以下项：
4. 点下一步来设置 DHCP 选项：
启用 DHCP - 在这个子网中启用 DHCP 服务。DHCP 可以为您的实例自动分配 IP 设置。
IPv6 地址 - 如果创建一个 IPv6 网络，指定 IPv6 地址和其它额外信息是如何分配的。
未指定选项 - 如果手工设置 IP 地址，或使用非 OpenStack 支持的方法分配地址，则使用这个选项。
SLAAC (Stateless Address Autoconfiguration) - 实例基于 OpenStack Networking 路由器发送的 RA（Router Advertisement）信息生成 IPv6 地址。使用这个配置的结果是，在创建 OpenStack Networking 子网时，ra_mode 和 address_mode 都被设置为 slaac。
DHCPv6 stateful - 实例从 OpenStack Networking DHCPv6 服务接收 IPv6 地址以及其它选项（如 DNS）。使用这个配置的结果是，在创建网络时，ra_mode 和 address_mode 都被设置为 dhcpv6-stateful。
DHCPv6 stateless - 实例基于 OpenStack Networking 路由器发送的 RA（Router Advertisement）信息生成 IPv6 地址。其它额外的选项（如 DNS）由 OpenStack Networking DHCPv6 服务分配。使用这个配置的结果是，在创建网络时，ra_mode set 和 address_mode 都被设置为 dhcpv6-stateless。
分配池 - DHCP 分配的 IP 地址范围。例如，192.168.22.100,192.168.22.100 代表范围内的所有 up 的地址都可以被分配。
DNS 域名解析服务器 - 网络中可用的 DNS 服务器的 IP 地址。DHCP 把这些地址分配给实例用来进行域名解析。
主机路由 - 静态主机路由。首先以 CIDR 的格式指定目标网络，然后指定下一个处理路由的地址。例如：192.168.23.0/24, 10.1.31.1。如果您需要为实例静态分配路由信息，请设置这个选项。
5. 点创建。
创建的网络可以在网络标签页中查看。您可以根据需要，通过点编辑来修改它的选项。现在，当您创建实例时，可以配置它来使用这个子网，并获得相应的 DHCP 选项。
3.2. 创建高级网络
当管理员通过管理员界面创建网络时，可以使用高级网络选项。这些选项定义了要使用的网络类型，并允许指定租户：
1. 在 dashboard 中，选择管理员 & 网络 & 创建网络 & 项目。在项目中选择一个项目来运行这个新网络。
2. 检查供应商网络类型中的选项：
Local - 网络流量只在本地 Compute 主机上传输，它的实际效果是和所有外部网络隔离。
Flat - 通讯数据被限制在一个单独的网络中，并可以和其它主机共享。没有 VLAN tagging 或其它网络分离的功能。
VLAN - 使用代表了物理网络中的一个 VLAN 的 VLAN ID 来创建网络。这可以使实例和处于相同 2 层 VLAN 中的系统进行交流。
GRE - 使用一个跨多个节点的网络覆盖（network overlay）来为实例间提供私人网络通讯。从网络覆盖出站的网络流量需要被路由。
VXLAN - 和 GRE 类似，使用一个跨多个节点的网络覆盖（network overlay）来为实例间提供私人网络通讯。从网络覆盖出站的网络流量需要被路由。
点创建网络，检查项目的网络拓扑来确认网络已被成功创建。
3.3. 添加网络路由
为了使网络数据可以路由到您的新网络，或从新网络中路由出来，您需要把它的子网添加为一个已存在虚拟路由器的接口：
1. 在 dashboard 中选择项目 & 网络 & 路由。
2. 在路由列中选您的虚拟路由器名称，点 +添加接口。在子网列表中选择您的新子网的名称。您也可以为这个接口指定一个 IP 地址。
3. 点增加接口。
现在，您网络中的实例就可以和子网以外的系统进行交流。
3.4. 删除网络
在一些情况下，您可能需要删除以前创建的网络。为了成功删除一个网络，您需要首先删除或断开所有使用它的接口。以下介绍了在项目中删除网络的方法。
1. 在 dashboard 中，选择项目 & 网络 & 网络。删除和目标网络的子网相关联的所有路由接口。删除一个接口的步骤是：在网络列中点目标网络来找到需要删除的网络的 ID（在 ID 项中显示）。所有和这个网络相关联的子网都在它们的网络 ID 项中共享这个值。
2. 选择项目 & 网络 & 路由，在路由列表中选您的虚拟路由器的名称，并找到附加到需要删除的子网上的接口。您可以通过它的 IP 地址（网关的 IP 地址）来和其它接口区分开。另外，它的网络接口 ID 应该和上一步获得的 ID 相匹配。
3. 点接口的删除接口按钮。
选择项目 & 网络 & 网络，点您的网络名。点目标子网的删除子网按钮。
如果您还不能删除子网，请检查它是否还被其它实例使用。
选项目 & 网络 & 网络，然后选项您需要删除的网络。提示时点删除网络，在下一个界面中再次确认。
3.5. 清除（purge）租户的网络
在 Red Hat OpenStack Platform 9 以前的版本中，在删除一个项目后，还存在分配给这个项目的资源，这包括网络、路由和端口。这些资源需要被手工删除，而且需要以正确的顺序删除。在 Red Hat OpenStack Platform 9 中，可以使用 neutron purge 命令来删除以前属于一个特定项目的所有 neutron 资源。
例如，在删除 test-project 前，需要 purge 它的 neutron 资源：
# openstack project list
+----------------------------------+--------------+
+----------------------------------+--------------+
| 02eb438dbcaac0 | test-project |
| 519ec079c8e2eabb690023b | services
| 80bf28e612fe615c886c6 | demo
| 98a2f53c20ce4d50a40dac4a38016c69 | admin
+----------------------------------+--------------+
# neutron purge 02eb438dbcaac0
Purging resources: 100% complete.
Deleted 1 security_group, 1 router, 1 port, 1 network.
# openstack project delete 02eb438dbcaac03.6. 创建子网
子网为相关的实例提供了网络连接功能。在每个实例的创建过程中，都需要被分配一个子网，您需要仔细考虑实例和子网的设置，以最好地满足您的网络连接需求。子网是在已存在的网络中创建的。一个需要考虑的重要因素是：OpenStack Networking 中的租户网络可以包括多个子网。这一点对于需要在同一个网络中提供相互独立的不同系统环境的情况非常重要。例如，您可以使 webserver 的网络流量只在一个子网中有效，而数据库网络流量在另外的子网中有效。每个子网都独立于其它子网，如果实例需要和其它子网进行通讯，必须经过一个网络路由器。您可以考虑把相互间需要进行大量网络通讯的系统放置在同一个子网中，这将会尽量避免网络路由，从而提高网络的性能。
3.6.1. 创建一个新子网
在 dashboard 中，选择项目 & 网络 & 网络，然后在网络项中点您的网络名称。
1. 点创建子网，然后指定以下项。
2. 点下一步来设置 DHCP 选项：
启用 DHCP - 在这个子网中启用 DHCP 服务。DHCP 可以为您的实例自动分配 IP 设置。
IPv6 地址 - 如果创建一个 IPv6 网络，指定 IPv6 地址和其它额外信息是如何分配的。
未指定选项 - 如果手工设置 IP 地址，或使用非 OpenStack 支持的方法分配地址，则使用这个选项。
SLAAC (Stateless Address Autoconfiguration) - 实例基于 OpenStack Networking 路由器发送的 RA（Router Advertisement）信息生成 IPv6 地址。使用这个配置的结果是，在创建 OpenStack Networking 子网时，ra_mode 和 address_mode 都被设置为 slaac。
DHCPv6 stateful - 实例从 OpenStack Networking DHCPv6 服务接收 IPv6 地址以及其它选项（如 DNS）。使用这个配置的结果是，在创建网络时，ra_mode 和 address_mode 都被设置为 dhcpv6-stateful。
DHCPv6 stateless - 实例基于 OpenStack Networking 路由器发送的 RA（Router Advertisement）信息生成 IPv6 地址。其它额外的选项（如 DNS）由 OpenStack Networking DHCPv6 服务分配。使用这个配置的结果是，在创建网络时，ra_mode set 和 address_mode 都被设置为 dhcpv6-stateless。
分配池 - DHCP 分配的 IP 地址范围。例如，192.168.22.100,192.168.22.100 代表范围内的所有 up 的地址都可以被分配。
DNS 域名解析服务器 - 网络中可用的 DNS 服务器的 IP 地址。DHCP 把这些地址分配给实例用来进行域名解析。
主机路由 - 静态主机路由。首先以 CIDR 的格式指定目标网络，然后指定下一个处理路由的地址。例如：192.168.23.0/24, 10.1.31.1。如果您需要为实例静态分配路由信息，请设置这个选项。
3. 点创建。
新建的子网可以在网络的子网标签页中看到。您可以根据需要，通过点编辑来修改它的选项。现在，当您创建实例时，可以配置它来使用这个新创建的子网，并获得相应的 DHCP 选项。
3.7. 删除子网
当一个子网不再被使用时，您可以删除它。当您删除子网时，如果有实例还在使用它，删除操作会失败，dashboard 会显示一个错误信息。以下介绍了在一个网络中删除一个特定子网的步骤。
在 dashboard 中，选择项目 & 网络 & 网络，然后点您的网络名。选择目标子网后点删除子网。
3.8. 添加一个路由器
OpenStack Networking 使用一个基于 SDN 的虚拟路由器提供网络路由服务。当您的实例需要和外部子网（包括物理网络之外的网络）进行通讯时，需要使用路由器。路由器和子网使用接口进行连接，每个子网都需要有自己的到路由器的接口。一个路由器的默认网关定义了它所接收的数据要发送到的下一个地址。它的网络通常会被设置为使用一个虚拟网桥把数据路由到外部物理网络。
1.在 dashboard 中，选择项目 & 网络 & 路由，然后点 +创建路由。
2. 为新的路由设置一个名称，然后点创建路由。
3. 点路由列表中的新路由器旁的设置网关。
4. 在外部网络列表中，指定接收发送到外部地址的网络数据的网络。
5. 点设置网关。在添加了一个路由后，您需要配置已经创建的子网来使用这个路由器发送网络数据，您需要通过在子网和路由器间创建一个接口来实现它。
3.9. 删除一个路由
如果一个路由没有和其它接口相连，您可以删除这个路由。以下介绍了删除路由接口，然后再删除路由本身的方法。
1. 在 dashboard 中，选择项目 & 网络 & 路由，然后点您需要删除的路由名称。
2. 选择类型为 Internal Interface 的接口，点删除接口。
3. 在路由列表中选择目标路由，点删除路由。
3.10. 添加一个接口
使用接口可以把路由器和子网进行连接。路由器可以把实例所发出的数据发送到所在子网以外。以下过程会添加一个路由器接口并把它连接到一个子网。它使用"网络拓扑"功能来以图形化的形式显示所有的虚拟路由器，并可以通过这个功能执行网络管理的任务。
1. 在 dashboard 中，选项目 & 网络 & 网络拓扑。
2. 找到您需要管理的路由器，把鼠标光标移到它上面，然后点添加接口。
3. 指定要连接到这个路由器的子网。您可以指定一个 IP 地址，它可以用于测试和故障排除，如果可以 ping 到这个地址，则说明数据可以被正确路由。
4. 点添加接口。
网络拓扑图会自动更新来显示在路由器和子网间添加的新接口。
3.11. 删除一个接口
当您不再需要路由器来处理到一个子网的接口的数据时，可以把这个接口从子网中删除。以下介绍了删除接口的步骤：
1. 在 dashboard 中选择项目 & 网络 & 路由。
2. 点您需要删除的接口所在的路由。
3. 选择接口（类型应该是 Internal Interface），点删除接口。
3.12. 配置 IP 地址
您可以使用以下介绍的方法来在 OpenStack Networking 中管理 IP 地址的分配。
3.12.1. 创建浮动 IP 地址池
通过使用浮动 IP 地址，您可以把外部的网络流量发送到您的 OpenStack 实例中。首先，您需要定义一组可以被路由的外部 IP 地址，然后可以把它们动态地分配给实例。OpenStack Networking 会把流入的网络数据发送到相关实例的浮动 IP 地址上。
OpenStack Networking 会把浮动 IP 地址分配给在同一个 IP 范围/CIDR 中的所有项目（租户）。这意味着，浮动 IP 地址子网可以分配给任何项目或所有项目。您可以通过为特定项目设置配额来对这个进行管理。例如，您可以把 ProjectA 和 ProjectB 的默认配额设为 10，把 ProjectC 的配额设为 0。
浮动 IP 地址池在创建一个外部子网时被定义。如果这个子网只包括主机的浮动 IP 地址，您可以使用 enable_dhcp=False 选项禁用 DCHP 服务。
# neutron subnet-create --name SUBNET_NAME --enable_dhcp=False --allocation_pool start=IP_ADDRESS,end=IP_ADDRESS --gateway=IP_ADDRESS NETWORK_NAME CIDR
# neutron subnet-create --name public_subnet --enable_dhcp=False --allocation_pool start=192.168.100.20,end=192.168.100.100 --gateway=192.168.100.1 public 192.168.100.0/243.12.2. 分配一个特定的浮动 IP
您可以使用 nova 命令来为实例分配一个特定的浮动 IP 地址。或者通过 dashboard 进行（请参阅 3.1.2 "更新一个实例（操作菜单）"）
# nova floating-ip-associate INSTANCE_NAME IP_ADDRESS
在这个例子中，为名为 corp-vm-01 的实例分配了一个浮动 IP 地址：
# nova floating-ip-associate corp-vm-01 192.168.100.203.12.3. 分配一个随机的浮动 IP
浮动 IP 地址可以被动态地分配给实例。您不需要选择一个特定的 IP 地址，而只是要求 OpenStack Networking 从地址池中分配一个。从前面创建的池中分配一个浮动 IP 地址：
# neutron floatingip-create public
+---------------------+--------------------------------------+
+---------------------+--------------------------------------+
| fixed_ip_address
| floating_ip_address | 192.168.100.20
| floating_network_id | 7a03e6bc-234d-402b-9fb2-0af06c85a8a3 |
| 9d7e2603482d
| router_id
| tenant_id
| 9e67d44eab334f07bf82fa1b17d824b6
+---------------------+--------------------------------------+
当获得一个 IP 地址后，您可以把它分配给一个特定的实例。找到和您的实例相关的端口 ID（它和与实例相关联的固定 IP 地址相匹配）。这个端口 ID 会在以下步骤中使用来把实例的端口 ID 和浮动 IP 地址 ID 相关联。您还可以通过检查实例的第 3 栏中的 MAC 地址来确定正确的端口 ID。
# neutron port-list
+--------+------+-------------+--------------------------------------------------------+
| name | mac_address | fixed_ips
+--------+------+-------------+--------------------------------------------------------+
| ce8320 |
| 3e:37:09:4b | {"subnet_id": "361f27", "ip_address": "192.168.100.2"} |
| d88926 |
| 3e:1d:ea:31 | {"subnet_id": "361f27", "ip_address": "192.168.100.5"} |
| 8190ab |
| 3e:a3:3d:2f | {"subnet_id": "b74dbb", "ip_address": "10.10.1.25"}|
+--------+------+-------------+--------------------------------------------------------+
使用 neutron 命令把浮动 IP 地址和一个实例的相关端口进行关联：
# neutron floatingip-associate 9d7e90ab3.13. 创建多个浮动 IP 地址池
OpenStack Networking 支持每个 L3 agent 有一个浮动 IP 地址池。因此，如果您需要增加 L3 agent 的数量，您将可以创建额外的浮动 IP 地址池。
请确保在您的环境中，只有一个 L3 agent 的 handle_internal_only_routers 被配置为 True（在 /etc/neutron/neutron.conf 文件中）。这个选项会把 L3 agent 配置为只管理非外部的路由器。
3.14. 桥接物理网络
以下介绍了把您的虚拟网络桥接到物理网络，从而使虚拟实例可以进行网络连接的方法。其中，我们使用物理 eth0 接口作为一个例子，把它映射到 br-ex 网桥；虚拟网桥会作为物理网络和虚拟网络之间的一个中间介质。其结果是，所有通过 eth0 的网络流量都会使用配置的 Open vSwitch 来访问实例。使用以下方法把一个物理 NIC 映射到虚拟 Open vSwitch 网桥：
IPADDR、NETMASK GATEWAY 和 DNS1（名称解析服务器）必须被更新来与您的网络相匹配。
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
Configure the virtual bridge with the IP address details that were previously allocated to eth0:
# vi /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.120.10
NETMASK=255.255.255.0
GATEWAY=192.168.120.1
DNS1=192.168.120.1
ONBOOT=yes
现在，您可以为实例分配浮动 IP 地址，并使物理网络可以使用它们。
第 4 章 规划 IP 地址的使用
一个 OpenStack 环境可能会需要使用比想象中更多的 IP 地址。本节的内容可以帮助您更准确地预测所需的地址数量，并介绍了它们需要在哪里被使用。
VIP（也被称为 Virtual IP Addresses - 虚拟 IP 地址） - VIP 地址用来支持 HA 服务，它就是一个被多个控制器节点共享的 IP 地址。
4.1. 使用多个 VLAN
在计划您的 OpenStack 部署时，首先应该从一组子网开始，然后才能计划不同的地址需要被如何使用。当有了多个子网后，您就可以把不同系统间的网络数据进行分隔来组成 VLAN。例如，在一般情况下，管理网络流量和 API 网络流量不应该和处理 web 网络流量的系统共享相同的网络。另外，不同 VLAN 间的网络流量都需要通过一个路由器，这样就可以在路由器上设置防火墙来进一步控制网络流量的安全。
4.2. 隔离 VLAN 的网络数据
一般情况下，您需要为不同的网络类型分配不同的 VLAN。例如，您可以为每一个网络类型都分配一个它们自己的 VLAN。这样，只有 External 网络需要可以路由到外部的物理网络中。在 Red Hat OpenStack Platform 9 中，DHCP 服务由 director 提供。
每个 OpenStack 部署不一定都需要本节中提到的所有 VLAN。例如，您的云用户不需要动态创建特定的虚拟网络，则不需要租户网络；如果您只希望所有虚拟机都直接连接到其它物理系统连接到的交换机时，您可能只需要把您的 Compute 节点直接连接到一个供应商网络中，从而使您的实例直接使用供应商网络。
Provisioning 网络 - 这个 VLAN 被专门用于使用 director 通过 PXE 引导部署新节点。OpenStack Orchestration（heat）会在 overcloud 的裸机服务器上安装 OpenStack；它们被附加到物理网络上来从undercloud 系统中获得平台的安装镜像。
Internal API 网络 - Internal API 网络被用来处理 OpenStack 服务间的通讯，包括 API 通讯、RPC 消息数据以及数据库通讯。另外，这个网络还被用来处理控制器节点间的操作信息。在设计您的 IP 地址分配时，需要考虑到，每个 API 服务都需要自己的 IP 地址。以下的每个服务都需要一个 IP 地址：
vip-msg（ampq）
vip-keystone-int
vip-glance-int
vip-cinder-int
vip-nova-int
vip-neutron-int
vip-horizon-int
vip-heat-int
vip-ceilometer-int
vip-swift-int
vip-keystone-pub
vip-glance-pub
vip-cinder-pub
vip-nova-pub
vip-neutron-pub
vip-horizon-pub
vip-heat-pub
vip-ceilometer-pub
vip-swift-pub
在使用高可用性功能时，Pacemaker 需要可以在不同的物理节点间移动 VIP 地址。
Storage（存储）网络 - 块存储、NFS、iSCSI 和其它存储。因为性能的原因，在理想情况下这个网络应该位于一个完全独立的物理以太网连接环境中。
Storage Management（存储管理）网络 - OpenStack Object Storage（swift）使用这个网络来在相关的副本节点中同步数据项。代理服务（proxy service）在用户请求和底层的存储层间起到一个中间接口的作用。这个代理会接收用户的请求，并找到所需的副本来获得所需的数据。使用 Ceph 作为后端的服务会通过 Storage Management 网络进行连接，因为它们不会和 Ceph 直接进行交流，而是使用前端的服务。请注意，RBD 驱动是个例外，它会直接连接到 Ceph。
Tenant（租户）网络 - Neutron 为每个租户提供自己的网络。这可以通过使用 VLAN 隔离（VLAN segregation，每个租户网络都是一个网络 VLAN）实现，也可以使用 VXLAN 或 GRE 隧道（tunneling）实现。每个租户网络的网络数据会被相互隔离，并都有一个相关联的 IP 子网。多个租户子网可以使用相同的地址。
External（外部）网络 - 外部网络包括了公共 API 的端点以及到 Dashboard（horizon）的连接。您也可以使用它作为 SNAT，但这不是必须的。在一个生产环境的部署中，通常会使用一个独立的网络用于浮动 IP 地址和 NAT。
Provider（供应商）网络 - 实例可以使用这些网络附加到已存在的网络基础设施中。通过扁平化网络结构（flat networking）或 VLAN tag，您可以使用供应商网络直接映射到数据中心中的一个物理网络。这可以使一个实例共享相同的 2 层网络作为 OpenStack Networking 基础架构的一个外部系统。
4.3. IP 地址的消耗
以下系统会消耗 IP 地址分配范围内的 IP 地址：
Physical（物理）节点 - 每个物理 NIC 都需要一个 IP 地址；一般情况下，最好是每个物理 NIC 都只提供特定的功能。例如，管理网络有它自己专用的物理 NIC，NFS 网络也有自己专用的 NIC（有时，多个 NIC 连接到不同的交换机来提供冗余容错功能）。
用于高可用性的虚拟 IP（VIP） - 控制器节点间共享的每个网络都需要 1 到 3 个 IP。
4.4. 虚拟网络
这些虚拟资源会消耗 OpenStack Networking 中的 IP 地址。它们被认为是云基础架构的本地资源，并不需要被外部物理网络中的系统访问：
Tenant（租户）网络 - 每个租户网络都需要一个子网来为实例分配 IP 地址。
虚拟路由 - 每个插入到子网中的路由接口都需要一个 IP 地址。
实例 - 每个实例都需要从它所在的租户子网中获得一个 IP 地址。如果实例有入站网络流量，则还需要从相关的外部网络中分配一个浮动 IP 地址。
Management（管理）网络流量 - 包括 OpenStack 服务和 API 的网络流量。在 Red Hat OpenStack Platform 9 中，所需虚拟 IP 地址的数量已被减小，所有服务将共享一组少量的 VIP。API、RPC 和数据库服务还在一个内部的 API VIP 上进行通讯。
4.5. 网络计划示例
这个例子分配了一组网络来运行 7 个子网，每个子网需要一定数量的地址：
表 4.1. 子网计划示例子网名地址范围地址的数量子网掩码
Provisioning 网络
192.168.100.1 - 192.168.100.250
255.255.255.0
Internal API 网络
172.16.1.10 - 172.16.1.250
255.255.255.0
172.16.2.10 - 172.16.2.250
255.255.255.0
Storage Management
172.16.3.10 - 172.16.3.250
255.255.255.0
Tenant network (GRE/VXLAN)
172.19.4.10 - 172.16.4.250
255.255.255.0
External network（包括浮动 IP）
10.1.2.10 - 10.1.3.222
255.255.254.0
Provider 网络（基础架构）
10.10.3.10 - 10.10.3.250
255.255.252.0
第 5 章 检查 OpenStack Networking 路由端口
OpenStack Networking 中的虚拟路由器使用端口来进行子网间的连接。您可以通过检查这些端口的状态来确定它们是否被正常连接。
5.1. 查看当前端口状态
以下过程会列出附加到特定路由器上的端口列表，然后演示了如何获得端口状态（DOWN 或 ACTIVE）的方法。
1. 查看附加到名为 r1 的路由器上的所有端口：
neutron router-port-list r1
结果输出：
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| name | mac_address
| fixed_ips
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| b58d26f0-cc03-43c1-ab23-ccdb1018252a |
| fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd", "ip_address": "192.168.200.1"} |
| c45e998d-98a1-4b23-bb41-5d |
| fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"}
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
2. 使用端口的 ID（左面列中的值）运行以下命令来查看端口详情。命令运行结果包括端口的 status 值（在下面的例子中是 ACTIVE）：
# neutron port-show b58d26f0-cc03-43c1-ab23-ccdb1018252a
结果输出：
+-----------------------+--------------------------------------------------------------------------------------+
+-----------------------+--------------------------------------------------------------------------------------+
| admin_state_up
| allowed_address_pairs |
| binding:host_id
| node.example.com
| binding:profile
| binding:vif_details
| {"port_filter": true, "ovs_hybrid_plug": true}
| binding:vif_type
| binding:vnic_type
| device_id
| 49c6ebdc-0e62-49ad-a9ca-58cea464472f
| device_owner
| network:router_interface
| extra_dhcp_opts
| fixed_ips
| {"subnet_id": "a592fdba-babd-48e0-96e8-2dd", "ip_address": "192.168.200.1"} |
| b58d26f0-cc03-43c1-ab23-ccdb1018252a
| mac_address
| fa:16:3e:94:a7:df
| network_id
| 63c24160-47ac-f9a670b0ca4
| security_groups
| tenant_id
| d588dfb6cac22f9be45d49
+-----------------------+--------------------------------------------------------------------------------------+
使用不同端口的 ID 执行以上命令来获得它们的状态。
第 6 章 对供应商网络进行故障排除
在开始看来，使用虚拟路由器和交换机（也被称为软件定义的网络，简称 SDN）会使网络系统变得复杂。实际上，对 OpenStack Networking 中的连接进行故障排除的过程和对物理网络进行故障排除的方法非常相似。虚拟基础架构可以看做为物理网络的一个主干扩展，而不是一个完全独立的环境。
6.1. 故障排除的方法
基本的 ping 测试
对 VLAN 网络进行故障排除
从租户网络内进行故障排除
6.2. 基本的 ping 测试
ping 命令是一个非常有用的分析网络连接问题的工具。使用它可以获得基本的网络连接状态，但无法排除所有的连接问题，如防火墙阻止的特定应用程序的连接。ping 命令的工作流程是，向指定的地址发送数据，然后输出这个操作是否成功作为结果。
ping 命令需要 ICMP 网络数据可以通过所有相关的防火墙。
从有网络连接问题的系统上运行 ping 命令进行测试非常有必要。当一个系统看起来已完全没有网络连接时，需要可以通过 VNC 管理控制台连接到系统的命令行以便运行 ping 命令。
例如，下面的 ping 测试命令验证了网络可以正常工作所需的多个网络层的功能（域名解析功能、IP 路由功能和网络交换功能）：
$ ping www.redhat.com
PING e1890.b.akamaiedge.net (125.56.247.214) 56(84) bytes of data.
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=1 ttl=54 time=13.4 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=2 ttl=54 time=13.5 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=3 ttl=54 time=13.4 ms
在获得了所需的结果后，您可以使用 Ctrl-c 中断 ping 命令。如果命令输出中的数据包丢失（packet loss）值是 0，则说明网络连接处于正常状态：
--- e1890.b.akamaiedge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.461/13.498/13.541/0.100 ms
另外，根据测试的目标，从 ping 测试的结果中可以发现造成网络问题的原因。例如，在以下的图例中，VM1 有一些网络连接问题。其中以红色数字标识的位置是 ping 测试的目的地址：
1. internet - 一个常见的做法是首先 ping 一个 internet 地址，如 www.redhat.com。
Success：这意味着，所有中间的网络端点都可以正常工作，包括虚拟网络和物理网络系统。
Failure：多种原因都可以造成 ping 一个 internet 地址失败。如果网络中的其它系统可以成功 ping 到 internet，则说明 internet 本身的连接是正常的，您需要进一步对本地网络系统进行检查。
2. Physical（物理）路由器 - 被网络管理员设置为处理向外部地址发送数据的路由器。
Success：ping 默认网关可以显示本地网络以及所依赖的底层网络交换是否可以正常工作。因为它们中的数据包还没有到达路由器，所以无法说明默认网关是否有路由问题。
Failure：这说明 VM1 和默认网关之间的连接有问题。路由器/交换机可能出现问题，或您使用了一个错误的网关。您可以把有问题的系统的设置和其它可以正常工作的系统上的配置进行比较。尝试 ping 本地网络中的其它服务器。
3. Neutron 路由 - 这是一个 RHEL OpenStack 用来处理虚拟机网络数据的虚拟 SDN（软件定义的网络）.
Success：防火墙允许 ICMP 数据，Networking 节点在线。
Failure：确认实例的安全组是否允许 ICMP 数据。检查 Networking 节点是否在线，所有需要的服务是否都在运行。
4. 物理交换机 - 物理交换机被用来管理相同物理网络中的节点间的通讯。
Success：虚拟机发送到物理交换机的数据需要通过虚拟网络系统。如果 ping 命令成功，则意味着这一段的网络在正常工作。
Failure：物理交换机端口是否被配置为处理相关的 VLAN？
5. VM2 - 尝试 ping 同一个子网中的同一个 Compute 节点上的虚拟机。
Success：VM1 上的 NIC 驱动和基本的 IP 配置可以正常工作。
Failure：检查 VM1 上的网络配置。也可能是 VM2 上的防火墙配置阻塞了 ping 的数据。
6.3. 对 VLAN 网络进行故障排除
OpenStack Networking 可以通过 SDN 交换机进行 VLAN 网络的端口汇聚（trunk）。对 VLAN-tagged 供应商网络的支持意味着虚拟实例可以在物理网络中和服务器子网进行集成。
为了对一个 VLAN 供应商网络的连接性进行故障排除，尝试 ping 在创建网络时指定的网关 IP。例如，您使用以下命令创建了网络：
# neutron net-create provider --provider:network_type=vlan --provider:physical_network=phy-eno1 --provider:segmentation_id=120 --router:external=True
# neutron subnet-create "provider" --allocation-pool start=192.168.120.1,end=192.168.120.253 --disable-dhcp --gateway 192.168.120.254 192.168.120.0/24
您可以尝试 ping 其中的网关 IP - 192.168.120.254
如果失败，请确认您是否正确配置了与 VLAN 相关的网络设置（在创建网络时定义）。在上面的例子中，OpenStack Networking 被定义为把 VLAN 120 端口汇聚（trunk）到供应商网络。这个选项通过 --provider:segmentation_id=120 参数设置。
检查网桥接口（在这里，它的名称是 br-ex） 上的 VLAN 网络流设置：
# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=, idle_age=0, priority=1 actions=NORMAL
cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop6.3.1. 查看 VLAN 配置和日志文件
OpenStack Networking（neutron）agent - 使用 neutron 命令验证所有 agent 都在运行，并以正确的名称注册：
# neutron agent-list
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| agent_type
| alive | admin_state_up |
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| a0-437d-b3730c0c | Metadata agent
| rhelosp.example.com
| a1-4fc8-b0ad-be0c97734e6a | L3 agent
| rhelosp.example.com
| b54f0be7-c555-43da-ad19-ddf0 | DHCP agent
| rhelosp.example.com
| d2be3cb0--b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com
+--------------------------------------+--------------------+-----------------------+-------+----------------+
检查 /var/log/neutron/openvswitch-agent.log - 这个日志应该显示，创建的过程使用 ovs-ofctl 命令来配置 VLAN 端口汇聚功能（VLAN trunking）。
检查 /etc/neutron/l3_agent.ini 文件中的 external_network_bridge 设置。如果它是一个“硬代码”值，则无法通过 L3-agent 使用供应商网络，也无法创建所需的网络流程。
检查 /etc/neutron/plugin.ini 文件中 network_vlan_ranges 的值。如果它是一个供应商网络，则不需要指定 VLAN ID。只有在您使用 VLAN 隔离租户网络时才需要指定 ID。
6.4. 从租户网络内进行故障排除
在 OpenStack Networking 中，所有网络流量都会被限制在网络命名空间内。这样，租户就可以在不相互影响的情况下进行网络配置。例如，网络命名空间允许不同租户都使用192.168.1.1/24 作为子网范围，而不会相互影响。
为了对租户网络进行故障排除，首先需要决定网络包括在哪个命名空间中：
1. 使用 neutron 命令列出所有租户网络：
# neutron net-list
+--------------------------------------+-------------+-------------------------------------------------------+
+--------------------------------------+-------------+-------------------------------------------------------+
| 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-ee01680bba 192.168.212.0/24 |
| a0cc8cdd-575f--5df8c6d0dd81 | private
| c1ef-44a7-bf94-d3 10.0.0.0/24
| baadd774-87e9-4e97-a055-326bb422b29b | private
| 340c58e1-7fe7-4cf2-96a7-96a0a4ff.200.0/24 |
| 24ba3a36--be47-f6af2a7d8af2 | public
| 35f3d2cb-6e4b-2a395c4bb3 172.24.4.224/28
+--------------------------------------+-------------+-------------------------------------------------------+
在这个例子中，我们将检查 web-servers 网络。记录下 web-server 行中的 id 值（这里是 9cb32fe0-d7fb-432c-b116-f483c6497b08）。在下一步的输出中，可以看到这个值被附加到一个网络命名空间名的后面。
2. 使用 ip 命令列出所有网络命名空间：
# ip netns list
qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08
qrouter-b3e-4906-bd69-cb39ed5faa01
qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
qdhcp-a0cc8cdd-575f--5df8c6d0dd81
qrouter-ea6--9
在结果中，一个命名空间与 web-server 网络 id 匹配。它由 qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 代表。
3. 在命名空间中运行命令来检查 web-servers 网络的配置。您需要在故障排除命令前加上 ip netns exec (namespace)。例如：
a) 查看 web-servers 网络的路由表：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n
Kernel IP routing table
Destination
Flags Metric Ref
172.24.4.225
0 qg-8d128f89-87
172.24.4.224
255.255.255.240 U
0 qg-8d128f89-87
192.168.200.0
255.255.255.0
0 qr-8efd6357-96
b) 查看 web-servers 网络的路由表：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n
Kernel IP routing table
Destination
Flags Metric Ref
172.24.4.225
0 qg-8d128f89-87
172.24.4.224
255.255.255.240 U
0 qg-8d128f89-87
192.168.200.0
255.255.255.0
0 qr-8efd6357-966.4.1. 在命名空间内执行高级的 ICMP 测试
1. 使用 tcpdump 命令获取 ICMP 网络流量。
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp
在执行下一步前，可能没有输出：
2. 在一个独立的命令行窗口中运行一个到外部网络的 ping 测试命令：
# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
ping www.redhat.com
3. 在运行 tcpdump 的终端中检查 ping 测试的结果详情。
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
172.24.4.228 & 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
172.24.4.228.40278 & 192.168.200.21: [bad udp cksum 0xfa7b -& 0xe235!] UDP, length 32
在对网络数据进行 tcpdump 分析时，您可能会发现返回的数据包会发送到路由器接口，而不是实例。这是一个正常的行为，因为 qrouter 会在返回的数据包上执行 DNAT。
第 7 章 把一个实例连接到物理网络
本章介绍了如何使用供应商网络把实例直接连接到一个外部网络。
OpenStack Networking 拓扑概述：
OpenStack Networking（neutron）有两类服务分布在多个节点类型中。
Neutron API 服务器 - 这个服务运行 OpenStack Networking API 服务器，它为最终用户提供了 API，以及和 OpenStack Networking 进行通讯的服务。这个服务器还集成了底层的数据库来存储和获取租户网络、路由器、负载均衡设备以及其它信息。
Neutron agent（代理） - 为 OpenStack Networking 执行网络功能的服务：
neutron-dhcp-agent - 为租户私人网络管理 DHCP IP 地址。
neutron-l3-agent - 在租户私人网络、外部网络和其它系统间执行第 3 层路由。
neutron-lbaas-agent - 配置由租户创建的 LBaaS 路由器。
Compute（计算）节点 - 这个节点包括了运行虚拟机的虚拟机监控程序（hypervisor）。Compute 节点需要通过网线直接连接到网络以便为实例提供外部的网络连接。
服务的位置：
OpenStack Networking 服务可以在同一个物理服务器上运行，也可以分别在专用的服务器上运行（服务器的名称与它们所运行的服务相匹配）：
控制器节点（Controller node） - 运行 API 服务的服务器。
网络节点（Network node） - 运行 OpenStack Networking agent 的服务器。
计算节点（Compute node） - 运行实例的虚拟机监控程序服务器。
本章中介绍的步骤假设您的环境中已经部署了这 3 个节点类型。如果您的 Controller 节点和 Network 节点都运行在相同的物理节点上，针对于这两类节点的步骤都需要在这个服务器上执行。这同样适用于高可用性（HA）环境，在 HA 环境中，所有 3 个节点都可能运行 Controller 节点和 Network 节点以实现高可用性。因此，适用于 Contorller 节点和适用于 Network 节点的步骤都需要在这 3 个节点上运行。
7.1. 使用扁平化供应商网络
以下步骤创建可以把实例直接连接到外部网络的扁平化（flat）供应商网络。当您有多个物理网络（如 physnet1、physnet2）和独立的物理接口（eth0 -& physnet1 和 eth1 -& physnet2），并需要把每个 Compute 节点和 Network 节点连接到这些外部网络时，可以进行这个操作。
如果您需要把同一个 NIC 中的多个 VLAN-tagged 接口连接到多个供应商网络，请参阅 VLAN 供应商网络。
配置控制器节点：
1. 编辑 /etc/neutron/plugin.ini（它是到 /etc/neutron/plugins/ml2/ml2_conf.ini 文件的 symbolic link），把 flat 添加到已存在的值列表中，把 flat_networks 设置为 *：
type_drivers = vxlan,flat
flat_networks =*
2. 创建一个扁平化外部网络，并把它与配置的 physical_network 相关联。如果把它创建为一个共享网络，则允许其它用户把他们的实例直接连接到这个网络：
neutron net-create public01 --provider:network_type flat --provider:physical_network physnet1 --router:external=True --shared
3. 使用 neutron subnet-create 或 OpenStack Dashboard 在这个外部网络中创建一个子网。
4. 重启 neutron-server 服务以使所做的改变生效：
# systemctl restart neutron-server.service配置网络节点和计算节点：
这些步骤需要在 Network 节点和 Compute 节点上进行。这些节点将会被连接到外部网络，并允许实例与外部网络直接进行通讯。
1. 创建 Open vSwitch 网桥和端口。这一步将创建一个外部网桥（br-ex）并添加相应的端口（eth1）：
i. 编辑 /etc/sysconfig/network-scripts/ifcfg-eth1：
DEVICE=eth1
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
ii. 编辑 /etc/sysconfig/network-scripts/ifcfg-br-ex：
DEVICE=br-ex
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
2. 重启 network 服务以使所做改变生效：
# systemctl restart network.service
3. 在 /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini 中配置物理网络，把网桥映射到物理网络：
如需了解更多与配置 bridge_mappings 相关的信息，请参阅本指南中的配置网桥映射一章。
bridge_mappings = physnet1:br-ex
4. 在 Network 节点和 Compute 节点上重启 neutron-openvswitch-agent 服务以使所做改变生效：
systemctl restart neutron-openvswitch-agent配置 Network 节点：
1. 把 /etc/neutron/l3-agent.ini 文件中的 external_network_bridge = 设为空值。这将会使用外部供应商网络。
# Name of bridge used for external network traffic. This should be set to
# empty value for the linux bridge
external_network_bridge =
2. 重启 neutron-l3-agent 以使所做改变生效：
systemctl restart neutron-l3-agent.service
如果有多个 flat 供应商网络，每个网络都需要有独立的物理网络和网桥来与外部网络连接。请正确配置 ifcfg-* 脚本，当在 bridge_mappings 中指定网络时，使用由逗号分隔的网络列表。如需了解更多与配置 bridge_mappings 相关的信息，请参阅本指南中的配置网桥映射一章。
把一个实例连接到外部网络：
在网络创建后，可以把它与一个实例进行相连来测试它是否可以正常工作：
1. 创建一个新实例。
2. 从 dashboard 的网络标签页中把新实例直接添加到新创建的外部网络中。
数据包传输是如何工作的？
本节介绍了在扁平化供应商网络被配置后，数据是如何传输到一个实例，以及数据如何从一个实例发送。
7.1.1. 出站网络数据的传输
数据包会离开实例并直接到达一个外部网络：一旦配置了 br-ex，添加物理接口，并把实例分配到一个 Compute 节点上。通过这一步所获得的接口和网桥将会和下图所示类似：
1. 从实例的 eth0 接口发送的数据包会首先到达 linux 网桥 qbr-xx。
2. 网桥 qbr-xx 通过 qvb-xx &-& qvo-xxx 连接到 br-int。
3. 接口 qvb-xx 被连接到 qbr-xx linux 网桥，qvo-xx 被连接到 br-int Open vSwitch (OVS) 网桥。
在 Linux 网桥上配置 qbr-xx：
qbr269d4d73-e7
qvb269d4d73-e7
tap269d4d73-e7
在 br-int 上配置 qvo-xx：
Bridge br-int
fail_mode: secure
Interface "qvof63599ba-8f"
Port "qvo269d4d73-e7"
Interface "qvo269d4d73-e7"
端口 qvo-xx 以与扁平化供应商网络相关联的内部 VLAN tag 进行标记（tag）。在这个例子中，VLAN tag 是 5。一旦数据包到达了 qvo-xx，VLAN tag 会被添加到数据包头中。
然后，数据包会根据 int-br-ex &-& phy-br-ex 被移到 br-ex OVS 网桥。
在 br-int 上配置 patch-peer 的一个示例：
Bridge br-int
fail_mode: secure
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
在 br-ex 上配置 patch-peer 的一个示例：
Bridge br-ex
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Port br-ex
Interface br-ex
type: internal
当数据包到达 br-ex 中的 phy-br-ex 后，br-ex 内的 OVS 数据流会删除 VLAN tag（5），并转发到物理接口上。
在以下例子中，输出显示了 phy-br-ex 的端口号是 2。
# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:c90dc6
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
2(phy-br-ex): addr:ba:b5:7b:ae:5c:a2
speed: 0 Mbps now, 0 Mbps max
以下输出显示了，所有到达 phy-br-ex（in_port=2） 的数据包都带有一个 VLAN tag 5（dl_vlan=5）。然后，VLAN tag 被删除，数据包被转发到（actions=strip_vlan,NORMAL）。
# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=s, table=0, n_packets=3620, n_bytes=333744, idle_age=0, priority=1 actions=NORMAL
cookie=0x0, duration=s, table=0, n_packets=13, n_bytes=1714, idle_age=3764, priority=4,in_port=2,dl_vlan=5 actions=strip_vlan,NORMAL
cookie=0x0, duration=s, table=0, n_packets=10650, n_bytes=447632, idle_age=0, priority=2,in_port=2 actions=drop
然后，这个数据包被转发到物理接口。如果这个物理接口是一个不同的 vlan tagged 接口，接口会把它的 vlan tag 添加到数据包中。
7.1.2. 入站网络数据的传输
本节介绍了从外部网络发出的入站数据到达实例接口的流程。
1. 入站网络数据首先到达物理节点的 eth1。
2. 数据包被发送到 br-ex 网桥。
3. 数据包根据 phy-br-ex &--& int-br-ex 被移到 br-int。
在下面的例子中，int-br-ex 使用端口 15。请参阅包括 15(int-br-ex) 的项：
ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:f644d
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
15(int-br-ex): addr:12:4e:44:a9:50:f4
speed: 0 Mbps now, 0 Mbps max观察 br-int 上的网络流量
1. 当数据包到达 int-br-ex 后，br-int 网桥中的一个 OVS 流规则会把内部 VLAN tag 5 添加到数据包中。请参阅 actions=mod_vlan_vid:5 的项：
# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=s, table=0, n_packets=12118, n_bytes=510456, idle_age=0, priority=1 actions=NORMAL
cookie=0x0, duration=s, table=0, n_packets=3489, n_bytes=321696, idle_age=0, priority=3,in_port=15,vlan_tci=0x0000 actions=mod_vlan_vid:5,NORMAL
cookie=0x0, duration=s, table=0, n_packets=628, n_bytes=57892, idle_age=4538, priority=2,in_port=15 actions=drop
cookie=0x0, duration=s, table=23, n_packets=0, n_bytes=0, idle_age=5351, priority=0 actions=drop
2. 第 2 个规则管理到达 int-br-ex (in_port=15) 上的不带有 VLAN tag (vlan_tci=0x0000) 的数据包：它把 VLAN tag 5 添加到数据包上（actions=mod_vlan_vid:5,NORMAL），然后把它转发到 qvo-xxx。
3. qvo-xxx 接受数据包并在删除 VLAN tag 后把它转发到 qvb-xx。
4. 数据包然后会到达实例。
VLAN tag 5 是一个带有扁平化供应商网络的测试 Compute 节点的例子，neutron-openvswitch-agent 会自动分配这个值。它可能会和您自己的扁平化供应商网络的值不同，在两个独立 Compute 节点上的同一个网络的值也可能不同。
7.1.3. 故障排除
如果一个扁平化的供应商网络出现了问题，可以从上一节中所显示的输出中获取信息进行故障排除。以下介绍的步骤会进一步帮助您进行故障排除。
1. 检查 bridge_mappings：
确认使用的物理网络名（例如 physnet1）和 bridge_mapping 配置的内容相匹配。例如：
# grep bridge_mapping /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
bridge_mappings = physnet1:br-ex
# neutron net-show provider-flat
| provider:physical_network | physnet1
2. 检查网络配置：
确认网络被创建为 external，类型是 flat：
# neutron net-show provider-flat
| provider:network_type
| router:external
3. 检查 patch-peer：
运行 ovs-vsctl show，确认 br-int 和 br-ex 通过使用 patch-peer int-br-ex &--& phy-br-ex 进行连接。
这个连接在 neutron-openvswitch-agent 服务重启时被创建，并需要 bridge_mapping 在 /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini 中被正确配置。如果没有被创建，请再次检查 bridge_mapping 的设置（即使已重启了服务）。
如需了解更多与配置 bridge_mappings 相关的信息，请参阅本指南中的配置网桥映射一章。
4. 检查网络数据流：
运行 ovs-ofctl dump-flows br-ex 和 ovs-ofctl dump-flows br-int，检查内部 VLAND ID 是否已从向外的数据包中删除，以及 VLAN ID 是否已被添加到向内的数据包中。当在特定 Compute 节点的这个网络上分配实例时，这个数据流会被创建。
如果在分配实例后没有创建这个数据流，请检查网络是否被创建为 flat，是否是 external，以及 physical_network 名是否正确。另外，请检查 bridge_mapping 的设置。
最后，检查 ifcfg-br-ex 和 ifcfg-ethx 的配置。确认 ethX 已作为 br-ex 内的端口被添加，它们在 ip a 中的输出中都带有 UP 标识。
例如，以下输出显示 eth1 是 br-ex 中的一个端口：
Bridge br-ex
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Port "eth1"
Interface "eth1"
以下例子显示，eth1 被配置为一个 OVS 端口，内核知道从接口上传输所有数据包，并把它们发送到 OVS 网桥 br-ex。这些可以在 master ovs-system 项中找到。
5: eth1: &BROADCAST,MULTICAST,UP,LOWER_UP& mtu 1500 qdisc mq master ovs-system state UP qlen 10007.2. 使用 VLAN 供应商网络
这个过程会创建一个可以把实例直接连接到外部网络的 VLAN 供应商网络。如果您需要把一个独立 NIC 上的多个 VLAN-tagged 接口连接到多个供应商网络，则要执行这些操作。这个例子使用一个名为 physnet1 的网络，它具有一组 VLAN（171-172）。网络节点和计算节点使用名为 eth1 的物理接口连接到物理网络。连接这些接口的交换机网络被配置为对所需的 VLAN 进行端口汇聚（trunk）。 以下过程使用上面提供的 VLAN ID 和名称对 VLAN 供应商网络进行配置。
配置控制器节点：
1. 编辑 /etc/neutron/plugin.ini （到 /etc/neutron/plugins/ml2/ml2_conf.ini 文件的符合链接）文件来启用 vlan 机制驱动，把 vlan 添加到存在的值列表中。如：
type_drivers = vxlan,flat,vlan
2. 配置 network_vlan_ranges 的设置来反映使用的物理网络和 VLAN。例如：
[ml2_type_vlan]
network_vlan_ranges=physnet1:171:172
3. 重启 neutron-server 服务以使所做的修改生效：
systemctl restart neutron-server
4. 创建外部网络作为 vlan 类型，并把它们与配置的 physical_network 相关联。把它创建为一个 --shared 网络来允许其它用户直接连接到实例。这个例子会创建两个网络：一个为 VLAN 171，另一个为 VLAN 172：
neutron net-create provider-vlan171 \
--provider:network_type vlan \
--router:external true \
--provider:physical_network physnet1 \
--provider:segmentation_id 171 --shared
neutron net-create provider-vlan172 \
--provider:network_type vlan \
--router:external true \
--provider:physical_network physnet1 \
--provider:segmentation_id 172 --shared
5. 使用 neutron subnet-create 或 dashboard 创建一组子网，并把它们配置为使用外部网络。您需要确保从网络管理员处获得的外部