sirmax Опубликовано 20 октября, 2014 · Жалоба коллеги доброго дня! Странное поведение на линукс роутре 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 Никаких толковых мыслей нет - "игры" с параметрами ядра ничего не дали, буду рад любым советам куда копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 20 октября, 2014 · Жалоба Не привожу настройки намерено - перепробовал много и было б очень интетерсно услыщать рекомендации, считая что все настроено "по дефолту". Маков в сети порядка 2-3 тыс активных, и потенципльно куда больше - т.к. маска большая на интерфейсе Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 октября, 2014 · Жалоба Памяти ему где то не хватает. На фре оно mbuf называется, на линухах skpacket или что то похожее, где тюнится - хз. Может тупо в оперативу упёрся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 октября, 2014 · Жалоба arp таблицы и коннтрак не переполнены? Такое было то ли при переполнении арп, то ли при переполнении коннтрака у меня. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба Насчет арпов не похоже - там он ругается обычно о переполнении таблицы соседей. С контракком тоже на первый взгляд не оно - нет ната и нотрак правила стоят для реальников, а фейков мало. Проблема обостряется при увеличении числа вланов в бридже даже при условии что в них нет траффика. Такое ощущение что бридж теряется при большом числе портов . Сходу правда ничего не гагуглил по этой теме Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 21 октября, 2014 · Жалоба Порылся в архивах, нашел вот что: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба taf_231 Попробовал - не привело к успеху. Проблема именно в бридже - траффик который не проходит через бридж идет нормально На бридже - потери от 2% до 20% если в него насыпать вланов (висящих в воздухе) У кого-то есть бриджи из 100+ интерфейсов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 21 октября, 2014 · Жалоба Попробуйте отключить dhcp на серваке Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба Попробуйте отключить dhcp на серваке ... вместе с сервером? dhcp snopping штука такая - не работает без сервера. не могу я его отключить. Собственно беспокоят не столько сообщения в логи сколько потери в 1-2% но везе в пределах бриджа - уверен что ошибки это следствие а не причина Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 21 октября, 2014 · Жалоба а тут прикол походу в ebtables , не справляется оно. Я гдето видел патчик который делал horizon как у микротика (но было это очень давно), походу это единственное решение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба martini А как это ТОЧНО проверить? перф топ вроде ничего такого необычного мне не показывает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба как я понимаю сделать запрет транзитного траффика на бридже без ebtables нельзя? iptables -I FORWARD --out-interface br0 -m mac --mac-source <mac br0> не имеет матчей. Это впринципе логично но не то что надо. Коллеги, дайте идеи - куда копать? Если в бридже много интерфейсов и много маков - может какой-то хеш недостаточного размера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 21 октября, 2014 · Жалоба Поидее запретить форвардинг с ин-интерфейс бр0 и аут-интерфейс бр0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 21 октября, 2014 · Жалоба Поидее запретить форвардинг с ин-интерфейс бр0 и аут-интерфейс бр0 Я прошу прощения, но это конечно будет работать но убьет конекшен между клиентами что нехорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 21 октября, 2014 · Жалоба так а ты включи хоть на время, чтобы точно проверить это ebtables или нет. Думаю за пол часа с клиентами ниче не случится если они друг у друга порнуху не покачают.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 21 октября, 2014 (изменено) · Жалоба Я прошу прощения, но это конечно будет работать но убьет конекшен между клиентами что нехорошо. Убить бридж и поднять прокси арп? Для межвланового общения. Изменено 21 октября, 2014 пользователем GrandPr1de Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 22 октября, 2014 · Жалоба 2 GrandPr1de - тогда не будет работать псевдосупервлан ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 22 октября, 2014 (изменено) · Жалоба 2 GrandPr1de - тогда не будет работать псевдосупервлан ) Я немного смысла с этого псевдосупервлана не улавливаю просто. Если хочется вешать сервис на один интерфейс - то загони все вланы в одну железяку. Сервисы держи на другой железке. В первой все вланы живут, а на сервисы уже клиенты идут по л3. Для кого релей придумали?) Забиндить дхцп к чертям на лупбек, и гнать релеем их со всех вланов, как вариант. Изменено 22 октября, 2014 пользователем GrandPr1de Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 22 октября, 2014 · Жалоба А чем псевдосупервлан то плох? Вист на нем сеток несколько /22 для клиентов - дхцп раздает а свитчи фильтруют, траффик между портами бриджа (по сути - вланами в сети) - фильтрует ебтабез Т.е для меня пока выгляит как бы вполне себе решеним - гиммороем с мелкими сетями и вечно "ав этом влане у нас ИПы кончилися" я сыт, спасибо =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 октября, 2014 · Жалоба А чего бы тогда accel-ppp не использовать в л2 режиме? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 22 октября, 2014 · Жалоба А чего бы тогда accel-ppp не использовать в л2 режиме? Действительно, и вообще влан на пользователя раскидать, ещё проще будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 23 октября, 2014 · Жалоба А чего бы тогда accel-ppp не использовать в л2 режиме? Я не вкурсе как это работает в L2 режиме - схема собиралась достаточно довно и работала стабильно до резкого возрастания числа вланов и маков. accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает". А чего бы тогда accel-ppp не использовать в л2 режиме? Действительно, и вообще влан на пользователя раскидать, ещё проще будет. Влан на пользователя - да, а как там IP выдавать, /30 же? Или есть что-то получше типа ip unnumbered на линуксе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 23 октября, 2014 · Жалоба accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает". Это уже много лет не так. Загляните в соседнюю ветку, посмотрите что он сейчас для ipoe умеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 23 октября, 2014 · Жалоба accel-ppp ведь это ВПН а задача была сделать максимально просто для настройки со стороны клиента - "включил и работает". Это уже много лет не так. Загляните в соседнюю ветку, посмотрите что он сейчас для ipoe умеет. Cпасибо - беглое прочтение вызвало легкий шок ) Я то свою схемку собирал лет и лет назад уже. Собственно и чиню потому что проблемка вылезла - годы это все работало без сбоев. В сторону ipoe+accel посмтотрю но все таки хотелось вернуться к4 теме бриджей и псевдо-супервланов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 23 октября, 2014 · Жалоба В сторону ipoe+accel посмтотрю но все таки хотелось вернуться к4 теме бриджей и псевдо-супервланов В линуксах, как вы сказали есть нормальный аналог ip unnumbered. Можно давать клиентам влан с /32, прозрачной адресацией и прозрачным же трафиком между клиентами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...