EIGRP包的hold time超时和RTO超过16后的结果是一样么？

kaiery

EIGRP holdtime超时还没有收到对方的hello包，是邻居关系DOWN掉？
那EIGRP的更新包重发16次还没收到确认，也是一样down邻居么？效果都一样哦？

CA-IOS

应该不一样，当发送一个组播报后，没有收到应到，再转到发送单播报，从组播到单播的时间由组播计时器决定，而重发16个单播时间加上组播时间返回时间就是SRTT了，所以真正意义上的hello holdtime应该与此不一样。

shaozhe

cq920103

16次重传是建立在需要ack确认的包的情况，是rtp协议中的规则，只是由于eigrp使用了rtp机制传送报文，所有感觉这两个是矛盾的，其实不然，你可以看成两个保障，就是其中一个超时都要down掉邻居。

cq920103

CA-IOS 发表于 2012-11-5 07:39
应该不一样，当发送一个组播报后，没有收到应到，再转到发送单播报，从组播到单播的时间由组播计时器决定， ...

那个消息的组播需要回复？还是说收到对方的组播？

yanjin1991

hold time 是秒为单位，srtt是毫秒为单位，组播加上16次的单播的时间应该会比保持时间短，也有可能长，如果16次后还没收到ACK，重置邻居，重新hello包建立邻居。在保持时间到期前即可判断邻居是否还存在，相当于是一种优化吧
小弟刚学，不对之处还忘多多指点

zhuliang325

hodl time 时间是在是收不对方hello包情况下采用倒计时的方式 一旦holdtime时间为0 立刻down掉邻居 hello是不可靠的包 是组播发送 没有单播的确认 16次重传实在update 时候  eigrp 以组播的方式发送一组更新如果没收到邻居的单播确认包 便会采用单播方式重新发送16次 16次还没收到邻居单播确认包 邻居关系则down掉 如果组播方式的hello 还是可以相互收到的 还是会建立邻居关系 当邻居关系建立 立马发送组播更新 这个更新是所有路由 而不是之前的变动路由 如果还是没有收到确认 还是会重传16次 并把这些路由置不可达  组播切换到单播是由RT0指定 单播包的放松间隔是由SRTT决定 这俩个时间是cisco私有算法 没有公开

zhuliang325

只有update Query Reply 是可靠包 组播的时候才需要单播的确认