Проблема со скоростью аплоуда у клиентов на BDCOM GP3600-08

[ISK 259]

20 часов назад, mpolk сказал:

Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару дней он уже будет красоваться на Shodan-е, а на третий день добрые люди запишут его в свой ботнет и пристроят к хорошему делу - DNS-amplification-ом заниматься

То есть NAT уже как бы не в моде?

 

20 часов назад, mpolk сказал:

Так там не то, что все клиенты отваливались, там ОЛТ в синюю асфиксию впадал необратимо. Случись это не на стенде, а в природе, я даже и не знаю, как бы я это восстанавливал.

Вот именно об этом я и хотел сказать. К выбору ОНУ нужно подходить вдумчиво и не жалея средств, иначе данный сценарий когда-то да случится.

 

P. S.: И да, отговаривайте абонов от необдуманных покупок говнороутеров меркусис, которые как раз такие проблемы в виде петель и создают. Я уже писал про это в другой теме…

[nedoinet 440]

25 минут назад, ISK сказал:

и не жалея средств

ну вот честно при их-то стоимости там и извращаться с экономией особо не надо. ц-дата/стелс 11-12 бакинских в рознице. базовый функционал с лупами и sla отрабатывают.чего там выдумывать. хотя есть черти покупающее дремучее б/у овно видевшее мамонтов и нечто нихера непонятное.

Відредаговано 2019-11-23 12:27:09 nedoinet

[ISK 259]

2 часа назад, nedoinet сказал:

хотя есть черти покупающее дремучее б/у овно видевшее мамонтов и нечто нихера непонятное.

Да, да, я именно об этом, коллега… Хоть кто-то понимает эту боль и печаль…

Відредаговано 2019-11-23 15:09:51 ISK

[NaviNavi 86]

3 часа назад, nedoinet сказал:

ну вот честно при их-то стоимости там и извращаться с экономией особо не надо. ц-дата/стелс 11-12 бакинских в рознице. базовый функционал с лупами и sla отрабатывают.чего там выдумывать. хотя есть черти покупающее дремучее б/у овно видевшее мамонтов и нечто нихера непонятное.

каждый смотрит из своей колокольни. Не хочет народ покупать новое за 11-12 бакинских, он берет за 30 и ипется с ним

[nedoinet 440]

1 час назад, NaviNavi сказал:

он берет за 30

За 30 чего? Ну ладно я пойму покупать на хреновые ветки б.у. брендовые зте тех ревизий, которые светят +4 дбм. А так извиняюсь в розницу тк-линк епон на чипах зте поштучно 275грн, а оптом дешевле в зависимости от кол-ва... Пистец...

Пы.сы. когда спрашивают что купить(роутеры) я отвечаю - то что стоит свыше 40 баксов по среднему ценнику, а там что понравится.

Відредаговано 2019-11-23 17:26:19 nedoinet

[ISK 259]

18 часов назад, nedoinet сказал:

Пы.сы. когда спрашивают что купить(роутеры) я отвечаю - то что стоит свыше 40 баксов по среднему ценнику, а там что понравится.

Да Вы везунчик, у Вас хотя бы спрашивают)

[nedoinet 440]

2 часа назад, ISK сказал:

Да Вы везунчик, у Вас хотя бы спрашивают)

Я не работаю в провайдинге, так иногда подрабатываю. Поэтому спрашивают-то в основном знакомые. А аборигенам в принципе нереально донести суть, что не все китайское оборудование одинаково полезно. 

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

Mercusys MW305R and MW325R

V1:

CPU: Mediatek MT7620N
Flash Mem: 2MiB
RAM: 16MiB
10/100: 4ports + WAN ( MT7620N switch)
2X2 Mimo b/g/n (MT7620N) - 2 antenna

 

V2:

CPU: Mediatek MT7620N
Flash Mem: 2MiB
RAM: 16MiB
10/100: 3ports + WAN ( MT7620N switch)
2X2 Mimo b/g/n (MT7620N) - 3x antenna

 

MW325R

CPU: Mediatek MT7620N
Flash Mem: 2MiB
RAM: 16MiB
10/100: 3ports + WAN ( MT7620N switch)
2X2 Mimo b/g/n (MT7620N) - 4x antenna

 

Вот как это можно назвать роутером? 16МБ озу...впритиррчку шоб крутить кастрированую(другая на 2МБ флеша не влезет) мтк-шную сдк...а потом что ж его так корячит...

Відредаговано 2019-11-24 13:33:36 nedoinet

[ISK 259]

52 минуты назад, nedoinet сказал:

Вот как это можно назвать роутером? 16МБ ...впритиррчку шоб крутить кастрированую мтк-шную сдк...а потом что ж его так корячит...

Буэ-э-э!… Вот, теперь вроде полегчало. Нет, это не роутеры, это что-то другое… В другой теме уже писал о них, да…

Відредаговано 2019-11-24 13:24:09 ISK

[mpolk 22]

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

0) Исходное состояние: еще в ночь с четверга на пятницу в общеклиентский rate-limit-профайл прописаны дефолтные значения (pir 1244160 cir 1244160), все это записано а в startup-config и ОЛТ перезагружен с этим конфигом. Уже тогда были предварительные данные, что аплоуд с таким конфигом будет хороший (85Мбит/с).

 

1) В субботу утром подключаемся и начинаем мерить. Действительно, 85 Мбит/с. На разных ОНУшках. (Как потом выяснилось, 85Мбит/с - это потолок аплоуда для нашего тестового ноутбука с его встроенной сетевухой и "оптимизированной" народными умельцами Windows 10). Счастье, вот оно. Мы нашли команду, которая все портила (спасибо @sanyadnepr). Просыпается оптимизм, вкус к жизни и желание поэкспериментировать. А теперь попробуем проверить гипотезу @foreverok, что излишний cir приносит вред.

 

2) Создаем тестовый rate-limit-профайл с pir 1244160 cir 10000. Удаляем ссылку на текущий rate-limit-профайл из рабочего virtal-port-профайла. А сейчас мы туда поставим ссылку на тестовый профайл с умеренным cir-ом. Ой, звук пропал... ОЛТ куда-то ушел... На телнет не реагирует, на пинги не отвечает. В принципе дело знакомое, ОЛТ так уходит в себя, когда массово переконфигурирует ОНУшки. Сейчас, правда, его никто об этом не просил. Видно сам решил. Подождем, он минуты чрез 3-4-5 должен вернуться.

 

Действительно, вернулся. Продолжаем с того места, где остановились. Назначаем тестовый rate-limit-профайл. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 35Мбит/с... Ах ты ж зараза!

 

3) Поднимаем cir до старого (предположительно, неверного) значения 100000. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 25Мбит/с...

Выставляем pir, равным cir, т.е. 100000. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 30Мбит/с...

Пытаемся постепенно поднять pir до дефолтного значения 1244160, при котором все было хорошо. 200000. Меряем. 35Мбит/с...

400000. Меряем. 20Мбит/с...

800000. Меряем. 35Мбит/с...

1200000. Меряем. 25Мбит/с...

Возвращаем дефолтный профайл (pir 1244160 cir 1244160), на котором мы видели 85Мбит. Меряем. 20Мбит/с...

В отчаянии перегружаю ОЛТа, не сохраняя конфига, надеясь вернуть его к начальному состоянию, которое было утром, когда и аплоуд был 85.

Меряем. 50Мбит/с. Занавес.

 

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

 

1) В принципе, направление изысканий правильное, крутить надо rate-limit-профайлы. Хотя, возможно, не только их: tcont-профайлы содержат аналогичные параметры. Чем один профайлы отличаются от других и как они взаимодействуют - в этом еще разбираться и разбираться.

 

2) ОЛТ безусловно понимает параметры этих профайлов каким-то извращенным образом. Возможно, на самом деле, вредный вклад в его образ действий вносит тот факт, что суммарный cir в rate-limit-ах превышает физическую пропускную способность канала. Теоретически этот вред не должен проявляться, пока не достигнуто насыщение физики, но на практике, в исполнении китайского ОЛТа, можно ожидать чего угодно. Так что cir-ы, вероятно, стоит отрихтовать.

 

3) Мало того, что реальное состояние параметров восходящих шейперов/полисеров хранится в системе "конфиг ОЛТа + кэш конфигов ОНУшек (т.е. sqlite-овый config.db) + рантаймовые конфиги ОНУшек". К тому же и синхронизация этих параметров, похоже, триггерится не только командами конфигурирования ОНУшечных сабинтерфейсов (типа GPON0/1:2), как мне казалось. Но также и какими-то командами изменения профайлов, где-то на их многочисленных уровнях косвенных ссылок. Это судя по тому, как ушел от меня ОЛТ в начале эксперимента.

 

4) Чтобы разобраться, как работает весь этот кошмар а-ля "волновая функция вселенной", нужно иметь гораздо более глубокое знакомство с БДКомо-ЖПОНовой кухней, чем у меня сейчас имеется. Эпизодическими измерениями с привлечением монтажников не обойдешься.

 

Строим стационарную тестовую точку с дистанционным управлением на территории лояльного клиента. И тогда продолжим...

Відредаговано 2019-11-24 15:17:24 mpolk

[mpolk 22]

Для тех, кому интересно, описываю дальнейший ход изысканий.

 

Были организованы две тестовых точки:

 

1) Автономно работающий ноутбук с Линуксом, автоматически подключающийся к серверам доступа через PON-сеть (через 1-й порт ОЛТ-а). На нем установлен iperf3, с помощью которого можно тестировать скорость аплоуда между ноутбуком и сервером доступа, к которому он в данный момент подключен. Данная точка размещена у одного из клиентов, с которым имеется договоренность на этот счет.

 

2) ОНУ-шка, подключенная прямо к порту ОЛТ-а (в данный момент к тому же 1-у порту) через асимметричный сплиттер 5/95 (по совету @nedoinet). Эзернет-порт ОНУ-шки подключен к домовому свичу и далее, специально организованным транзитным ВЛАНом, выведен «обратным ходом» снова на сервера доступа. Таким образом, можно, запуская на одном из серверов доступа PPPoE-клиента, подключаться к другому серверу и тестировать скорость iperf-ом.

 

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

 

Кроме того, я за последнюю неделю самостоятельно провел серию изысканий с помощью вышеописанных тестовых точек (по ночам, чтобы меньше мешать клиентам).

 

Исследования проводились по следующей схеме: я отключал часть клиентских ОНУ-шек от PON-сети (с помощью команды «gpon onu disable» на соотв. подинтерфейсе) и измерял скорость аплоуда (и даунлоуда) на обеих тестовых точках. Потом разрешал этим ОНУ-шкам снова подключиться, отключал следующие и т. д. Также я проверял эффект полного тушения порта с отключением всех клиентов (командой shutdown на GPON-интерфейсе) и эффект перезагрузки ОЛТа.

 

Кроме того, я пытался менять ограничения скорости аплоуда (cir и pir) в «onu rate-limit profile». Как выяснилось, эти изменения не влияют (по крайней мере прямо) на ситуацию (см. ниже), поэтому я вернул профиль к исходному состоянию. Результаты исследований приведены ниже:

 

1. Скорость аплоуда в обеих тестовых точках практически одинакова (с точностью до 1 Мбит/с). Она может меняться в зависимости от ситуации (см. ниже), но между двумя точками разницы в скорости аплоуда нет никогда (пока точки подключены к одному и тому же порту). Это при том, что уровень сигнала на порту ОЛТ равен примерно -26 dBm для первой точки и -9 dBm для второй.

 

2. Скорость даунлоуда в обеих точках также одинакова между собой с точностью до 1 Мбит/с и, кроме того, не зависит от ситуации. Она всегда равна 92-93 Мбит/с и определяется возможностями тестового оборудования и 100-Мбитного эзернет-подключения.

 

3. Сразу после поднятия GPON-порта на ОЛТ-е (неважно, какой ход событий предшествовал и привел к этому поднятию: shutdown порта, перезагрузка ОЛТ-а или запрет всех ОНУ-шек, зарегистрированных на порту) ОЛТ устанавливает одинаковую максимальную скорость аплоуда для всех ОНУ-шек на порту. Или, может быть, не для всех, но на тех двух ОНУ-шках, за которыми я мог наблюдать, эта скорость всегда была одинаковой. Значение этой максимальной скорости, похоже выбирается случайно, хотя возможно ОЛТ и имеет на этот счет какие-то неизвестные мне соображения. Я наблюдал значения в интервале от 50-и до 80-и Мбит/с.

 

4. Далее, если ОЛТ и ОНУ-шки оставить в покое и ограничиться пассивными замерами скорости, то обнаружится, что скорость аплоуда будет постепенно расти, оставаясь при этом одинаковой для двух тестовых точек. Рост продолжается, пока не будет достигнут предел в 93 Мбит/с, определяемый, как я уже писал, возможностями тестового оборудования. Время, необходимое для восстановления скорости аплоуда до номинальной величины, в разных случаях разное и, похоже, не коррелирует с начальной скорость аплоуда. Мне приходилось наблюдать временные интервалы от 6-и часов до двух с половиной суток. Детальный характер роста скорости (плавно, скачками или еще как-то) мне определить не удалось.

 

5. Дальше, скорость аплоуда будет оставаться на этом уровне, пока не произойдет следующее падение порта или массовое переподключение ОНУ-шек (например, при их массовом переконфигурировании). После этого будет установлено новое случайное значение скорости и все повторится снова.

 

6. Если в период от поднятия порта до достижения номинальной скорости аплоуда отключить от порта одну или несколько ОНУ-шек (командой «gpon onu disable»), то скорость аплоуда на остальных ОНУ-шках возрастает. Степень возрастания скорости зависит как от количества отключаемых ОНУ-шек, так и от их «качества». Т.е. некоторые ОНУ-шки при отключении вносят больший вклад в увеличение скорости аплоуда, чем другие. «Качество» ОНУ-шек никак не коррелирует с уровнем сигнала на на этих ОНУ-шках. В то же время, «качество» ОНУ-шки является параметром постоянный, т. е. при повторных отключениях каждая ОНУ-шка вносит тот же самый вклад в улучшение скорости аплоуда, что и во время предыдущих попыток.

В зависимости от «качества» отключаемых ОНУ-шек может потребоваться отключение от 2-х до 6-и единиц ОНУ для достижения номинальной скорости аплоуда в 93 Мбит/с.

 

7. После возвращения отключенных ОНУ-шек в строй скорость аплоуда снова падает. Как правило, она падает до того же уровня, который наблюдался до отключения ОНУ‑шек. Но довольно часто, скорость аплоуда после отключение оказывается немного (на несколько Мбит/с) выше, чем она была до отключения. Таким образом, эксперименты с отключением ОНУ-шек приводит к ускорению процесса возвращения скорости аплоуда к номинальной величине.

 

Есть подозрение, что и «естественный» процесс подъема скорости аплоуда до номинальной величины движется за счет «естественных» событий подключения/отключения клиентских ОНУ-шек.

 

8. Как оказалось, мои предыдущие манипуляции с параметрами cir и pir в rate-limit-профиле - все это к причинному месту двери. Единственный видимый эффект от них состоит в том, что изменение этих параметров (или параметров в любом другом onu-профайле) вызывает отключение и переконфигурирование ОНУшки или ОНУшек, в которых этот профайл задействован. Если профайл "глобальный", т.е. задействован во всех или в многих ОНУшках, то произойдет массовое переподключение, которое повлечет за собой события, описанные выше. Переконфигурирование ОНУшки(ОНУшек) триггерится в некоторых случаях непосредственно изменением в профайле, на который ссылается ОНУшка, а других - по команде "exit" после внесения изменений в профайл.

 

Таким образом, складывается устойчивое впечатление, что заниженная скорость аплоуда определяется не какими-то настройками QoS в конфиге (правильными или неправильными), а неправильным распределением ОЛТ-ом восходящей полосы пропускания, вызванным ошибочным расчетом этого распределения ОЛТ-ом в момент поднятия линка на порту. Со временем (возможно, по мере переподключения ОНУ-шек) ОЛТ корректирует свои расчеты, и скорость приходит в норму.

 

Если это предположение верно, то проблема может быть решена только силами разработчиков ПО ОЛТ-а. Ждем фидбэка от них.

[nedoinet 440]

59 минут назад, mpolk сказал:

. Степень возрастания скорости зависит как от количества отключаемых ОНУ-шек, так и от их «качества». Т.е. некоторые ОНУ-шки при отключении вносят больший вклад в увеличение скорости аплоуда, чем другие. «Качество» ОНУ-шек никак не коррелирует с уровнем сигнала на на этих ОНУ-шках

Еще добавлю еще варианты. Корявые онушки или корявые или святищие онушки. Было недавно дело чувак мучался на епоне. После прохода по всем абонам найдено 4 светящих онушки на ветке из 45.

При чем степень жопы зависила от количества ону в онлайне

[mpolk 22]

И так, проблема, наконец, была решена (если это кому-нибудь еще интересно).

 

Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик iperf-а в обход PPPoE и перебирая все известные им способы не заниматься проблемой напрямую. Наконец, мне была дана Скайп-аудиенция с младшим чиновником провинции Фу Цзянь по делам серверных варваров.

 

Чиновник оказался женска полу: ко мне вышла девушка в огромных очках и с длинными волосами, как в фильме "Шанхайский дракон 4" (если, конечно, верить аватарке) и показала настоящее кунг-фу. Пять минут она выслушивала мою челобитную, потом пять минут думала, потом три минуты копалась в недрах ОЛТа (ей был дан удаленный доступ) и потом спросила примерно так:

 

- You have 90Mbit/s now. You are happy?

 

- O-o-h! I am happy. What did you do?

 

- You see this command in your TCONT profile:

 

gpon profile onu-tcont tcont-general id 2
 gpon-profile tcont-type 3 pir 100032 cir 8192
 gpon-profile alloc-type nsr

Remember this command, use it in your life, reboot your ONUs and be happy. Go your way.

 

(Честно говоря, девушка еще пояснила мне, что эта команда, она ... "the command NSR of the tcont profile ,it means the onu only need care about the bandwidth for itself.it will not effection other onu in the same pon port". На самом деле, команда по-видимому, переводит механизм DBA в режим non-status-reporting. И ведь с самого начала я предполагал, что проблема в DBA).

 

С тех пор у моих клиентов хороший аплоуд, а я хожу просветленный, мечтаю снова встретить ту девушку и очень не люблю ДЕПС.

[Zlobar 30]

Вау, треба перевірити вживу, є одна гілка дуже схожа!

[trsnah 9]

32 минуты назад, mpolk сказал:

мечтаю снова встретить ту девушку и очень не люблю ДЕПС.

Ну я уже месяц у ДЕПСа выбиваю ОИД, для снятия МАК адресов с ОНУшек (конечно мне кажется, что его даже не существует). Но тем не менее, мне дают не рабочие ОИДы и так по сей день ...

Я уже даже Вендору написал =)

Відредаговано 2020-01-17 10:26:28 trsnah

[mpolk 22]

23 минуты назад, trsnah сказал:

Ну я уже месяц у ДЕПСа выбиваю ОИД, для снятия МАК адресов с ОНУшек (конечно мне кажется, что его даже не существует). Но тем не менее, мне дают не рабочие ОИДы и так по сей день ...

Я уже даже Вендору написал ?

А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?

Відредаговано 2020-01-17 10:48:28 mpolk

[trsnah 9]

7 минут назад, mpolk сказал:

А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?

Работает и в принципе меня устраивает, но к сожалению, мои навыки внедрения слишком низки, чтоб использовать этот способ в PonMonitor от Виталия Моисеева ?

[andryas 1 059]

1 час назад, mpolk сказал:

И так, проблема, наконец, была решена (если это кому-нибудь еще интересно).

 

Не використовую цього пристрою, принаймні, поки що, але висловлюю свою повагу, за те що рішення проблеми опубліковане.

До речі, як себе показує це обладнання у плані стабільності?

[mpolk 22]

32 минуты назад, andryas сказал:

 

Не використовую цього пристрою, принаймні, поки що, але висловлюю свою повагу, за те що рішення проблеми опубліковане.

До речі, як себе показує це обладнання у плані стабільності?

 

В плане стабильности у него все вроде бы в порядке.

 

Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в поле и засунут в ящик на чердаке. Живых пациентов мы к нему по-моему еще не подключали, просто хотели посмотреть, как на него свежий воздух подействует и бодрящая атмосфера летнего чердака в хрущовке.

 

Примерно через сутки ОЛТ исчез с экранов радаров и больше не появлялся. Его вытащили из ящика и положили на анатомический стол. Вскрытие показало, что перед смертью покойник сильно потел и стер себе содержимое флэшки, так что грузиться ему было уже неоткуда. Возникла гипотеза, что ОЛТ не любит жары, но ДЕПС уверил, что эти ОЛТы и не такую температуру с легкостью выдерживают, и что это первый такой случай в их практике. Мы поверили, восстановили прошивку (уже не помню как) и вернули ОЛТа на чердак. Там он с тех пор и работает без каких-либо нареканий (не считая проблемы, описанной в данной теме).

 

Но запасной экземпляр мы на всякий случай держим.

 

Главная проблема с этим железом - отсутствие нормальной документации. Из документации есть только:

1) 22 тома наставлений от БДКома про "свичи вообще", где описано, как свичи перезагружать и смотреть на них время. Про GPON там сказано только то, что, чтобы посмотреть посмотреть информацию об ОНУшках, надо прямо так и сказать: show gpon onu-info. И т.п.

 

2) "Малая книга заклинаний" от ДЕПСа. По объему и информативности примерно соответствует двум страницам из рукописи Войнича, только без картинок. Если этих заклинаний не хватает, то надо просить аудиенции у Вендоров (см. выше).

Відредаговано 2020-01-17 11:50:09 mpolk

[b.and 7]

11 минут назад, mpolk сказал:

Мы поверили, восстановили прошивку (уже не помню как) и вернули ОЛТа на чердак. Там он с тех пор и работает без каких-либо нареканий (не считая проблемы, описанной в данной теме)

не совсем так, мы поставили на чердак запасной, а с восстановленной прошивкой стоит на стапеле