CCNA17-RIP路由协议
一，RIP的工作原理
RIP是应用层协议（OSI的第7层），RIPv2组播地址是224.0.0.9
RIP路由协议用“更新（UNPDATES）”和“请求（REQUESTS）”这两种分组来传输信息的。每个具有RIP协议功能的路由器每隔30秒用UDP520端口给与之直接相连的机器广播更新信息。更新信息反映了该路由器所有的路由选择信息数据库。路由选择信息数据库的每个条目由“局域网上能达到的IP地址”和“与该网络的距离”两部分组成。请求信息用于寻找网络上能发出RIP报文的其他设备。
RIP用“路程段数”（即“跳数”）作为网络距离的尺度。每个路由器在给相邻路由器发出路由信息时，都会给每个路径加上内部距离。在如下图中，路由器3直接和网络C相连。当它向路由器2通告网络142.10.0.0的路径时，它把跳数增加1。与之相似，路由器2把跳数增加到“2”，且通告路径给路由器1，则路由器2和路由器1与路由器3所在网络142.10.0.0的距离分别是1跳、2跳。
二，RIPv1和RIPv2之间的比较
三，RIP的宣告
什么是通告？
通告就是将路由器的本地接口划入一个路由器的路由选择协议的进程，让其可以参与该路由协议报文的收发工作。RIP
只能基于主类网络号的宣告。
发送路由条目：一个被宣告进RIP协议的接口可以将该路由器上的所有被宣告进协议进程的接口直连的路由和通过这些被宣告接口获悉的来自RIP协议并加入路由表的条目宣告出去
例如 R3会把直连的11.0.0.0/24的网段和获悉的10.0.0.0/24网段都发送出去
接受路由条目：一个被宣告进RIP协议的接口可以接受邻居路由器发来的任何关于该协议的路由条目
四，RIP自动汇总
RIP V2 的automatic summary
1.不会对收到的明细路由进行汇总
2.对自己直连的路由进行汇总后,再通告出去.
3.把收到的明细路由放进路由表中,但会对明细路由进行汇总后再通告出去!
五，RIP简单的配置
R1： R1(config)#router rip R1(config-router)#version 2 R1(config-router)#no auto-summary R1(config-router)#network 10.0.0.0 R1(config-router)#network 1.1.1.0 **************###############################*************** R2(config)#router rip R2(config-router)#no auto-summary R2(config-router)#version 2 R2(config-router)#network 10.0.0.0 R2(config-router)#network 11.0.0.0 R2(config-router)#network 2.2.2.0 ##################################################### R3(config)#router rip R3(config-router)#network 3.3.3.0 R3(config-router)#network 11.0.0.0 R3(config-router)#version 2 R3(config-router)#no auto-summary
六，RIP协议的6大增强机制
| R1 |
R2 |
R3 |
hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 13.1.1.1 255.255.255.0 no shut ! interface Serial1/1 ip address 12.1.1.1 255.255.255.0 no shut ! router rip version 2 no auto-summary network 1.1.1.0 network 12.1.1.0 network 13.1.1.0 ! |
! hostname R2 ! interface Serial1/0 ip address 12.1.1.2 255.255.255.0 no shutdown ! interface Serial1/1 ip address 23.1.1.2 255.255.255.0 no shutdown ! router rip version 2 no auto-summary network 12.1.1.0 network 23.1.1.0 ! |
! hostname R3 ! interface Serial1/0 ip address 23.1.1.3 255.255.255.0 no shut ! interface Serial1/1 ip address 13.1.1.3 255.255.255.0 no shut ! router rip version 2 no auto-summarynetwork 13.1.1.0 network 23.1.1.0 ! |
(1)，路由失效计时器
路由器收到的RIP路由条目的有效时间是180s，如果过了180s，那么路由器就会将这条路由表示为possibly down。
1.当有条目加入到路由表中时，该条目的invalid timer就会初始化为180S；
2.如果路由器在invalid timer内没有收到该条目的更新信息，那么它在超过180S后将会被标记为不可达，即16跳；
3. 它的典型周期范围是3～6个update周期，无效时间在IOS中缺省是180秒
(2)，最大跳数（计数到无穷大）
RIP定义的最大的metric是15，当到达16之后就会直接把这条路由给删除
如上图所示是实验图
产生16跳的工作过程：
1:R1丢失了looback接口的网络（下面简称网络A）后，产生一个即时更新送往R2和R3。这个更新信息要告诉R2和R3，R1不再有到达网络A的路径。然而这个更新信息传输到R3被推迟了（ C P U忙、链路拥塞等），但到达了R2。R2从路由表中去掉到网络A的路径。
2:R3仍未收到R1的即时更新信息，并发出它的常规路由选择更新信息，通告网络A以2跳的距离可达。R2收到这个更新信息，认为出现了一条新路径到网络A。
3:R2告诉R1它能以3跳的距离到达网络A。
4:R1告诉R3它能以4跳的距离到达网络A。
5:这个循环将进行到跳数为无穷，在R I P中定义为1 6。一旦一个路由器达到无穷，它将声明这条路径不可用并从路由表中删除此路径。由于记数到无穷大问题，路由选择信息将从一个路由器传到另一个路由器，每次段数加一。路由选择环路问题将无限制地进行下去，除非达到某个限制。这个限制就是R I P的最大跳数。当路径的跳数超过1 5，这条路径就从路由表中删除。
第一步：各个路由器完成基本配置，R2的路由表如下：
R2#sh ip route
R 1.1.1.0/8 [120/1] via 12.1.1.1, 00:00:01, Serial1/0
23.1.1.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/1
12.1.1.0/24 is subnetted, 1 subnets
C 12.1.1.0 is directly connected, Serial1/0
R 13.1.1.0/8 [120/1] via 23.1.1.3, 00:00:23, Serial1/1
[120/1] via 12.1.1.1, 00:00:01, Serial1/0
网络1.1.1.0是学自R1的
第二步：被动R1的s1/1接口，令R2学到网络A是来自R3，而不是R1，被动接口只能接受RIP更新，但是不能发送RIP更新
大约4分钟后，R2的路由表如下：
R1(config)#router rip
R1(config-router)#passive-interface s1/1
R2#show ip route
R 1.1.1.0/8 [120/2] via 23.1.1.3, 00:00:06, Serial1/1
23.1.1.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/1
12.1.1.0/24 is subnetted, 1 subnets
C 12.1.1.0 is directly connected, Serial1/0
R 13.1.1.0/8 [120/1] via 23.1.1.3, 00:00:22, Serial1/1
现在R2学到1.1.1.0的网络是来自R3了
第三步：把R1的s1/0的接口也被动，且断开lookback0接口。且打开个各个路由器的debug ip rip
R1(config)#router rip
R1(config-router)#passive-interface s1/0
R1(config)#int loopback 0
R1(config-if)#shutdown
第四步：直到R1收来1.1.1.0的网络是来自R2后，再取消R1被动s1/0接口。
R1#sh ip route
R 1.1.1.0/8 [120/3] via 12.1.1.2, 00:00:01, Serial1/1
R 23.1.1.0/8 [120/1] via 13.1.1.3, 00:00:19, Serial1/0
[120/1] via 12.1.1.2, 00:00:01, Serial1/1
12.1.1.0/24 is subnetted, 1 subnets
C 12.1.1.0 is directly connected, Serial1/1
13.1.1.0/24 is subnetted, 1 subnets
C 13.1.1.0 is directly connected, Serial1/0
R1现在的路由表学到的1.1.1.0网络是来自R2的
R1(config)#router rip
R1(config-router)#no passive-interface s1/0
第五步：通过上面的一系列设置，1.1.1.0这个网络已经在拓扑上出现R1―R3―R2―R1这样的路由环。下面我们看看debug信息：
R3#debug ip rip
*Mar 9 00:49:27.839: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (23.1.1.3) #----发送到R2
*Mar 9 00:49:27.839: RIP: build update entries
*Mar 9 00:49:27.843: network 1.1.1.0 metric 2
*Mar 9 00:49:27.843: network 13.1.1.0 metric 1
R3#
*Mar 9 00:49:39.335: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:49:39.339: 1.1.1.0 in 4 hops #------------------接收来自R1为4跳
*Mar 9 00:49:39.339: 12.1.1.0 in 1 hops
*Mar 9 00:49:41.343: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:49:41.343: RIP: build flash update entries
*Mar 9 00:49:41.347: network 1.1.1.0 metric 5
R3#
*Mar 9 00:49:45.463: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:49:45.463: 1.1.1.0 in 7 hops
*Mar 9 00:49:47.463: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:49:47.463: RIP: build flash update entries
*Mar 9 00:49:47.463: network 1.1.1.0 metric 8
R3#
*Mar 9 00:49:51.347: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:49:51.347: 1.1.1.0 in 10 hops
*Mar 9 00:49:53.355: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:49:53.355: RIP: build flash update entries
*Mar 9 00:49:53.359: network 1.1.1.0 metric 11
*Mar 9 00:49:53.507: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:49:53.507: RIP: build update entries
*Mar 9 00:49:53.511: network 1.1.1.0 metric 11
*Mar 9 00:49:53.511: network 13.1.1.0 metric 1
R3#
*Mar 9 00:49:57.387: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:49:57.391: 1.1.1.0 in 13 hops
R3#
*Mar 9 00:49:59.395: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:49:59.395: RIP: build flash update entries
*Mar 9 00:49:59.399: network 1.1.1.0 metric 14
R3#
*Mar 9 00:50:03.583: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:50:03.587: 1.1.1.0 in 16 hops (inaccessible) #---------------------------------跳数去到16，已经无限大，不可达了。于是R3马上向所有接口发送16跳不可达信息。↓↓
R3#
*Mar 9 00:50:05.587: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1 (13.1.1.3)
*Mar 9 00:50:05.587: RIP: build flash update entries
*Mar 9 00:50:05.591: network 1.1.1.0 metric 16
*Mar 9 00:50:05.591: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 00:50:05.595: RIP: build flash update entries
*Mar 9 00:50:05.595: network 1.1.1.0 metric 16
R3# --------------------同时R3也收到其他路由器发来不可达的信息------------
*Mar 9 00:50:07.603: RIP: received v2 update from 23.1.1.2 on Serial1/0
*Mar 9 00:50:07.607: 1.1.1.0 in 16 hops (inaccessible)
*Mar 9 00:50:07.863: RIP: received v2 update from 13.1.1.1 on Serial1/1
*Mar 9 00:50:07.867: 1.1.1.0 in 16 hops (inaccessible)
*Mar 9 00:50:07.867: 12.1.1.0 in 1 hops
(3)，水平分割
路由器通过一个被宣告进路由协议的接口所发送的路由更新报文中，不能包含通过该接口学习到的路由信息。
如上图所示是实验图
RIP 默认开启了水平分割
我们看看在串行链路中水平分割的情况。为了方便测试我们先断开R1的s1/0接口
R1(config)#int s1/0
R1(config-if)#shutdown
看看R2、R3的路由表
R2#sh ip route
R 1.1.1.0/8 [120/1] via 12.1.1.1, 00:00:17, Serial1/0
23.1.1.0/24 is subnetted, 1 subnets
可以看到R2学到了来自R1的1.1.1.0/8路由条目
R3#sh ip route
R 1.1.1.0/8 [120/2] via 23.1.1.2, 00:00:14, Serial1/0
23.1.1.0/24 is subnetted, 1 subnets
可以看到R3通过R2学到了1.1.1.0/8路由条目
现在通过debug ip rip看看R2的接收和发送情况。
R2#debug ip rip
RIP protocol debugging is on
*Mar 9 14:30:51.939: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 14:30:51.943: 1.1.1.0 in 1 hops #---接收到来自R1为1跳的路由
R2#
*Mar 9 14:30:53.695: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (12.1.1.2) #----发送到R1的更新
*Mar 9 14:30:53.695: RIP: build update entries
*Mar 9 14:30:53.699: network 23.1.1.0 metric 1
R2#
*Mar 9 14:31:03.315: RIP: sending v2 update to 224.0.0.9 via Serial1/1 (23.1.1.2) #----发送到R3的更新
*Mar 9 14:31:03.315: RIP: build update entries
*Mar 9 14:31:03.319: network 1.1.1.0 metric 2
*Mar 9 14:31:03.319: network 12.1.1.0 metric 1
从debug信息可以看到，R2从s1/0接收来自R1的1.1.1.0/8路由条目，再从s1/0发送更新时，只有23.1.1.0的网络，并没有包括了1.1.1.0的网络，但从s1/1发送到R3的更新时，却包括了1.1.1.0的网络，这就是说水平分割已经起作用了。
现在我们来看看关闭水平分割的情况
R1(config)#int s1/1
R1(config-if)#no ip split-horizon
R2(config)#int s1/0
R2(config-if)#no ip split-horizon
R2# debug ip rip
*Mar 9 14:46:03.123: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 14:46:03.127: 1.1.1.0 in 1 hops
*Mar 9 14:46:03.127: 12.1.1.0 in 1 hops
*Mar 9 14:46:03.127: 23.1.1.0 in 2 hops
*Mar 9 14:46:03.651: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 14:46:03.651: RIP: build update entries
*Mar 9 14:46:03.655: network 1.1.1.0 metric 2
*Mar 9 14:46:03.655: subnet 12.1.1.0 metric 1
*Mar 9 14:46:03.655: network 23.1.1.0 metric 1
从debug信息可以看到，关闭水平分割之后，R2从S1/0接收来自R1的1.1.1.0网络，又从S1/0发送回给R1。
现在我们来玩个小游戏，就是利用在R1、R2都关闭了水平分割，只用两个路由器就能产生一跳一跳地增加到16跳的效果，实验前都要打开R1、R2的debug ip rip来监测
（1）:先被动掉R1的s1/1接口
R1(config)#router rip
R1(config-router)#passive-interface s1/1
（2）:关闭loopback0接口
R1(config)#int loopback 0
R1(config-if)#shutdown
*Mar 9 15:13:25.567: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
（3）:取消R1的S1/1接口的被动
R1(config-if)#
R1(config-router)#no passive-interface s1/1
（4）:以R2为例看看它的debug ip rip信息
R2#debug ip rip
*Mar 9 15:13:54.551: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:13:54.551: RIP: build update entries
*Mar 9 15:13:54.555: network 1.1.1.0 metric 2
*Mar 9 15:13:54.555: subnet 12.1.1.0 metric 1
*Mar 9 15:13:54.555: network 23.1.1.0 metric 1
R2#
*Mar 9 15:14:10.347: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:10.351: 1.1.1.0 in 3 hops
*Mar 9 15:14:10.351: 12.1.1.0 in 1 hops
*Mar 9 15:14:10.355: 23.1.1.0 in 2 hops
R2#
*Mar 9 15:14:12.351: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:12.351: RIP: build flash update entries
*Mar 9 15:14:12.355: network 1.1.1.0 metric 4
R2#
*Mar 9 15:14:14.371: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:14.375: 1.1.1.0 in 5 hops
R2#
*Mar 9 15:14:16.375: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:16.375: RIP: build flash update entries
*Mar 9 15:14:16.379: network 1.1.1.0 metric 6
R2#
*Mar 9 15:14:18.495: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:18.499: 1.1.1.0 in 7 hops
R2#
*Mar 9 15:14:20.499: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:20.499: RIP: build flash update entries
*Mar 9 15:14:20.503: network 1.1.1.0 metric 8
R2#
*Mar 9 15:14:22.623: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:22.627: 1.1.1.0 in 9 hops
*Mar 9 15:14:22.763: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:22.763: RIP: build update entries
*Mar 9 15:14:22.767: network 1.1.1.0 metric 10
*Mar 9 15:14:22.767: subnet 12.1.1.0 metric 1
*Mar 9 15:14:22.767: network 23.1.1.0 metric 1
R2#
*Mar 9 15:14:24.895: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:24.899: 1.1.1.0 in 11 hops
R2#
*Mar 9 15:14:26.899: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:26.899: RIP: build flash update entries
*Mar 9 15:14:26.903: network 1.1.1.0 metric 12
R2#
*Mar 9 15:14:28.967: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:28.971: 1.1.1.0 in 13 hops
R2#
*Mar 9 15:14:30.971: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:30.971: RIP: build flash update entries
*Mar 9 15:14:30.975: network 1.1.1.0 metric 14
R2#
*Mar 9 15:14:33.023: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:33.027: 1.1.1.0 in 15 hops
R2#
*Mar 9 15:14:35.027: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:35.027: RIP: build flash update entries
*Mar 9 15:14:35.027: network 1.1.1.0 metric 16
R2#
*Mar 9 15:14:37.083: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 15:14:37.087: 1.1.1.0 in 16 hops (inaccessible)
R2#
*Mar 9 15:14:39.087: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 15:14:39.087: RIP: build flash update entries
*Mar 9 15:14:39.091: network 1.1.1.0 metric 16
上面就是两路由器间关闭水平分割，产生16跳的效果了，为了直观中间我删除了部分debug信息。
其实原理很简单：
我们把R1的S1/1出口passive 了，R1 就不能把lo 0被shutdown掉的信息以flash update 的形式发给R2，同时我们也把R1和R2的两接口的水平分割关了。
这时不知道情况的R2就发送更新对R1说：“你到lo 0是２跳”。而现在R1本身已经没有了与自身直连的lo 0的０跳信息，所以它别无选择的接受R2发来的２跳。
当我们取消R1的S1/1被动功能，R1再对R2说：“你到lo 0是３跳”。虽然比原来的差，且是从同一个接口收到的，但R2它也别无选择。
就这样它们之间就相互“欺骗”，如此循环直到出现１６跳。
(4)，带有毒性逆转的水平分割：
路由器通过一个被宣告进路由协议的接口所发送的路由更新报文中，可以包含通过该接口学习到的路由信息，但是这些路由信息metric值被置为无穷大（16条）
毒性逆转的规则是：从一个接口学习的路由会发送回该接口，但是已经被毒化，跳数设置为16跳，不可达。
实验步骤：
1：为了方便测试我们断开R1与R3链接的S1/0接口
R1(config)#int s1/0
R1(config-if)#shutdown
2：各个路由器全部路由都学到了，在各个路由器打开debug ip rip观察
3: 断开R1的loopback0接口
R1(config)#int loopback 0
R1(config-if)#shutdown
R1#debug ip rip
*Mar 9 17:18:08.811: RIP: received v2 update from 12.1.1.2 on Serial1/1
*Mar 9 17:18:08.815: 1.1.1.0 in 16 hops (inaccessible)
*Mar 9 17:18:08.815: 23.1.1.0 in 1 hops
R1#
*Mar 9 17:18:12.807: RIP: sending v2 update to 224.0.0.9 via Serial1/1 (12.1.1.1)
*Mar 9 17:18:12.807: RIP: build update entries
*Mar 9 17:18:12.811: network 1.1.1.0 metric 16
从接口S1/1收到，又出接口S1/1发出去，但已经标记为16跳不可达
R2#debug ip rip
*Mar 9 17:17:46.727: RIP: received v2 update from 12.1.1.1 on Serial1/0
*Mar 9 17:17:46.731: 1.1.1.0 in 16 hops (inaccessible)
R2#
*Mar 9 17:17:48.731: RIP: sending v2 flash update to 224.0.0.9 via Serial1/0 (12.1.1.2)
*Mar 9 17:17:48.731: RIP: build flash update entries
*Mar 9 17:17:48.735: network 1.1.1.0 metric 16
*Mar 9 17:17:48.735: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1 (23.1.1.2)
*Mar 9 17:17:48.739: RIP: build flash update entries
*Mar 9 17:17:48.739: network 1.1.1.0 metric 16
R2#
*Mar 9 17:17:50.799: RIP: received v2 update from 23.1.1.3 on Serial1/1
*Mar 9 17:17:50.803: 1.1.1.0 in 16 hops (inaccessible)
从信息也已经看到从同一个接口收到，也在同一个接口发出，但也是已经毒化
R3#debug ip rip
*Mar 9 17:18:07.551: RIP: received v2 update from 23.1.1.2 on Serial1/0
*Mar 9 17:18:07.555: 1.1.1.0 in 16 hops (inaccessible)
*Mar 9 17:18:07.555: 12.1.1.0 in 1 hops
R3#
*Mar 9 17:18:20.955: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (23.1.1.3)
*Mar 9 17:18:20.955: RIP: build update entries
*Mar 9 17:18:20.955: network 1.1.1.0 metric 16
R3的情况也是一样，从相同的接口接收和发送。
注意!!:以上的效果是不用关闭水平分割的，否则不能说明毒性逆转
(5)，触发更新
当拓扑发生改变的时候，如果该变化影响到路由信息，那么路由器就会无视更新计时器是否到期，立即发送RIP更新给所有的邻居变更的事项
触发更新的规则是：一旦检测到路由崩溃，立即组播路由刷新报文，而不等到下一刷新周期
下面我们就以R1、R2为例子做实验
1：完成基本配置，都学全路由后，我们在R1 打开debug ip rip和debug ip rip trigger
2: 先在R1的S1/1启动触发更新（ip rip triggered）
R1(config)#int s1/1
R1(config-if)#ip rip triggered
3：查看debug信息
R1#debug ip rip
RIP protocol debugging is on
R1#debug ip rip trigger
RIP trigger debugging is on
*Mar 9 18:26:55.963: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第一次请求
*Mar 9 18:26:55.963: RIP: Start poll timer from 12.1.1.1 on Serial1/1
*Mar 9 18:26:59.707: RIP-TIMER: sending timer on Serial1/1 expired
*Mar 9 18:26:59.999: RIP-TIMER: age timer expired
*Mar 9 18:27:00.247: RIP-TIMER: sending timer on Loopback0 expired
*Mar 9 18:27:00.963: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired #----第一次超时
*Mar 9 18:27:00.963: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第二次请求
*Mar 9 18:27:00.967: RIP: Start poll timer from source 12.1.1.1 on Serial1/1
R1#
*Mar 9 18:27:05.967: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired #----第二次超时
*Mar 9 18:27:05.967: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第三次请求
*Mar 9 18:27:05.967: RIP: Start poll timer from source 12.1.1.1 on Serial1/1
R1#
*Mar 9 18:27:09.999: RIP-TIMER: age timer expired
*Mar 9 18:27:10.967: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired #----第三次超时
*Mar 9 18:27:10.967: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第四次请求
*Mar 9 18:27:10.971: RIP: Start poll timer from source 12.1.1.1 on Serial1/1
R1#
*Mar 9 18:27:15.971: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired #----第四次超时
*Mar 9 18:27:15.971: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第五次请求
*Mar 9 18:27:15.975: RIP: Start poll timer from source 12.1.1.1 on Serial1/1
R1#
*Mar 9 18:27:19.999: RIP-TIMER: age timer expired
*Mar 9 18:27:20.975: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired #----第五次超时
*Mar 9 18:27:20.975: RIP: sending triggered request on Serial1/1 to 224.0.0.9 #----第六次请求
*Mar 9 18:27:20.979: RIP: Start poll timer from source 12.1.1.1 on Serial1/1
R1#
*Mar 9 18:27:25.979: RIP-TIMER: polling timer on Serial1/1(12.1.1.1) expired
*Mar 9 18:27:25.979: RIP: Poll 6 times on Serial1/1 thru 12.1.1.1 without any ack #----经过6次触发请求后还没有收到确认消息
R1#
*Mar 9 18:27:29.463: RIP-TIMER: sending timer on Serial1/1 expired
*Mar 9 18:27:29.463: RIP: sending v2 update to 224.0.0.9 via Serial1/1 (12.1.1.1) #---请求无效后，发送一个普通的组播更新
*Mar 9 18:27:29.467: RIP: build update entries
*Mar 9 18:27:29.467: network 1.1.1.0 metric 1
*Mar 9 18:27:29.467: network 13.1.1.0 metric 1
*Mar 9 18:27:29.999: RIP-TIMER: age timer expired
R1#
*Mar 9 18:27:32.895: RIP: received v2 update from 12.1.1.2 on Serial1/1
*Mar 9 18:27:32.899: 23.1.1.0 in 1 hops #----还可以收到R2来的信息，是因为R2始终在组播着他自己的RIP更新
从R1的debug调试信息中，显示的就是R1启动了触发更新试图与链路的另一端的R2建立触发更新关系。R1以5s为每个周期发送轮询（Poll）并等待确认，但发送了6个触发请求后还没有收到确认消息，那么整个轮询过程就认为超时，触发更新建立不成功，路由器R1等待下一个普通的更新时间，并组播一个普通RIP的更新。而在整个过程R2始终在组播着他自己的RIP更新。
4: 我们现在在R2也打开debug ip rip和debug ip rip，并且把R2的S1/1接口也启动触发更新（ip rip triggered）。
R2#debug ip rip
RIP protocol debugging is on
R2#debug ip rip trigger
RIP trigger debugging is on
R2(config)#int s1/0
R2(config-if)#ip rip triggered
*Mar 9 19:43:45.231: RIP: sending triggered request on Serial1/0 to 224.0.0.9 #----R2发送触发更新请求
*Mar 9 19:43:45.231: RIP: Start poll timer from 12.1.1.2 on Serial1/0
*Mar 9 19:43:45.347: RIP: received v2 triggered update from 12.1.1.1 on Serial1/0 #----由S1/0收到来自R1的触发更新
*Mar 9 19:43:45.351: RIP: sending v2 ack to 12.1.1.1 via Serial1/0 (12.1.1.2), #----R2通过S1/0接口向R1发送确认信息
flush, seq# 0
*Mar 9 19:43:45.355: RIP: Stop trigger rip poll timer for 12.1.1.2 on Serial1/0 #----停止向R1发送触发更新的轮询
*Mar 9 19:43:45.355: RIP: Trigger rip running on network 12.1.1.0 thru Serial1/0 #----透过S1/0接口在网络12.1.1.0上运行着RIP的触发更新
*Mar 9 19:43:45.359: RIP: 12.1.1.1 change state from DOWN to INIT
*Mar 9 19:43:45.359: RIP: send v2 triggered flush update to 12.1.1.1 on Serial1/0 with no route
*Mar 9 19:43:45.363: RIP: assigned sequence number 0 on Serial1/0
*Mar 9 19:43:45.363: RIP: start retransmit timer of 12.1.1.1
*Mar 9 19:43:45.363: 1.1.1.0 in 1 hops
*Mar 9 19:43:45.367: 13.1.1.0 in 1 hops
*Mar 9 19:43:45.443: RIP: received v2 triggered ack from 12.1.1.1 on Serial1/0
R2#
*Mar 9 19:43:45.447: RIP: 12.1.1.1 change state from INIT to LOADING
*Mar 9 19:43:45.447: RIP: send v2 triggered update to 12.1.1.1 on Serial1/0
*Mar 9 19:43:45.447: RIP: assigned sequence number 1 on Serial1/0
*Mar 9 19:43:45.451: RIP: build update entries
*Mar 9 19:43:45.451: route 8: network 23.1.1.0 metric 1
*Mar 9 19:43:45.455: RIP: Update contains 1 routes, start 8, end 8
*Mar 9 19:43:45.455: RIP: start retransmit timer of 12.1.1.1
*Mar 9 19:43:45.463: RIP: received v2 triggered ack from 12.1.1.1 on Serial1/0
seq# 1
*Mar 9 19:43:45.463: RIP: 12.1.1.1 change state from LOADING to FULL
*Mar 9 19:43:46.539: RIP-TIMER: age timer expired #----计数器超时
R2#
*Mar 9 19:43:53.259: RIP-TIMER: sending timer on Serial1/1 expired
*Mar 9 19:43:53.259: RIP: sending v2 update to 224.0.0.9 via Serial1/1 (23.1.1.2)
*Mar 9 19:43:53.263: RIP: build update entries
*Mar 9 19:43:53.263: network 1.1.1.0 metric 2
*Mar 9 19:43:53.263: network 12.1.1.0 metric 1
R2#
*Mar 9 19:43:55.491: RIP: received v2 update from 23.1.1.3 on Serial1/1
*Mar 9 19:43:55.495: 1.1.1.0 in 2 hops
*Mar 9 19:43:55.495: 13.1.1.0 in 1 hops
R2#
*Mar 9 19:43:56.539: RIP-TIMER: age timer expired
R2#
*Mar 9 19:44:06.539: RIP-TIMER: age timer expired
*Mar 9 19:44:07.383: RIP-TIMER: sending timer on Serial1/0 expired
从上面的debug信息，可以看到，由请求到轮询到确认是很短的时间的。
再就是触发状态从DOWN状态开始，经过INT和LOADING状态，最后到为FULL状态。
而后的就是进行路由信息的交换和更新确认了。而在输出信息的后面也出现了RIP更新计时器超时，做实验时候花多些时间，细心观察debug信息，R2会一直没有向R1发送新的更新和从R1那里接收新的更新。这就是RIP启用触发更新会关闭计时器的效果。
下面再看看R1和R2的路由表和RIP 数据库
R1#show ip route
1.1.1.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
R 23.1.1.0/8 [120/1] via 12.1.1.2, 00:10:05, Serial1/1
[120/1] via 13.1.1.3, 00:00:03, Serial1/0
12.1.1.0/24 is subnetted, 1 subnets
C 12.1.1.0 is directly connected, Serial1/1
13.1.1.0/24 is subnetted, 1 subnets
C 13.1.1.0 is directly connected, Serial1/0
R2#show ip route
R 1.1.1.0/8 [120/1] via 12.1.1.1, 00:10:40, Serial1/0
23.1.1.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/1
12.1.1.0/24 is subnetted, 1 subnets
C 12.1.1.0 is directly connected, Serial1/0
R 13.1.1.0/8 [120/1] via 12.1.1.1, 00:39:40, Serial1/0
[120/1] via 23.1.1.3, 00:00:14, Serial1/1
R1#show ip rip database
1.1.1.0/8 auto-summary
1.1.1.0/24 directly connected, Loopback0
12.1.1.0/8 auto-summary
12.1.1.0/24 directly connected, Serial1/1
13.1.1.0/8 auto-summary
13.1.1.0/24 directly connected, Serial1/0
23.1.1.0/8 auto-summary
23.1.1.0/8
[1] via 13.1.1.3, 00:00:06, Serial1/0
[1] via 12.1.1.2, 00:10:22 (permanent), Serial1/1
* Triggered Routes:
- [1] via 12.1.1.2, Serial1/1
R2#show ip rip database
1.1.1.0/8 auto-summary
1.1.1.0/8
[1] via 12.1.1.1, 00:11:14 (permanent), Serial1/0
* Triggered Routes:
- [1] via 12.1.1.1, Serial1/0
12.1.1.0/8 auto-summary
12.1.1.0/24 directly connected, Serial1/0
13.1.1.0/8 auto-summary
13.1.1.0/8
[1] via 23.1.1.3, 00:00:02, Serial1/1
[1] via 12.1.1.1, 00:11:14 (permanent), Serial1/0
* Triggered Routes:
- [1] via 12.1.1.1, Serial1/0
23.1.1.0/8 auto-summary
23.1.1.0/24 directly connected, Serial1/1
从上面的信息我们已经看到，路由表阴影部分的路由条目时间已经变得很大了，这是因为启动了触发更新学到的条目是永久（permanent）的，在R1、R2的RIP数据库也已经证明了。
(6)抑制计时器（hold down timer）
1：周期更新计时器周期更新计时器用于设置定期路由更新的时间间隔（一般为３０
s），在这个间隔里路由器发送一个自己路由表的完整拷贝到所有相邻的路由器。
2：无效计时器用于决定一个时间长度，即路由器在认定一个路由成为无效路由之前
所需要等待的时间（１８０s，实际情况往往略大于１８０s）．如果路由器在更新计时
器期间没有得到关于某个指定路由的任何更新消息，它将认为这个路由失效，这时就会
进入到无效计时器阶段．当这一情况发生时，这个路由器将会给它所有的邻居发送一个
更新消息以通知它们这个路由已经无效。
3：保持计时器用于设置路由信息被抑制的时间数量．当上述无效计时器计时完毕后，
就会进入到保持计数器阶段．也可理解为，当指示某个路由为不可达的更新数据包被接
受到时，路由器将会进入保持失效状态．这个状态将会一直持续到一个带有更好度量的
更新数据包被接受到或者这个保持计时器到期．默认时，它的取值是１８０s．在进入
到这个阶段的前６０s，会显示一个如下的路由信息possibly down，这时路由器并没有
直接删除这条路由信息，但记住，若此时该路由恢复正常通讯，路由表信息也不会更新，
在接下来的１２０s会起到一个保持网络稳定的作用。
4：刷新计时器用于设置某个路由成为无效路由并将它从路由表中删除的时间间隔（２
４０s）．这个计时器是刚开始就启动的，一直到保持计时器进行到６０s时，它将路由
表刷新．在将它（无效路由）从表中删除前，路由器会通告它的邻居这个路由即将消亡。
5:我们也可以用time basic来改变计时器的时间间隔。
timers basicupdate invalid holddown flush
(7)，异步更新
本文出自 “好好活着” 博客，转载请与作者联系！