7 云计算系列之Neutron安装与配置

preface

紧接上一章，我们这里开始部署网络服务Neutron，可参考官网文档：http://docs.openstack.org/newton/install-guide-rdo/neutron.html.

涉及到挺多网络概念，如有本人理解错误的地方，还望指出，多谢。

安装neutron网络服务

先说说Openstack Neutron下的几个概念

1. 网络：在Neutron的世界里，网络将多个不同的云主机连接起来。
2. 子网： 在实际的物理环境下，在一个物理网络中，我们可以将网络划分为多个逻辑子网。在Neutron世界里，子网也隶属于网络下的。
3. 端口： 在Neutron的世界里端口也隶属于子网下，云主机的网卡会对应到一个端口上。
4. 路由器： 连接不同的网络或者子网。

neutron的组成

• neutron-server:
  
  Neutron-server 可以理解一个专门用来接受Neutron Rest api调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。

• neutron-plugin
  
  Neutron-plugin可以理解为不同的网络功能实现不同的入口，各个厂商可以开发自己的plugin，Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。

• neutron-agent
  
  Neutron-agent可以直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操作和参数，并转换为具体的设备级操作，以指导设备的动作。当设备本地发生问题时，neutron-agent会将情况通知给neutron-plugin。

• Neutron database
  
  顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。

• Network provider
  
  即为实际执行功能的网络设备，一般为虚拟交换机（OVS或者Linux Bridge）。比如linux-bridge： linux网桥，其实就是插件。

plugin的两类模块-为core-plugin和service-plugin：

neutron-plugin分为core-plugin和service-plugin两类。

• Core-plugin：
  
  Core-plugin，Neutron中即为ML2（Modular Layer 2），负责管理L2的网络连接。ML2中主要包括network、subnet、port三类核心资源，对三类资源进行操作的REST API被neutron-server看作Core API，由Neutron原生支持，其中：

名称	解释
Network	代表一个隔离的二层网段，是为创建它的租户保留的一个广播域。subnet和port始终分配给某个特定的network。network的类型包括flat,vlan,vxlan,gre等。
Subnet	代表一个IPV4/V6的CIDR地址池，以及相关配置，如网关，DNS等，该subnet中的VM实例会自动继承该配置。Subnet必须关联一个network
Port	代表虚拟交换机上的一个虚拟交换端口，VM的网卡VIF连接port后，就会拥有MAC地址和IP地址。Port的IP地址就是从subnet地址池中分配的。

• Service-plugin
  
  即为除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要实现L3-L7的网络服务。
  
  这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。
  
  “Neutron对Quantum的插件机制进行了优化，将各个厂商L2插件中独立的数据库实现提取出来，作为公共的ML2插件存储租户的业务需求，使得厂商可以专注于L2设备驱动的实现，而ML2作为总控可以协调多厂商L2设备共同运行”。
  
  在Quantum中，厂家都是开发各自的Service-plugin，不能兼容而且开发重复度很高，于是在Neutron中就为设计了ML2机制，使得各厂家的L2插件完全变成了可插拔的，方便了L2中network资源扩展与使用。

ML2作为L2的总控，其实现包括Type和Mechanism两部分，每部分又分为Manager和Driver。Type指的是L2网络的类型（如Flat、VLAN、VxLAN等），与厂家实现无关。Mechanism则是各个厂家自己设备机制的实现，如下图所示。当然有ML2，对应的就可以有ML3，不过在Neutron中L3的实现只负责路由的功能，传统路由器中的其他功能（如Firewalls、LB、VPN）都被独立出来实现了，因此暂时还没有看到对ML3的实际需求。

一般而言，neutron-server和各neutron-plugin部署在控制节点或者网络节点上，而neutron agent则部署在网络节点上和计算节点上。

Neutron支持层OSI模型，如下所示：

ML2（module Layer2）plug：

DHCP-Agent： dhcp分配功能

L3-Agent：网络路由功能

聊聊Openstack-vlan模式

我们先说下vlan模式下的chunk链路与Access链路，如下图所示：

• Access链路只允许一个vlan通过。
• Chunk链路允许多个vlan通过。

上图的流程是：

PC1它处在vlan10下，当他需要与其他vlan10下的PC机通信时，它发起的包会通过交换机1封装，打上vlan10的标签，然后在vlan10下广播，喊道“某某主机，PC1找你”，如果本交换机内部没有找到，那么就通过chunk链路发送到对面的交换机2上，由于chunk链路支持多个vlan通行，所以vlan10到对面的交换机上没有问题的。交换机2也进行vlan的广播，找到pc1要找的主机。这就是在access和Chunk链路下简单通信流程.

知道上面的知识以后，我们知道为了实现多个vlan在同一个链路传播，那么必须使用chunk链路，所以Openstack服务器与交换机之间配置成chunk链路。

同时我们称为这个为大二层网络。什么是大二层网络,大二层网络就是一个交换机连接了一个交换机，另一个交换机又连了一个交换机等等，这里的大二层网络就是Openstack宿主机的虚拟交换机与物理网络的真实交换机形成的大二层网络的。

Openstack内部网络流程图

• tap设备是在宿主机上的，虚拟机想要到外网，那么必须通过tap设备进行转发。

• linux网桥是提供安全组，安全组就是基于iptables实现的。所以linux网桥通过iptables规则来控制网络的进出。

• 划分vlan的动作是在br-int上操作的。每个vlan过来的数据包都会拆包后打上一个vlan标签后再封装转发出去。只能划分4096个vlan。

• br-ex是关联物理网卡，做vlan转换。把从虚拟机过来的vlan1的数据包，和物理交换机存在的vlan相互转发，从而能够在物理网络中通信的。反之，从物理网络过来的vlan包如果要到虚拟机上，那么br-eth也需要转换下，从物理网络的vlan1转换到虚拟机之间的vlan1。

• 由于这种模式涉及到vlan的转换，所以需要和物理网络的vlan绑定。适合小规模部署，几百台服务器部署正好。不适合大规模部署。

• 不需要网络节点（Openstack-neutron-agent节点）。从云主机出来的数据包到物理交换机是这样的一个流程：经过tap->linux网桥->veth对->Openswitch br-in -> Openswitch br-ex -> 物理交换机。其中如果云主机是vlan10的话，那么在经过Openswitch br-in 的会打上vlan10的标签，然后通过Openswitch br-ex 再次转换，由内部的vlan标签转换成物理网络可识别的vlan标签，此时在物理交换机如果设置了vlan10的默认网关，那么数据包就会直接被物理交换机转发到网关上了。

云主机跨物理机通信过程(同一个vlan)

如图所示：



如果两个云主机在同一个物理机上且同一个vlan下的，那么他们之间数据包到br-int上就会进行vlan下的广播，所以vm1与vm2上互ping比较快。

下面看看跨物理机的云主机通信（在同一个vlan下面）。

1. vm1和vm6假设处在vlan1下面。vm1虚拟机发起一个请求到vm6上，vm1发起的包首先经过tap设备转发，然后到linux网桥，再到br-int上进行广播，广播无人回应，同时打上vlan1的标签后转发到br-ex上，br-ex上进行转换，把vlan1的虚拟网络vlan标签转换成物理网络对应的vlan标签后发到物理交换机上。
2. 物理交换机上进行广播，广播包通过thunk链路到了右边的物理机上。
3. 首先还是经过br-ex，把物理网络的vlan标签进行转换成虚拟网络的标签vlan1后发送到br-int上，br-int上对属于vlan1的端口进行广播。每个属于vlan1端口的云主机都收到了来自br-int的广播，但是拆包发现目标IP不属于自己的，都不响应，只有vm6发现目标IP是自己的才响应。
   
   上诉过程就是云主机跨物理网络通信的流程。

云主机跨vlan通信过程

如图所示：

跨vlan的通信，必然涉及到路由设备。那么就说说云主机跨vlan通信的过程。

vm1是属于vlan1，vm2属于vlan2上，vm1想要去和vm2通信，那么就要先判断是不是在同一个网段内了。判断两个IP地址是不是在同一个网段，就将它们的IP地址分别与子网掩码做与运算，得到的结果一网络号，如果网络号相同，就在同一子网，否则，不在同一子网。

1.当vm1计算后，发现vm2与自己不在同一个网段内，那么就把数据包发往自己的网关。流程为vm1-eth0 --> tap设备 --> linux网桥 --> veth对 --> br-int打上vlan标签 --> br-ex vlan标签转换 --> 物理交换机转发 --> Openstack 网络节点（图右边那个）

2.openstack网络节点收到包以后，br-ex转换，br-int进行转发到vlan1对应的虚拟路由器上，虚拟路由器由L3-agent虚拟出来的。虚拟路由器再把来自vm1的数据包转发到vlan2网段内，然后原路返回到图左中的Openstack计算节点。

3.计算节点收包后还是br-ex vlan转换，br-int去vlan标签后在vlan2中广播目标IP为XXXX的。vm2收到广播包后发现目标IP就是自己，那么进行响应。响应包原路返回。

即使在同一个计算节点上不同vlan的云主机，他们通信也得经过Openstack网络节点(neutron-agent)来实现跨vlan通信。

通过Openstack网络节点与外网通信

Openstack网络节点还是由Openswitch br-int,Openswith br-ex来做vlan的标签转发与打标签。

右边的网络节点在openswitch上面是由L3-Agent虚拟出来的路由器实现三层转发。由这个虚拟路由器转发到物理交换机上，从而实现与外网的通信。

那总的说下虚拟机与外网通信的过程通过Openstack网络节点：

云主机发起一个到外网的请求，首先包通过tap设备映射转发出去，然后到linux网桥，再到veth对上，到了openswitch br-int上，打上vlan的标签，再转发到openswitch br-ex上，把虚拟vlan标签转换成物理网络可识别的vlan标签。通过交换机到Openstack网络节点上，网络节点的openswitch br-ex进行转换，由物理网络的vlan标签转换到虚拟网络的标签，往openswitch br-int上，openswitch br-int对应一个路由设备（L3-agent提供），通过这个路由设备发往外网。

云主机刚开始创建的时候，所分配的IP也是有DHCP-agent来分配的

说完了vlan模式，那我们总结下：

1. vlan模式有上限的，最多支持4096个vlan，还包括系统保留的Vlan，我记得思科交换机就默认占用vlan1。
2. MAC表爆满。Openstack节点可以虚拟出很多台云主机，如果每个云主机都有2个MAC地址（对应2个网卡），那如果有5000个Openstack节点的时候，那么交换机的mac地址表那么得多大啊，甚至是溢出的表。
3. 广播风暴，vlan模式能够很好的隔离大规模的广播风暴。
4. 基于IP地址的子网划分限制网络规模。

GRE网络模式

说完vlan，我们说说gre网络模式。

gre网络模式类似于vlan通过VPN一样，通过gre-id来识别不同的网络。我们先看看gre包的封装(假设192.168.1.1 ping 192.168.2.1)：



看其包封装类型，其实很想ISCSI一样，SCSI协议在外面封装了一层IP协议，所以SCSI能够在IP网络通信了。gre也是一样的原理。

下面看看gre通信过程：



我们就说说这个流程吧：

1. 首先一台云主机192.168.1.2去和192.168.1.3通信的话，由于不在同一节点上且跨了网段，那么就需要把包发给网关转发到公网。
2. 转发到公网的之前，出口路由器会在这个报文的IP头（此时源地址为云主机192.168.1.2，目的IP是192.168.1.3）在封装一层gre，在gre协议之上再次封装一层源地址是左边公网IP，目标地址右边公网IP的IP层。随后转发出去。
3. 右边出口路由器收到后，发现IP地址是自己的，就拆包，然后发现是gre协议，那么就在对应的广播域内广播，寻找192.168.1.3的主机。

gre跨网段的封装报文如下：

gre 在云主机之间的通信过程：

流程图如下：

1. 左边的br-tun是把来自云主机的网络包打上一层gre-tunnel-id（把vlan-id转为gre-tunnel-id），然后再此之上，再封装一层IP协议，这个源ip就是Openstack物理节点上的，目标IP就是另一个云主机的宿主机的IP。
2. 封装完IP报文后再封装其他的相关的网络报文就转发到交换机上，此时交换机到Openstack物理机上不走多个vlan了，所以可以使用access链路模式了。交换机接收到报文后可以直接转发到对应的目标IP上。目标IP的Openstack节点收到包后，发现目标IP是自己的，便解开报文，露出gre-tunnel-id的报文，然后把gre-tunnel-id转为对应的vlan-id后在对应的vlan进行广播。
3. 目标云主机收到广播后，便进行响应，回包流程也是一样的。

那么总结下gre的网络模式特点：

好处：

1. gre是物理上的三层通信，虚拟机上的二层通信
2. gre-id是2的24次方，因为是由24字节组成的。所以可以使用的id远远大于vlan
3. 交换机只需要记录Openstack物理机的MAC地址就行。
4. 解决了子网划分的规模问题。无需考虑子网划分

坏处：

1. 两两之间计算节点建立隧道。如果节点过多，那么建立的隧道量也特别多！

vxlan网络模式

相比于GRE的通用性，VXLAN主要用于封装、转发2层报文。VXLAN全称Virtual eXtensible Local Area Network，简单的说就是扩充了的VLAN，其使得多个通过三层连接的网络可以表现的和直接通过一台一台物理交换机连接配置而成的网络一样处在一个LAN中。其将二层报文加上个vxlan header，封装在一个UDP包中进行传输。vxlan header会包括一个24位的ID（称为VNI），含义类似于VLAN id或者上面提到的GRE的tunnel id。在上面GRE的例子中，是通过路由器来进行GRE协议的封装和解封的，在VXLAN中这类封装和解封的组件有个专有的名字叫做VTEP。相比起VLAN来说，好处在于其突破了VLAN只有4094子网的限制，同时架设在UDP协议上后其扩展性提高了不少（因为UDP是高层协议，屏蔽了底层的差异，换句话说屏蔽了二层的差异）。

封装报文如下：

参考上面的图文，可以得出总结：

1. vxlan也是物理上的三层通信，虚拟上的二层通信。
2. 封装报文可以简单理解为: 原始数据2层包+(1 vni-id ,2组播地址 )+udp报文+ip报文。

可以参考这篇博文：http://www.opencloudblog.com/?p=300

关于gre和vxlan二次封装数据包的MTU问题

VXLAN 模式下虚拟机中的 mtu 最大值为1450，也就是只能小于1450，大于这个值会导致 openvswitch 传输分片，进而导致虚拟机中数据包数据重传，从而导致网络性能下降。GRE 模式下虚拟机 mtu 最大为1462。

计算方法如下：

1. vxlan mtu = 1450 = 1500 – 20(ip头) – 8(udp头) – 8(vxlan头) – 14(以太网头)
2. gre mtu = 1462 = 1500 – 20(ip头) – 4(gre头) – 14(以太网头)

可以配置 Neutron DHCP 组件，让虚拟机自动配置 mtu，

#/etc/neutron/dhcp_agent.ini
[DEFAULT]
dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf#/etc/neutron/dnsmasq-neutron.conf
dhcp-option-force=26,1450或1462

重启 DHCP Agent，让虚拟机重新获取 IP，然后使用 ifconfig 查看是否正确配置 mtu。

gre和vxlan的对比：

若br-tun之间两两点对点的连接，通信封包为GRE格式，那么这样的网络环境就是OVS-GRE网络模式。同理，若br-tun之间跑三层网络协议，封包方式为VXLAN格式，这样的网络环境就是OpenStack-Neutron-OVS-VXLAN网络模式。对于GRE和VXLAN网络模式而言，可以抽象地将每个br-tun看成隧道端点，有状态的隧道点对点连接即为GRE；无状态的隧道使用UDP协议连接则为VXLAN。

可以参考其他博文：http://www.sdnlab.com/11819.html

基础工作要做好：

确保neutron用户已经创建了，在linux-node1节点上查看：

[root@linux-node1 ~]# openstack user list   #linux-node1节点上
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 00f8c9ca79f542d7b4a8e0582f2351b7 | glance  |
| 1077bb04680840a688b62e10b0d58a7e | neutron |     # neutron创建成功
| 1b24326bb39249bb9bec94f6fa63a12f | cinder  |
| 54f2e8a7f28b42178692ae39f7ed9b37 | admin   |
| 6895ff530fd24df08e289810fbce482b | demo    |
| 8e4927503d1340a6aa3ca23bd91b08bf | nova    |
+----------------------------------+---------+

这里选择的是提供者网络(Linuxbridge代理)模式，那么在linux-node1节点上操作。

[root@linux-node1 ~]# yum install openstack-neutron openstack-neutron-ml2 \
>   openstack-neutron-linuxbridge ebtables

另一台机器计算节点也安装Neutron网络服务

[root@linux-node2 ~]# yum install openstack-neutron-linuxbridge ebtables ipset

配置控制节点：

1.首先更改数据库配置

[root@linux-node1 ~]# vim /etc/neutron/neutron.conf
[database]
connection = mysql+pymysql://neutron:neutron@192.168.56.11/neutron

2.添加keystone认证：

[DEFAULT]
auth_strategy = keystone
[keystone_authtoken]
auth_uri = http://192.168.56.11:5000
auth_url = http://192.168.56.11:35357
memcached_servers = 192.168.56.11:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = neutron
password = neutron

3.更改核心插件：

[DEFAULT]
# The core plugin Neutron will use (string value)
core_plugin = ml2
# The service plugins Neutron will use (list value)
service_plugins =

4.添加rabbitmq

[DEFAULT]
transport_url = rabbit://openstack:openstack@192.168.56.11   # 第530行

5.配置网络服务来通知计算节点的网络拓扑变化：

[DEFAULT]
notify_nova_on_port_status_changes = true
notify_nova_on_port_data_changes = true

[nova]
auth_url = http://192.168.56.11:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = nova
password = nova

6.配置锁路径

[oslo_concurrency]
lock_path = /var/lib/neutron/tmp    # 在1135行左右

7.配置 Modular Layer 2 (ML2) 插件,ML2插件使用Linuxbridge机制来为实例创建layer－2虚拟网络基础设施.

[root@linux-node1 neutron]# vim /etc/neutron/plugins/ml2/ml2_conf.ini

[ml2]
type_drivers = flat,vlan       #启用flat和VLAN网络，flat单一扁平网络，指虚拟机和宿主机同一网络。：
tenant_network_types =           #禁用私有网络：
mechanism_drivers = linuxbridge    #启用Linuxbridge机制：
extension_drivers = port_security  # 启用端口安全扩展驱动：

[ml2_type_flat]
flat_networks = public     # 配置公共虚拟网络为flat网络：

[securitygroup]
enable_ipset = True    # 启用 ipset 增加安全组的方便性：

8.配置Linuxbridge代理,Linuxbridge代理为实例建立layer－2虚拟网络并且处理安全组规则。

[root@linux-node1 neutron]# vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge]
physical_interface_mappings = public:eth0      #将公共虚拟网络和公共物理网络接口对应起来：

[vxlan]
enable_vxlan = False     # 禁止VXLAN覆盖网络

[securitygroup]
enable_security_group = True      # 启用安全组并配置 Linux 桥接 iptables 防火墙驱动：
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

9.配置DHCP代理,这个DHCP代理提供了为虚拟网络提供了DHCP服务

[root@linux-node1 neutron]# vim /etc/neutron/dhcp_agent.ini

[DEFAULT]    # 配置Linuxbridge驱动接口，DHCP驱动并启用隔离元数据，这样在公共网络上的实例就可以通过网络来访问元数据
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True

10.配置元数据主机以及共享密码（neutron和nova交互的密码），还是还是/etc/neutron/metadata_agent.ini：：

[DEFAULT]
nova_metadata_ip = 192.168.56.11   # 设置源数据服务器IP
metadata_proxy_shared_secret = oldboy   # 设置IP

11.配置计算服务（nova服务）来使用网络服务

[root@linux-node1 openrc]# vim /etc/nova/nova.conf
[neutron]
url = http://192.168.56.11:9696      # 9696是neutron的端口
auth_url = http://192.168.56.11:35357
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = neutron
password = neutron
service_metadata_proxy = True
metadata_proxy_shared_secret = oldboy    # 要和上面元数据的共享密钥一样

12.做软链接,网络服务初始化脚本需要一个超链接/etc/neutron/plugin.ini 指向ML2插件配置文件/etc/neutron/plugins/ml2/ml2_conf.ini。如果超链接不存在，使用下面的命令创建它：

[root@linux-node1 ~]# ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

13.同步数据库：

[root@linux-node1 ~]# 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

''''''
  OK   # 最后一行显示OK就说明同步成功了

14.重启计算API 服务(only it)

[root@linux-node1 ~]# systemctl restart openstack-nova-api.service

15.设置开机启动和启动服务

# 设置开机启动
[root@linux-node1 ~]# systemctl enable neutron-server.service \
>   neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
>   neutron-metadata-agent.service

# 启动服务
[root@linux-node1 ~]# systemctl start neutron-server.service \
>   neutron-linuxbridge-agent.service neutron-dhcp-agent.service \
>   neutron-metadata-agent.service

16.创建neutron服务实体：

[root@linux-node1 ~]# source admin_openrc       # 一定要先source下它
[root@linux-node1 ~]#  openstack service create --name neutron \
>   --description "OpenStack Networking" network
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | OpenStack Networking             |
| enabled     | True                             |
| id          | f0fb0c7015794d829e3f6d06a1dc8332 |
| name        | neutron                          |
| type        | network                          |
+-------------+----------------------------------+

17.创建网络服务API端点：

[root@linux-node1 ~]# openstack endpoint create --region RegionOne network public http://192.168.56.11:9696

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 8c9da83c56504bd799b2b6436e460fe1 |
| interface    | public                           |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f0fb0c7015794d829e3f6d06a1dc8332 |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://192.168.56.11:9696        |
+--------------+----------------------------------+
[root@linux-node1 ~]# openstack endpoint create --region RegionOne network internal http://192.168.56.11:9696
+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | ad84ba8453764b6cb17183a83079ffbc |
| interface    | internal                         |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f0fb0c7015794d829e3f6d06a1dc8332 |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://192.168.56.11:9696        |
+--------------+----------------------------------+
[root@linux-node1 ~]# openstack endpoint create --region RegionOne network admin http://192.168.56.11:9696
+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| enabled      | True                             |
| id           | 0182dfcc97db4ff9a9bc0eec461026a3 |
| interface    | admin                            |
| region       | RegionOne                        |
| region_id    | RegionOne                        |
| service_id   | f0fb0c7015794d829e3f6d06a1dc8332 |
| service_name | neutron                          |
| service_type | network                          |
| url          | http://192.168.56.11:9696        |
+--------------+----------------------------------+

[root@linux-node1 neutron]# openstack endpoint list |grep network     # 执行这个命令查看下,出现下面三行说明添加成功哇
| 0182dfcc97db4ff9a9bc0eec461026a3 | RegionOne | neutron      | network      | True    | admin     | http://192.168.56.11:9696                    |
| 8c9da83c56504bd799b2b6436e460fe1 | RegionOne | neutron      | network      | True    | public    | http://192.168.56.11:9696                    |
| ad84ba8453764b6cb17183a83079ffbc | RegionOne | neutron      | network      | True    | internal  | http://192.168.56.11:9696                    |

18.验证控制节点neutron是否正常运行

[root@linux-node1 neutron]# neutron agent-list
+---------------------------+--------------------+-------------------------+-------------------+-------+----------------+---------------------------+
| id                        | agent_type         | host                    | availability_zone | alive | admin_state_up | binary                    |
+---------------------------+--------------------+-------------------------+-------------------+-------+----------------+---------------------------+
| 362514ce-28a8-4847-98f5-c | Metadata agent     | linux-node1.example.com |                   | :-)   | True           | neutron-metadata-agent    |
| ea08fac88df               |                    |                         |                   |       |                |                           |
| a2c0dcd0-33a4-40b9-a8ea-  | DHCP agent         | linux-node1.example.com | nova              | :-)   | True           | neutron-dhcp-agent        |
| efb09fcb952d              |                    |                         |                   |       |                |                           |
| a98b616a-aae8-4c48-939d-  | Linux bridge agent | linux-node1.example.com |                   | :-)   | True           | neutron-linuxbridge-agent |
| 60506edfe2f7              |                    |                         |                   |       |                |                           |
+---------------------------+--------------------+-------------------------+-------------------+-------+----------------+---------------------------+

上面alive列出现三个