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

Переполнение таблицы соседей на хостах Linux, связанных с мостом и ipv6

Примечание. У меня уже есть способ решения этой проблемы (как описано ниже), так что это всего лишь вопрос, о котором вы хотите знать.

У меня есть продуктивная установка с примерно 50 хостами, включая блейд-серверы с xen 4 и equallogics, обеспечивающие iscsi. Все xen dom0 - это почти простой Debian 5. Установка включает в себя несколько мостов на каждом dom0 для поддержки мостовых сетей xen. Всего на каждом домене dom0 имеется от 5 до 12 мостов, обслуживающих по одному vlan. Ни на одном из хостов не включена маршрутизация.

В какой-то момент мы переместили одну из машин на новое оборудование, включая рейд-контроллер, и поэтому мы установили исходное ядро ​​3.0.22 / x86_64 с патчами xen. На всех остальных машинах работает debian xen-dom0-kernel.

С тех пор мы замечали на всех хостах в настройке каждые ~ 2 минуты следующие ошибки:

[55888.881994] __ratelimit: 908 callbacks suppressed
[55888.882221] Neighbour table overflow.
[55888.882476] Neighbour table overflow.
[55888.882732] Neighbour table overflow.
[55888.883050] Neighbour table overflow.
[55888.883307] Neighbour table overflow.
[55888.883562] Neighbour table overflow.
[55888.883859] Neighbour table overflow.
[55888.884118] Neighbour table overflow.
[55888.884373] Neighbour table overflow.
[55888.884666] Neighbour table overflow.

Таблица arp (arp -n) никогда не показывала более 20 записей на каждой машине. Мы попробовали очевидные настройки и повысили

/proc/sys/net/ipv4/neigh/default/gc_thresh*

ценности. Наконец, до 16384 записей, но никакого эффекта. Не изменился даже интервал ~ 2 минуты, что привело меня к выводу, что это совершенно не связано. tcpdump не показал необычного трафика ipv4 на любом интерфейсе. Единственным интересным открытием tcpdump были пакеты ipv6, например:

14:33:13.137668 IP6 fe80::216:3eff:fe1d:9d01 > ff02::1:ff1d:9d01: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:9d01, length 24
14:33:13.138061 IP6 fe80::216:3eff:fe1d:a8c1 > ff02::1:ff1d:a8c1: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:a8c1, length 24
14:33:13.138619 IP6 fe80::216:3eff:fe1d:bf81 > ff02::1:ff1d:bf81: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:bf81, length 24
14:33:13.138974 IP6 fe80::216:3eff:fe1d:eb41 > ff02::1:ff1d:eb41: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff1d:eb41, length 24

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

Единственным другим намеком было совпадение обновления хоста с началом проблем. Я выключил рассматриваемый хост, и ошибки исчезли. Затем я впоследствии снял мосты на хосте, и когда я снял (ifconfig down) один конкретный мост:

br-vlan2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:120 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5286 (5.1 KiB)  TX bytes:726 (726.0 B)

eth0.2159 Link encap:Ethernet  HWaddr 00:26:b9:fb:16:2c  
          inet6 addr: fe80::226:b9ff:fefb:162c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:126228 (123.2 KiB)  TX bytes:1464 (1.4 KiB)

bridge name bridge id       STP enabled interfaces
...
br-vlan2158     8000.0026b9fb162c   no      eth0.2158
br-vlan2159     8000.0026b9fb162c   no      eth0.2159

Ошибки снова исчезли. Как видите, у моста нет IPv4-адреса, и единственным его членом является eth0.2159 поэтому транспорт не должен пересекать его. Мост и интерфейс .2159 / .2157 / .2158 которые во всех аспектах идентичны, за исключением vlan, к которому они подключены, не оказали никакого эффекта при отключении. Теперь я отключил ipv6 на всем хосте через sysctl net.ipv6.conf.all.disable_ipv6 и перезагрузился. После этого даже с мостом br-vlan2159 включен, ошибок не возникает.

Любые идеи приветствуются.

Я считаю, что ваша проблема связана с ошибкой ядра, которая была исправлена ​​в net-next.

Отслеживание многоадресной рассылки отключается при инициализации моста из-за ошибки при попытке перехэширования таблицы. Отслеживание IGMP не позволяет мосту пересылать каждый ответ на многоадресный запрос HBH ICMPv6, что приводит к заполнению таблицы соседей ff02:: соседи из многоадресных ответов, которые должны не увидеть (попробовать ip -6 neigh show nud all).

Правильный обходной путь - попытаться повторно включить отслеживание, например: echo 1 > /sys/class/net/eth0/bridge/multicast_snooping. Альтернативный вариант - сделать пороговые значения gc таблицы соседей больше, чем количество хостов в широковещательном домене.

Патч есть Вот.

что возвращение ip route show cache table all когда вы столкнулись с этой ошибкой?

arp -n или ip neigh show покажет только некоторые записи в кеше.

ip route show cache table all будет гораздо более подробным (и будет включать много записей, связанных с v6).

Мы попробовали очевидные настройки и подняли / proc / sys / net / ipv4 / neigh / default / gc_thresh *

Вы сделали то же самое для ipv6? это решило проблему для нас

До свидания,

- Creis