ICMP重定向字段的路由重定向实验
ICMP的重定向字段，被路由器用于通知主机去往目标的最佳网关，是数据链路上的另一台路由器。
实验目的：
1. 验证重定向。
2. 重定向对主机的数据转发的影响。
3. 关闭重定向后，数据转发过程。
实验拓扑：
实验设计：
1. R2、R3、R4、R5运行RIPv2协议，R1关闭路由功能，将默认网关指向R2
2. R4、R5上各有环回接口，IP分别为 4.4.4 .4、5.5.5.5，所有IP地址使用/24位地址。
3. 在验证过重定向后，关闭R 2 F 0/0的路由重定向功能，通过抓包，查看数据转发路径。
实验过程：
各路由器的配置在此就不写了，直接来验证实验结果。
首先先对拓扑进行分析，从拓扑上看，R1发往R4的数据，其最短路径应为R1—R3——R4；R1发往R5的数据，其最短路径应为R1—R2—R5。我们通过抓包，来分别检验到R4，R5的数据转发路径。当然在开始前要做些准备工作：
1. 在R1上使用debug ip icmp命令来开启debug信息。
2. 关闭R 2 F 0/0接口的路由重定向功能，应为该功能是默认开启的，命令如下：
1.关闭R2路由重定向功能时的数据传输路径
1.1 在R1上ping 5.5.5 .5
ping通后，看看抓包的结果，查看R1的F0/0口即可
图1 R1 ping请求抓包
图2 R1 ping应答抓包
从请求及应答包的二层头部可以看出，R1的数据发向了R2，因为R2运行有RIP协议，故数据包将由R2转给R5。
1.2 在R1上ping 4.4.4 .4
图3 R1 ping 4.4.4 .4 请求抓包
图4 R1 ping 4.4.4 .4 应答抓包
为了更好的说明问题，再在R 3 f 0/0上进行抓包
图5 R3上抓取的ping请求包
图6 R3上抓取的ping应答包
由图3可看出，R1向R4的ping请求首先发向了ca00.0518.0000（R2），由图4可看出，直接向R1转发此次ping应答的是ca02.0518.0000（R3）。
由图5可看出，ca01.0518.0000（R2）发送过来一个ping请求，由图6可看出，对于这个ping请求，做出的应答R3直接发向了ca00.0518.0000（R1）。
意即，当关闭重定向时，关于此次ping的全过程的路径是R1—R2—R3—R4（数据到达R4，开始回包）—R3—R1。一去一回是所经过的路径不一样，也就是产生了不对称的流量。同时，不进行重定向，在有时间间隔的ping过程中，存在丢包显现，意即数据链路的可靠性较低。
2.开启R2的路由重定向功能
因为路由重定向功能主要是针对于去往R4的数据流量，故可不再进行ping R5的实验。
R1 ping 4.4.4 .4，结果如图7。由图7中可看出，当R1 ping 4.4.4.4后，产生了一条重定向提示：接收到来自123.1.1.2的重定向信息—去往4.4.4.4使用网关123.1.1.3。
图7 R1 ping 4.4.4 .4的debug信息
接着，在查看一下R1此时的路由表，如图8。
图8 R1路由表
此时，可发像，R1的缺省网关仍为123.1.1.2，只是路由表中多了一条明细信息，将去往 4.4.4 .4的网关指向了123.1.1.3。
下面将34.1.1.3、34.1.1.4也ping通，通时再ping一下34.1.1.0/24网段的其他地址，看看R1路由表信息，如图9。
图9 R1路由表
由图9可看出，虽然，34.1.1.5及34.1.1.6是不存在的主机地址，但是仍被重定向到了R3。这是因为R2使用的是RIP协议，拥有到达34.1.1.0/24及 4.4.4 .0/24网段的路由，因此在R2查看过自己路由表后，会将所有去往34.1.1.0/24及 4.4.4 .0/24网段的数据全部重定向到R3。在路由表中Last Use是距上一次使用时的时间，Total uses应该是使用的频次。
在进行下一步的路径验证之前，我们先看一下抓包工具抓出来的重定向ICMP包，如图10。
从图10中，从而三层头部信息中可知这是有R2发给R1的信息，在ICMP消息中，可看出类型为5，代码为1，校验和为0x2b19，重定向到123.1.1.1，再其后便表明为哪个地址进行的重定向。
图10 重定向ICMP抓包
现在开始进行路劲验证，同样还是通过分析抓到的ping包来进行，如图11～14。
图11 ping R4的请求包
图 12 ping R4的应答包
图 13 ping R5的请求包
图 14 ping R5的应答包
由图11、12可看出，去往R4的流量均直接使用R3进行传输，而不再使用R2，即网关被重定向到R3；由图13、14可看出，去往R5的流量仍有R2进行处理，即网关仍未R2。
3.一个解决路由从定向问题的方法
卷一中提供了一个避免路由重定向的方法，就是主机将网关指向自己的接口，下面开始验证一下，结果如图15、16所示。
图15 R1 ping R5（有缺省网关）
图 16 R2 debug信息
由图15中debug信息可知，数据包已经形成并发送到f0/0口（网关），而从图16 R2的debug信息中，却没有发现有数据经过，且也为接受到ARP的请求。由此可是，在用路由器模拟主机的实验环境下，这个解决方案是不成立的。但是我可以肯定的说，当主机将网关指向自己的以太网口的时，再ping不同网段的的主机是会发出ARP请求的，也就是说真实主机将网关指向自己的时候，在这种情况向的确可以避免路由重定向。关于主机将网关指向自己时的ARP实验结果，见下次实验。
当然，在这中路由器模拟主机的环境下，采用卷一中的提示，避免路由重定向也是可实现的。通过上一次的代理ARP实验可知，当用路由器模拟的主机在不指网关的时候，要与不同网段数据通信的时候也是会发送ARP请求的。因此，要先将R1的默认网关清掉，然后再ping R5，结果如图17所示。
由图17中可发现，当R1 ping 5.5.5 .5的时候，首先发送了关于5.5.5.5的MAC地址的ARP查询，第一个包由于还未接到应答，不知道二层头部信息，因此封装失败。×××的框中显示，R1收到的关于5.5.5.5的ARP应答，指明5.5.5.5的MAC地址是ca01.0518.0000（R2的MAC地址，因为默认代理ARP功能是打开的）。同样，ping 4.4.4.4的时候，R1也会发送ARP查询，MAC地址将由R3来代理，如图17中的ARP表，意即去往R4的数据将交由R3来转发。
这种做法的确避免了路由重定向，不过却加重了网络的负担，因为ARP请求使用的是广播，而在指明网关后，使用的均为单播信息。
另外需说明一点，在此实验中，R1发出了ARP请求，而R2、R3均有到达两个网段的路由，只从这点考虑的话，R1的每个ARP请求应该会接到两个ARP应答。但是实际上R1每个ARP请求只收到了一个准确的最近网关的ARP代理应答，而通过抓包也发现，R2、R3均未为要使用接受ARP请求的端口发送数据的ARP请求做应答。即R2未给向 4.4.4 .4的请求做应答，因为去往4.4.4.4的数据让要从f0/0口（接受4.4.4.4 ARP请求的端口）发出；同样R3未给向5.5.5.5的请求做应答。这也就是说路由器的代理ARP功能是为其它端口进行代理，也就是说当路由器判定数据让要从接受ARP请求的端口转发，将不会应答此请求。
由以上过程，我又想到一个实验，即如果R2、R3为同一个网络开启了负载均衡，那么R1会接受谁的ARP代理，此实验留待下次解决。
图 17 R1 ping R5 debug信息（无网关）
总结
1. 当路由器从一个接口接到一个数据，经查询过路由表，判定仍要从接收该数据接口发送该数据时，将会向原目标发送重定向的ICMP消息。
2. 不使用路由重定向功能，会造成不对称流量，并且链路可靠性降低。
3. 主机将网关指向自己可避免路由重定向的问题，但会造成ARP流量的增加。
4. 路由器模拟主机，在配置缺省网关（即使网关指向自己）之后，将不会发出不同网段的ARP请求，这与未配置网关的主机相同；而主机在将网关指向自己之后，会发出不同网段的ARP请求，这与未配置缺省网关的路由器模拟的主机相同。
5. 路由器的代理ARP功能是为其它端口进行代理的，也就是说当路由器判定数据仍要从接受ARP请求的端口转发时，将不会应答此请求。
留待解决问题
1. 主机将网关指向自己后，进行不同网段ARP查询的实验。
2. 当一台模拟主机的路由器连到两台对同一网络进行了负载均衡配置的网络，代理ARP情况如何？