CCR1009-7G-1C неадекватная нагрузка

[seagull]

Приветствую!

 

Дано:

CCR1009-7G-1C,  v6.48.1

На портах ether1-4 собран бондинг - для надежности и производительности.

На бондинг навешиваются внутренние и внешние вланы.

Железка служит PPTP и PPPoE сервером, авторизация радиусом.

Шифрование и сжатие запрещено.

на VPN сессии создаются simple queue, типа PCQ, с параметрами рекомендованными тут на форуме.

 

Проблема - изначально после присоединения порядка 100 пользователей нагрузка показалась великовата - в среднем около 20-30% при трафике мегабит до 200 всего.

Потом через несколько часов, при 120 сессиях - вообще взлетела до 100% по всем ядрам.

PPS по интерфейсам нормальный, флудов, досов не видно.

По результату профайлинга - основной источник нагрузки - firewall.

По ядрам если смотреть - основная нагрузка в IRQ.

 

Откуда нагрузка в файрволе - непонятно.

NATа нет!

Tracking по понятным причинам отключить не могу.

Правила файрвола обычные самые, содержимое пакетов вроде не анализирую, самые частые правила - вверху.

Ситуация кажется мне не очень нормальной, не может же быть 200мбит и 100 клиентов потолком для этой железки, бред же какой-то?

Посоветуйте, где копать-то?

 

[jffulcrum]

Вообще, 200 человек на CCR1009-8G-1S в свое время был предел для PPTP+queue. Так что похоже вы нашли свой потолок.

[seagull]

Что, без НАТа 200 человек - предел???

Тогда непонятно, почему на картинке профайлера выше firewall - 75.5%, а queueing - 3%.

[Saab95]

Просто надо бондинг убрать, а так же почикать большую часть правил на последней картинке с зелеными галочками.

[seagull]

Так, про бондинг да, были подозрения. Надо попробовать.

А что, есть информация, что жрет ресурсы? Я искал, ничего не нашел на эту тему.

Про почикать - это простите как? Да и зачем, если 99% пакетов пропускаются правилами 1 или 2, и дальше не идут по цепочке?

[Saab95]

21 час назад, seagull сказал:

Про почикать - это простите как? Да и зачем, если 99% пакетов пропускаются правилами 1 или 2, и дальше не идут по цепочке?

Это убрать все не нужное. Разрешающие правила вообще не нужны, и блокировать все не нужно.

 

Достаточно закрыть порт винбокса, и заблокировать абонентам доступ на роутер (если требуется), так же закрыть порт ДНС с инета, если используется. Так же правило блокировки должников, по сути это 4-5 правил.

В НАТ так же достаточно 2-х правил, первое для самого НАТ, второе для переадресации на веб прокси должников.

В манглах ничего быть не должно, максимум схема для предоставления бесплатного доступа в сеть для должников. Это 4 правила.

 

21 час назад, seagull сказал:

А что, есть информация, что жрет ресурсы? Я искал, ничего не нашел на эту тему.

Жрет ресурсы у вас файрвол.

 

21 час назад, seagull сказал:

Так, про бондинг да, были подозрения. Надо попробовать.

Вместо бондинга хорошо работает SFP+ порт.

[seagull]

Писал же, чему там жрать в файрволе, если большинство пакетов дальше 1-2 правила не проходят по цепочке???

Если делать по вашему - default accept, а перед ними все запрещать, наоборот длиннее путь получится.

Вообще кстати, best practice все же закрывать все, а открывать только нужное, а не наоборот.

НАТа и мангла нет - опять же писал.

А SFP+ порта там нет.

[NiTr0]

В 16.02.2021 в 17:44, seagull сказал:

Ситуация кажется мне не очень нормальной, не может же быть 200мбит и 100 клиентов потолком для этой железки, бред же какой-то?

это некротик, детка. там пптп нифига не ядерный, а юзерспейсный. потому - еще как может...

[seagull]

20 минут назад, NiTr0 сказал:

это некротик, детка. там пптп нифига не ядерный, а юзерспейсный. потому - еще как может...

Так по профайлинге жрет не пптп, а файрвол...

[Saab95]

2 часа назад, seagull сказал:

Писал же, чему там жрать в файрволе, если большинство пакетов дальше 1-2 правила не проходят по цепочке???

 

2 часа назад, seagull сказал:

Вообще кстати, best practice все же закрывать все, а открывать только нужное, а не наоборот.

Как в этом случае по цепочке проходят правила? В этом случае 100 процентов пакетов, проходящих через оборудования, проходят через файрвол.

 

Вот во вложении картинка, всего 9 правил:

 

0-2 выделено синим это защита от пропуска в сеть вирусных портов 445 и 1900. Блокируется входящий и исходящий трафик по ним.

3-5 блокировка ограничения доступа на микротик, разрешено только с админской подсети. С остальных адресов на него попасть нельзя (запустить пинг, зайти в винбокс).

6 правило блокировки возврата трафика, то есть нельзя отправлять в интернет трафик с IP назначения = IP своих белых подсетей.

7 блокировка доступа на веб прокси всем, кроме адресов абонентов.

8 блокировка доступа на микротик через ssh всех, кроме биллинга.

9 блокировка доступа в интернет абонентов, IP которых есть в адрес листе.

 

Все службы кроме винбокса и ссш отключены.

 

В пиках проходит до 5г трафика, CCR1036, никаких проблем не возникает.

[seagull]

18 минут назад, Saab95 сказал:

Как в этом случае по цепочке проходят правила? В этом случае 100 процентов пакетов, проходящих через оборудования, проходят через файрвол.

Нет, не так.

Может конечно у микротика какой-то свой, особенный iptables, но по классике, правило accept является терминирующим, то есть после него пакет выходит из таблицы FILTER.

То есть, в моем случае, большинство пакетов проходят 1-2 правила, а вашем - 9.

А у вас conntrack работает?

[Saab95]

2 часа назад, seagull сказал:

НАТа и мангла нет - опять же писал.

Если НАТа нет, conntrack не нужен, его следует выключать.

В моем примере он включен, т.к. на этом устройстве NAT происходит.

 

17 минут назад, seagull сказал:

Может конечно у микротика какой-то свой, особенный iptables, но по классике, правило accept является терминирующим, то есть после него пакет выходит из таблицы FILTER.

Так и есть, только через это правило опять же проходит весь трафик.

Если перейти на схему разрешено все, что на запрещено, то 95 процентов трафика вообще не будут файрволом обрабатываться. Это сильно снижает нагрузку на оборудование.

 

[NiTr0]

4 часа назад, seagull сказал:

Так по профайлинге жрет не пптп, а файрвол...

а вы уверены что профайлинг там нормально время считает, а не %SI из линукса, который там под капотом? :)

 

2 часа назад, Saab95 сказал:

Если перейти на схему разрешено все, что на запрещено, то 95 процентов трафика вообще не будут файрволом обрабатываться. Это сильно снижает нагрузку на оборудование.

бред же. пакет сначала проходит ВСЕ проверки на запреты, и только потом попадает в accept.

[seagull]

3 часа назад, Saab95 сказал:

Если НАТа нет, conntrack не нужен, его следует выключать.

Да, можно отключить,  но тогда stateful функционал в файрволе не будет работать.

Что выгодней по ресурсам - вопрос...

 

55 минут назад, NiTr0 сказал:

а вы уверены что профайлинг там нормально время считает, а не %SI из линукса, который там под капотом? :)

Нет, не уверен - просто опираюсь на то, что есть...

Но если я правильно понимаю, userspace процессы как раз таки в SI не должны попадать.

SI - это же что-то вроде сетевых драйверов, и тд, процессов ядра в общем?

[NiTr0]

21 минуту назад, seagull сказал:

Но если я правильно понимаю, userspace процессы как раз таки в SI не должны попадать. 

там же основной затык-то не в юзерспейсе как таковом, а в передаче из кернел спейса в юзерспейс и наоборот, с переключением контекста. именно тут и наступает боль для pptp, и именно оно и попадает в SI.

[starik-i-more]

В 18/02/2021 в 10:45, NiTr0 сказал:

это некротик, детка. там пптп нифига не ядерный, а юзерспейсный.

А L2TP ядерный или userspace? 

[NiTr0]

4 часа назад, starik-i-more сказал:

А L2TP ядерный или userspace? 

вроде как ядерный должен быть, но я его особо не гонял.

[starik-i-more]

А как можно проверить? 

[Timax]

Добрый день! Чтобы не плодить темы задам вопрос тут. Имеется CCR1009-7G-1C-1S+. CCR подключен к агрегации через 10G порт. Аплинк vlan и клиентские vlan идут через один порт 10G. Подключено в районе 200 клиентов pppoe, из этих клиентов есть несколько стриммеров, которые стримят на ютубе, от данных клиентов поступают жалобы на низкий битрейт, плавающий битрейт, потери. Вообщем подключились тестовым ноутом, поставили OBS запустили трансляцию - действительно проблемы есть. При этом на CCR загрузка проца не превышает 50%, трафика не более 500-600 мбит. Дропов, ошибок нет, как на стороне ccr так и на стороне коммутатора. Есть подобные узлы где так же стоят CCR 1009 с большей нагрузкой и таких проблем нет, единственное что аплинк и даунлинк вланы на разных портах. Решили раскидать вланы по портам, аплинк влан оставили на 10г, остальные раскидали по другим портам и вуаля проблем нет. Так вот вопрос почему такие проблемы на 10г порту при трафике RX/TX 600/600 мбит? Ведь по идее интерфейс подключен к процу, чипа коммутации нет. Можно ли как то это победить? 

[jffulcrum]

41 минуту назад, Timax сказал:

При этом на CCR загрузка проца не превышает 50%

Дьявол кроется в деталях - откройте Tools - Profile в Winbox. С высокой вероятностью у вас одно из ядер в полке, оттого и печали. Увы, но на каком-то этапе у вас очередь интерфейса - одна, и обслуживать ещё будет одно ядро. Но, возможно, ещё раньше бьетесь в FW или Queue, кстати, шейпинг есть?

[Timax]

26 минут назад, jffulcrum сказал:

Дьявол кроется в деталях - откройте Tools - Profile в Winbox. С высокой вероятностью у вас одно из ядер в полке, оттого и печали. Увы, но на каком-то этапе у вас очередь интерфейса - одна, и обслуживать ещё будет одно ядро. Но, возможно, ещё раньше бьетесь в FW или Queue, кстати, шейпинг есть?

По поводу одного ядра в полку-возможно, сейчас пока этого нет, но проблемы начинаются и при общей нагрузке CPU в 20 %. Шейпинг есть.

[Saab95]

Цитата

Ведь по идее интерфейс подключен к процу, чипа коммутации нет. Можно ли как то это победить? 

Можно - увеличить размер буфера шейпера абонентов. Изменить аппаратный буфер на PFIFO и туда много много байт буфер, или сразу на PCQ так же с большим буфером.

 

Тут схема работы через один порт простая - пакет попал на устройство, встал в очередь на обработку, был обработан и встал в очередь на отправку, был отправлен. Если используется один интерфейс то у него обе стороны (прием и передача) работают на одинаковой скорости, т.к. сначала принимает и после передает. Аппаратный буфер всегда переполнен.

 

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

[Timax]

15 минут назад, Saab95 сказал:

Можно - увеличить размер буфера шейпера абонентов. Изменить аппаратный буфер на PFIFO и туда много много байт буфер, или сразу на PCQ так же с большим буфером.

 

Тут схема работы через один порт простая - пакет попал на устройство, встал в очередь на обработку, был обработан и встал в очередь на отправку, был отправлен. Если используется один интерфейс то у него обе стороны (прием и передача) работают на одинаковой скорости, т.к. сначала принимает и после передает. Аппаратный буфер всегда переполнен.

 

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

Добрый день! Данный метод пробовали в самом начале, не помогает. А что вы имеете ввиду под словом аппаратный? Поменять тип очереди на Ethernet интерфейсах?

Edited March 3, 2023 by Timax

[korsakik]

В 04.03.2023 в 01:04, Timax сказал:

Добрый день! Данный метод пробовали в самом начале, не помогает. А что вы имеете ввиду под словом аппаратный? Поменять тип очереди на Ethernet интерфейсах?

Попробуйте, снизить таймеры в IP - Firewall - connections - tracking. У нас общую нагрузку это снижало. PCQ использовать надо с оглядкой.

 

Покажите tool profile.

 

Ssh и прочее у людей не отваливаются с такими заниженными параметрами, жалоб 0, работает уже несколько лет (это для экспертов которые могут щас налететь с комментариями).

 

Плюс проверяйте загруженность канала до серверов YT. Был у нас как то стример который вдувал >50 Мбит битрейта на сервера и жаловался на кадры, только вот после общения с YT выяснилось, что там нужный битрейт не более 12 МБит для 1080 60fps. Более они сами отбрасывают.

 

Edited March 4, 2023 by korsakik

[Saab95]

Да, на самих интерфейсах. Тогда после переполнения буфера сетевой карты данные начнут поступать в программный буфер.

 

Но тут есть лишь один нюанс. Когда буфера только аппаратные, в случае большого потока, который процессор не сможет обработать, пойдут дропы, но доступ на устройство будет. Если же поток данных будет больше возможностей процессора, и буфер дополнительный программный, то доступ на устройство может полностью пропасть или стать ограниченным, т.к. все пакеты сверх буфера будут просто отброшены.