Reanemator_ua

Не получится - я уже говорил - ОЛТ трогать не надо. Алгоритм должен быть простой, как грабли, но не уязвимый.

Смотрите - мы реализуем фичу, которую хотят многие ISP. По умолчанию она выключена. Хотите - включайте, хотите - нет. Если права с Законом и будут, то провайдер идёт на это сознательно. Мы рассматриваем техническую сторону момента, а не юридическую. Хотя если тут есть грамотные юристы, то они могут высказать своё мнение по этому поводу.

Ну с этим тоже можно бороться. Можно заставить ОНУ блокировать прошивку ниже её текущей. Т.е. обновить назад уже не получится. Но тут нужно сделать так, чтобы при обновлении вперёд список МАКов не удалялся.

Через шаблон не получится. Как я сказал, ОЛТ в этом алгоритме вообще не участвует - забить список МАКов на ОНУ можно будет только через Телнет и/или WEB.

Смотрите, получается в нашем алгоритме есть один недостаток - мы не учли вариант выхода из строя Ваших родненьких ОЛТов. Конечно вероятность не велика но всё же. Решения, как я вижу, может быть 2: 1) Залить на новый OLT ROM от старого OLT-а. Действие не очень долгое и за 10 минут можно управиться. 2) Всё таки разрешить ОНУшкам регаться на ОЛТе, но не пропускать трафик. Как по мне 2-ой вариант действительно лучше, т.к. позволит быстро менять МАКи на ОНУшках удалённо, а не катаясь по всему району к клиентам. Но для этого на всех ОНУшках должен быть назначен ВЛАН управления. P.S. В

В том то и дело - BDCOM это делать не будет. поэтому вариант один - творить фичу на стороне ОНУ. По поводу смены МАКа на ОЛТе - да можно. Для этого нужно загрузчик заменить. В общем, если столкнётесь с такой проблемой - поможем.

А никто не говорит, что мы её придумали. Но мы услышали мнение комьюнити и составили с китайцами алгоритм работы этой фичи, чтобы ничего не упустить из виду.

Давайте не будем ссориться, но мы свои FORA никогда не позиционировали как роутеры, т.к. они таковыми не являются . Данная ONU - это SFU устройство, работающее в режиме бриджа - не умеет оно NATить и работать в режиме роутера. Да чего уж там греха таить - и Wi-Fi там отродясь не было. P.S. роутер приобретается отдельно. Например TP-Link 741N - не плохая и крайне популярная модель.

Никто ничего не видел . Это коммерческая тайна.

Ну сама прога тут лежит и молчит https://www.dropbox.com/sh/wuotrjsnlbim0oc/AABrELiWKwEhk11-c_62cqM2a?dl=0

Цена проги - 5000$. Я думаю BDCOM не даст ключ. . Я бы не дал.

Плохо то, что если Netis на MTK, то это решение себя не оправдало.Я уже выкладывал в ветке UA.PON 6.0 тест ONU TP-Link на MTK чипе. У этого зверя есть пару вполне очевидных недостатков. 1. Он не поддерживает Management VLAN. Т.е. устроить попингушки из Zabix-а и посмотреть, а жива ли ONU не получится. Следующий недочёт - нет поддержки Loop Back Detection. Для кого-то тоже не страшно; а для тех, кто испытал на себе всю прелесть флуда с клиентской сетевушки, наличие LBD на ONU является обязательным требованием. По моему мнению MTK чип является не стабильным. Может быть не стабильным является

Это называется "Найдите 10 совпадений" ))) Чем они похожи? Визуально или аппаратно?

Я имел в виду физически вскрывать ОЛТ. Мы договорились с клиентом, что он может вскрыть ОЛТ и даже если у него ничего не получится, то он вышлет его нам и мы его отремонтируем.

Сам клиент лезть в OLT не должен до истечения гарантийного срока. У клиента OLT уже не на гарантии. Но поскольку я сам дал ему не верный дамп, что и привело к гибели устройства, то тогда IC-Line берёт ответственность на себя за ремонт девайса.

Всем привет. Давайте я разъясню, что к чему. 1) По не понятным причинам у клиента раз в неделю отваливается по одной ФОРе - не критично, но не приятно. Проблему диагностировать не получается, т.к. сигналы в норме, флуда в сети нет. ONU может отвалиться хаотично в любом дереве. Ребут ОНУ с ОЛТа либо передёргиванием питания проблему решает. 2) Было принято решение откатиться до старой версии прошивки, чтобы проверить, проявится ли баг. Тут неоднократно поднимался вопрос о том, что BDCOM лочит сторонние ОНУ. Но доказательств этому нет. Вот мы и решили проверить, так ли это на самом деле.

На коммутаторах домовых производства BDCOM (S2228F) так же? Думаю, что да. Не проверял.

Я предложил решение, а пользоваться им или нет - дело Ваше. У BDCOM-а реально команда ip dhcp-relay snooping vlan <VID> включает снупинг во всех ВЛАНах сразу.

На текущий момент у BDCOM-а есть такие варианты обработки DHCP пакетов Switch_config_g0/1#dhcp snooping information ? circuit-id -- Config the suboption with circuit_id(suboption 1) remote-id -- Config the suboption with remote-id(suboption 2) vendor-specific -- Config the suboption with vendor-specific(suboption 9) drop -- Drop the packet with option82 replace -- Replace the option82 of the packet append -- Append the information in suboption 9 with configuration Чем Вам не подходит вариант APPEND. Если опции нет, она добавляется;

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

На каком чипе сие чудо?

Ну как сказать... аппаратная это проблема или нет. С одной стороны - ДА, но с другой стороны, всё активное оборудование должно быть подключено к стабилизатору, УПС, а в идеале ещё и к генератору. В правилах эксплуатации OLT-а написано, что BDCOM не несёт ответственности за стабильную работу OLT-а при экстренном отключении питания. Как правило, Ваша проблема решается многократным ребутом OLT-а (более 5 раз). Если это не поможет, значит вероятней всего выгорели пару шариков на PON чипе, поэтому данные через порт не передаются. Олта была включена через упсу, света не было чоень долго...

Ну как сказать... аппаратная это проблема или нет. С одной стороны - ДА, но с другой стороны, всё активное оборудование должно быть подключено к стабилизатору, УПС, а в идеале ещё и к генератору. В правилах эксплуатации OLT-а написано, что BDCOM не несёт ответственности за стабильную работу OLT-а при экстренном отключении питания. Как правило, Ваша проблема решается многократным ребутом OLT-а (более 5 раз). Если это не поможет, значит вероятней всего выгорели пару шариков на PON чипе, поэтому данные через порт не передаются.

Добрый день. Давайте разберём проблему по частям. 1) ОНУшки к Вам уже попали с прошивкой 1.1.1 или Вы их шили сами? 2) Сколько примерно Фор работали нормально, а сколько начали "выделываться"? 3) В каком статусе находились Форы в этот момент? Т.е. что показывала команда show epon active-onu и show epon onu-information. Статусов может быть несколько: auto-configured, not ready, linkfault. Важно понимать, в каком статусе были ОНУшки, через которые не лился Инет. 4) Какой способ авторизации абонентов - PPPoE или IPoE? 5) Во время "отвала" Фор посмотрите, есть ли эта ОНУ в списке "show epo

Уже на версии 1.0.7 эти баги были пофикшены. Только учтите, многие прошивают на ОНУ только файл прошивки, а потом жалуются, что не помогло и бак не исчез. У Форы 2 файла прошивки - линукс ядро и собственно прошивка. Шить нужно оба файла. Вот ссылка на актуальную версию прошивки https://www.dropbox.com/sh/nryrdtvv8l4erb0/AADM84GTD2BppMfRmd5ftEK-a?dl=0