KusakabeShi's Space

RootlessRouter系列: Rootless Router(Part: 0): 用戶態DN42節點 Rootless Router(Part: 1): wggo-vpp Rootless Router(Re: 0): VPP Host stack Rootless Router(Part: 2): BIRD-vpp Rootless Router(Part: 3): EtherGuard Rootless Router(Extra):蒐集的Userspace 網路棧 Rootless Router(Part: 4): 被VPP Host Stack衝康 Rootless Router(Part: 5): 完結 Rootless Router(Fin): UML版本上線啦! Rootless Router(Afterword): Azure App Service真的很靈 不知道RootlessRouter是什麼的人，請點上面第一篇，了解整個故事線 最後，RootlessRouter終於上線了! 完結灑花! 在放棄VPP以後，最初我的計劃長這樣: 自己刻一個Simple Router代替原本的VPP，大致架構不變 原本VPP的LD_PRELIAD的kernel bypass部分拿掉，改成端口轉發。把遠端端口179轉發到localhist:10079 然後BIRD就和localhost:10079 建立session，同時把遠端發往SimpleRouter的179端口轉發到localhost:179 同時也不忘看看 這裡 一些其他選項，在我看UML的時候，其中一句話吸引了我: You can get extremely high performance for anything which is a “kernel specific task” such as forwarding, firewalling, etc while still being isolated from the host kernel. 我決定相信他所謂的extremely high performance。而且BIRD正好不怎麼fork，完美適合UML發揮的場景! 現在的架構長這樣: BIRD是運作在UML裡面的，圖片沒畫好又有點懶得改，附註一下 同時我決定把計畫更名，從原本的Ro

當初知道DN42的時候，還什麼都不懂 只會抄配置，抄來了也不懂意思。經過了好幾個月，才搞懂他到底在幹嘛 我當初的癥結點，是卡在「 不知道他的交互對象 」 一旦搞懂這些，剩下的就迎刃而解了。 但我當初不知道，摸了很久才發現這點。 所以想花三分種講說明一下 路由是一個長類似這樣的資料結構(加上一些額外標記) [1] 192.168.1.0/24 → dev eth0 [2] 192.168.2.0/24 → via 192.168.1.1 [3] 192.168.3.0/26 → dev eth0 via 169.254.42.1  以上面的三條路由為例，假如我們 kernel 內有這三條路由，然後 kernel 依序收到以下封包，這是接下來會發生的事情: 1. 任何封包發送時，首先第一步就是決定要往哪張物理網卡送。畢竟網卡是網路連線的渠道 DstIP=192.168.1.9。查詢到路由表裡的 [1]，就會把這個封包送往eth0 DstIP=192.168.2.9。查詢到路由表裡的 [2]。 但是路[2]裡面沒有指明具體網卡 ，只有寫「請找192.168.1.1」，所以他又去找 192.168.1.1 了，匹配路由 [1]。路由[1]指定了網卡eth0，最後這個封包就會送往eth0了。這個步驟叫做 遞迴查詢 DstIP=192.168.3.9。查詢到路由表裡的 [3]。但是[3]同時指定了網卡和IP。這個時候 [3]和[1] 的行為非常像，都是送入 eth0。不一樣的是下一步 2. 封包發送時，找到對應網卡以後，接下來就是填入目標的 mac address 了，這個時候不僅要查詢路由表，還要查詢 arp table 路由[1] 沒有指定IP，那麼DstIP是多少，就填入那個IP的 MAC 地址。 然而路由[3]比[1]多了「via」選項:「169.254.42.1」，那麼就會改為填入 169.254.42.1 的MAC地址 那麼我們要怎麼知道某IP的mac address呢? 電腦首先會在一個本地資料庫「arp table」裡面查詢。如果查不到，那電腦對那張網卡發出 arp request ，在區網內廣播「who has 169.254.42.1」，對面應答以後，就知道對面的 mac address，並存入本地的 arp table 「169.254.42.1 的 MA