Andrew Rogov

Resolved Caveats—Cisco IOS XE Release 3.1.3S

Проверял. Проблем нет. ЕМНИП, 3 года назад на МЕ3400 были серьёзные проблемы с приоритезацией REP. Как сейчас - не в курсе, может уже и пофиксили... ага, поэтому и спросил))) 3 года назад это был 2007 год. Что-то мне кажется методика тестов была не показательна. По моим данным исправили все в 2008-ом году. Причем, чуть ли не на аппаратном уровне. Проблемы с REP были исправлены в 12.2(46), причем как на 3400, так и на 4948.

Проверял. Проблем нет. ЕМНИП, 3 года назад на МЕ3400 были серьёзные проблемы с приоритезацией REP. Как сейчас - не в курсе, может уже и пофиксили... Не припомню.

Работает. Стабильно. Агрегаторы - Cisco 4948-10G Доступ - ME3400. PS: это не совсем рекомендация. Это то, на чем у меня работает. :) не проверяли, как обслуживаются служебные сообщения на нагруженных интерфейсах, т.е. когда механизмы QoS уже должны срабатывать? Проверял. Проблем нет. Можете показывать схему сборки при которой производилось тестирование? Уффф... "Ну ты, барин, и задачки ставить" ... Тестировали три года назад, когда сеть дизайнили.

на SCE 8000 в режиме работы без персонификации SCE не шейпит на контролерах циска говорит что 30 августа где-то в Азии уже открыли кейс по этому поводу только что проверил - да, есть такой косяк но с другой стороны ни один DPI никогда не будет корректно определять все протоколы поэтому с этим можно смириться. Согласен. Думаю, по этой причине нам дан Signature Editor :) Не видел ни одного чела который с ним может разобраться :) Да, там проблема выявить подходящие для SE :) закономерности в трафике. Так-то все несложно.

на SCE 8000 в режиме работы без персонификации SCE не шейпит на контролерах циска говорит что 30 августа где-то в Азии уже открыли кейс по этому поводу только что проверил - да, есть такой косяк но с другой стороны ни один DPI никогда не будет корректно определять все протоколы поэтому с этим можно смириться. Согласен. Думаю, по этой причине нам дан Signature Editor :)

3.6.1 pp22. Не нормально. При Default rule = block, MailRu Agent, например, вполне себе работает. Но он, паршивец, использует порт is-is :)

Работает. Стабильно. Агрегаторы - Cisco 4948-10G Доступ - ME3400. PS: это не совсем рекомендация. Это то, на чем у меня работает. :) не проверяли, как обслуживаются служебные сообщения на нагруженных интерфейсах, т.е. когда механизмы QoS уже должны срабатывать? Проверял. Проблем нет.

Да, извините, туплю. Просто у Аллота нет возможности задавать URL по маске. У SCE довольно мощные средства.

Проблема в том, что у каждого файлообменника несколько, а то и несколько десятков серверов с разными УРЛами, порой именуемыми бессистемно. И чтобы всё это дело снифить и мониторить, придётся отдельного сотрудника только на эту задачу и садить. Я так подробно спрашивал, потому что предположил, что есть какой-то другой способ идентифицировать файлообменники кроме тупого ручного отслеживания. Ну в доменном имени же присутствует какой-то общий признак, не ?

Ну вот есть, к примеру, файлообменник letitbit. Что мы будем в этот flavor прописывать, чтобы он летитбитовские сервера опознал? Как уже ответили выше по ветке, для создания качественного flavor неплохо поснифить трафик. Навскидку - HTTP URL + параметры строки запроса. По ссылке, которую я давал, довольно внятно все показано. PS: ты хочешь, чтобы я тебе готовый flavor предложил ? :)

А файлообменник как идентифицировать? Не понял вопроса.

Работает. Стабильно. Агрегаторы - Cisco 4948-10G Доступ - ME3400. PS: это не совсем рекомендация. Это то, на чем у меня работает. :) Деньги инвестора ? Ну а если по существу, то есть же еще E-RPS (http://en.wikipedia.org/wiki/Ethernet_Ring_Protection_Switching) Появляется на D-Link, например. Сам не тестировал, про работу ничего пока сказать не могу.

Спасибо за ссылку! Но всё равно не понятно, какой объединяющий признак можно указать в этом "запахе" для файлообменников? Схема примерно такая. 1. Для каждого файлообменника создаешь уникальный flavor 2. Объединяешь все flavors файлообменников в отдельный service.

Работает. Стабильно. Агрегаторы - Cisco 4948-10G Доступ - ME3400. PS: это не совсем рекомендация. Это то, на чем у меня работает. :) Деньги инвестора ? Это важно ? :) Да, инвестора.

Нет. Сигнатур нет. Их можно классифицировать по flavors. А что такое flavors? http://www.cisco.com/en/US/docs/cable/serv....html#wp1056550

Нет. Сигнатур нет. Их можно классифицировать по flavors.

По крайней мере в версии SCOS 3.5.5 (SCE2020) у нас наблюдается проблемы с ограничением скорости отдельных случайных клиентов.У клиента, предположим, pir(primary BWC)=300 kbps, а утилизирует он 800kbps (после SCE) - это видно по отчетам Reporter'а и на интерфейсе BRAS'а (drop rate 504000 bps). В отчете преобладают следующие сервисы (круглосуточно): - Other UDP - Voice and Video cals ( врят ли клиент говорит сутки на пролет:) - Bittorent Главная специфика - у клиента наблюдается очень большое количество UDP сессий ~ 2500 (маленькие UDP сегменты). Скорей всего SCE не в состоянии классифицировать такой поток и применить к нему политики. На каком pp ?

Раздумываю. Надо проверять.

Работает. Стабильно. Агрегаторы - Cisco 4948-10G Доступ - ME3400. PS: это не совсем рекомендация. Это то, на чем у меня работает. :)

Как доложила разведка, 3.6.0 крайне неудачная версия, в которой много проблем с классификацией. Ставьте 3.6.1. На 3.6.1 картина такая же.

Примерно так: vlan database vlan 2-4 exit ip igmp snooping multicast-tv vlan 2 add 224.1.1.100 ip igmp snooping multicast-tv vlan 2 add 224.1.1.101 interface range ethernet g(1-2) no shut switchport mode trunk switchport trunk allowed vlan add 2 interface ethernet e3 no shut switchport access vlan 3 spanning-tree disable switchport access multicast-tv vlan 2 interface ethernet e4 no shut switchport access vlan 4 spanning-tree disable switchport access multicast-tv vlan 2

D^2 А оно там надо ? :)

mschedrin qos trust dscp на интерфейсе разве не помогает ?! PS: есть документ по архитектуре 4500 платформы с прошлогоднего Cisco Live. Если надо - говори, как его тебе отдать.

Ну, как вариант. http://www.cisco.com/en/US/docs/ios/isg/co....html#wp1054603 Вкратце: с RADIUS для сессий нужных тебе абонентов отдавать в атрибутах subnet mask такую, чтобы она покрывала адреса абонентов. Таким образом они у тебя попадут под действие одной policy. В твоей конфигурации, видимо, придется поколдовать немного с выдаваемыми адресами.