wglazyrin Опубликовано 14 декабря, 2015 (изменено) · Жалоба Кто нибудь использовал ону тп линк еп 110 с бдком? Как работает, есть ли баги? Есть баги. И есть неисправимые пока пробелы в функционале. Есть тест репорт. Хардваре и Софтваре. Не в связи с ТПЛИНК, а скорее вообще в связи с чипсетом МТК --- не рекомендую При всем уважении к великой компании TPlink, довольно часто, некотрые их проекты, в погоне за экономической эфективностью, выходят откровенно UNUSABLE. Пример - веб смарт свитчи, особенно 2218. Report TP-Link TL-EP110 HW Report TP-Link TL-EP110 SW Изменено 14 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurk Опубликовано 16 декабря, 2015 · Жалоба Прописываю на онушке IP, а она не пингуется, ни с олта, ни с подключенного к ней компа epon onu ctc ip address static 10.0.20.40 255.255.255.0 gateway 10.0.20.1 cvlan 1 svlan 0 priority 5 epon onu ip address static 10.0.20.41 255.255.255.0 gateway 10.0.20.1 vlan 1 в чем может быть проблема? спасибо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 16 декабря, 2015 · Жалоба Прописываю на онушке IP, а она не пингуется, ни с олта, ни с подключенного к ней компа epon onu ctc ip address static 10.0.20.40 255.255.255.0 gateway 10.0.20.1 cvlan 1 svlan 0 priority 5 epon onu ip address static 10.0.20.41 255.255.255.0 gateway 10.0.20.1 vlan 1 в чем может быть проблема? спасибо Некоторые ОНУ категорически отказываются работать в 1-ом ВЛАНе - попробуйте перенести в другой. Также интересно взглянуть на настройки EPON порта. У некоторых ОНУшек ВЛАН управления вообще отсутствует. Т.е. настроить его можно, но он всё равно не пингуется. Также обратите внимание, что приведённые Вами команды нельзя использовать одновременно. Только одну из них. Если пропишите обе, то тоже пинговаться не будт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
viper063 Опубликовано 16 декабря, 2015 · Жалоба Прошу прощения за тупой вопрос,но зачем вообще вланы на гепон? Я вот к примеру достал из коробки олт воткнул в стойку, включил порты и трафик побежал куда надо. У меня только инет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 16 декабря, 2015 · Жалоба Прошу прощения за тупой вопрос,но зачем вообще вланы на гепон? Я вот к примеру достал из коробки олт воткнул в стойку, включил порты и трафик побежал куда надо. У меня только инет. Если у Вас сеть состоит из одного ОЛТа и Микротика в качестве роутера, то можно и без ВЛАНов. А когда сетка разрастается, то приходится использовать ВЛАНы, чтобы сеть не засирать бродкастом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurk Опубликовано 17 декабря, 2015 · Жалоба Также интересно взглянуть на настройки EPON порта. interface EPON0/1 epon onu-authen-method mac epon bind-onu mac fcfa.f718.f5a6 1 epon bind-onu mac fcfa.f718.f734 2 switchport protected flow-control on Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 17 декабря, 2015 · Жалоба Также интересно взглянуть на настройки EPON порта. interface EPON0/1 epon onu-authen-method mac epon bind-onu mac fcfa.f718.f5a6 1 epon bind-onu mac fcfa.f718.f734 2 switchport protected flow-control on У Вас порт стоит в режиме Access, т.е. ждёт прихода не тэгированного трафика, а Вы ему трафик в первом ВЛАНе подсовываете - поэтому и не пингуется. Порт в Trunk поставьте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurk Опубликовано 17 декабря, 2015 (изменено) · Жалоба Я думал, что в 1 влане трафик итак ходит interface EPON0/1 epon onu-authen-method mac epon bind-onu mac fcfa.f718.f5a6 1 epon bind-onu mac fcfa.f718.f734 2 switchport mode trunk switchport protected flow-control on ! interface EPON0/1:1 onu-configuration epon onu ip address static 10.0.20.40 255.255.255.0 gateway 10.0.20.1 vlan 1 epon onu port 1 ctc loopback detect epon onu port 2 ctc loopback detect epon onu port 3 ctc loopback detect epon onu port 4 ctc loopback detect !!onu-configuration-end не помогло на онушках тоже с вланам колдовать тогда надо наверное? вот еще кусочек настроек interface VLAN1 ! ip default-gateway 10.0.20.1 ! spanning-tree mode rstp ! ip address 10.0.20.5 255.255.255.0 ! ! ! vlan 1 ! Изменено 17 декабря, 2015 пользователем zurk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 17 декабря, 2015 · Жалоба А откуда Вы ОНУ пингуете? если с ОЛТа, то пинговаться должна. Если с компа, который в ОЛТ подключен, то нужно GE порт тоже в транк перевести. Вы скажите, что за ОНУ - может она не умеет Management VLAN :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurk Опубликовано 17 декабря, 2015 · Жалоба пингую с олта ону bdcom P1004C1 Соль в том, что на столе я ее пинговал с компа, подключенного к ней (ону). Но, хоть убей, не помню пинговал я ее с олта или нет. точно помню, что пинговалась при обоих способах настройки адреса Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 17 декабря, 2015 · Жалоба пингую с олта ону bdcom P1004C1 Соль в том, что на столе я ее пинговал с компа, подключенного к ней (ону). Но, хоть убей, не помню пинговал я ее с олта или нет. точно помню, что пинговалась при обоих способах настройки адреса Вы могли использовать 2 команды одновременно! После этого ОНу нужно перезагрузить, а ещё лучше нажать на ней Reset. У меня была такая ситуация при использовании обеих команд по настройке IP сразу. Ставишь 2 команды - ОНУ больше не пингуется. Удаляешь одну команду - всё равно не пингуется. Пришлось ресетить - тогда заработало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 18 декабря, 2015 (изменено) · Жалоба Несколько месяцев назад компания BDCOM заявила, что она снимает с продажи так всем полюбившийся 4х портовый GEPON OLT BDCOM P3310B. При этом его старших братьев (OLT-ов 3608/3612/3616) пертурбации не коснутся. Чем вызвано такое решение, менеджеры компании BDCOM пояснить отказались, но уточнили, что на смену модели P3310B придёт её брат-близнец P3310C, поэтому переживать любителям 4х портовых PON решений не придётся - ниша пустовать не будет. Приведённое выше фото наглядно демонстрирует, что отличить модель C от B практически невозможно. Визуальное отличие только одно - наличие порта mini USB рядом с портом Console. Его предназначение пока остаётся загадкой. Можно лишь предположить, что порт служит для подключения внешних USB накопителей для смены прошивки OLT-а, не прибегая к помощи TFTP сервера. Но это выглядит чересчур оптимистично - скорее всего, это дополнительный консольный порт для владельцев консольного кабеля с mini USB. Как обычно бывает, самое интересное скрыто от глаз обывателя. Если вскрыть корпус OLT-а, то можно немного удивиться и одновременно огорчиться. PCB OLT-а стала субъективно меньше на 60-70%. Это вызывает только положительные эмоции - греться плата будет меньше. Но с другой стороны недоумение вызывает размер корпуса, который остался прежним. Корпус можно было уменьшить как минимум вдвое. Однако BDCOM пошёл по проторенной дорожке и не стал заказывать новый проект корпуса. Жаль - сэкономить на логистике не получится. Так что же случилось с платой? Почему изменился её размер? По заверениям R&D департамента компании BDCOM в связи с появлением на рынок более экономичных и эффективных SoC решений, проект PCB был переработан. Скорее всего, BDCOM позарился на дешевизну новых чипов, нежели на их энергоэффективность - максимальная потребляемая мощность OLT-а увеличились с 40W (модель P3310B) до 48W (модель P3310C). Т.к. отрывать радиаторы от главных чипов времени нет, то придётся поверить инженерам компании BDCOM. На месте главного Ethernet чипа красуется SoC решение от компании Broadcom - BCM53312S. Место PON чипа занимает Cortina CS8022. Но это всё сухие данные, которые никому особо не интересны. Что же может новый OLT? Революции ждать не приходится. Новая архитектура явно была призвана удешевить устройство, нежели увеличить его функциональность. При этом удешевление производства не привело к снижению входной цены на устройство. Другими словами, цена нового OLT-а осталась без изменения. Если рассматривать функциональность новой модели, то она тоже не изменилась - перед нами всё тот же P3310B, но с добавлением FEC (Forward Error Correction). FEC служит для снижения показателя BER (Bits Error Rate) и призван уменьшить влияние шума в канале связи на качество детектирования сигнала. Звучит заманчиво, однако проверить работу FEC у нас так и не получилось. Ещё одним приятным моментом нового OLT-а является увеличенный размер Flash памяти. Теперь он составляет около 16Mb. Наконец-то можно забыть те времена, когда для обновления прошивки ONU приходилось удалять c флэшки прошивку OLT-а (файл Switch.bin), т.к. файл с прошивкой ONU на флэшке не помещался. Также немалый интерес представляет сам PON чип Cortina CS8022. Он поддерживает 128 LLID, т.е. может регистрировать до 128 ONU. В спецификации к BDCOM P3310С указан Split-ratio = 64 , т.е. 64 ONU на порт. Возникает вопрос - BDCOM не хочет или не может обеспечить 128 ONU на порт. Возможно аппаратная платформа OLT-а попросту не справится с 512 абонентами. По заверениям самого BDCOM-а OLT 3310С может зарегистрировать 128 ONU на порт, но при этом может происходить потеря пакетов и даже дерегистрация ONU-шек, поэтому введено программное ограничение. Жаль. Изменено 18 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 18 декабря, 2015 (изменено) · Жалоба Выдержка из теста Выход модели BDCOM P3310C на смену "легендарного" P3310B сразу наталкивает на ряд вопросов: "А что там с обратной совместимостью OLT-ов?", "А все ли старые и новые BDCOM ONU будут работать с новым OLT-ом?", "А изменились ли команды в CLI?" и т.д. В данном тесте мы постараемся ответить на эти вопросы. При этом мы не будет тестировать L2 функционал OLT-а, т.к. он не изменился. Упор будет сделан на тестировании работоспособности различных ONU. Для ценителей подробных тест репортов далее по тексту будет подробно описан механизм тестирования каждой из упомянутой в таблице функции на примере одной ONU. Подключение и регистрация Довольно часто при подключении ONU к дереву, процесс её регистрации занимает много времени. Конечно, родных ONU-шек BDCOM это не касается, а вот альтернативные ONU часто страдают таким "недугом" - время регистрации может доходить до 2х минут. Крайне редко, но всё таки встречаются образцы, которые и нескольких секунд не могут удержаться в дереве и после регистрации сразу же (или через несколько секунд) дерегистрируются. Как правило, это связано с рассогласованием таймеров протокола MPCP на самой ONU и OLT-е. У наших же подопытных проблем с регистрацией не возникло. Все ONU зарегистрировались в течение 12 секунд. Было бы странно, если бы у BDCOM ONU возникли проблемы с регистрацией на BDCOM OLT-е. DDM и базовая информация Любая ONU, произведённая по стандартам CTC (China Telecom Corporation), должна показывать базовую информацию о себе, а также диагностическую информацию (DDM) с SFF модуля. Комментировать здесь особенно нечего - необходимую информацию ONU показывает. In-band Management VLAN Данный функционал довольно спорный. Одним провайдерам VLAN управления на ONU нужен, другим - нет. Чаще всего VLAN управления на ONU используется с 2 целями: -обновление прошивки ONU через WEB интерфейс -мониторинг активности ONU по средствам PING-а У BDCOM OLT-ов существует 2 типа команд для настройки IP адреса на ONU: Private OAM и CTC. Проверим обе. Обе команды отработали исправно - ONU при этом пингуется. Пропускная способность Часто возникает ситуация, когда провайдер подключает к ONU не конечного клиента, а какой-нибудь 8х, 16х или даже 24х портовый коммутатор. В этом случае нужно быть уверенным, что ONU стабильно работает на скоростях выше 100 mbps. Для проверки пропускной способности воспользуемся утилитой IPERF (дорогущего Spirent SmartBits под рукой не оказалось). IPERF-клиент запускается на ПК за ONU-шкой, а IPERF-сервер - на ПК за GE портом OLT-а. Перед началом теста необходимо изменить настройки SLA на ONU, т.к. по умолчанию максимальную пропускная способность ONU составляет 100 mbps. Изменим её до 1G. Далее проводим 30-минутный прогон синтетического трафика через ONU (сначала в режиме Half-Duplex, а затем в режиме Full-Duplex). >> iperf -c 192.168.1.77 -t 1800 -w 256k -r >> iperf -c 192.168.1.77 -t 1800 -w 256k -d В итоге на 100-мегабитной ONU можно добиться скорости порядка 95 mbps, а на 1G ONU - порядка 965 mbps. Даже при наличии профессионального оборудования для тестирования трафика добиться от ONU честного 1G не получится, т.к. часть канала съедает служебный трафик (MPCP и DBA). Пару слов стоит сказать про механизм DBA. Его предназначение - эффективно распределять пропускную способность канала в направлении ONU -> OLT. Благодаря грамотному распределению квантов времени среди ONU-шек, DBA позволяет заметно уменьшить задержки в сети. Проблема с этим механизмом заключается в том, что при базовых его настройках (рекомендуемых BDCOM-ом) сторонние (не BDCOM) ONU могут не регистрироваться на OLT-е или работать со сбоями. Для стабильной работы таких ONU параметры DBA на OLT-е приходилось менять. В 36-ой серии OLT-ов BDCOM пошёл на интересный шаг - убрал возможность изменять параметры DBA. Это привело к тому, что альтернативные ONU более уверенно работали на 3310B, а владельцам BDCOM OLT-ов 36-ой серии (3608/3612/3616) приходилось покупать родные BDCOM ONU либо углубляться в долгие поиски "альтернативки", стабильно работающей с дефолтными настройками DBA. К счастью любителей разводить зоопарк ONU-шек BDCOM P3310C имеет возможность редактировать настройки DBA. Изменено 18 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 18 декабря, 2015 (изменено) · Жалоба Loop Back Detection (LBD) LBD - одна из базовых функций, которая должна включаться на ONU по умолчанию. Некоторые провайдеры её недооценивают и намеренно не включают. Однако первый же шторм в сети из-за подгоревшего абонентского порта заставляет провайдеров изменить своё мнение. Включим LBD на UNI порту ONU и запустим сниффер пакетов WireShark. Как видно из работы WireShark-а, каждые 2 секунды ONU отправляет широковещательный пакет (TPID = 0xFFFE). Этот пакет и является пакетом LBD. Функционал работает. Port Security Port Security есть ни что иное как ограничение количества MAC адресов, которые ONU может хранить. Данная функция используется довольно редко, однако в случае сетевых атак типа MAC-Spoofing или DHCP Starvation она бывает крайне полезной. Для начала ограничим размер MAC таблицы ONU до 5 MAC-ов. Для проверки механизма Port Security мы будем использовать атаку DHCP Starvation, суть которой заключается в отправке DHCP серверу большого количества запросов от фейковых MAC адресов. В качестве утилиты, реализующей DCHP Starvation, будем использовать DHCDROP. Запускаем утилиту DHCDROP - пытаемся заполнить адресное пространство DHCP сервера. В результате теста было выявлено, что для защиты от DCHP Starvation и MAC Spoofing Port Security абсолютно бесполезен, если атака запущена в режиме флуда. В этом случае PON чип OLT-а (Cortina CS8022) не успевает блокировать лишние MAC-и и пропускает их дальше в сеть. Справедливости ради надо отметить, что модель P3310B также не могла пройти данный тест. Выход из этой ситуации один - обзвонить всех абонентов и попросить не запускать сетевые атаки в режиме флуда, а только отдельными пакетами. А если серьёзно, то Port Security можно включить непосредственно на UNI порту ONU - в этом случае функция будет работать корректно. Если запустить утилиту DHCDROP ещё раз в режиме флуда, то ONU передаст пакеты с 4 новыми MAC-ами, а все остальные пакеты отбросит. Изменено 18 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 18 декабря, 2015 (изменено) · Жалоба Итак, можно констатировать, что механизм Port Security справляется с возложенными на него обязанностями, если знать, как правильно его включить. Storm-Control Данная функция также крайне полезна и может использоваться по умолчанию для защиты сети от флуда со стороны клиента. Storm-control может работать в нескольких режимах: ограничение широковещательных (broadcast), групповых (multicast) пакетов, а также пакетов с неизвестным адресом получателя (unknown unicast). Также есть режим, в котором ограничению подвергаются все вышеперечисленные пакеты одновременно. Именно этот режим провайдеры используют чаще всего. Мы включили на ONU Storm Control в 4-ом режиме ("фильтровать всё"), но формировать будем только широковещательный шторм, т.к. он является наиболее актуальной проблемой в сетях доступа. Для формирования шторма нам подойдёт программа Ostinato, которая позволяет легко задавать структуру пакетов и настраивать скорость их отправки. Мы создали банальный 64-байтный широковещательный Ethernet кадр (Dst MAC + Src MAC + TPID + пустой Payload). Скорость отправки - 1000 pps. Если запустить Ostinato при отключенном Storm-Control-е, то OLT отображает в логах огромное количество ошибок. При этом нагрузка на процессор тоже возрастает. "Положить" OLT полностью за счёт флуда, конечно, не удастся, т.к. ONU не может передавать данные постоянно, однако заметно увеличить задержки в сети вполне возможно. Мы не ставим перед собой задачу оценить точность механизма storm-control, а просто проверяем - работает функционал или нет. Активируем Storm-Control c лимитом трафика в 256 kbps и заново запускаем Ostinato - теперь никаких ошибок OLT не показывает и нагрузка CPU (>> Switch# show cpu) остаётся неизменной. Storm-Control сделал своё дело. DHCP Snooping (Option 82) Большинства провайдеров, авторизующих клиентов по IPoE, используют Option 82 для привязки клиента к оборудованию провайдера. Поэтому умение OLT-а добавлять Option 82 к DHCP пакетам является крайне важным. Включим DHCP Snooping в первом VLAN-е и активируем Option 82 (Cisco формат). Посмотрим, что из этого вышло: WireShark показывает, что опция 82 на месте - можно идти дальше. Изменено 18 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 18 декабря, 2015 · Жалоба Кстати, в тексте написано, что FEC протестировать не получилось. Это не совсем так. Чуть позже мы выложим тест FEC-а. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 18 декабря, 2015 (изменено) · Жалоба 802.1Q Port-based VLAN Напомним, что UNI порт ONU может работать в нескольких режимах обработки VLAN-ов: Tag, Translation, Transparent, Vlan-stacking, Aggregation, Trunk, Private-trunk. Наверняка большинство читателей использовали только 3 режима (Tag, Trunk и Transparent). Смысл остальных режимов для большинства админов остаётся тайной. Режимы Translation и VLAN-Stacking - аналог QinQ, только в случае Translation один тэг меняется на другой, а в случае VLAN-Stacking к внутреннему тэгу добавляется ещё один (внешний). Зачем такой функционал нужен на абонентском устройстве - не ясно. Также до сих пор загадкой остаётся режим Aggregation. Режим Private-trunk появился только в этом OLT-е - в модели P3310B такого режима не было. Отличие данного режима от обычного trunk-а заключается в возможности подменять TPID кадра и задавать его приоритет. >> Switch_config_epon0/4:1#epon onu all-port ctc vlan mode private-trunk 200 1001,1002 8100 5 Как правило, провайдеры используют режим Tag (Access), реже - Trunk и Transparent. Поэтому мы не стали трогать остальные режимы, а провели проверку только этих 3. Описывать процедуру тестирования смысла нет, т.к. она тривиальна, поэтому просто констатируем, что ONU поддерживает все 3 режима обработки тэгов. Multicast VLAN Для провайдеров, которые предлагают своим клиентам услугу IP телевидения (IPTV), важно, чтобы ONU умела обрабатывать мультикаст трафик. ONU должна принимать мультикаст трафик только с определёнными VID (Multicast VLAN), снимать тэг с трафика и отдавать поток на UNI порт. В нашем случае мультикаст поток формируется самым варварским способом - при помощи обычного VLC Player-а. В качестве клиентского софта используется всё тот же VLC Player. Мультикаст будем транслировать в 1000-ом VLAN-е. Показывать настройки OLT-а мы не будем, а вот настройки самой ONU представлены ниже. Тест на работу с мультикаст VLAN-ом ONU прошла. Прошивка ONU через CLI OLT-a Ещё раз отметим, что на модели 3310C Flash память выросла до 16Mb, поэтому для загрузки прошивки от ONU на флэшку, не нужно удалять файл Switch.bin, как это было в модели 3310B. Также стоит обратить внимание на изменение набора файлов, хранящихся на флэшке. Теперь набор файлов пришёл к общему знаменателю с моделями OLT-ов BDCOM 36-ой серии. Прошивка PON чипа теперь называется tiger.blob (вместо olt.blob на модели B). Конфиг OLT-а теперь раздроблен на 2 части: конфиг самого OLT-а (startup-config) и конфиг ONU-шек (config.db). Файл Switch.bin имя не поменял. В результате прошивка ONU прошла успешно. Выводы К сожалению, BDCOM не смог удивить своим решением. Он выпустил всё тот же 3310B, но с новой аппаратной платформой, которая кроме FEC ничего нового не умеет (да и его целесообразность под вопросом). Хотелось бы со временем увидеть новую прошивку, которая позволит раскрыть весь потенциал PON чипа Cortina CS8022 и регистрировать до 128 ONU на порт. Если BDCOM-у это удастся, продажи данной модели резко возрастут. Скачать Отчет_BDCOM P3310C Изменено 18 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vinto Опубликовано 18 декабря, 2015 · Жалоба А с форами тест делали? Кстати может в этом олт не будет проблем с отвалом чипа после отключения электричества Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 18 декабря, 2015 · Жалоба А с форами тест делали? Кстати может в этом олт не будет проблем с отвалом чипа после отключения электричества Проблема отваливания PON чипа связана с подсыханием электролитов. Если на плате их все заменить, то PON чип перестаёт отваливаться. Как правило, профилактика по замене электрлитов нужна BDCOM-у раз в 2-3 года (у всех по-разному). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mefer Опубликовано 20 декабря, 2015 · Жалоба Но для меня в подобной топологии остаётся несколько не ясных моментов: - сколько желательно ставить FBT сплиттеров в каскад и какие за ними ставить PLC делители? - как правильно подобрать процентное соотношение FBT делителей в каскаде? - какие вообще процентные соотношения делителей бывают? Скажем, 47 на 53 есть, или только числа, кратные 5? Ну давайте разбираться от простого к сложному. 1) Китайцы теоретически могут сделать FBT с любым процентом деления. Но это в теории ))) На практике всё более приземлённо и перечень FBT сплитеров ограничен следующими позициями: 1/99 5/95 10/90 15/85 20/80 25/75 30/70 35/65 40/60 45/55 50/50 Причём, далеко не у всех продавцов есть весь перечень этих сплиттеров, т.к. держать на складе столько позиций не рационально. Зачастую, любую, даже самую извращённую ситуацию (ну как в Вашем случае), можно решить, имея сокращённый набор FBT делителей: 5/95 10/90 20/80 30/70 40/60 50/50 2) Если Вам нужен нестандартный делитель (например 3/97), то его можно заказать у китайцев, но ждать придётся пару месяцев, поэтому смысла в этом никакого нет. 3) Если говорить о том, сколько же этих самых делителей нужно, то тут многое зависит от района покрытия. Я редко использую шинную топологию в проектах, но, когда от "шины" не отвертеться, использую схему (7xFBT + 8xPLC1x8). Она подходит практически под любую задачу. по крайне мере, я ещё не сталкивался с картой, где бы эта схема была не применима. Схема проста: каскад из 7 FBT сплиттеров. К абонентскому выходу FBT сплиттера (т.е. к тому, у которого больше затухщание), подключаем PLC 1x8, а к магистральному выходу - вход следующего FBT сплиттера. 4) Как же выбирается номинал FBT сплиттера. У вас пришло волокно в первый узел ветвления. Вы знаете, что здесь будет стоять PLC 1x8, т.е. в этой точке будет подключено 8 ONU. Значит дальше (в следующих узлах суммарно будет подключено 56 ONU). Значит мы должны разделить сигнал так, чтобы у всех абонентов он был одинаковый. Значит FBT должен делить сигнал в соотношении 8 к 56. Делим 8 на 56 - получаем 0,14, т.е. 14%. Однако FBT 14/86 в продаже не найдёте, поэтому берёте наиболее близкий к этому значению - например 15/85. Далее алгоритм повторяется. Во второй точке нужно найти отношение 8 к 48 - это примерно 17%. Тут можно взять опять 15/85 или 20/80. Я предпочёл бы опять использовать 15/85, т.к. 17 всё таки ближе к 15, а не к 20. К тому же в "шине" есть негласное правило - стараться оставить побольше сигнала "дальним" абонентам. Ведь при расчёте процентовки я беру во внимание только затухание на сплиттерах, но не учитываю затухания на волокне, сварках, коннекторах. Конечно можно учитывать и их, но тогда расчёт будет значительно сложнее, но при этом не сильно изменит каскад FBT сплиттеров (если вообще изменит). Так вот, вернёмся к задаче. Первую FBT определили - 15/85, вторая FBT - тоже 15/85. Третья FBT будет иметь соотношение 8 к 40, т.е. 20/80 и т.д. Последним сплиттером в каскаде всегда будет 50/50. вот сейчас у меня в машине лежат сплиттера 1/99 , 2/98 , 3/97 не такие они и редкие. в итоге я их использую часто в начале дерева. Изначально делю сигнал на 2 равных плеча, дабы при большом количестве абонентов потом просто убрать сплиттер и подключить еще один порт. в итоге на выходе имею +2 дБ. далее первый сплиттер 1/99 на проход затухания мизерные, а на отвод получаю -18, что потом можно поделить еще на 4. при этом сразу на 4 не делю, пока нет еще одного абонента. вот как то так. да и вообще оптического бюджета реально портов на 200 хватает. надо понимать, что сигнал реально не избыточен, так как реальная плотность подключений не столь высока. иногда ставлю сплиттера 45/55 , хотя вот это уже редко. в случае чего-ты потом это замучаешься обслуживать. это необходимо если у тебя трасса километров 25-и через 500м ты вешаешь юзера.ну или ты оч жадный))хотя такие сплитты будут стоить больше чем сэкономленный кабель. Сплиттера 1 на 2 с любыми коэффициентами стоят одинаково. Сейчас около 4-5 баксов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 21 декабря, 2015 (изменено) · Жалоба Что такое FEC? FEC (Forward Error Correction) - техника кодирования и декодирования сигнала, призванная исправлять ошибки, возникающие при передачи данных в канале связи. FEC использует помехоустойчивый избыточный код Рида-Саламона 239B255B (239 байт в 255 байт). Провайдеру не нужно знать, как работает FEC - главное, что FEC спасёт его сеть, если она работает на грани оптического бюджета. Важно понимать, что FEC уменьшит пропускную способность канала примерно на 7% за счёт избыточного кодирования данных. Однако это не большая плата за более стабильный линк. BDCOM P3310C + FEC Т.к. на новом OLT-е BDCOM P3310C был реализован FEC, то сразу возникло желание провести эксперимент и проверить, так ли хорош FEC на самом деле и есть ли в нём смысл. Для проведения эксперимента нам понадобятся: OLT P3310С *Noname* ONU *Noname* Медиаконвертер под SFP *Noname* SFP CWDM 1310nm 80km *Noname* SFP OLT модуль (2 штуки) PLC Spliiter 1x2 FBT Splitter 1x2 40/60 LC и SC статические аттенюаторы Тест будет проводиться в 4 этапа: Собираем стенд, пытаясь добиться наихудшего качества сигнала, при котором ONU всё ещё может работать. Запускаем тест трафика утилитой IPERF и смотрим на количество ошибок на EPON порту. Включаем FEC на OLT-е и на ONU Ещё раз прогоняем синтетический трафик и смотрим количество ошибок. Этапы тестирования Для начала соберём стенд и попробуем "испортить" сигнал между ONU и OLT-ом в обе стороны. Мы должны добиться той ситуации, когда сигнал станет настолько низкий, что любое его понижение тут же приведёт к дерегистрации ONU. Однако этого мало. В сигнал необходимо добавить шум. Для этих целей параллельно ONU ставится ночной кошмар любого PON провайдера - медиаконвертер с 80-километровым SFP CWDM модулем на 1310нм. Мощность излучения такого модуля близка к мощности излучения ONU - 1.6 dBm. Однако на этом издевательства над сетью не закончены. Мы испортили только upstream сигнал. Для downstream-а мы поступим похожим образом - параллельно основному SFP OLT модулю мы включим ещё один, но в Ethernet порт. Таким образом, медиаконвертер с CWDM модулем с 2-ой SFP OLT модуль играют роль "зашумителей" сигнала. Для их подключения мы используем PLC 1x2 и FBT 1x2 40/60. Собственно, вот что получилось. Для точной настройки мощностей сигналов мы использовали LC и SC аттенюаторы. В ONU включены аттенюаторы с суммарным затуханием - 25dB, в SFP CWDM - 29dB, в SFP OLT - 4 db. Запускаем IPERF на 3 минуты в режиме Half-Duplex c выключенным FEC-ом: Средняя скорость трафика ONU->OLT: 27.9 mbps, OLT->ONU: 721 mbps. Результат слегка неожиданный. Медиаконвертер с SFP CWDM модулем сделал детектирование сигнала затруднительным, поэтому скорость трафика опустилась почти до нуля. Однако в обрутную сторону сигнал прошёл спокойно. 2-ой SFP OLT модуль не сильно повлиял на детектирование сигнала, в результате чего мы имеем средню скорость 721 mbps. Что касается ошибок на EPON порту ... 0 - их нет. Как мы ни старались, статистика по порту постоянно показывала нулевые счётчики ошибок. Это может говорить лишь об одном - софт OLT-а пока не "допилен". Нововведением модели P3310C является возможность определения номера ONU с постоянно включённым лазером. Скриншот ниже наглядно это демонстрирует. Функция полезная, однако только в разрезе диагностики, есть засвет или нет. Точно определить номер "светящей" ONU OLT не может, т.к. опредление основывается на мощности сигналов, а в дереве могут быть несколько ONU со схожими показателями сигнала. Включим FEC на ONU и OLT-е. Еще разок прогоним трафик IPERF-ом: Средняя скорость трафика ONU->OLT: 711 mbps, OLT->ONU: 841 mbps. Выводы Тесты показали, что FEC отлично справился с поставленной задачей. Он позволил поднять скорость upstream-а с 27.9 до 711 mbps (2448%) и downstream-а с 711 до 841 mbps (18%). При этом FEC не требует никаких сложных настроек и долгих шаманских ритуалов с параметрами - его достаточно включить и наслаждаться качеством его работы в "не качественной сети". Скачать тест целиокм Изменено 21 декабря, 2015 пользователем wglazyrin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 25 декабря, 2015 · Жалоба Доброго времени суток, wglazyrin!) Имеется OLT BDCOM P3310B и порядка 100 абонентских терминалов ONU BDCOM GEPON(P1004C1) и 1 абонентский терминал ONU BDCOM GEPON(P1501C1). Просто попался абонент, которого не устраивал тарифный план в 100Мбит, ему захотелось именно 150Мбит, от чего и была куплена ONU BDCOM GEPON(P1501C1), являющаяся гигабитной. Всё было хорошо, всё работало, не было никаких жалоб. Потом в виду необходимости было решено перепрошить данную OLT BDCOM P3310B, т.к. на старой прошивке обнаружился баг с отдачей информации по SNMP (По snmpwalk отдавались значения OID, а если запрашивать snmpget определённые OID, то писалось, что такого OID не существует). Хотя другие OLT BDCOM P3310P всё "хорошо" отдавали и подобных проблем не было. Единственное, чем они отличались от той, у "проблемного" BDCOM была старее прошивка, чем у всех остальных. До этого стояла 10.1.0B Build 21324; System Bootstrap 0.3.8 Обновил в итоге до 10.1.0B Build 30847; System Bootstrap 0.3.8 (Прошивку брал с data.nag.ru) Где-то читал, что от версии к версии может поменяться "синтаксис" команд, но я специально стянул конфиги до и после прошивки, а потом сравнил их с помощью diff, который показал лишь отличие в паре пустых лишних строк. Т.е. никакая часть конфига не была отвергнута. После обновления прошивки скорость у абонента с тарифом 150Мбит не превышала 95Мбит. Грешили сперва на сервер, т.к. в прошлом был подобный "момент" при самом старте заведения данного 150Мбит тарифа, но сервер тут ни при чём. Также пробовали заводить тестового пользователя с подобным тарифом и у него было всё хорошо (150Мбит), но эту проверку делал не "за EPON" оборудованием, а из-под обычного коммутатора доступа. Сегодня выяснилось, что подключаясь к коммутатору, к которому подключен OLT BDCOM P3310B - всё прекрасно, а если подключаться со стороны клиента, находящегося за epON, то скорость действительно не превышает 95Мбит/с. Пробовали и своим оборудованием - ничего не изменилось. Сигнал хороший. Увы, других ONU BDCOM GEPON(P1501C1) не имеем под рукой, абонент такой единственный. Абонент попался ещё "интересный" тем, что имел привычку делать замеры speedtest'a каждый день (не знаю зачем). По его замерам было брошено внимание, что в "день прошивки" всё и "перестало работать". Поэтому в данный момент грешу на новую прошивку OLT. Меня также смущает тот факт, что из-под OLT я не могу посмотреть скорость порта данной гигабитной ONU. Определяется как "Unknown", да и при конфигурирование порта я могу лишь выбрать между 10/100 и Auto. show epon interface epON 0/2:27 onu port 1 state Hardware state is Link-Up Speed is Unknown epon onu port 1 speed ? 10 -- Force 10 Mbps operation 100 -- Force 100 Mbps operation auto -- Enable AUTO speed configuration Так и должно быть? Или я чего-то не понимаю. Хотя линк действительно поднимается гигабитный при подключении нашего/клиентского оборудования к данной гигабитной ONU. Спасибо за прочтение моего потока сознания, постараюсь задать вопросы, к которым хотел подвести: 1) Действительно ли есть "подобный(ая) баг/фича" у данной прошивки? Или в прошивке не может быть "подобного"? 2) Хочу откатить прошивку, благо сохранил старую, но можно ли делать Downgrade на BDCOM P3310B? Часто читал, не буду искать источник "сплетен", что каждая прошивка ставит свой загрузчик, от чего нельзя будет "вот так просто" откатиться, не сделав из BDCOM кирпич. Как я вижу, то в точке "ДО" и в точке "ПОСЛЕ" версия BootStrap не изменилась, осталась 0.3.8., а значит я могу смело откатиться!? 3) И ещё такой вопрос, чтобы учесть все риски. Если каким-то "чудесным" образом я всё же сделаю кирпич во время перепрошивки, имеются ли способы "оживить мертвеца"? Если да, то каким образом это сделать? Хотелось бы подстраховаться от любой ситуации в предновогодние праздники =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wglazyrin Опубликовано 25 декабря, 2015 · Жалоба нужно добавить в конфиг его ОНУ следующие строчки Switch_config_epon0/3:1#epon sla downstream pir 1000000 cir 15000 Switch_config_epon0/3:1#epon sla upnstream pir 1000000 cir 15000 CIR - скорость зарезервированная на данного клиента "намертво" PIR - верхнее ограничение скорости отдельная строка на поток наверх и вниз текущие строки означают минимум 15мегабит, максимум 1000м(1Гигабит) Если у вас скорость режется выше, на роутере примените именно эти строки, тогда у него порт разблочится до гигабита, а роутер будет нарезать его тариф в 150м Если вы хотите зарезать его тариф на порте, отредактируйте строчки например так Switch_config_epon0/3:1#epon sla downstream pir 150000 cir 15000 Switch_config_epon0/3:1#epon sla upnstream pir 1000000 cir 15000 это скорость наверх на полную катушку скорость вниз минимум 15м максимум 150м В общем можете поиграться с этим командами, как вам надо НЕ рекомендую менять CIR Цифра в 15 мегабит = 1000/64 абонента По идее, при полной загрузке в 64 абонента, и одинаковой конкуренции всех стразу скорость не должна падать ниже15 мегабит. То есть режем только ПИР. Резать или не резать стрим на верх, можно понять, только зная вашу ситуацию. В данном случае прошивка скорее всего вообще не причем. Делать даунгрейд не нужно. Когда и если вам это будет нужно, это тема для отдельного разговора, там есть тонкости. Без надобности не стоит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 25 декабря, 2015 (изменено) · Жалоба Какая крайняя рекомендуемая прошивка для P3310B ? И где ее взять? Краяняя которая мне доступна: http://data.nag.ru/BDCOM/Firmware/3310B/P3310B_en_30847.rar Изменено 25 декабря, 2015 пользователем ShyLion Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 25 декабря, 2015 · Жалоба Какая крайняя рекомендуемая прошивка для P3310B ? И где ее взять? Краяняя которая мне доступна: http://data.nag.ru/BDCOM/Firmware/3310B/P3310B_en_30847.rar У меня есть 31923. Вот только changelog BDCOM к ней не прилагает. Мол вот новая прошивка - пользуйтесь. Нужно у них будет уточнить, что за изменения. На версии 29333 BDCOM сказал, что дальнейшая поддержка заканчивается и новых прошивок не будет. Затем появилась прошивка 30847 "якобы под конкретного клиента". Интересно, для кого BDCOM так старается, или можно R&D заплатить немного денег и тогда поддержка продолжается полным ходом ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...