★路由遞歸查詢方法及相關圖…

我們知道，路由查

找的過程是尋找資料包下一跳的過程!IP路由逐跳将資料包送往目的地。所謂的下一跳就是和自己直連的某台路由器的對應接口IP位址，這是合乎情理的了解，

然而IP路由提供了另外一種方式，即下一跳不必非要和自己直連，它可以忽略目前路由器“附近的拓撲”，直接告知相對較遠方的拓撲，如下圖所示：

　　到達Server的下一跳是R2，到達R2的下一跳是R1...以此類推。協定棧

的路由查找邏輯在查找路由時，如果發現nexthop不是和自己直連的，那麼就會将此nexthop作為destination再次按照上述邏輯查找路由

表直到查到和自己直連的nexthop或者完全失敗為止。這種路由相當于把nexthop推向了遠方。這種遞歸查找能帶來什麼好處呢?顯然的，遞歸路由可

以是nexthop受到附近網絡拓撲變化的影響最小化!針對必須使用靜态路由的情況，合理的遞歸路由規劃可以大大簡化靜态路由的維護工作量，當然如果你使

用動态路由，那就沒有必要了，要知道遞歸路由在帶來維護友善的同時，其代價是路由器增加了查找壓力。以一個例子說明，試看如下拓撲：

　　試想，如果到達R1，R2的鍊路均出現了問題，現在需要将N1，N2，N3的nexthop都切換到R7，你就需要同時修改這三條路由(在無法

實作路由彙總的情況下，更糟糕)，然而如果我們已經知道到達N1，N2，N3都要經過R3，那麼就可以配置N1，N2，N3的nexthop均為R3，頓

時在邏輯上繞開了問題鍊路，實際上，協定棧

的路由查找邏輯幫助管理者找到了一條到達R3的路，最終的nexthop物力上還是和R0直連的，遞歸查找的結束條件就是destination和R0直

連。在配置上，尋址3個網絡的需求變成了尋址R3的需求，配置也簡化了不少，你隻需要配置一個預設網關即可，鍊路切換時需要更改的配置也少了很多。

　　然而記住，遞歸路由并沒有改變任何資料包到達目标網絡的路徑，它最終還是要落實到一個直連nexthop上，如果我們根據遞歸路由的配置反推，

那麼就可以配置出一個非遞歸的“正常路由”，這個正常的路由配置也能解決上述的繁瑣配置問題，是以遞歸路由某種程度上是一種懶人的做法。另外，遞歸路由的

使用有一個要點，那就是你必須對整個網絡拓撲比較熟悉，之是以要使用遞歸路由，目的是繞開那些經常變動的鍊路，而作為靜态路由，鍊路變動就意味着所有相關

的路由都要重新配置，使用遞歸路由可以使配置工作量減小，是否使用遞歸路由的一個權衡點是：如果到達目标網絡的鍊路在途中不能彙聚成比目标網絡數量更少的

鍊路，遞歸路由就沒有什麼意義。

　　歸于實際，我發現Windows是有遞歸路由配置功能的，當然Cisco就

更别說了，可是Linux沒有，說它沒有還真是有一半，竟然沒有實作完，空留一個CONFIG_IP_ROUTE_PERVASIVE宏，最可悲的是，竟

然在iproute2裡面有一個NHFLAGS := [ onlink | pervasive

]，這個pervasive是最可惡的。Linux總是這樣，核心的實作與否和使用者态程式實作與否總是不一緻!!