Jump to content
Калькуляторы

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

taf_231

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

martini

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this