求助：arp reply报文丢失

asuka2001

在某台虚拟机中:

# arping -I eth1 192.168.240.6
ARPING 192.168.240.6 from 192.168.240.8 eth1
Sent 6 probes (6 broadcast(s))
Received 0 response(s)

但是tcpdump可以发现有收到报文

#  tcpdump -nexx -c 10 -i eth1 arp
01:14:39.251204 fa:16:3e:1e:6b:40 > Broadcast, ethertype ARP (0x0806), length 42: arp who-has 192.168.240.6 (Broadcast) tell 192.168.240.8
        0x0000:  ffff ffff ffff fa16 3e1e 6b40 0806 0001
        0x0010:  0800 0604 0001 fa16 3e1e 6b40 c0a8 f008
        0x0020:  ffff ffff ffff c0a8 f006
01:14:39.251576 fa:16:3e:6e:02:4e > fa:16:3e:1e:6b:40, ethertype ARP (0x0806), length 56: arp reply 192.168.240.6 is-at fa:16:3e:6e:02:4e
        0x0000:  fa16 3e1e 6b40 fa16 3e6e 024e 0806 0001
        0x0010:  0800 0604 0002 fa16 3e6e 024e c0a8 f006
        0x0020:  fa16 3e1e 6b40 c0a8 f008 0000 0000 0000
        0x0030:  0000 0000 0000 0000

完全搞不明白了，是因为防火墙的原因把arp reply报文给扔了吗？对这个不熟悉，请熟悉的人帮忙看看，谢谢。以下是一些详细信息！




# ip neigh show
??? dev eth0 lladdr 74:25:8a:e7:de:e0 REACHABLE
??? dev eth1 lladdr fa:16:3e:ce:24:4d REACHABLE
??? dev eth0 lladdr fa:16:3e:39:8c:ca REACHABLE
127.1.1.2 dev tmm0 lladdr 00:01:23:45:67:00 DELAY
192.168.239.2 dev eth0 lladdr fa:16:3e:39:8c:ca REACHABLE
192.168.239.1 dev eth0 lladdr 74:25:8a:e7:de:e0 STALE
192.168.240.2 dev eth1  FAILED


# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr FA:16:3E:1E:6B:40
          inet addr:192.168.240.8  Bcast:192.168.240.255  Mask:255.255.255.0
          inet6 addr: fe80::f816:3eff:fe1e:6b40/64 Scope:Link
          UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST  MTU:9000  Metric:1
          RX packets:287945 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17196973 (16.4 MiB)  TX bytes:3449556 (3.2 MiB)

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
icsa       all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  127.2.0.1            127.2.0.2
ACCEPT     all  --  127.2.0.2            127.2.0.2
DROP       all  --  0.0.0.0/0            127.2.0.2
ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0           tcp dpt:3306
ACCEPT     tcp  --  127.3.0.0/24         0.0.0.0/0           tcp dpt:3306
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable
ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0           tcp dpts:1097:1099
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:1097:1099 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain hnet (0 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain icsa (1 references)
target     prot opt source               destination

瀚海书香

回复 1# asuka2001
The packets should dropped by iptables.
There is a user-defined chain "hnet", but not used. Are you sure this is the complete iptables -nvL output?

   

asuka2001

回复 2# 瀚海书香

这里是输出，完整的就是这样了！

# iptables -nvL
Chain INPUT (policy ACCEPT 4147K packets, 647M bytes)
pkts bytes target     prot opt in     out     source               destination
4147K  647M icsa       all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       127.2.0.1            127.2.0.2
    0     0 ACCEPT     all  --  *      *       127.2.0.2            127.2.0.2
    0     0 DROP       all  --  *      *       0.0.0.0/0            127.2.0.2
    0     0 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpt:3306
    0     0 ACCEPT     tcp  --  *      *       127.3.0.0/24         0.0.0.0/0           tcp dpt:3306
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable
    0     0 ACCEPT     tcp  --  *      *       127.0.0.1            0.0.0.0/0           tcp dpts:1097:1099
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1097:1099 reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 4111K packets, 644M bytes)
pkts bytes target     prot opt in     out     source               destination

Chain hnet (0 references)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain icsa (1 references)
pkts bytes target     prot opt in     out     source               destination


   

asuka2001

回复 2# 瀚海书香

对了，eth0的arp报文就能收到。。。内核里看到arp_rcv中也就挂了个NF_HOOK(NFPROTO_ARP, NF_ARP_IN, skb, dev, NULL, arp_process)。iptables应该不会只针对某个net device吧？

# arping 192.168.239.1
ARPING 192.168.239.1 from 192.168.239.8 eth0
Unicast reply from 192.168.239.1 [74:25:8A:E7E:E0]  2.128ms
Unicast reply from 192.168.239.1 [74:25:8A:E7E:E0]  1.656ms
Unicast reply from 192.168.239.1 [74:25:8A:E7E:E0]  1.032ms
^CSent 3 probes (1 broadcast(s))
Received 3 response(s)

   

asuka2001

发现 eth0所连接的网络里居然可以arping 192.168.240.6。。。

一般来说，IP地址冲突应该不会导致arp reply被扔吧。。。没看到代码里有对这个做处理。

但是现在用的是BIG IP的内核，到底是防火墙扔了包还是内核对arp回复有特别处理，有知道的人吗？

帅绝人寰

tcpdump下， 看能不能看到

再看看到底是哪层丢的

2, 3？

asuka2001

回复 6# 帅绝人寰

?不太明白。。。

arp reply报文tcpdump能抓到，不过tcpdump后这个包就递交给arp_rcv处理了，应该不在往上走了吧。