因为关于代理ARP的实验仍有些续疑问，同时路由重定向实验又想到了一个小实验，故本文用来解决一部分上述实验中所留下的问题。
1.关于一个广播的ARP应答
在代理ARP实验中，抓到了一个广播的ARP应答包，一直比较怀疑其用途，在接下来做的其他一些实验中，有抓到过这样的ARP包，但是目前仍无法指出其作用。
首先说明一下环境，在接口为配置好的情况下，本人就预先对各接口进行了抓包的设置，然后，路由器是一台台的配的，然后抓到了该ARP包，如图1。
图1 R1上的广播ARP应答包
如图所示，R1、R2、R3每台路由器在接口no shutdown后都发送了这个广播的ARP应答包，很类似于无故ARP的性质，但是路由器却没有更新自己的CAM表，如图2，这与无故ARP的作用不符，故现在仍无法确定这种广播的ARP应答是哪一类，做何用。
图2 R1 CAM表
同时，在开启ARP 的debug信息后，又得到了如下信息，如图3、4。
图3 R1 clear arp-cache后的debug信息
图4 R2上ARP的debug信息
从图3上可以看出，在清除ARP缓存之后，发出了一条广播的应答，然后收到了这条应答，但从图4中可以看出，R2 却收到了两条应答，同时对比两条消息的时间差，R1发收的时间差明显大与R2收两条的时间差，所以可以推断这个ARP信息是在网络中“绕”了一圈之后才回来的。如果这么看得话，再加上R2、R3都没有更新自己的ARP表，联想反向ARP的作用，因此我猜测这条广播ARP应答是为了告诉路由器它自己的MAC地址是什么。但是问题又来了，R1只发了一条出去，但是R2、R3都收到了两条，谁第二次向网络中的所有设备发送了这条广播？我没想出来，继续留疑。
2.主机的无故ARP包，及主机将网关指向自己时的ping实验
在卷一的代理ARP那一节中，书中讲不配网关的主机会发去往不同网段的ARP查询，经验证这句话是错误的；在其下一节ICMP中，又讲到主机将网关指向自己，会发出ARP查询，可以避免路由重定向。随后在用路由器模拟的主机上进行的实验都失败了，偶然间想到可以用虚拟机来进行实验（本人使用的是vista系统，不敢装wincap这个东西，故无法在vista下进行抓包），故在虚拟机中对其网口进行了抓包，抓到了主机的无故ARP包，如图5。
图5 虚拟机无故ARP抓包
图6 主机将网关指向自己的ARP查询抓包
如图5，这是个广播的ARP，是一个ARP请求，源/目地址都是192.168.240.128，与书中对无故ARP的描述一致。
下面，我们将虚拟机的网关指向自己，然后再ping一下其他网段，结果如图6。
由图6，可知虚拟机对与自己不在同一网段内的IP地址进行了ARP查询，只是未收到应答。如果这台主机接在网关路由器上，并且路由器开启了代理ARP功能，那么这台主机将是可以上网的，同时这也验证了ICMP一节中“主机将网关指向自己可避免路由重定向”是正确的。
3.代理ARP与负载实验
3.1实验目的
在上一个ICMP路由重定向实验的最后一部分，一个解决重定向的方案实验中，突然又构想了另一个实验，就是模拟主机的R1不配网关，而与之相连的R2、R3到指定网段又具有相同的度量，那么R1将会接受谁的代理ARP，因此设计拓扑进行实验。
3.2实验设计
1. R1模拟主机，不指网关。
2. R2、R3具有到达同R6环回
3. R2、R3、R4、R5、R6运行eigrp协议。
3.3实验拓扑
3.4实验结果
仍然省略相关配置。
首先，在R6上ping R1，多ping几次，直至ping通。我们在R1上开启debug信息，结果如图7，R1的ARP表如图8所示。
图7 R1上信息
图8 R1 ARP表
可看出，当R6使用命令ping 123.1.1.1时，R1发出了ARP查询，多ping几次之后就通了。但是由图7中可看出，目的地址都是56.1.1.6，即说明ping的来源都是56.1.1.6。图8验证了这一点，因为R1只拿到了56.1.1.6的ARP地址（当然是被代理的），由抓包也可以看出，R6只使用自己的56.1.1.6接口去往123.1.1.0/24网段。
但是这就又出现了一个问题，首先看R6的路由表，如图9。
图9 R6路由表
由图9可看出，去往123.1.1.0/24网段是负载均衡的，也就是说，两条链路会交替使用的，但是当用简易的ping的时候，只使用了一条。这点我还不清楚，也许和默认的模块有关。
简易的ping或许不能负载均衡，下面来进行拓展的ping，将源地址设为6.6.6.6。结果仍然是R6使用了s1/0接口进行了转发。这个可以通过抓R6两个接口的包看出来，图我就不发了，因为只发一个图，没法证明些什么，有怀疑的还是自己敲敲实验吧。
下面在R1上ping
图10 R1上debug信息
因为R2、R3均有到达6.6.6.6的路由，由debug信息也可以看到，R2、R3均给R1做出了代理ARP的应答，但是R2的代理ARP来的要晚一些，因此R1使用R2为自己进行ARP代理。
因此，在这种情况下，主机将会使用ARP应答较晚的路由器为其进行代理。
下面，再看一个有趣的现象，在R6上用拓展ping，ping 123.1.1.2，结果如图11。
图11 R2上debug信息
由debug信息可知，数据来源均是由F0/0接口来的，应答ping的时候全是由S1/1口走的，也就是说R6没有使用负载均衡，而且数据在网络中不是按原路返回，走了另一条路径回去，也就是说此种网络架构产生了不对称流量。
图12 R6上debug信息
下面把开启R1的路由功能，运行eigrp，看看负载均衡是否会进行。结过很不幸，仍是没有，所以我怀疑这是不是拓扑的问题，过模拟器的问题，于是我将R1、R2、R3之间都换成了串线。同样还是没看到什么负载均衡，反而还看到了不对称流量，如图12。可能是模拟器原因，也可能配置上有失误，这问题也留待解决吧，等将来更新了设备，又或是开到eigrp的负载均衡，再考虑此问题。
3.5总结
1. 主机将网关指向自己，会发出不同网段的ARP查询。
2. ARP缓存会被更新，储存接收到的最晚的ARP信息。
3.6存疑点
1. eigrp的负载均衡问题。
2. 广播ARP应答的类型及作用，以及图4中第二条ARP信息由何而来
