Mininet 代码分析

Mininet是个很不错的模拟（emulate）网络的工具，特别在模拟SDN环境的时候。

使用Mininet可以在一台物理机上快速搭建较大规模的SDN网络进行控制器或交换机方面的验证和测试。

关于如何使用Mininet，可以参考这里或官方主页mininet.org。

Mininet的代码结构十分清晰，分析文档可从这里下载。

OpenvSwitch 2.0.0发布

作为SDN交换机的标准软实现，可以夸张一点说，OpenvSwitch的每个进展，都影响到SDN产业的发展。

特别OpenvSwitch从一开始，就实现了控制层面和管理层面的分离，其对配置的管理协议ovsdb-conf正在成为管理层面协议的标准参考。

OpenvSwitch 2.0.0版本的主要feature在于：

ovs-vswitchd已经实现了多线程；

改进对OpenFlow1.1,1.2和1.3的支持；

支持对tunneled网包的发出源和目标地址的匹配；

db中的接口表支持ifindex项；

支持linux kernel版本到3.10；

log时间戳精确到毫秒级。

跟硬件交换机项目，SDN的软交换实现确实已经远远走在了前面。

参考：http://openvswitch.org/releases/NEWS-2.0.0

SDN 产业面临的挑战

The challenges that SDN industry is meeting.

SDN技术的发展正是如火如荼，ONF的成立，ONS的举办，各种论文的发布，各种软件的编写，都昭示着SDN已经成为了一个事实上的产业。

从Openflow开始，跟随SDN的诞生、成长历程数年，欣喜于其发展速度之快，未雨绸缪，有几个挑战是SDN产业继续成熟所必须要面对和克服的。

1、基础设施。软件交换机对SDN技术支持已经较为成熟，典型的代表包括Openvswitch、Indigo等。虽然Nicira很希望将来大家都用Openvswitch实现SDN架构，但不可否认，硬件兼容交换机的缺失，极大阻碍了SDN产品的普及。目前通过ONF官方认证的仅NEC一家，而可见的硬件交换产品功能大都限制颇多，而且价格昂贵。如果这一点不能尽快解决，将会限制SDN技术的应用领域。

2、典型案例。目前可见的SDN应用场景还是中小型的网络环境中，而且往往不够复杂。虽然Google今年在Sigcomm上发表了介绍其3年前部署的B4，但实际上，B4中涉及SDN技术的真实应用十分简单，并不能作为一个完全用SDN实现的典型例子，仍是个不错的尝试。实际上，SDN从诞生之初，就跟数据中心发展的需求密不可分。而无论大型数据中心还是中小型数据中心，往往都已有成熟解决方案。特别是大型厂商的不断创新，留给SDN技术的空间不断收缩。而在广域网和运营商领域，起步则太晚，可以预计这块能做的东西也不多。私有云和企业用户倒是极为青睐SDN，但愿意公开其部署技术的例子更少。

3、技术限制。不得不承认，SDN在带来网络监控上极大便利的同时，也确实仍存在技术上的问题，比如南向接口Openflow，在表的支持方面仍不够灵活；而开放北向接口一直缺失。虽然OpenDaylight项目已经做出了不少贡献，但仍未有release出来，也将影响SDN产业的快速发展。此外，性能方面的代价，现在仍未有简洁成熟的解决方案。与此同时，Cisco的ONE，Juniper的Contrial，Facebook的OCP，都带来了不同的技术路线。

4、扩展支持。SDN解决的是网络的问题。但在现在的应用场景中，网络并非独立存在，往往伴随着各种其他资源，比如计算，比如存储，比如安全。所谓动一发而动全身。网络技术的革新，必然要求其他领域的配合和改变。Openstack之所以能被广泛部署，取代其他现有产品，很大的一个优势就是它所提供的解决方案是一体化的，并非单独替代某一项技术。因此，如何跟其他领域的管控技术融合，也将是SDN进一步发展必须要考虑的。

5、管控解耦。对于系统，特别是网络系统来说，管理和控制实际上是两码事。SDN自诞生起关注控制层，提出了合理的控制层模型。而在管理层方面一直重视不够。最近ovsdb方面的配置协议在管理层面有所进展，但整个SDN界对此的认识仍然十分落后。不少SDN产品中管理和控制层面混杂到一起，给未来进一步的扩展带来极大的挑战。

RFC中的奇葩(2) - The Twelve Networking Truths

http://tools.ietf.org/html/rfc1925

12个网络相关的事实，发表在1996年的愚人节。

虽说是在愚人节，讲的东西却颇有道理。以幽默的方式阐述了设计网络这个前无古人的大工程中要注意的事实。

1）必须要能工作。。
2）不能增加光的速度。。
3）足够的推力，猪也可以飞，但显然没必要这么做。一个是很难控制它的着陆，另一个是当它们飞在空中经过的时候，坐在下面是一件很危险的事情。。
4）有些东西，不实际体验下，永远难以很好的认识和理解。
5）把多个问题糅合到一起，提出一个复杂的解决方案，不是一个好主意。
6）把问题转移到其他地方，比解决它要容易。
7）永远是某个存在。（怀疑有遗漏，推论是凡事总有tradeoff）
8）比你想象的更为复杂。
9）对所有的资源，你总是需求更多。
10）一个尺寸不能适应所有的事情。
11）所有的老主意总会被再次提出，换个名字，换个表达方式，不管是否工作的好。
12）在设计协议的时候，完美的目标，不是说无法再添加什么上去了，而是说无法再拿掉什么了。

理解网络元素

这里谈的网络，是以互联网为代表的计算机网络。
现实的网络要远比人们想象的复杂，无论是从拓扑结构还是底层设备上。
理想的网络模型，交换设备（各层的交换机、路由器、网关）连通主机，而在实际中，还存在大量的其他类型的盒子，比如负载均衡、防火墙、IDS，等等等等。
在云计算数据中心网络中，各类带有复杂功能的盒子更多，更杂乱。
那么，如何理清各种盒子（网络元素）对于正确理解网络本身就十分重要。

从网络的主要功能角度出发来看，网络的存在是为了信息的交互，因此，其最根本的功能是转发。无论一个盒子是几层设备，它的功能都是某种意义上的转发。而且这个转发，对终端用户来说应该是透明的，即用户不应该也不需要知道中间的信息。源主机只需要知道目的主机的信息，然后把流量扔出去，怎么转发到目的主机是网络的事情。同样的，目的主机收到的流量，只知道是源主机发过来的，也不需要知道具体是怎么发过来的。

基于“网络的存在是为了转发”这一原则，可以把现在的网络元素分为三大类。
第一类是基础转发盒子（basic forward network element），代表设备为传统意义上的安全middlebox，一头进流量，处理完了，从另外一头扔出来。这类盒子的特征是转发的方式是固定的，跟流量无关的。
第二类是根据流量转发的盒子（traffic aware network element），代表设备为各种交换设备。这些设备往往有多个接口，各个接口之间如何转发并非固定，而是需要根据traffic 的内容（典型的是包头中的目标值）来进行“动态”决策。
第三类是高级智能盒子（advanced smart network element），代表设备为负载均衡系统等。这类设备不光需要检查traffic的内容，还需要考虑其它相关的因素，比如服务器负载情况，各种QoS情况等。

这三类盒子，越往上，功能越复杂，同时支持的网络协议层数往往也越多。现在middlebox在网络中很热门，因为使用middlebox往往可以实现十分复杂的处理功能，这些middlebox也大多都是第三类元素。随着技术的进步，可以预见，第三类盒子的存在将越来越多。特别配合SDN技术，对这些盒子的管理将更加容易和多样化。

当然，现在有很多盒子同时把多种功能做到了一起，但万变不离其宗，仍然可以从这三个层次去理解它。