Примечание. У меня уже есть способ решения этой проблемы (как описано ниже), так что это всего лишь вопрос, о котором вы хотите знать.
У меня есть продуктивная установка с примерно 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