Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)

问题导读：

1.怎样使用arp_responder ？

2.怎样搭建l2pop环境？

3. ARP Responder

    arp_responder 的原理不复杂。Neutorn DB 中保存了所有的端口的 MAC 和 IP 地址数据。而 ARP 就是一个虚机要根据另一个虚机的 IP 地址查询它的 MAC。因此，只需要 Neutron server 通过 RPC 告诉每个计算节点上的 ML2 agent 所有活动端口的 MAC 和 IP，那么就可以将 br-tun 变成一个供本机适用的 ARP Proxy，这样本机上的虚机的 ARP 请求的响应就可以由 br-tun 在本地解决。Assaf Meller 有篇文章来阐述 ARP Responder。

  使用 ARP Responder 需要满足两个条件：

（1）设置 arp_responder = true 来使用 OVS 的ARP 处理能力 。这需要 OVS 2.1 （运行 ovs-vswitchd --version 来查看 OVS 版本） 和 ML2 l2population 驱动的支持。当使用隧道方式的时候，OVS 可以处理一个 ARP 请求而不是使用广播机制。如果 OVS 版本不够的话，Neutorn 是无法设置 arp responder entry 的，你会在 openvswitch agent 日志中看到 “Stderr: '2015-07-11T04:57:32Z|00001|meta_flow|WARN|destination field arp_op is not writable\novs-ofctl: -:2: actions are invalid with specified match (OFPBAC_BAD_SET_ARGUMENT)\n'”这样的错误，你也就不会在 ”ovs-ofctl dump-flows br-tun“ 命令的输出中看到相应的 ARP Responder 条目了。

（2）设置 l2_population = true。同时添加 mechanism_drivers = openvswitch,l2population。OVS 需要 Neutron 作为 SDN Controller 向其输入 ARP Table flows。

3.1 升级 OVS

杀掉 neutron openvswitch， ovs-* 各种进程

#编译安装

去 http://openvswitch.org/download/ 下载最新版本的代码，解压，进入解压后的目录

安装依赖包，比如 gcc，make

[mw_shl_code=bash,true]uname -r
./configure --with-linux=/lib/modules/3.13.0-51-generic/build
make && make install[/mw_shl_code]

#查看安装的版本

[mw_shl_code=bash,true]root@compute2:/home/s1# ovs-vsctl --version
ovs-vsctl (Open vSwitch) 2.3.2
Compiled Jul 12 2015 09:09:42
DB Schema 7.6.2[/mw_shl_code]

#处理 db

[mw_shl_code=bash,true]rm /etc/openvswitch/conf.db （老的db要删除掉，否则会报错）
ovsdb-tool create /etc/openvswitch/conf.db vswitchd/vswitch.ovsschema[/mw_shl_code]

#启动 ovs

[mw_shl_code=bash,true]cp /usr/local/bin/ovs-* /usr/bin
ovsdb-server /etc/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/usr/local/var/run/openvswitch/db.sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --no-chdir --log-file=/var/log/openvswitch/ovsdb-server.log --pidfile=/var/run/openvswitch/ovsdb-server.pid --detach --monitor
ovs-vswitchd unix:/usr/local/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir --log-file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/openvswitch/ovs-vswitchd.pid --detach --monitor[/mw_shl_code]

#启动 neutron openvswitch agent，确保log 文件中 ovs-vsctl 和 ovs-ofctl 调用没有错误

#修改 /usr/share/openvswitch/scripts/ovs-lib 文件，保证机器重启后 OVS 正常运行

将 rundir=${OVS_RUNDIR-'/var/run/openvswitch'} 改为 rundir=${OVS_RUNDIR-'/usr/local/var/run/openvswitch'}

3.2 ARP Responder

有了 arp_responder 以后，br-tun 的流表增加了几项和处理：

（1）table 2 中增加一条 flow，是的从本地虚机来的 ARP 广播帧转到table 21

# ARP broadcast-ed request go to the local ARP_RESPONDER table to be locally resolved

table=2, n_packets=0, n_bytes=0, idle_age=3, priority=1,arp,dl_dst=ff:ff:ff:ff:ff:ff actions=resubmit(,21)

（2）在 table 21 中增加一条 flow 将其发发往 table 22

# If none of the ARP entries correspond to the requested IP, the broadcast-ed packet is resubmitted to the flooding table

table=21, n_packets=0, n_bytes=0, idle_age=4, priority=0 actions=resubmit(,22)

如果下面第 （3）步增加的 flow rule 都处理不了这条 request，那么转到table 22 去 flood 到所有端口。

（3）由 L2 population 发来的 entry 来更新 table 21。

  table 21 是在新的 l2pop 地址进来的时候更新的。比如说，compute C 上增加了新的虚机 VM3，然后计算节点 A 和 B 收到一条 l2pop 消息说 VM3 （IP 是***，MAC 是 ***） 在 Host C 上，在 network "Z“ 中。然后，Compute A 和 B 会在 table 21 中增加相应的 flows。   

  br.add_flow(table=21, priority=1, proto='arp', dl_vlan=local_vid, nw_dst= ip, actions=actions)

    其中action为： （好晦涩，这是谁定义的奇葩语法。。幸好 这里 有详细解释）

[mw_shl_code=python,true]ARP_RESPONDER_ACTIONS = ('move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],'
                         'mod_dl_src:%(mac)s,'
                         'load:0x2->NXM_OF_ARP_OP[],'
                         'move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],'
                         'move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],'
                         'load:%(mac)#x->NXM_NX_ARP_SHA[],'
                         'load:%(ip)#x->NXM_OF_ARP_SPA[],'
                         'in_port')[/mw_shl_code]

（4）table 21 的处理过程

     table 21 中的每一条 flow，会和进来的帧的数据做匹配（ARP 协议，network，虚机的 IP）。如果匹配成功，则构造一个 ARP 响应包，其中包括了 IP 和 MAC，从原来的 port 发回到虚机。如果没有吻合的，那么转发到 table 22 做泛洪。

增加的 flow tables 在红色部分：

   因此，通过使用 l2-pop mechanism driver 和 OVS 2.1, Neutorn 可以在本地回答虚机的 ARP 请求，从而避免了昂贵的 ARP 广播。这个功能给 GRE 和  VXLAN 的实现是在 Juno 版本中完成的。 这个blueprint似乎在支持VLAN 中的这个功能，但是看起来没有完成。

4. L2 population

根据这篇文档，l2pop 目前支持 VXLAN with Linux bridge 和 GRE/VXLAN with OVS，其 blueprint 在这里。

4.1 原理

    l2pop 的原理也不复杂。Neutron 中保存每一个端口的状态，而端口保存了网络相关的数据。虚机启动过程中，其端口状态会从 down 到build 到 active。因此，在每次端口发生状态变化时，函数 update_port_postcommit  都将会被调用：

[mw_shl_code=javascript,true]{'status': 'DOWN/BUILD/ACTIVE', 'binding:host_id': u'compute1', 'allowed_address_pairs': [], 'extra_dhcp_opts': [], 'device_owner': u'compute:nova', 'binding:profile': {}, 'fixed_ips': [{'subnet_id': u'4ec65731-35a5-4637-a59b-a9f2932099f1', 'ip_address': u'81.1.180.15'}], 'id': u'1167e9ac-e10f-4cf5-bd09-6649eab38b32', 'security_groups': [u'f5377a66-803d-481b-b4c3-a6631e8ab456'], 'device_id': u'30580ea7-c456-416b-a01e-0fe645edf5dc', 'name': u'', 'admin_state_up': True, 'network_id': u'86c0d29b-4880-4739-bd68-eb3c392f5099', 'tenant_id': u'74c8ada23a3449f888d9e19b76d13aab', 'binding:vif_details': {u'port_filter': True, u'ovs_hybrid_plug': True}, 'binding:vnic_type': u'normal', 'binding:vif_type': u'ovs', 'mac_address': u'fa:16:3e:4f:59:9d'} [/mw_shl_code]

在某些状态变化下：

• update_port_postcommit (down to active) -> _update_port_up -> add_fdb_entries -> fdb_add -> fdb_add_tun -> setup_tunnel_port  （如果 tunnel port 不存在，则创建 tunnel port）, add_fdb_flow -> add FLOOD_TO_TUN flow （如果是 Flood port，则将端口添加到 Flood output ports）; setup_entry_for_arp_reply('add'。如果不是 Flood port，那么 添加 ARP Responder entry （MAC -> IP）) 以及 add UCAST_TO_TUN flow Unicast Flow entry （MAC -> Tunnel port number）。
  

• update_port_postcommit (active to down) -> _update_port_down -> remove_fdb_entries
  

• delete_port_postcommit (active to down) -> _update_port_down -> remove_fdb_entries -> fdb_remove -> fdb_remove_tun -> cleanup_tunnel_port, del_fdb_flow -> mod/del FLOOD_TO_TUN flow; setup_entry_for_arp_reply ('remove'), delete UCAST_TO_TUN flow
  

• update_port_postcommit (fixed ip changed) -> _fixed_ips_changed -> update_fdb_entries
  

    通过这种机制，每个节点上的如下数据得到了实时更新，从而避免了不必要的隧道连接和广播。

• Tunnel port
• FLOOD_TO_TUN （table 22）flow
• ARP responder flow
• UCAST_TO_TUN （table 20） flow
  

有和没有 l2pop 的效果：

4.2 过程实验

1. def tunnel_sync(self) 函数除了上报自己的 local_ip 外不再自己见 tunnels，一切等 l2pop 的通知。

2. 在 compute1 上添加第一个虚机 81.1.180.8

neutron-server：

• 通知 compute1： {'segment_id': 6L, 'ports': {u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:87:40:f3', u'81.1.180.1']]}, 'network_type': u'gre'}}
• 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']]}, 'network_type': u'gre'}}
  

compute1：

• 添加和网络节点的tunnel options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"}
• 添加到网段网关的 Unicast flow：table=20, n_packets=0, n_bytes=0, idle_age=130, priority=2,dl_vlan=2,dl_dst=fa:16:3e:87:40:f3 actions=strip_vlan,set_tunnel:0x6,output:4
• 增加网段 81.1.180.1 网关的 ARP flows：table=21, n_packets=0, n_bytes=0, idle_age=130, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:87:40:f3,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e8740f3->NXM_NX_ARP_SHA[],load:0x5101b401->NXM_OF_ARP_SPA[],IN_PORT
• 修改 Flood flow
  

compute 2 节点：因为它上面还没有运行虚机，所以不做操作。

3. 在 compute 2 上添加一个虚机 81.1.180.9

neutron server：

• 通知 compute 2 ： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']], u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:87:40:f3', u'81.1.180.1']]}, 'network_type': u'gre'}}
• 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.39': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:73:49:41', u'81.1.180.9']]}, 'network_type': u'gre'}
  

compute1：

• 建立 tunnel（ID 5）：  {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"}
• 增加 arp responder flow（compute2 上新的虚机 IP -> MAC）：table=21, n_packets=0, n_bytes=0, idle_age=79, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.9 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:73:49:41,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e734941->NXM_NX_ARP_SHA[],load:0x5101b409->NXM_OF_ARP_SPA[],IN_PORT
• 增加 unicast flow （新虚机的 MAC -> Tunnel port）：table=20, n_packets=0, n_bytes=0, idle_age=79, priority=2,dl_vlan=2,dl_dst=fa:16:3e:73:49:41 actions=strip_vlan,set_tunnel:0x6,output:5
• 添加新的 Tunnel port 到 Flood flow：table=22, n_packets=13, n_bytes=1717, idle_age=255, hard_age=78, dl_vlan=2 actions=strip_vlan,set_tunnel:0x6,output:5,output:4
  

compute2：

• 建立和计算节点以及compute1的tunnel：options: {df_default="true", in_key=flow, local_ip="10.0.1.39", out_key=flow, remote_ip="10.0.1.21"}，options: {df_default="true", in_key=flow, local_ip="10.0.1.39", out_key=flow, remote_ip="10.0.1.31"}
• 增加 ARP flow（compute 1 上的虚机的 MAC -> IP）：table=21, n_packets=0, n_bytes=0, idle_age=268, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.8 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:b3:e7:7a,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163eb3e77a->NXM_NX_ARP_SHA[],load:0x5101b408->NXM_OF_ARP_SPA[],IN_PORT
• 增加 Unicast flow （compute 1 上的虚机 MAC -> Tunnel port）：table=20, n_packets=0, n_bytes=0, idle_age=268, priority=2,dl_vlan=2,dl_dst=fa:16:3e:b3:e7:7a actions=strip_vlan,set_tunnel:0x6,output:4
• 增加 ARP flow（新虚机的网关的 MAC -> IP） table=21, n_packets=0, n_bytes=0, idle_age=268, priority=1,arp,dl_vlan=2,arp_tpa=81.1.180.1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:fa:16:3e:87:40:f3,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e8740f3->NXM_NX_ARP_SHA[],load:0x5101b401->NXM_OF_ARP_SPA[],IN_PORT
• 修改 Flood flow（添加到 Compute 1 的 port）：table=22, n_packets=13, n_bytes=1717, idle_age=128, dl_vlan=2 actions=strip_vlan,set_tunnel:0x6,output:5,output:4
  

3. 删除 compute1 上的一个vm（也是唯一的一个）

neutron server：

• 通知所有 agent： {'segment_id': 6L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:b3:e7:7a', u'81.1.180.8']]}, 'network_type': u'gre'}
  

compute 1：

• 因为没有别的虚机了，删除所有 tunnel ports
• 修改或者删除 ARP, Unicast 和 Flood flows
  

compute 2：

• 删除了 compute1 的 tunnel
• 删除该虚机对应的 ARP flow
  

4. 在 compute1 上创建第一个不同网络的虚机

neutron server：

• 通知 compute 1： {u'e2022937-ec2a-467a-8cf1-f642a3f777b6': {'segment_id': 4L, 'ports': {u'10.0.1.21': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:90:e5:50', u'91.1.180.1'], [u'fa:16:3e:17:c9:26', u'90.1.180.1'], [u'fa:16:3e:69:92:30', u'90.1.180.3'], [u'fa:16:3e:69:92:30', u'91.1.180.2']]}, 'network_type': u'gre'}}
• 通知所有 agent：{u'e2022937-ec2a-467a-8cf1-f642a3f777b6': {'segment_id': 4L, 'ports': {u'10.0.1.31': [['00:00:00:00:00:00', '0.0.0.0'], [u'fa:16:3e:e9:ee:0c', u'91.1.180.9']]}, 'network_type': u'gre'}}
  

compute 1：建立和网络节点的 tunnel port；更新 Flood flows；添加 ARP flows

compute 2：没什么action，因为该节点上没有新建虚机的网络内的虚机

过程的大概说明：

• 虚机在收到 fannout FDB entries 后，检查其中每个 port 的 network_id（即 “segment_id”）。如果本机上有该 network 内的 port，那么就处理 entries 中的 “ports”部分；否则，不处理该 entries。
• 因此，当计算节点上没有运行任何虚机时，不会建立任何 tunnel。如果两个虚机上有相同网络内的虚机，那么建立会建立 tunnel。
• 这种机制能实时建立 tunnel port，Flood entry （创建 Tunnel port 同时添加到 Flood output ports 列表）， Unicast flow （虚机和网关 MAC -> Tunnel port） 和 ARP Responder entry  （虚机和网关 MAC -> IP）。下图中的蓝色部分的流表都会被及时更新。
• Neutron server 在端口创建/删除/修改时，如果是该节点上的第一个虚机，首先发送直接消息；然后发通知消息给所有的计算和网络节点。
  

4.3 性能

4.3.1 MQ 性能问题

    应该说 l2pop 的原理和实现都很直接，但是在大规模部署环境中，这种通知机制（通知所有的 ML2 Agent 节点）可能会给 MQ 造成很大的负担。一旦 MQ 不能及时处理消息，虚机之间的网络将受到影响。下面是 l2pop 中通知机制代码：

[mw_shl_code=python,true]def __init__(self, topic=topics.AGENT):
        super(L2populationAgentNotifyAPI, self).__init__(
            topic=topic, default_version=self.BASE_RPC_API_VERSION)
        self.topic_l2pop_update = topics.get_topic_name(topic, topics.L2POPULATION, topics.UPDATE)

    def _notification_fanout(self, context, method, fdb_entries):
        self.fanout_cast(context, self.make_msg(method, fdb_entries=fdb_entries), topic=self.topic_l2pop_update)

    def _notification_host(self, context, method, fdb_entries, host):
        self.cast(context, self.make_msg(method, fdb_entries=fdb_entries), topic='%s.%s' % (self.topic_l2pop_update, host))

    def add_fdb_entries(self, context, fdb_entries, host=None):
        if fdb_entries:
            if host:
                self._notification_host(context, 'add_fdb_entries',fdb_entries, host) #cast 给指定 host
            else:
                self._notification_fanout(context, 'add_fdb_entries', fdb_entries) #fanout 给所有计算和网络节点[/mw_shl_code]

这段代码是说，l2pop 采用的 MQ topic 是 “L2POPULATION”，消息通知采用 fanout 或者 cast 机制。如果是 fanout 的话，消息将发到所有的 ML2 agent 节点。这样的话，其覆盖面就有些过于广泛了，就这个问题有人提了一个 ticket，官方答复是 work as design，要改的话只能是添加 new feature 了。

4.3.2 大规模网络环境中节点上的 OpenFlow flows 过多

    不知道这个数目有没有上限？数目很多的情况下会不会有性能问题？OVS 有没有处理能力上限？这些问题也许得在实际的生产环境中才能得到证实和答案。

相关内容：


neutron系列：Neutron 所实现的虚拟化网络(1)

neutron系列：Neutron 所实现的虚拟化网络(2)

neutron系列：使用 Open vSwitch + VLAN 组网(3)

neutron系列：使用 Open vSwitch + VLAN 组网(4)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网 (5)

Neutron系列 : 使用Open vSwitch + GRE/VxLAN 组网(6)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(7)

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(9)

Neutron系列 : Neutron 是如何向 Nova 虚机分配固定IP地址的(10)

Neutron 系列 (11): Neutron 是如何实现负载均衡器虚拟化的【基础篇】

Neutron 系列 (12): Neutron 是如何实现负载均衡器虚拟化的【提高篇】

Neutron 系列 (13): Neutron 是如何实现虚机防火墙的 【上】

Neutron 系列 (14): Neutron 是如何实现虚机防火墙的 【下】

Neutron 系列 (15): OpenStack 是如何实现 Neutron 网络 和 Nova虚机 防火墙的

Neutron 系列（16）：虚拟专用网（VPN）虚拟化

Neutron 系列 (17): Neutron 分布式虚拟路由【上】

Neutron 系列 (18): Neutron 分布式虚拟路由【下】

Neutron系列（19）：Neutron L3 Agent HA 之 虚拟路由冗余协议（VRRP）【上】

Neutron系列（20）：Neutron L3 Agent HA 之 虚拟路由冗余协议（VRRP）【下】

Neutron系列（21）：OpenStack 高可用和灾备方案 [OpenStack HA and DR]【上】

Neutron系列（22）：OpenStack 高可用和灾备方案 [OpenStack HA and DR]【下】