Content Type
Profiles
Forums
Events
Everything posted by Mackiavelly
-
epon onu-config-template vlan-per-user cmd-sequence 1 epon onu all-port ctc vlan mode tag %1 ... ! interface EPON0/1 epon pre-config-template vlan-per-user binded-onu-llid 1 param 101 epon pre-config-template vlan-per-user binded-onu-llid 2 param 102 ... epon pre-config-template vlan-per-user binded-onu-llid 64 param 164 ... ! interface EPON0/2 epon pre-config-template vlan-per-user binded-onu-llid 1 param 201 epon pre-config-template vlan-per-user binded-onu-llid 2 param 202 ... epon pre-config-template vlan-per-user binded-onu-llid 64 param 264 ... ! Странно работает вот так и не нужно 256 шаблонов, и вроде не сильно громоздко
- 26 replies
-
- 1
-
-
- pon
- bdcom p3310
-
(and 1 more)
Tagged with:
-
no epon oam-version 1 0x30
-
К сожалению по не понятным причинам, после пары запросов откисает SNMP...
- 33 replies
-
- onu-blacklist
- bdcom
-
(and 1 more)
Tagged with:
-
А де ви ці останні прошивки берете?
- 33 replies
-
- onu-blacklist
- bdcom
-
(and 1 more)
Tagged with:
-
да именно по этом у меня 3 olt 3310B c отвалеными портами и 10 3310С без всяких проблем и только на одной наблюдаются проблемы из первого поста и конфиги одинаковые, только вланы разные, а онушки везде небольшой зоопарк
-
Вариантов я так понимаю нет...
-
Pon Control - комплекс управления и мониторинга сетью
Mackiavelly replied to dan_aspire's topic in PON
хм а это уже странно проверил на своих олт Build 46085 и на Build 36039 все норм -
Pon Control - комплекс управления и мониторинга сетью
Mackiavelly replied to dan_aspire's topic in PON
прошивка в конце D или E -
Pon Control - комплекс управления и мониторинга сетью
Mackiavelly replied to dan_aspire's topic in PON
P3310B? -
более того для теста меняли ону, перед свичами которые пропадают, на других производителей, результат не поменялся...
-
Есть OLT BDCOM P3310C Build 43480 у нее на одном из pon портов висят онушки(класика все как обычно темплейт все дала) epon onu-config-template E1000 cmd-sequence 001 epon sla upstream pir 1000000 cir 10000 cmd-sequence 002 epon sla downstream pir 1000000 cir 10000 cmd-sequence 003 epon onu all-port ctc loopback detect cmd-sequence 004 epon onu all-port ctc vlan mode tag <каждая ону в своем отдельном влане> ! interface EPON0/1 epon pre-config-template E1000 binded-onu-llid 1-64 switchport mode trunk switchport protected 1 ! все вланы транком уходят на комутацию за каждой ону(назовем их эксесные ону) кроме одной находится управляемый свич на котором висит IP (чисто для мониторинга) в каждом свиче макс 4 клиента вот за одной из ону(назовем ее транковая ону) чуть другая схема там стоит свич из которого включено еще 3 свичика, на эту ону отдается транк и все 4 свича за этой ону тоже в отдельных вланах STP любого рода выключено везде суть все работает как часики, НО --------------------------------- Если например пропадает питание на одном из свичей который находятся за транковой ону, на некоторые другие свичи которые находятся за эксесными ону пропадает пинг(именно пинг), более того у клиентов все работает как и работало, сессии спокойно себе висят, притом для теста пробывали и ppptp и pppoe, и новые сессия спокойно устанавливаются... во общем все работает но пинг(icmp) на свичи почему-то не проходит... И казус всего этого, что фактически все розвланено, и коммутаторы даже не знают про существование друг друга... Та же ситуация наблюдается и в обратную сторону если пропадает эксесная ону и естественно свич за ней то пропадает пинг на 2 из 3 свичей за транковой ону и парочки свичей за эксесными ону Логи везде где только можно не регистрирую ничего даже варнингов... Повторюсь сеть продолжает работать стабильно без никаких проблем, просто в мониторинге смотрится не очень))) Может кто-то стыкался с похожей ерундой. P.S. да, да сеть построена не идеально но это тема отдельного разговора...
-
ага как выяснилось данные OID появились только в прошивках E аля Version 10.1.0E, во всех предыдущий версиях, этих полей нет, дерево заканчивается на 8 индексе
-
.1.3.6.1.4.1.3320.101.11.1.1.10.10.128.20.168.62.77.72 Name/OID: llidOnuBindLastDeregTime.10.128.20.168.62.77.72; Value (OctetString): 0x07 E1 0A 12 14 3A 2E 00 2B 03 00 на всякий это тоже оставлю здеся... ))))
-
.1.3.6.1.4.1.3320.101.11.1.1.11.10.128.20.168.62.77.72 Name/OID: llidOnuBindLastDeregReason.10.128.20.168.62.77.72; Value (Integer): power-off (9) тут вроде вообще все понятно
-
да да я вот эти 2 поля LastDeregTime, LastDeregReason тоже очень хочу... Нашли oid ? К сожалению, их не существует. Ответ от китайской техподдержки. Таки да OID не нашел взял телнетом.... думаю все найдут то что искали .1.3.6.1.4.1.3320.101.11.1.1, и похоже чутка прибрэхивает китайский саппорт Ничего подобного тут нету. Единственный способ отловить dereg reason - это ловить snmp трапы. Только есть одна загвоздка, в трапах есть только DyingGasp - пропало питание и registered/deregistered onu event. Cледовательно чтобы найти wire down - нужно складывать в базу данных все события питания и проверять не пропало ли питание когда приходит deregistered. В общем эти все скрипты есть и они даже работают, а в кактях рисуется количество wire down на ОЛТ, но не всегда нормально обрабатывают события, особенно когда питание пропадает массово и шлется куча сообщений. Скорее всего не вовремя отрабатывают многоэтажные костыли в виде snmptrapd - snmptt - самодельный php trap handler в кучу потоков. Поэтому не вижу смысла выкладывать это здесь. Для нормального решения задачи гораздо проще и эффективней ломиться телнетом и парсить вывод команды. ну плохо для вас, но вот например, .1.3.6.1.4.1.3320.101.11.1.1.9.10.128.20.168.62.77.72 последние 6 отсеков как не странно мак onu, 7 с конца порт на котором висит ону, тут все просто, само значение выглядит так Name/OID: llidOnuBindLastRegTime.10.128.20.168.62.77.72; Value (OctetString): 0x07 E1 0A 12 14 3B 11 00 2B 03 00 и о боже как все страшно, но 07 E1 = 2017, 0A = 10, 12 = 18, 14 = 20, 3B = 59, 11 = 17, для проверки идем в телнет и находим там EPON0/4:12 8014.a83e.4d48 auto-configured ctc-oam-oper 3977 2453 2017.10.18.20:59:17 2017.10.18.20:58:46 power-off 39.15:05:25 матерь божья оказывается есть удобный snmp, где если поискать можно что-то найти...
-
да да я вот эти 2 поля LastDeregTime, LastDeregReason тоже очень хочу... Нашли oid ? К сожалению, их не существует. Ответ от китайской техподдержки. Таки да OID не нашел взял телнетом.... думаю все найдут то что искали .1.3.6.1.4.1.3320.101.11.1.1, и похоже чутка прибрэхивает китайский саппорт
-
да да я вот эти 2 поля LastDeregTime, LastDeregReason тоже очень хочу...
-
Image Loader 1.0.5.0 Image File 1.4.20.11 проблема такая же, ни mercury, ни admin не подходят
