nixx

мне явно помогает задавать здесь вопросы - быстро ответы нахожу ) в общем, оказывается, что существует два американских вида резьб - US Coarse Thread и US Fine Thread с дюймовыми параметрами. сокращенно UNC / UNF. резьба, похожая на нашу M5 - это либо UNC 10#-24, либо UNF 10#-32 (4,83 мм) пойду заказывать, проверять. 10 винтиков - 230 рублей, блин... https://www.packerfastener.com/technical/threads/standard.html https://fullerfasteners.com/tech/thread-identification-chart-american-standard/ ps: если я ошибся в выводах - поправьте )

Есть рельсы для бесперебойников APC... Есть рельсы для серверов hp... Встречал рельсы для серверов Intel... ...в которых резьбы уже нарезаны/вварены, и для крепления их к стойке используются винтики с потайной шляпкой диаметром 5 или 6мм, но с нестандартным шагом резьбы (угол резьбы на глаз не отличается). Собственно, вопрос - как правильно эта резьба называется по-русски/по-английски? дюймовая? еще какая-то? Хочу попробовать заказать на али, но не знаю, что искать.

таки скачать MIKROTIK-MIB и посмотреть там сложнее, чем здесь написать? )) я скачал, посмотрел - не нашел. ну и вообще, насколько я вижу из многолетнего "прогресса" в развитии private снмп-ветки у микротиков, snmp - это устаревшая технология ) имхо, можно ориентироваться на инкремент в счетчиках дропов пакетов в очереди.

имхо, даже больше. у меня цдатовская онушка на бдком-олт "думала" после посыла в нее прошивки минут 10+, потом ушла в ребут и вернулась с новой версией. никаких "коммит" не писал. просто update onu image и ждал.

родителей уберите. маркировку уберите. порадуетесь 5-10% на всех ядрах. шейпить пачку очередей с 1-2 родителями по достижении некой определенной нагрузки микротик не может, это факт, в который я сам уткнулся полгода назад. как вариант - сделайте 36 родителей, если вам ваша конфигурация позволяет. upd: и никакого намека на включенный маскарадинг (хоть даже для служебных целей, не для абонентов) в файерволле быть не должно. очень поднимает нагрузку.

вообще ccr1009 (или 1100ahx4) ожидается, но это если hex до 40-50% по обоим ядрам доползет. пока ему очень далеко ) график процессоров - это сумма загрузки ядер. т.е. максимум там 400.

ну да. а что? вопрос в объеме трафика, от которого напрямую зависит нагрузка, а не в количестве каналов. сейчас у меня 100 с копейками мегабит по сотне каналов бегает, как оказалось. про 150 я соврал, тут все 250 будет... )

за это уточнение огромное спасибо. с учетом того, что у меня там ожидается эдак под 150+ еоипов и вланов - перспективы роста нагрузки великолепны )) значит, остаюсь на старом варианте.

дык "софт-интерфейсы" я пихаю в мосты в обоих вариантах, т.е. это не причина увеличения нагрузки, они в обоих случаях есть и нет никаких включенных оффлоадов ни на чем. в обоих случаях по profile проц кушает процесс networking - в случае первого варианта слабее, второго - сильнее. всё остальное близко к нулям. но куда полезут широковещательные пакеты, если в бридже четко сказано "вот этот влан с вот этим еоипом"? ну в общем у меня была надежда, что есть какое-то волшебство, про которое я не в курсе ) если такое увеличение закономерно, то пойду грустить. ps: routeros 6.48.7, конфиг на ресетнутом "в ноль", только нужное.

есть типовая задача - прилетающие с разных офисов eoip-каналы надо запихивать во вланы, и дальше уже производить с ними всякий роутинг/нат и т.д. ("дальше" к данному вопросу не относится и делается не на микротиках). знаю два варианта реализации: 1) создаем влан-интерфейс на ether-порту микротика и бриджуем его персональным бриджом с еоип-каналом (число бриджей равно числу вланов/каналов) 2) создаем бридж с включенной влан-фильтрацией, вешаем на него все вланы как вланы (Bridge -> VLANs), а не как интерфейсы, и в нем же бриджуем соответствующие вланы с еоип-каналами второй вариант более нравится по причине его внешней простоты и легкости по сравнению с первым (тупо меньше на экране всякого болтается )) при этом у второго варианта вижу минус - нельзя бриджевать влан с вланом (ну т.е. технически невозможно соединить один с другим) но таки переделал конфиг под второй вариант (ни трафика, ни вообще чего бы то ни было не изменилось) и получил... удвоение нагрузки на процы. было 20-30 процентов, сейчас 50-55. равномерность нагрузки ядер примерно та же, что и была. вопрос - в целях оптимальной производительности я обречен на болтающиеся в конфиге нцать бриджей по числу каналов/вланов, или же я что-то не так делаю? ps: микротик hEX.

12й дебиан с ядром 6.1 утверждает, что с 6м ядром собирается: https://packages.debian.org/bookworm/iptables-netflow-dkms сам ставить не пробовал, да и дебиановцы свой bookworm в продакшен пока не рекомендуют.

добавлю информации, что, возможно косяк и не в BDCom'е (не совсем в BDCom'е )) у меня тут параллельно была трехдневная эпопея с RX CRC-ошибками на SFPplus-модуле Modultech, воткнутом в BDCom, а с другой стороны был свитч Dell с таким же Modultech'ом. пока до Dell'а SFP модуль был воткнут в микротик - все было хорошо. переткнул в Dell - и на стороне BDCom'а повалили CRC. я и так, и эдак, уже чуть ли не до дезинфицирования пигтейлов не дошел. потому как меняю патч-корд, меняю Modultech на Modultech - ошибки начинают валить с другой интенсивностью... но ни разу чтобы ноль... поставил в Dell Gateray модуль - такая же фигня, ошибки на BDCom'е. взял взаймы SNR модуль, поставил - все зашибись, ошибок ноль. и до сих пор ноль, почти неделя прошла. ну то есть предположительно в Modultech'е и Gateray что-то не так (не нравится Dell'у) с прошивкой/железной частью, что всунутые в Dell они умудряются посылать битые пакеты в BDCom... хотя звучит как-то бредово, на мой взгляд. но это единственное объяснение, которое я могу придумать.

хм... это с OLT всё делается. #show epon interface epON 0/2:6 onu port 1 state Hardware state is Link-Up Speed is 100Mbps Duplex is Full-Duplex #epon update onu image filename.bin interface EPON 0/2:6 я почему спрашиваю - занимаюсь сейчас сетью, в которой, сцуко, каждой онушке при заведении абонента вручную выдают адрес. и ничего внятно ответить не могут, зачем это им надо, кроме как "биллинг его пингует". и меня интересуют "уникальные" случаи, когда без этого айпишника ну вот вообще никак.

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

отправил в личку.

странное нашлось при чтении логов OLT указанной модели, которые имеют оптические линки в гигабитных или десяточных портах (не-PON), случайным образом - могут раз в полсуток, могут раз в час - пишут в лог такое Jul 6 05:33:25 SFP DDM Alarm Released for Bias Current low on g0/1 Jul 6 05:33:25 SFP DDM Alarm Released for Suppy Voltage low on g0/1 Jul 6 05:33:25 SFP DDM Alarm Released for Rx Power low on g0/1 Jul 6 05:33:25 SFP DDM Alarm Released for Tx Power low on g0/1 Jul 6 05:33:25 SFP DDM Warning Released for Bias Current low on g0/1 Jul 6 05:33:25 SFP DDM Warning Released for Suppy Voltage low on g0/1 Jul 6 05:33:25 SFP DDM Warning Released for Rx Power low on g0/1 Jul 6 05:33:25 SFP DDM Warning Released for Tx Power low on g0/1 Jul 6 05:33:20 SFP DDM Alarm Occured for Bias Current low on g0/1 Jul 6 05:33:20 SFP DDM Alarm Occured for Suppy Voltage low on g0/1 Jul 6 05:33:20 SFP DDM Alarm Occured for Rx Power low on g0/1 Jul 6 05:33:20 SFP DDM Alarm Occured for Tx Power low on g0/1 Jul 6 05:33:20 SFP DDM Warning Occured for Bias Current low on g0/1 Jul 6 05:33:20 SFP DDM Warning Occured for Suppy Voltage low on g0/1 Jul 6 05:33:20 SFP DDM Warning Occured for Rx Power low on g0/1 Jul 6 05:33:20 SFP DDM Warning Occured for Tx Power low on g0/1 ну то есть всем своим видом показывают, что у них попытался упасть оптический линк, а потом успешно "починился" за 5 секунд но при этом на другой стороне линка ничего не падает и не ругается SFP почти разные - гигабитные Gateray и Modultech, десяточные Modultech. есть в работе OLT BDCom других моделей - там подобного не встречается с такими же модулями. баг в прошивке?

а версия nfdump та же? еще пара идей: 1) вы пишете, что выключили ufw... а iptables у вас пропускает входящие пакеты? ufw это ж просто надстройка над iptables. 2) для гарантии, что "точно все в порядке" я бы сдампил несколько летящих пакетов и декодировал бы их для убедиться - реально там внутри нетфлоу v5, или что-то потустороннее? ) 3) ну и ss -aun - слушает ли вообще nfcapd на нужном интерфейсе? не висит ли на порту 2055 нужного интерфейса кто-то еще? может, сам биллинг, судя по prompt'у?

все выглядит красиво, кроме вот этого src 0.0.0.0. я не уверен, что nfcapd нормально воспринимает такое. у вас уже где-то работало подобное?

файлы будут появляться по-любому, т.к. сам nfcapd их по умолчанию ротейтит каждые 5 минут то есть вы tcpdump'ом смотрели и видели, что летят в порт, на котором слушает nfcapd, пакеты? nfcapd не слишком древний? может вы в него v10 льете, а он у вас только v9 умеет?

понял, спасибо. вы меня утвердили во мнении, что правильным выбором будет Dude 3.6 на винде сервисом ) я не сторонник регулярных оживляющих пинков, которые надо делать ручками.

взял в руки модель S5320, пошел в гугл и... сайт хуавея об этой модели вообще практически ничего не знает. что это вообще за зверь? ) оно в глубоком EoL'е? или это не совсем хуавей, и искать надо где-то еще? (типа как h3c) гуглится только что-то типа "https://support.huawei.com/enterprise/en/switches/s5300-pid-16563 ", где только "пишите письма", и всё в общем, два вопроса присутствующим: 1) где можно найти официальную поддержку на это железо? (интересует с целью скачивания документации да поглядеть, какие версии прошивок актуальны) 2) где взять последнюю прошивку? у меня модель S5320-36C-EI-28S-AC, прошивка V200R011C10SPC600.

стоит Dude на RouterOS CHR. сначала было что-то вроде 6.44, сейчас почти последняя 6.48.6. больше там ничего не крутится, в той роутероси. кидаю в каталог Dude кириллические ttf-шрифты (разные - пробовал и Arial, и DejaVu, и Consolas с мыслями, что "вдруг ему конкретный шрифт не нравится", сейчас коллега записал DroidSans) - они через некоторое время пропадают. просто файлы исчезают, и всё. где-то нагуглил (на этапе первых разборок), что файлы для Dude более кошерно копировать через ftp - типа у людей тоже были аналогичные проблемы (что отчасти вдохновило - не одни мы с полтергейстом). ну ок, копировал черз ftp. похрену - пропадают. время исчезновения разное. могут через пару суток пропасть, могут и две недели жить нормально. коллега утверждает, что с CHR ничего не делается, только бэкапится оно регулярно (каким способом - мне неведомо). скажите, у кого-то используется на картах кириллица или еще какие-то доп файлы на dude+chr, нет ли подобных глюков?

Скажите, а существует ли где-нибудь в открытом доступе парсилка config.db + ifindex-config с целью получения из них текстовых конфигов ONU? Или, может быть, кто-то может дать описание ifindex-config, чтобы не разгадывать, в каком байте у него что? config.db вроде и так более-менее понятен. Ну и вообще правильно ли я понимаю, что в config.db лежат конфиги онушек, а в ifindex-config - номера онушек в сопоставлении с номерами PON-портов?

ну в общем ой. конфиг полностью идентичен паре десятков других ccr1009, за исключением диапазонов айпишников. эта самая пара десятков уже полгода работает и не бурчит. а 2004й сегодня выдал такое, как на скриншотах. ps: а еще у них (2004 + ros7.9) есть явный косметический глюк с винбоксом 3.38, при котором большие списки (вланов, очередей) недогружаются при первом открытии окна с ними. закрываешь - открываешь снова - уже всё целиком.

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