Перейти к содержимому

(Решено) Чудеса P3616-2TE


melvin

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

Добрый день!

Существует вот такая проблемка:

На олте 15 pon портов (1-6,8-16) забиты практически полностью (по 3-4 свободных места на каждом).

Темплейт тривиальный и один для всех epon портов:

epon onu-config-template ep1
 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 11
 cmd-sequence 2 epon onu port 1 ctc loopback detect
 cmd-sequence 3 epon onu port 1 storm-control mode 1 threshold 256

Настройки epon портов тоже одинаковы:

epon pre-config-template ep1 binded-onu-llid 1-64
 switchport trunk vlan-allowed 10-11,44
 switchport mode trunk
 switchport pvid 44
 ip access-group subs.filter
 switchport protected 1

Прошивка OLT'а:

BDCOM(tm) P3616-2TE Software, Version 10.1.0E Build 36039
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2016-6-22 15:9:50 by SYS, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.5, Serial num:00315072970
System image file is "Switch.bin"
hardware version:V1.0
(RISC) processor with 262144K bytes of memory, 32768K bytes of flash
Base ethernet MAC Address: 00:e0:0f:5e:ee:ad
PCB version:A 
snmp info:
  product_ID:2011   system_ID:1.3.6.1.4.1.3320.1.2011.0

Описание проблемы:

На 7-мом epon порту зарегистрировано 32 онушки, которые стабильно функционируют и выполняют свою задачу.

33-ая и последующие онушки, при добавлении, успешно регистрируются (reg горит стабильно, не пропадает), но конфиг теплейта не подтягивают ни в автоматическом режиме ни при конфигурации в ручную. 

Выдает следующее:

Current configuration:
!
interface EPON0/7:35

Но при этом в самом порту:

 

 epon bind-onu mac 8014.a8a4.1710 35

Замечено, что та же онушка, но на других epon портах регистрируется , подтягивает автоматом конфиг и нормально продолжает функционировать.

- SFP модуль меняли;

- ONU VSOL, BDCOM, FOXGATE - симптомы одни и те же.

 

Заранее спасибо.
 

Изменено пользователем melvin
Ссылка на сообщение
Поделиться на других сайтах

А зачем у Вас ?

 switchport pvid 44

и

cmd-sequence 1 epon onu port 1 ctc vlan mode tag 11

одновременно?

 

И тут же 44 влан транком

switchport trunk vlan-allowed 10-11,44

и его pvid указываете

switchport pvid 44

 

 

И обновитесь до 46085.

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

Дык влан управления, нет ?

всё норм, я тоже так делаю, чтоб в 1 влан ничё не приходило

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

Как зачем?????

11 влан - это сервис под абонентов

44 влан - это менеджмент.

Влан транком быть не может :)

А что Вас возмутило в pvid  ?????? э

Да и смысл то не в том, куда Вы обратили свое внимание т.к. на всех остальных портах все замечательно.

 

Ребят, а кто-то тестил 46085, как со стабильностью?

20 минут назад, RockManX сказал:

всё норм, я тоже так делаю, чтоб в 1 влан ничё не приходило

ОООО, плюсую к карме. 

Изменено пользователем melvin
Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Касается всех портов в целом при включенной функции или есть ограничение на общее кол-во ону с этим функционалом?

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

я не помню, но что мешает проверить в ночное время, сохранить конфиг, отреггать все и зарегистрировать по новой с минимальнім конфигом ону где указан только влан.  Когда то на форуме подымался такой вопрос, поищите повнимательней.

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

За совет спасибо. На ограничение по портам не похоже, т.к. на всех остальных портах от 58 онушек.

Если есть ограничение по общей таблице, то достаточно, для эксперимента, вручную удалить несколько записей шторма с некоторых онушек.

 

Перерегать онушки - не вариант. Несколько вланов и в этих вланах разные подсети.

Спасибо.

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

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

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

Проблема решилась банально.

Для начала - небольшое отступление.

Удалось поковыряться в недрах интернета и проверить эксперементальным путем ограничения по кол-ву ONU на порту.

Делаем вывод:

Ограничения по таблице tcam действуют при подключениях dhcp-snooping, isg (ip source guard), dai (arp inspection), acl.

 

На данный момент проблема решилась перепрошивкой на:

BDCOM(tm) P3616-2TE Software, Version 10.1.0E Build 49510
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2018-1-11 15:4:51 by SYS, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.5, Serial num:00315072970
System image file is "Switch.bin"
hardware version:V1.0
(RISC) processor with 262144K bytes of memory, 32768K bytes of flash
Base ethernet MAC Address: 00:e0:0f:5e:ee:ad
PCB version:A 
snmp info:
  product_ID:2011   system_ID:1.3.6.1.4.1.3320.1.2011.0

Онушки на epon 0/7 теперь дальше продолжают регистрироваться и подтягивать конфиг с темплейта в автоматическом режиме.

Таким образом ограничения не действуют на loopback и storm control - это факт.

Благодарю форумчан, которые высказали свои идеи и предположения. "Поле для маневра" - это уже половина решения поставленной задачи. 

 

З.Ы: До этого была проблема с epon 0/6 (пол года назад), но решилась заменой SFP модуля. Но там ситуация была чуть другая, сигнал был хороший, но ни одна ONU не регистрировалась. Может кому поможет в будущем.

 

После перепрошивки -  конфиги не послетали (хоть и не должны были, но чем черт не шутит :) ). Все онушки зарегистрировались в штатном режиме, косяков со скоростью не обнаружено, ONU с порта на порт не плавают (бывает и такое :) ), вланы поподхватывали те, которые и были на них закреплены. На каждом epon порту действует access-list

 

Для тех, кто ищет:

 

BD_3616_10.1.0E_49510.bin

Изменено пользователем melvin
  • Like 2
  • Thanks 3
Ссылка на сообщение
Поделиться на других сайтах
  • 5 weeks later...

Добрый день.

Понимаю что не в той теме, но не знаю где спросить, по-этому приношу свои извинения.

Нужны дефолтные логин и пароль на web интерфейс BDCOM ONU GP1501DR (gpon).

ip 10.0.0.10/24 уже знаю.

Но дефолтные admin/admin и все что приходило в голову, в том числе ресет кнопкой, не помогли.

ОНУ с коробки. До меня ее не ковыряли.

Заранее спасибо всем откликнувшимся.

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

Добрый день.

Понимаю что не в той теме, но не знаю где спросить, по-этому приношу свои извинения.

Нужны дефолтные логин и пароль на web интерфейс BDCOM ONU GP1501DR (gpon).

ip 10.0.0.10/24 уже знаю.

Но дефолтные admin/admin и все что приходило в голову, в том числе ресет кнопкой, не помогли.

ОНУ с коробки. До меня ее не ковыряли.

Заранее спасибо всем откликнувшимся.

в депс обратитесь  там подскажут 

Ссылка на сообщение
Поделиться на других сайтах
  • 3 weeks later...
В 17.07.2018 в 11:27, melvin сказал:

Проблема решилась банально.

Для начала - небольшое отступление.

Удалось поковыряться в недрах интернета и проверить эксперементальным путем ограничения по кол-ву ONU на порту.

Делаем вывод:

Ограничения по таблице tcam действуют при подключениях dhcp-snooping, isg (ip source guard), dai (arp inspection), acl.

 

На данный момент проблема решилась перепрошивкой на:


BDCOM(tm) P3616-2TE Software, Version 10.1.0E Build 49510
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2018-1-11 15:4:51 by SYS, Image text-base: 0x10000
ROM: System Bootstrap, Version 0.4.5, Serial num:00315072970
System image file is "Switch.bin"
hardware version:V1.0
(RISC) processor with 262144K bytes of memory, 32768K bytes of flash
Base ethernet MAC Address: 00:e0:0f:5e:ee:ad
PCB version:A 
snmp info:
  product_ID:2011   system_ID:1.3.6.1.4.1.3320.1.2011.0

 

 

Для тех, кто ищет:

 

BD_3616_10.1.0E_49510.bin


Добрый день
поделитесь файлом tiger.blob

Ссылка на сообщение
Поделиться на других сайтах
В 06.09.2018 в 17:42, router_mx сказал:

С этой прошивкой BD_3616_10.1.0E_49510.bin он нормально дружит?

 

В 06.09.2018 в 17:44, Doctorzlo сказал:

насколько помню да , да и на самом деле   версия тайгера не особо  зависит от прошивки  

как и прошивка от тайгера 

Версия тайгера не зависит от прошивки. Но, лучше, выложу, т.к. Bdcom - это еще те чудеса в коробке.

 

Сам файл:

 

tiger.blob

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

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

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

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

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

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

Войти

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

Войти сейчас
  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: tadesky
      Продам б/в BDCOM P3616-2TE OLT . 

      Повністю робочий, без нюансів, знятий після модерну.  Комплектований резервним БЖ. 
      Оціночна вартість 40 тис. грн.

      За потреби можна комплектувати SFP Picotel EPON SFP PX++ = 600 грн/шт. 
       
      Пишіть в особисті. 
       
    • Автор: forella
      Имеется такая ситуация.
      топология: абонент---ону---bdcom p3310---cisco 4948--- далее 2 пути, 99% идут на линуксовый шлюз, оставшиеся(избранные, назовем их так) 1% на микротик по оттдельному vlan.
      олт 13шт. каждая олт оттдельным портом на 4948 подключена. все аналогично работают как описано выше.
      наблюдается вот такая ситуация на циско:
       
      *Apr 20 03:17:28.873: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:32.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 *Apr 20 03:17:33.489: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/11 to port Gi1/5 *Apr 20 03:17:34.273: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/10 to port Gi1/11 *Apr 20 03:17:34.277: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/11 to port Gi1/10 *Apr 20 03:17:43.769: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/7 to port Gi1/11 *Apr 20 03:17:43.973: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:47.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 vlan 321 это те самые избранные, и по логам видно что связующее звено 11 порт, за ней олт. (порты 5,7,10 так же олт)
      что было сделано:
      на олт за 11 портом выключены абоненты имеющие отношение к влан 321 - флапы продолжились.
      выключены пон порты по очереди и все сразу - флапы продолжились.
      выключен порт 11 на циско - флапы прекратились.
      включен порт, но удален влан 321 на циско - флапы прекратились.
      собственно вопрос - это глюк прошивки олт, что при выключеных пон портах флапы продолжаются, либо не там ищу причину?
       
    • Автор: Emanon
      Приветствую форумчан. Есть проблема и суть ее такова:
      В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600.
      Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разговора.
      А пока что хотелось бы в кое чем разобраться. Недавно, начали идти заявки от НЕКОТОРЫХ абонентов одного и того же дома с одного и того же узла с жалобой на нестабильный интернет. Это через неделю-две после изменения топологии и соответственно, переключения их коммутатора к pon-сети.
      Техник, осмотрев происходящее, заявлял что рандомно, раз в минуту-две, начинаются потери пакетов. Проверял целостность линий,  подключался напрямую ноутом. Результат один и тот же. Линк между свичом и роутером не падает. Не падает линк и между onu и свичом. Проблем с режимами (half duplex, full duplex) портов тоже не было. Если уже далеко зайти, сам домовой свич, olt, коммутатор агрегации, без проблем пингуются (правда находятся в отдельном управляющем vlan). Очевидные проблемы, вроде роста cpu и утечек памяти, в их работе не наблюдались. В логах все чисто. В мониторинге видно, что канал не нагружен (download и upload не превышают 250 Мбит как по pon так и выше, нет аномальных значений pps как для broadcast, так для unicast и multicast). Да и для остальных пользователей, кроме проблемных, не было вопросов. У всех вроде работает, кроме некоторых ребят с конкретного узла. Трасса упорно показывает, что проблемный участок как раз между роутером и bras. Логи на роутерах тоже ничего вразумительного не пишут. При этом, стоило подключить вместо абонентского tp link archer ax12, c64 или keenetic titan, какой то древний роутер, вроде dlink dir300 или tp link tl-wr841n, как все работало стабильно, без потерь. 
      Со стороны bras сессии не рвутся, но через tcpdump действительно обнаруживается, что при пинге ( как 32 байта, так и побольше) часть icmp пакетов от проблемных абонентов не доходит. 
      Менялись mac  абонентских устройств, пытались найти mac flapping, менялся mac aging, менялся абонентский ip. Без результатов. Mac таблица за onu не забивается кстати, там не более 8 устройств. Проверялись оптические уровни. Конечно, onu rx -24 и olt rx -26 - это уже почти на грани. 
      И наверное это отчасти играет роль. Но нюанс с тем, что происходит при замене роутеров, заставляет задуматься. Возможно то, что такое вылезло именно после перехода на gpon - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
    • Автор: CoUL
      Sync users ONU скрипт.
      Скрипт виконує автоматичне додавання ONU та відповідної OLT, на якій вона зареєстрована, в карту абонента MikBiLL.
      Забезпечує повну синхронізацію ONU при зміні топології мережі — тобто при реальному переміщенні ONU між OLT або між абонентами. Все відбувається автоматично без необхідності вручну додавати чи змінювати ONU працівниками.
      Можлива синхронізація окремих OLT в ручному режимі.
      Підтримується робота з BDCOM EPON та GPON обладнанням.
      Можливе розширення під інших виробників OLT за потреби.
      💬 По всім питанням звертайтесь у приват.
      BDCOM xPON ONU Auto Sync Script.webm
    • Автор: ГрозаИнтернета
      Всем привет. Сеть разбили, продаю оборудование, которое удалось спасти.
      Роутер MikroTik 1036-12G-4S - 16500 грн.
      Сервер Dell R410(Xeon L5640(60Вт), 16 Gb RAM, 2x300 Gb SAS, iDrac, Raid, IPMI) - 4500 грн.
      Коммутатор ZyXEL MES-3528 - 2000 грн.
      Коммутатор HUAWEI S2326 - 1500 грн.
      Коммутатор Dell PowerConnect 6224F(опц.10G) - 5000 грн
      Коммутатор D-Link DGS-3627G (нюанс) - 1000 грн
      OLT BDCom P3310(Пролайн упс) - 9000 грн
      Упс APCSmart-UPS RT 2000 + картаAP9619 + кабель для подключения внешних АКБ - 12500 грн.
      Коммутатор ELTEX MES2324FB AC в коробке - 10000
      OLT EPON E9004-D 10G (Пролайн упс) в коробке - 10000
      Кабель OK-NET S/FTP Cat.6a 500Mhz LSOH AWG 23 4pr 280 метров - 8500
      Куча SFP EPON C+++, SFP SC, сетевые карты, твинакс кабеля.

×
×
  • Создать...