Reanemator_ua

за 2 месяца 3ий раз такое.причем у остальных голов такого не встречалось. Тогда я думаю только замена, если он гарантийный.

Я конфиг этого ОЛТа видел. Авторизация по DHCP. А вот прошивка на ОНУ стоит 1023. Вроде бы не старая, но у меня в базе такой прошивки нет - есть только 1022 и 1037, поэтому вариант один - шить до версии 1037, но это должен делать провайдер, а не абонент.

А эта ошибка не систематична, поэтому если она возникла единожды, то нет смысла беспокоиться. Не важно, гарантийный ОЛТ или нет, у нас нет средств для диагностики этой проблемы. Сам BDCOM нам говорил "Ну это скорее проблема PON чипа, что-то вроде зависания. Такое происходит крайне редко и после перезагрузки устройства рабочее состояние всегда восстанавливается". Иными словами, ОЛТу хотя бы раз в месяц нужно устраивать профилактический ребут ) Но если эта проблема будет повторяться, то по гарантии мы ОЛТ заменим.

Такая проблема на форуме уже всплывала. ОЛТ показывает, что он потерял все 4 PON интерфейса. Это происходит, когда главный чип опрашивает PON чип и не получает ответа. Почему это происходит - то ли из-за перегрева PON чипа, то ли из-за флуда в сети, не ясно.

Тут вариантов может быть несколько: 1) У Вас и так уже на порту зарегистрировано 64 ОНУ, просто одна из них уже давно отключена, но при этом от ОЛТа Вы её не отвязали и просто про неё забыли. 2) Текущая ОНУ уже была зарегистрирована на ОЛТе, но в другом дереве. Удалить её с другого дерева Вы забыли, вот ОЛТ и не хочет её авторизировать, т.к. будет конфликт МАКов. 3) На ОНУшках в дереве настроен SLA и сумма всех CIR-ов (гарантированной скорости) превышает пропускную способность ОЛТа. 4) Если это ОНУ FORA, то у неё была такая проблема на старой прошивке (1.0.6). на новых версиях прошивок

я имел ввиду мнение спеца в "общем", т.е. без привязки к производителю. При использовании любой альтернативной ОНУ, нужно понимать, что скорее всего она будет успешно регистрироваться и даже передавать трафик, но вот дополнительные настройки (LBD, storm-control, port-security) могут не работать

Его, скорее всего, не будет. Времени нет. жаль..... на что посоветуете обратить внимание при использовании данного девайса? Он у меня на столе лежит, но я его ни разу не подключал, поэтому ничего об Екстралинках сказать не могу.

Его, скорее всего, не будет. Времени нет.

Вообще интересное замечание. Мы столько продали этих ОНУшек, но даже не заметили такого косяка.

нет. не используем. только дхцп снупинг. к тому же в бою 8 олтов, конфиги идентичны. на половине олтов абонентов поболее чем на проблемном. На всякий случай можно проверить загрузку OLT_а и список процессов (show cpu, show task). Был случай, когда в сети был слишком маленький Lease Time (около 5 минут), от чего клиенты постоянно перезапрашивали IP-шник и OLT не успевал строить таблицу. Может это не ваш случай, но нагрузку проца всё равно проверить можно.

Вы ACL используете? Если да, то проблема может быть в них.

Таблица FFP на OLT-е 3310 всего 512 записей. Для чистого DHCP Snooping-а, чтобы построить таблицу, вполне достаточно. Но вот если Вы включите DAI и ISG, то максимальное количество привязок составит 512/3 = 170, т.е. реально на ОЛТе одновременно могут сидеть 170 абонентов. Это при условии, что не используются ACL ))) P.S. По умолчанию таблица FFP разделена так: 256 записей на ACL и DHCP Snooping, и по 128 записей на DAI и ISG. Если хотите включить DAI и ISG, то максимальное количество клиентов при отсутствии ACL составит 128. Чтобы добиться 170 одновременно работающих клиентов, нужно вручну

Как правило решение данной проблемы - это хорошее охлаждение устройства. Но коль уж такая беда случилась, то решение только одно - прогревать BGA чип (мост между PON и Ethernet чипом). Причём прогревать в тупую феном не получится - нужна инфракрасная паяльная станция и нужен термопрофиль , иначе чип можно убить окончательно. А можно поинтересоваться для данного устройства - какой "реальный" критический температурный режим ? Максимальная температура чипа - 70 градусов. Речь идёт про чип, который выступает мостом между PON и Ethernet чипами.

Ну судя по тексту ошибки, OLT отправляет ONU-шке OAM пакет, пытаясь получить базовую информацию об ОНУшке. ОНУшка при этом не отвечает, либо не успевает ответить (если Вы не изменяли EPON MPCP timeout). Если ОНУ 3 раза не отвечает, OLT может её удалить. По какой причине это происходит в дереве, где стоят все BDCOM-ы сказать трудно. Как вариант "бокавые" ОНУшки можно перепрошить. Ну и святое дело - покажите конфиг OLT-а и его прошивку.

Как правило решение данной проблемы - это хорошее охлаждение устройства. Но коль уж такая беда случилась, то решение только одно - прогревать BGA чип (мост между PON и Ethernet чипом). Причём прогревать в тупую феном не получится - нужна инфракрасная паяльная станция и нужен термопрофиль , иначе чип можно убить окончательно.

1. этот напряг в 5$ окупается за 1 месяц. 2. это в пределах 1-2х процентов общей стоимости сети при этом растянуто по времени - не все же 5К сразу подключатся, а вот линки должны быть готовы, т.е. ОЛТ +/- надо будет приобресть, а тут как раз Гпон в 2 раза дешевле. + экономия волокон в 2 раза, а соответственно и человекоресурсов и бабла. 3. При 5К абонов даже если просто активку брать разница будет не 5$ Что-то я не пойму. А где Вы видите экономию волокон в 2 раза? Экономия только на магистральном участке! А распределительный и абонентский участки оптической трассы остаются такими же.

1. этот напряг в 5$ окупается за 1 месяц. 2. это в пределах 1-2х процентов общей стоимости сети при этом растянуто по времени - не все же 5К сразу подключатся, а вот линки должны быть готовы, т.е. ОЛТ +/- надо будет приобресть, а тут как раз Гпон в 2 раза дешевле. + экономия волокон в 2 раза, а соответственно и человекоресурсов и бабла. 3. При 5К абонов даже если просто активку брать разница будет не 5$ Что-то я не пойму. А где Вы видите экономию волокон в 2 раза? Экономия только на магистральном участке! А распределительный и абонентский участки оптической трассы остаются такими же.

Пруф пожалайста, о том что на канальное кодирование уходит в GPON именно 0.5G, или Вы посчитали это по принципу EPON 1.25 Gbps (1.0 Gbps 8B/10B coding) и умножили на 2 ? Итак, освежил в голове мат часть. В итоге мы имеем,что в GPON эффективная нагрузка сети составляет 92%, это примерно 2.2G. В GEPON-е 1G. Кажется что GPON выигрывает. Но давайте теперь задумаемся на тему - а реально ли в GEPON-е 1G. Конечно нет. Ведь существуют служебные пакеты (OAM. MPCP), которые не относятся к канальному кодированию, но при этом снижают полезную нагрузку трафика. В итоге эффективная нагрузка в GEPO

Ну а если Вы Господь БОГ, так можно и на 1024 поделить . А если серьёзно, то -25 dB на абонента - это не по стандарту. Должен быть запас 3 dB, на деформацию кабеля, микротрещины, деградацию волокна, деградацию лазера ОНУ и самого ОЛТа. Но в принципе согласен - при правильном подходе поделить на 128 и оставить ещё запас можно, но реально я такое встречал пару раз . Поэтому соглашусь с тем, что лучше не выпендриваться и использовать GEPON. По сути что Вы 1G делите на 64 абонента, что 2G на 128 - т.е. экономия только на волокнах. В GEPON-е волокна и так достаточно эффективно используются - не в

Пример команды приведешь? вроде все работает Саш, я в нашей теме UA_PON 6.0 писал тест по этой ОНУшке и приводил примеры команд, которые применяются, но по сути не работают.

Вообще всё зависит от хотелок. Уже не раз на локале обсуждалось, что у любого ОЛТа есть набор команд для управления ONU. Часть из этих команд OAM (Operation/Administration/Maintense), другая часть CTC (China Telecom Corporation). Как правило сторонние ONU спокойно "кушают" CTC команды с не родного OLT-а. Но бывают исключения, причём довольно часто, когда ONU выдаёт ошибку при попытке применить к ней CTC команду. Что уж говорить про OAM. OAM - протокол стандартный (TPID: 0x8808 и 0x8809) для всех производителей, но вот в теле протокола производитель может изгаляться как хочет - шифровать данны

у меня тоже под рукой нет новых BDCOM_ов. Завтра на FORE проверю

Вот мои настройки ONU interface EPON0/1:4 onu-configuration epon onu port 1 ctc vlan mode trunk 1 200,1000-1002 epon onu port 1 ctc mcst mc-vlan add 1000-1002 !!onu-configuration-end При такой конфигурации мультикаст проходит тэгированным до следующего свитча, а уже там тэги снимаются. P.S. ONU 1501C, за OLT-ом стоит BDCOM 3928GX.

Этот параметр определяет через сколько циклов передачи данных будет цикл регистрации ОНУшек. Чем этот параметр меньше, тем быстрее регаются ОНУшки, но тем меньше становится полезная нагрузка сети, так уменьшается кол-во циклов передачи данных.

Transparent не пробовали ? Насколько мне известно режим transparent на ONU работает как туннель только для бродкаст и уникаст трафика, а мультикаст трафик всё равно обрабатывается отдельным процессом. Поэтому если есть желание использовать transparent и для мультикаста, то на ONU нужно отключить ip mcst enable - в этом случае ONU-ха будет обрабатывать мультикаст как обычный трафик.