Emanon

ONU міняли. Поки помічена в межах одного комутатора. Все ж таки спробували трохи про діагностувати оптичну лінію. Виявили на місці зварювання просадки по рівням, на 4дб! Але просадки були швидкими і рандомними в часі. Переварили. І ситуація наче покращилась. Наразі моніторимо. До цього при виводі show interface gpon 0/3, помічались errors, bip8errors, discarded. Але було багато сумнівів. Можливо, слабкі роутери давали менші burst-и, корекція помилок якось виправляла ситуацію

Эта настройка сильно влияет ? Понятно, что лучше фильтровать бродкаст, но слышал мнение что она может даже помешать с теми же dhcp discovery. Да и zabbix не показывает какие то всплески по бродкасту Тут ещё надо учесть, что предварительно его настраивал не я, а другие люди. Сам только добавлял gpon-профили

Вот конфиг bdcom. Опять же, не сильно судите за возможно кривую настройку: Для справки, проблемная onu: GPON 0/3:9. Ее несколько изменённая по сравнению с другими конфигурация объясняется тем, что ранее уже пытались что то изменить для исправления проблемы. Building configuration... Current configuration: ! !version 10.3.0D build 94280 service timestamps log date service timestamps debug date logging buffered 100000 ! hostname OLT-gpon port-protected 1 ! ! ! ! ! ! no spanning-tree !

Приветствую форумчан. Есть проблема и суть ее такова: В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600. Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разг