博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
关于路由的递归查询
阅读量:5792 次
发布时间:2019-06-18

本文共 1334 字,大约阅读时间需要 4 分钟。

我们知道,路由查找的过程是寻找数据包下一跳的过程!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总是这样,内核的实现与否和用户态程序实现与否总是不一致!!

 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1268864

你可能感兴趣的文章
不错的句子
查看>>
【数据立方cube】数据立方
查看>>
Ubuntu Linux 中启动FTP服务
查看>>
time简介
查看>>
PHPCMS V9 视频分享模块SQL注射漏洞分析
查看>>
4、单机运行环境搭建之 --CentOS-6.5优化Tomcat7
查看>>
操作系统概论——引
查看>>
外边距叠加问题小结
查看>>
Android 开源框架Universal-Image-Loader完全解析(二)--- 图片缓存策略详解
查看>>
汉字转数字
查看>>
(转载)编写高效的jQuery代码
查看>>
比较完整的路径符号对应解释列表
查看>>
Activity进程和线程之间的关系
查看>>
穷追不舍、事故入手和倒逼
查看>>
Microsoft Visual C++ 6.0预处理器参考手册
查看>>
解决 PermGen space Tomcat内存设置(转)
查看>>
linux yum命令详解
查看>>
HDFS的java操作方式
查看>>
子查询返回的值不止一个
查看>>
BZOJ2707 : [SDOI2012]走迷宫
查看>>