LINUX.ORG.RU
Форум — Admin  

Сообщение в логе: «ipv4: Neighbour table overflow», жуткие тормоза сети

 ,


0

1

Здравствуйте! Прошу не кидаться камнями, но помогите понять что за ерунда творится. Есть сервер-шлюз на Debian, 4 сетевых карточки. В лог спонтанно могут повалиться сообщения вида: 

Aug 28 12:46:04 gw kernel: [591582.812889] ipv4: Neighbour table overflow.
Aug 28 12:46:04 gw kernel: [591582.824085] ipv4: Neighbour table overflow.
Aug 28 12:46:04 gw kernel: [591582.834822] ipv4: Neighbour table overflow.
Aug 28 12:46:04 gw kernel: [591582.845219] ipv4: Neighbour table overflow.
Aug 28 12:46:04 gw kernel: [591582.855767] ipv4: Neighbour table overflow.

Самое странное, что после выдергивания кабеля провайдера (интернет по PPPoE) - все нормализуется. Выдергивание кабеля, идущего в локальную сеть, ничего не дает, в лог по прежнему сыплются эти сообщения.

Может быть я просто не вижу где у меня ошибка. Вот текущие настройки сети (ppp0, ppp1 - интернет-соединения через wan1 и wan2, crp - доступ к КИС, ppp5 - доступ в КИС): 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 9c:b6:54:bb:aa:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.87.2/24 brd 192.168.87.255 scope global wan1
    inet6 fe80::9eb6:54ff:febb:aa8c/64 scope link 
       valid_lft forever preferred_lft forever
3: wan2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 9c:b6:54:bb:aa:8d brd ff:ff:ff:ff:ff:ff
    inet 192.168.89.2/24 brd 192.168.89.255 scope global wan2
    inet6 fe80::9eb6:54ff:febb:aa8d/64 scope link 
       valid_lft forever preferred_lft forever
4: crp: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:de:21:00 brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.2/24 brd 172.16.10.255 scope global crp
    inet6 fe80::215:17ff:fede:2100/64 scope link 
       valid_lft forever preferred_lft forever
5: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:15:17:de:21:01 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::215:17ff:fede:2101/64 scope link 
       valid_lft forever preferred_lft forever
6: vlan101@lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:15:17:de:21:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global vlan101
    inet6 fe80::215:17ff:fede:2101/64 scope link 
       valid_lft forever preferred_lft forever
7: vlan102@lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:15:17:de:21:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global vlan102
    inet6 fe80::215:17ff:fede:2101/64 scope link 
       valid_lft forever preferred_lft forever
8: vlan103@lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:15:17:de:21:01 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.1/24 brd 192.168.4.255 scope global vlan103
    inet6 fe80::215:17ff:fede:2101/64 scope link 
       valid_lft forever preferred_lft forever
63: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet xxx.xxx.232.8 peer 10.128.0.0/32 scope global ppp0
91: ppp5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1456 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 10.236.13.11 peer 10.128.0.0/32 scope global ppp5
92: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet xxx.xxx.11.5 peer xxx.xxx.0.1/32 scope global ppp1

Вот роуты: 

default dev ppp0  scope link 
10.0.0.0/8 via 10.236.13.11 dev ppp5 
10.0.0.0/8 via 172.16.10.2 dev crp  metric 30 
10.128.0.0 dev ppp0  proto kernel  scope link  src 5.140.232.8 
10.128.0.0 dev ppp5  proto kernel  scope link  src 10.236.13.11 
172.16.0.0/16 via 172.16.10.2 dev crp  metric 30 
172.16.10.0/24 dev crp  proto kernel  scope link  src 172.16.10.2 
xxx.xxx.0.1 dev ppp1  proto kernel  scope link  src xxx.xxx.11.5 
192.168.2.0/24 dev vlan101  proto kernel  scope link  src 192.168.2.1 
192.168.3.0/24 dev vlan102  proto kernel  scope link  src 192.168.3.1 
192.168.4.0/24 dev vlan103  proto kernel  scope link  src 192.168.4.1 
192.168.87.0/24 dev wan1  proto kernel  scope link  src 192.168.87.2 
192.168.89.0/24 dev wan2  proto kernel  scope link  src 192.168.89.2 
xxx.xxx.87.41 dev ppp0  scope link  src xxx.xxx.232.8

Может быть здесь что-то не так?

★

Последнее исправление: gard (всего исправлений: 1)

Ответ на: комментарий от zolden

Сейчас, пока сообщения не сыпятся и мало включенных компьютеров - ip n выводит около 20ти записей. Попробую выполнить, когда опять будет переполнение, хотя arp -avn мне выполнить не удавалось. Ругалось на что-то вроде «маловато памяти».

gard ★
() автор топика
Ответ на: комментарий от gard

думаю ты понял смысл - надо понять не бага ли это, может тебе левые записи сыпятся, и если это корректное поведение на сети, то надо увеличить размер ARP таблицы

zolden ★★★★★
()
Ответ на: комментарий от zolden

Да, смысл понятен. Вообще это явно не корректное поведение. Странно то, что до замены шлюза на новый - все работало и странно то, что ситуация исправляется стоит выдернуть провод провайдера, а не локальной сети. Надо смотреть что там за адреса.

gard ★
() автор топика

От провайдера в ARP-кеш прилетает много лишнего. Я бы или arptables накрутил, или

cd /proc/sys/net/ipv4/conf/eth0

echo 0 > arp_accept
echo 2 > arp_ignore
echo 1 > arp_announce
echo 1 > arp_filter

Ещё стоит снять дапм с прилетающего трафика и посмотреть wireshark-ом.

selivan ★★★
()

Сколько интерфейсов в сети? Если меньше 128-ми, то по-дефолту, даже сборщик мусора не должен запускаться!

Возможны варианты:

1. Левые арпы сыплются через провайдерский интерфейс. Если у тебя только PPPoE, то тебе не только арп, тебе даже айпишники на нем не нужны. Отключить в любом случае с целью профилактики.

2. Какая-то сволочь сканит сеть, а бедный рутер прилежно записывает возникающие при этом арпы.

Но, ЕМНИП, такое поведение будет только с включенным proxy ARP.

3. Тебя похачили, и с рутера запускают сканер сети.

В любом случае нужно смотреть содержимое таблицы соседей.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Да, наверное надо убрать IP-адрес у сетевок, смотрящих на провайдеров. Задал наобум что-то вроде 192.168.88.2 и 192.168.89.2. Просто не разобрался сходу как сделать, чтобы интерфейс при старте системы поднимался, даже если на нем нет IP и не настроено получение адреса по DHCP. Но в общем есть вариант поднимать интерфейсы через pre-up для ppp-соединений.. спасибо за совет.

gard ★
() автор топика
Ответ на: комментарий от selivan

Спасибо, надо будет покурить эти параметры подробнее ))

gard ★
() автор топика
Ответ на: комментарий от gard

А вообще провайдер такой провайдер. Вполне возможно, что сканят сеть клиенты провайдера. Просто клиенты провайдера с Windows видят в сетевом окружении кучу компов других клиентов )))

gard ★
() автор топика
Ответ на: комментарий от gard

как сделать, чтобы интерфейс при старте системы поднимался, даже если на нем нет IP и не настроено получение адреса по DHCP

/etc/interfaces:

auto eth0
iface eth0 inet manual
up ip link set dev eth0 up
down ip link set dev eth0 down

selivan ★★★
()
Последнее исправление: selivan (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin