[nixx]

есть узлы сети на микротиках, много ccr1009 (в основном)

работают в качестве шейперов/маршрутизаторов для клиентов, подключенных по схеме vlan-per-user, в каждом влане также поднят dhcp сервер с маской /29, плюс в целом на микротике для абонентов работает днс с форвардингом запросов во внешний мир (ну типа на 8.8.8.8, 1.1.1.1).

еще там есть файерволл из ~4-6 правил с редиректом на сайт провайдера для отключенных абонентов, но он, сцуко, везде разный, и я пока не добился, как же он должен выглядеть в оригинале. походу, буду сам сочинять.

 

и вот пришел сентябрь, абоненты вернулись в родные края кто работать, кто учиться, трафик приподнялся, и все это начало в отдельно взятых местах (т.е. в 2-3 местах из десятка, где такое железо стоит) нещадно тормозить - у абонентов in/out скорость снижается до 1 мбита вместо тарифных 50. при этом загрузка всех ядер - в пределах 40 процентов, т.е. в проц не упирается ну вообще никак.

отключаем шейпинг - тормоза проходят.

шейпинг сделан на simple queues, одна общая очередь в гигабит размером, в которую (как в Parent'а) напиханы персональные абонентские по ~50мбит.

queue type - default-small.

 

вопрос к знатокам (я, увы, вот так плотно в абонентов микротики не впихивал - у меня они сугубо для каналообразующих целей всю жисть были) - как/где дебажить, из-за чего именно скукоживается шейпинг?

абонтрафик ниже микротика дампил, в целом ничего в глаза бросающегося не поймал (ну типа там высоких pps, левых пакетов и прочего). но дампил "по случаю", объем был маленький, по-хорошему надо ехать (увы, далеко и лениво) и снова дампить.

нетбиос позаблочил везде, ipv6 тоже до кучи (до меня вообще никаких acl'ек нигде не было).

 

пока из идей - еще раз половить вредителей сниффером (если они вообще есть), попробовать убрать все редиректы из файерволла, оставив только drop/reject отключенным абонентам.

 

upd: все это происходило на 6.48.6, и также пробовали накатывать 7.5 - без изменений.

Изменено 14 октября, 2022 пользователем nixx
add fw

[jffulcrum]

А мониторинг здоровья самих железяк проблемных что показывает? У CCR1009 была вечная проблема с низкой надежностью карлсонов, пропеллер помирал или начинал еле крутиться - и начинался жесткий тротлинг от перегрева при сколь-либо серьёзной нагрузке.

[nixx]

В 14.10.2022 в 10:43, jffulcrum сказал:

А мониторинг здоровья самих железяк проблемных что показывает? У CCR1009 была вечная проблема с низкой надежностью карлсонов, пропеллер помирал или начинал еле крутиться - и начинался жесткий тротлинг от перегрева при сколь-либо серьёзной нагрузке.

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

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

[gard]

У вас просто шейпинг не "настолько точный", скорее всего абонентский трафик идет не туда... Ну.. как предположение.

Идет в дефолтное, последнее правило - где тот самый Мегабит.

Изменено 18 октября, 2022 пользователем gard

[nixx]

В 18.10.2022 в 20:09, gard сказал:

У вас просто шейпинг не "настолько точный", скорее всего абонентский трафик идет не туда... Ну.. как предположение.

Идет в дефолтное, последнее правило - где тот самый Мегабит.

ну то есть вы хотите сказать, что если забить мегабитное (мелкое по скорости) правило, то весь шейпер встанет раком?

 

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

Изменено 19 октября, 2022 пользователем nixx

[gard]

Да я не про то.. я про то, что абонентский трафик может каким-то образом попадать скажем в "последнюю" очередь, где указан этот мегабит.

Ну хотя, наверное это не ваш случай..

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

[Sergey_kha]

Какой размер default-small ?  по умолчанию 10 пакетов была похожая проблема с помогло сушественное увеличение до 1000 пакетов

а в очереди трафик вобше попадает? счетчики увеличиваются у проблемных пользователей?

Изменено 21 октября, 2022 пользователем Sergey_kha

[nixx]

В 21.10.2022 в 03:20, Sergey_kha сказал:

Какой размер default-small ?  по умолчанию 10 пакетов была похожая проблема с помогло сушественное увеличение до 1000 пакетов

а в очереди трафик вобше попадает? счетчики увеличиваются у проблемных пользователей?

да, была очередь по умолчанию, потом по совету какого-то спеца по микротикам поставили как раз 1000. вообще ничего не изменилось, те же тормоза.

при нормальной работе трафик в очереди попадает, счетчики увеличиваются.

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

[nixx]

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

 

1) все очереди сидели под одной родительской. в силу неумения микротика корректно балансировать по ядрам такую конфигурацию, наблюдались стремительные взлеты занятости процессора при достижении трафиком какого-то относительно небольшого значения

2) зверинец с мту, который вел к перепаковке пакетов и сказочным тормозам в совершенно неожиданных местах. ну то есть, к примеру, download у абонента 50, upload - 2. меняем мту на всех портах по пути к ядру (приводим к общему значению) - все нормализуется.

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

4) input-файерволл в 80% конфигураций отсутствовал вообще. также были включены все сервисы, mndp и прочее. думаю, понятно, что не лез в микротик только ленивый.

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

наверное было еще что-то, сейчас пока не вспоминается.

 

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

зато вылезли глюки с бдкомами, которые раньше были незаметны на фоне остальных )))

 

ps: еще на текущий момент очень интересует рабочий и малоресурсоемкий метод редиректа заблоченных абонентов на соцсайты и личный кабинет с помощью микротиков при условии, что закрывается инет абоненту выключением его очереди.

 

upd: во, вспомнилась еще одна пакость.

после вылизывания конфигов, приведения их к общему виду и т.д. и т.п. микротик стал переставать быть DNS )) т.е. он и до моих вмешательств, и после них работал в качестве DNS-форвардера на сервера яндекса, гугла, клаудфлара, абонентам выдавался адрес микротика в качестве DNS. ну и либо через день, либо через три, либо вообще через полдня после полного причесывания конфига и контрольного ребута от абонентов начинали сыпаться заявки о неработе интернета, которые после начала разбирательств оказывались отсутствием DNS-ответов от микротика. причина, опять-таки, непонятна... просто переставал, и всё. ребут помогал, но не более, чем на пару суток.

на третьем-четвертом "причесывании" я уже не заморачивался и сразу вписывал в DHCP выдачу яндексовских днсов, а сейчас поднял пару своих isc-bind и выдаю их абонентам.

вообще проблемы с DNS были и до меня, но так... очень эпизодически на трех-четырех узлах. после моих же действий они наступали быстро и гарантированно везде.

Изменено 21 марта, 2023 пользователем nixx

[Saab95]

Цитата

ps: еще на текущий момент очень интересует рабочий и малоресурсоемкий метод редиректа заблоченных абонентов на соцсайты и личный кабинет с помощью микротиков при условии, что закрывается инет абоненту выключением его очереди.

вебпрокси.

[fractal]

13 часов назад, nixx сказал:

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

Сделали несколько родительских? 

[nixx]

6 часов назад, fractal сказал:

Сделали несколько родительских? 

нет, убрал родителя вообще. все очереди теперь одного уровня.