从某位大牛的微博上看到了对opencontrail的评价，引起了我的兴趣，点开有人为其翻译的中文文档学习了下，把之前一些零碎的东西，比较系统性地串起来了，感觉很爽，所以决定把src下下来八一八。
下载了contrail-vrouter的代码，因为刚好在做底层类似的东西，可以对比学习下，contrail-controller的代码，暂时没时间研究了，留着闲了再说。
1. 先从数据结构上分析， 它里面都是基于vr_packet来做，对于linux而言就是在skb->cb里面存了一个结构，并把skb->head等信息存进去，后面所以的处理都是基于packet，最后发送的时候再转成skb，跟我们的想法类似，我们直接就define skb xxxx，这样就很好滴解决网络包结构异构的问题。
2. 有比较完整的库，从写法上来看，是做了很多库封装的事情，跨各种平台(freebsd)，各种协议(mpls,vxlan,gre)，有点dpdk的感觉， 包括里面也自己对于内存分配进行了管理
3. 在dataplane上的一些处理，跟ovs类似，有flowtable，action，并且也是从用户态下发action。
4. 整个dataplane做的非常灵活，完全是基于决策来做事情的，比如所action= hold， 那么用户会把flow enqueue进去，等到用户态一个命令下来，就会flush flow，这样可以用在action invalid的时候，先hold再更新保证事务，还有arp的请求，可以用户配置成proxy模式，这样就会自动进行回复，还有下一条设置成mpls, vxlan等各种类型，这样包可以随时在mpls或者vxlan之间进行网络切换，可以用于网络的升级，正好可以解决我们现在面对的网络架构升级问题。
5. 代码主要分为几层，第一层host，这里面首先是一些通用的host上的操作(vr_host_interface_ops)，具体的方法是调用freebsd和linux里面的实现，剩下的逻辑就是包在host上的处理，如把包从udp socket上收上来，传给dataplane（入口为vif_rx）， 或者把内层包从udp socket发出去了。第二层就是dataplane，里面就是内层包的处理逻辑，根据nexthop，解封相应的隧道头，并把包发给相应的interface处理。 这里的nexthop的结构相比linux
kernel要复杂很多，包括了各种flag, tunnel type 还有arp proxy，里面ip forward的查找是基于4层lpm计算的，arp的逻辑主要在vr_get_proxy_mac
6. 针对linux bridge， host上面的hook点在br_handle_frame_hook， openvswitch_handle_frame_hook，看来大家都想到一块去了。
7. 由于它有个做决策的用户态进程，所以复杂的业务逻辑都可以转交给上层进行解析处理，并下发决策，目前看它支持的trap类型有AGENT_TRAP_FLOW_MISS， AGENT_TRAP_ECMP_RESOLVE， AGENT_TRAP_SOURCE_MISMATCH，AGENT_TRAP_DIAG，AGENT_TRAP_HANDLE_DF，AGENT_TRAP_ARP
8. 它里面支持mirror，这个功能对于线上排查问题来说，非常好用啊。
收包路劲的分析
1.. 先从vm的入包流程分析，host.hif_udp_rx -> vm_rx->vr_virtual_input->先查表，vr_flow_forward 如果失败则 vr_bridge_input ->nh_output->nh_l2_rcv->如果是arp的包，vr_arp_input， ip的包则vr_l3_input
2.. 如果是arp的请求包，配置了arp proxy则构造一个reply包，用proxy的mac进行回复，又重新调用vr_bridge_input发送出去，如果是xconnect， 则调用bridge的vif tx发送，最终发给vm。
3.. 如果是arp的响应包，从外面收到的arp reply，先xconnected，通过bridge的vif tx发送到vm，并且必须trap到用户态的agent
4. 如果是ipv4包的话，vr_ip_input->先进行vr_flow_forward，如果失败则vr_forward->vr_inet_route_lookup 进行路由查找，找到下一跳和下一跳的dev，调用nh_output，把包发给相应的vm的收包函数
关于发包路径，及 multicast, ecmp, ipfragment, flow entry的细节还待研究