Перейти к содержимому
Калькуляторы

RU.PON (FAQ о ПОН на BDCOM и альтернативных ONU)

Кто нибудь использовал ону тп линк еп 110 с бдком? Как работает, есть ли баги?

Есть баги. И есть неисправимые пока пробелы в функционале.

 

Есть тест репорт. Хардваре и Софтваре.

Не в связи с ТПЛИНК, а скорее вообще в связи с чипсетом МТК

--- не рекомендую

При всем уважении к великой компании TPlink,

довольно часто, некотрые их проекты, в погоне за экономической эфективностью,

выходят откровенно UNUSABLE. Пример - веб смарт свитчи, особенно 2218.

 

 

Report TP-Link TL-EP110 HW

Report TP-Link TL-EP110 SW

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прописываю на онушке 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

 

в чем может быть проблема?

спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прописываю на онушке 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 порта.

У некоторых ОНУшек ВЛАН управления вообще отсутствует. Т.е. настроить его можно, но он всё равно не пингуется.

 

Также обратите внимание, что приведённые Вами команды нельзя использовать одновременно. Только одну из них. Если пропишите обе, то тоже пинговаться не будт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прошу прощения за тупой вопрос,но зачем вообще вланы на гепон? Я вот к примеру достал из коробки олт воткнул в стойку, включил порты и трафик побежал куда надо. У меня только инет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прошу прощения за тупой вопрос,но зачем вообще вланы на гепон? Я вот к примеру достал из коробки олт воткнул в стойку, включил порты и трафик побежал куда надо. У меня только инет.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Также интересно взглянуть на настройки 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Также интересно взглянуть на настройки 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 поставьте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я думал, что в 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
!

Изменено пользователем zurk

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А откуда Вы ОНУ пингуете? если с ОЛТа, то пинговаться должна. Если с компа, который в ОЛТ подключен, то нужно GE порт тоже в транк перевести.

Вы скажите, что за ОНУ - может она не умеет Management VLAN :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пингую с олта

ону bdcom P1004C1

 

Соль в том, что на столе я ее пинговал с компа, подключенного к ней (ону). Но, хоть убей, не помню пинговал я ее с олта или нет.

точно помню, что пинговалась при обоих способах настройки адреса

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пингую с олта

ону bdcom P1004C1

 

Соль в том, что на столе я ее пинговал с компа, подключенного к ней (ону). Но, хоть убей, не помню пинговал я ее с олта или нет.

точно помню, что пинговалась при обоих способах настройки адреса

 

Вы могли использовать 2 команды одновременно! После этого ОНу нужно перезагрузить, а ещё лучше нажать на ней Reset. У меня была такая ситуация при использовании обеих команд по настройке IP сразу.

Ставишь 2 команды - ОНУ больше не пингуется. Удаляешь одну команду - всё равно не пингуется. Пришлось ресетить - тогда заработало.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Top.jpg

1.jpg

 

Несколько месяцев назад компания 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-шек, поэтому введено программное ограничение. Жаль.

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Выдержка из теста

 

 

Выход модели BDCOM P3310C на смену "легендарного" P3310B сразу наталкивает на

ряд вопросов: "А что там с обратной совместимостью OLT-ов?", "А все ли старые

и новые BDCOM ONU будут работать с новым OLT-ом?", "А изменились ли команды в CLI?" и т.д.

 

В данном тесте мы постараемся ответить на эти вопросы. При этом мы не будет

тестировать L2 функционал OLT-а, т.к. он не изменился. Упор будет сделан на

тестировании работоспособности различных ONU.

 

2.jpg

 

Для ценителей подробных тест репортов далее по тексту будет подробно

описан механизм тестирования каждой из упомянутой в таблице функции на примере одной ONU.

 

 

Подключение и регистрация

 

 

Довольно часто при подключении ONU к дереву, процесс её регистрации занимает

много времени. Конечно, родных ONU-шек BDCOM это не касается, а вот альтернативные

ONU часто страдают таким "недугом" - время регистрации может доходить до 2х минут.

Крайне редко, но всё таки встречаются образцы, которые и нескольких секунд не

могут удержаться в дереве и после регистрации сразу же (или через несколько секунд)

дерегистрируются.

 

Как правило, это связано с рассогласованием таймеров протокола MPCP на самой ONU

и OLT-е. У наших же подопытных проблем с регистрацией не возникло. Все ONU

зарегистрировались в течение 12 секунд. Было бы странно, если бы у BDCOM ONU

возникли проблемы с регистрацией на BDCOM OLT-е.

 

3.jpg

 

 

DDM и базовая информация

 

 

Любая ONU, произведённая по стандартам CTC (China Telecom Corporation),

должна показывать базовую информацию о себе, а также диагностическую

информацию (DDM) с SFF модуля.

 

4.jpg

Комментировать здесь особенно нечего - необходимую информацию ONU показывает.

 

 

In-band Management VLAN

 

 

Данный функционал довольно спорный. Одним провайдерам VLAN управления на

ONU нужен, другим - нет. Чаще всего VLAN управления на ONU используется с 2 целями:

 

-обновление прошивки ONU через WEB интерфейс

-мониторинг активности ONU по средствам PING-а

 

У BDCOM OLT-ов существует 2 типа команд для настройки IP адреса

на ONU: Private OAM и CTC. Проверим обе.

5.jpg

 

Обе команды отработали исправно - ONU при этом пингуется.

 

Пропускная способность

 

Часто возникает ситуация, когда провайдер подключает к ONU не

конечного клиента, а какой-нибудь 8х, 16х или даже 24х портовый

коммутатор. В этом случае нужно быть уверенным, что ONU стабильно

работает на скоростях выше 100 mbps. Для проверки пропускной способности

воспользуемся утилитой IPERF (дорогущего Spirent SmartBits под рукой не оказалось).

 

IPERF-клиент запускается на ПК за ONU-шкой, а IPERF-сервер - на ПК за GE

портом OLT-а. Перед началом теста необходимо изменить настройки SLA на ONU,

т.к. по умолчанию максимальную пропускная способность ONU составляет 100 mbps.

Изменим её до 1G.

6.jpg

 

Далее проводим 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.

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Loop Back Detection (LBD)

 

 

LBD - одна из базовых функций, которая должна включаться на ONU по умолчанию.

Некоторые провайдеры её недооценивают и намеренно не включают. Однако первый

же шторм в сети из-за подгоревшего абонентского порта заставляет провайдеров

изменить своё мнение.

 

Включим LBD на UNI порту ONU и запустим сниффер пакетов WireShark.

7.jpg

 

8.jpg

Как видно из работы WireShark-а, каждые 2 секунды ONU отправляет широковещательный

пакет (TPID = 0xFFFE). Этот пакет и является пакетом LBD. Функционал работает.

 

 

Port Security

 

 

Port Security есть ни что иное как ограничение количества MAC адресов, которые

ONU может хранить. Данная функция используется довольно редко, однако в случае

сетевых атак типа MAC-Spoofing или DHCP Starvation она бывает крайне полезной.

 

Для начала ограничим размер MAC таблицы ONU до 5 MAC-ов.

9.jpg

 

Для проверки механизма Port Security мы будем использовать атаку DHCP Starvation,

суть которой заключается в отправке DHCP серверу большого количества запросов

от фейковых MAC адресов. В качестве утилиты, реализующей DCHP Starvation,

будем использовать DHCDROP.

10.jpg

 

Запускаем утилиту DHCDROP - пытаемся заполнить адресное пространство DHCP

сервера. В результате теста было выявлено, что для защиты от DCHP Starvation

и MAC Spoofing Port Security абсолютно бесполезен, если атака запущена в

режиме флуда. В этом случае PON чип OLT-а (Cortina CS8022) не успевает

блокировать лишние MAC-и и пропускает их дальше в сеть. Справедливости ради

надо отметить, что модель P3310B также не могла пройти данный тест.

 

Выход из этой ситуации один - обзвонить всех абонентов и попросить не запускать

сетевые атаки в режиме флуда, а только отдельными пакетами. А если серьёзно,

то Port Security можно включить непосредственно на UNI порту ONU - в этом

случае функция будет работать корректно.

11.jpg

 

Если запустить утилиту DHCDROP ещё раз в режиме флуда, то ONU передаст

пакеты с 4 новыми MAC-ами, а все остальные пакеты отбросит.

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

12.jpg

Итак, можно констатировать, что механизм Port Security справляется с возложенными

на него обязанностями, если знать, как правильно его включить.

 

Storm-Control

 

 

Данная функция также крайне полезна и может использоваться по умолчанию для

защиты сети от флуда со стороны клиента. Storm-control может работать в

нескольких режимах: ограничение широковещательных (broadcast), групповых (multicast)

пакетов, а также пакетов с неизвестным адресом получателя (unknown unicast).

Также есть режим, в котором ограничению подвергаются все вышеперечисленные пакеты

одновременно. Именно этот режим провайдеры используют чаще всего.

13.jpg

 

Мы включили на ONU Storm Control в 4-ом режиме ("фильтровать всё"), но формировать

будем только широковещательный шторм, т.к. он является наиболее актуальной

проблемой в сетях доступа.

 

Для формирования шторма нам подойдёт программа Ostinato, которая позволяет легко

задавать структуру пакетов и настраивать скорость их отправки.

14.jpg

 

Мы создали банальный 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 формат).

 

15.jpg

 

Посмотрим, что из этого вышло:

16.jpg

 

WireShark показывает, что опция 82 на месте - можно идти дальше.

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, в тексте написано, что FEC протестировать не получилось. Это не совсем так. Чуть позже мы выложим тест FEC-а.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

17.jpg

 

Режим 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.

18.jpg

 

Описывать процедуру тестирования смысла нет, т.к. она тривиальна, поэтому

просто констатируем, что ONU поддерживает все 3 режима обработки тэгов.

 

 

Multicast VLAN

 

 

Для провайдеров, которые предлагают своим клиентам услугу IP телевидения (IPTV),

важно, чтобы ONU умела обрабатывать мультикаст трафик. ONU должна принимать

мультикаст трафик только с определёнными VID (Multicast VLAN), снимать тэг с

трафика и отдавать поток на UNI порт.

 

В нашем случае мультикаст поток формируется самым варварским способом - при

помощи обычного VLC Player-а. В качестве клиентского софта используется всё

тот же VLC Player. Мультикаст будем транслировать в 1000-ом VLAN-е.

Показывать настройки OLT-а мы не будем, а вот настройки самой ONU

представлены ниже.

19.jpg

Тест на работу с мультикаст 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 имя не поменял.

20.jpg

В результате прошивка ONU прошла успешно.

 

 

Выводы

 

 

К сожалению, BDCOM не смог удивить своим решением. Он выпустил всё

тот же 3310B, но с новой аппаратной платформой, которая кроме FEC

ничего нового не умеет (да и его целесообразность под вопросом).

Хотелось бы со временем увидеть новую прошивку, которая позволит

раскрыть весь потенциал PON чипа Cortina CS8022 и регистрировать

до 128 ONU на порт. Если BDCOM-у это удастся, продажи данной

модели резко возрастут.

Futter.jpg

Скачать Отчет_BDCOM P3310C

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А с форами тест делали?

Кстати может в этом олт не будет проблем с отвалом чипа после отключения электричества

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А с форами тест делали?

Кстати может в этом олт не будет проблем с отвалом чипа после отключения электричества

 

Проблема отваливания PON чипа связана с подсыханием электролитов. Если на плате их все заменить, то PON чип перестаёт отваливаться. Как правило, профилактика по замене электрлитов нужна BDCOM-у раз в 2-3 года (у всех по-разному).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но для меня в подобной топологии остаётся несколько не ясных моментов:

- сколько желательно ставить 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 баксов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Top.jpg

 

Что такое 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. Собственно, вот что получилось.

 

1.jpg

 

Для точной настройки мощностей сигналов мы использовали LC и SC аттенюаторы.

В ONU включены аттенюаторы с суммарным затуханием - 25dB, в SFP CWDM - 29dB, в SFP OLT - 4 db.

 

Запускаем IPERF на 3 минуты в режиме Half-Duplex c выключенным FEC-ом:

 

2.jpg

 

Средняя скорость трафика ONU->OLT: 27.9 mbps, OLT->ONU: 721 mbps.

Результат слегка неожиданный. Медиаконвертер с SFP CWDM модулем сделал

детектирование сигнала затруднительным, поэтому скорость трафика опустилась

почти до нуля. Однако в обрутную сторону сигнал прошёл спокойно.

2-ой SFP OLT модуль не сильно повлиял на детектирование сигнала,

в результате чего мы имеем средню скорость 721 mbps.

 

Что касается ошибок на EPON порту ... 0 - их нет. Как мы ни старались,

статистика по порту постоянно показывала нулевые счётчики ошибок.

Это может говорить лишь об одном - софт OLT-а пока не "допилен".

 

Нововведением модели P3310C является возможность определения номера

ONU с постоянно включённым лазером. Скриншот ниже наглядно это демонстрирует.

Функция полезная, однако только в разрезе диагностики, есть засвет или нет.

Точно определить номер "светящей" ONU OLT не может, т.к. опредление основывается

на мощности сигналов, а в дереве могут быть несколько ONU со схожими показателями сигнала.

 

3.jpg

 

Включим FEC на ONU и OLT-е.

 

4.jpg

 

Еще разок прогоним трафик IPERF-ом:

 

5.jpg

 

Средняя скорость трафика ONU->OLT: 711 mbps, OLT->ONU: 841 mbps.

 

Выводы

 

Тесты показали, что FEC отлично справился с поставленной задачей. Он

позволил поднять скорость upstream-а с 27.9 до 711 mbps (2448%) и

downstream-а с 711 до 841 mbps (18%). При этом FEC не требует никаких

сложных настроек и долгих шаманских ритуалов с параметрами - его

достаточно включить и наслаждаться качеством его работы в "не качественной сети".

 

Скачать тест целиокм

Изменено пользователем wglazyrin

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Доброго времени суток, 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) И ещё такой вопрос, чтобы учесть все риски. Если каким-то "чудесным" образом я всё же сделаю кирпич во время перепрошивки, имеются ли способы "оживить мертвеца"? Если да, то каким образом это сделать? Хотелось бы подстраховаться от любой ситуации в предновогодние праздники =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нужно добавить в конфиг его ОНУ следующие строчки

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 мегабит.

 

То есть режем только ПИР.

Резать или не резать стрим на верх, можно понять, только зная вашу ситуацию.

 

В данном случае прошивка скорее всего вообще не причем.

Делать даунгрейд не нужно.

Когда и если вам это будет нужно, это тема для отдельного разговора,

там есть тонкости. Без надобности не стоит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какая крайняя рекомендуемая прошивка для P3310B ? И где ее взять?

Краяняя которая мне доступна: http://data.nag.ru/BDCOM/Firmware/3310B/P3310B_en_30847.rar

Изменено пользователем ShyLion

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Какая крайняя рекомендуемая прошивка для P3310B ? И где ее взять?

Краяняя которая мне доступна: http://data.nag.ru/BDCOM/Firmware/3310B/P3310B_en_30847.rar

 

У меня есть 31923. Вот только changelog BDCOM к ней не прилагает. Мол вот новая прошивка - пользуйтесь. Нужно у них будет уточнить, что за изменения.

На версии 29333 BDCOM сказал, что дальнейшая поддержка заканчивается и новых прошивок не будет. Затем появилась прошивка 30847 "якобы под конкретного клиента". Интересно, для кого BDCOM так старается, или

можно R&D заплатить немного денег и тогда поддержка продолжается полным ходом )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.