==============================================================================================
每个小区保安都是一个有潜力的哲学家，他们每天都要问三个终极的人生问题：
l 你是谁？
l 你从哪里来？
l 你要到哪里去？
是的，作为敏捷网络系列这样一套duang duang duang的技术文章，我们也会问这三个问题：
l 什么是敏捷网络？
l 为什么需要敏捷网络？
l 怎么使用和发展敏捷网络？
什么是敏捷网络
何谓“敏捷”？快而灵活。快追求的是“功效”，灵活则是包裹在这套快拳之内一股“巧劲”。光有快没有灵活，就是横冲直撞，最后可能造出一个不可平滑演进的怪物，光有灵活没有快，就是隔靴搔痒，最后可能解决不了实际问题。
在敏捷网络里，两个要素缺一不可。
所以说，敏捷网络是指一套组网架构吗？不是。是一堆特性或产品组合吗？不是。是一个SDN控制器吗？不是。敏捷网络这个词应该更像一个愿景――我们希望打造的是一个“快而灵活的网络”。而紧密围绕在这个愿景之下的，是支撑实现这一愿景的一系列架构，方案，产品，特性，功能。以下是本人对敏捷（Agile）的趣解，有点凑单词的嫌疑。。。
为了实现这一愿景，我们这帮吭哧吭哧的技术人员可谓“无所不用其极”。我们秉承邓爷爷的“不管白猫黑猫，只要能抓住老鼠就是好猫”的谆谆教诲，寻找一切让网络快不起来，灵活不起来的绊脚石，利用各种技术和方法一个一个攻破。
基于这个出发点，下面我们就要回答一个重要的问题：敏捷网络就是SDN吗？
1 敏捷网络就是SDN吗？――敏捷网络与SDN的关系
答案可能很难理解：既是又不是。
为什么会有这个答案？是因为同一个事情我们从不同角度来看，就可以得到不同的答案。
SDN字面意义是“软件定义网络”。其实这是一个很技术的术语，阐述的是一种技术方向。而敏捷网络的字面意义则是一个技术无关的网络建设目标。
比方说QoS这个术语。字面意义是“服务质量”。从字面意义而言，有谁能看出来QoS要使用什么技术吗？看不出来，因为这个词是QoS想要实现的目的――在网络中保证服务的提供质量。为了达到这一目的，我们可以用各种各样的方法，比如现在有流量监管，队列调度等等。未来还可能有更多满足这一目标，而且各不相同的技术出现。
而SDN则不然，从字面意义里就能看到技术的影子――用软件方式来定义、改造、管理网络，至于这样做之后能达到什么目的，其实不得而知。因此，SDN并不是从诸如“网络管理员已经厌倦了网络设备的命令行配置”或者“网络设备上要进行配置纠错已经到了令人抓狂的地步”这类客户抱怨出发，它一上来就是一个无比高大上的立足点――要让网络像软件一样可以自由定义，其实背后隐藏的意思就是“让网络无所不能”。
事实上，正因为这个“无所不能”，才让大家对什么是SDN进行了长久的争论。也正因为SDN本身是从技术理念而不是实际问题出发的，所以当人们一谈到SDN时，自然而然地就会将目光注视到了“控制器”、“控制与转发分离”、“Openflow”这一类技术上面。至于用了这些技术之后，到底有什么显而易见到，连从来没听说过SDN的网络管理员也能理解的“收益”？这不是SDN主要致力于要解决的问题，因为研究SDN的人们普遍认为的是“既然用了SDN之后，想让网络干嘛就干嘛，那到时候还不是想要什么收益就有什么收益么？”。SDN是一种自底向上的发展思路，先把一种机制或平台搭建好，在这个平台之上任由后来人发展应用场景。
所以，归根结底，SDN的目标是让网络更加“灵活”，也就是敏捷网络中的“敏”字，有更多的扩展性和可能性；至于用了SDN之后的“功效”，也就敏捷网络中的“捷”字，是网络设备厂商自己打开脑洞，去自由挖掘的创造之地。
敏捷网络要实现“快而灵活”的愿景，SDN相关的一系列理念和技术自然会在我们利用的范畴之内。所以，要说敏捷网络用了SDN技术吗？肯定用了。比如控制器，比如接口开放，比如设备虚拟化。从这个角度来讲，敏捷网络算是一个SDN网络。
但是，敏捷网络就仅仅是一个SDN网络吗？肯定也不是。SDN只解决了部分问题，还有很多让网络敏捷不起来的问题没有解决。要解决这些问题，我们还需要利用其它跟SDN无关的技术。所以，SDN在达成“敏捷”这个目标中有用、能用的地方我们就用，无用武之地的地方我们就不用。从这个角度来讲，敏捷网络又不是大家最常讨论的“依靠控制器下发流表来指导交换机进行流量转发”的SDN网络。在后面对敏捷网络的详细解析部分，大家可以看到大部分方案都与Openflow无关。
敏捷网络和SDN是从两个出发点，两个角度延伸而来的两个概念，自然不能完全用“是”或者“不是”来简单地判定两者之间的关系。敏捷网络会借用和兼容SDN所提出的理念和技术，但是并不将创新范围仅仅局限在目前大家所认为的某些SDN标准上。还是那句话：“不管是白技术，还是黑技术，只要能让网络敏捷起来的就是好技术”。
=====================================================================================================
2 怎么才算SDN了呢？――SDN的本质特征
从我们的出发点而言，重点在于解决客户网络臃肿难行的现实问题，至于是否用了SDN技术是次要的东西，是需要在一堆技术中优胜劣汰的事情。但是还是有很多客户一上来就问：敏捷网络是不是SDN？不是的话我就不用了。
之所以会有这种考虑，也是有实际原因的：
当前SDN的内涵和发展其实还是处于一个众说纷纭，百家争鸣的时期。很多人只知道SDN“很有可能”是未来网络发展的一个趋势，但是却没有时间、精力去深入研究和理解这个东西，或者仅仅是因为网络厂商纷乱的竞争，让大家根本就无从深入。
这是很正常的，作为一个顾客而言，就应该轻松地花钱买东西，为啥要操那么多心了解这么个深奥的玩意。所以，在“看不清”的现状下，只能笼统地下个结论：只有SDN的网络才是最有可能近几十年内不会被历史淘汰的网络，我部署成SDN网络，这个网络才是长期有效的。至于其他的，厂商说出花来也没有用。这是从客户自身网络的稳定性和可发展性角度来考虑的。
顾客有需求，我们就要满足，谁让顾客是上帝呢。既然顾客有这个担心，那我们就要解答：敏捷网络到底怎么就SDN了呢。
要回答这个问题，首先要回答，怎么就算SDN了呢？
这里不是SDN的专题介绍，自然不能将SDN的来龙去脉讲得清清楚楚。这里只能按照个人的理解对其特征进行一些总结。特别声明的是，纯属个人理解，如有争议，借用电视台常用的一句话：言论仅代表嘉宾个人观点，不代表本台立场。
2.1 软件定义网络
首先，还是SDN的字面意思，软件定义网络。个人认为这个词比“转发与控制分离”更能代表SDN的本质。这个词有以下几层意思：
l 让网络本身可以抽象化成“算法+数据结构”，可以用软件语言来描述和操控。这个抽象化又包含几层意思：
n 把网络中的各种物理实体抽象成编程对象。
比如，以前网管看待网络的视角是网元和拓扑。网元是网络组成的最小单位。依附于网元的，是网元的各种状态参数，比如接口的UP/DOWN状态，CPU占用率等等。网管首先是个“查看器”。基于查看结果，管理员通过自己的知识与智慧，完成“期望结果”到“设备配置”的转换。然后网管又是个“配置器”，利用网管与设备间的某些接口，向设备下发配置。最终利用设备的某些功能，间接达到调整设备状态的目的。比如通过接口限速降低设备的CPU负载等。
而SDN的想法更加彻底和激进。SDN希望让网络中每一个可操作的单元都变成编程语言中的一个“对象”，可以通过程序来直接调节其各种属性值。比如，有可能未来交换机上某个接口，就是一个编程对象。应用程序可以直接通过调节这个物理接口的PoE供电电压，来调整智能灯泡的亮度，起到节能减排的目的。当然，最为大家熟悉的，还是将网络设备的转发表变成可编程的对象，利用Openflow来实现控制器对转发表的操控。
n 把整张网络进行虚拟化，实现逻辑拓扑和物理拓扑的分离。
其实这个想法现在已经有应用案例了，那就是BGP MPLS VPN对网络的多实例化。BGP MPLS VPN想要实现的效果就是同一张物理网络，被逻辑隔离成多张虚拟网络。然而，BGP MPLS VPN其实并没有实现真正的网络虚拟化。
简单理解一下，BGP MPLS VPN的公网中，除了PE设备外，其他的设备对各个VPN实例都是不感知的。这些设备并没有存在“属于哪个VPN实例”这一说，它们只是转发着被封装好的，不知道属于谁的报文。从网管上看，管理员不能看到一张完整的只属于某个VPN实例的公网网络拓扑，而只能看到哪个站点跟哪个站点可以互联。
所谓的VPN实例，其实只是公网的边界设备，也就是PE之间的一种点到点的隧道把戏。相应的代价是，管理员需要进行非常复杂的标签过滤规则和路由配置来实现多个站点之间的合理互联。这种方式通常被称为“Overlay”。
真正的网络虚拟化应该是网络中每台设备都被一虚多为多台逻辑设备，这些逻辑设备间既可以通过物理线缆直连，也可以通过隧道进行虚拟直连。管理员可以随心所欲地定义这些逻辑设备间的互联关系以及相应工作机制，从而在同一张物理网络上，为某个客户定义出一张的既有二层，又有三层的纯树状网络，同时又为另一个客户定义出一张纯二层的环网。管理员可以在网管上看到每一个客户的一张完整、可控的逻辑拓扑图。
这么牛叉的技术有用么？配合云计算就有用了。将来大家都不自建网络，全去租用ISP的云数据中心，当这个数据中心达到一定规模时，我们要关心就不只是服务器的数量问题了，而应该关心服务器采用何种网络架构互联。不同架构适合于不同的数据模型，不同行业和客户需求，匹配好了才能达到最高传输效率。
n 把网络设备进行虚拟化。
网络设备虚拟化现在也是一个很笼统的概念。其实跟传统意义上的SDN没有太大关系，但是因为提到了虚拟化概念，就顺带着介绍一下。也刚好印证我们的“白猫黑猫”理论。目前主要包括三类概念：
u 将通用服务器虚拟化为一台或多台网络设备。就像现在数据中心的虚拟服务器一样。这就是现在也很火的NFV。NFV和SDN其实是两码事。
u 将一台物理网络设备虚拟化为多台网络设备。前面的网络虚拟化中已经提到。目前实际上已有部分设备支持类似特性，比如华为NGFW的虚拟系统则从管理界面、安全策略到路由转发都进行了多实例化，是已经比较完善的“一虚多”特性了。
u 将多台物理网络设备虚拟为一台网络设备。这种虚拟化跟多台服务器虚拟化为一台服务器不同。服务器的虚拟化根本目的是为了提升性能，而这里提到的网络设备虚拟化主要是为了提高可靠性的同时，还可以简化网络设备的管理。以前华为交换机所支持的CSS特性就是这个目的。敏捷园区网方案中做得更加强大一些。后面讲到时会再详细介绍。
l 讲完抽象化，接下来就是软件定义网络的第二层意思，将网络设备的能力开放给软件。
这里大家可能要疑惑的就是，以前网络设备里难道没有软件吗？
当然有。只不过以前网络设备在追求更快更高更强的路上艰难前行，最佳的策略就是软硬件的一体化设计。现在大家希望通过SDN实现的，是 “通用硬件+更多定制化软件”，在网络设备领域复制“Intel+微软+开发者”的辉煌。所以，重点在“开放”而不是“软件”。
事实上，一家厂商包揽软硬件设计的方法，从最终成品的质量上来看，一定是最佳策略。因为这意味着会有更多的精细化的调优和控制。
很明显的例子就是iPhone和Android。iPhone的硬件配置一直不高，连开始用2G的内存都上了最近的新闻。而Android早在前年就已经陆续上了2G内存了。但是从流畅度上来讲，iPhone的对手很少。
那么为什么我们要讲开放？要把网络设备做成Android手机那样的一个通用平台，软件给大家一起编？因为凡事都抗不过一个综合成本。一体化设计虽然最终产品的工作效率高，但是成本也高。一个公司就这么点人，扩展功能和需求响应都是很慢的。通用平台虽然工作效率低，但是因为批量化可以降低成本，可以通过“量”来弥补“质”的不足。就好像现在Android天生就比iPhone慢，那就靠提升硬件配置来追平对手。最后总成本还是比iPhone低，卖得还是比iPhone多。苹果电脑一开始用自己的PowerPC处理器，后来不也是换成了Intel。凡事没有绝对，在商业利益面前，技术还是矮一头的。
好，先不论孰优孰劣，总之就是，还是有很多人希望网络设备厂商出厂的设备一方面越来越傻，即自主的控制能力越来越弱，一方面又越来越灵活，即根据各种上层软件的指令可以对网络报文进行随心所欲的处理。拿QoS来说，就是希望，什么队列调度，什么优先级标记，网络设备都有很高效的芯片可以处理，可以保证报文的高速转发，唯独不知道的就是到底谁应该进什么队列，谁应该标记什么优先级。这个东西要靠大家编写的软件来告诉它。
以上就是SDN中关于什么叫做“软件定义网络”的一些个人理解。接下来，我们就来看看大家对SDN提得很多的“转发控制分离”。
2.2 转发与控制分离
事实上，从前面的阐述，大家已经可以看出来，“转发控制分离”不过是为了更好实现“软件定义网络”而采用的一种手段，顶多可以算一个充分条件，但肯定不是必要条件。
传统的网络设备的软件系统早就已经从稳定性和安全性的角度，将转发面、控制面和管理面三面进行分离。只不过原来是逻辑分离，代码本身还是跑在同一台设备上。现在SDN所强调的转发控制分离，不就是把以前网络设备中的控制面和管理面代码拿到控制器上去，同时将原来的设备内的主线通信改成了网络通信么？不仅没有本质区别，而且还降低了通信速率――网络通信会比板间通信更快么？
那么为什么还要这么做？还是从功能性的角度来考虑的。把控制面挪到控制器上之后，才能更好地对控制面进行扩展，才可以在集群服务器上实现更复杂的编程和更强大的计算。同时以前每个设备的控制器都是独立工作，路由是自己去计算，链路通断是自己去探测，现在挪到控制器上之后，就可以让全网可以更好地协同工作，实现更多的功能。理念就是牺牲单设备的工作效率，提升整网的工作效率。
那么这么做，真的可以达到我们想要的效果吗？在目前还没有一个非常理想的控制器产品出现的背景下，大家对控制器调控全网资源的“智力”还是存疑的。因此，基于技术和现实，旧网与新网的调和，现在控制器的模型也还存在好几种：
简单解释一下：
l 策略控制器模型保留了网络设备的基本能力，但是通过策略控制器来对大量网络设备的策略配置进行统一编排，从管理角度起到了简化网络运维的作用，同时还保留了传统网络的高效转发能力。相当于由控制器接管（或者两者并存）了网络设备的管理面的部分职能。是与传统网络融合最好的模型。该模型重点关注的是如何快速部署网络业务，而对于网络设备上诸如二层交换，三层转发等基本转发能力（例如MAC地址表，路由表）不做过多干预。
l 虚拟化模型是从网络虚拟化的角度出发，一方面保留了网络设备的基本转发能力，使得网络设备可以按照传统机制构建一个高效互联的物理网络，另一方面利用虚拟化技术在物理网络的基础上构建出所需的虚拟设备和虚拟网络。这个就有点像是BGP MPLS VPN了。BPG MPLS VPN在一个全互联的物理网络基础上，先将边界设备进行多实例化，再利用隧道技术快速建立边界设备上的实例间的多点到多点的逻辑链路，最终实现部分站点才可互联的虚拟网络的效果。只不过正如之前所说，这次的虚拟化做得更加彻底和完善。控制器要将每一台设备都进行多实例化，并且根据需要控制每个实例的配置与转发表项。这种全面的虚拟化在原来的纯手工配置的时代里是无法完成的，如果有一个超级强大的控制器这种虚拟化就会变得异常简单。
l SDN模型是对传统网络改造最大的模型。其完全剥夺了网络设备的转发“判断”能力，离了控制器，网络设备什么也干不了，既无法学习路由，也无法感知网络质量。而且实际网络的运行效率能运行到什么程度，关键看控制器的拓扑发现、链路质量识别、路由计算算法的设计与实现。总体来说，是个比较美好，但是实际实现风险很高的模型。
可以看出，前两种模型都没有或者只是部分实现了网络设备的转发面和控制面在物理实体上的分离，但是其实由于SDN的笼统定义，这几种模型都属于SDN讨论的范畴，它们都涉及到SDN的几个关键特征：需要对网络对象进行抽象化描述（只是抽象的维度和目的各不相同），网络设备的能力开放给更多的应用程序（只是开放的能力范围各不相同），存在一个统一的控制器（只是控制器接管的工作各不相同）等等。这进一步解释了为何“转发与控制分离”或者单纯的一种南向接口协议“Openflow”不能算是SDN的本质特征。即使转发与控制没有实现物理实体的分离，如果网络设备提供了足够强大的编程空间和计算能力，也就是被软件定义的能力，其实也仍然可以算是SDN。
这几种模型其实各有各的优势和适用场合，并不存在绝对的冲突，事实上也是可以相互融合使用的。这也敏捷网络的做法。
所以总结一下，怎么才算SDN了呢？符合以下一个或多个特征的网络都可以算作SDN网络：
l 对网络的抽象化，主要是指两个维度：
n 网络设备的部分软硬件元素（例如转发表项和接口电压）可以抽象为可编程对象，并可受上层软件操控。结合第二、三个特征，这里的上层软件通常是指独立于设备实体之外的统一管理平台及其加载的厂商自编或第三方编写的软件。
n 网络本身的抽象化和逻辑化。需要澄清的是这种虚拟化存在三种角度：NFV、Overlay、网络设备集群（多虚一）。目前大家普遍认为的，与SDN联系较为紧密的，是指“在一张物理网络基础上逻辑化出多张overlay的虚拟网络”这种角度。
l 网络设备能力的开放，有三种层次：
n 网络设备管理面的开放。即由控制器接管网络设备的配置。
n 网络设备控制面的开放。即由控制器接管网络设备的路由学习和转发表项计算。
n 控制器自身的开放。即控制器上的应用软件不仅可由网络设备厂商来编写，还可以由第三方应用程序供应商来编写，大家可以共同统一的南北向接口。
l 转发与控制分离：基于前两个特征，在网络设备实体之外独立存在一个全网统一的控制器，是实现前两种特征的最佳方案。
=====================================================================================================
3 敏捷网络究竟做了些什么？――敏捷网络各方案简介
我们从SDN的简单介绍里面其实已经提取到了很多有用的东西，既有理念层面，也有技术层面的。
理念层面的关键点包括“网络对象的抽象化”、“网络控制器”、“控制与转发分离”等等。具体技术层面我们有控制器向设备下发指导转发的流表的“Openflow”，和XMPP、Restful等一堆南北向接口协议。
那么回到敏捷网络的出发点“让网络快而灵活起来”，这些东西有一些是有助于实现这一目标。具体怎么帮助，后面会在对敏捷网络的一篇篇解析中娓娓道来。这里只举两个例子：
l 敏捷园区网络中的业务随行方案，就是借鉴了策略控制器模型，以及对象抽象化和网络虚拟化的思想，将参与网络通讯的终端抽象化为不同的逻辑组，通过管理逻辑组之间的策略来控制终端之间的互访，实现业务策略与网络物理拓扑、VLAN、IP的解耦。最终达到快速进行业务策略部署的目的。
l 敏捷园区网络中的SVF方案，就是借鉴了网络设备虚拟化的思想，将原本只有相同型号的交换机才可以虚拟化的堆叠技术发展成为了可以同时将核心、汇聚、接入三层交换机，全部虚拟为一台“超级交换机”的技术。相当于一整个园区网络最后变成了一台交换机，可想而知管理工作简化了多少。
在这些例子中，我们都是从管理员每天都要面对的实际问题出发，以解决客户需求为最终目标，借鉴已有的思想和技术，同时根据需求创造或发展必要的新技术。
在详细解析一个个解决具体问题的敏捷网络方案之前，我们先来系统地看一下，敏捷网络在SDN之下（硬件基础），SDN之中（Openflow兼容），和SDN之上（应用层方案）都做了什么。
3.1 SDN之下：ENP
SDN定义了一个“网络设备基于流表转发+应用程序控制流表”的模型，以解决网络设备非常关键但是同时也是非常小的一部分功能。
以往的网络设备也是基于各种表项来转发的，交换机需要将MAC地址转发表下发到ASIC芯片中，然后芯片就可以做到线速的转发。简单理解线速就是，有一个盒子，盒子里面提前把“水”槽挖好了，“水”从一端流入，自然而然地就沿着槽从指定的出口出来，流动的速率完全看“水”的速率。当然ASIC就是这个盒子，“水流”在这里就是“电流”，电流的速度那是杠杠的。ASIC本身具备一定的编程能力，但是可由软件自由修改的部分很少，尤其是商业套片。打个比方就是说，“目的MAC地址XX从接口YY发送出去”这句话里面，软件可以修改XX和YY，却修改不了这句话的结构，因为其已经固化在ASIC芯片里了。
那么线速转发的对应面是什么呢？就是CPU转发。大致的意思就是报文的部分或全部内容都要根据其含义拆分成一个一个数据节，然后根据算法将一个个数据节依次送到CPU里面去计算，最终得出这个报文应该向哪里发送，怎么发送的结论，然后再将报文重新组装好了发送出去。重组后的报文可能内容都一样，但是其实“太阳还是太阳，报文已经不是那个报文了”。这个速率显然会比ASIC的线速慢很多，但是其处理的灵活性基本达到了“万能”的地步，全看算法怎么编。
这两者就是效率与功能的两个极端。就像所有领域一样，这两者总是存在不可调和的矛盾。
既然SDN模型的基础其实也基于流表转发，那么SDN相比于以往的ASIC模型有什么本质改进？其实没有，SDN模型基本上是按照ASIC这个模式来的，即不改变设备按照流表转发的基本模型，但是SDN增强了流表计算的能力――目前大部分厂商的交换机都是ASIC的，这也是SDN的创造者的一种惯性思维。
这也就意味着，SDN确实可以在流量的具体表项计算上大做文章，但是一旦涉及到调整表项结构，比如增加表项匹配的报文字段、增加报文处理的动作、改变报文匹配的流程，就可能因为硬件芯片的不支持而导致无法快速落地到设备上。现在Openflow协议本身也是在不停地出新版本，实际上已经有出现过几次调整流表结构的情况了。
但是敏捷网络看来，一方面ASIC带来的高速转发能力是网络设备尤其是交换机不可或缺的部分，另一方面ASIC所带来的功能禁锢又是实现敏捷，实现软件定义网络中的一个大绊脚石。以往由客户需求或者协议成熟触发的ASIC芯片改造，通常周期长达数年甚至数十年。在这个一年倒闭几千个公司的时代，这种芯片改造的速度是跟不上软件发展的速度的。
同时，目前靠控制器来直接指导转发的生态系统并未成熟，冒然全面切换至Openflow很可能导致网络的基本业务都受到影响，而且还有很多基本转发能力之外的，目前正在海量设备上工作的产品特性，SDN并未给出任何解决方案。
因此继续用ASIC不行，全部换成SDN方案也不行，华为最终选择了自主创新：ENP芯片。
ENP芯片是一种效率和功能折中的底层硬件方案，它基于华为路由器已经成熟应用十几年的NP芯片，工作原理是ASIC和NP芯片的一个融合，其通过内置硬件加速组件、片内集成SmartMemory和高速查找算法，在保留了传统交换机ASIC成本、功耗、性能优势的同时，更具备灵活的全可编程能力。
ENP的可编程分成两个层次，即华为自己可编程和第三方可编程。传统采用ASIC芯片的交换机将所有功能都固化在芯片里，后期无法更改。而采用了ENP芯片的敏捷交换机具备了按需定制的能力。华为可以根据客户的业务变化去给客户定制行业需要的功能，第三方也可以利用华为在敏捷交换机上提供的API接口进行编程。
由于ENP芯片采用全可编程架构，通过微码编程实现新业务，客户无需更换新的硬件，六个月即可上线。而传统ASIC芯片采用固定的转发架构和转发流程，新业务无法快速部署，需要等待数年的硬件支持。
就拿业务随行中的“策略解耦”来说，最后实现时要求芯片先根据报文的源/目的IP去匹配一张由Controller动态维护的“IP-Group”映射表，得到的结果就是报文的源/目的组，然后再用源/目的组号去匹配管理员基于组配置的业务策略。原理其实很简单，就是把原来的ASIC的一次表项匹配改成了两次，但是ASIC就是做不到（ASIC哭诉：臣妾做不到哇～～）。
本人也不是芯片方面的专家，这里篇幅有限也不能深入介绍ENP是怎么做到的。反正blablabla一堆最后就是一个“好”字！谁叫是华为给咱发工资，给咱带来幸福生活呢。
通过ENP这个设计，其实我们可以看出，敏捷网络并没有全面放弃网络设备自身的智能，反而让网络设备自身的计算与报文改造能力更加强大和灵活。换句话说，敏捷网络虽然会上收一部分控制权到控制器上，但是同时也保留了一部分控制权给设备本身，并且这部分能力会比传统设备更加强大。相当于我们不仅可以拥有一个独立于网络设备之外的控制器，我们还拥有了一个集成在设备上的微型控制器。
所以，ENP并未阻挡SDN的落地，相反它是一个更加坚强的底层平台，它让SDN可以更快地落地。SDN能解决的，我们可以让SDN来解决，通过对独立控制器进行编程来解决，ENP可以更快地适应各种控制器南向接口协议和不同的转发模型；SDN暂时解决不了的，我们仍然可以通过对设备上的ENP芯片直接进行编程来解决。
下面，我们就来看敏捷网络对SDN的准备情况。
3.2 SDN之中：控制器以及一机双平面
诚如前面所讲，控制器也有很多种模型。敏捷网络目前有三大板块：敏捷园区、敏捷数据中心和敏捷分支。其中目前已经商用的敏捷园区控制器基本属于“策略控制器”这个模型，而敏捷分支和敏捷数据中心的控制器因为还在开发过程中，暂时不能透露太多小秘密。本期以及未来的几期都将先聚焦于敏捷园区方案。
首先简单解释一下为什么敏捷园区控制器没有做成经典SDN模型。
经典的SDN模型目前的关注点在流量转发的相关问题上，比如拓扑发现，路径调优，负载分担等等，其实最终目的都是为了让网络带宽得到更有效的利用，网络业务更少丢包、抖动和时延。这些问题在广域网里面比较突出。
在园区网络里面，由于高性能交换机和10G、40G光纤互联大量使用，园区带宽还是比较充裕的。同时园区的网络结构因为一般都是局域网，规模不是很大，路由域也很小，规划得比较好的园区网络都是简单清晰的树状结构，不存在错综复杂的广域网里面各种乱七八糟的路径和路由问题。因此，如果现在在园区网里面用经典的SDN模型，实在是有些杀鸡用牛刀的感觉。
然后我们再来看敏捷园区方案是准备如何兼容未来的“转发与控制分离”的SDN网络的。
采用ENP芯片之后，由于园区内的交换机保留了控制面的计算能力，同时又具备了更强的编程能力，因此可以实现“一机双平面”，即“一台物理设备，既支持传统路由转发，又支持Openflow流表转发”。华为可以用一张物理网络实现两张逻辑网络。一张逻辑网络运行原有的协议和业务；另外一张逻辑网络运行SDN，以便试验新业务。ENP交换机既支持现有网络的全部协议，又支持SDN协议。使用这样一机双平面的ENP交换机就可以构建一张支持平滑过渡到SDN的网络。
以上是网络设备这一侧，最后我们来看控制器一侧。网络设备的管理面的部分能力由控制器接管是必然的，这个是哪个模型都要做的事情。敏捷园区方案仍然采用的是一步一个脚印的策略，并未完全接管设备的管理配置界面，同时根据实际客户场景的需求，逐步上收部分功能的配置权。我们可以看到敏捷园区的一个一个版本中，控制器可配置的网络设备的能力是在一点一点增加和丰富的。同时，虽然目前已经商用的敏捷园区控制器并没有接管网络设备的控制平面，但是基于一机双平面这个硬件基础，敏捷园区控制器随时都有接管的能力。具体时机要看整个生态系统的成熟度和网络的实际需求，
这也就解答了客户关心的敏捷网络能不能平滑演进到SDN的问题。其实现在不是能不能的问题，而是需不需要的问题。总体而言，敏捷网络在涉及到SDN技术方面，已经属于Ready状态，而且是从芯片，协议支持，以及控制器三个方面都做了充分的准备。在此基础上，敏捷网络还从SDN的理念出发对网络进行了深入的扩展。
下面，我们就来看看都有哪些意外惊喜。
3.3 SDN之上：那些意外惊喜
前面已经提到，有一些现网已经运行的特性，并不能靠一个简单的流表可以替代。有一些客户的实际问题，也不能靠Openflow解决。我们使用了SDN的一些思想和技术，但是同时也不会受到SDN的束缚。因此，我们会在敏捷网络中看到很多貌似跟SDN没什么关系的方案。
这些方案基本上都是围绕网络安全和网络管理来展开的。如果硬要对应到TCP/IP五层架构里面去，这些方案都可算是工作在应用层的方案（SDN其实基本可以算是工作在链路层和网络层）。即这些方案通常都是建立在网络设备和终端之间已经通过各种方式（包括传统网络协议和SDN）实现了互联互通的基础上，目的不是为了改变报文的基本转发机制，而是对网络施加业务控制。我们可以称之为“SDN之上”的方案。
下面我们以敏捷园区方案为例，简单介绍一下目前已有的方案，每个方案的详细情况我们会在后续期目里为大家逐一道来：
l 关注于快速开局，精简网络拓扑管理的“有线无线深度融合方案”、“SVF方案”、“零配置开局方案”。
用一个词来总结这几个方案的目标的话，应该是“即插即用”。传统园区网络里面，交换机成百上千，WiFi普及后，AP又是成百上千，海量的接入设备如何安装、维护、管理成了管理员的心头事。在敏捷网络看来，要解决这些问题，应该从这几方面入手：
n 第一步，把冰箱门打开，让有线无线融合成一张网络
原来的有线网络中交换机之间是没有从属关系，要管也只能被网管管。还好传统园区拓扑固定，人员固定，接入位置固定，有线网络这种松散的管理模型还能勉力前行。
结果无线网络一出来，由于网络需要快速扩张，人员需要大范围移动，大家立马发现“胖AP”这种自己管自己的方式已经完全不可行了，于是就在无线网络中引入了AC这一角色。其实AC就有点像是SDN里面那个控制器，属于“策略控制器模型”，接管了AP的管理面。
由于AC的引入，无线网络和有线网络分道扬镳，各管各的，长久以往，问题也就出现了――企业员工才不管有线还是无线呢，在他们眼里，这就是一张网，认证的账号应该是一样的，相应的体验应该是一样的，自己还可以随时在有线无线中切换。于是管理员配啥都得配两套。
为了解决这个问题，敏捷园区在网络简化上的第一刀就是将交换机和AC进行了融合，也就是“有线无线深度融合方案”，也就是我们常说的“随板AC方案”。随板AC可不是传统的AC插卡。AC插卡只是比独立AC少了两根线，管理面还是独立的。敏捷园区真正做到了交换机和AC的管理面的合一。
n 第二步，让有线网络可以像无线网络一样集中管起来，实现海量接入交换机像AP一样即插即用。
“AC+瘦AP”模型所带来的好处是有目共睹的。最大的亮点是“AP完全没有配置工作量”。其实AP不是没有配置，而是配置都是由AC来下发的。能实现这一点的前提就是AP具有相似性。很多AP，其发布的SSID是一致的，绑定的VLAN是一致的，各种无线信号参数都是一致，那为啥要管理员在每台AP上面一遍一遍地配置，对吧？接入交换机难道不是这样吗？其实大量的接入交换机的配置基本都是趋同的。
有了这个现实基础，接下来就好办了。既然核心交换机已经与AC做了管理面的融合，那自然核心交换机也可以借鉴AC与AP之间的管理模式，对接入交换机进行自动识别，统一管理，批量配置，从而实现接入交换机的即插即用。
这就是敏捷园区的SVF方案，将核心、汇聚、接入三层交换机虚拟化为一台“超级交换机”，由核心交换机来对汇聚、接入交换机的配置进行统一管理。汇聚交换机变成不可见的通信通道，接入交换机变成核心交换机的虚拟接口卡。
n 第三步，实现自动开局。
通过前两个方案，园区网络的逻辑拓扑已经得到了尽可能的简化，接下来就要动刀的就是冗长乏味且极容易出错的开局阶段了。
目前对于大型园区，通常的自动化开局方法是：
\1. 由管理员为每台设备手工编制（通常是用记事本这个大杀器）开局配置文件。
\2. 管理员再到一台主控制设备（通常选用核心交换机）上配置每一台设备的MAC地址或ESN号与每一个开局文件的对应关系。
\3. 开局设备（接入或汇聚交换机）上电时通过DHCP的Option字段获取到主控制设备的地址，再从主控制设备获取到FTP服务器的地址和对应的配置文件的ID，最后到FTP服务器上自动获取开局配置文件，完成开局过程。
这其中“逐台设备手工编制开局配置文件”、“设备标示与配置文件一一映射”两个过程都存在不直观，繁琐，易出错的问题。
而且由于网规和安装通常是两批人负责，经常会出现设备安装位置出错的问题――即某台设备根据其标示获取到了配置文件，但是由于该设备的安装位置不是原计划的位置，例如本来应该安装到1楼设备间，结果安装到了2楼，导致其获得的配置不符合当前的实际位置。
敏捷园区网中的“零配置开局方案”通过“网管界面化绘制规划拓扑”、“根据规划拓扑生成配置文件”、“设备上电后自动感知实际拓扑”、“实际拓扑与规划拓扑一致性校验”、“网管根据设备所在位置自动下发对应配置文件”这几步改进了以上传统方案的问题，实现了完善的开局自动化。
l 关注于网络业务策略快速部署，简化网络策略管理的“智能应用控制方案”、“业务随行方案”。
这两个方案都致力于一方面增强网络设备的策略匹配能力（基于端口识别服务演进到基于流识别应用，基于IP执行策略演进到基于身份执行策略），另外一方面对传统网络的业务策略部署方式进行革新（实现业务策略与拓扑解耦无关、实现全网批量部署）。
由于下一期就要开始详细介绍业务随行方案，所以这里只简单说一下策略与拓扑解耦有什么好处。
传统网络设备上的策略都是基于“IP+端口”来配置，因为这两个元素被携带在报文中，沿途所有设备都可以识别。背后的逻辑其实就是“身份到IP进行一一映射”。也就是管理员一开始想的是“为XX部门配策略”，结合“XX部门使用YY网段”，才可以把策略配出来。
这种配法首先是绕了一个弯，是麻烦的，对于管理员记忆力和Excel的使用功力要求很高。更重要的是，它把“人限制在了网络里”，也就是为了管理员配置策略方便，人不能在不同的网段里面跑来跑去。这可真是天理难容。人怎么可以被网络限制呢。传统有线网中，人被网线捆住，所以这个问题还不显眼，随着WiFi、远程VPN技术的大力发展，这个问题越来越突出。所以我们希望策略与拓扑无关，其实就是希望策略与VLAN无关、与IP无关、与接入位置无关，从而实现人在网络中的真正“自由连接”。
以往也有一些网络设备可以基于“用户”来做策略，但是前提都是人需要在这个设备上认证成为“本地接入用户”。显然如果我们希望全网设备都可以基于身份做策略，是不可能要求人在每一台设备都做认证的。业务随行实现了身份信息的全网统一，所以全路径上的设备都可以基于流量的身份做策略。从用户角度看来，就是不管用户从哪里接入，用什么IP地址，都可以在网络中享受一致的权限和体验。这就是业务随行方案。
l 关注于网络质量感知，故障快速定位的“质量感知方案”。
局也开完了，策略也部署完了，网络终于轰轰烈烈地上线了，让我们红尘作伴，活得潇潇洒洒，策马奔腾，哦，No，马掉沟里了――网络在运维阶段出故障了怎么办？
以前诊断网络故障不仅是一门技术活，还是一门体力活。通常来说，诊断通断问题要靠管理员从一端PC上一个路由器一个路由器地Ping，Ping到哪里不通了就是哪里出错了。好吧，Tracert也蛮好用的。知道哪里出错了，再去断的设备上看接口状态，看配置等等。但是有时IP通断还是跟ICMP报文通断不能完全等同的，有些设备上的包过滤就是配置成ICMP允许通过，IP报文阻断的，这时就定位不出来了。
比配置问题导致的业务通断更头疼的是偶发的丢包。来无影去无踪，大家只知道打个电话断断续续的，管理员根本找不到丢包的设备。就算找到了设备，业务也可能早已已经恢复了正常，完全看不出来问题在哪了。实际有可能是接口接触不良，网络浪涌导致的拥塞，线缆老化导致信号质量变差等等各种各样稀奇古怪的原因。
之所以会存在这些“维护难”的问题都是因为传统网络质量的检测技术都是“事后的”、“模拟的”，案发现场无法还原导致丢包案件无法侦破。而敏捷园区的质量感知方案想要实现的就是“随流检测，实时检测”，具体方法是统计一条或多条流量经过的路径上每一台设备上的报文收***况，一旦出现丢包的情况，网管马上就可以感知到，而且立刻就能定位是哪条链路，哪台设备，甚至是哪块单板发生了丢包，丢了多少包。这样前面所提到的问题就能迎刃而解，实现真正的网络质量可感知。具体实现原理还是非常复杂和高大上的，这里先不深入展开。
l 关注于利用大数据分析进行网络安全防护的“安全协防方案”。
网络的基本业务开展顺利了，接下来就要操心网络安全的问题。
登为一个童话世界的毁灭踏上了最后一脚，大家发现原来不只是非法的黑客可能会对网络进行攻击，就连合法的也在大行其肆――人心险恶，不能不防啊。
传统网络安全技术通常结晶为某一种网络安全设备，最著名的就是防火墙，其他的还有IPS、IDS、AV、Anti-DDoS等等各种安全设备，导致很多人在针对一个园区网络做安全设计的时候就简单理解为解决“网络安全设备的摆放”问题。但是实际上网络安全是一个系统工程，牵扯到制度、架构、技术、设备等等方方面面。单台安全设备确实被证实在某些安全问题防护上是卓有成效的。但是也仍然有一些隐形或未知攻击是单台设备很难甚至无法发现的。所以最近APT（Advanced Persistent Threat，高级持续性威）这个词也很火热，有兴趣的童鞋可以问下度娘。
高级的系统化的入侵或攻击方法自然也需要系统化的防御方法。在互联网领域风生水起的大数据分析在网络安全领域同样可以如鱼得水。事实上，在战争时期，靠人工进行海量信息的收集、汇总、分析、预测，从而防御敌人的进攻已经有了数不胜数的成功案例，积累了大量宝贵经验。目前市场已经已有许多SOC（Security Operations Center）系统，就是基于这个想法，通过收集网络终端、服务器、网络设备以及各种软件上报的事件与日志进行大数据分析，进而发现潜在的安全威胁。而由于传统SOC系统与网络本身的脱节，导致SOC系统目前通常只能工作成一个告警系统，即只能完成安全威胁的检测，不能完成防御。敏捷园区网方案基于SDN中的网络能力开放理念，尝试将网络的部分控制能力开放给这些SOC系统。一方面敏捷园区控制器可以提供给SOC系统更多无法从单台设备获取的信息，另一方面SOC可以通过与敏捷园区控制器进行联动完成攻击的实时阻断或限制，从而使得SOC系统的检测能力和网络的防御能力完整结合在一起，形成“检测―分析―联动―防御―继续检测直至防御撤销”的闭环系统。
通过以上简单介绍，我们可以看到敏捷网络的出发点不是仅仅为了落地一个Openflow或者一个控制器，而是为了解决我们所找到的一系列影响网络部署、运行、管理效率的问题。从下一期开始，我们就将从目前已经商用的这些方案开始，逐渐揭开敏捷网络的神秘面纱，前方高能预警，敬请期待。
=========================================================================================================================
原文链接：https://forum.huawei.com/enterprise/zh/thread-294425.html
- 本文链接：https://zeozzz.github.com/2019/05/29/55/
- 版权声明：本博客所有文章除特别声明外，均默认采用 许可协议。