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

rus-p

Активный участник
  • Публикации

    567
  • Зарегистрирован

  • Посещение

1 подписчик

О rus-p

  • Звание
    Аспирант
    Аспирант

Контакты

  • ICQ
    Array

Посетители профиля

2898 просмотров профиля
  1. Только сейчас приступим. Как что получится, отпишу.
  2. Странно, мне инженер опсоса сказал, что БС умеет голосу и данным разные метки ставить. Первый раз в жизни сталкиваюсь с перегрузом по ппс на коммутаторе. Я всегда думал, что там ну пусть 32 гбпс, пусть даже на треть честных, и большими пакетами, это ведь все равно около полумиллиона в секунду. А трафика по сути много только в транке.
  3. Тогда такое поведение наверняка можно отключить на контроллере. А как голосу легче становиться, если он метиться другим CoS/DSCP нежели дата.   Ну тоесть не все по 64, а то я уже напрягся ) Да, мы даем 100-200, но нагрузка пока! еще не превышает 20-30.
  4. нда, вот оно как, оказывается. Включать все в агрегацию дорого и тоже имеет свои минусы. Ладно, по результатам отпишусь.
  5. Тьфу, тьфу, перестроений нет. Полечили от этого говна уже в свое время. Оборудование самые обычные коммутаторы Edge-Core 35xx, 41xx, Qtech 28xx, Qtech34xx, Dlink 1210-xx, затем аггрегационный коммутатор, и уже операторское железо. Гарантировать менее 0.01% потерь мы есстественно можем только на операторском железе, ну с натяжкой на коммутаторе агрегации, хотя и тут нужны тесты. А весь зоопарк с коммутаторами доступа просто нереально охватить. Поэтому хочется понять, что это за мега зависимость у БС от уровня ошибок в канале. Ведь по здравому смыслу, голос должен выживать при ошибках до 0.5-1% Может все гораздо проще, и, хоть БС рапортует, что есть проблема - сама проблема ничтожно мала. И хоть там 20% недостаточность, но это никак ощутимо не влияет на голос и данные в канале.
  6. У опсоса как раз Эриксон. Ежели бы дропалась часть пакета, то она дропалась бы и при нашем клиентском трафике 100-200 мбит. А тут четко проблема за этой границей начинается. Дропы на свитчах траблшутятся крайне сложно, т.к. у некоторых моделей коммутаторов ошибки не отображаются в cli, и понять их наличие можно только промером канала. Емкости предоставляем 100-200, это все с запасом укладывается в гиговые аплинки. Нам надо расковырять этот Эриксоновский протокол грантирования полосы, ну или еще чего они там придумали. Может ведь быть более сложный алгоритм. Опсос сам не понимает как оно работает, по крайней мере мне удалось дотянуться до таких инженеров. Qos конечно попробуем.
  7. Вы под RT подразумеваете real time ? Но тогда выходит, что именно задержка пакетов влияет на их оценку оборудованием, пропал он или не пропал. Тогда да, настроив кос, можно надеяться, что поможет. А если микроберсты, тут уже ничто не поможет. Тут еще вопрос стоит так, если есть небольшие потери, и БС жалуется, то сколько ей не хватает ? И, судя по профилю, ей не хватает чуть чуть. Тогда из этого получается, что контрольный трафик между БС и RNC идет псевдосинхронно маленькими пакетиками, и емкость логического канала определяется не полями в этих пакетах, а количеством самих пакетов. И микроберсты в этом случае сделают для нас недостижимой нормальную работу БС. Я уже гадаю конечно на кофейной гуще, нужен человек, который это все уже разобрал по роду деятельности.
  8. Коллеги, помогите Через нас - интернет провайдера, подключили базовые станции и некоторые БС не работают как положено. Столкнулись с неясным пока для нас явлением, со слов опсоса, "недостаточности транспортного канала от БС 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. Может еще какие мысли есть ?
  9. Если приставки хотят мультикаст, компания маленькая, а оборудование надежное, можно попробовать. Трафика ну 100-300 мбит съедят клиенты на 1G транковом порту. Вот и думайте надо оно вам. Проблем с мультикастом море, особенно в L2 сегментах на коммутаторах доступа. Нетфликс идет по пути юникаста и это работает, съест ресурсов у вас больше. Соответственно получать часть денежки надо за каждого абонента иначе в трубу вылетите.
  10. Собственно все написано в гайде, увы только 60Г. Конечно, для 1 RU это результат, но как всегда если пошла пьянка трудно остановиться. Ну и голый L2 дает о себе знать если вдруг вам надо расшириться или перебросить часть трафика. Не люблю я ни pbr, ни огород с ecmp, это всегда ужимки.
  11. Люди, подскажите, в старшей версии A10, а если сможете и в старшей версии Econat можно ли создать интерфейс из 12*10GE портов, т.е. из всех, а на нем L3 сабинтерфейсы для паблик ноги и для приватной. Или возможно только два интерфейса по 60Г ? По понятным причинам in/out у клиентов отличаются и первый вариант сильно предпочтительнее.
  12. RR перешлет разные РД, как следствие, получите балансировку, тогда как в стандартном варианте с одним RD у трафика всегда один путь. Как вы посмотрите какие префиксы клиента в bgp имеются ? Фильтр есть только на РД. Если их много, их надо помнить. РД либо один, либо два если балансировка и численно равны РТ. Время затрачиваемое на поиск проблемы самое важное в большой сети.
  13. Киберкот, а есть ли возможность логировать dst ip/port с EIM или без EIM ? Пробывали ли вы это в продакшене и насколько падает общая производительность коробки от этого ?
  14. А смысл этого ? Экономия публичных адресов или что-то еще ?
  15. 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.