6、我们称建立连接的两台设备互为对等体（PEER） ， 因为这两个设备是跨越ISP的 ， 所以我们称为外部对等体 ， 以后会出现内部对等体的概念 。为了确保两头设备的扩展RIP进程都在存活 ， 我们要求两端的设备周期性的通过该TCP连接发送HELLO消息 ， 以向对方确认自己还存活；
7、假如一端设备在一个存活超时的时间内没有接收到对方的HELLO消息 ， 则认为对方已经停止运行RIP进程 ， 于是拆除该TCP连接 ， 并把从对方接收到的路由全部删除 。
这样的改进之后 ， 完成路由表的传递这个任务已经超超有余了 ， 并且还可以做到对路由表的简单维护（比如当认为对方RIP进程停止后 ， 就删除从对方接收到的路由表） 。
& 本部分有下列要点：
1、为了避免经常性的大量数据传输 ， 我们去除了RIP协议中周期发送整个路由表的机制 ， 引入了增量机制；
2、为了克服UDP协议的不可靠传输 ， 我们改变了RIP的传输协议 ， 改用TCP ， 而且引入了邻居维护机制（在TCP协议上传输HELLO报文）和路由表维护机制（当判定外部对等体DOWN掉之后 ， 删除从该对等体获得的路由表） 。
2.2 需求之二—下一跳问题
在上一部分中 ， 我们对RIP做了改造 ， 使之很适合传播大量的路由 ， 但这样的改造又产生了一些问题 ， 首先是下一跳的确定问题 ， 请看下面的网络图形：
在这个图形中 ， 三个路由器RT1 ， RT2和RT3通过广播式的网络（在该图中是以太网）连接起来 ， 其中RT1和RT2之间建立了我们上面介绍的扩展RIP TCP连接 ， RT2和RT3之间也建立了该连接 ， 这样RT2会从RT3学习到路由 ， 并且把学习到的路由通告给RT1 ， 这时候 ， 根据RIP协议的规则 ， RT1会把RT2作为到到RT3上路由的下一跳 ， 但实际情况是 ， RT1只要直接把RT3作为下一跳即可 ， 因为这是个广播网络 ， 而假如把RT2作为下一跳 ， 理论上是没有任何问题的 ， 因为RT2还是要把数据报递交给RT3 ， 但这样会浪费RT2很多资源 。能不能想个办法 ， 让RT1直接把RT3作为他的下一跳呢？
解决的办法也有很多 ， 在这里我们这样解决：
1、在路由器上 ， 给每条通告的路由附加上一个IP地址值 ， 该地址值指出了通往该路由的下一跳；
2、一般情况下 ， 路由器在向外通告自己的路由的时候 ， 把下一跳改写为向外通告的接口的IP地址 ， 但假如通过的路由的原来的下一跳跟自己往外通告的接口位于同一个广播网络 ， 则不修改下一跳 ， 而直接发送出去 。
引入这样的规则后 ， 上面图中的问题便解决了：RT2从RT3接收到的路由的下一跳是RT3的连接广播网络的端口 ， 而当RT2在把从RT3获得的路由通告给RT1的时候 ， RT2判定出口的IP地址跟通告的路由位于同一个广播网络（通过IP地址判定） ， 则不修改下一跳 ， 直接把这些路由通告给RT1 。需要注重的是 ， RT2在向RT1通告不是从RT3获得的路由的时候 ， 还是要把路由的下一跳修改为自己通告的接口 。
在大多数情况下 ， 这样的处理是合适的 ， 但有些情况就不适合 ， 比如下面的网络：
RT1 ， RT2和RT3通过一种叫做NBMA（非广播多路访问 ， 典型的如ATM ， 帧中继等）的网络连接起来 ， 这时候 ， RT1和RT2之间 ， 以及RT2和RT3之间建立了PVC ， 而RT1和RT3之间没有建立PVC ， 在这样的情况下 ， 假如RT2再进行刚才的动作 ， 在向RT1通告从RT3获得的路由的时候 ， 不修改下一跳 ， 这样RT1就会把下一跳当成RT3 ， 问题产生了：RT3和RT1之间根本没有PVC ， 所以RT1和RT3之间根本没法通信 ， 这样必然会阻断一部分数据流量 。
为了解决这个情况 ， 我们采取一种折中的方案：默认情况下 ， 按照开始提出的规则 ， 即假如通告的路由的下一跳跟通告的接口位于同一个三层网段 ， 则不修改下一跳 ， 但提供一个配置命令 ， 这个配置命令强制路由器修改下一跳为通告的接口 ， 而不管通告的路由的下一跳是什么 。
推荐阅读
- 1 RIP协议的基本配置
- 在Vovida的基础上实现自己的SIP协议栈②
- 802．1x协议解析
- TCP/IP协议处理 由“软”转“硬”
- 在Vovida的基础上实现自己的SIP协议栈①
- TCP/IP协议中的三个参数
- 802．1x协议工作机制
- QoS 的协议与结构
- 剖析TCP和UDP协议
- TCP协议的拥塞控制策略及改进