LINUX.ORG.RU
ФорумAdmin

Странно ходит трафик в bridge

 , , , ,


0

3

Конфа такая

                                                                     __ (iptables zone2)  lxc-node2 10.0.0.2/24
                                                                    / 
host1(mysql) 10.0.0.4/24 7c:e4:aa:c2:02:59 <- (LAN)->  linuxhost (bridge) 
                                                              \__(iptables zone3) lxc-node3 10.0.0.3/24 7c:e4:aa:00:5f:54 
                                               

  • iptables настроен для всех bridge ports.

Очень рандомно, если пару часов, условно, не ломиться на mysql с node3, первая попытка коннекта к базе с node3 может дать сбой, т.к. пакет вдруг пошел на node2 (см. лог iptables). Следующая попытка коннекта успешна, т.к. SYN пакет уже пошел в сторону host1 через bridge- > LAN… Я такое что-то не припомню, что видел где-то. Есть мысли, где и что загуглить?

Лог iptabels May 24 00:29:04 linuxhost zone3-zone2 REJECT IN=br1 OUT=br1 MAC=7c:e4:aa:c2:02:59:7c:e4:aa:00:5f:54:08:00 SRC=10.0.0.3 DST=10.0.0.4 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=37022 DF PROTO=TCP SPT=37214 DPT=3306 SEQ=1547163638 ACK=0 WINDOW=64240 SYN URGP=0 MARK=0x0

★★

Последнее исправление: macumazan (всего исправлений: 4)
Ответ на: комментарий от firkax

Да, похоже. Если ping с node3 -> mysql запусть на постоянку, то проблема исчезает. Какая-то чертовщина.

59 - мак базы
54 - мак node3

macumazan ★★
() автор топика
Последнее исправление: macumazan (всего исправлений: 1)
Ответ на: комментарий от macumazan

А, точнее я не arp-кеш имел ввиду а кеш соответствия маков с портами. Свитч же например когда не знает на каком порту нужный мак - шлёт широковещательно. Тут не свитч но что-то аналогичное.

А если пинговать не с node3 а с node2 - исчезает? Или пинг должен быть оттуда же откуда потом реальные запросы?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

ping с node2 тоже помогает. Выяснилось, что сей пинг поддерживает запись 7c:e4:aa:c2:02:59 dev eth0 master br1 в bridge fdb на linuxhost. Как эта запись исчезнет, запрос TCP SYN c node3 пойдет сначала через node2 и зарежется iptables. В течении ~2х секунд надо сделать повторный запрос к базе и тогда он сработает. Если выждать более ~2х, то опять пройдет через node2 и опять зарежется. Что-то заставляет ядро в приоритете засылать сначала «на ближайшего соседа» из bridge.

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

Судя по «IN=br1 OUT=br1» у тебя включен nf_call_iptables (посмотреть тожно через ip -d li sh br1).

Если ты осознано включил nf_call_iptables и не стал добавлять специфические правила для фильтрации трафика моста в iptables, то ты ССЗБ.

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

Судя по всему в твоих правилах пакет «IN=br1 OUT=br1» был неожидаемый, раз ты такие пакеты дропаешь.
У тебя 2 вырианта: либо отключить nf_call_iptables, либо добавляешь правила для форвардинга пакетов через бридж.
nf_call_iptables достаточно хитрая вещь и используется достаточно ограниченно.

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