Назад | Перейти на главную страницу

Странные записи в кэше соседей linux (синдром всего мира-ссылки-локального) (linux 3.0.0-16)

В абсолютно стандартном дистрибутиве linux ubuntu-server, работающем только с кешем BIND, иногда я вижу не связанные с локальными локальными IP-адресами в таблице arp / nei, и нет возможности связаться с этими записями

После поиска в Google большую часть утра я не обнаружил подобной проблемы, поэтому думаю, что с моей настройкой что-то не так.

Настройка очень проста:

1 сетевой интерфейс, с 1 vlan (eth0.264) с 1 IP-адресом и 1 шлюзом по умолчанию - больше ничего

(на вопрос - я заменяю свои ip адреса на 9.9.9.9, моя подсеть с 9.9.9.0/24 и пример записи с 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

(конечно 9.17.100.131 доступен со следующего сервера 9.9.9.14, и 9.9.9.14странные записи arp доступны из 9.9.9.13.. и т.д)

ip nei flush не удаляет запись,

также arp -s отказывается установить его (как и должно):

# 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

У меня есть 3 сервера с одной и той же версией ubuntu и с одним и тем же процессом (только BIND), все они испытывают синдром всего мира-это-локальная ссылка после reboot, он работает пару дней, а затем начинает добавлять эти записи, не связанные с локальными ссылками.

некоторая статистика использования:

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

Мы будем благодарны за любые идеи.

Я предполагаю, что ваш шлюз имеет один физический интерфейс как для сети 9.9.9.0/24, так и для сети, к которой подключен 9.17.100.131. Вот почему он отправляет перенаправления.

На мой взгляд, на вашем сервере Ubuntu есть две ошибки (или «странные особенности»):

  • Он должен игнорировать перенаправления, поскольку net.ipv4.conf.all.accept_redirects = 0
  • Он должен игнорировать перенаправления для IP-адресов, которые недоступны из вашей сети Ubuntu.

Однако вы можете временно исправить это на своем Ubuntu, используя:

ip route flush cache

И вы, вероятно, навсегда исправите это на шлюзе, используя:

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

В конце концов, вероятно, это плохая идея - разрешать перенаправления от шлюза, у которого несколько сетей подключены к одному физическому интерфейсу.

В чем ценность net.ipv4.conf.all.secure_redirects ? Если 1, что является значением по умолчанию, он будет принимать перенаправления от вашего шлюза независимо от accept_redirects. Отключите это. (а также отключить send_redirects на вашем шлюзе, как было предложено Арно Бьенвеню).

Так же В ядре 3.0 есть досадная ошибка, из-за которой перенаправленные маршруты никогда не удаляются из ядра. даже если очистить кеш маршрутизации, единственный способ очистить их - это перезагрузка или несколько сложных шагов включая ожидание очень долгого таймаута.

Почему вы находите запись ARP для компьютера, который не находится в той же подсети? Это невозможно.

Если у вас есть сеть 9.9.9.0/24, то ваш компьютер должен подключиться к компьютеру 9.17.100.131 через шлюз по умолчанию, потому что часть IP-адреса подсети 9.9.9.x (маска сети 255.255.255.0). Тогда у вас должна быть запись в кэше вашего соседа только для шлюза по умолчанию. Ваш компьютер должен отправить пакет с IP-адресом назначения 9.17.100.131, но с MAC-адресом вашего шлюза по умолчанию. Ваш шлюз направит этот пакет в другую сеть.

Жалобы arp «Сеть недоступна» говорят вам, что компьютер не является частью сети, в которой находится адрес 9.17.100.131, то ARP-запись для этого IP-адреса - ерунда.

Ваша таблица маршрутов сообщает вам, что ваш маршрутизатор пытался перенаправить вас в пункт назначения 9.17.100.131 через пакет перенаправления ICMP. Это сообщение для вас, что у вашего роутера другая сетевая маска, чем у вашего компьютера, например /8 (255.0.0.0) и, по его мнению, вы находитесь в той же сети, что и 9.17.100.131, и маршрутизатору не нужно пересылать пакеты от вас на этот компьютер.

Пожалуйста, внимательно проверьте сетевые маски на компьютерах в вашей сети, особенно по отношению к компьютеру или маршрутизатору со «шлюзом по умолчанию» - они должны быть одинаковыми, чтобы все работало правильно.

Вот что я нашел:

Мой сервер Ubuntu 14.04 потерял связь с удаленным хостом 150.43.127.1 после того, как он был отключен на несколько минут для обслуживания.

Проверка кеша маршрутов показывает, что запись использует неправильный 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>

После очистки кеша, теперь используется правильный 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:~$

Удаленный хост теперь доступен:

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