prolan

У нас есть собственная система, разрабатываемая уже много лет. Функционал похож на UserSide - интеграция с биллингом (просмотр информации о клиентах, пополнение баланса, добавление новых клиентов), учет оборудования, заявок, звонков (интеграция с Asterisk). Работает с PON, Ethernet, радио. Если, у кого-то есть интерес в альтернативе UserSide - можно пообщать в личке на предмет необходимого функционала и возможности перехода или нового запуска. Потребуется время на доработки\переделки, но думаю, все решаемо.

Скорей всего STP. Как вариант - сделать дамп трафика и посмотреть, что именно за пакеты прилетают от циски

Спасибо. А хоть можно как-то получить информацию о профиле, привязанном к ONU? Например его имя

Подскажите OID для GP3600-08B, как получить информацию о вланах на портах ONU. Я так понимаю, нужно как-то получить какой профиль привязан к ONU, а потом выяснить какие вланы как настроены в профиле.

Навешивайте второй тэг на OLT.

Именно так и указывается. address=gateway, network=ip_клиента. Работает и без proxy-arp (но proxy-arp нужен для связи клиентов внутри одной сети), шлюз отдельно нигде не навешивается. unnumbered на микротиках весьма кривой получается. И любое включение proxy-arp может привести к зависанию миркотика и его ребуту через watchdog.

У вас конкретная ошибка этот IP висит на том сервере, где пытаетесь поднять коллектор? Скорей всего нет. Меняйте IP на IP коллектора

Никакого ключа нет. Коллектор слушает порт. Сенсор шлет на этот порт данные. Соответственно на коллекторе надо указать интерфейс, который он будет слушать (ip:port). На сенсоре указать интерфейс, который слушает коллектор, и все.

ipt_netflow - сенсор. flow-capture - коллектор. Никаких проблем держать их на разных машинах нет.

Для истории - в итоге проблема была обнаружена, на OLT умудрились сварить два интерфейса между собой (за кучей делителей). ONU VSOL оказались более чувствительными к проблемам. Как диагностировать подобное поведение - не понятно.

Зачем же так категорично. system dot1q-tunnel transit и искать следующую причину продажи)

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x_chapter_0100.html

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

Добрый день. Имеются жалобы клиентов с одной из OLT на периодическое пропадание связи. По логам была обнаружена только одна ситуация, которая не очень совпадает со списком обратившихся клиентов: В течении 1-2 секунд более 30 ONU отвалилось с OAM Status Linkfault. Анализ показал, что все отваливающиеся ONU - VSOL D401. При этом, на других OLT с такими же ONU проблем не наблюдается. Но и предположительно, данная проблема отражается и на других ONU, но в логи это не попадает (пока не удалось подтвердить или опровергнуть данный факт). Далее данные ONU переходят в OAM STATUS Operational, который иногда меняется на Linkfault. Пример одной из ONU: На OLT стоит последняя прошивка Прошу подсказать, в какую сторону стоит смотреть в данном случае (учитывая что проблема практически на всех интерфейсах).

Нет веба. С командами проблемы нет - проблема именно что после перезагрузки onu она не применяет ранее прмененную настройку на порту