詳解路由器遞歸查詢方法

　　路由查找的過程是尋找數(shù)據(jù)包下一跳的過程!IP路由逐跳將數(shù)據(jù)包送往目的地。所謂的下一跳就是和自己直連的某臺路由器的對應(yīng)接口IP地址，這是合乎情理的理解，然而IP路由提供了另外一種方式，即下一跳不必非要和自己直連，它可以忽略當前路由器“附近的拓撲”，直接告知相對較遠方的拓撲。

　　到達Server的下一跳是R2，到達R2的下一跳是R1...以此類推。協(xié)議棧的路由查找邏輯在查找路由時，如果發(fā)現(xiàn)nexthop不是和自己直連的，那么就會將此nexthop作為destination再次按照上述邏輯查找路由表直到查到和自己直連的nexthop或者完全失敗為止。這種路由相當于把nexthop推向了遠方。這種遞歸查找能帶來什么好處呢?

　　顯然的，遞歸路由可以是nexthop受到附近網(wǎng)絡(luò)拓撲變化的影響最小化!針對必須使用靜態(tài)路由的情況，合理的遞歸路由規(guī)劃可以大大簡化靜態(tài)路由的維護工作量，當然如果你使用動態(tài)路由，那就沒有必要了，要知道遞歸路由在帶來維護方便的同時，其代價是路由器增加了查找壓力。

　　試想，如果到達R1，R2的鏈路均出現(xiàn)了問題，現(xiàn)在需要將N1，N2，N3的nexthop都切換到R7，你就需要同時修改這三條路由(在無法實現(xiàn)路由匯總的情況下，更糟糕)，然而如果我們已經(jīng)知道到達N1，N2，N3都要經(jīng)過R3，那么就可以配置N1，N2，N3的nexthop均為R3，頓時在邏輯上繞開了問題鏈路，實際上，協(xié)議棧的路由查找邏輯幫助管理員找到了一條到達R3的路，最終的nexthop物力上還是和R0直連的，遞歸查找的結(jié)束條件就是destination和R0直連。

　　在配置上，尋址3個網(wǎng)絡(luò)的需求變成了尋址R3的需求，配置也簡化了不少，你只需要配置一個默認網(wǎng)關(guān)即可，鏈路切換時需要更改的配置也少了很多。

　　然而記住，遞歸路由并沒有改變?nèi)魏螖?shù)據(jù)包到達目標網(wǎng)絡(luò)的路徑，它最終還是要落實到一個直連nexthop上，如果我們根據(jù)遞歸路由的配置反推，那么就可以配置出一個非遞歸的“正常路由”，這個正常的路由配置也能解決上述的繁瑣配置問題，因此遞歸路由某種程度上是一種懶人的做法。

　　另外，遞歸路由的使用有一個要點，那就是你必須對整個網(wǎng)絡(luò)拓撲比較熟悉，之所以要使用遞歸路由，目的是繞開那些經(jīng)常變動的鏈路，而作為靜態(tài)路由，鏈路變動就意味著所有相關(guān)的路由都要重新配置，使用遞歸路由可以使配置工作量減小，是否使用遞歸路由的一個權(quán)衡點是：如果到達目標網(wǎng)絡(luò)的鏈路在途中不能匯聚成比目標網(wǎng)絡(luò)數(shù)量更少的鏈路，遞歸路由就沒有什么意義。

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

　　以上就是學(xué)習(xí)啦帶給大家不一樣的精彩。想要了解更多精彩的朋友可以持續(xù)關(guān)注學(xué)習(xí)啦，我們將會為你奉上最全最新鮮的內(nèi)容哦! 學(xué)習(xí)啦，因你而精彩。