到达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总是这样，内核的实现与否和用户态程序实现与否总是不一致！！
