linux router - bridge + dhcp - send_packet: No buffer space available

[sirmax]

коллеги доброго дня!

 

Странное поведение на линукс роутре

send_packet: No buffer space available

 

Клиенты по большей части работают нормально но в сети небольшие потери - 2-3%

некоторые TCP сессии не разгоняются хотя с роутреа все нормально

 

Организация сети такая ( в общих чертах)

- всего одна сетевая карта в роутре

- куча вланов

- 1 влан - вплинк

- примерно 100 вланов - сбриджованы в подобие супервалана, траффик между ними перекрыт ebtables

- dhcp на этом бридже и на нем же арп прокси

- шейпера - отключение шейперов ничего не дает

- траффик порядка 2гиг на исход на клиентов (естественно столько же на вход на другом влане)

- сетевая карта

ethtool  -i eth4
driver: ixgbe
version: 3.19.1-k
firmware-version: 0x61c10001
bus-info: 0000:05:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f9600000 (64-bit, prefetchable) [size=512K]
I/O ports at e000 [size=32]
Memory at f9700000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 90-e2-ba-ff-ff-4a-d3-3c
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: ixgbe

 

Никаких толковых мыслей нет - "игры" с параметрами ядра ничего не дали, буду рад любым советам куда копать.

[sirmax]

Не привожу настройки намерено - перепробовал много и было б очень интетерсно услыщать рекомендации, считая что все настроено "по дефолту".

Маков в сети порядка 2-3 тыс активных, и потенципльно куда больше - т.к. маска большая на интерфейсе

[Ivan_83]

Памяти ему где то не хватает. На фре оно mbuf называется, на линухах skpacket или что то похожее, где тюнится - хз. Может тупо в оперативу упёрся.

[NiTr0]

arp таблицы и коннтрак не переполнены? Такое было то ли при переполнении арп, то ли при переполнении коннтрака у меня.

[sirmax]

Насчет арпов не похоже - там он ругается обычно о переполнении таблицы соседей. С контракком тоже на первый взгляд не оно - нет ната и нотрак правила стоят для реальников, а фейков мало. Проблема обостряется при увеличении числа вланов в бридже даже при условии что в них нет траффика.

 

Такое ощущение что бридж теряется при большом числе портов . Сходу правда ничего не гагуглил по этой теме

[taf_321]

Порылся в архивах, нашел вот что:

 

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_congestion_control = htcp
net.netfilter.nf_conntrack_max = 524286
net.netfilter.nf_conntrack_tcp_timeout_established = 28800
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_intvl=120
net.ipv4.tcp_keepalive_probes=4
net.ipv4.tcp_keepalive_time=3600
net.ipv4.tcp_max_syn_backlog=1280
net.ipv4.tcp_orphan_retries=1
net.ipv4.tcp_sack=0
net.ipv4.tcp_window_scaling=0

[sirmax]

taf_231

Попробовал - не привело к успеху.

Проблема именно в бридже - траффик который не проходит через бридж идет нормально

На бридже - потери от 2% до 20% если в него насыпать вланов (висящих в воздухе)

 

У кого-то есть бриджи из 100+ интерфейсов?

[Antares]

Попробуйте отключить dhcp на серваке

[sirmax]

Попробуйте отключить dhcp на серваке

... вместе с сервером?

dhcp snopping штука такая - не работает без сервера. не могу я его отключить.

Собственно беспокоят не столько сообщения в логи сколько потери в 1-2% но везе в пределах бриджа - уверен что ошибки это следствие а не причина

[martini]

а тут прикол походу в ebtables , не справляется оно. Я гдето видел патчик который делал horizon как у микротика (но было это очень давно), походу это единственное решение

[sirmax]

martini

А как это ТОЧНО проверить? перф топ вроде ничего такого необычного мне не показывает

[sirmax]

как я понимаю сделать запрет транзитного траффика на бридже без ebtables нельзя?

iptables -I FORWARD  --out-interface br0 -m mac --mac-source  <mac br0>

не имеет матчей.

Это впринципе логично но не то что надо.

 

Коллеги, дайте идеи - куда копать?

 

Если в бридже много интерфейсов и много маков - может какой-то хеш недостаточного размера?

[GrandPr1de]

Поидее запретить форвардинг с ин-интерфейс бр0 и аут-интерфейс бр0

[sirmax]

Поидее запретить форвардинг с ин-интерфейс бр0 и аут-интерфейс бр0

Я прошу прощения, но это конечно будет работать но убьет конекшен между клиентами что нехорошо.

[martini]

так а ты включи хоть на время, чтобы точно проверить это ebtables или нет. Думаю за пол часа с клиентами ниче не случится если они друг у друга порнуху не покачают..

[GrandPr1de]

Я прошу прощения, но это конечно будет работать но убьет конекшен между клиентами что нехорошо.

Убить бридж и поднять прокси арп? Для межвланового общения.

Edited October 21, 2014 by GrandPr1de

[martini]

2 GrandPr1de - тогда не будет работать псевдосупервлан )

[GrandPr1de]

2 GrandPr1de - тогда не будет работать псевдосупервлан )

Я немного смысла с этого псевдосупервлана не улавливаю просто.

Если хочется вешать сервис на один интерфейс - то загони все вланы в одну железяку. Сервисы держи на другой железке.

В первой все вланы живут, а на сервисы уже клиенты идут по л3.

Для кого релей придумали?)

Забиндить дхцп к чертям на лупбек, и гнать релеем их со всех вланов, как вариант.

Edited October 22, 2014 by GrandPr1de

[sirmax]

А чем псевдосупервлан то плох?

 

Вист на нем сеток несколько /22 для клиентов - дхцп раздает а свитчи фильтруют, траффик между портами бриджа (по сути - вланами в сети) - фильтрует ебтабез

Т.е для меня пока выгляит как бы вполне себе решеним - гиммороем с мелкими сетями и вечно "ав этом влане у нас ИПы кончилися" я сыт, спасибо =)

[NiTr0]

А чего бы тогда accel-ppp не использовать в л2 режиме?

[GrandPr1de]

А чего бы тогда accel-ppp не использовать в л2 режиме?

Действительно, и вообще влан на пользователя раскидать, ещё проще будет.

[sirmax]

А чего бы тогда accel-ppp не использовать в л2 режиме?

Я не вкурсе как это работает в L2 режиме - схема собиралась достаточно довно и работала стабильно

до резкого возрастания числа вланов и маков.

 

accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает".

 

А чего бы тогда accel-ppp не использовать в л2 режиме?

Действительно, и вообще влан на пользователя раскидать, ещё проще будет.

Влан на пользователя - да, а как там IP выдавать, /30 же?

Или есть что-то получше типа ip unnumbered на линуксе?

[taf_321]

accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает".

 

Это уже много лет не так. Загляните в соседнюю ветку, посмотрите что он сейчас для ipoe умеет.

[sirmax]

accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает".

 

Это уже много лет не так. Загляните в соседнюю ветку, посмотрите что он сейчас для ipoe умеет.

 

Cпасибо - беглое прочтение вызвало легкий шок )

Я то свою схемку собирал лет и лет назад уже. Собственно и чиню потому что проблемка вылезла - годы это все работало без сбоев.

 

В сторону ipoe+accel посмтотрю но все таки хотелось вернуться к4 теме бриджей и псевдо-супервланов

[kayot]

В сторону ipoe+accel посмтотрю но все таки хотелось вернуться к4 теме бриджей и псевдо-супервланов

В линуксах, как вы сказали есть нормальный аналог ip unnumbered. Можно давать клиентам влан с /32, прозрачной адресацией и прозрачным же трафиком между клиентами.