Александр Л.

Лучше не маршрутизировать домены с широким ветвлением типа googlevideo.com тогда проблема будет меньше проявляться.

Помучил нейронку. Вердикт: большой FQDN-list + длительная работа + большое число DNS-событий + множество меняющихся A/AAAA + периодические пересборки динамических OGDN sets. И когда внутреннее состояние достигает какого-то размера/состояния, Dns::Route::ResolveQueue начинает жрать CPU.

Сократил количество доменов. Загрузка CPU упала. Будем наблюдать.

Когда использовалась маршрутизация по IPV4 он без проблем тянул и в несколько раз больше. Кстати на домашнем KN-1713 (с таким же CPU) я такого не наблюдаю, хотя у меня там гораздо больше доменов и CIDR.

450 доменов и 139 CIDR с покрытием около 1 млн. адресов. Tld не используется. ЗЫ прикрепляю скрытые сообщения, но они исчезают. Так и должно быть?

Здравствуйте. На Keenetic Start KN-1112, KeeneticOS 5.01.C.4.0-1, периодически возникает постоянная загрузка CPU 90–100% при практически отсутствующем пользовательском трафике. По диагностике: show system cpustat: busy avg ~98% user avg ~86% system avg ~11% irq/sirq ~0% iowait 0% show processes показывает, что основную нагрузку создаёт процесс ndm: ndm cpu avg ~87% cur ~93% max ~98% При этом ndnproxy, stubby, WireGuard и другие процессы практически не потребляют CPU. В show threads основной потребитель: DNS route IPset sync queue cpu: min 34% max 95% avg 53–72% cur 42–44% Стек: Netfilter::IpSet::Net6::AddItem(...) libndmIp6Object() Dns::Route::ResolveQueue::Group_::UpdateSet6_() Dns::Route::ResolveQueue::Group_::OnCacheSync_() Dns::InterfaceSpecific::ClearServiceData(...) То есть нагрузка возникает при синхронизации IPv6 ipset для DNS/FQDN routing. В конфигурации используются object-group с FQDN/CIDR и правила dns-proxy route для маршрутизации через PPPoE и WireGuard. Важный момент: после выполнения no dns-proxy route CPU сразу падает примерно до 5–10%, а поток DNS route IPset sync queue исчезает. При этом правила маршрутизации остаются отображаться в GUI. Через некоторое время проблема воспроизводится снова: поток DNS route IPset sync queue появляется и снова начинает потреблять 40–95% CPU. IPv6 у провайдера фактически не используется. Просьба проверить, не является ли это известной проблемой KeeneticOS 5.01.C.4.0-1 в механизме DNS/FQDN routing / синхронизации IPv6 ipset (Dns::Route::ResolveQueue::Group_::UpdateSet6_). Готов предоставить show system, show system cpustat, show processes, show threads, конфигурацию и лог. Такая проблема воспроизводится на множестве аналогичных устройств.

Не забыли выложить?

Судя по всему,проблеме подвержены определенные модели. На KN-1713, KN-1112, KN-4010 проблема не наблюдается.

Сколько ждать?

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

Количество устройств в мобильном приложении постоянно растёт, и каждый раз пролистывать весь список для добавления нового устройства несколько напрягает. В связи с этим предлагаю разместить кнопку "Добавить устройство" ("Add Netcraze Device") где-нибудь наверху списка.

Да

Нет. Если это важно, настройка производится со смартфтона в режиме автоматического вызова конфигуратора через настройки WiFI. Да, и кстати, проблема появилась с релизом 5.0.4. При обновлении до 4.3.6 пароль совершенно точно не сбрасывался.

Нет

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