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 меняется на Not

На будущее учтём, но на текущий момент переделка пластиковой пресс-формы в Китае стоит более 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 Это, пожалуй, единственный баг, который найден на Форе и пока не поддаётся лечению. Правда варианта такого бага несколько: ОНУшка па

Я конечно всё понимаю. Все хотят оптический бюджет в 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 . Кстати,

Вы скорость у них проверьте. Как вариант они работают на критически низкой скорости с огромным пингом.

Насколько мне стало известно на текущий момент из всех проданных 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-а при выделении ОНУ квантов времени. Т.е. ОЛТ видит, что у ОНУшки буфер забит и ей необходимо выделить окно большого размера для передачи, но при этом ОНУ

Ну опять же, я не думал что кто-то будет использовать полисинг на ОНУ. Как правило скорость режут шейпером. Поэтому функцию 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 О

Немножко оффтопа. Если кто всречал подобную ошибку epon sla set failed,epon_sla_if,3226! Ошибка редкая, но означает она буквально следующее - суммарно ваши ОНУшки потребляют полосы пропускания больше, чем может выдать ОЛТ. Допустим, у Вас в ветке 64 ОНУ и на каждой настроен SLA с CIRом 15 mbps. Умножим 15 на 64 получаем, что ОЛТ гарантирует суммарную пропускную способность не меньше 960 mbps. Но проблема в том, что ОЛТ может гарантировать только около 950 mbps, остальное - служебный трафик. Таким образом, если у вас дерево забито до отказа и вы любитель использовать SLA, то ставьте CIR не 150

Прошивку проверил. Всё пофикшгено. Опция добавляется. Remote ID и Circuit ID нужную информацию показываю. К сожалению, данная прошивка не является даже бета релизом, а сделана, как говорится, на коленках, поэтому в массы пока не пойдёт - я её у себя придержу. Как торлько появится нормальная версия прошивки, выложу её на наш дроп и отпишусь