有四個路由器，分別是POOH,TIGGER,PIDET,RABBIT，在這個拓撲下面顯示的是POOH的路由表，可以看到，現在已經可以從POOH上查詢到了五個網段，也就是說現在達到了全網互通。
舉 例來說，如果想達到網段10.1.10.0，CPU開始查找路由表，發現了壹個路由條目是到達10.1.10.0的，通過192.168.1.194,而 這個地址就是piglet路由器最左邊的那個端口，那麽這個192.168.1.194又是怎麽到達呢？再壹次查找路由表，找到了壹個網段 192.168.1.192，這裏面就包含了192.168.1.194這個地址，而到達它是通過192.168.1.66來實現的。那麽 192.168.1.66又是應該怎麽到達？還得繼續查找路由表。192.168.1.194
這個過程在周而復始的進行，形成壹個遞歸的過程，知道路由器找到直連網段位置，按照上面的那個實例來說就是當找到192.168.1.64這個條目。
好了，這就是路由器遞歸查詢的過程。
但是，這樣的查詢方法有什麽用途呢？妳是否考慮過呢？
先讓我們回到壹個比較本質的問題上去，路由器和交換機的作用是什麽？其實無非是兩個作用，壹是考慮如何把數據包正確的送到目的地址，二是如何更快的送到。 至於其他的各種安全技術，QoS等等都是為這兩個終極目標服務的。由於本篇不涉及到交換機的內容所以在此略過不提，單說路由器，工程師們為了讓路由器更好的完成這兩個任務做出了不懈的努力，其中壹個就是不斷改進的包交換方法以達到快速的轉發包的目的。
先讓我們從歷史的角度看壹下
最早誕生的是“進程交換”
這種交換很傳統，路由器每收到壹個包就會通過CPU查找路由表然後送到出站端口，每過來壹個包就會這樣做壹次。這種方法是沒有問題的，但是卻很慢，明顯的效率不高。
為了解決這個問題，“快速交換”誕生了
這 裏面有壹個前提，也是能開發出“快速交換”的壹個先提條件，那就是我們的數據壹般都是以流的形式傳播的，流，這個詞十分形象，就是壹串數據包都去往同壹個 地方。當工程師發現了這個規律之後，“快速交換”的想法誕生了，所謂快速交換就是，先分析每個流的第壹個包，按照進程交換的方式進行查詢，然後出站同時把 這個查詢的結果保存在壹個獨立的緩存中。當這個流中剩下的包進站時，路由器不是去查路由表而是去查緩存，這樣就能節省CPU的資源，直接把包轉發出去。這 樣不但提高了包轉發的速度，實際上也提高了CPU的使用效率。
最後就是CEF
思科的快速交換，CEF有太多的內容需要講，相對於前兩種交換方式有很大的不同，我在這裏只取其在交換形式上的差別。進程交換是當壹個新數據流來了後路由第壹個包，然後把信息記入緩存來對轉發進行加速。而CEF的做法更絕！
連第壹個包都不用查了，直接進行緩存操作！而且是在包之前就進行了緩存。
也就是大名鼎鼎的FIB表。
當壹個數據包入站的時候，直接查詢FIB表而不是路由表，這樣就能大大增加轉發的速度。
也 許妳有疑問，我當初就是有疑問的，本來有好好的路由表，現在又建立了壹個FIB表，壹個數據包到了不還是需要查找嗎？這樣有什麽作用？很顯然現在壹般的圖 書上並沒有寫明原因，沒有給我壹個合理的解釋。不過對於這個問題，以及對於CEF的專題討論我會在下周的時候單獨寫壹篇文章來敘述，讓妳明白CEF!
現在讓我們尊重壹個事實，CEF更快！
我用了大量的篇幅來寫看似與本篇主題無關的“路由器交換”，我想告訴大家的是“加快交換，遠離路由表”，CPU路由查詢的次數越少轉發的效率越高！
那麽現在讓我們回到本篇文章的主題“遞歸路由的查詢”，強烈的困惑！人家查壹次路由表都嫌多，妳卻使用遞歸查詢查了那麽多遍路由表！
確實，這就是遞歸查詢的最大缺點！也是我們在設計網絡的時候必須要考慮的壹個問題。不過仔細想壹下，既然這是壹個極為“不成功”的方法，那麽為什麽還會允許它的存在呢？這又是為了什麽？
遞歸查詢的優勢！無與倫比的優勢！
我們來看壹下這個拓撲，註意壹下SANDERZ的靜態路由的設計。
這就是壹個典型的遞歸路由的使用案例，可以仔細的看壹下。
這裏我們先設計壹個情景，從顯示的路由路由信息來看，現在到達右側網段的所有數據都要從HEFFALUMP路由器通過，這個時候如果HEFFALUMP壞了，那麽必須要從WOOZLE進行路由。
這個時候網絡管理員只需要調整壹條路由就可以了。
Sanderz(config)# ip route 10.87.14.0 255.255.255.0 10.23.5.95
Sanderz(config)# no ip route 10.87.14.0 255.255.255.0 10.23.5.20
這樣就完成了任務。
那麽如果不使用遞歸路由呢？那麽圖中的每壹個路由都要重新設置，如果按照上圖的案例來說，我們需要重新寫26條路由條目。如果妳覺得這樣的數量還能忍受， 那麽如果有100個，400個網段呢？妳要重寫200條，800條路由！這個工作量就大了吧，妳還能忍受嗎？同樣是400個網段，使用遞歸路由還是上面的 兩條命令。
借用並改造算法中時間復雜度的概念：不使用遞歸路由的時間復雜度為O(n),而使用了遞歸路由的時間復雜度為O(1)！
這也就是遞歸路由最大的優點！
面對遞歸路由的優點與缺點，確實是很難辦，是需要斟酌的。（這是《ROUTING TCP/IP VOL.1 》的說法）
不過我想其實並不是那麽“難辦”
從實際的網絡應用來講，現在能夠使用靜態路由的網絡拓撲不會很大，相對於路由器CPU的處理能力來講不是很大的負擔，也就不會很影響速度，所以為了管理的方便我們是可以放心的使用遞歸路由的。
但是，我這種說法並不包含 兩個大的園區網之間用靜態路由的情況（教育網），這樣的情況還是使用最普通的路有方式吧。
具體情況具體分析，相必大家對與遞歸路由的優勢和缺點也是很熟悉了，能夠在其間取舍。