2

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 9.9.9.9, my subnet with 9.9.9.0/24 and the example entry with 9.17.100.131)

# 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 9.9.9.13/24 brd 9.9.9.255 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 9.9.9.1 dev eth0.264  metric 100 
9.9.9.0/24 dev eth0.264  proto kernel  scope link  src 9.9.9.13 

# ip neigh show 9.17.100.131
9.17.100.131 dev eth0.264  INCOMPLETE

# arp -n 9.17.100.131
9.17.100.131                     (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 9.17.100.131
9.17.100.131 dev eth0.264  src 9.9.9.13 
    cache <redirected>  ipid 0x05cb
9.17.100.131 from 9.9.9.13 dev eth0.264 
    cache <redirected>  ipid 0x05cb


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

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

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

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

ip nei flush does not remove the entry,

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

# arp -s 9.17.100.132 00:11:22:33:44:55
SIOCSARP: Network is unreachable
# arp -d 9.17.100.131
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.

1
  • What is the actual address for 9.17.100.131 ? Is it a publicly routable address?
    – dfc
    Feb 28, 2012 at 3:52

4 Answers 4

2

I guess your gateway has a single physical interface for both the 9.9.9.0/24 network and the network where 9.17.100.131 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.

1
  • 1
    ip route flush cache does not affect routes received by ICMP redirects. Apr 7, 2015 at 18:30
1

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

If you have network 9.9.9.0/24, then your computer have to go to the computer 9.17.100.131 via default gateway, because it's subnet's part of IP address is 9.9.9.x (netmask is 255.255.255.0). Then you have to have in your neighbor cache record only for default gateway. Your computer has to send packet with destination IP 9.17.100.131, 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 9.17.100.131, 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 9.17.100.131 via ICMP redirect packet. It is message for you, that your router have another netmask, than your computer, say /8 (255.0.0.0) and in it's opinion you are on the same network as 9.17.100.131 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.

2
  • sorry mate, 9.17.100.131 is just a random number, so is 9.9.9.9. 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, 2012 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, 2012 at 7:09
1

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.

1
  • you saved me. I faced two problems: 1.secure_redirects 2.android 4.0(linux 3.0)
    – diyism
    Dec 24, 2014 at 11:00
0

Here's what I found:

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

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

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

After flushing the cache, now using the correct gw (150.150.127.1):

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

Remote host is now reachable:

rg@buntu:~$ ping 150.43.127.1
PING 150.43.127.1 (150.43.127.1) 56(84) bytes of data.
64 bytes from 150.43.127.1: icmp_seq=1 ttl=252 time=14.9 ms
64 bytes from 150.43.127.1: icmp_seq=2 ttl=252 time=15.6 ms
^C

You must log in to answer this question.

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