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

[Bash shell] 纯文本查看 复制代码

?


1

2

3

uname -r

./configure --with-linux=/lib/modules/3.13.0-51-generic/build

make && make install

#查看安装的版本

[Bash shell] 纯文本查看 复制代码

?


1

2

3

4

[email protected]:/home/s1# ovs-vsctl --version

ovs-vsctl (Open vSwitch) 2.3.2

Compiled Jul 12 2015 09:09:42

DB Schema 7.6.2

#处理 db

[Bash shell] 纯文本查看 复制代码

?


1

2

rm /etc/openvswitch/conf.db （老的db要删除掉，否则会报错）

ovsdb-tool create /etc/openvswitch/conf.db vswitchd/vswitch.ovsschema

#启动 ovs

[Bash shell] 纯文本查看 复制代码

?


1

2

3

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

#启动 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为： （好晦涩，这是谁定义的奇葩语法。。幸好 这里 有详细解释）

[Python] 纯文本查看 复制代码

?


1

2

3

4

5

6

7

8

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‘)

（4）table 21 的处理过程

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

增加的 flow tables 在红色部分：

<ignore_js_op>

因此，通过使用 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  都将会被调用：

[JavaScript] 纯文本查看 复制代码

{‘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‘}

在某些状态变化下：

  • 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 的效果：

<ignore_js_op>

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 在端口创建/删除/修改时，如果是该节点上的第一个虚机，首先发送直接消息；然后发通知消息给所有的计算和网络节点。

<ignore_js_op>

4.3 性能

4.3.1 MQ 性能问题

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

[Python] 纯文本查看 复制代码

?


01

02

03

04

05

06

07

08

09

10

11

12

13

14

15

16

17

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 给所有计算和网络节点

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

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

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

http://www.aboutyun.com/forum.php?mod=viewthread&tid=16564&highlight=neutron%2B%2B%CF%B5%C1%D0

原文地址：https://www.cnblogs.com/liuhongru/p/11121142.html

时间： 2024-10-09 05:47:50

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)的相关文章

Neutron 理解 (4): Neutron OVS OpenFlow 流表 和 L2 Population [Netruon OVS OpenFlow tables + L2 Population]

学习 Neutron 系列文章: (1)Neutron 所实现的虚拟化网络 (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络 (4)Neutron OVS OpenFlow 流表 和 L2 Population (5)Neutron DHCP Agent (5)TBD OVS bridge 有两种模式:“normal” 和 “flow”.“normal” 模式的 bridge 同普通的 Linux

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

http://www.aboutyun.com/forum.php?mod=viewthread&tid=16563&highlight=neutron%2B%2B%CF%B5%C1%D0 问题导读: 1.OVS bridge有几种模式?2.Neutron 中的流表是怎样实现的? OVS bridge 有两种模式:“normal” 和 “flow”.“normal” 模式的 bridge 同普通的 Linux 桥,而 “flow” 模式的 bridge 是根据其流表(flow tables

openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)

一.写在前面 唉,被分配到sdn安全方向,顶不住,顶不住,感觉搞不出来什么有搞头的东西.可若是让我水水的应付,我想我也是做不到的,世上无难事只怕有心人.好了,进入正题,本次要讨论的时一个比较细节的东西,在流表项中的有关ip掩码的问题.对了,本文适合于,有一定基础的openflow使用者,一点点就行. 二.问题描述 若不是机缘巧合,我甚至完全不会注意到这个问题,为什么,咱来看一个平时实验环境中最为常见的流表项长啥样,如图1                                      

软件定义网络基础---OpenFlow流表

一:流表 (一)流的概念 我们把同一时间经过同一网络中,具有某种共同特征或属性的数据,抽象为一个流 比如:我们将访问同一个地址的数据视为一个流 流一般是由网络管理员定义的,可以根据不同的流执行不同的策略,在OpenFlow中,数据都是作为流进行处理的.所以流表就是针对特定流的策略表项的集合,负责数据包的查找和转发 一张流表包含了一系列的流表项flow entries (二)流表项组成 (包头域.计数器.动作表3个) (三)包头域 (四)计数器 (五)动作表 动作表用于指示交换机,在收到匹配的数据

Openflow流表应用测试--逻辑隔离

1.搭建拓扑 搭建了三层的二叉树结构网络,开启SimpleSwitch3.py无法完成pingall联通测试,于是将拓扑结构更改为简单的line,四个交换机(OF13)连成一线,每个交换机下挂两个主机,依次h1--h8 s1 = net.addSwitch('s1', cls=OVSKernelSwitch, protocols='OpenFlow13', mac='00:00:00:00:00:11')    s2 = net.addSwitch('s2', cls=OVSKernelSwit

OpenvSwitch 流表转换

推荐看一下这篇文章,讲述了各个流表,我们这里着重讲流程和代码,对流表不再细说. 我们主要的关注点还是OVS-DPDK的流表转换,其实和OVS的转换差不多,只不过OVS的Datapath流表位于kernel,报文在Datapath找不到流表即通过netlink上传到Userspace,而OVS-DPDK则是Datapath流表依然位于Userspace,可以看做是一个缓存.查找不到的话直接继续调用其他接口查找Userspace的流表. controller会根据网络情况给ovs下发流表,或者命令o

Open vSwitch流表应用实战

写在前面 本随笔参考 学会了如何下发流表及删除流表的操作. 第一个不用脚本的实验. 实验原理 在SDN环境下,当交换机收到一个数据包并且交换机中没有与该数据包匹配的流表项时,交换机将此数据包发送给控制器,由控制器决策数据包如何处理. 控制器下发决策后,交换机根据控制器下发的信息来进行数据包的处理,即转发或者丢弃该数据包.我们可以通过对流表操作来控制交换机的转发行为. 实验任务 Mininet创建一个默认树形拓扑. 选择Mininet的控制器指定为ODL,进行基本的添加.删除流表操作,使网络实现网

OVS中arp响应的流表的实现

总结: 1.br-int 流表总体是按照Normal 的方式,即常规的交换机的转发方式进行转发.而br-tun 交换机则主要按照流表的方式进行转发. 2.一般情况下,VM发出的ARP请求,会在该VM的所有邻居进行广播发送和查找,大量浪费带宽.当neutron开启了l2 pop后(二次注入功能), 计算节点会学习别的主机发送的免费ARP, 从而在本地存在ARP表项. 3.当本地的VM发出ARP请求时,br-tun交换机会优先查找本地的ARP表项,从而对报文进行ARP应答. 这样的话,就不用发出AR

ovs源码阅读--流表查询原理

segmentfault对应博文:https://segmentfault.com/a/1190000016112493 背景 在ovs交换机中,报文的处理流程可以划分为一下三个步骤:协议解析,表项查找和动作执行,其中最耗时的步骤在于表项查找,往往一个流表中有数目巨大的表项,如何根据数据报文的信息快速的查找到对应的流表项是ovs交换机的一个重要的功能. 在openflow协议中,支持多级流表的形式,可以类比于将一个复杂的功能进行打散,分解成过个小的功能,实现一个流水线的功能,具体见下图: 上图中