时间就到了2016年。因为公司的项目稍微涉及到了一些OpenStack的内容，所以又找了一些资料来看。只是安装网络节点/控制节点/计算节点，就花了很多的时间。其实如果本身项目的文档写得很完善，官方文档肯定是最主要的参考资料。当然，安装的过程中一定会遇到形形色色的问题，甚至有的问题重装一遍就莫名其妙地不在了，适应就好。另外还要狠狠地吐槽一下百度，能搜到的有参考意义的文档实在有限，还好有谷歌。总的来说，如果所有的功能尤其是网络通信都虚拟化了，其实也就没有我们交换机什么事情了。好在找到了overlay封装和解封装，软件处理速度一般来说没有ASIC处理快这个点，成为我们宣传的一大亮点。
做了快一年的SDN/OpenFlow，有一点要被洗脑的感觉。觉得传统的路由交换都不如SDN高大上。虽然知道有“首包上controller”，流表条目数等诸多限制，还是很坚持这一点，直到接触到Atrium这个project。
Atrium本质上就是一个controller配合Quagga来使用。Quagga负责和外部的设备做BGP协议交互，然后将相关信息通告给控制器，翻译成流表形式下发到交换机，从而实现两边的主机通信。确实，完全没有必要把BGP的协议栈移植到controller上，而可以把开源的Quagga拿来直接集成。毕竟目前大部分网络还是基于传统的路由协议，SDN化是一个过程，期间肯定还要又互联互通的需求，这可能也是Atrium这个项目的初衷。
我们上一代交换机，曾经提交过适配的driver。可是Atrium的版本演化到16版本，处理流程发生了很大的变化。尤其是我们新一代交换机需要重新编写适配的driver。调用指定的driver，这个很简单，修改一下onos-driver.xml就好。而driver文件，是用Java写的。作为没用过Java的人，刚接下这个事情，还是心里没底。好在Atrium提供了一份softer-switch的driver，可以用来参考。而且它本身用到的语法也并不复杂。经历过多次修改-编译-再修改-再编译之后，终于流表下发正确，主机可以通信了！那一刻，真的非常非常地开心！
在验证自己家产品之余，肯定还是要关注行业内其它厂商的设备。后来发现P家的交换机porting OVS非常彻底，而且支持hybrid，就抱着试试看的想法向公司打了申请。真的没想到批下来了，一周后，亲手把刚采购的P上了机架。接下来一周多的时间，就是查文档，实际操作，遇到问题骚扰P的客服小哥(后来可能是被我烦的都不怎么回复了……)。既有被P的一些亮点折服，也发现了P的一些问题。
比较是一种很好的学习方法。有句话说：“没有比较就没有伤害”。我更推崇的是“没有比较就没有进步”。就像研究生的时候“拼凑论文”，如果你只拿这别人写得一篇论文来看，你一定是抄袭的。如果你拿来了十篇论文来参考，总归能比较出一些优劣，看出一些行业的共性和趋势。套用到现在的工作中，整天搞自己的一套，渐渐思路就会被束缚。而通过和其它友商产品的比较，才能找出不足，也能坚定对自己产品的信心。
除了完善内部产品测试流程之外，在积累了一些和各种控制器互通的经验后，我又主动开始编写一份相关文档，就是将交换机和Ryu/ONOS/OpenDaylight如何互通，如何通过WebUI/CLI/REST操作flow/group/meter的步骤记录下来，甚至放了很多的截图上去。写完后不久，就开始有很多客户陆陆续续来询问相关的问题。把这个文档先丢过去，节省了我们很多support的时间和精力。这些不光是个人的积累，对于公司来说也是有意义的事情。
