В абсолютно стандартном дистрибутиве 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 есть две ошибки (или «странные особенности»):
Однако вы можете временно исправить это на своем 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