验证EIGRP重传机制

本地路由器在规定时间内没有收到邻居的ack确认信息,需要重传。在组播发送数据包的时候,该数据包的单播拷贝会放进一个重传队列中进行排队,一旦这个数据包发送失败,即没有收到邻居的ack确认,那么这个拷贝会被再次发送出去,而触发这个动作的时限就是RTO。如果重传16次没有收到确认,这个邻居就宣布无效。

在R2上限制EIGRP报文,观察RTP--EIGRP的16次单播重传。

首先,R2上查看邻居表:

做如下配置:

R2(config)#ip access-list extended BLOCK_EIGRP

R2(config-ext-nacl)#deny eigrp any any

R2(config-ext-nacl)#permit ip any any

R2(config-ext-nacl)#exit

R2(config)#int s1/0

R2(config-if)#ip access-group BLOCK_EIGRP in

在R1上开debug eigrp transmit,贴出output:

R1向R2(12.1.1.2)发送单播hello包,5s一次。

此时R2中邻居表中已经没有了R1,但R1的邻居表仍然有R2。因为R1仍能收到R2发送的EIGRP hello数据包,而R2在s1/0口对EIGRP报文做了入方向的block。

同时,R1的邻居表中,队列计数异常(不为零):

在该输出中,SRTT=1(由于建邻居出了问题,没有计算出SRTT),而且注意RTO=5000ms(正常值为SRTT的6倍)。

经过16次重传,出来一下log,邻居12.1.1.2已经down掉:

时间: 2024-10-07 19:03:10

验证EIGRP重传机制的相关文章

通过packetdrill构造的包序列理解TCP快速重传机制

TCP的逻辑是极其复杂的,其学习曲线虽然很平缓但其每一步都是异常艰难,好在这些都是体力活,只要肯花时间也就不在话下了.想彻底理解一个TCP的机制,有个四部曲:1.读与其相关的RFC:2.看Linux协议栈的TCP实现:3.通过抓包以及其它工具来确认事实就是如此:4.解决一个与之相关的网络问题.经历了以上四步骤,相信任何人都可以在相关领域内稍微装逼一把了...        本文的内容是TCP快速重传机制,但是与其它文章不同的是,本文并不剖析源码实现,也不翻译RFC,更不是原理性介绍,而是通过一个

TCP的重传机制

接收端不会主动请求重传.发送端会一直等待回应ACK,当接收端没有回应的时候.如果 一个特定的超时之后,重传数据包.这就是ARQ自动重传请求. Stop-and-wait ARQ Go-Back-N ARQ Selective Repeat ARQ TCP的重传机制

【原创】TCP超时重传机制探索

TCP超时重传机制探索 作者:tll (360电商技术) 1)通信模型 TCP(Transmission Control Protocol)是一种可靠传输协议.在传输过程中当发送方(sender)向接收方(receiver)发送的数据丢失时,将引起发送方向接收方重传丢失的数据包. 其通信模型例如以下: wx_fmt=png" data-ratio="1.5138121546961325" data-w="362" _src="https://mm

TCP超时与重传机制

TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制.其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号.  这里比较重要的是重传超时时间,怎样设置这个定时器的时间(RTO),从而保证对网络资源最小的浪费.因为若RTO太小,可能有些报文只是遇到拥堵或网络不好延迟较大而已,这样就会造成

TCP协议的确认重传机制

TCP协议是面向连接的传输层协议,TCP的传输特点具有可靠性,它具有面向连接服务来确保可靠稳定传输,而确认重传机制是TCP协议保证可靠稳定传输最重要的机制,他包括累计确认.超时时间计算.快速重传等几个方面. 确认重传机制 在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号. 1.累计确认 累计确认就是TCP协议的确认方法,TCP使用可变长度报文段来发送数据,重传时,报文段数据可能会比原报文段

7、EIGRP查询机制导致的问题及防范

1.查询机制导致的问题 2.防范措施 防范措施一,汇总路由 防范措施二,在EIGRP路由进程下配置eigrp stub

Android事件分发机制实例验证

Android事件分发机制实例验证 欢迎转载,转载请注明原文出处http://blog.csdn.net/lavor_zl/article/details/51198634,谢谢. 事件分发机制的学习主要来自下面两篇博文: Android事件传递机制 Android 编程下 Touch 事件的分发和消费机制 这两篇博文写的非常好,但是看完了这两篇博文还是有一些不理解的地方,缺少一丝明悟.于是亲自写下几种情况的代码,来看事件分发的结果,从而验证事件分发机制.验证完后瞬间有了一种明悟,感觉豁然开朗.

Android艺术开发探索——第二章:IPC机制(下)

Android艺术开发探索--第二章:IPC机制(下) 我们继续来讲IPC机制,在本篇中你将会学习到 ContentProvider Socket Binder连接池 一.使用ContentProvider ContentProvider是Android中提供的专门用来不同应用之间数据共享的方式,从这一点来看,他天生就是适合进程间通信,和Messenger一样,ContentProvider的底层实现同样也是Binder,由此可见,Binder在Android系统中是何等的重要,虽然Conten

05   EIGRP

发送路由条目更新路由表的是距离矢量 发送链路状态信息更新路由表的是链路状态 分类:IGP.高级距离矢量.支持VLSM/CIDR.支持多种路由协议.快速收敛 组播更新:RIP:224.0.0.9 EIGRP:224.0.0.10 OSPF:224.0.0.5 224.0.0.6 EIGRP的功能和属性 1.快速汇聚:EIGRP采用DUAL来实现快速汇聚 2.部分更新:EIGRP发送部分更新而不是定期更新,且仅在路由的路径或度量值发生改变时才发送.更新中只包含已变化的链路的信息,而不是整个路由表.此