1

This question is very similar to this one:

Linux is sending ARP requests to hosts in other subnets?

Main problem - Ubuntu Linux server is sending ARP requests asking for a MAC address of a host on a different subnet.

One router has four different Class C networks attached physically. No VLAN or any other separation.

The router has an IP address in each of the four Class C subnets. That is what allows routing between the four subnets.

Ubuntu Linux server has IP address x.x.250.2.

When a ping is done to one of the different subnets (x.x.249.x), SOME requests are successful and others are not. For those that are not, Wireshark (packet sniffer running in the Ubuntu Linux server) shows it is sending out ARP packets ("Who has IP x.x.249.x?")

Why is this occurring? No ARP packets should be sent from the server destined for something not on it's same subnet.

Network config on the server is x.x.250.2. Subnet mask is 255.255.255.0. Gateway is x.x.250.1. Set statically.

Routing table has not been modified and is just the default for this:

    Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         x.x.250.1   0.0.0.0         UG    0      0        0 eth0
x.x.250.0   0.0.0.0         255.255.255.0 U     0      0        0 eth0

The arp cache on the Linux server shows many MAC addresses for systems in the x.x.249.x and also the x.x.250.x network. Again, this should not be happening.

Now - A Windows XP computer was used for testing purposes. Put into the same subnet as the Linux server. It can ping those addresses in the x.x.249.x subnet that the Linux server cannot.

There must be some kind of potential bug in the TCP stack of Ubuntu/Linux. Sending out ARP packets to other networks/subnets should not be happening.

1
  • "The arp cache on the Linux server shows many MAC addresses for systems in the x.x.249.x", this means that the devices on the other subnet are successfully responding to the ARP requests. Having said that, you're right, the Linux box shouldn't be sending the ARP requests in the first place. It might be worth taking a look at your router and/or switch just to be sure there's nothing strange configured. In regards to the XP machine, does it send ARP requests for devices on the x.x.249.x subnet? By the way, are these physical or virtual machines?
    – OzNetNerd
    Nov 26, 2015 at 5:37

1 Answer 1

1

This has been solved.

Linux obviously doesn't exactly play by the regular rules of the TCP stack like Windows machines do.

I restarted the Linux server. Did a ping to an IP address that was problematic (x.x.249.76).

An ICMP Redirect was received from the router (x.x.250.1) saying "Hey, you can talk to x.x.249.76 directly and you don't need to go through me). Immediately once that was received, the ping responses timed out and quit.

The router is a MicroTik router and I bet it is based on Linux as well.

Since these four subnets were all on the same router, the MikroTik device THOUGHT that it did not need to relay the messages. Wrong.

The solution was to update the /etc/sysctl.d/10-network-security.conf file and these lines were added:

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

This told my Linux server to completely ignore any ICMP redirects.

Server was restarted. Starting pinging x.x.249.76 and the redirect notices still were received, but were ignored and the server continued to successfully ping the IP address.

1
  • Wouldn't correctly configuring the router be a better solution? Nov 28, 2015 at 4:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .