Перейти до

UA.PON v6.0


wladd

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

как бы 7у.е это 150грн на 10 подключках 1500грн экономии.... поключили 20 абонов и заработали + до зп 3к грн

а свистопляски - поначалу и с бдкомом было тоже немало

 

Полностью согласен. Сейчас время не спокойное и каждая копейка на счету. Так что немного подождите и мы разберёмся с Форой.

На текущий момент китайцы прислали новую прошивку, которая решает проблему Opt 82. Тестирую...

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

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

мне по фиг, как оно называеться, главное настроить чтобы wi-fi отдавал!!!!

я конечно понимаю, что у айсилайн немного "подгорает" от цены пикотела, но зачем же так активно это показывать?

Я наверное странный - но не шьем ни ONU, ни OLT. Работает с заводским софтом пару лет, никто туда и не лазит лишний раз.

Posted Images

Прошивку проверил. Всё пофикшгено. Опция добавляется. Remote ID и Circuit ID нужную информацию показываю. К сожалению, данная прошивка не является даже бета релизом, а сделана, как говорится, на коленках, поэтому в массы пока не пойдёт - я её у себя придержу. Как торлько появится нормальная версия прошивки, выложу её на наш дроп и отпишусь

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

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

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

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

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

 

 

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226!

Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.

попадался уже

ставил всегда раньше тариф 30 мбит как 

epon sla upstream pir 30760 cir 30760
epon sla downstream pir 30760 cir 30760
 
после 31-ой ону на ветке начали отваливаться ону с перерегистрацией
теперь описываю так
epon sla upstream pir 30760 cir 10240
 epon sla downstream pir 30760 cir 10240
 
не давать зарегистрироваться ону - странный механизм обработки ошибки

 

А вот это очень инетерсно!

Получается что ОНУ можето отваливаться в перерегистрацию в случае превышения CIR

Это требует проверки!!!

 

- у нас на стендах ни одного отвала за сутки. Может эти магические пере-регистрации связаны именно с превышением полосы?

 

Screep - расскажите, а у вас какие полосы CIR назначены на каждую ОНУ и сколько их в дереве?

 

может быть я не правильно выразился

звонит клиент и жалуется что нет интернетов

на ону пон порт мигает зеленым (онушни тогда еще были 1004В) - значит идет регистрация

смотрю логи, а оно его реконектит каждую секунду

ону цепляется, доходит до применения sla, вылетает с ошибкой и дисконектится... и так по кругу

начал рыть логи - оказывается такое было уже накануне несколько раз, но никто не жаловался

выходит проблема вылазила только когда в дереве собирались все ону в онлайне.

Відредаговано Den_LocalNet
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

представлений о мире должны найти причну эпизода и воспроизвести ее.

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

если внимательно прочесть переписку - обсуждение того что тут было

унас есть два прецедента

 

Водном случае, человек наблдал отвал онушки после (но не значит вследствие)

того как наблдал не выдачу ДДМ.

 

параметры CIR/PIR - не проверены

 

В другом случае, человек наблдал не отдачу ДДМ, но отвал не наблюдал.

параметры CIR/PIR проверены

epon onu-config-template t2318
 cmd-sequence 1 epon sla upstream pir 1000000 cir 512
 cmd-sequence 2 epon sla downstream pir 1000000 cir 512

Всего около 35 ОНУ на ветке.

Мы собрали два стенда

 

КНР -  более 40 ОНУ NA-1001B  -нет отвалов ( да и ДДМ показывает больше суток)

Тута - 30*1501С + 10*NA-1001 + 2*NA-1001B  -не отвалов да и ДДМ показывает исправно

 

Версия:

Эпизод отваливающеся ОНУ может быть связан с превышемем CIR (напремер)

 

 

Тов Screep - пришлите ваши даные CIR/PIR и количество ОНУ.

 

Это конечно только версия, но мы так и ли иначе из гностических

представлений о мире должны найти причну эпизода и воспроизвести ее.

 

На тій лінії, було 9 ону зареєстровано CIR/PIR 100000/15000 так десята викидала такі фортеля, правда ону бдком аніак та 1 шт фора.

 

На іншій голові все так само тільки онушок було 17 шт з такими ж параметрами CIR/PIR так все працює нормально 

 

Зробив там де спостерігався глюк CIR/PIR 100000/10000, ніби зареєструвалась онушка  нормально, буду спостерігати. Але є декілька гілок де64 онушки, мішанка бдком, аніак, фіком, тплінк,  там  CIR/PIR 100000/15000 і всі реєструються, аптайм порядку місяця у всіх де живлення не вимикали. Тому питання - то фора така "фортова"?

 

PS.

ДДМ не віддається (замічено) тоді коли sh ep ac видає

 

a0c6.ec00.fc94 auto_configured linkfault

або

a0c6.ec00.fc98 authenticated   notready

тоді з ону нічого не віддається, хоча трафік якийсь через ню біжить, але швидкість не піднімається більше 1-10мбіт\с і можливі втрати до 10%-15% потім вона рандомно починає перереєстровуватись поки не перезавантажити по живленню.

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

Я пока не буду делать никаких выводов, но наш стенд из 64 ONU стоит уже 2 дня. никаких дерегистраций не происходит. Я выключал DBA совсем, ставил Cycle-time на 25000 и 50000, ставил динамический Cycle-time - всё работает.

 

Правда было замечено что при фиксированном Cycle-time 25000 TQ скорость от ОНУ в сторону ОЛТа не превышает 460 мбит/с. При установке динамического времени цикла скорость подпрыгнула до вполне нормальных 780 мбит/с.

 

Так или иначе, я дерегистрировал Форы и заново регистрировал, сбрасывал конфиг ЕПОН порта, чтобы все ОНУ одновременно зарегались. При этом регистрация 64 ОНУ проходит секунд за 30, при том что пластиковые, что металлические ФОРЫ регистрируются не последними, а мелькают среди BDCOM-ов. Это говорит, что с MPCP у них никаких проблем не наблюдается. На ночь поставили IPERF между ПК, подключённого к пластиковой ФОРЕ, и ПК, подключённого к ГЕ порту ОЛТа. В результате 10 часового теста в режиме полного дуплекса ОНУ не отвалилась и выдала вполне симметричную скорость 651/609 мбит/с

 

Мне остаётся только продолжать тест и попробовать ещё больше нагрузить PON чип. Кроме того я ожидаю поступления на наш склад партии пластиковых ФОР - тогда смогу поставить больше ФОР в ветку, убрав часть BDCOM-ов.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

1. about the de-regist bug, our side didn't repeated yeat. it running > 30 hours, still stable.
it is still hard to tell why the de-regist problem appears, until it repeated.

may be the optical modual problem, which means it is the hardware problem of a specific, standalone device.

 

2. about the opt82, it should be OK, tested in all cases, e.g: tag/untag mode, all works. and we're ready to release you with new firmware.

 

3. What we can report to community now time?

 

1) opt82 problem is solved. 2) we're trying to re-display the bug problem, but no luck. > 30 hours elapsed, still stable,

I  didn't meant our onus of no any statability problems; however as more test time elapsed, higher probability of problems

of standalone/few devices, or even mightbe the OLT optical moduals.

 

if we still couldn't repeat the bug, i guess we need more information of this problem. e.g: in case of it appears, what the

optical power it is?what the probability of this bug? is there any special usage of that device?

did  all devices appended under the same pon port rised the bug? or even could you please recycle the problem device,

and open up the box, so that we can check the circuite board....

 

3. about the ACL, might take more RD resource, the deadline mightbe delay, will be 2-10.

 

Попытаемся сегодня по максимуму нагрузить дерево.

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

Спасибо вам большое. Классная книга. Я заказал себе такую, на вашем сайте. Буду ждать, когда приедет. Я в PONE  новенький. Много чего не понимаю. Хочу спроектировать GPON, но пока не понимаю топологию сети и как строят такие сети.

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

В результате 86000 секунд прогона IPERF-ом в режиме FULL-DUPLEX TCP трафика через 2 ONU FORA NA-1001B (2 ПК подключёны к 2 Форам, 2 других - к GE портам ОЛТа), обе ОНУшки стабильно отработали. Суммарная скорость 2 потоков, пропущенных через ОЛТ, - 730/670 mbps. У меня закончились идеи, как можно нагнуть ФОРу и заставить её дерегистрироваться. Разве что дождаться поступления новой партии ФОР и включить в дерево их побольше.

 

Мы так и не собрали статистику. Продано около 1000 ОНУ. Пока мы услышали о проблеме от 2-3 клиентов - это около 10-30 ОНУ. Где все остальные :) ? Неужели ещё не ставили форы "в бой"? 

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

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358
Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000
Ссылка на сообщение
Поделиться на других сайтах

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

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

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

А разве вторая конструкция это не полисер тоже?

Я думал что единственная разница в том, что первая конструкция режет скорость на UNI портах, а вторая на EPON порту ОНУ.

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

 

 

В бой с колес ушло уже 6 штук. Разные ветки, забиты по разному. От 20-ти до 60-ти зарегистрированных ону на пон-порт.

BDCOM P3310B Software, Version 10.1.0B Build 16358

Клиенты только BDCOM (от 1004В до 1501С1). Три дня - полет нормальный.

Вылезла единственная мелкая проблема..

При:

  epon onu port 1 ctc rate-limit 55000 ingress
  epon onu port 1 ctc rate-limit 55000 egress

скорость не режется.

 

Пришлось поправить скрипты в биллинге на:

 epon sla upstream pir 55000 cir 15000
 epon sla downstream pir 55000 cir 15000

 

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.

 

Ну почему же, если сделать один единственный тариф, допустим 50М за ххх грн., то проще будет обрезать скорость на каждой ОНУ, без включения шейпера. А без шейпера и ресурсов оборудования надо поменьше. Пока я не слышал, что б так делали, ну а дальше посмотрим.

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

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

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

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

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

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

Шейпер же пытается такие пакеты поставить в очередь и затормозить, т.е. таким образом заставить отправителя медленнее отправлять данные. Ну и уже "непослушных" дропает.

 

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

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

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.

т.е. как я и говорил:

1. Шейпера на ОНУ нет. Только полисинг.

2. epon onu port 1 ctc rate-limit позволяет резать скорость на UNI портах ОНУ (если у вас 4-х портовая ОНУ - вы сможете резать скорость на каждом порту отдельно, без общего ограничения на EPON порту)

3. epon sla downstream/upstream режет скорость на EPON порту ОНУ (вне зависимости от кол-ва UNI портов и ограничений на них).

    т.е. если применить

    epon sla downstream pir 55000 cir 15000

    и

    epon onu port 1 ctc rate-limit 55000 ingress

    epon onu port 2 ctc rate-limit 55000 ingress

    epon onu port 3 ctc rate-limit 55000 ingress

    epon onu port 4 ctc rate-limit 55000 ingress

 

    то суммарно все четыре порта ОНУ не смогут прокачать больше 55Мбит/с

 

P.S. Возможно попутал ingress/egress ... Но не суть важно.

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

Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0.

Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).

Спасибо, будем пробовать.

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

 

Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте).

Нет.

Полисинг тупо дропает пакеты, которые не влазят в rate-limit.

Шейпер же пытается такие пакеты поставить в очередь и затормозить, т.е. таким образом заставить отправителя медленнее отправлять данные. Ну и уже "непослушных" дропает.

 

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

 

Можно сказать проще - полисер, это шейпер с буфером нулевого размера. Больше никакой разницы нет.

Ну а TCP скорость потока регулирует автоматом в любом случае, с ростом числа дропнутых(и перезапрошенных) пакетов.

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від 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 и выясняя что и для чего. остального и в инете полно. 
    • Від Amigo
      Продам GEPON ОЛТи BDCOM
      1. BDCOM P3310B (Вживаний) - 6000 грн.
      2. BDCOM P3310C (Вживаний) - 7500 грн.
      3. BDCOM P3310C (Вживаний без вух) - 7000 грн.
      4. BDCOM P3608-2TE (Вживаний) - 20000 грн.
      5. BDCOM P3608-2TE  (Вживаний) - 19000 грн.

    • Від grapefruit
      Доброго вечора, спільното!
      Можливо хтось стикався з завданням,коли потрібно на OLT BDCOM GP3600 по oid визначити час розреєстрування ону. В неті нічого знайти не вдалося, через MIB браузер тоже ніц.
      Якщо підкажете буде дуже вдячний, або хоч підкажіть де шукати.
      Всім гарного вечора)
    • Від alexeya
      Продам OLT ZTE C320. OLT укомплектован блоком живлення PRAM, двома платами GTGH(K00), платою керування SMXA(A31).

      Кожна GTGH-плата, це 16 GPON портів, 16 GPON модулів C++.
      SMXA-плата, це SFP+ (10G) порт, 1 гігабітний комбо порт.

      В наявності 2 одиниці. Один новий, один був у використанні (стан близький до нового)

      Ціна нового - 120000 грн
      Ціна вживаного - 105000 грн

      BDCOM GP-3600-08B куплявся в ДЕПСі в вересні 23 року. В ньому використовувались тільки 3 порти (тобто є тільки 3 GPON SFP модулі). 48к разом з модулями

      ОЛТИ без модулів:
      3310B-2AC - 1штука - 8000
      3310B - 2 штуки - 7500
      3310B + Proline UPS - 1 штука - 8500
      3310D + Proline UPS - 1 штука - 12500
      BDCOM P3600-04 + Proline UPS - 1 штука - 16500
      3616-2TE - 3 штуки - 53к

      Додам вживані EPON С++ модулі по 400 грн за штуку. Або нові по 750 грн за штуку
    • Від alexeya
      Продам оборудование в связи с прекращением деятельности телеком-оператора в Донецкой области.
       
      Eltex MES2324FB в отличном состоянии (8 штук) - 13.000 грн
      Eltex MES5324 (24 SFP+, 4 QSFP) - 62.000 грн
      Extreme Networks X620-16x (16 SFP+) - 42.000 грн
       
      OLT ZTE C320 (GTGH (K00) * 2, PRAM, SMXA (A31) - 32 GPON ports, C++ модули, 10G плата управления. Состояние близкое к новому (был в эксплуатации пол года) - 110.000грн, новый 125.000 грн.
       
      Juniper MX80 (MX5-T upgraded to MX80, 16 subsribers, все лицензии есть), есть 2 штуки. - 1700$
       
      Кабель бухтами (в Павлограде, могу привезти в Днепр или отправка деливери/нп)
      ОКТ-Д(1.0)-2Е1-0,36Ф3,5/0,22Н18-2 — 3000м - 3.5 грн/метр 
      ОКЗ(б2,7)Т-008(7,8 мм) — бухти 3840 и 4000 м - 13 грн/метр
      ОЦБгП-8А1(1х8) 2,7 кН — 2 бухти по 3830 м - 13 грн/метр
       
       
       
























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