Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On absolutely standard ubuntu-server linux distro running only BIND cache, sometimes i see non-link-local ip addresses in the arp/nei table and there is no way to communicate with those entries

After googling for most of the morning, i did not find similar problem, so i think it might be something wrong with my setup.

The setup is very simple:

1 network interface, with 1 vlan (eth0.264) with 1 ip address, and 1 default gateway - nothing else

(for the question - i am replacing my ip addresses with, my subnet with and the example entry with

# uname -a
Linux space 3.0.0-16-server #28-Ubuntu SMP Fri Jan 27 18:03:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

# ip a li
4: eth0.264@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:30:48:d5:c2:70 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0.264
    inet6 fe80::230:48ff:fed5:c270/64 scope link 
       valid_lft forever preferred_lft forever

# ip rule li
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

# ip ro li
default via dev eth0.264  metric 100 dev eth0.264  proto kernel  scope link  src 

# ip neigh show dev eth0.264  INCOMPLETE

# arp -n                     (incomplete)                              eth0.264

# sysctl net.ipv4.conf.all.accept_redirects
net.ipv4.conf.all.accept_redirects = 0

# strange route cache stuff
# ip ro show cache dev eth0.264  src 
    cache <redirected>  ipid 0x05cb from dev eth0.264 
    cache <redirected>  ipid 0x05cb

# ip ro flush cache
# ip ro show cache
# ping
PING ( 56(84) bytes of data.
--- ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# ip ro show cache from dev eth0.264 
    cache <redirected>  ipid 0x06cb dev eth0.264  src 
    cache <redirected>  ipid 0x06cb

# arp -d
SIOCDARP(dontpub): Network is unreachable

(of course is reachable from the next server, and's weird arp entries are reachable from etc)

ip nei flush does not remove the entry,

also arp -s refuses to set it (like it should):

# arp -s 00:11:22:33:44:55
SIOCSARP: Network is unreachable
# arp -d
SIOCDARP(dontpub): Network is unreachable

I have 3 servers, with the same ubuntu version and running the same processess(only BIND), all of them experience the whole-world-is-link-local syndrome after reboot, it works for a couple of days and then it starts adding those non-link-local entries.

some usage statistics:

eth0.264 ~ 1000 pps udp traffic
load average 0.03
processes - rsyslogd, named, snmpd, sshd

Any ideas will be greatly appreciated.

share|improve this question

migrated from Feb 21 '12 at 2:12

This question came from our site for professional and enthusiast programmers.

What is the actual address for ? Is it a publicly routable address? – dfc Feb 28 '12 at 3:52

I guess your gateway has a single physical interface for both the network and the network where is connected. This is why it sends redirects.

In my opinion, there two bugs (or "strange features") in your Ubuntu server :

  • It should ignore redirects since net.ipv4.conf.all.accept_redirects=0
  • It should ignore redirects for IPs that are not reachable from your Ubuntu's network

However, you can fix this temporarily on your Ubuntu using :

ip route flush cache

And you will probably fix this permanently on the gateway, using :

sysctl -w net.ipv4.conf.all.send_redirects=0

After all, it is probably a bad idea to allow redirects from a gateway that has several networks connected to the same physical interface.

share|improve this answer
ip route flush cache does not affect routes received by ICMP redirects. – Manuel Faux Apr 7 '15 at 18:30

Why you're finding an ARP record for computer, which is not on the same subnet? It's not possible.

If you have network, then your computer have to go to the computer via default gateway, because it's subnet's part of IP address is 9.9.9.x (netmask is Then you have to have in your neighbor cache record only for default gateway. Your computer has to send packet with destination IP, but with MAC address of your default gateway. Your gateway will route this packet to the another network.

arp's complaints 'Network is unreachable' say to you, that computer is not part of network, on which is address, then ARP record for this IP address is nonsense.

Your route table saying to you, that your router tried to redirect you to the destination of via ICMP redirect packet. It is message for you, that your router have another netmask, than your computer, say /8 ( and in it's opinion you are on the same network as and router don't have to forward packet from you to this computer.

Please, check carefully netmasks on computers on your network, specially against your 'default gateway' computer or router - they must be same to everythink work correct.

share|improve this answer
sorry mate, is just a random number, so is in all the output i provided i find+replaced my server's ip address and example entry address, nothing else was replaced. also the fact that icmp redirects are disabled, and i see redirect route cache entries. I know it is not possible to have non link-local arp entries, that is why i am asking the question. i think the real problem is in the linux route cache which repopulates the same entries even after flush. – jackdoe Feb 24 '12 at 6:17
OK, I have only information, which you provide... But I still have question, why router send to you ICMP redirect (which is in the router entry) instead of forward packet. Are you sure, that router have the same network and netmask as your server? – Jan Marek Feb 24 '12 at 7:09

What is the Value of net.ipv4.conf.all.secure_redirects ? If 1, which happens to be the default, it will accept redirects from your gateway, regardless of accept_redirects. Disable that. (and also disable send_redirects on your gateway as suggested by Arnaud Bienvenu).

Also, the 3.0 kernel has a infuriating bug where redirected routes will never be purged from the kernel even if purging the routing cache, the only way to purge them is a reboot, or some complicated steps including waiting for a very long timeout.

share|improve this answer
you saved me. I faced two problems: 1.secure_redirects 4.0(linux 3.0) – diyism Dec 24 '14 at 11:00

Here's what I found:

My Ubuntu 14.04 server lost connectivity with a remote host after it was powered down for a few minutes for maintenance.

Inspection of route cache shows an entry using the wrong gw (

rg@buntu:~$ sudo ip route get via dev eth0  src
    cache <redirected>

After flushing the cache, now using the correct gw (

rg@buntu:~$ sudo ip route flush cache
rg@buntu:~$ sudo ip route get via dev eth0  src

Remote host is now reachable:

rg@buntu:~$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=252 time=14.9 ms
64 bytes from icmp_seq=2 ttl=252 time=15.6 ms
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.