ip_conntrack緩存neighbour

在個人ip_conntrack版本中，它目前已經能夠緩存路由，filter規則等，還能夠平滑生效最新配置的NAT，它愈來愈像真正的SDN了，惟一有待完善的就是將5元組的tuple進化成N元組的tuple了，其他的更新及修正都是些不會引起質變的量變。
   如今看一下，ip_conntrack還能緩存什麼？固然了，在個人"路由cache in conntrack"版本中，我只是將dst_entry簡單的從skb中拷貝到了ip_conntrack中，相似IPMARK那樣，能夠在skb和conntrack之間save和restore。數據包進入協議棧被處理的流程依然沒變，優化掉的僅僅是一個路由緩存和路由表的查找過程。雖然邁出了決定性的一步，可是在編程接口上確實沒有什麼吸引人的地方，所以你也就不想基於此去寫一些代碼了。好比說，數據包依然要通過ip_rcv函數的處理，依然要通過FORWARD這個HOOK鏈，一切都像往常同樣，不一樣的只是在查找路由以前，路由已經被從conntrack結構體裏面restore到skb了。
   若是想實現真正的流式轉發，而且基於硬卡實現這種邏輯，那麼就必然要對真正負責轉發的鏈路層以及物理層動手術，好比在PREROUTING中直接將數據包注入硬卡，而後由硬卡實現如下policy：
由tuple查找conntrack；
取出route；
取出neighbour；
直接ASIC轉發。
返回HOOK NF_STOLEN
對了，正是這個邏輯，它不但解放了BOX的CPU，並且還使得轉發更加靈活。咱們已經能夠取出route，而且因爲neighbour就保存在route中(Linux網絡棧如此設計真的很妙！)，只要將此neighbour hold on，它就能保持一直不被釋放，脫離ARP的timer管理，相似static設置的ARP映射同樣。
   這個neighbour的cache很關鍵，它直接cache了「須要最終落實的信息」，那就是下一跳的MAC地址，它甚至能夠cache上一跳的MAC地址，如此一來網絡上的數據轉發就真正退化(也許是進化)成了「基於流頭的路由，策略匹配，MAC地址的下一跳解析"了！屬於同一流的後續包無需作任何協議棧裏面的常規操做，全部信息均可以從conntrack中取得，這難道不就是SDN的核心嗎？
   從最開始完成」徹底橋接「版本的conntrack(即那個不須要配置返回包路由的那個版本，直接將上一跳的MAC進行cache，返回包直接封裝其MAC地址的版本)，到接觸到SDN，而後陸續完成各類基於SDN核心思想的conntrack版本，其間兩個月有餘，然而代碼很不規範，也沒有提交到任何地方...
   看看所作的這一切，經過iptables，經過本身編寫HOOK函數，來實現自動路由，自動封裝MAC地址，一切都是基於conntrack，這是什麼行爲？這其實正是在逐漸架空傳統協議棧的路由邏輯，ARP解析邏輯啊！一個轉發BOX居然沒有路由邏輯，沒有ARP邏輯，這是不可想象的，它成了什麼？或者問什麼東西沒有這些複雜的邏輯？答案顯而易見！switch！對了，就是switch，終於，BOX退化成了一個交換機！僅僅負責數據的轉發，而控制邏輯從哪裏來？或者問，一個傻瓜switch到底是如何知道該如何轉發數據的，個人版本是預配置，這固然只是個人一種方式而已！標準作法是經過一個通訊協議，從另外一臺機器上獲取，這個所謂的另外一臺機器是什麼？我把它稱爲控制器。也就是說，路由邏輯等控制模塊所有移到了這個控制器中了。
   這即是個人SDN版本！一個不一樣於OpenFlow的，可是徹底體現SDN思想的非標準化的SDN實現。接下來要證明的是，IP路由並非根本，根本是什麼？根本是」能夠落實的「東西，那就是有封裝以太幀的目標MAC地址！！！(走火入魔了！！！)