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

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

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

В какой-то момент мы переместили одну из машин на новое оборудование, включая raid-контроллер, и установили ядро ​​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 / lie / default / gc_thresh *

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

До свидания,

- Creis