zoukankan      html  css  js  c++  java
  • RIP的防环机制6种

    RIP 的防环机制共有6种:
    1.最大跳数
    2.水平分割
    3.毒化路由
    4.毒性逆转
    5.hold-down计时器
    6.触发更新
    联想:定时更新和触发更新的区别:
    · 定时更新:运行如RIP,IGRP等距离矢量协议的路由器以一定的时间间隔广播路由表的全部内容。
    RIP缺省情况下每隔30s向每个活跃接口广播所有路由。IGRP的缺省更新时间间隔是90s。
    触发更新:更新通过在网络发生变化时为等待到定时更新的时间点就立即发送更新,从
    而消除了定时更新带来的收敛延迟,快速更新发生在网络的结点和结点之间,减少了整
    个网络的收敛时间。
    以下针对每种更新方式,以实验的方式进行验证:
    l 最大跳数演示试验:

    R1上有一个环回口地址1.1.1.1/24位,全网起RIP V2协议,演示醉倒跳数的试验。

    R2 R3 #show ip route rip
    正常情况下R2的下一跳是R1的串口地址,R3的下一跳是R1的以太口地址。
    第一步:被动接口R1的以太网口R1(config-router)#pass fa0/0
    大约4分钟后,R3上看到的1.1.1.0/24的下一跳是R2过来的。
    第二步:把R1的s1/1的接口也被动掉,且断开lookback0接口。且打开个各个路由器的
    debug ip rip
    R1(config)#router rip
    R1(config-router)#passive-interface s1/1
    R1(config)#int loopback 0
    R1(config-if)#shutdown
    第三步:直到R1收到1.1.1.0的下一跳是R2时,打开s1/1的被动接口。
    R1(config-router)#do show ip route rip
    1.0.0.0/24 is subnetted, 1 subnets
    R 1.1.1.0 [120/3] via 172.16.1.3, 00:00:02, FastEthernet0/0
    通过上面的一系列设置,1.0.0.0这个网络已经在拓扑上出现R1-R2-R3-R1这样的路由
    环。下面我们看看上面的debug信息:
    此时R1,R2,R3的RIP数据库都呈现:
    R2#show ip rip database
    1.0.0.0/8 is possibly down
    1.1.1.0/24 is possibly down
    10.0.0.0/8 auto-summary
    10.1.12.0/24 directly connected, Serial1/0
    10.1.23.0/24 directly connected, Serial1/1
    10.1.34.0/26 is possibly down
    10.1.45.1/32 is possibly down
    172.16.0.0/16 auto-summary
    172.16.1.0/24
    [1] via 10.1.12.1, 00:00:19, Serial1/0
    [1] via 10.1.23.3, 00:00:11, Serial1/1
    注意:如果收不到这个路由,他立刻会在路由表中清除这条路由,但是仍然会在RIP的
    数据库中保留60s时间,60s过后,在RIP的数据库中也将被清除。


    l 水平分割实验:
    水平分割规则是:从一个接口学习到的路由不会再广播回该接口。
    此处有一点问题:


    如果同一个接口从不同地方收到了同一条路由信息,但是一个是metric=1,一个
    metric=2
    它会接收这条路由,并且从同一个接口发送出去。
    上面的说法应该是:从一个接口学习到的最优路由不会在发送回给接口。

    暂时先断开R1与R3之间的链路:此时R2,R3的目的网段1.1.1.0/24的路由条目如下:
    R2#show ip rout rip
    1.0.0.0/24 is subnetted, 1 subnets
    R 1.1.1.0 [120/1] via 10.1.12.1, 00:00:13, Serial1/0
    10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
    R 10.1.45.1/32 [120/1] via 10.1.12.1, 00:00:13, Serial1/0
    R 10.1.34.0/26 [120/1] via 10.1.12.1, 00:00:13, Serial1/0

    R3#sho ip route rip
    1.0.0.0/24 is subnetted, 1 subnets
    R 1.1.1.0 [120/2] via 10.1.23.2, 00:00:08, Serial1/0
    10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
    R 10.1.12.0/24 [120/1] via 10.1.23.2, 00:00:09, Serial1/0
    R 10.1.45.1/32 [120/2] via 10.1.23.2, 00:00:09, Serial1/0
    R 10.1.34.0/26 [120/2] via 10.1.23.2, 00:00:09, Serial1/0


    R2#
    *Jun 28 20:46:06.975: RIP: sending v2 update to 224.0.0.9 via Serial1/0
    (10.1.12.2)
    *Jun 28 20:46:06.975: RIP: build update entries
    *Jun 28 20:46:06.979: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0//向R1发送
    更新时没有包括1.1.1.0/24的更新
    R2#
    *Jun 28 20:46:30.151: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.23.2)
    *Jun 28 20:46:30.151: RIP: build update entries
    *Jun 28 20:46:30.155: 1.1.1.0/24 via 0.0.0.0, metric 2, tag 0//向R3发送更
    新时就带有1.1.1.0/24的路由条目
    *Jun 28 20:46:30.155: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 20:46:30.159: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
    *Jun 28 20:46:30.159: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
    从上面的debug信息可以看出:
    从debug信息可以看到,R2从s1/0接收来自R1的1.0.0.0/8路由条目,再从s1/0发送更新
    时,只有10.1.23.0的网络,并没有包括了1.0.0.0的网络,但从s1/1发送到R3的更新时,
    却包括了1.0.0.0的网络,这就是说水平分割已经起作用了。

    现在打开R1,R2的水平分割原则:
    R1(config-if)#no ip split-horizon
    R2(config-if)#no ip split-horizon
    *Jun 28 20:53:45.882: RIP: sending v2 update to 224.0.0.9 via Serial1/0
    (10.1.12.2)
    *Jun 28 20:53:45.882: RIP: build update entries
    *Jun 28 20:53:45.886: 1.1.1.0/24 via 10.1.12.1, metric 2, tag 0
    *Jun 28 20:53:45.886: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 20:53:45.890: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 20:53:45.890: 10.1.34.0/26 via 10.1.12.1, metric 2, tag 0
    *Jun 28 20:53:45.890: 10.1.45.1/32 via 10.1.12.1, metric 2, tag 0
    *Jun 28 20:54:03.482: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.23.2)
    *Jun 28 20:54:03.482: RIP: build update entries
    *Jun 28 20:54:03.486: 1.1.1.0/24 via 0.0.0.0, metric 2, tag 0
    *Jun 28 20:54:03.486: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 20:54:03.490: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
    *Jun 28 20:54:03.490: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
    从R1收到的更新,再次的发回给R1。
    从debug信息可以看到,关闭水平分割之后,R2从S1/0接收来自R1的1.0.0.0网络,又从
    S1/0发送回给R1。


    为了达到效果,先被动掉R1的s1/1口,接口关闭环回口1.1.1.1/24,然后取消R1的被动
    接口S1/1。
    R2#
    *Jun 28 20:57:55.694: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.23.2)
    *Jun 28 20:57:55.694: RIP: build update entries
    *Jun 28 20:57:55.698: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 20:57:55.698: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 20:57:55.702: 10.1.34.0/26 via 0.0.0.0, metric 2, tag 0
    *Jun 28 20:57:55.702: 10.1.45.1/32 via 0.0.0.0, metric 2, tag 0
    R2#
    *Jun 28 20:58:03.346: RIP: received v2 update from 10.1.23.3 on Serial1/1
    *Jun 28 20:58:03.350: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
    R2#
    *Jun 28 20:58:08.602: RIP: received v2 update from 10.1.12.1 on Serial1/0
    *Jun 28 20:58:08.606: 10.1.12.0/24 via 0.0.0.0 in 1 hops
    *Jun 28 20:58:08.606: 10.1.23.0/24 via 0.0.0.0 in 1 hops
    *Jun 28 20:58:08.606: 10.1.34.0/26 via 0.0.0.0 in 1 hops
    *Jun 28 20:58:08.610: 10.1.45.1/32 via 0.0.0.0 in 1 hops
    这样就在R1和R2上产生了环路。
    其实原理很简单:
    我们把R1的S1/1出口passive 了,R1 就不能把lo 0被shutdown掉的信息以flash update的形式发给R2,同时我们也把R1和R2的两接口的水平分割关了。这时不知道情况的R2就发送更新对R1说:“你到lo 0是2跳”。而现在R1本身已经没有了与自身直连的lo 0的0跳信息,所以它别无选择的接受R2发来的2跳。当我们取消R1的S1/1被动功能,R1再对R2说:“你到lo 0是3跳”。虽然比原来的差,且是从同一个接口收到的,但R2它也别无选择。就这样它们之间就相互“欺骗”,如此循环直到出现16跳。


    l 毒性逆转实验:
    毒性逆转的规则是:从一个接口学习的路由会发送回该接口,但是已经被毒化,跳数设
    置为16跳,不可达。
    试验拓扑同上:
    这个试验是关闭了水平分割原则的。
    *Jun 28 21:06:41.486: RIP: received v2 update from 10.1.12.2 on Serial1/1
    *Jun 28 21:06:41.490: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
    *Jun 28 21:06:39.418: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 21:06:39.418: RIP: build flash update entries
    *Jun 28 21:06:39.422: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0


    R2#
    *Jun 28 21:07:24.334: RIP: sending v2 update to 224.0.0.9 via Serial1/0
    (10.1.12.2)
    *Jun 28 21:07:24.334: RIP: build update entries
    *Jun 28 21:07:24.338: 1.1.1.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 21:07:24.338: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 21:07:24.342: 10.1.23.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 21:07:24.342: 10.1.34.0/26 via 10.1.12.1, metric 2, tag 0
    *Jun 28 21:07:24.346: 10.1.45.1/32 via 10.1.12.1, metric 2, tag 0
    R2#
    *Jun 28 21:07:26.134: RIP: received v2 update from 10.1.12.1 on Serial1/0
    *Jun 28 21:07:26.138: 1.1.1.0/24 via 0.0.0.0 in 16 hops (inaccessible)
    从上面可以看出:从信息也已经看到从同一个接口收到,也在同一个接口发出,但也是
    已经毒化(跳数是最大跳数)

    l 触发更新的理解:
    1.一旦有变化立刻发送更新(防环) 2.ip rip triggered 用于在低速链路上(串口),
    一般情况下不发送更新,有变化的时候才会发送,类似ospf的按需电路。相当于按需电
    信的周期性更新。
    触发更新和增量更新是互斥的。
    触发更新的规则是:一旦检测到路由崩溃,立即广播路由刷新报文,而不等到下一刷新
    周期
    在接口启动trigger的话,默认在RIP中会修改hold-down时间。
    timers basic 30 180 0 240
    先在R1的S1/1启动触发更新(ip rip triggered)
    R1(config)#int s1/1
    R1(config-if)#ip rip triggered
    查看debug信息
    R1(config-if)#
    *Jun 28 21:30:19.830: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:19.834: RIP: Start poll timer from 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:24.834: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    第一次请求超时
    *Jun 28 21:30:24.834: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:24.838: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:26.302: RIP-TIMER: age timer expired
    R1(config-if)#


    *Jun 28 21:30:29.838: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    第二次请求超时
    *Jun 28 21:30:29.838: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:29.842: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:34.842: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    第三次请求超时
    *Jun 28 21:30:34.842: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:34.846: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:36.302: RIP-TIMER: age timer expired
    *Jun 28 21:30:36.546: RIP: received v2 update from 10.1.12.2 on Serial1/1
    *Jun 28 21:30:36.550: 10.1.12.0/24 via 0.0.0.0 in 1 hops
    *Jun 28 21:30:36.550: 10.1.23.0/24 via 0.0.0.0 in 1 hops
    R1(config-if)#
    *Jun 28 21:30:39.846: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    第四次请求超时
    *Jun 28 21:30:39.846: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:39.850: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:44.850: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    第五次请求超时
    *Jun 28 21:30:44.850: RIP: sending triggered request on Serial1/1 to 224.0.0.9
    *Jun 28 21:30:44.854: RIP: Start poll timer from source 10.1.12.1 on Serial1/1
    R1(config-if)#
    *Jun 28 21:30:46.278: RIP-TIMER: sending timer on Serial1/1 expired
    *Jun 28 21:30:46.302: RIP-TIMER: age timer expired
    R1(config-if)#
    *Jun 28 21:30:49.854: RIP-TIMER: polling timer on Serial1/1(10.1.12.1) expired
    *Jun 28 21:30:49.854: RIP: Poll 6 times on Serial1/1 thru 10.1.12.1 without any
    ack第六次请求超时,并且没有收到对方的确认消息。
    R1(config-if)#
    *Jun 28 21:30:56.302: RIP-TIMER: age timer expired
    R1(config-if)#
    *Jun 28 21:31:02.290: RIP: received v2 update from 10.1.12.2 on Serial1/1
    *Jun 28 21:31:02.294: 10.1.12.0/24 via 0.0.0.0 in 1 hops
    *Jun 28 21:31:02.294: 10.1.23.0/24 via 0.0.0.0 in 1 hops
    R1(config-if)#
    *Jun 28 21:31:06.302: RIP-TIMER: age timer expired
    R1(config-if)#
    *Jun 28 21:31:14.646: RIP-TIMER: sending timer on Serial1/1 expired
    *Jun 28 21:31:14.646: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 21:31:14.646: RIP: build update entries

    *Jun 28 21:31:14.646: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 21:31:14.646: 10.1.23.0/24 via 10.1.12.2, metric 2, tag 0请求无效
    后,发送一次全网的更新消息。
    从R1的debug调试信息中,显示的就是R1启动了触发更新试图与链路的另一端的R2建立触发更新关系。R1以5s为每个周期发送轮询(Poll)并等待确认,但发送了6个触发请求后还没有收到确认消息,那么整个轮询过程就认为超时,触发更新建立不成功,路由器R1等待下一个普通的更新时间,并广播一个普通RIP的更新。而在整个过程R2始终在广播着他自己的RIP更新。
    此时打开R1的环回口:
    *Jun 28 21:42:53.110: RIP: sending request on Loopback0 to 224.0.0.9
    *Jun 28 21:42:53.114: RIP: sending request on Loopback0 to 224.0.0.9
    *Jun 28 21:42:53.126: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
    our addresses)
    *Jun 28 21:42:53.130: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
    our addresses)
    R1#
    *Jun 28 21:42:53.822: %SYS-5-CONFIG_I: Configured from console by console
    R1#
    *Jun 28 21:42:55.090: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
    R1#
    *Jun 28 21:42:55.110: RIP: sending v2 flash update to 224.0.0.9 via Loopback0
    (1.1.1.1)
    *Jun 28 21:42:55.110: RIP: build flash update entries - suppressing null update
    *Jun 28 21:42:56.090: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,
    changed state to up
    R1#
    *Jun 28 21:42:56.302: RIP-TIMER: age timer expired
    R1#
    *Jun 28 21:42:57.534: RIP-TIMER: neighbor sending timer of 10.1.12.2 expired
    *Jun 28 21:42:57.534: RIP:retransmit seq# 7
    *Jun 28 21:42:57.534: RIP: build update entries
    *Jun 28 21:42:57.538: route 83: 10.1.12.0/24 metric 1, tag 0
    *Jun 28 21:42:57.538: route 86: 10.1.23.0/24 metric 2, tag 0
    *Jun 28 21:42:57.542: RIP: Update contains 2 routes, start 83, end 86
    *Jun 28 21:42:57.542: RIP: Starting triggered retrans timer waiting on neighbor
    10.1.12.2's ack.
    *Jun 28 21:42:59.326: RIP-TIMER: sending timer on FastEthernet0/0 expired
    *Jun 28 21:43:06.254: RIP-TIMER: sending timer on Serial1/1 expired
    *Jun 28 21:43:06.302: RIP-TIMER: age timer expired

    可以看到R1立即发送触发更新给R2
    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
    *Jun 28 21:39:52.878: RIP: received v2 triggered request from 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.878: RIP: Trigger rip running on network 10.0.0.0 thru Serial1/0
    *Jun 28 21:39:52.882: RIP: 10.1.12.1 change state from DOWN to INIT
    *Jun 28 21:39:52.882: RIP: 10.1.12.1 change state from INIT to LOADING
    *Jun 28 21:39:52.886: RIP: send v2 triggered flush update to 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.886: RIP: assigned sequence number 0 on Serial1/0
    *Jun 28 21:39:52.890: RIP: Update contains 2 routes, start 25, end 27
    *Jun 28 21:39:52.890: RIP: received v2 triggered request from 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.894: RIP: 10.1.12.1 change state from LOADING to INIT
    *Jun 28 21:39:52.894: RIP: 10.1.12.1 change state from INIT to LOADING
    *Jun 28 21:39:52.898: RIP: send v2 triggered flush update to 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.898: RIP: assigned sequence number 1 on Serial1/0
    *Jun 28 21:39:52.902: RIP: Update contains 2 routes, start 25, end 27
    *Jun 28 21:39:52.902: RIP: received v2 triggered update from 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.922: RIP: received v2 triggered request from 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.926: RIP: 10.1.12.1 change state from LOADING to INIT
    *Jun 28 21:39:52.926: RIP: 10.1.12.1 change state from INIT to LOADING
    *Jun 28 21:39:52.926: RIP: send v2 triggered flush update to 10.1.12.1 on
    Serial1/0
    *Jun 28 21:39:52.930: RIP: assigned sequence number 2 on Serial1/0
    *Jun 28 21:39:52.930: RIP: Update contains 2 routes, start 25, end 27
    *Jun 28 21:39:52.998: RIP: received v2 triggered ack from 10.1.12.1 on Serial1/0

    l hold-down实验:
    1:R1#debug ip routing

    R1#debug ip rip
    2:在R1上,做个访问列表,不接收来自R2的rip数据包
    R1(config)#access-list 110 deny udp any any eq rip
    R1(config)#access-list 110 permit ip any any
    R1(config-if)#ip access-group 110 in
    使用默认的时间,调试过程时间较长,我们可以通过修改timer来使调试的结果更加明
    显。
    R1(config)#int s1/1
    R1(config-if)#no ip access-group 110 in
    R1(config-router)#timer basic ?
    <0-4294967295> Interval between updates
    R1(config-router)#timer basic 5 ?
    <1-4294967295> Invalid
    R1(config-router)#timer basic 5 10 ?
    <0-4294967295> Holddown
    R1(config-router)#timer basic 5 10 15 ?
    <1-4294967295> Flush
    R1(config-router)#timer basic 5 10 15 20
    R2(config)#router rip
    R2(config-router)#timer basic 5 10 15 20
    *Jun 28 22:05:38.330: RIP: sending v2 flash update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 22:05:38.330: RIP: build flash update entries
    *Jun 28 22:05:38.330: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:38.334: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:38.338: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
    our addresses)
    *Jun 28 22:05:39.378: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
    *Jun 28 22:05:39.378: RIP: build update entries
    *Jun 28 22:05:39.378: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:39.378: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 22:05:39.382: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:39.3
    R1(config-if)#82: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of our
    addresses)
    *Jun 28 22:05:39.894: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 22:05:39.894: RIP: build update entries
    *Jun 28 22:05:39.898: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 22:05:39.898: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0


    *Jun 28 22:05:39.898: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
    R1(config-if)#
    *Jun 28 22:05:43.830: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
    *Jun 28 22:05:43.830: RIP: build update entries
    *Jun 28 22:05:43.834: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:43.834: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 22:05:43.838: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:43.842: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
    our addresses)
    R1(config-if)#
    *Jun 28 22:05:44.878: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 22:05:44.878: RIP: build update entries
    *Jun 28 22:05:44.882: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 22:05:44.882: 2.2.2.0/24 via 0.0.0.0, metric 16, tag 0
    *Jun 28 22:05:44.886: 10.1.23.0/24 via 0.0.0.0, metric 16, tag 0
    R1(config-if)#
    *Jun 28 22:05:46.326: RT: delete subnet route to 2.2.2.0/24
    *Jun 28 22:05:46.326: RT: NET-RED 2.2.2.0/24
    *Jun 28 22:05:46.330: RT: delete network route to 2.0.0.0
    *Jun 28 22:05:46.330: RT: NET-RED 2.0.0.0/8
    *Jun 28 22:05:46.334: RT: delete subnet route to 10.1.23.0/24
    *Jun 28 22:05:46.334: RT: NET-RED 10.1.23.0/24
    R1(config-if)#
    *Jun 28 22:05:48.798: RIP: sending v2 update to 224.0.0.9 via Loopback0 (1.1.1.1)
    *Jun 28 22:05:48.798: RIP: build update entries
    *Jun 28 22:05:48.802: 10.1.12.0/24 via 0.0.0.0, metric 1, tag 0
    *Jun 28 22:05:48.806: RIP: ignored v2 packet from 1.1.1.1 (sourced from one of
    our addresses)
    *Jun 28 22:05:49.654: RIP: sending v2 update to 224.0.0.9 via Serial1/1
    (10.1.12.1)
    *Jun 28 22:05:49.654: RIP: build update entries
    *Jun 28 22:05:49.658: 1.1.1.0/24 via 0.0.0.0, metric 1, tag 0

    总结:在距离矢量路由协议里面,路由器会将它学习的整张路由表信息更新发出去,R
    ip使用4种计时器来管理它的性能:
    1:周期更新计时器周期更新计时器用于设置定期路由更新的时间间隔(一般为30
    s),在这个间隔里路由器发送一个自己路由表的完整拷贝到所有相邻的路由器。
    2:无效计时器用于决定一个时间长度,即路由器在认定一个路由成为无效路由之前
    所需要等待的时间(180s,实际情况往往略大于180s).如果路由器在更新计时
    器期间没有得到关于某个指定路由的任何更新消息,它将认为这个路由失效,这时就会
    进入到无效计时器阶段.当这一情况发生时,这个路由器将会给它所有的邻居发送一个
    更新消息以通知它们这个路由已经无效。
    3:保持计时器用于设置路由信息被抑制的时间数量.当上述无效计时器计时完毕后,
    就会进入到保持计数器阶段.也可理解为,当指示某个路由为不可达的更新数据包被接
    受到时,路由器将会进入保持失效状态.这个状态将会一直持续到一个带有更好度量的
    更新数据包被接受到或者这个保持计时器到期.默认时,它的取值是180s.在进入
    到这个阶段的前60s,会显示一个如下的路由信息possibly down,这时路由器并没有
    直接删除这条路由信息,但记住,若此时该路由恢复正常通讯,路由表信息也不会更新,
    在接下来的120s会起到一个保持网络稳定的作用。
    4:刷新计时器用于设置某个路由成为无效路由并将它从路由表中删除的时间间隔(2
    40s).这个计时器是刚开始就启动的,一直到保持计时器进行到60s时,它将路由
    表刷新.在将它(无效路由)从表中删除前,路由器会通告它的邻居这个路由即将消亡。
    5:我们也可以用time basic 来改变计时器的时间间隔。
    timers basic update invalid holddown flush

  • 相关阅读:
    Ubuntu apt常用命令
    PHP 图片操作(按照指定尺寸压缩,按照比例裁剪)
    Django简介
    浅议SNMP安全、SNMP协议、网络管理学习
    Linux下dmesg命令处理故障和收集系统信息的7种用法
    syslog之三:建立Windows下面的syslog日志服务器
    syslog之二:syslog协议及rsyslog服务全解析
    syslog之一:Linux syslog日志系统详解
    syslog简单配置介绍
    ethtool工具使用实例
  • 原文地址:https://www.cnblogs.com/cyrusxx/p/12562853.html
Copyright © 2011-2022 走看看