问题的提出：
网络工程技术人员和或者学习者面对ARP代理技术时，通常能理解ARP代理的作用和技术要点是什么，但是无法根据技术描述去实现ARP代理的功能！
首先来看一般对代理ARP的定义：
通常根据上述文字的描述，就意味着在如图1所示的环境中，主机192.168.2.2/24可以在不配置默认网关的情况下成功的与路由器R2的192.168.3.2/24通信。其实这种理解是没有错的，但是当用户使用实验来证实代理ARP的作用时，结果却非常的意外，如果在主机192.168.2.2/24上不配置任何网关，路由器R1启动了代理ARP功能，不能让192.168.2.2访问192.168.3.2，对，不能，永远不能，那这是为什么呢，难道是理论定义有错，现在我们来做分析。
首先看验证代理ARP技术时各个通信节点上的原始配置：
计算机192.168.2.2上的配置，如图2所示，确定只配IP地址不配置默认网关：
路由器R1和R2的配置如下所示，默认情况下路由器的代理ARP技术是被启用，可以通过指令showip interface e1/0在路由器R1上来查看并确认，R1的E1/0接口的代理ARP的确是被启动的，如图3所示。
路由器R1的配置：
interfaceEthernet1/0
ip address 192.168.2.1 255.255.255.0
interfaceEthernet1/1
ip address 192.168.3.1 255.255.255.0
routerrip
version 2
network 192.168.2.0
network 192.168.3.0
no auto-summary
路由器R2的配置：
interface Ethernet1/1
ipaddress 192.168.3.2 255.255.255.0
router rip
version 2
network 192.168.3.0
noauto-summary
按照上述的原始配置，那么主机192.168.2.2/24在没配置默认网关的情况下应该就能ping通192.168.3.2，但事实上，如图4所示，结果出乎意外，192.168.2.2根本就无法ping通192.168.3.2。
然后大众会发出几种对故障的猜想和推论：
1 关于代理ARP技术的理论的定义不正确，所以导致了无法完成的实验
能被列入RFC文档的论述，都是得到了比应用级更高的专家（研发级）共同认同的公理，虽然不能说100%就是定论，但是在多数情况下是不被推翻的，所以由于这种原因产生故障的可能性不太，要么就是应用级人员没有彻底理解文档，要么就是实施有误。
2 路由器IOS存在bug（漏洞），所以无法完成实验
种个厂商的IOS的确会存在bug（漏洞），但是这种bug通常会被顶尖的高手和黑客所发现，然后厂商会立即作出反应，对bug进行修复，并公开bug，典型的情况就是用户在查看IOS版本时，比如出现IOS12.2(14)，说明这个版本已经经过了14次的修改，修改的次数越多，存在的bug就越少，所以对于代理ARP这种技术存在bug，而没被厂商发现的可能性太小了。
3 不同厂商的设备可能对ARP代理的定义和限制是不同的
这种原因就更不可能，因为网络公理，就相当于数学几何中的证明公理一样，它具备开放和开源性，差别只在于实现的指令和配置方式不同而已，再加上OSI模型的产生，所以所有厂商的技术，除私有特性技术外，都是一样，且必须一样，不然它将无法满足市场兼容性的需求，最终被踢出局。所以这种可能基本不会发生。
注意：任何一种对故障原因的分析和判别，都必须建立在数据、理论、取证三大元素之上，而且三大元素必须联动起来形成一种对故障现象非常有针对的“链条线”！尊重实验事实！
故障原因的分析思路与解决方案：
根据代理ARP的定义，如果主机192.168.2.2/24没有配置默认网关，那么它发出对192.168.3.2的ARP请求，将被路由器的R1的E1/0接口所接收，然后R1将代理源主机192.168.2.2去请求192.168.3.2的MAC地址，然后完成不同网络的通信。
一个关键过程是：如果路由器R1确认已经启动代理ARP功能，那么主机192.168.2.2是否发送对192.168.3.2的ARP请求，如果没发送，为什么？如果发送，路由器R1是否成功的执行了代理ARP的这个过程，并将结果返回给主机192.168.3.2，所以这是需要取证的第一个过程，所以在需要在主机192.168.2.2ping192.168.3.2时取证这个过程，如下图5所示，对ping行为的取证时，整个过程主机192.168.2.2都没有发送任何ARP请求，既然通信源主机对目标192.168.3.2的ARP请求都没有，何谈代理ARP的过程，所以确认实验故障是在主机192.168.2.2上，那么，为什么会出现这个故障，主机192.168.2.2为什么不发送针对192.168.3.2的ARP请求。
主机192.168.2.2/24不发送ARP请求的原因：
基于IPv4的主机在发送ARP请求之前，它会将目标的IP地址拿来和自已的子网掩码求“与”运算，如果目标主机的IP地址与自己的子网掩码在求“与”运算后，确定目标主机和自己的IP不在同一子网，那么该主机在没有配置默认网关的情况下不会发送任何ARP请求，如果配置了默认网关那么该主机会把ARP请求发送给默认网关，在代理ARP这个实验中，主机192.168.2.2子网掩码为255.255.255.0，请大家注意看目标主机192.168.3.2与自己的子网掩码求与得出的网络ID是192.168.3.0；而自己属于192.168.2.0，并没有配置任何默认网关，所以主机192.168.2.2/24根本不会发送任何ARP请求，所以路由器R1上的代理ARP功能根本就没法工作起来，实验怎会不失败！
故障解决方案并验证代理ARP的工作过程：
然仍保持不配置任何默认网关，然后如下图6所示，将主机的子网掩码改为255.255.0.0(即16位的子网)，那么目标主机192.168.3.2和255.255.0.0求“与”运算，得到网络ID为192.168.0.0/16,而改变子网掩码后，自己也属于192.168.0.0/16这个网段，所以主机192.168.2.2可以发送ARP请求，即便是192.168.2.2没有配置默认网关，由于路由器R1的E1/0接口启动了代理ARP，所以R1将代理主机192.168.2.2去对192.168.3.2进行ARP解析，此时即便主机192.168.2.2没有配置任何默认网关也能成功的与192.168.3.2通信如图7所示。
如果用户在完成主机192.168.2.2改变子网掩码为16位，再ping192.168.3.2时，启动了协议分析器，那么就该能捕获如图8所示的数据帧，主机192.168.2.2在网络上询问谁是192.168.3.2的MAC，然后路由器在代理192.168.3.2对主机192.168.2.2做应答，R1使用自己E1/0的MAC地址来应答192.168.2.2。
致此为止，描述了对代理ARP故障的分析与解决，如果此时将路由器R1的E1/0接口的代理ARP功能关闭，会发生什么情况？答案是：主机192.168.2.2在没有配置默认网关的情况下再也无法ping通192.168.3.2,因为现在的连通性是代理ARP在维持。
关闭路由器R1的E1/0接口的代理ARP功能：
R1(config)#intee1/0
R1(config-if)#noip proxy-arp ＊关闭代理ARP功能
注意：在关闭代理ARP功能以后，用户在作新的测试之前，如下图10首先在主机上使用ARP –a功能，查看主机的ARP缓存，如果缓存还存有没关闭代理ARP功能之前的解析结果，那么将误导您对代理ARP实验的认识，所以需要使用ARP –d清除缓存中所有的ARP记录，确认主机的ARP表已经被清空，再次ping192.168.3.2,结果是由于在R1上关闭了代理ARP的功能，连通性丢失！
如果在这个过程中，您再次启动协议分析器分析实时通信的数据帧，如下图10所示，只有主机192.168.2.2的N个ARP请求，但是没有应答，原因就是关闭了路由器R1的代理ARP功能，又没有配置默认网关，所以不会对该请求作应答，除非再次启动路由器R1的代理ARP功能。
在实践环境中代理ARP一般用在什么地方，它的优势与不足是什么？
一般在一些网络工程环境中，工程师为了防止用户错误的配置默认网关而导致通信丢失，可能会启动代理ARP功能，或者需要实现对子网划分的透明化，或者三层冗余时也会启动ARP代理。代理ARP有一定冗错的作用，但本人强烈反对这种做法，因为这会造成额外的流量，并构成很大的安全风险特别是在有可能发生ARP欺骗攻击的环境中。建议使用其它的冗余方案来替代它！
本文转自 kingsir827 51CTO博客，原文链接：http://blog.51cto.com/7658423/1441149，如需转载请自行联系原作者
