一次ARP问题的Troubleshooting-白红宇

一次ARP问题的Troubleshooting

阅读量：5830 次

发布时间：2019-06-18

本文共 4743 字，大约阅读时间需要 15 分钟。

前一段时间，接到某用户的电话，用户反映A10的AX负载均衡设备在与国内一知名网络厂商的网络设备进行联合调试时出现了一些问题，希望厂商的工程师能够到现场做一些调试，找到导致问题的根源。

主要问题和现象:

网络的拓扑结构非常简单，防火墙和AX均启用了VRRP协议，采用HA的方式部署，并将对端作为路由的下一条地址。但是，在调试的过程中发现：

1）防火墙可以ping通AX的Floating-IP和接口IP；

2）AX无法ping通防火墙的Floating-IP地址，但是能够分别ping通两个防火墙的接口地址；

3）如果在AX上进行静态MAC和Floating-IP地址绑定，AX可以ping通防火墙的VRRP地址。

AX1K#ping 10.35.0.146

PING 10.35.0.146 (10.35.0.146) 56(84) bytes of data.

64 bytes from 10.35.0.146: icmp_seq=1 ttl=255 time=47.3 ms

64 bytes from 10.35.0.146: icmp_seq=2 ttl=255 time=19.9 ms

64 bytes from 10.35.0.146: icmp_seq=3 ttl=255 time=15.9 ms

64 bytes from 10.35.0.146: icmp_seq=4 ttl=255 time=20.0 ms

64 bytes from 10.35.0.146: icmp_seq=5 ttl=255 time=15.9 ms

--- 10.35.0.146 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4019ms

rtt min/avg/max/mdev = 15.995/23.871/47.370/11.885 ms

AX1K#ping 10.35.0.147

PING 10.35.0.147 (10.35.0.147) 56(84) bytes of data.

From 10.35.0.148 icmp_seq=2 Destination Host Unreachable

From 10.35.0.148 icmp_seq=3 Destination Host Unreachable

From 10.35.0.148 icmp_seq=4 Destination Host Unreachable

From 10.35.0.148 icmp_seq=5 Destination Host Unreachable

--- 10.35.0.147 ping statistics ---

5 packets transmitted, 0 received, +4 errors, 100% packet loss, time 4006ms

, pipe 3

AX1K#

问题分析和处理过程

要想进行问题的定位，我们需要从数据流在整个TCP/IP协议模型中处理的过程来考虑。首先，让我们来想象一下，整个ping的过程是如何完成的：

1）当我们在命令行键入 ping 10.35.0.147这个命令时，实际上是通过ICMP协议来探测目标主机的网络连通状况。

2）首先，系统首先根据掩码来判断，目标IP与本地接口IP是否属于同一个子网。

3）如果目标IP与本地接口IP属于同一子网，系统查询本地ARP缓存，希望获得目标IP对应的MAC地址；如果目的IP与本地接口IP不属于同一子网，系统查询本地路由表或根据默认网关进行转发。很显然，本案例属于前一种情况。

4）如果本地ARP缓存中不存在目标IP与MAC的对应表项，系统将自动发送ARP请求后，并通过交换机广播到子网中的每一个节点。

5）目标主机收到ARP请求后，会向源端返回ARP应答。

6）源端从ARP应答中获得目标主机的IP和MAC对应关系，并放入ARP缓存。

7）系统从ARP中获得目标IP的MAC地址，将ICMP请求数据包进行封装，并从接口转发。

8）交换机接收到数据帧后，查询MAC地址表，然后将数据帧转发至目标接口

9）目的主机接收到ICMP数据包后，更新本地ARP缓存，然后将ICMP应答数据包送出。

10）交换机转发ICMP应答数据帧至源端

11）源端接收ICMP应答数据包后，将应答情况通过ping命令显示至终端屏幕上。

当然，我们可以将这个过程描述的更加细致，这取决于我们对协议和系统实现的理解程度和我们遇到的具体问题。对协议和系统实现的理解程度将决定我们是否能够细致的了解应用数据的处理过程；而具体的问题将有助于我们对过程进行取舍。

从网络故障的诊断步骤来说，一般都是从低层向高层逐步诊断。由于AX可以ping通防火墙的接口IP，因此，我们基本上可以认为网络的物理连通性良好。从上面的ping的处理过程分析，我大致断定导致问题的原因可能与ARP有关。

因此，我从AX上查询ARP和MAC的一些状态信息，试图找到一些线索：

AX1K(config)#show arp

Total arp entries: 11 Age time: 300 secs

IP Address MAC Address Type Age Interface Vlan

---------------------------------------------------------------------------

10.35.0.145 0025.9e21.638a Dynamic 36 ve62 62

10.35.0.146 0025.9e34.8903 Dynamic 197 ve62 62

10.35.0.149 001f.a010.0c2d Dynamic 169 ve62 62

果然，在ARP表中看不到有关10.35.0.147的表项。因此，我们可以有以下几种假设：

1) AX发出的ARP请求没有成功送出；

2) AX送出的ARP请求有问题；

3) AX没有收到防火墙的ARP应答；

4) AX收到的防火墙ARP应答有问题。

由于AX可以ping通防火墙的其它接口，因此，我暂时排除了1), 2), 3)的可能性。很有可能是防火墙的ARP应答有问题。因此，我决定从AX上抓包验证一下。

从抓包的情况来看也验证了我的判断：AX送出了有效的ARP请求，并收到了防火墙返回的ARP应答。看起来，AX并没有在收到ARP后更新自己的ARP缓存。

AX1K#debug packet l3 arp count 0

AX1K#debug monitor

Wait for debug output, enter <ctrl c> to exit

(0,15437400) o( 1, 62,11db3)> arp who-has 10.35.0.147 tell 10.35.0.148

(0,15437404) i( 1, 62,1e895)> arp reply 10.35.0.147 is-at 00:00:5e:00:01:39

(0,15437648) o( 1, 62,1e895)> arp who-has 10.35.0.147 tell 10.35.0.148

(0,15437652) i( 1, 62,1167f)> arp reply 10.35.0.147 is-at 00:00:5e:00:01:39

从前面我们分析的ping的11个步骤来看，至少前5个步骤都顺利完成了，第6步也完成了一半，AX收到了防火墙返回的ARP应答，但是不知道为什么，AX并没有能够成功的处理这个报文，把相应的ARP表项放入缓存中。因此，我决定仔细检查ARP的应答报文，看看这里面到底有些什么古怪。

在分析上面的报文之前，让我们先来回忆一下ARP的报文结构。ARP报文直接封装在二层数据帧中。总长度为28个字节，根据ARP的数据包接口，我们分析以上AX接收到的ARP报文，终于发现了ARP应答报文的异常。

根据ARP的报文结构，我们对上面的ARP应答内容进行一些分析：

1）前面12个字节，是数据帧头部，分别表示目的MAC（6字节， 001f a010 0d54）和源MAC（6字节，0025 9e21 638a），然后紧跟的4个字节表示后面封装的协议类型（0x 0806表示ARP协议）

2）紧接着的28个字节表示ARP协议

a) 2个字节表示硬件类型

b) 2个字节表示协议类型

c) 1个字节表示硬件地址长度

d)1个字节表示协议地址长度

e)2个字节表示该ARP报文的类型，如：ARP请求还是ARP应答

f) 6个字节表示发送者硬件地址，在这里即源MAC

g)4个字节表示发送者协议地址，在这里即源IP

h)6个字节表示接收者硬件地址，在这里即目的MAC

i) 4个字节表示接收者协议地址，在这里即目的IP

通过与标准协议进行对照，我发现防火墙的ARP应答包中，接收者协议地址部分的数据包有问题。按照标准，这4个字节的数据应该是接收者IP，而我们收到的数据包这部分显然是错的。10.35.0.148的二进制表示应该是0x 0a230094，而实际接收到的却是：0x 0000 5e00。这显然是不符合标准的ARP协议的，因此，AX丢弃了这个ARP报文，没有从中学习到对应IP的MAC地址。