Linux bridge 毕竟是老牌技术，很早就已经加入了linux的内核，其本身不支持 Openflow 协议，当Linux bridge 作为转发设备时，其转发实现依靠的是传统的地址学习机制。交换机识别出包头的内容后，即去查找交换机的 mac 地址列表，然后按照包头中目的mac对应的 port 转发出去，如果mac地址没有查到则在所有接口中洪泛数据包，直到收到包含未知mac 的数据包后，记录下mac地址和对应的接口，一个最基础的二层转发过程就完成了。

传统mac学习机制早已深入人心，不做过多的介绍。而SDN化后设备的配置、初始化等可以统一由Neutron server和主机上的 L2 agent来完成，但 Linux bridge本身的问题导致它跟传统网络交换机一样，转发行为不可控，添加功能麻烦。

来自 <http://www.innervoice.in/blogs/2015/01/26/using-mac-table-linux-bridge-wilt/>

Linux bridge的mac地址表

local

Local 模式为虚拟网络最基础的模式，该模式下的虚拟机连接到位于主机内部的虚拟交换机，同一台交换机上虚拟机之间能够通信，虚拟机无法与外界通信。

local模式下的本地联通

当采用Linux bridge作为二层转发设备时，每在主机上创建一个本地网络时，Linux bridge agent都会在物理主机上起一个新的虚拟交换机 bridge，交换机的名称的前缀为brq-xxxxxx ，Neutron的L2虚拟机主机连接到本地网络上时，就是通过tap类型的虚拟接口连接到了这个特定的bridge上。当有主机需要连接到交换机上时，

租户首先请求创建一个虚拟网络和一个端口，Neutron会分配对应的网络资源并分配vlan id，随后即创建端口和并关联到此网络。
租户请求创建虚拟主机，Nova组件将按照租户的需求调用虚拟网络驱动，创建一个tap类型的接口，随后nova创建虚拟机后即会将虚拟机与该接口关联。
随后租户请求将tap设备关联上之前创建的网络端口，Neutron将端口的关联信息记入数据库。
主机上的bridge agent不断扫描本地的接口变动情况，一旦发现新加的接口后，会上Neutron查询新接口的详细信息。
随后主机上的agent会根据Neutron server数据库中的配置在主机上创建bridge和vlan，并设置虚拟机接口的连接。最后更新Neutron server数据库中接口状态。
vm正式关联上虚拟网络。

来自 <https://wiki.openstack.org/wiki/Neutron-Linux-Bridge-Plugin>

至此同一bridge上的虚拟主机已经可以相互通信。不同的 bridge 之间暂时还不行。这也就是Neutron、支持的最基础的网络类型：Local。

在实际环境中因为无法与外部通信，Local类型的网络在实际中使用得较少，仅仅在需要隔离进行测试系统或者业务时需要用到。

Flat

Flat模式为虚拟机与外部网络直连的模式，主机内虚拟机直接连接到租户网络。

而一旦当 Bridge 关联一个物理网卡后，每当物理网卡收到数据时，都会把数据转发到 Bridge 上进行处理。而linux Bridge 接收到此数据时，则开始进行mac地址学习、查找mac地址表、转发、丢弃等操作。这种情况下，物理网卡与虚拟设备直连，物理网卡上不配置任何IP地址，数据帧出物理主机也不带vlan的标签。虚拟机上的数据通过二层直接转发到外界的物理网络上。实现虚拟机与外界的直接通信。实现了Flat类型的网络。

在物理主机上查看Linux bridge虚拟交换机

除此之外，Linux bridge上还有另一个隐藏的三层接口，类似与传统交换机的SVI接口，用于bridge与linux 内核之间的通信。

flat模式下，云主机直接连接到物理网卡进行通信，这种情况下、物理网卡只能连接一个虚拟交换机，主机内部所有需要直连物理网络的虚拟机，都会接入到这台虚拟交换机上。

这种接入模式在实际环境中使用得较少，主要用于云主机需要与数据中心内部硬件服务器互联互通的应用场景，如：应用服务器安装在虚拟机上，而数据库服务器安装在硬件服务器上，以及虚拟机需要通过二层连接传统的 SAN 存储的情况下。在公有云上使用得不多，因为直接连接到物理网络上，意味着暴露给了其他租户，存在被扫描漏洞以及被攻击的风险。而且不同租户之间虚拟机需要通过通信的业务更少见。

VLAN

vlan 类型是比较经典的组网模型，同一 vlan 中的虚拟机可以通信，不同 vlan虚拟机之间的数据通过二层vlan标签进行隔离，该类型网络要求租户网络的接口与物理主机的借口通过trunk互联。

Linux bridge中，vlan类型的网络将在网卡eth1上创建1个子接口： eth1.xx ，当有流量从该接口流出到物理网卡上时，会加上一个xx的vlan标签。而带标签的流量流入时，则会去除标签并转发到对应虚拟交换机上。

VLAN 是一种非常普遍的网络类型。

公有云中云主机、路由器连接的“基础网络”、“经典网络”就是一个vlan类型的网络，租户的数据不再需要通过overlay的方式进行封装，而是去掉标签直接与互联网进行通信。

这个二层网络通常为数据中心内部的vlan，默认这个vlan内的主机之间都能通信，所以在连上基础网络后，通过端口扫描能够扫描出大量其他用户的主机。而且因为没有公网IP映射和回指路由，这个vlan内的ip是无法通往外部网络（Internet）的。

VXLAN

VXLAN扯开了讲，这篇博文就要明年才能更新了。简单说就是vlan最多只能隔离4096个网络。对于用户数庞大的云运营商来说，肯定是不够的。

虚拟交换机上创建一个 vxlan-1的虚拟接口，vxlan-1捆绑到配置了VETP地址的物理网卡上。

虚拟交换机上行数据包被vxlan-1接口封装到UDP包中，并通过VTEP接口转换到物理交换机上。

这几乎是每一个想公有云都会用到的技术了，更多的逻辑隔离，意味着容纳更多的用户、更多的流量。而且兼容传统网络设备，可以直接利旧。VXLAN本身也不完美，过长的包头导致带宽无用的损耗，其次协议的封装也会给设备带来更大的压力。

Open vswitch实现方式

与老牌的Linux bridge不同，OVS是由Openflow祖师爷的公司创建的，其通过流表（flow table）的方式实现数据层面的转发和操作。控制器直接将数据包转发的规则以流表的方式发送给交换机，流表包含了详细的匹配信息——什么样的数据包（包类型、源mac地址、目的mac地址、源IP地址、端口等等，1.5版本中已经支持最多45个匹配域），执行什么样的操作（转发、丢弃、修改其中某些字段，匹配其他流表），如果遇到流表无法匹配的数据包，默认也会转发给控制器，由控制器生成新的流表。以下是流表中一个条目包含的字段。

以下太长了懒得看系列：每条 Openflow 流条目包含了匹配条件和执行的操作。匹配到的数据包会按照操作进行转发或者丢弃等。

Openflow 条目

匹配字段：用来匹配需要处理的数据包，可根据数据包的入接口、包头字段、和上一流表定义的元数据字段等等来匹配。最新的1.5.1支持45个匹配域，包括了：入接口、源mac地址、目的mac地址、以太网帧类型、vlan id、vlan priority、ip DSCP、ip ECN、ip源地址、ip目的地址、源端口、目的端口、arp opcode、icmp code、MPLS 标签、流表之间传递的元数据等等。
优先级：流条目匹配的优先级。优先级高的条目先匹配。
计数器：匹配成功后计数器会+1。
说明：用来指定对于匹配成功的数据执行的操作。
超时：流的过期时间。
cookie：自定义字段，用于实控制器的一些自定义操作，例如批量地删除或修改cookie值为XXXXX/16 的流条目（这些流条目可能是用于对某一类业务或者某一个租户的数据包进行处理的）。cookie不会对于数据包的转发和匹配造成影响。
Flag：flag用于标识流条目的管理方式。比如当flag包含 OFPFF_SEND_FLOW_REM ，则当交换机因为流条目超时或者流条目空间不足而删除条目时，都会触发交换机发送流删除的消息给控制器。

（相信对于很多人来说都会发现流表其实与传统交换机上的ACL、route-map等策略路由的处理方式是有点类似的）

Openflow v1.5 数据包处理流程

以下太长了懒得看系列：Openflow 交换机对数据包的处理可以看成两条管道对数据流进行过滤，流表和流条目就是滤网，将筛选出来的数据转发出去或者丢弃。

Openflow 在1.5版本后有一个非常大的功能改动，那就是引入了出端处理流程（Egress processing）。过去版本中数据包进入交换机后直接只需经过一次处理，确定出口后即被转发出去。1.5版本后，数据包匹配完，确定出接口后，会再进入出端的匹配流程。例如：

数据包的进入Openflow的交换机后，首先进入入端处理流程（Ingress porcessing）逐条匹配入流表中的流条目；
数据包 match 到的优先级最高的条目，流条目对应动作集也将执行，并更新流条目相关的计数器。
根据动作，数据包有可能被传递（Goto-Table）到另一个流表，然后重新按顺序匹配。也有可能直接丢弃（drop），或者最终匹配到优先级最低的条目。
如果匹配正常，确定的了数据包的出接口，则开始出接口处理流程（egress processing），出流表与入流表在功能上时类似的，不同的是入流程和出流程之间不能通过（Goto-Table）传递数据包。出流程无法重新指定数据包的出接口。
每个流表都必须支持一个 Table-miss 条目，Table-miss 条目优先级最低，为 0。并且匹配域全部匹配。可以看成是一条全为 0 的ACL条目，用来处理那些还没有建立转发规则的数据流。对于这一类的流量，可以选择转发给其他表、或者转发给控制器用于生成新的流表、以及直接丢弃。从流表的设计优化的角度来说，table 0 内的table-miss条目会将数据包转发给控制器，而不是任由无法识别的流量向下持续匹配。

一次流表操作示例

所以基于此，我们完全可以制定出这样的流表：

Ingress processing：

table=0 , priority=1 , ARP类型的数据包（ETH TYPE=0x0806） , 交给 table(10)处理 resubmit(10) -通过匹配域识别出arp类型的流量，并交由指定的流表处理。

table=10 , priority=1 , ARP请求的目标ip为 192.168.1.0/24 (OXM_OF_ARP_TPA=192.168.1.0/24) , action 修改请求中的源mac地址为网关的mac（0xa0a0a0a）。修改请求中的源IP为用户请求的IP（192.168.1.x）。修改包的类型为arp 回复 ——(arp代理的实现)用网关的ip来回应原主机

将原请求中的源mac 和源ip 移动到目的mac 和目的ip ，返回给源端口(OXM_OF_IN_PORT)。 ——构建arp返回包

进入出处理流程

Egress processing：

table=233，priority=100，修改以太网帧的源mac地址，目的mac地址，转发出接口。——重新封装二层帧

（实际中不一定包含 egress processing ，相应的流条目可以放在入处理流程内，实际现有arp代理功能并没用到egress processing ，此例仅为演示效果。）

交换机收到目标IP为192.168.1.100的ARP请求，交换机用自身的mac地址来代替远程主机的mac，并修改数据包类型为ARP回应后，从源端口发送出去。

由此可以看出，SDN交换机可以在完全不懂arp协议是什么的情况下，仅仅通过匹配和操作即实现了传统交换机的 arp代理功能。同理如果需要增加新的功能，只要制定流表就可以，当然前提是交换机上Openflow协议支持对应的匹配域和动作。

处理前

原二层帧头	发送器MAC地址	发送器IP地址	目标MAC地址	目标IP地址
	OXM_OF_ARP_SHA	OXM_OF_ARP_SPA	00-00-00-00-00-00	192.168.1.100

处理后

新二层帧头	发送器MAC地址	发送器IP地址	目标MAC地址	目标IP地址
	0a-0a-0a-0a-0a-0a	192.168.1.100	OXM_OF_ARP_SHA	OXM_OF_ARP_SPA

1.5版本中，Egress processing 的引入大大缩减流表匹配的复杂度，然而 Openflow 每次版本更新所带来的改变同样让sdn交换机厂家比较头疼，这意味着交换机和控制器的协议栈要重新编译，甚至不得不重新设计转发芯片。所以sdn交换机都会注明支持 1.0、1.3等版本的Openflow，如果交换机只支持旧版本的Openflow协议，则意味着交换机的功能也有限。而且新版本的协议发布后，设备厂家跟进也需要时间。其次Openflow这种协议无关的规则，也限制了其本身的应用。

从国内主流厂商官网的信息来看，大部分的交换机依旧只支持Openflow 1.3

local

OVS 会在主机上创建三类虚拟交换机

• Integration bridge (br-int) : 内部交换机，用于连接主机上所有的虚拟机和其他两类交换机。还有一些特殊功能的插件也会连接的br-int上。如浮动ip、dhcp等。

• External bridge (br-ex) : 外部交换机，即 ovs Provider Bridge 用于连接外部网络。即租户网络的边界。

• Tunnel bridge (br-tun) : 隧道交换机，即 OVS Tunnel Bridge 用于连接各计算节点之间的租户网络，所有租户网络的流量在打上vxlan的标签后都会发送到此网络。

简单来讲，OVS 的三个虚拟交换机各有分工，br-int 内部交换机主要用于计算节点内部的网段之间的通信，而br-tun用于节点之间的网段通信。Br-ex 与虚拟主机与外部网络的通信。三个交换机都通过各自不同的流表来实现相关的功能。

ovs也支持local类型的网络，在openvswitch中有所不同，所有的实例都连接到 br-int 交换机上，每一个本地的网络相当于一个ovs 上的 local vlan，连接本地网络中的所有节点。Neutron不会为local vlan创建任何flow rule。意味着不同的local vlan之间是无法通信的。

Local vlan位于主机本地，不同于我们常理解的vlan，从名字就能看出，一个主机内的 local vlan 在其他主机上是没有意义的，当两个主机之间通信时，需要通过流表把各自把 local vlan 标签通过流表转换为外部统一的 vlan 标签。

ovs 和 Linux bridge 之间通过虚拟以太网 veth 类型的接口互联，veth 类型的接口可以理解为一条网线，数据包从一头进入，另一头出来。

ovs 的交换机之间（br-int、br-tun、br-ex）通过 patch 类型的接口互联，patch 接口与 veth 类似，不过为 ovs 做了优化。据说能提供更好的性能。

Flat

ovs上flat类型的网络亦是通过flow rules（流表）来控制的，flat类型的网络关联到本地的local vlan，Neutron创建对于local vlan网络的规则：从ovs 的flat网络中出去的流量，将取出local vlan的标签，并通过 br-ex 交换机转发出去；而未打标签的流量从 br-ex 中进来的时候则会加上local vlan标签。

VLAN

openvswitch，每个vlan类型的网络都会映射到OVS上的一个local vlan。当OVS上有Local vlan的流量出去网卡时，OVS会根据local vlan和真实vlan的映射关系进行标签的转换。然后从br-ex 交换机转发出去。

VXLAN

在此模式下 br-tun 虚拟交换机终于派上用场，OVS通过名为 br-tun 虚拟交换机来实现流量的封装和解封，tunnel bridge连接内部的integration bridge 和配置了VTEP的物理网卡。br-tun 通过流规则来实现数据包的封装，将从br-int交换机传输过来的数据包，根据目的地点的不同选择从VXLAN、或GRE的隧道转发出去，并对数据包进行重新封装，封装之后的数据包外层为节点物理网卡的二层和三层包头，数据包的载荷则是原来完整的数据包，就跟包饺子一样，馅被整个地包到了外皮里面。当使用VXLAN类型的网络时，br-int传来的数据包会被 br-tun 重新封装一遍，并在原数据包的前面加上一个UDP的包头，里面包含了该网段对应的VXLAN的网络ID，新数据包的包头为主机物理网卡的IP和mac地址，加上目标主机物理网卡的IP和mac地址。

VXLAN数据包的结构

GRE

GRE是一种历史悠久的隧道协议了，其优点是支持组播，甚至能够用来承载动态路由协议的数据包，被广泛运用在各种场景下，不仅仅只是云数据中心。GRE隧道模式下与ovs工作流程与VXLAN 非常类似，不过一个 VNI 号位于TCP的字段，一个位于UDP的字段内。

GRE包头

需要注意的是 Linux bridge不支持GRE协议。

2.对于广播、多播的处理

传统模式下，当虚拟交换机处于地址学习的模式下，当交换机收到到一个未知mac地址的数据帧，这时如果交换机不做任何的优化，则默认需要将该数据包重新封装后从二层广播出去，直到那个未知的主机返回数据帧后，才能准确知道目标虚拟主机对应的节点。这一问题也只有在overlay的环境才更突出。

在下面的例子中，租户233位于计算节点1和计算节点N上的 VM1需要与节点N上的 VM4 通信，VM1还不知道VM4的MAC地址，VM不得不发送ARP请求进行查询，而虚拟交换机上也没有对应的mac地址记录，因此数据在整个租户网络上洪泛。同一承载网络上的所有主机都收到这一请求，直到节点N 核对网络号和主机IP后，将数据转发给VM4，VM4再做出单播的回应。

Ovs 默认的处理流程也与此类型，不同的是ovs的虚拟交换机收到arp请求之后，并不懂得如何处理，而是转发给控制器，控制器会让交换机在所有端口上洪泛，直到收到虚拟主机的回应后，交换机再将回应的包转发给控制器，控制器依据此信息更新流表，随后才能正常转发两个主机之间的流量。

这种方式显然有问题，通常一个租户有多台云主机时，并不会将所有的云主机都放置在同一台云主机上（这个放置算法也很有料，有空可以聊一下）。这时，如果所有的未知地址的二层帧，或虚拟网络的广播、组播包全部都在物理网络上洪泛的话，物理网络将长期被各种广播包占据。特别是租户较多的网络中，这种方式无疑会导致物理网络无法正常工作。

对于这一问题，主要有以下几种解决办法：

1、在虚拟交换机上启用arp proxy，Neutron L2 driver 会在所有的虚拟交换机之间预加载远程VM的 IP 和 mac 的对应关系、以及VM的mac和物理节点网卡mac的对应关系，本地虚拟交换机响应主机的arp请求，从而杜绝 arp广播在传输网络中的广播。但这仅能处理arp的广播包。

2、仅将二层的广播包发送给包含了该租户网络(VNI)的节点，主要有两种实现方式。

2.1、在物理网络上启用多播，这样当节点上有虚拟机加入租户网络时，节点发送IGMP请求加入该虚拟网络对应的组播组，这样，广播流量被转化为组播流量，当该租户网络上有广播包时，节点的网卡会将虚拟机的广播包封装成组播包，发往物理交换机，物理交换机只会将组播包复制到加入到该组播组的主机，无需再在网络中进行洪泛。这要求物理网络支持组播，而且需要规划好组播组与租户网络的对应关系。因为组播地址数远少于租户网络（VNI）的数量，所以通常多个租户网络对应一个组播地址，这样依旧会有一些租户网络的数据包被发送到不相干的

节点上。

组播复制

2.2、租户网络二层广播包被物理主机单播到一个服务节点，该服务节点本地保存所有vm ip、vm mac、主机mac信息，由该服务节点将原始数据包复制多份之后，分别发给包含该租户网络的节点。这不要求物理网络支持组播，也不会有多余的传输，但是对于服务节点的存在本身就是一个较大的问题。

单播复制

3.其他功能

3.1安全组

Neutron 选择使用linux内核中的 iptables 来实现的虚拟安全组的功能，所有安全组的策略都关联在虚拟机所连接的tap接口上，流量进出虚拟机网卡时都要经过 iptables 的过滤，保证了虚拟机的安全。然而尴尬的是，这种方式下需要将数据包交由主机内核的协议栈来执行iptables的处理，而 ovs 基于流表的处理方式是独立于内核的。所以当使用ovs来实现安全组的功能时，不得不在每台VM和ovs之间添加一台 Linux bridge，虚拟机发出的数据包先到达 Linux bridge，经 iptables 过滤后再上行到ovs。如果是进入虚拟机的流量则将这一过程反过来，最终成了下面这种奇葩的连接方式。

详细的安全组的介绍还是放到后面吧….

4.OVS与Linux bridge 之争

4.1 功能对比：

总结以上来看Linux bridge为早期的虚拟交换机实现方式，理念也更接近以前思科的网络模型，更多的依赖物理网卡作为网关。而OVS的实现更加符合SDN的理念。由此可以看出，Linux bridge更加成熟稳定，但是如果要添加功能会比较麻烦。比如至今任不支持GRE、也不支持DVR（这才是最伤的，只能使用集中式路由意味着VPC之间的流量需要绕过网络节点的发卡弯，这个后面路由的时候再详细介绍）。

OVS更符合SDN的理念，通过flow-rule 来实现各种二层、三层的特性，这样优点是可以简单的通过流表添加新的功能的，也有可能兼容更多的SDN解决方案，除此之外OVS 也支持模拟传统交换机的行为，实现与传统交换机的共同组网。

但是同样，Rackspace 也列出了ovs当前存在的问题：

1、内核错误（版本 1.10），可能导致物理主机出错

2、分段错误（版本 1.11），ovs分段错误重启导致流表被清空

3、广播风暴，物理主机大批量开机，而同时主机上的ovs 插件没有起来，则可能导致广播风暴，可以通过修改ovs的启动脚本解决，不过会使ovs变得复杂。

4、数据损害（版本2.01），这里他们举了一个例子，mysql的“BEGIN”指令到了接收端变成了“BEGie”（真是个奇怪的问题，不知道有没有大神能阐述一下原因）

而他们看重的linux bridge的理由则很简单：

1、稳定

2、容易排错

3、同样被社区支持

追求稳定性的同时，也意味着失去更多的可定制化（包括对DVR的支持）

两者功能对比：

4.2 性能对比：

OVS和Linux bridge两者在性能上的差异并不大，在使用vlan类型的网络时，OVS 和 Linux bridge都能获得不错的性能表现，约等于物理网卡的理论速率的90%，而运行在Vxlan模式时，则会有非常高的性能损耗。在使用SCP这一类单线程协议，传输大文件时，传输速率接近腰斩。

iperf打流的情况下，ovs 和 Linux bridge 都只能达到网卡理论速率的10%左右，性能衰减非常厉害。可能的原因有：在数据包数量较多，数据收发频繁时CPU容易成为性能的瓶颈，这一问题在使用DPDK技术后能得到一定的缓解。不过根据rackspace的实测结果，即便在多线程的情况下，对于交换机的性能也没有显著的改变，可见瓶颈在于CPU对于VXLAN数据的封装和解封装上。不过我没有实测过ipref在打流时CPU的利用率，有测过的同学可以一起讨论一下。

但是总的来看，吞吐性能与交换机采用的网络类型有着直接的联系，考虑到封装VXLAN后数据包多了一圈包头，数据的有效载荷减少，实际网络的吞吐要比测试的稍微好那么一点点，但是性能下降的程度可见一斑。

Rackspace的ovs和Linux bridge跑分测试结果

3.3总结

Linux bridge 、ovs 这两者都被Neutron容纳进来，既有国外巨头因为ovs的不成熟而整体切换到 Linux bridge，也有国内厂家使用OVS 流表实现了各种 Neutron 都还不具备的高级功能。而除了 Linux bridge、OVS这两大代表解决方案外，还有与这两者完全不同的解决方案。

	OVS	Linux bridge
工作方式	基于流表	基于地址学习
功能	不成熟，不同的版本支持不同的功能，可扩展性强	较为成熟，可扩展性差
性能	一般	一般
优势	可定制能力强，通过流表可满足非常多特殊应用场景下的功能需求使用得最为普遍的SDN 交换机	成熟稳定，主流功能都由相应的插件满足要求。足以满足大部分用户的使用需求。
劣势	Openflow的特性还未被完全利用，部分功能还无法实现。 Openflow协议本身的不成熟，新版本与老版本之间差异较大，导致硬件厂家需要较长的适配周期。技术与市场脱节。	难以响应新型业务的需求，导致在一些教新的SDN领域应用得很少。
代表方向	数据层和控制层的完全标准化，特性的业务需求完全可自主实现，无需依赖硬件厂家	与传统网络兼容，在各种设备混杂的环境下，通过封装统一的北向接口实现网络的自动化。

花了老鼻子力气来讲 Linux bridge与 OVS 在原理上的不同，核心是试图摆明现在SDN实现中两种不同的方向。一个天生就不屑于与传统势力共舞，立意高远试图以更接近理想地方式颠覆传统的网络，并定义标准的协议的软交换产品，技术实力雄厚的大佬们已经凭借着技术的优势获得了不菲的成绩。可是大众的用户依旧面临着不够成熟的产品，和自身羸弱的开发能力，许多时候只能望洋兴叹。

代表组织：ONF
涉及势力：Facebook、Google、Big switch

而另一个在现有的基础上兼容着传统的网络设备和协议，不涉及到转发层面的操作，并不限定任何南向的技术标准，允许各个厂家百花齐放。只是定义一套统一的北向接口，试图的作为一个口袋方案，囊括底层所有的复杂性，尽量以统一的面目对外。大量地厂家投入到该项目，用户有大量的可选方案，然而厂家参与者们各自心怀鬼胎，用户依旧不得不面临各参与者人为制造出复杂性和隐藏的深坑。

代表组织：ODL
涉及势力：Cisco、Juniper、Brocade等

这两种情况在现实中都拥有着大量的用户群体。部分运营着大规模网络的用户，选择的是在现有设备的基础上，实现管理控制的SDN化，以更好地满足业务的需求。一方面不得不耗费大量的人力和时间去适配网络中各种厂家、型号、软件版本的硬件设备。另一方面大量使用overlay+软交换机的模式，期望最大限度地降低这种复杂性和对底层的依赖，典型如：如运营商（电信、联通）、大型企业（阿里、百度、腾讯）等。中小企业如果耗费大量资金来招募团队来做SDN的实现就违背了做SDN的初衷，但是大量企业又希望能享受SDN带来的便利，而只能转投传统网络企业的阵营，采购现成的产品，如，思科、brocade、vmware、juniper、华为、H3C、锐捷。这些产品往往被打包融入厂家的基础架构中，用户依旧被绑架，而不得不购买整套的产品，同时这些厂家之间同样基本缺乏完备的互操作性，看似支持开源技术的产品，实则被各个厂家包装后，依旧和原来一样封闭。然而对于用户来说，是否开源并没有那么重要，

SDN的现状，正如朝霞的天空一样色彩斑斓，剧烈涌动，没人知道这种混乱要持续到什么时候。

附各厂家SDN控制器阵营划分

部分参考：

《Neutron L2 and L3 agent:how they work and how kilo improves them》 -opnestack summit

https://www.ibm.com/developerworks/cn/linux/1310_xiawc_networkdevice/

http://www.innervoice.in/blogs/2015/01/26/using-mac-table-linux-bridge-wilt/

Openflow® Switch Specification Ver 1.5.1

查看全文

相关阅读:
java xpath
structs2 Interceptor
jetbrains idea web help
Java xpath example code THE RIGHT WAY
java xpath engine
本地安装jruby到maven仓库，由于公司网络不给力
 skybe的linux下的版本下载
 mybastis学 rails有migration了
 Using Java from Ruby with JRuby IRB
PropertyPlaceholderConfigurer

原文地址：https://www.cnblogs.com/pmyewei/p/6413875.html