SDN（Software Defined Network）是个有意思的概念。ONF（Open Network Foundation）这样定义SDN：
In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.
用普通话说就是软件独立于硬件，让硬件标准化，软件平台化，信息中心化。
这概念说新颖不新颖，软件行业从OS诞生的那一天，就已经这么做了。Wintel主导的PC革命让整个行业围绕着一致的硬件体系，统一的，向后兼容的API（Windows SDK）开发硬件和软件的各种应用。用个不太恰当的类比：上图的infrastructure layer相当于PC的硬件，control layer相当于windows/SDK或*nix/POSIX，application layer相当于OS之上的各种软件。
可是网络设备行业却一直没有形成这样的生态圈。我觉得是两个方面的原因：
所以CISCO/Juniper等一票vendor就这样软硬兼施地做了若干年，慢慢把市场培养成现在的样子：没有第三方，一切软件，从系统到应用，从package forwarding到VoIP，只能是我自己提供。所以当08年还是09年，Juniper依然壮士断腕，轰轰烈烈地推动One JUNOS，开放SDK，试图打造一个类似Windows的生态圈，似乎为时已晚，应者寥寥，因为愿意和有能力接盘的软件公司已经不多。
但是网络设备的发展的相对滞后，越来越赶不上mobile internet/cloud computing时代的步伐。成千上万的应用被不断地创造出来，就几个vendor的一帮苦逼程序猿咬牙应对，肯定是杯水车薪。
信息中心化是对传统网络的一大挑战。Internet的前身，ARPANET，在创建之初就有一个前提：这个网络是个自制的，无中心的系统，网络遭受任何局部损失都不会影响其他部分的正常通讯。所以，所有的RFC都围绕着这个前提来构建，所有的网络设备也遵循着这一前提来研发。
但是SDN将这一前提打破。所谓天下合久必分，分久必合。网络世界也不能免俗。Cloud computing引发的互联网革命新浪潮将计算和存储中心化，SDN顺应了这一趋势。通过硬件，软件平台的支持，信息（网络状态）被共享到一个逻辑上集中的中心。相对于去中心化的传统网络，SDN带来很多很多优势。本文将着重讨论信息中心化对网络设备的革命性意义。
温馨提示：作者对还未系统研读过关于SDN的ONF white paper，也没有实际研发过SDN相关的软件，所以本文中的一些想法均属臆测，既不完整，也不完备，可能经不起进一步的推敲，不当之处，还望指正。
网络设备的核心是转发，即packet从接口X转发到接口Y。转发的依据是选路，路由协议会告诉系统如何选路。转发最头疼的问题是link down，无论是physcial还是logic link down，对于拓扑中的一台网络设备来说，link down意味着重新选路并通知其他网络设备。这直接导致一段时间的丢包。选路时间越长，丢包越多。
link down带来两个问题：
先看收敛问题。一台运行OSPF（其他协议大致如此）的网络设备的convergence time大概可以这样算出：
Convergence = 链路状态变化发现时间 + 协议消息传递时间 + SPF计算时间 + RIB/FIB更新时间所需时间：
由以上公式大概可以看出，convergence的瓶颈在SPF计算和协议消息传递上，网络越大，SPF和协议消息传递所需时间越长。此外，一般网络设备对计算量大的任务，如SPF，跑在相对低优先级的task上，无形中又降低了SPF的速度。
在众多路由协议中，OSPF和IS-IS这样的链路状态协议，由于每台设备都拥有局部甚至全局的网络拓扑信息，收敛速度已算上佳。
再看重新选路的不确定性。由于拓扑中其他设备的影响，某台设备的同一条链路先后几次link down的选路不一定相同。所以，每次link down发生，路由需要重新收敛，不能依照之前的历史来做出决定。
如果能够将路由信息中心化，即一个云端计算中心实时掌握全网的拓扑状态，则可以做很多很有价值的处理。比如：
配过防火墙，或者见过大型网络下防火墙在生产环境下实际配置的同学都知道，这玩意儿不是一个好配置的主。动辄成百上千的address book, policy, VPN等无论是CLI还是WebUI配置都是一种折磨。虽然大型的企业会顺带购买网管系统来统一配置旗下的各台设备，但那玩意还是一个局部的，纯静态的配置。
配置麻烦是传统网络设备的一大问题。
另一个问题是服务器动态迁移带来的网络管理问题。这个问题是服务器虚拟化革命带来的，现在的网络设备对此基本无解。为了便于说明，我们看下图：
一个典型的企业intranet会将不同部门间的访问权限分隔开，比如说engineering team只能访问engineering server，finance team只能访问finance server。传统防火墙对此表示毫无压力。
from eng-clients-zone to eng-server-zone any-source any-dest permit
from finance-clients-zone to finance-server-zone any-source any-dest permit但是有一天，机房里的服务器全部都被虚拟化了，物理上已经没有了zone的概念。所以配置需要变成：
from eng-clients-zone to intranet-server-zone eng-client-ips eng-server-ips permit
from finance-clients-zone to intranet-server-zone finance-client-ips finance-server-ips permit在同一台防火墙的管理下，这可以运行地很好，即使virtualized server在physical server间跑来跑去，只要IP不变，policy就不用发生改变。
但是，当网络变大，支撑业务运作的服务器和网络设备都增加时，会发生问题。想像一下，上述网络由两台防火墙保护，virtual server从一台防火墙后面迁移到另一台防火墙后会发生什么情况？
已有的配置将无法适应这种变化。管理员需要手工去调整配置。但是，virtual server的灵活性和physical server不可同日而语：一周甚至一个月内，physical server可能都不会有太多的变化（迁移，部署），但virtual server可能朝生暮死（想像一下aws）。
同样地，有了全网的实时拓扑信息后，SDN可以动态调整网络的配置，甚至都不需要人工干预。不用细谈，想想看：
顿时觉得无限可能，尽在SDN。
没做过网络设备的人可能不知道网络软件的Debug有多么辛苦。一般软件Debug步骤：
对于网络软件而言，信息搜集是一道坎，你要能拿到topology下面各个相关网络设备的配置和问题出现时的log。这绝对不是一件容易的事儿。不信你问customer escalation engineer。他们每天要死要活地抓log，一次很难成功，两次，三次成功都算苍天有眼。
就算成功抓到了需要的log，想想AT&T给你个路由震荡的issue，一个大topology下数十台设备，数兆的configuration，数十兆的log。相关的，不相关的，反正都抛给你，你死的心都有了。
SDN太有优势了，因为集中控制，所以可以：
最后，可能有80%的case都能找到一个前例；剩下那20%，到engineer手上，也是narrow down的有价值的数据，甚至分析报告。
瞎扯了一些SDN的也许不着边际的应用场景，立此存照，来年再看。我对SDN商业上的看法是：
依旧例，放上一张小宝最近的游泳照，感谢你耐心读到这里：
如果您对本站的文章感兴趣，欢迎订阅我的微博公共账号：程序人生。每次博文发表时，您都能获得通知。此外，公共账号还会不定期推送一些短文，技术心得，供您参考。
