一、SDN交换机机器选型
包转发率以能够处理最小包长来衡量，对于以太网来说最小包为64bytes，加上帧开销20bytes(8byte的前导字节以及12byte的帧间间隙)，最小包是84bytes [3] 。
计算方法如下：
对于一个全双工千兆接口达到线速时要求：包转发率=1000mbps/(84*8)=1.488mpps.
同理，全双工万兆接口达到线速时要求包转发率为14.488mpps。
交换机的交换容量又称为 背板带宽 或 交换带宽 ，是交换机接口处理器或接口卡和数据总线间所能吞吐的 最大数据量 。交换容量表明了交换机总的数据交换能力，单位为gbps。一台交换机的交换容量越高，所能处理数据的能力就越强，但同时设计成本也会越高 [1] 。
我们在购买交换机时希望交换机能达到最佳性能，即要求交换机做到做到线性无阻塞传输。那么我们就要判断待买交换机是否存在阻塞的结构设计 [2] ：
英文简称etherchannel(以太通道)，是由cisco研发的，应用于交换机之间的多链路捆绑技术。它的基本原理是：
一般情况下，交换机厂商都会在这一栏写支持 802.3x流控 。
在全双工环境中，服务器和交换机之间的连接是一种无碰撞（csma/cd机制）的发送和接收通道。由于没有碰撞检测，且不允许交换机通过产生一次冲突而使得服务器停止发送，那么服务器将一直发送到交换机的帧缓冲器溢出。
因此，ieee 802.3x 规定了一种64字节的“pause”mac控制帧的格式。当端口发生阻塞时，交换机向信息源发送 “pause”帧，告诉信息源暂停一段时间再发送信息。
在实际的网络中，尤其是一般局域网，产生网络拥塞的情况极少，所以有的厂家的交换机并不支持流量控制。高性能的交换机应该支持后退压力算法和ieee802.3x流控 [5] 。
综上所述 ：一般对sdn交换机数据接口的传输速率要求较高，所以在购买openflow交换机时，希望待买交换机支持 802.3x流控 。
简单来说，就是大量的广播/单播/组播报文在一瞬间涌向交换机端口时，为了防止交换机的cpu利用率过高，风暴抑制使用阈值的上升和下降参数来控制广播风暴 [6] 。
默认情况下，风暴抑制被禁用。
“巨型帧”
一些网络设备的新型厂商大胆的吧以太网的最大帧长扩展到9k，加大帧长的好处在于，减少了网络中数据包的个数，减轻了网络设备处理包头的额外开销。这是一种厂商标准的超长帧格式，专门为千兆以太网设计，目前还没有获得ieee标准委员会的认可 [7] 。
综上所述 ，这个功能支不支持看购买者的需求。
qsfp可以作为一种光纤解决方案，并且速度和密度均优于4通道cx4接口。由于可在 xfp 相同的端口体积下以每通道10gbps的速度支持四个通道的数据传输，所以qsfp的密度可以达到xfp产品的4倍， sfp+ 产品的3倍。具有4通道且密度比cx4高的qsfp接口已经被infiniband标准所采用 [8] 。
路由策略是根据一些规则，使用某种策略改变规则中/影响路由发布、接收或 路由选择 /的参数而改变路由发现的结果，最终改变的是路由表的内容。是在路由发现的时候产生作用。
策略路由是尽管存在当前最优的路由，但是针对某些特别的主机(或应用、协议)不使用当前路由表中的转发路径而单独使用别的转发路径。在数据包转发的时候发生作用、不改变路由表中任何内容。
策略路由的优先级比路由策略高，当路由器接收到数据包，并进行转发的时候，会优先根据策略路由的规则进行匹配，如果能匹配上，则根据策略路由来转发，否则按照路由表中转发路径来进行转发。
，路由策略是路由发现规则，策略路由是数据包转发规则。其实将“策略路由”理解为“转发策略”，这样更容易理解与区分。由于转发在底层，路由在高层，所以转发的优先级比路由的优先级高，这点也能理解的通。
其实路由器中存在两种类型和层次的表，一个是路由表(routing-table)，另一个是转发表(forwording-table)。转发表是由路由表映射过来的，策略路由直接作用于转发表，路由策略直接作用于路由表。
最终建议：
其实主要考虑的还是端口速率和端口数目。对于sdn交换机的购买还需要着重考虑交换机所支持的南向协议的种类。目前市面上可购买到的交换机，一般都支持openflow和netconf这两种典型的南向协议。
[1] 路由器，整机交换容量:80gbps是什么概念?
[2] 交换机的背板容量、交换容量和包转发能力有何区别？
[3] 交换机背板带宽、交换容量、包转发率和线速转发的含义
[4] cisco交换机端口聚合(etherchannel)
[5] 交换机流量控制原理
[6] cisco交换机风暴控制
[7] jumbo frame介绍
[8] qspf百度百科
[9] 路由策略和策略路由的区别
二、SD-WAN究竟是怎么回事
最近sd-wan在业界炙手可热，越来越多的企业客户准备或已经上马sd-wan。在此风生水起之际，各式各样的sd-wan供应商自然轮番出招、应接不暇。在深入接触了一些国外主流商用sd-wan厂家的技术方案后，希望能对这些主流商用sd-wan方案中所采用的最根本的sdn特性进行一些分析，供大家讨论。
说实话，在深入了解业界主流商用sd-wan之前，对sd-wan名字中software defined的认知更多的停留在传统sdn所强调的控制面和转发面分离的模糊概念上。笔者曾先入为主的以为sd-wan中采用的转控分离就是沿袭学术界sdn的经典套路，采用类似google基于openflow构建的横跨全球数据中心的b4 sd-wan的思路－－毕竟google的b4 wan是 sd-wan的鼻祖啊。
然而在初步接触了几大商用sd-wan厂商的技术方案之后，笔者骤然有种被欺骗的感觉：这些sd-wan解决方案中所谓的“sdncontroller”其实就相当于一个大家已经使用了快20年的bgp routereflector,和 sdn没什么关系。这完全颠覆了笔者的世界观，令我非常的失望和不安。
但随着进一步的深入了解，笔者发现这些所谓的“sdn controller”和传统的bgp route reflector虽有神似，实则不同。具体说来，这些冒牌的"sdn controller"虽然没有像学术界或google b4 sd-wan所使用的sdn controller中转控分离做的那么理想和纯粹，但确实也继承了sdn的一些神韵。如此一来，sd-wan的名字也算差强人意。下面就请听我慢慢道来:
首先我们来讲讲主流商用sd-wan方案中这些所谓的"sdn controller"和传统的 bgp route reflector究竟有多么的相似。我们借用全球sd-wan top 2厂商 viptela的一张系统架构图（图一）来解释一下。(注：目前viptela和 velocloud谁是sd-wan市场老大还存在争议，但他们两个以及绝大多数sd-wan厂商的系统架构都非常类似。另外有趣的是，这两个top 2 vendors最近分别被cisco和vmware收购了,可见这个市场的热度,竞争的激烈,以及日趋饱和)。
图一：viptela sd-wan系统架构
在图一中，vsmart controller就是viptela所谓的 “sdn controller”，用来负责与用户各个站点的cpe设备（图中的vedgerouters）进行通信从而交换用户各个站点之间的路由信息。所以从控制平面来看，各站点的cpe设备彼此之间不再交换路由信息，而是统一发送给中心控制器。之后再由中心控制器将路由信息传递给其他的cpe设备。这种集中控制的思想正是sdn的精髓所在。然而如果仔细来看这些cpe设备与中心控制器之间是如何来交换路由信息的话，我们发现目前主流sd-wan厂商都是采用基于bgp协议的路由交换 。bgp?是的，您没有看错，正是那仙福永享，寿与天齐的bgp，而不是因为sdn炒的火热的新贵小开openflow（注：通常sd-wan厂商都会在bgp的基础上做些改动和扩展，比如viptela将改动后的bgp协议称为overlaymanagement protocol (omp),具体细节可以参见他们为omp申请的专利： https://www.google.com/patents/us9467478 。）
看到这里，各位看官可能会有这样的疑惑：如果cpe设备和中心控制器都是基于bgp的路由交换，那么这和传统的bgp route reflector有什么区别呢？（注：这里附上一个传统的bgp route reflector的架构图供您参考，其中心思想就是各个bgp router之间不再建立网状的bgp session来交换路由，而是统一发给中心的bgp route reflector ，再由他传递给其他所有的bgprouters。可见其与sd-wan里的sdn controller多么的相似）
图二：传统的bgp route reflector架构
bgp route reflector早就有了，比今天大家热炒的sdn早了快20年。这些主流sd-wan厂商所采用的技术真的算是sdn吗，还是挂羊头卖狗肉，新瓶装旧酒？
这种疑惑伴随着笔者许久，直到笔者仔细研究了这些sd-wan厂商对bgp协议的改动和扩展，以及这些解决方案中对集中式policy的强调和使用，才发现sd-wan里的sdn controller大大超出了传统bgp route reflector的能力范围。下面是笔者总结的所谓的sdn controller与传统bgp route reflector的几个主要区别：
1.目标的不同
传统的bgp route reflector主要是为了解决ibgp网络里对bgp router之间需要full mesh互联的问题。bgp route reflector可以有效的将所需的bgp session的总量从full mesh时的n^2的数量级降低到hub-spoke时的n的数量级。这对减少超大规模的bgp网络的复杂度非常重要。
而反观 sd-wan里的 sdn controller,它最主要的目的是提供一个集中管理和配置overlay网络的工具。同时sdn controller除了提供以hub-spoke方式的路由交换，还提供了简化的安全密钥交换（用于数据平面cpe设备之间ipsec隧道的建立），中心化的policy控制，以及vpn标签的分配，等等。所以sd-wan中的sdn controller的目标和功能远远超出了传统bgp route reflector单纯的路由交换。
2.路由传递实现方式的不同
传统的bgp route reflector在交换路由时，只是简单的将从一个cpe router处收到的路由信息原封不动的“反射”给其他所有的cpe routers,这也正是route reflector (路由反射)名字的由来。
然而 sd-wan里的sdn controller在收到从一个cpe router发出的路由信息之后，在sdn controller做了很多的计算和处理，然后才将过滤和处理后的路由信息发给相应的cpe routers (注意不一定是其它所有的cpe routers)。通常sdn controller所做的处理包括：根据用户定义的policy来修改路由的参数，综合所有已收到的路由信息计算出到达任何用户子网的最佳路由，将上面计算出的最佳路由信息发送给某些特定的cpe routers(具体由用户policy决定)。从这里我们再次可以看到 sd-wan里的sdncontroller比传统的bgp routereflector要复杂得多，功能也要强大的多。
当然除了以上总结的两点主要区别以外，他们之间还有其它一些小的区别，比如路由所携带的参数信息，最佳路由的算法等，此处不再展开。
如果您能坚持看到这里还没有睡着或者改刷朋友圈的话，那么恭喜您！－您已经掌握了目前市场上主流sd-wan厂商所使用的最核心的路由技术及其与sdn这个大帽子的真正关系。当然sd-wan不仅仅是sdn，我们今天所讨论的路由技术也只是sd-wan所使用的众多技术中的一个。虽然笔者认为如何在overlay层面构建路由是sd-wan最核心的关键技术，然而我们不得不承认sd-wan在overlay路由基础之上所提供的多种多样的功能和服务（比如application aware routing,集中化和界面化的policy control, zero touch provisioning (ztp), vpn和 segmentation ）才是sd-wan真正吸引客户的地方。关于sd-wan那些琳琅满目，吸引客户争先恐后掏出荷包的功能，我们下次再专门找个机会聊一聊。
------摘自 sd-wan究竟是怎么回事
如有违规，请及时通知并删除
三、sdn发展历程
sdn发展历程
sdn（软件定义网络）的发展历程可以追溯到上世纪90年代，当时网络设备的配置和管理主要通过命令行接口（cli）实现，网络的灵活性和可扩展性受到限制。随着互联网和云计算的兴起，传统的网络架构和管理方式已无法满足日益增长的网络需求。
进入21世纪后，网络虚拟化技术的出现为sdn的诞生奠定了基础。网络虚拟化技术允许在一套物理网络设备上创建多个虚拟网络，每个虚拟网络可以独立配置和管理，从而提高了网络的灵活性和资源利用率。同时，openflow等开源协议的出现使得网络设备可以通过编程接口进行控制，进一步推动了sdn的发展。
近年来，sdn已成为网络领域的研究热点，各大厂商和组织纷纷推出自己的sdn解决方案。例如，onf（开放网络基金会）推出的openflow协议已成为sdn领域的事实标准，许多网络设备厂商如cisco、juniper等都支持openflow协议。此外，onos、floodlight等开源sdn控制器的出现也为sdn的普及和应用提供了有力支持。
总的来说，sdn的发展历程经历了从命令行接口到网络虚拟化，再到基于编程接口的控制平面的演进过程。在这个过程中，openflow等开源协议和开源sdn控制器的出现起到了关键作用。随着sdn技术的不断成熟和应用的不断拓展，未来sdn将在云计算、数据中心、5g等领域发挥更大的作用。
