[rus-p]

Коллеги, помогите

 

Через нас - интернет провайдера, подключили базовые станции и некоторые БС не работают как положено. Столкнулись с неясным пока для нас явлением, со слов опсоса, "недостаточности транспортного канала от БС 3G до RNC".

 

Что имеем:

0. БС 3G подключена без радиорелеек в обычное кольцо из Ethernet коммутаторов в порт 1G, full-duplex. Далее по кольцу везде аплинки 1G. Далее в операторское оборудование и стык с опсосом.

1. В случае потерь на канале на уровне 0.01% БС шлет отчеты, что интегрально, например за час, около 5% времени ей не хватало емкости логического канала от нее самой до RNC. Физически емкости достаточно.

2. В случае потерь 0.05-0.1% уже жалуется, что у нее 15-25% времени недостаточность емкости транспорта.

3. Прослеживается четкая корреляция интегрального показателя доступности логического канала с ЧНН от обычных интернет клиентов.

4. При трафике в кольце коммутаторов менее 200 мбит, жалоб нет.

5. Настройки qos в пакетах БС опсос не дает, мотивируя тем, что в отсутствии затора никаких проблем быть не должно (вроде логично).

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

т.е. до нуля канал не схлопывается, например 20мбит, и тем, не менее она жалуется, что емкости логического канала не хватает.

7. Выяснили, что есть некий протокол грантирования полосы, когда БС постоянно запрашивает RNC о выделении ей логической полосы и RNC постоянно шлет подтверждения.

 

Подозреваем, что либо

а) на трафике более 200-300 мбит в кольце коммутаторов на самих коммутаторах начинаются небольшие дропы

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

б) При большом трафике начинаются вариации задержки пакетов, это, теоретически, в зависимости от реализации протокола грантирования полосы может приводить к тому, что пакеты этого протокола, чуть задержавшись, считаются БС или RNC пропавшими.

 

 

Вопрос, как работает на самом деле этот протокол.

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

Может еще какие мысли есть ?

 

 

 

 

 

 

Изменено 12 июля, 2018 пользователем rus-p

[alibek]

Потому что трафик для БС критичен к RT.

Скорее всего дело именно в микроберстах.

Настройке QoS на своем транспорте, выделив высокий приоритет, возможно это поможет.

[rus-p]

Вы под RT подразумеваете real time ?

Но тогда выходит, что именно задержка пакетов влияет на их оценку оборудованием, пропал он или не пропал.

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

А если микроберсты, тут уже ничто не поможет.

 

Тут еще вопрос стоит так, если есть небольшие потери, и БС жалуется, то сколько ей не хватает ?

И, судя по профилю, ей не хватает чуть чуть.

Тогда из этого получается, что контрольный трафик между БС и RNC идет псевдосинхронно маленькими пакетиками, и емкость логического канала определяется не полями в этих пакетах, а количеством самих пакетов.

И микроберсты в этом случае сделают для нас недостижимой нормальную работу БС.

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

 

 

[Unker]

1. СОГЛАСУЙТЕ с оператором MTU, вероятно у вас пакеты фрагментируются и часть пакета дропается на кольце.

2. Могут быть дропы на свичах, особенно при кольцевой топологии. 

3. У нас через микротик через бридж нормально канал под оператора не заработал, но через свич-группу все ок, даже на RB2011.

 

Какую ёмкость канала предоставляете оператору?

Если не секрет, кому предоставляете канал?

 

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

Хуавей менее всего критичен к дропам на сети, а вот эриксон нормально работать не будет.

Мы даже временно собирали канал на юбикути под оператора (бс на оборудовании хуавей), работал без нареканий.

[alibek]

1 час назад, rus-p сказал:

Вы под RT подразумеваете real time ?

Да.

Конкретно БС мы не подключали, но мы периодически даем канал для ТВ-студии и их оборудование очень критично к качеству канала.

Экспериментировали с настройками портов, flow-control, qos, пока не подобрали приемлемое для оборудования качество.

MTU на всякий случай тоже стоит проверить, но мне кажется, что причина наверняка не в нем.

[rus-p]

У опсоса как раз Эриксон.

Ежели бы дропалась часть пакета, то она дропалась бы и при нашем клиентском трафике 100-200 мбит.

А тут четко проблема за этой границей начинается.

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

Емкости предоставляем 100-200, это все с запасом укладывается в гиговые аплинки.

 

Нам надо расковырять этот Эриксоновский протокол грантирования полосы, ну или еще чего они там придумали. Может ведь быть более сложный алгоритм.

Опсос сам не понимает как оно работает, по крайней мере мне удалось дотянуться до таких инженеров.

Qos конечно попробуем.

 

[TheUser]

@rus-p , какое оборудование с вашей стороны по всей цепочке?

Нет ли перестроений колец (мало-ли...)?

[rus-p]

Тьфу, тьфу, перестроений нет. Полечили от этого говна уже в свое время.

 

Оборудование самые обычные коммутаторы Edge-Core 35xx, 41xx, Qtech 28xx, Qtech34xx, Dlink 1210-xx, затем аггрегационный коммутатор, и уже операторское железо. Гарантировать менее 0.01% потерь мы есстественно можем только на операторском железе, ну с натяжкой на коммутаторе агрегации, хотя и тут нужны тесты.

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

 

Поэтому хочется понять, что это за мега зависимость у БС от уровня ошибок в канале.

Ведь по здравому смыслу, голос должен выживать при ошибках до 0.5-1%

 

Может все гораздо проще, и, хоть БС рапортует, что есть проблема - сама проблема ничтожно мала.

И хоть там 20% недостаточность, но это никак ощутимо не влияет на голос и данные в канале.

 

[rdc]

Здравый смысл не применим к опсосам.

А по сути вопроса - QoS решает. Дайте опсосному трафику максимальный приоритет и всё.

Если микробёрсты опсосного трафика не превышают буфер свича, потери исчезнут.

 

А вот если именно опсосные микробёрсты его превышают - либо такие свичи надо менять на модели с бОльшим буфером, либо переделать сеть так, чтобы на этих свичах не было снижения скорости (типа - пакет пришёл на 10GE и ушёл на 1GE).

[LostSoul]

А это нереально такого клиента, как ОПСОС воткнуть отдельным волокном в агрегацию?

ну или хотя бы лямбдой?

платят то наверное неплохо

 

[Unker]

41 минуту назад, rus-p сказал:

Поэтому хочется понять, что это за мега зависимость у БС от уровня ошибок в канале.

Ведь по здравому смыслу, голос должен выживать при ошибках до 0.5-1%

Как нам объяснили инженеры одного из операторов, когда начинаются потери в канале, контроллер думает что на канале до бс начинается перегруз, и чтобы его избежать начинает ограничивать скорость у клиентов на данной бс. Сделано это чтобы избежать перегруза на ррл с маленькой емкостью, чтобы качество голоса не ухудшалось.

Если оборудование эриксон, то у вас свичи на доступе просто не могут прожевать канал по количеству пакетов. Голос (а возможно и весь трафик опсоса) ходит пакетами по 64 байта. 

 

50 минут назад, rus-p сказал:

хотя и тут нужны тесты.

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

Есть тестер Беркут, попросите у опсоса и ходите ищите где затык образуется. Мы только с его помощью нашли что у нас был затык на софтовом бридже на микротике. Причем при загрузке cpu уже выше 25% начинались дропы, стандартным пингом это не обнаружить.

[alibek]

5 минут назад, Unker сказал:

Голос (а возможно и весь трафик опсоса) ходит пакетами по 64 байта.

Да уж. Это конечно радикальное решение проблемы с MTU.

[Unker]

Только что, alibek сказал:

Да уж. Это конечно радикальное решение проблемы с MTU.

Видимо это решение у эриксона такое))

Мегафон на хуавее просит мту 2000, у них там mpls и еще что-то бегает специфичное. При 1500 работает, но бс ругается на фрагментацию и скорость на 3G выше 1-2 мбит не дает разогнать.

[rus-p]

нда, вот оно как, оказывается.

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

 

Ладно, по результатам отпишусь.

[Unker]

Вот статистика с порта опсоса за 60 сек. Как раз эриксон. И график загрузки порта за час.

А вы там под 200 мбит гоняете.... 1210-28 наверно уже дымится...

[rus-p]

16 минут назад, Unker сказал:

Как нам объяснили инженеры одного из операторов, когда начинаются потери в канале, контроллер думает что на канале до бс начинается перегруз, и чтобы его избежать начинает ограничивать скорость у клиентов на данной бс. Сделано это чтобы избежать перегруза на ррл с маленькой емкостью, чтобы качество голоса не ухудшалось.

Если оборудование эриксон, то у вас свичи на доступе просто не могут прожевать канал по количеству пакетов. Голос (а возможно и весь трафик опсоса) ходит пакетами по 64 байта. 

 

 

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

А как голосу легче становиться, если он метиться другим CoS/DSCP нежели дата.

 

 

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

Вот статистика с порта опсоса за 60 сек. Как раз эриксон. И график загрузки порта за час.

А вы там под 200 мбит гоняете.... 1210-28 наверно уже дымится...

 

Ну тоесть не все по 64, а то я уже напрягся )

Да, мы даем 100-200, но нагрузка пока! еще не превышает 20-30.

[Unker]

в 3G голос и дата одними пакетами ходят. У мегафона было такое, когда на ррл перегруз начинался, то в 3ж невозможно было разговаривать, а в 2ж пожалуйста, потому что 2ж было на Е1 потоке с макс приоритетом в ррл.

 

Никакие метки вам не помогут, ищите затык в коммутаторах доступа, на каком узле у вас перегруз по pps.

 

https://shop.nag.ru/catalog/04963.SNR/19911.Kommutatory-dostupa-GigabitEthernet/24907.SNR-S2985G-24T-RPS#tech

Вот что-то типа такого вам надо ставить

[rus-p]

Странно, мне инженер опсоса сказал, что БС умеет голосу и данным разные метки ставить.

 

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

Я всегда думал, что там ну пусть 32 гбпс, пусть даже на треть честных, и большими пакетами, это ведь все равно около полумиллиона в секунду. А трафика по сути много только в транке.

[Unker]

Разложите перспективные 200 мбит на пакеты... ну хотя бы по 128 байт и смотрите какой производительности нужен коммутатор. Другого решения нет. Любые метки и тд - это костыль, который в любой момент даст трещину.

 

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

[Saab95]

У нас тут на ваймаксе был канал до удаленной БС сотового, далее по цепочке микротиков поверх L3 шло до ядра - ни разу не жаловались просто так, только если реально потери идут, которые и наш мониторинг определял. Поэтому уберите L2 на транспорте и проблема уйдет сама собой.

[Unker]

@rus-p Нашли затык?

[TheUser]

В 13.07.2018 в 22:44, Saab95 сказал:

Поэтому уберите L2 на транспорте и проблема уйдет сама собой.

Предлагаю сразу убрать еще L3-L6 на транспорте, оставив только L7!

Сам так хочу сделать, Микротик это позволяет. L1-L6 уже давно устарели, L7 - именно то, что нужно!!!

[rus-p]

В 19.07.2018 в 23:11, Unker сказал:

@rus-p Нашли затык?

Только сейчас приступим.

Как что получится, отпишу.