純用戶態的DN42節點(Part 1)

 前文提到的東西,第一部分終於完成了

也就是memif+tap2tun的部分

tap2tun的部分邏輯很簡單,如下

tap部分邏輯

收到一個封包
if 是ARP request:
    回復一個ARP response
    加入ARP Table
elif 是Neighbor solicitation :
    回覆一個Neighbor advertisement
    加入Neighbor Table
elif 是ARP reply:
加入ARP Table elif 是Neighbor advertisement: 加入Neighbor Table else: 拔掉L2丟去tun對面

tun的部分更簡單

收到一個封包
去ARP/Neighbor Table查表
if 查表成功:
    目標Mac=查表結果
elif 需要查表(預先定義了一個要查表的範圍,通常是設定成l2內網範圍):
    發送一個ARP request/Neighbor solicitation到tap端
    丟棄該封包,返回
else:
    目標Mac=Gateway Mac Address
補上l2包頭,發送到tap端



幾經波折,終於完成第一部分。把wireguard-go的tun的 CreateTun/Read/Write 改掉,變成用libmemif+vpp-api和vpp互動



以上指定都是用普通用戶身分在userspace執行,亦不需要kernel的tun/tap支援

成功在vpp裡面ping通對端電腦

對端電腦也成功收到來自vpp的封包

完成了第一部分,至於心得嘛...
govpp根本不是一個可以正常用的package,還得幫他們debug。想用的建議直接改用C++,詳情請看issue 20~22
雖然都是一些小修正,但是又不是很少用的功能出錯。而是example裡面提供的程式碼,也就是最基礎的功能都無法正常運作! 讓人不禁想抱怨一下

有興趣的人可以去這邊下載,原始碼: https://github.com/KusakabeSi/wireguard-go-vpp

至於第2部分,bgp daemon了。目前也沒有任何一個bgp daemon直接支援vpp的
現在想到2個做法

1: 弄一個程式解析Zebra Protocol,然後把路由資訊vpp-api丟給VPP
  • 優點
    1. : FRRouting/Quagga是十分強大的routing daemon,他們都用Zebra Protocol。這部分就不重複造輪子。未來想搞babel/ospf都能直接用,也能用上各種強大的FRRouting的功能
  • 缺點
    1. Zebra Protocol有110個。我肯定是不想全部實現。頂多ZEBRA_IP_PREFIX_ROUTE_ADD/DEL這2個,再弄到讓FRRouting能動
    2. 要實現上面這點,肯定又是各種FRRouting的程式碼閱讀了... 這麼個大東西實在不想讀
    3. Zebra Protocol有110個就算了,重點是還找不到他們的文檔! 我找到的這個list只有函數名,定義作用返回值通通沒有。看到這個我直接放棄,下一位

2: exabgp ,收到的路由用 python3-vpp-api 丟給VPP
  •  優點: 程式小,又是python寫的,易讀易debug
  •  缺點: FRRouting裡面的各種強大功能(ROA/RPKI)肯定是要用python重新實現了

最後因為方法1有3個缺點,所以我決定用方法2了。FRRouting強大的功能是甚麼?反正我也不一定用的到,先能動再說

留言