rus-p

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

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

Тогда такое поведение наверняка можно отключить на контроллере. А как голосу легче становиться, если он метиться другим CoS/DSCP нежели дата.   Ну тоесть не все по 64, а то я уже напрягся ) Да, мы даем 100-200, но нагрузка пока! еще не превышает 20-30.

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

Тьфу, тьфу, перестроений нет. Полечили от этого говна уже в свое время. Оборудование самые обычные коммутаторы Edge-Core 35xx, 41xx, Qtech 28xx, Qtech34xx, Dlink 1210-xx, затем аггрегационный коммутатор, и уже операторское железо. Гарантировать менее 0.01% потерь мы есстественно можем только на операторском железе, ну с натяжкой на коммутаторе агрегации, хотя и тут нужны тесты. А весь зоопарк с коммутаторами доступа просто нереально охватить. Поэтому хочется понять, что это за мега зависимость у БС от уровня ошибок в канале. Ведь по здравому смыслу, голос должен выживать при ошибках до 0.5-1% Может все гораздо проще, и, хоть БС рапортует, что есть проблема - сама проблема ничтожно мала. И хоть там 20% недостаточность, но это никак ощутимо не влияет на голос и данные в канале.

У опсоса как раз Эриксон. Ежели бы дропалась часть пакета, то она дропалась бы и при нашем клиентском трафике 100-200 мбит. А тут четко проблема за этой границей начинается. Дропы на свитчах траблшутятся крайне сложно, т.к. у некоторых моделей коммутаторов ошибки не отображаются в cli, и понять их наличие можно только промером канала. Емкости предоставляем 100-200, это все с запасом укладывается в гиговые аплинки. Нам надо расковырять этот Эриксоновский протокол грантирования полосы, ну или еще чего они там придумали. Может ведь быть более сложный алгоритм. Опсос сам не понимает как оно работает, по крайней мере мне удалось дотянуться до таких инженеров. Qos конечно попробуем.

Вы под RT подразумеваете real time ? Но тогда выходит, что именно задержка пакетов влияет на их оценку оборудованием, пропал он или не пропал. Тогда да, настроив кос, можно надеяться, что поможет. А если микроберсты, тут уже ничто не поможет. Тут еще вопрос стоит так, если есть небольшие потери, и БС жалуется, то сколько ей не хватает ? И, судя по профилю, ей не хватает чуть чуть. Тогда из этого получается, что контрольный трафик между БС и RNC идет псевдосинхронно маленькими пакетиками, и емкость логического канала определяется не полями в этих пакетах, а количеством самих пакетов. И микроберсты в этом случае сделают для нас недостижимой нормальную работу БС. Я уже гадаю конечно на кофейной гуще, нужен человек, который это все уже разобрал по роду деятельности.

Коллеги, помогите Через нас - интернет провайдера, подключили базовые станции и некоторые БС не работают как положено. Столкнулись с неясным пока для нас явлением, со слов опсоса, "недостаточности транспортного канала от БС 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. Может еще какие мысли есть ?

Если приставки хотят мультикаст, компания маленькая, а оборудование надежное, можно попробовать. Трафика ну 100-300 мбит съедят клиенты на 1G транковом порту. Вот и думайте надо оно вам. Проблем с мультикастом море, особенно в L2 сегментах на коммутаторах доступа. Нетфликс идет по пути юникаста и это работает, съест ресурсов у вас больше. Соответственно получать часть денежки надо за каждого абонента иначе в трубу вылетите.

Собственно все написано в гайде, увы только 60Г. Конечно, для 1 RU это результат, но как всегда если пошла пьянка трудно остановиться. Ну и голый L2 дает о себе знать если вдруг вам надо расшириться или перебросить часть трафика. Не люблю я ни pbr, ни огород с ecmp, это всегда ужимки.

Люди, подскажите, в старшей версии A10, а если сможете и в старшей версии Econat можно ли создать интерфейс из 12*10GE портов, т.е. из всех, а на нем L3 сабинтерфейсы для паблик ноги и для приватной. Или возможно только два интерфейса по 60Г ? По понятным причинам in/out у клиентов отличаются и первый вариант сильно предпочтительнее.

RR перешлет разные РД, как следствие, получите балансировку, тогда как в стандартном варианте с одним RD у трафика всегда один путь. Как вы посмотрите какие префиксы клиента в bgp имеются ? Фильтр есть только на РД. Если их много, их надо помнить. РД либо один, либо два если балансировка и численно равны РТ. Время затрачиваемое на поиск проблемы самое важное в большой сети.

Киберкот, а есть ли возможность логировать dst ip/port с EIM или без EIM ? Пробывали ли вы это в продакшене и насколько падает общая производительность коробки от этого ?

А смысл этого ? Экономия публичных адресов или что-то еще ?

Output drops при трафике >= 200-300 мбит это стандартная грабля на 3750 с берстом. Никакими трешхолдами и буферами не лечится. Причина в малом буфере на чипе. Если из мануала все сделано - http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/116089-technote-switches-output-drops-qos-00.html, а дропы идут, то только замена на, например, 4948.

Если не поможет wscale, дело пахнет TCP прокси на стороне МТС. А с таймстампом они похоже пакты не трогают, т.к. тут алгоритм сложнее. Косвенное подтверждение этому win7, ку нее таймстамп включен по дефолту. Попробуйте netsh int tcp set global timestamps=enabled. ЗЫ. Уже понятно, что дело не вwscale. Что-то вроде DPI на этот сайт у них стоит, у них этого говна навалом.

Еще в порядке эксперимента задайте на винде wscale = 7

Тоже бред, но может крутили в реестре и не перегружали машину )

Heggi, итого, что получается. 1. Через МТС не работает с виндовых машин с линукса работает. 2. Все дампы вы снимали на стороне клиента. 3. Сервер не получает или не понимает ACK от винды ни на каждый пакет ни на группу. Вы сказали, что mss крутили, а если попробывать жестко задать на винде mtu 1360 (дампик бы тоже не помешал) ?

Тогда дамп с единицей.

Дамп снимали ? Есть подозрение, что 1 это ждать 1 пакет, попробуйте 0. Дамп обязателен, без него тут полбутылки не хватит.

т.е вы берете, условно, 2 десятки в инет, 2 на кастомеров. Итого трафика по всем интерфейсам in+out 20+20+20+20=80. Ресурсы ESP исчерпаны. С точки зрения ESP через него течет 20 в одну сторону, 20 в другую, циска пишет ESP40. Правильно я вас понял ? В этом случае все сходится, действительно можно дойти до 40in + 40out, но по всем интерфейсам. Переводя на провайдерский язык, это 20full-duplex через роутер. Вот это многих, видимо, и загоняет в раздумья, вроде пишут можно 40 туда и 40 сюда, а тянет 20 ) Все верно, у вас (8+8)/2 = 8, а ESP10. Или по другому, 8 в ESP, 8 из ESP, итого через ESP 8. т.е. важен трафик _через_ ESP. Ну и помимо этого лимитируется in и out, т.е. формулу (in+out)/2 можно использовать, пока трафик симметричный и его паттерн простой, в противном случае нужно считать по каждому направлению отдельно.

Вы намекаете, что можно получить больше 20G full-duplex ?

Ну тык выставьте на винде ключ TcpAckFrequency в 1 или 0, не знаю, что винда понимает под "слать сразу" и будет вам счастье. А вообще кривой стек на сервере.

Да вроде и не обязана винда слать на каждый. TcpAckFrequency ключ в реестре глядите. Это механизм delaydAСK, там еще и таймер есть. Смотрите почему сервер хочет на каждый пакет получит ACK, виндовс то ведь ему подтверждает сразу 3 пакета, а сервер все равно ретранзмит первому пакету делает.