Перейти до

Проблема со скоростью аплоуда у клиентов на BDCOM GP3600-08


mpolk

Рекомендованные сообщения

Наблюдаем проблему со скоростью аплоуда у клиентов, подключенных к ОЛТу BDCom GP3600-08. Данный ОЛТ у нас первый из устройств этой модели в хозяйстве, и вообще большого опыта в области GPON-а у нас пока нет. Не исключено, что проблема проявлялась уже давно, но обнаружена она была недавно. Суть проблемы: максимальная скорость аплоуда у клиентов ограничена величиной 25-37 Мбит/с. Не видно зависимости скорости аплоуда от уровня сигнала у конкретного клиента, но просматривается зависимость от порта ОЛТа, к которому подключен клиент. К примеру, на 3-м порту у всех клиентов макс. скорость аплоуда 25-28Мбит/с,на 4-м - 32-34 Мбит/с, на 5-м - 35-37 Мбит/с. Потерь пакетов у клиентов не наблюдается; проблем со скоростью даунлоуда - тоже (у всех около 94 Мбит/с). Какой-либо физический перегруз каналов исключен (трафик небольшой).

На стенде, с 2-мя ONU эта проблема не наблюдалась. Создается впечатление, что скорость аплоуда зависит от количества ОНУ, зарегистрированных на порту, т.е. ОЛТ выделяет каждой ОНУ фиксированную полосу пропускания, не пытаясь осуществлять DBA. Если проблема именно в этом (в чем я не уверен), то способов включить DBA на ОЛТе я не вижу. Я надеялся, что DBA включен автоматически, но, возможно, я ошибался.

 

Дополнительно, в процессе проведенных изысканий было обнаружено следующее. Возникло подозрение, что скорость аплоуда в порту определяется ОНУшкой с самым слабым сигналом (такое явление обсуждалось в прошлом на local.com.ua применительно к EPON-овскому оборудованию). Для проверки этой гипотезы я начал временно отключать ОНУ работающих клиентов, подключенных к тому же порту, что и тестовый ноутбук, и при этом перемерять скорость аплоуда. Сначала я отключал ОНУ с самым слабым сигналом. Потом стал отключать, наоборот, самые благополучные ОНУ. Оказалось, что по мере отключения параллельно работающих клиентов скорость аплоуда на тестовом оборудовании действительно растет. Однако уровень сигнала отключаемых ОНУ никак не влияет на результат.  Ускорение тестового аплоуда зависит, по-видимому, только от общего количества отключаемых ОНУ.

 

В целом, вырисовывается такая картина, что дело не в физике, не в уровнях сигнала и т.п., а в каких-то патологиях в распределении ОЛТом восходящей полосы пропускания между ОНУшками. Возможно, патологии обусловлены ошибками конфигурирования ОЛТа (делалось все, естественно, методом китайского научного тыка, как положено с БДКомом). Или, может быть, дырками в софте ОЛТа, или сочетанием того и другого.

 

Не сталкивался ли кто с такой проблемой и не знает ли методов лечения?

 

Данные ОЛТа:

Скрытый текст

Kaz42-GPON#sh ver
BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2019-10-22 21:27:32 by SYS, Image text-base: 0x80008000
ROM: System Bootstrap, Version 0.1.4, Serial num:00320000525
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"
hardware version:
(RISC) processor with 524288K bytes of memory, 32768K bytes of flash
Base ethernet MAC Address: 84:79:73:37:42:c8
snmp info:
  product_ID:342   system_ID:1.3.6.1.4.1.3320.1.342.0
Kaz42-GPON uptime is 4:04:10:46, The current time: 2019-11-18 14:9:13
 Reboot history information:
  No. 1: System is rebooted by command at 2019-11-13 13:14:31, uptime 0:00:27:59

 

ОНУшки используем родные: BDCom GP1501DR.

Kaz42-GPON.start

Відредаговано mpolk
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 68
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

И так, проблема, наконец, была решена (если это кому-нибудь еще интересно).   Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик

Вчера провели, наконец,  измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 0) Исходное состояние: еще в ночь

В плане стабильности у него все вроде бы в порядке.   Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в по

Конфиг и версия ПО находятся в студии с самого начала. Первый в приложении, а вторая под спойлером.

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, mpolk сказал:

Конфиг и версия ПО находятся в студии с самого начала. Первый в приложении, а вторая под спойлером.

 

А как так у вас получилось ? 

В файле Kaz42-GPON.star

!version 10.3.0C build 50870
boot system flash BD_GP3616_10.3.0C_50870.bin

А в sh ver

BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"

 

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, fet4 сказал:

 

А как так у вас получилось ? 

В файле Kaz42-GPON.star


!version 10.3.0C build 50870
boot system flash BD_GP3616_10.3.0C_50870.bin

А в sh ver


BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"

 

Это несложно. Конфиг был слит до перехода на новую прошивку. Никаких принципиальных отличий там нет.

Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, andruxovich сказал:

Была похожая проблема. Решилась откатом прошивки до BD_GP3616_10.3.0C_46550. На более новых работать нормально отказывается

А не поделитесь ли прошивкой? Буду признателен.

Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, andruxovich сказал:

Вот здесь лежат прошивки http://bdcom.mega.dp.ua/files/

Спасибо. Пошел пробовать. По результатам отпишусь.

Ссылка на сообщение
Поделиться на других сайтах

Полноценно испытать прошивку BD_GP3616_10.3.0C_46550 не удалось. С текущим конфигом ОНУшки подключиться не смогли, ОЛТ ругался на незнакомую команду "cmd-sequence 004 gpon onu loopback-detect protocol private". После удаления этой команды из профилей конфигурирования ОНУ слегка полегчало: ОНУшки подключились. Но клиенты подключиться уже не смогли. Трафик в клиентских ВЛАНах над ОЛТом полностью отсутствовал. От дальнейших экспериментов над живыми людьми я пока воздержался.

Попробую еще поэкспериментировать с прошивкой 46550 ночью, постепенно упрощая конфиг до такого состояния, что клиенты таки смогут подключиться. Хотя жить с такой прошивкой (без loopback-detect-а) сколько-нибудь долго нельзя, только на время эксперимента.

 

Либо придется искать другое решение.

Ссылка на сообщение
Поделиться на других сайтах

У меня трафик не хотел бежать, как я не упрощал конфиг. В итоге удалил все, и настроил с нуля. Теперь работает. А проблема начиналась с плохой скорости, которая падала по мере роста кол-ва ону на голове (неважно в каких pon портах). В итоге дошел до момента, когда новые ону не получали конфиг. Если отключить пару зареганых ранее ону - новые получали конфиг. А насчёт разницы версий в sh run и sh conf - таки да, после обновления, или отката в sh run отображается текущая версия,  в sh conf предыдущая. Если сделать write all - все становится одинаково. 

Ссылка на сообщение
Поделиться на других сайтах

Если проблема в с корости с ростом ОНУ - значит косяк в лайн/дба профилях, где бендвич указывается несколькими способами - жёстко, плавающе по максимальной полосе и ДР . Что то вроде sir/pir на епоне

Ну и ещё с сигналом может бида быть. Но тогда ошибки тикают.

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах

А что Вы хотите от общей среды?

Если просто и на пальцах, то http://www.gpon.com/how-gpon-works

Вот и делите эти 1.2Gbps на все подключенные абонентские терминалы.

Ссылка на сообщение
Поделиться на других сайтах

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, Dimkers сказал:

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

Так дело ж не в полосе, а в физике (L1). Вы точно про UPLOAD?

Відредаговано foreverok
Ссылка на сообщение
Поделиться на других сайтах

http://ngoptics.com.ua/materials/reference_information/osobennosti-nastroyki-profaylov-na-olt-zte/

У меня есть ветки с 110+ ОНУ. Жалоб на скорость, нерегистрацию ОНУ - нет. То, что не дает зарегать ОНУ - это таки похоже на жесткое нарезание профилей. Не забывайте, Гпон это вниз таки 2,5Гб

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, Dimkers сказал:

http://ngoptics.com.ua/materials/reference_information/osobennosti-nastroyki-profaylov-na-olt-zte/

У меня есть ветки с 110+ ОНУ. Жалоб на скорость, нерегистрацию ОНУ - нет. То, что не дает зарегать ОНУ - это таки похоже на жесткое нарезание профилей. Не забывайте, Гпон это вниз таки 2,5Гб

ТС таки жаловался на скорость UPLOAD. 

Ссылка на сообщение
Поделиться на других сайтах

Ааа, сорян.

Что то было и такое тут. В прошивках онух косяк был.

Кстате, а с шейпером все норм?

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
13 часов назад, Dimkers сказал:

Если проблема в с корости с ростом ОНУ - значит косяк в лайн/дба профилях, где бендвич указывается несколькими способами - жёстко, плавающе по максимальной полосе и ДР . Что то вроде sir/pir на епоне

Ну и ещё с сигналом может бида быть. Но тогда ошибки тикают.

Да я понимаю, что беда где-то в этой области: cir/pir/shaper/policer и т.п.. Так прямо сразу и написал. Вот только не понимаю пока, где конкретно. DBA-профайла в этом ОЛТе нет вообще (или я о нем не знаю). Это меня тоже сильно смущает.

С физикой значимых проблем нет: уровни сигнала приемлемые, потерь пакетов нет, скорость не рваная, а ровно (но неправильно) нарезанная.

 

12 часов назад, foreverok сказал:

А что Вы хотите от общей среды?

Если просто и на пальцах, то http://www.gpon.com/how-gpon-works

Вот и делите эти 1.2Gbps на все подключенные абонентские терминалы.

Я хочу, чтобы скорость делилась не между подключенными терминалами (в том числе спящими, ковыряющими в носе и размышляющими о жизни). А между терминалами, реально запросившими передачу данных, в пределах выделенных cir/pir/eir-ов. Такой способ разделения полосы называется Dynamic Badwidth Allocation (DBA)  и присутствует в стандарте GPON-а, во всех вменяемых реализациях EPON-а (за отсутствием там стандарта) и во всех вменяемых технологиях, использующих TDM (под разными названиями). PON без такой фичи мне точно не нужен.

 

12 часов назад, Dimkers сказал:

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

У меня на БДКОМе оно аналогично выглядит. Но то ли я неправильно пишу эти профайлы, то ли ОЛТ неправильно их понимает. У меня стоит 3-й тип трафика, и в нем 8Мбит гарантированных и 100М максимальных. С виду ничего криминального, должно быть хорошо. А на деле плохо.

 

12 часов назад, foreverok сказал:

Так дело ж не в полосе, а в физике (L1). Вы точно про UPLOAD?

Дело именно в полосе, а не в физике. Я точно про аплоуд. Загрузка PON-портов очень небольшая в обоих направлениях.

 

12 часов назад, Dimkers сказал:

Ааа, сорян.

Что то было и такое тут. В прошивках онух косяк был.

Кстате, а с шейпером все норм?

Думаю, что не в норме, судя по результатам (если вы про шейперы ОЛТа и/или ОНУ). Только я не знаю, как это поправить. Где начинаются настройки ОНУшек и заканчиваются настройки ОЛТа (т.е. кто именно нарезает скорость аплоуда) из конфига и документации тоже, кстати, не видно.

 

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

  • Like 1
Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, mpolk сказал:

(если вы про шейперы ОЛТа и/или ОНУ

не, я про НАСы\БРАСы.

 

2 часа назад, mpolk сказал:

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

Одна из первых ссылок гугла дала конфиг https://forum.nag.ru/index.php?/topic/148225-bdcom-gp3600-16-nastroyka-multikasta/

Крутите.

Ссылка на сообщение
Поделиться на других сайтах

Правьте сигналы и ставьте усиленные модули. Нам ток это помогло. Все настройки до фени. Если модули фоксгейты и на голову приходит меньше -25, нихрена вам не поможет, повторюсь ток сигналы и усиленные модули.

У нас осталась с этой башкой одна проблема: раз в несколько недель пропадают маки на одном из понов-помогает ток ребут

Ссылка на сообщение
Поделиться на других сайтах
В 19.11.2019 в 13:03, andruxovich сказал:

У меня трафик не хотел бежать, как я не упрощал конфиг. В итоге удалил все, и настроил с нуля. Теперь работает. А проблема начиналась с плохой скорости, которая падала по мере роста кол-ва ону на голове (неважно в каких pon портах). В итоге дошел до момента, когда новые ону не получали конфиг. Если отключить пару зареганых ранее ону - новые получали конфиг. А насчёт разницы версий в sh run и sh conf - таки да, после обновления, или отката в sh run отображается текущая версия,  в sh conf предыдущая. Если сделать write all - все становится одинаково. 

А можно уточнить: что значит удалить все? К примеру удаление файла config.db, в котором хранятся, насколько я понимаю закэшированные конфиги ОНУ-шек - это правильный способ? И не приведет ли это к неспособности ОЛТа загрузиться? Честно говоря, боязно экспериментировать на живую.

Ссылка на сообщение
Поделиться на других сайтах

Если боязно - тогда через вебморду reset к заводским настройкам. Но, можно также удалить startup-config и config.db , перезагрузить и все будет хорошо. 

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від neom
      Продам GPON ОЛТ - стоял в идеальной серверной
      PRAM+SCBE3+GTGO
       
      цена 2000$
    • Від ppv
      Після оновлення до 1.5.1 не відображаються сигнали на
      OLT BDCOM P3310B (Device version10.1.0B)

      та
      P3608-2TE (Firmware Version10.1.0E). 

      3310C та P3608B ніяких проблем немає, знімає все добре. 
      З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • Від LIKO
      Продам оптичний лінійний термінал (OLT) BDCOM P3600-16E-2AC , повна комплектація, можливий продаж з модулями BDCOM OLT-GSFP-20+++
      Ціна 85500 грн.
       





    • Від machadorafaael
      Hi, Could you share the firmware files for the C6xx models you have in your regions?
    • Від legenda vols
      Всем привет, заезженная тема но приходиться искать по всем уголкам интернета - А именно OID и как их использовать.
      Начнём. 
      для новичков.
      bash 
      set_olt_oids() {
          # Общие для EPON (BDCOM)
          if [[ "$1" =~ ^(P3310|P3310B|P3310C|P3608|P3608B|P3316|P3600-16E|P3608-2TE|P3616-2TE|IEP3310)$ ]]; then
              OID_GET_MAC="1.3.6.1.4.1.3320.101.10.4.1.1"
              OID_VENDOR_ONU="1.3.6.1.4.1.3320.101.10.1.1.1"
              OID_MODEL_ONU="1.3.6.1.4.1.3320.101.10.1.1.2"
              OID_TEMP_ONU="1.3.6.1.4.1.3320.101.10.5.1.2"
              OID_AUNT_ONU_STATUS="SNMPv2-SMI::enterprises.3320.101.10.1.1.26"
              OID_UPTIME_ONU="1.3.6.1.4.1.3320.101.10.1.1.80"
              OID_DIST="1.3.6.1.4.1.3320.101.10.1.1.27"
              OID_IF_MAC10="1.3.6.1.4.1.3320.101.11.1.1.3"
              OID_IFindexmac10="1.3.6.1.4.1.3320.101.11.1.1.1"
              LASTREG_DATE="1.3.6.1.4.1.3320.101.11.1.1.9"
              LASTDEREG_DATE="1.3.6.1.4.1.3320.101.11.1.1.10"
              LASTDEREG_REASON="1.3.6.1.4.1.3320.101.11.1.1.11" 
              OID_ONU_ETH="1.3.6.1.4.1.3320.101.12.1.1.8"
              OID_PORT_INDEX="1.3.6.1.4.1.3320.101.107.1.1" # oid возвращает все индексы ПОН портов, работает не везде
              OID_GEPORT_COUNT="1.3.6.1.4.1.3320.101.10.1.1.12"
              OID_FEPORT_COUNT="1.3.6.1.4.1.3320.101.10.1.1.14"
              OID_REBOOT_ONU="1.3.6.1.4.1.3320.101.10.1.1.29" # snmpset -v2c -c RW IP OID.onuIndex i 0 reboot
              OID_DEL_ONU="SNMPv2-SMI::enterprises.3320.101.11.1.1.2" #.$portID.$mac10" i 0 #mac decimal onu
          fi
          # Общие для GPON
          if [[ "$1" =~ ^(GP3600-08|GP3600-16B|GP3600-08B)$ ]]; then
              ETH_STATUS="1.3.6.1.2.1.2.2.1.8" # статус порта 1 портовая ону
              ETH_STATUS4="1.3.6.1.4.1.3320.10.4.1.1.4" # статус портов 4х портовая ону
              OID_VENDOR_ONU="1.3.6.1.4.1.3320.10.3.1.1.2"
              OID_ADMIN_STATUS="1.3.6.1.4.1.3320.10.4.1.1.3"
              OID_DOWN_REASON="1.3.6.1.4.1.3320.10.3.1.1.35"
              OID_DIST="1.3.6.1.4.1.3320.10.3.1.1.33"
              OID_MODEL_ONU="1.3.6.1.4.1.3320.10.3.1.1.9"
              OID_VENDOR_ONU="1.3.6.1.4.1.3320.10.3.1.1.2"
              OID_REBOOT_ONU="1.3.6.1.4.1.3320.10.3.2.1.4" #snmpset -v2c -c RW IP OID.onuIndex i 1 reboot
              
          fi
          # Уникальные параметры для моделей
          case "$1" in
              # EPON модели
              P3310 | P3310B)
                  OID_RX_ONU="1.3.6.1.4.1.3320.101.10.5.1.6"
                  OID_RX_OLT="1.3.6.1.4.1.3320.9.183.1.1.5"
                  OID_PORT_LIST="1.3.6.1.4.1.3320.101.107.1.1"
                  ;;
              IEP3310)
                  OID_RX_ONU="1.3.6.1.4.1.3320.101.10.5.1.5"
                  OID_RX_OLT="1.3.6.1.4.1.3320.9.183.1.1.5"
                  OID_TX_ONU="1.3.6.1.4.1.3320.101.10.5.1.6"
                  ;;
              P3608 | P3608B | P3310C | P3316 | P3600-16E | P3608-2TE | P3616-2TE)
                  OID_RX_ONU="1.3.6.1.4.1.3320.101.10.5.1.5"
                  OID_RX_OLT="1.3.6.1.4.1.3320.101.108.1.3"
                  OID_TX_ONU="1.3.6.1.4.1.3320.101.10.5.1.6"
                  OID_PORT_LIST="1.3.6.1.4.1.3320.101.107.1.1"
                  ;;
              # GPON модели
              GP3600-08 | GP3600-16B | GP3600-08B | P3600-08E)
                  OID_RX_ONU="1.3.6.1.4.1.3320.10.3.4.1.2"
                  OID_RX_OLT="1.3.6.1.4.1.3320.10.2.3.1.3"
                  OID_TX_ONU="1.3.6.1.4.1.3320.10.3.4.1.3"
                  OID_GET_MAC="1.3.6.1.4.1.3320.10.3.1.1.4"
                  ;;
              *)
                  echo -e "\e[1;91mНеизвестный режим OLT: $1\e[0m"
                  return 1
                  ;;
          esac
          return 0
      }
      что бы было понятно в дальнейшем что за переменные 
      snmp1="snmpwalk -v2c -c паблик стринг"
      snmp2="snmpwalk -v2c -Ouqv -c паблик стринг"
      snmp3="snmpget -v2c -c паблик стринг"
      snmp3q="snmpget -v2c -Ouqv -c паблик стринг"
      snmp4="snmpget -v2c -Ouqv -c приват стринг"
      snmp5="snmpset -v2c -c приват стринг"

      EPON GEPON
      1- OID_GET_MAC="1.3.6.1.4.1.3320.101.10.4.1.1" на бдкомах епон 
      = SNMPv2-SMI::enterprises.3320.101.10.4.1.1.96 = Hex-STRING: A0 94 6A 97 CC 50
      snmp_response=$($snmp3 "$IP" "$OID_GET_MAC.$1" 2>/dev/null | awk -F'Hex-STRING: ' '{print tolower($2)}' | tr -d ' ')
          onu_mac=$(echo "$snmp_response" | sed 's/\(..\)/\1:/g;s/:$//') #Переводим в человеческий вид
          mac10=$(echo "$snmp_response" | awk '{    # Переводим в mac10 дада способов есть миллиард.
              for (i=1; i<=length; i+=2) {
                  printf "%d", strtonum("0x" substr($0, i, 2))
                  if (i + 2 <= length) printf "."
              }
              print ""
          }')

      лучший способ сделать функцию для форматирования снмп запросов в зависимости от типов STRING / HEX-STRING / COUNTER32 и тд тп.

      ifID=$($snmp1 "$IP" "$OID_IF_MAC10" 2>/dev/null | awk -v mac="$mac10" '$0 ~ mac {split($1, arr, "."); print arr[length(arr)-6]; exit}') 


      2 - OID_VENDOR_ONU="1.3.6.1.4.1.3320.101.10.1.1.1"
      тут без лишних слов возвращает вендор онушек 
      SNMPv2-SMI::enterprises.3320.101.10.1.1.1.97 = STRING: "XPON"   если укажем параметр -Oqv  или -Ouqv получим просто "XPON" и надо будет лишь сделать | tr -d ' " '    что бы удалить лапки.

      3 - OID_MODEL_ONU="1.3.6.1.4.1.3320.101.10.1.1.2" аналогично вендорам, получаем модель.

      4- OID_TEMP_ONU="1.3.6.1.4.1.3320.101.10.5.1.2"  - температура ону делим на / 256
      SNMPv2-SMI::enterprises.3320.101.10.5.1.2.17 = INTEGER: 7027  
      temp_onu=$($snmp3q $IP 1.3.6.1.4.1.3320.101.10.5.1.2.$INDEX | awk '{printf "%.2f", $1/265}' 2>/dev/null)

      5 - OID_AUNT_ONU_STATUS="1.3.6.1.4.1.3320.101.10.1.1.26"
      SNMPv2-SMI::enterprises.3320.101.10.1.1.26.276 = INTEGER: 3

      onuAunt_type=$($snmp3q $IP "$OID_AUNT_ONU_STATUS.$INDEX" 2>/dev/null)
          case "$onuAunt_type" in
              0) onuAunt_type_txt="authenticated" ;;
              1) onuAunt_type_txt="registered" ;;
              2) onuAunt_type_txt="deregistered" ;;
              3) onuAunt_type_txt="auto_config" ;;
              4) onuAunt_type_txt="lost" ;;
              *) onuAunt_type_txt="unknown" ;;
          esac

      6 - OID_UPTIME_ONU="1.3.6.1.4.1.3320.101.10.1.1.80" uptime
      SNMPv2-SMI::enterprises.3320.101.10.1.1.80.207 = INTEGER: 290907
      timetick 
      | awk '{h=int($1/3600); m=int(($1%3600)/60); s=$1%60; printf "AliveTime: %dч %dмин %dсек\n", h, m, s}')${reset}"

      7 - OID_DIST="1.3.6.1.4.1.3320.101.10.1.1.27"
      SNMPv2-SMI::enterprises.3320.101.10.1.1.27.149 = INTEGER: 1600
      на епоне в метрах  на гпоне делим на 10

      8 - OID_IF_MAC10="1.3.6.1.4.1.3320.101.11.1.1.3"
      SNMPv2-SMI::enterprises.3320.101.11.1.1.3.14.60.21.18.8.130.175 = Hex-STRING: 3C 15 12 08 82 AF  
      SNMPv2-SMI::enterprises.3320.101.11.1.1.3      .14-PORTINDEX     60.21.18.8.130.175  - MAC10                = Hex-STRING: MAC HEX

      9- OID_IFindexmac10="1.3.6.1.4.1.3320.101.11.1.1.1"
      SNMPv2-SMI::enterprises.3320.101.11.1.1.1.125.60.21.18.6.227.186 = INTEGER: 125
      SNMPv2-SMI::enterprises.3320.101.11.1.1.1.125.60.21.18.6.247.136 = INTEGER: 125
      возвращает PORT INDEX и можно грепнуть по mac10 найти индекс и можно грепнуть через мак10

      10 - LASTREG_DATE="1.3.6.1.4.1.3320.101.11.1.1.9"
      дату отдаёт в хексе. надо декодировать это дело.
      вызов snmp + IP + oid + PORTINDEX + MAC10 
      date_hex=$($snmp1 $IP "$LASTREG_DATE.$IF_INDEX.$mac10" 2>/dev/null | awk -F': ' '{print $2}' | tr -d ' ')
      if [[ -n "$date_hex" ]]; then
              # Преобразуем дату из hex в числовое представление
              data=($(echo "$date_hex" | sed 's/../0x& /g'))
              local year=$((data[0] * 256 + data[1]))
              local month=${data[2]}
              local day=${data[3]}
              local hour=${data[4]}
              local minute=${data[5]}
              local second=${data[6]}


      local formatted_date=$(printf "%04d-%02d-%02d %02d:%02d:%02d" "$year" "$month" "$day" "$hour" "$minute" "$second")


      10 - LASTDEREG_DATE="1.3.6.1.4.1.3320.101.11.1.1.10"
      аналогично 9му оиду.

      11 - LASTDEREG_REASON="1.3.6.1.4.1.3320.101.11.1.1.11" 
      DEREG_STATUS=$($snmp3 $IP "$LASTDEREG_REASON.$IF_INDEX.$mac10" -Oqv 2>/dev/null)
          case "$DEREG_STATUS" in
              2) dereg_status_text="normal";;
              3) dereg_status_text="mpcp-down";;
              4) dereg_status_text="oam-down";;
              5) dereg_status_text="firmware-download";;
              6) dereg_status_text="illegal-mac";;
              7) dereg_status_text="llid-admin-down";;
              😎 dereg_status_text="wire-down";;
              9) dereg_status_text="power-off";;
              255) dereg_status_text="unknown";;
              0) dereg_status_text="Нет данных.";;
              *) dereg_status_text="not found";;
          esac

      есть прикол если онушка autoconfig статус 3 / authenticated статус 0
      там инвертируються 7 и 8  может и от моделей ону зависеть.... 
      7) dereg_status_text="llid-admin-down";;
      😎 dereg_status_text="wire-down";;
      это уже тестами )


      12  -  OID_ONU_ETH="1.3.6.1.4.1.3320.101.12.1.1.8" статус езернет ничего не обычного кроме того что может верно отдать данные с 2-3го раза )
      2 down 1 up 
      там же есть прикол с authenticated autoconfig инвертируется...
      local PORT_COUNT=$($snmp2 "$IP" "$OID_ONU_ETH.$INDEX" | wc -l)
      local ETH_STATUS=$($snmp2 "$IP" "$OID_ONU_ETH.$INDEX.$port" 2>/dev/null)
              [[ "$ETH_STATUS" =~ ^[0-9]+$ ]] || continue  # Проверяем, что ETH_STATUS - это число
              if [[ "$onuAunt_type" == "0" ]]; then
                  STATUS_COLOR=$( [[ "$ETH_STATUS" -eq 2 ]] && echo "UP" || echo "DOWN" )
              else
                  STATUS_COLOR=$( [[ "$ETH_STATUS" -eq 1 ]] && echo "UP" || echo "DOWN" )
              fi

      13 - OID_PORT_INDEX="1.3.6.1.4.1.3320.101.107.1.1" # oid возвращает все индексы ПОН портов, работает не везде.
      14 - OID_GEPORT_COUNT="1.3.6.1.4.1.3320.101.10.1.1.12"   гигабит езернет порты на онушках (кол-во)
      15 - OID_FEPORT_COUNT="1.3.6.1.4.1.3320.101.10.1.1.14"   ФастЕзернет 100мбит аналогично. 
      INTEGER 

      16 - OID_REBOOT_ONU="1.3.6.1.4.1.3320.101.10.1.1.29" # snmpset -v2c -c RW IP OID.onuIndex i 0                                  reboot REBOOT ONU epon snmp
      $snmp5 "$IP" "$OID_REBOOT_ONU.$INDEX" i 0 >/dev/null 2>&1

      17 - delete onu epon  удалить ону бдком снмп 
      OID_DEL_ONU="SNMPv2-SMI::enterprises.3320.101.11.1.1.2"
      $snmp5 "$IP" "$OID_DEL_ONU.$ifID.$mac10" i 0 > /dev/null 2>&1    oid.PORTINDEX.mac10 i 0 
      остальные есть выше там думаю всё понятно.

      SIGNAL LEVELS в зависимости от моделей плат и олтов расписаны 
      все везде одинаково 
      $snmp2 "$IP" "$OID_RX_OLT.$INDEX" 2>/dev/null | awk '{print $NF / 10}')   результат делим на 10.

      epon пакеты, ошибки по портам на онушке.
      broadcasts=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.16.$INDEX.$port" 2>/dev/null)
      multicasts=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.17.$INDEX.$port" 2>/dev/null)
      unicasts=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.18.$INDEX.$port" 2>/dev/null)
      pause=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.19.$INDEX.$port" 2>/dev/null)
      fcserrs=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.20.$INDEX.$port" 2>/dev/null )
      oversize=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.13.$INDEX.$port" 2>/dev/null)
      jabber=$($snmp4 "$IP" "1.3.6.1.4.1.3320.101.12.2.1.14.$INDEX.$port" 2>/dev/null)

      мне бы такое помогло.. а не искать на тонне форумов и сайтов и неделю тыкая snmpwalk и выясняя что и для чего. остального и в инете полно. 

×
×
  • Створити нове...