在网络的使用中这个是我们比较少关注的一个协议， 它是用来查看ip地址和mac地址的对应关系。

一般情况下网络问题很少出现在这个地方。而且如果查看这个值出现问题的时候， 一般是上层的协议出现了问题，或者就是整个网络出现了问题。

但是今天需要讲述一个比较特殊的情况下arp的网络问题。 问题的起源是我使用openvpn搭建一个client-to-client 的环境。 就是使用一台openvpn的服务器，然后使用两台openvpn的客户端去连接openvpn的服务器。 我在openvpn中配好 client-to-client 选项后， 然后两台openvpn的客户端可以ping通服务端，也可以看到下发的策略。 但是在两台客户端的中相互ping对方，却是不通的。 查看ip和tcp，都是正常的。没有检查到异常，但是一直都是不通的。

最后没有办法，只能按照网络协议层一层一层的往下去分析。 在windows的cmd下，查看路由 route print。路由正常。 ip和端口正常，ip层和tcp层都是正常的。 使用arp -a的指令，得到

arp -a

172.16.0.2 ether   00:ff:90:4e:20:cc   C  tap0
172.16.0.3 ether   00:ff:90:4e:20:cc   C  tap0

172.16.0.0/16 是虚拟IP的地址，第三项是对应的Mac地址， 所以到链路层之后，有两个相同的mac地址。 所以从mac地址转换成IP地址的时候丢失了IP地址。所以一直访问不通。

为什么会有两个相同的mac地址呢？第二个openvpn的客户端是直接复制第一个 openvpn的虚拟机。所以出现了两个相同的mac地址。修改其中一个虚拟IP的mac地址 之后就可以相互ping通对方了。

如果想重现问题，可以将两个IP地址改成相同的mac地址，查看一下你的那边会出现什么情况。

###虚拟IP

arp -a
192.168.41.97            ether   00:0C:29:EB:70:DA   C                     eth0
192.168.41.92            ether   00:0C:29:EB:70:DA   C                     eth0

有时候我们可以在同一台机器上看到两个IP有相同的物理地址。 traceroute 这两个IP都是正常的，可以访问的。 没有出现上面不能访问的情况。

在这种情况下主机中发出的数据中包含了目标地址的IP，所以可以正常到达目标主机。 但是如果是两个Mac相同，发送apr的tell数据包的时候，会有两个地方都会响应， 那么就会造成Mac地址冲突了。