我們知道，路由查找的過(guò)程是尋找數(shù)據(jù)包下一跳的過(guò)程!IP路由逐跳將數(shù)據(jù)包送往目的地。所謂的下一跳就是和自己直連的某臺(tái)路由器的對(duì)應(yīng)接口IP地址，這是合乎情理的理解，然而IP路由提供了另外一種方式，即下一跳不必非要和自己直連，它可以忽略當(dāng)前路由器“附近的拓?fù)?rdquo;，直接告知相對(duì)較遠(yuǎn)方的拓?fù)?，如下圖所示：

到達(dá)Server的下一跳是R2，到達(dá)R2的下一跳是R1...以此類推。協(xié)議棧的路由查找邏輯在查找路由時(shí)，如果發(fā)現(xiàn)nexthop不是和自己直連的，那么就會(huì)將此nexthop作為destination再次按照上述邏輯查找路由表直到查到和自己直連的nexthop或者完全失敗為止。這種路由相當(dāng)于把nexthop推向了遠(yuǎn)方。這種遞歸查找能帶來(lái)什么好處呢?顯然的，遞歸路由可以是nexthop受到附近網(wǎng)絡(luò)拓?fù)渥兓挠绊懽钚』?針對(duì)必須使用靜態(tài)路由的情況，合理的遞歸路由規(guī)劃可以大大簡(jiǎn)化靜態(tài)路由的維護(hù)工作量，當(dāng)然如果你使用動(dòng)態(tài)路由，那就沒(méi)有必要了，要知道遞歸路由在帶來(lái)維護(hù)方便的同時(shí)，其代價(jià)是路由器增加了查找壓力。以一個(gè)例子說(shuō)明，試看如下拓?fù)洌?/p>

試想，如果到達(dá)R1，R2的鏈路均出現(xiàn)了問(wèn)題，現(xiàn)在需要將N1，N2，N3的nexthop都切換到R7，你就需要同時(shí)修改這三條路由(在無(wú)法實(shí)現(xiàn)路由匯總的情況下，更糟糕)，然而如果我們已經(jīng)知道到達(dá)N1，N2，N3都要經(jīng)過(guò)R3，那么就可以配置N1，N2，N3的nexthop均為R3，頓時(shí)在邏輯上繞開(kāi)了問(wèn)題鏈路，實(shí)際上，協(xié)議棧的路由查找邏輯幫助管理員找到了一條到達(dá)R3的路，最終的nexthop物力上還是和R0直連的，遞歸查找的結(jié)束條件就是destination和R0直連。在配置上，尋址3個(gè)網(wǎng)絡(luò)的需求變成了尋址R3的需求，配置也簡(jiǎn)化了不少，你只需要配置一個(gè)默認(rèn)網(wǎng)關(guān)即可，鏈路切換時(shí)需要更改的配置也少了很多。

然而記住，遞歸路由并沒(méi)有改變?nèi)魏螖?shù)據(jù)包到達(dá)目標(biāo)網(wǎng)絡(luò)的路徑，它最終還是要落實(shí)到一個(gè)直連nexthop上，如果我們根據(jù)遞歸路由的配置反推，那么就可以配置出一個(gè)非遞歸的“正常路由”，這個(gè)正常的路由配置也能解決上述的繁瑣配置問(wèn)題，因此遞歸路由某種程度上是一種懶人的做法。另外，遞歸路由的使用有一個(gè)要點(diǎn)，那就是你必須對(duì)整個(gè)網(wǎng)絡(luò)拓?fù)浔容^熟悉，之所以要使用遞歸路由，目的是繞開(kāi)那些經(jīng)常變動(dòng)的鏈路，而作為靜態(tài)路由，鏈路變動(dòng)就意味著所有相關(guān)的路由都要重新配置，使用遞歸路由可以使配置工作量減小，是否使用遞歸路由的一個(gè)權(quán)衡點(diǎn)是：如果到達(dá)目標(biāo)網(wǎng)絡(luò)的鏈路在途中不能匯聚成比目標(biāo)網(wǎng)絡(luò)數(shù)量更少的鏈路，遞歸路由就沒(méi)有什么意義。

歸于實(shí)際，我發(fā)現(xiàn)Windows是有遞歸路由配置功能的，當(dāng)然Cisco就更別說(shuō)了，可是Linux沒(méi)有，說(shuō)它沒(méi)有還真是有一半，竟然沒(méi)有實(shí)現(xiàn)完，空留一個(gè)CONFIG_IP_ROUTE_PERVASIVE宏，最可悲的是，竟然在iproute2里面有一個(gè)NHFLAGS := [ onlink | pervasive ]，這個(gè)pervasive是最可惡的。Linux總是這樣，內(nèi)核的實(shí)現(xiàn)與否和用戶態(tài)程序?qū)崿F(xiàn)與否總是不一致!!