從某位大牛的微博上看到了對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的細節還待研究