关于GARP以及ARP缓存在Windows Vista之后的一些改变
DAD & GARP & ARP Neighbor Cache
在Windows系统中，如何通过已知的IP地址找到对方设备的物理地址(MAC Address)呢？通常，Windows系统会通过ARP协议发送一个ARP请求，请求包含四个主要的属性：
1） SendersMacAddress
2） SendersIp4Address
3） TargetMacAddress
4） TargetIp4Address
SendersIp4Address和SendersMacAddress分别填上自己的IP和MAC，TargetIp4Adress会填上想要解析的对方的IP地址，TargetIPMACAddress置为00-00-00-00-00-00；网络上IP为TargetIp4Adress的设备收到此请求后，将会作出响应，响应内容是告诉请求发自己的MAC地址。如，
1 4:21:9 PM 7/30/2012 192.168.15.33 192.168.15.2 ARP ARP:Request, 192.168.15.33 asks for 192.168.15.2
Frame: Number = 1, Captured Frame Length = 42, MediaType = ETHERNET
+ Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-15-5D-08-83-1E]
- Arp: Request, 192.168.15.33 asks for 192.168.15.2
HardwareType: Ethernet
ProtocolType: Internet IP (IPv4)
HardwareAddressLen: 6 (0x6)
ProtocolAddressLen: 4 (0x4)
OpCode: Request, 1(0x1)
SendersMacAddress: 00-15-5D-08-83-1E
SendersIp4Address: 192.168.15.33
TargetMacAddress: 00-00-00-00-00-00
TargetIp4Address: 192.168.15.2
2 4:21:09 PM 7/30/2012 192.168.15.2 192.168.15.33 ARP ARP:Response, 192.168.15.2 at 00-15-5D-08-83-16
Frame: Number = 2, Captured Frame Length = 42, MediaType = ETHERNET
+ Ethernet: Etype = ARP,DestinationAddress:[00-15-5D-08-83-20],SourceAddress:[00-15-5D-08-83-16]
- Arp: Response, 192.168.15.2 at 00-15-5D-08-83-16
HardwareType: Ethernet
ProtocolType: Internet IP (IPv4)
HardwareAddressLen: 6 (0x6)
ProtocolAddressLen: 4 (0x4)
OpCode: Response, 2(0x2)
SendersMacAddress: 00-15-5D-08-83-16
SendersIp4Address: 192.168.15.2
TargetMacAddress: 00-15-5D-08-83-20
TargetIp4Address: 192.168.15.8
原先的请求方收到这样的响应后，会将对方的IP和MAC作为动态的唯一的对应信息缓存在ARP缓存中。可以通过arp –a命令进行查看。
地址冲突监测(Duplicate Address Detection)机制也使用了ARP协议的这种请求：
当TCPIP协议栈接收到加载IP地址的事件(如重启机器，重启网卡，修改TCPIP属性)时，会通过ARP协议广播一种特殊的ARP请求，这种特殊ARP请求的TargetIPAdress会填上自己的IP地址，TargetIPMACAddress置为00-00-00-00-00-00；我们称之为GARP(Gratuitous ARP)。如，
52 6:40:00 PM 8/1/2012 40.3886896 192.168.15.2 192.168.15.2 ARP ARP:Request, 192.168.15.2 asks for 192.168.15.2
Frame: Number = 52, Captured Frame Length = 42, MediaType = ETHERNET
+ Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-15-5D-08-83-16]
- Arp: Request, 192.168.15.2 asks for 192.168.15.2
HardwareType: Ethernet
ProtocolType: Internet IP (IPv4)
HardwareAddressLen: 6 (0x6)
ProtocolAddressLen: 4 (0x4)
OpCode: Request, 1(0x1)
SendersMacAddress: 00-15-5D-08-83-16
SendersIp4Address: 192.168.15.2
TargetMacAddress: 00-00-00-00-00-00
TargetIp4Address: 192.168.15.2
正常情况下，如果网络中没有IP地址冲突，是没有正对这种ARP请求的响应的；如果有响应，那么就说明，这个IP地址已有冲突，此时Windows也会弹出窗口提示有IP地址冲突发生。
另外，网络其他设备接收到这种广播的GARP以后，也会响应的更新他们的ARP缓存，创建一条IP地址和MAC地址的映射(SendersMacAddress和SendersIp4Address)。
Changes
相信以上的行为对大家来说，都并不陌生。
但是，从Windows Vista以后，以上两种行为有了较大的改进：
1. Windows Vista\2008以后的操作系统在相同的情况下广播的GARP请求中，将不包含自己的IP地址，即SendersMacAddress置为0.0.0.0；如，
2. Windows Vista\2008以后的操作系统在接收到任何形式的GARP请求时，不再更新自己的ARP缓存而仅通过直接的ARP请求和响应来更新ARP缓存；
有这两种改进的原因是：
在之前的系统版本中，所有能接收到GARP设备的系统都会将GARP内包含的IP和MAC信息作为映射存到ARP缓存中，如果该GARP中包含的IP实际上是地址冲突的地址，当地址冲突监测发现后，就会更改IP。但是接收方已经更新了ARP缓存，且短时间内不会删除，稍后便会造成错误的IP地址解析。
且这两处更改从代码上逻辑的更改，是不可调的。
Changes again
这样的更改固然是减少了由于IP地址冲突造成的一系列问题，但是同样，也对某些依靠GARP更新客户端ARP缓存的设备或架构收到影响，如，Windows Cluster和物理的容错机制。
当群集中发生Failover的时候，虚拟的IP地址迁移到新的节点（新的MAC地址），新的节点将会广播出GARP做IP地址冲突监测，同时，一些网路设备也完全依靠这样的GARP来更新他们的ARP缓存，如，一些硬件防火墙，交换机或路由设备。设想，如果群集设备是Windows 2008系统，广播出的GARP并不包含完整的IP和MAC映射信息，网络设备将无法更新自己的ARP缓存。造成这些问题的主要原因是大部分的网络设置在Windows 2000和2003期间，设计逻辑过于依赖GARP。因而造成群集在Failover之后，客户端无法联系群集的虚拟IP – 实际上是因为他们中间的路由设备无法通过GARP更新ARP缓存，也无法主动通过发送Unicast的ARP请求以获得响应。这样的问题对于同一个网段的客户端是没有任何影响的，因为他们不依赖于路由设备。不过目前，Windows暂没有针对这种类型的情况作出更新。
另外一种情况，Windows Vista/2008作为GARP的接收方时不能根据GARP更新自己的ARP缓存的问题，Windows在2008 R2期间出了针对于Windows Vista以后所有版本的补丁https://support.microsoft.com/kb/2582281. 该补丁再一次更改了其中一个行为，即“操作系统在接收到任何形式的GARP请求时，不再更新自己的ARP缓存而仅通过直接的ARP请求和响应来更新ARP缓存”，更改后，“操作系统在接收到由Windows Vista以前的操作系统（如，Windows XP或2003）发出的GARP时，可更新自己的ARP缓存； 接收到Windows Vista以后的系统发出的GARP时，仍不更新ARP缓存”。