Wireguard + Babeld 內網搭建

玩DN42，igp有很多方案。

使用L2 VPN，鏈路層和igp綁定在一起。由VPN軟體來負責選路
我是使用etherguard搭建內網，由etherguard負責選路。
這樣的話，igp和etherguard綁在一起了。我一直以來都這樣用

還有一種方案，鏈路層和內網路由分開，鏈路層隨意，上面再跑一層OSPF/babel
假設你有abcd四個節點，就可以這樣搭配

優點是靈活搭配，根據不同網路情況建立不同隧道
缺點則是配置繁瑣，每個元件都是互相獨立的

還有一個方案，就是在鏈路層上面做內網路由，例如我的etherguard，或是zerotier/tinc之類
他們會在內部建立起路由表，然後根據MacAddress尋路
缺點就是鏈路層和igp綁定了，要用只能用全套的。
如果某節點針對UDP的限速很嚴重，單獨對這個節點我想換別的鏈路層就十分麻煩

理論上eg的過牆性能和wg應該是一樣的。

現在wg正常使用，但不知道哪天會被封。加上wg協議本身沒有隱蔽性，很容易被識別

為了縮MTU，eg的header被我魔改過，長得有點不一樣

最近某群友贊助了我一台江蘇的server

為了未雨綢繆，哪天etherguard無法連線，我決定把igp和鏈路層分開，使用babeld來維護內網路由

如果用上了 igp ， ibgp 的設定就很不一樣了

我們的路由表，又稱作RIB，一定要變成轉發表，又稱作FIB，封包才能真正地送出去

路由表的資料結構有以下這些欄位: 1.prefix 2.device(optional) 3. nexthop(optional)

而轉發表非常類似，有這些欄位: 1. prefix 2. device 3.MAC address

(note: L2 裝置比如tap，或是物理網卡才有 mac address。 L3裝置比如 tun，沒有 MAC address)

我們可以看到，只有第三點不一樣: nexthop vs MAC address 。這和一個概念很相關: 「直接可達」

IP地址代表了某台電腦。nexthop 填入的是一個IP，但是不能隨便填。nexthop的IP，必須要是「直接可達」的IP。

甚麼是直接可達的IP呢? 就是「可以被轉換成MAC address的IP」。因為RIB要轉換成FIB，封包才能真正被發出去

路由器和交換機最大的差別，路由器是用 dst-ip 來尋路，而交換機是用 MAC address來尋路的

(2023/11/15 UPDATE)

然後... 在我還沒寫完這篇文章的時候，我就發現 babeld 所帶來的問題了，導致我放棄 babeld，最後改用 OSPF+自動測量延遲+更新 cost 的腳本

babeld 所帶來的問題是這樣的，每當 metric 更新的時候，內部運作是「先移除舊路由，再寫入新路由」，參考下方 babeld 原始碼:

而 bird 則是監聽 netlink ，是事件驅動的。所以不管時間窗口多短，「路由移除」事件一定會被 bird 捕捉到。

bird 捕捉到「igp 路由移除」事件，會讓和這條 igp 路由關聯的 ebgp 路由全部被撤回。而 ebgp 路由全表有 1200 多條，會向每個 peer 發送 600 多個「撤回路由」訊息

0.05 秒以後， babeld 寫入新路由， bird 又重新把路由發給每個 peer

一來一回，每次 babeld 測量延遲，就會產生 2400 個 BGP UPDATE 發給每個 peer

而 babeld 預設 4秒測量一次延遲，更新路由表。每4秒發 2400 個 BGP UPDATE ，想想就不對

不只有流量問題，額外 CPU 消耗，還造成整個網路充滿大量無意義的 BGP UPDATE，讓網路不穩

所以最終我選擇放棄了 babeld ，自己寫了一個 OSPF 自動測量延遲的腳本。

開機後每小時測量一次，隔天開始每天測量一次，緩解了 BGP UPDATE 太多的問題

KusakabeShi's Space