我們知道，路由查找的過程是尋找數據包下一跳的過程!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總是這樣，內核的實現與否和用戶態程序實現與否總是不一致!!