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

[mpolk 22]

4 часа назад, andruxovich сказал:

Если боязно - тогда через вебморду reset к заводским настройкам. Но, можно также удалить startup-config и config.db , перезагрузить и все будет хорошо. 

Ну тогда следующей ночью так и попробую.

[sanyadnepr 305]

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

Да я понимаю, что беда где-то в этой области: cir/pir/shaper/policer и т.п.. Так прямо сразу и написал.

!
gpon profile onu-rate-limit 100M id 2
 gpon-profile pir 100000 cir 100000
!
gpon profile onu-virtual-port virtual-port-default id 1
 gpon-profile encryption disable
 gpon-profile upstream queue 8
 gpon-profile upstream rate-limit-profile ratelimit-default
 gpon-profile downstream queue 8
!
gpon profile onu-virtual-port vport-general id 2
 gpon-profile encryption disable
 gpon-profile upstream queue 8
 gpon-profile upstream rate-limit-profile 100M
 gpon-profile downstream queue 8
 gpon-profile downstream rate-limit-profile 100M
!

1. Зачем эти строки в конфиге ? Зачем используется рейт-лимит ? Если его убрать, будут улучшения ?

2. Уровни сигналов всех ону мин-макс какие ?

3. sh run int ошибки есть ?

 

Сервер для измерения подключить напрямую в ОЛТ.

[mpolk 22]

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

!
gpon profile onu-rate-limit 100M id 2
 gpon-profile pir 100000 cir 100000
!
gpon profile onu-virtual-port virtual-port-default id 1
 gpon-profile encryption disable
 gpon-profile upstream queue 8
 gpon-profile upstream rate-limit-profile ratelimit-default
 gpon-profile downstream queue 8
!
gpon profile onu-virtual-port vport-general id 2
 gpon-profile encryption disable
 gpon-profile upstream queue 8
 gpon-profile upstream rate-limit-profile 100M
 gpon-profile downstream queue 8
 gpon-profile downstream rate-limit-profile 100M
!

1. Зачем эти строки в конфиге ? Зачем используется рейт-лимит ? Если его убрать, будут улучшения ?

2. Уровни сигналов всех ону мин-макс какие ?

3. sh run int ошибки есть ?

 

Сервер для измерения подключить напрямую в ОЛТ.

1. Эти строки получены из virtual-port профайла, присутствующего в дефолтном конфиге путем его копирования с заменой предположительного значения скорости в 1 Гбит/с на желательные 100 Мбит/с. Сделано, конечно, не в результате трезвого понимания своих действий, а под влиянием интуитивного представления, что "в дефолтном конфиге все должно быть более-менее нормально, надо только слегка подкрутить".  Это представление подкреплялось и тем обстоятельством, что на стенде этот конфиг проблем не вызывал. Будут ли положительные изменения при удалении указанных лимиттеров, проверить прямо сейчас не могу. Как только возможность (свободные монтажники в поле) появится - проверю.

 

2. Уровни на разных портах разные:

1: -27,6 ... -22,7

2: -26,3 ... -21,2

3: -33 ... -20,7

4: -32,2 ... -21

5: -24,3 ... -19,4

6: -30 ... -20,6

7: -31,5 ... -21,3

8: -28,8 ... -22,8

 

Однако, как я уже писал, скорость аплоуда по моим наблюдениям не зависит от уровней сигнала ОНУшек. Она низкая даже на 5-м порту, где слабых ОНУшек нет. И отключение слабых ОНУшек улучшает в аплоуд не более, чем отключение любых других ОНУшек: важно только количество отключаемых ОНУ. Чем меньше ОНУшек остается на порту, тем лучше аплоуд. Но он не хорош, даже когда все слабые ОНУшки отключены.

 

3. Если вы имеет в виду "sh int", то ошибок там нет (в значимых количествах).

 

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

 

[foreverok 95]

Так сколько у Вас клиентов на одном дереве и какая скорость UPLOAD там же?

[NaviNavi 86]

4 минуты назад, foreverok сказал:

Так сколько у Вас клиентов на одном дереве и какая скорость UPLOAD там же?

По конфигу что прилаживался выше абонов нормально в дереве. Скорей всего как писали выше проблема с нарезкой скорости. Ждём когда тс тесты проведет на столе с такими настройками 

[foreverok 95]

1 минуту назад, NaviNavi сказал:

По конфигу что прилаживался выше абонов нормально в дереве. Скорей всего как писали выше проблема с нарезкой скорости. Ждём когда тс тесты проведет на столе с такими настройками 

Так сколько? 5-10-20 и тд (именно активных).

Или тут у всех стабильно скорость UPLOAD 100Mbit+ на деревьях с более чем 20 активными клиентами?

[sanyadnepr 305]

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

Подключение тестового ноутбука прямо в порт ОЛТа

1. Подключить тестовый ноут медью в ОЛТ, без Гпона и проверить, скорость исхода есть ?

2. Откуда взялся "дефолтный конфиг" не припомню рейт-лимита 100М в дефолте.

3. Откуда это и с какой целью ? В дефолте этого нет.

!
gpon profile onu-uni uni-general id 2
 gpon-profile speed 100
 gpon-profile eth-wiring auto
!

4. Сетевушка тестера какая ?

[a_n_h 599]

У меня скорость "аплоад" падала когда в ветке онушка "светила" постоянно с уровнем порядка -20 дБ.

[mpolk 22]

8 часов назад, foreverok сказал:

Так сколько? 5-10-20 и тд (именно активных).

Или тут у всех стабильно скорость UPLOAD 100Mbit+ на деревьях с более чем 20 активными клиентами?

Кого вы называете "активными клиентами"? Я употреблял аналогичное выражение "активная ОНУ" в смысле "ОНУ, имеющая что послать в сеть в данный момент". Если речь идет о таких "активных клиентах", то их количество меняется несколько раз в секунду. Так что посчитать их в буквальном смысле очень затруднительно. Можно как-то оценить их количество, активность и влияние на пропускную способность сети глядя на объем трафика. Как я уже писал, трафик в PON-ах небольшой, порядка 200Мбит/с вниз / 30МБит/с вверх в момент наибольшей загрузки на самых загруженных портах. В среднем по времени и по палате - намного меньше. От насыщения физики пока очень далеко.

 

Если вы говорите о ком-то/чем-то другом, например, о количестве активных клиентских подключений на БРАСах / на порт, то это посчитать как-то можно, но на мой взгляд, это не имеет прямого отношения к проблеме.

 

Просто зарегистрированных ОНУшек на портах от 20-и до 75-и, в среднем около 40-а. Счастья нет ни на одном из портов. Степень несчастья варьирует.

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

У меня скорость "аплоад" падала когда в ветке онушка "светила" постоянно с уровнем порядка -20 дБ.

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

[mpolk 22]

7 часов назад, sanyadnepr сказал:

1. Подключить тестовый ноут медью в ОЛТ, без Гпона и проверить, скорость исхода есть ?

2. Откуда взялся "дефолтный конфиг" не припомню рейт-лимита 100М в дефолте.

 

3. Откуда это и с какой целью ? В дефолте этого нет.

!
gpon profile onu-uni uni-general id 2
 gpon-profile speed 100
 gpon-profile eth-wiring auto
!

4. Сетевушка тестера какая ?

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

 

2. В дефолтном конфиге есть ограничение аплоуда на 1 Гигабит (gpon profile onu-rate-limit ratelimit-default id 1). Я заменил Гигабит на желательные мне 100Мбит. Поясню логику этих манипуляций (не пытаясь оправдать полученный результат): исторически у нас основная масса клиентов (не-ПОН-овских) имеют тарифную скорость 100Мбит и подключены к портам домовых свичей, тоже 100-Мбитных. Учитывая это чудесное совпадение и желая облегчить жизнь БРАСов, мы к 100-Мбитным клиентам шейперов на БРАСах не применяли вообще, полагаясь на ограничения физики. (Так было на момент первоначального конфигурирования ОЛТа, сейчас шейперы есть у всех клиентов). С появлением ПОНа и ОНУшек с Гигабитным клиентским портом возникло желание воспроизвести эту схему и на ПОНе. Данный rate-limit-profile есть результат попытки ограничить скорость клиента 100Мбитами силами самого ПОНа (методом китайского тыка). Вместе с аналогичным tcont-profile-ом и uni-profile-ом, упомянутым ниже. Сейчас выясняется, что попытка была неудачная. Но на стенде этого видно не было.

 

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

 

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

 

3. Этот uni-profile - вариация на ту же тему про ограничение в 100Мбит. И как раз он - это правильный способ добиться такого ограничения (в отличие от предыдущих). Он ставит физическую скорость эзернет-порта ОНУшки в 100Мбит. Работает как должно.

 

4. Про сетевушку тестового ноутбука ничего сказать не могу, кроме того, что она встроенная и 100Мбитная. Но она правильная, со своими тестовыми задачами справляется и скорость в 90-95 Мбит/с выдает.

Відредаговано 2019-11-22 08:56:31 mpolk

[fet4 46]

mpolk! Вы случаем не писатель, решивший заняться сетевыми технологиями ? Интересно читать Ваше повествование проблемы! Чем же все закончится ?!

[logic 523]

а не пробували різати швидкість не на олті а на серваку ?

[ISK 259]

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

Учитывая это чудесное совпадение и желая облегчить жизнь БРАСов, мы к 100-Мбитным клиентам шейперов на БРАСах не применяли вообще, полагаясь на ограничения физики.

Самоочевидно же что не пробовал...

 

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

[foreverok 95]

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

Кого вы называете "активными клиентами"?

Активные, в смысле включенные в розетку и имеющие линк с OLT. Пока что у Вас примерно так и есть, что скорость upload равна 1,2Gbps разделить на количество активных онух.

 

Много писать не люблю, поэтому попробуйте поменять,

gpon-profile pir 100000 cir 100000 (cir уменьшите скажем до 10000).

судя по всему тут собака порылась. 

[mpolk 22]

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

mpolk! Вы случаем не писатель, решивший заняться сетевыми технологиями ? Интересно читать Ваше повествование проблемы! Чем же все закончится ?!

Да нет, скорее админ, имеющий склонность к изящной словесности ?

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

а не пробували різати швидкість не на олті а на серваку ?

Для клиентов с пакетами, отличных от 100Мбит, скорость всегда и нарезалась именно на БРАСах. А теперь, когда мы начинаем ставить гигабитные домовые свичи для пациентов с пакетами более 100М, шейпим на БРАСах и 100Мбит тоже. Но год назад, когда этот ПОН запускался, 100Мбитные полосы нарезались физикой, благо она такая в природе существует и работает совершенно бесплатно.

 

Но отдавать весь шейпинг/полисинг на БРАСы тоже нельзя. Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару дней он уже будет красоваться на Shodan-е, а на третий день добрые люди запишут его в свой ботнет и пристроят к хорошему делу - DNS-amplification-ом заниматься. Или еще лучше, простого трояна пациент заведет, такого который udp во все стороны рассылает что есть силы. Этот аплоуд на БРАСе шейпить уже поздно будет. Боюсь, что для ПОНа это будет немногим лучше той "светящей" ОНУшки, если эти порывы прямо на ОНУшке не гасить.

 

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

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

Да я понимаю. Я собственно к минимуму и свожу. Но без вышеописанного ограничения аплоуда и особенно без loopback-detect-a на ОНУ жить нельзя вообще в принципе. Я на стенде петлю пробовал делать на ОНУШке, подключенной к этому самому ОЛТу, когда еще китайцы loopback-detect-а не завезли. Так там не то, что все клиенты отваливались, там ОЛТ в синюю асфиксию впадал необратимо. Случись это не на стенде, а в природе, я даже и не знаю, как бы я это восстанавливал.

 

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

Активные, в смысле включенные в розетку и имеющие линк с OLT. Пока что у Вас примерно так и есть, что скорость upload равна 1,2Gbps разделить на количество активных онух.

 

Много писать не люблю, поэтому попробуйте поменять,

gpon-profile pir 100000 cir 100000 (cir уменьшите скажем до 10000).

судя по всему тут собака порылась. 

 Мне такой расчет тоже в голову приходил. Я даже перемножал в Экселе скорости аплоуда на количества ОНУшек на порту. Получалось не слишком ровно, но тенденция просматривается.

 

Увы, проверять, новые гипотезы у меня снова не получается. Даже вчерашнюю гипотезу (с отключением rate-limit-профайла) проверить окончательно не удается, хотя она вполне вероятно, уже и может решить проблему. Мои монтажники опять перемерзли на аварийных работах и теперь натирают тюленьим жиром отмороженные пальцы, которые еще можно спасти от ампутации. Следующий ориентировочный срок для измерений - завтра в первой половине дня.

[nedoinet 441]

5 часов назад, foreverok сказал:

gpon-profile pir 100000 cir 100000

Если это правило делает тоже самое что на епоне - это пздец... х#$ его знает как бошка его отрабатывает при уже 15 онушках.... На епоне в основном не регистрируются онушки, хотя и башню срывало наглухо...

[foreverok 95]

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

Если это правило делает тоже самое что на епоне - это пздец... х#$ его знает как бошка его отрабатывает при уже 15 онушках.... На епоне в основном не регистрируются онушки, хотя и башню срывало наглухо...

Ну хрен знает как оно работает в этих чудных устройствах.

Однако определенная логика есть. cir - это гарантированная полоса, значит должна резервироваться.

gpon-profile pir 100000 cir 100000 - я не с потолка взял, это из конфига ТС. Потому рекомендую уменьшить cir до 10000

[nedoinet 441]

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

Мои монтажники опять перемерзли на

А почему нельзя включится на узле, где стоит олт? Электрика в розетке и условия труда по идее интереснее. Сделать себе отвод делителем 5/95 через sc-шки. И вся ветка в ваших руках

[mpolk 22]

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

А почему нельзя включится на узле, где стоит олт? Электрика в розетке и условия труда по идее интереснее. Сделать себе отвод делителем 5/95 через sc-шки. И вся ветка в ваших руках

1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает.

2) Асимметричных делителей у нас в хозяйстве нет.

 

Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку.

10 часов назад, foreverok сказал:

Ну хрен знает как оно работает в этих чудных устройствах.

Однако определенная логика есть. cir - это гарантированная полоса, значит должна резервироваться.

gpon-profile pir 100000 cir 100000 - я не с потолка взял, это из конфига ТС. Потому рекомендую уменьшить cir до 10000

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

Відредаговано 2019-11-23 07:10:45 mpolk

[NaviNavi 86]

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

1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает.

2) Асимметричных делителей у нас в хозяйстве нет.

 

Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку.

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

а вы пробовали подключиться перед олт и сделать измерения скорости?

[nedoinet 441]

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

В общечеловеческом понимании cir

на гпоне не вкурсе. на 3310 и  3608 епонах cir резервируется сразу на все всю ветку. тобишь на 64 онушки СРАЗУ

[NaviNavi 86]

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

на гпоне не вкурсе. на 3310 и  3608 епонах cir резервируется сразу на все всю ветку. тобишь на 64 онушки СРАЗУ

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

[nedoinet 441]

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

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

логике 146% что точно так же темболее один вендор. да и по логике ну вот щас возьмут 50 онух из 128 гонять маленький траф - тупо вроутер в розетке или абон серфит странички в тырнэтах и все, кабздец-приплыли... с другой стороны если олт будет анализировать активность в реалтайме и нарезать cir согласно активности  - это ж никакого железа не хватит...

[NaviNavi 86]

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

логике 146% что точно так же темболее один вендор. да и по логике ну вот щас возьмут 50 онух из 128 гонять маленький траф - тупо вроутер в розетке или абон серфит странички в тырнэтах и все, кабздец-приплыли... с другой стороны если олт будет анализировать активность в реалтайме и нарезать cir согласно активности  - это ж никакого железа не хватит...

тут камрады должны отписаться. У меня в работе епон 3310с с не лучшим шаблоном в плане нарезки скорости, при этом жалоб нет на скорость

cmd-sequence 001 epon onu all-port ctc vlan mode tag 230
 cmd-sequence 002 epon sla downstream pir 1000000 cir 15000
 cmd-sequence 003 epon sla upstream pir 1000000 cir 15000
 cmd-sequence 004 epon onu all-port storm-control mode 4 threshold 256
 cmd-sequence 005 epon onu all-port ctc loopback detect
 cmd-sequence 006 switchport port-security dynamic maximum 6
 cmd-sequence 007 switchport port-security mode dynamic

[nedoinet 441]

нормальный шаблон.

10 минут назад, NaviNavi сказал:

pir 1000000

максимальная скорость с онушки. если параметр не верный/не поддерживаемая функция онушкой - просто работает на максимальной скорости

10 минут назад, NaviNavi сказал:

cir 15000

гарантированая как раз исходя из 64 онух на ветке. 64*15к=960М

все гуд.

Відредаговано 2019-11-23 10:40:32 nedoinet