On 2/18/2011 1:09 AM, Julian Anastasov wrote:
Hello,
On Thu, 17 Feb 2011, Bart Kus wrote:
Hello Experts,
With 00:04:23:bb:18:56 being a Linux box, it gets a ping request from
a network device:
05:50:50.393373 00:0c:db:b5:b7:00 (oui Unknown) > 00:04:23:bb:18:56
(oui Unknown), ethertype IPv4 (0x0800), length 60: 172.20.11.3 >
192.168.70.1: ICMP echo request, id 43981, seq 1, length 24
Before replying (even though it could, since it has the MAC as part
of the ping request) it decides to query for the MAC based on source
IP of the original ping request:
05:50:50.402347 00:04:23:bb:18:56 (oui Unknown) > Broadcast,
ethertype ARP (0x0806), length 42: Request who-has 172.20.11.3 tell
192.168.70.1, length 28
The tell section indicates to "tell 192.168.70.1", but the interface
on which this came in has an IP of 172.20.11.1. 192.168.70.1 is
another IP on the Linux router, on a different interface.
Shouldn't the ARP request say "tell 172.20.11.1" instead given ARP is
an ethernet protocol, incapable of routing to 192.168.70.1? The
reply to this broadcast never comes back from the other network
device due to the weird "tell 192.168.70.1" being there. The end
result is complete ping loss.
May be what you need is to set on Linux box
/proc/.../arp_announce to 1 or 2. Check
Documentation/networking/ip-sysctl.txt for more info.
Perfect! Setting arp_announce to 1 has fixed the issue:
09:15:21.151841 00:0c:db:b5:b7:00 (oui Unknown) > 00:04:23:bb:18:56 (oui
Unknown), ethertype IPv4 (0x0800), length 60: 172.20.11.3 >
192.168.70.1: ICMP echo request, id 43981, seq 1, length 24
09:15:21.162059 00:04:23:bb:18:56 (oui Unknown) > Broadcast, ethertype
ARP (0x0806), length 42: Request who-has 172.20.11.3 tell 172.20.11.1,
length 28
09:15:21.162300 00:0c:db:b5:b7:00 (oui Unknown) > 00:04:23:bb:18:56 (oui
Unknown), ethertype ARP (0x0806), length 60: Reply 172.20.11.3 is-at
00:0c:db:b5:b7:00 (oui Unknown), length 46
Thanks!
--Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html