igaryok

як вияснилось, проблема дійсно була в OLT, а точніше в версії прошивки. Ця проблема виникала при передачі великих запросів по SNMP. В останій версії прошивки для OLT цю проблему усунуто. Тому після оновлення прошивки на OLT запрацював нормально і snmpwalk і всі сигнали відображаються в білінгу

Якщо б була б проблема із якоюсь ONU то show epon optical-transceiver-diagnosis не працювала б, але вона нормально відпрацьовує я все ж думаю що проблема в налаштуванні snmp OLT ввожу на сервері snmpwalk -On -v2c -c public 192.168.1.29 .1.3.6.1.4.1.3320.101.10.5.1.5 відпрацювує на 160 ONU і Timeout одразу через 10 секунд знову запускаю snmpwalk і одразу отримую Timeout Якщо почекати пару хвилин і знову snmpwalk - знову можна отримати сигнал із 160 ONU і потім Timeout Напевно стоїть обмеження на кількість запросів за якийсь час на OLT

білінг звичайно ні до чого... і на OLT команда show epon optical-transceiver-diagnosis відпрацювує правильно і показує сигнал всіх 180 ONU. Можливо налаштування OLT на час віддачі запросу по SNMP і тому дані отрумуться частково

напрашивается вывод - может проблема с самим ОЛТ? можливо... зараз зробив з сервера snmpwalk запрос на рівень сигналу ONU з даного OLT, і запрос до кінця не відпрацювує - віддає рівень сигналу із 130 ONU а потім: Timeout: No Response from 192.168.1.29

Так ото ж. Працює для двох OLT. А от для одного не працює. Force query - маю на увазі кнопочку в біллінгу в модулі switchpoller

SNMPWALK_PATH="/usr/local/bin/snmpwalk -On -v2c" ;Time to store SNMP raw data cache in minutes SNMPCACHE_TIME=60 SNMPSET_PATH="/usr/local/bin/snmpset -On -v2c" SNMP_MODE=system SNMPWALK_BACKGROUND=0

Добрий день Підскажіть де шукати помилку. Ubilling 0.8.0 rev 5261 Перестали відображатися в довіднику понізатор сигнали від ONU, які розміщені на одній із трьох OLT(на двох інших все нормально) Якщо в консолі розробника виконати SELECT `id`,`ip`,`snmp`,`modelid` from `switches` WHERE `desc` LIKE '%OLT%' array ( 0 => array ( 'id' => '33', 'ip' => '192.168.1.14', 'snmp' => 'public', 'modelid' => '4', ), 1 => array ( 'id' => '34', 'ip' => '192.168.1.29', 'snmp' => 'public', 'modelid' => '4', ), 2 => array ( 'id' => '38', 'ip' => '192.168.1.47', 'snm

Дякую за поради. До речі, про існування зовнішнього NAS-су, я написав ще в першому пості

Під "масовим ресетом" я мав на увазі масове відключення всіх користувачів і повторне їх включення за дуже малий проміжок часу. В прикріпленому файлі - лог цих подій(з allconnect.log). allconnect.txt Схоже дійсно на те як сказав l1ght - втрачається звязок між білінгом і насом, я дійсно і раніше спостерігав при падінні каналу перших секунд 10-20 не маю доступу до сервера з насом. Що відбувалося з бд в той час не можу сказати, логування в mysql не було включено. А на рахунок, як побудована взаємодія з NAS, то як описано в рекомендціях до Ubilling так і зробив. Два сервера, на обох intel i350-t

За яких обставин (налаштувань) може відбуватися масовий ресет? NAS і Ubilling(0.7.0 rev. 4720) на окремих серверах. Користувачів 470. Сьогодні пару абонентів подзовинили і повідомили що у них пропав Інтернет. Перевіряю таблицях ipfw на NAS - IP прописане в таблицях 3 і 4, а от pipe для цього IP є тільки до таблиці 3 а до 4 нема. І так по кожному абоненту. В логах allconnect.log на NAS - масовий ресет користувачів з часу до двух ночі. При чому якраз на цих користувачах, що не прописалися pipe вискакували помилки: Warning: mysql_connect(): MySQL server has gone away in /etc/rscriptd/GetUpSpe

Добрий день. У модулі ПОНізатор за однією ONU можна прописати одного абонента. Але, якщо ONU 4-х портова, то наразі як варіант її можна закріпити за одним із абонентів. Чи можна врахувати в наступних оновленнях, щоб за ONU із 4 портами можна було прописати до 4 абонентів?