一线工程师告诉你：我们需要什么样的SDN

面对现实吧，离我们真正大规模采购SDN技术还有很长一段路要走。在Reddit的讨论帖子中，网络工程师要求停止如此糟糕的市场推销手法，他们告诉供应商他们的真实SDN需求。

我们邀请技术撰稿人David Geer在Reddit上找一些网络工程师来讨论一些为什么他们还不准备采购SDN技术。我们得到的信息是Reddit风格的尖锐评论--充满关于网络工程师真正想从SDN获得什么的质问。

来自Reddit的声音：网络人员对SDN说"不"

Geer首先提出了下面这个问题：

"现在SDN已经在真正产品化，在认真考虑试用SDN之前，大型企业(非巨头公司)的常规网络工程师、网络经理和管理员在未来1-2年里需要从SDN获得什么?"

第一个答复似乎来自一个正在忙于工作(实际上不是)的网络工程师：

"它需要协同和整合更多云选项，还要有一个能够通过运用协同策略而自我修复和持续优化性能的动态基础架构。这样才能通过绑定坚实质量承诺来提升企业竞争力。"

这番话让Reddit上非常个性的网络工程师争论激烈。

一位工程师回复说："只要我一看到协同这个词，我马上就知道这篇文章的其他内容都是垃圾。"

这话让我看着很想笑。更有意思的是最后还有下面这样的话：

工程师们希望SDN能降低他们的基础架构成本--但是这可能吗?后面真有这样的回复：

"我需要SDN来降低硬件价格。除此之外，其他方面对我没什么用处。"

另一位工程师认同这种说法：

"降低设备价格，同时还要让我的分配系统更干净和更便宜。"

当然，肯定有供应商出来回应(但是至少他说的是实话)：

"你希望的价格是什么?你看过白盒交换机吗?我来自Cumulus，所以我偏好白盒设备，但是如果你购买了白盒设备，你就可以像服务器一样给它安装多个操作系统。"

而我们的记者想了解更多关于通过SDN提高网络成本效益的信息。

"你意思是，由于可以使用任意硬件，所以就可以使供应商为你的业务展开竞争?这就是你希望SDN降低硬件价格的方式?或者说，你的意思是降低支持费用?"

后来Cumulus又有一个回复：

"Cumulus Networks提供了SDN方法(堆叠、网络虚拟化和自动化)。我们是谷歌风格数据中心的支撑和支持结构;对于企业而言，我们是‘支撑’和物理交换机。"

SDN并不是新事物，而且工程师一样喜欢传统网络。

最后，有一位工程师加入交流，他的观点与很多SDN支持者不同--他更喜欢传统网络技术。

"SDN这个术语已经被整个行业所滥用，实际上很多人并不是在说SDN，而更多是在说某某供应商已经在实现SDN，因为他们宣称自己的设备管理API是支持SDN的。对于这种现象，我倒是一个赶时髦的网络工程师，因为早在SDN流行并我已经在实现SDN了(编写根据自身需要去管理网络设备配置的库和工具)。你可能会想，‘但是你可以自己用软件来开发协议和控制流量。’我确实不担心这个问题。大多数网络工程师也一样不担心这个问题。现有协议更好、更快，我并没有遇到什么流量流问题需要用SDN来解决。到现在，大多数说SDN的人最后都是一些系统管理员，他们认为自己找到新方法是一个20多年来一直没有搞懂的协议。"

我们真正需要的是配置管理和映射!

许多人认为，SDN最后就是自动化和管理，而有一位工程师希望了解更多这方面的信息：

"我有一个问题。SDN是否支持自动化生成网络图?这是我在未来1-2年里最关心的问题。"

但是，他得到的回复并不乐观。

"LLDP(链路层发现协议)可以支持，但是它并不复杂。"

接下来的响应者对于SDN一点也不感冒：

"不行，肯定不行。你可以自动化生成网络图，但是它们就是一堆垃圾。LLDP也没办法帮你生成有用的网络图。"

另一位工程师的观点倒是带来一些希望：

"确实不行--但是，只要思路正确，我们(网络工程师)就应该能够得到一致的文档和配置。其中一些与SDN有关--如它将网络视为网络，而不是一系列构成网络的孤立设备。"

最后，有人提出了一个非常有意思但又非常真实反映SDN的观点：

"我还没有那么丰富的阅历，无法在短时间里给出一个更聪明的观点(再来20年不算多)--所以，我来说一个大实话：自动分配。通过简单的点击操作来控制网络端的分配操作。另外还有CPE(客户现场设备)/PE(供应商边界)/NID(网络接口设备)等设备的自动分配。这个业务案例就是降低运营成本，因为它可以减少完成这些工作的网络人员。"

然后，有另一位工程师提出了关于管理、交换和成本效益的观点：

"我想要的是所有位置的NetFlow。我讨厌SNMP，而且缺少一个100% CDP的环境。我一定是被思科庞坏了。"

我很满意大多数3层交换机的价格/性能，但是接