Reanemator_ua
-
Всього повідомлень
325 -
Приєднався
-
Останній візит
-
Дней в лидерах
3
Тип контенту
Профили
Форум
Календарь
Все, що було написано Reanemator_ua
-
Как и обещали - новая прошивка для пластиковых ФОР, решающая проблему падения ОНУ в Linkfault, уже на нашем Дропбоксе. https://www.dropbox.com/sh/yt8lzgl8n90lwjs/AAA96KGb02ASk-N0JY6dsIPWa?dl=0 Наслаждайтесь.
-
Нет, порт всё равно нужно насильно переводить в сотку. По заверениям китайцев, эта недоработка будет исправлена в следующей прошивке.
-
Если модуль в гиге, и при этом порт 2528GX насильно перевести в сотку, то работать будет.
-
Не переживайте - книг у нас много
-
Для жаждущих ACL на пластиковых FORах - китайцы пообещали, что на следующей неделе будет релиз новой прошивки. Ждёмс...
-
Всем приятных весенних деньков и дешёвых ONU-шек . Есть хорошая новость. Проблема падения пластиковых ONU FORA в статус LinkFault, а затем в Not Ready, обнаружена. Как видите, проблема диагностировалась достаточно долго, так как найти причину было сложно. Смысл в том, что OLT через определённый промежуток времени посылает ONU так называемые Heart-Beat сообщения и ждёт на них ответа. Если ответа нет в течение определённого промежутка времени, то OLT считает, что ONU отключилась по неизвестной причине и переводит её в статус LinkFault. Через некоторое время статус LinkFault меняется на NotReady, что примерно означает "Не законченный режим регистрации". Что интересно - даже в статусе LinkFault и NotReady ONU может запрашивать у OLT-а кванты времени и получать их для передачи пакетов . Но при этом диагностическую информацию ONU не показывают. Так почему всё такие FORы падают в LinkFault. Потому что они не успевают отправить OLT-у это самое Heart-Beat сообщение. Причина этого довольно интересная - большая перегрузка чипа ONU PPPoE сессиями и/или DHCP запросами. Поэтому ,дорогие друзья, если Вы используете PPPoE, то изолируйте EPON порты между друг другом. Это же касается любителей IPoE - также изолируйте EPON порты, используйте DHCP Snooping с назначением доверительного порта. Это заметно сократит количество бродкастного флуда в сети. И вообще на OLT-е есть функция ограничения кол-ва DHCP запросов, проходящих через чип в единицу времени. Тем не менее, мы не пытаемся оправдаться . Новая прошивка для решения бага уже в строю.... и мы Вам её не дадим !!! Прошивка находится в стадии бета тестирования, т.е. пока что является сыроватой. Но как бы то ни было, на текущий момент при использовании этой прошивки ONU в LinkFault больше не падают. Через несколько дней будет готов релиз новой прошивки и мы с радостью выложим её на Дропбокс.
-
На будущее учтём, но на текущий момент переделка пластиковой пресс-формы в Китае стоит более 10000$, так что сами понимаете
-
Мы занимаемся только OLT-ами компании BDCOM, поэтому о совмещении ONU FORA и OLT ZTE ничего сказать не могу.
-
sh epon act int e 0/1 Выделенное жирным, это ону от FORA, но при этом есть интересный момент, у сотрудника работает интернет нормально, 6 суток поднята сесия PPPoE. Еще что нашел, не показывает при этом МАК онушки почемуто sh mac ad int e 0/1:31 При этом не работают команды указанные ниже, они ничего не выдают, как буд-то бы онушка выключена sh epon int epon 0/1:31 onu ctc ba sh epon int epon 0/1:31 onu ctc opt Прошивка на ону 1.0.5 Это, пожалуй, единственный баг, который найден на Форе и пока не поддаётся лечению. Правда варианта такого бага несколько: ОНУшка падает в Линкфалт и трафика нет, или трафик всё же есть, но при этом ОНУ не показывает диагностическую информацию. Как бы это не было печально, но с сегоднешнего дня китайцы уходят на новогодние каникулы и вернутся не раньше 27-го. Мой стенд из 64 ONU работает уже 2 недели и ФОРы в Линкфалт не падают. Заметил следующий интересный бажок - на EPON порту включаем обмен трафиком между ONU (epon inner-onu-switch), к 2 любым ONU подключаем ПК и начинаем пинговать друг друга. Пинг есть. Но! Если одна из этих ОНУ будет ФОРа, то пинг куда-то пропадает. Иногда при перетыкании меди пинг появвляется, при повторном перетыкании может опять пропасть. Эта ситуация наблюдалась на всех версиях прошивок: 1.0.4, 1.0.5, 1.0.6 и 1.0.7. Я не знаю может ли это быть связанным с Линкфалтом на ONU, но всё равно ситуация интересная.
-
Я конечно всё понимаю. Все хотят оптический бюджет в PONе 40 dB и чтобы абонентов можно было 1000 на одно волокно посадить. Бедный PON терзают как только можно
-
Идея отрубать ONU, которая перешла в состояние LOST конечно хорошая, но представьте, что абонент уехал в отпуск на 1,5 месяца и отключил ONU. Она само собой перейдёт в статус LOST, а вы возьмёте и клиента отключите. Не порядок
-
Только руками.
-
Я понимаю Ваше рвение решить проблему с MTU, только BDCOM не будет ничего решать, т.к. их тесты показали, что заявленные 1536 байт соответствуют действительности. Я пока мучаюсь с ФОРой, поэтому за MTU не брался. Вы можете сделать свой баг репорт с подробным описанием проблемы и тестов на английском языке, а я передам этот документ их инженерам. А то непонятно, когда у меня появится время для повторного теста MTU.
-
Вышла самая обалденная и самая новая прошивка для OLT P3310B (10.1.0B_22960). Тут недавно обсуждался вопрос, что если Вам попалась ONU, которая сама вставляет опцию 82 в DHCP пакет и отключить это невозможно, то OLT пропустит такой пакет дальше - следовательно DHCP сервер получит опцию 82, вставленную ONU-шкой, а она как правило содержит неправильные данные. По идее на любом управляемом L2 свиче можно указать, чтобы Опция 82 перезаписывалась, но P3310B такого не умел. Теперь умеет . Прошиваем ОЛТ новой прошивкой, в конфиге EPON порта прописываем dhcp snooping information replace . Кстати, также вышли новые прошивки для ONU 1004C1 и 1501C1. Прошивка для 1004С1 решает столь мелкие баги, что инженеры BDCOM не смогли вспомнить какие, а вот новая прошивка для 1501С1 решает баги с работой функций EPON FILTER и IP ACL. Все прошивки здесь https://www.dropbox.com/sh/l0u7nehcqlxfk6m/AAApv3GjPp7OgGNllR0H0Otla?dl=0 Также я напомнил BDCOM-у, что мы всё ещё ждём новую прошивку, в которой к одной ONU можно будет применять несколько шаблонов.
-
Вы скорость у них проверьте. Как вариант они работают на критически низкой скорости с огромным пингом.
-
Насколько мне стало известно на текущий момент из всех проданных FOR проблемными считаются около 5%. Конечно, это можно спихнуть на брак, но суть в том, что при перемещении ONU в другую ветку или на другую голову она может начать благополучно работать. В настоящий момент китайцы делают новую прошивку, которая будет сохранять на флэш память ONU отладочную информацию. Как только эта прошивка появится, я выложу её на наш Дропбокс.
-
FORA NA-1001B поддерживает FEC. Правда включать его нужно через Telnet. Я попросил китайцев реализовать включение через CLI OLT-а. В любом случае использовать FEC смогут только владельцы 36-ой серии ОЛТов от BDCOM-а. Модель 3310B FEC не поддерживает. Более того FEC сжирает около 18% пропускной способности. Мне кажется, что 30dB оптического бюджета для PON-а вполне достаточно. Кстати, ACL на FORах уже в разработке. Надеемся, что до китайского Нового Года наши заморские браться порадуют нас новой прошивкой.
-
Информация уточняется. команды точно не применяются с BDCOM-овской головы, но это мелочь, если сам функционал присутствует... а может быть и нет
-
Новая прошивка для FORA NA-1001B, решающая проблему с Option 82, выложена на дроп https://www.dropbox.com/sh/r35rr8qrh7dxygv/AABZRUkALVmufqJEHD6BmRmya?dl=0. Напомню, UImage шьём через веб морду, архив jffs2_fs.tar.gz - через CLI OLT-а (как говорится, кому как больше нравится).
-
Rate-limit - это полисинг, т.е. жёсткое обрезание трафика, ведущее к потерям пакетов. Шейпинг - обрезание трафика более мягкое (с использованием размера TCP окна... если я не прав, поправьте). Я всегда клиентам говорю, что на ONU есть шейпер, подразумевая SLA. Но на самом деле это никакой не шейпер. SLA определяет, какую пропускную способность (гарантированную (CIR) и пиковую (PIR)) может иметь ONU. Эта информация учитывается на стороне OLT-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ уже практически исчерпала значение PIR - в этом случае ОЛТ примет решение о выделении меньшего кванта времени, чем просит ОНУ. В итоге в буфере ОНУ пакеты будут накапливаться до тех пор, пока буфер не переполнится, а как результат - опять потеря пакетов.
-
Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию Rate-Limit на FORЕ я не проверял. Как мне кажется, она там лишняя.
-
В результате 86000 секунд прогона IPERF-ом в режиме FULL-DUPLEX TCP трафика через 2 ONU FORA NA-1001B (2 ПК подключёны к 2 Форам, 2 других - к GE портам ОЛТа), обе ОНУшки стабильно отработали. Суммарная скорость 2 потоков, пропущенных через ОЛТ, - 730/670 mbps. У меня закончились идеи, как можно нагнуть ФОРу и заставить её дерегистрироваться. Разве что дождаться поступления новой партии ФОР и включить в дерево их побольше. Мы так и не собрали статистику. Продано около 1000 ОНУ. Пока мы услышали о проблеме от 2-3 клиентов - это около 10-30 ОНУ. Где все остальные ? Неужели ещё не ставили форы "в бой"?
-
Я пока не буду делать никаких выводов, но наш стенд из 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-ов.
-
Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226! Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 15000 kbps, а немного поменьше.
-
Прошивку проверил. Всё пофикшгено. Опция добавляется. Remote ID и Circuit ID нужную информацию показываю. К сожалению, данная прошивка не является даже бета релизом, а сделана, как говорится, на коленках, поэтому в массы пока не пойдёт - я её у себя придержу. Как торлько появится нормальная версия прошивки, выложу её на наш дроп и отпишусь
