Переповнення сусідньої таблиці на хостах Linux, пов’язаних з мостом та ipv6

Примітка. У мене вже є вирішення цієї проблеми (як описано нижче), тому це лише питання "хочу знати".

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

Одного разу ми перенесли одну з машин на нове обладнання, включаючи рейдовий контролер, і тому ми встановили ядро ​​версії 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 -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.

Єдиним іншим натяком було збіг оновлення хоста з початком проблем. Я вимкнув хост, про який йде мова, і помилок не було. Тоді я згодом зняв мости на хості, і коли я зняв (якщо конфігурувати вниз) один особливо міст:

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, які у всіх аспектах однакові, окрім влан, до якого вони підключені, не впливали при знятті . Тепер я відключив 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 / susjed / default / gc_thresh *

Ви зробили те ж саме для ipv6? що вирішило проблему для нас

До побачення,

- Кріс