пятница, 18 ноября 2011 г.

SCE - DPI от Cisco и с чем его едят

Предисловие

Т.к никакого другого DPI кроме устройства от Cisco трогать не доводилось, то все описанное справедливо только для моделей 2020 и 8000 этой уважаемой многими (иногда кстати совершенно не заслуженно) конторы.
Моя писанина никак не является кратким пересказом существующего мануала от Cisco, а просто старается рассказать о основных принципах работы SCE и некотором опыте работы с ней. Желающие ознакомиться со всем функционалом подробно welcome to sweet journey in manual.


Начну с того, что cобственно скрывается за непонятной многим аббревиатурой DPI.
DPI - deep packet inspection, устройство предназначенное для "глубокого"(вплоть до L7 модели OSI) анализа проходящих через него пакетов и с возможностью придания этим пакетам определенной QoS-окраски. Т.е на основе анализа протоколов,портов,сигнатур DPI определяет к какому типу трафика принадлежит данный пакет и в зависимости от этого может произвести над пакетом какие то действия: дропнуть, сложить его в канал с определенной полосой, выставить пакету нужный ToS, совершить еще какие то глумления. Причем все это может производиться на уровне отдельного пользователя (subscriber) путем назначения каждому пользователю определенного паккеджа (package).

SCE умеет создавать как глобальные для всего устройства контролеры полосы (global bandwidth controllers), так и локальные контроллеры накладываемые на отдельного пользователя (subscriber bandwidth controllers).


GBC - это логические полосы которые щедрой рукой можно нарезать. Сами по себе они ничего не делают, т.к просто являются трубой для некого гипотетического трафика. Для того чтобы ограничения стали реальными и начали работать требуется указать соответствие SBС определенному GBC. Т.е GBC можно представить в виде автострады по которой летит трафик из сматченных с ней SBС и в случае, когда автострада загружена, то какому то трафику из SBС приходится ждать своей очереди, а часто быть попросту дропнутым. Ширина отдельных GBC может варьироваться в зависимости от расписания (weekly calendar).

SBC - работают на уровне отдельных сабскрайберов (пользователей). Каждый сабскрайбер привязан к определенному паккеджу.



Паккедж представляет собой набор из одного/нескольких PBC (primary bandwidth controller) с развернутыми внутри них SBC и сервисов (service), в котором каждый сервис принадлежит определенному SBC или просто заблокирован (в этом случае и соответствия никакого не нужно).











SBC в свою очередь принадлежит одному из GBC. Каждому SBC можно выдать определенную полосу которую он будет забирать из слинкованного с ним GBC. Так же любому SBC можно выставить приоритет (AL) относительно других SBC в данном паккедже. Приоритет влияет на то какой из SBC будет иметь более высокий приоритет в получении полосы при высокой утилизации PBC. PBC же определяет суммарную максимальную доступную полосу для всех вложенных в него SBC, в простейшем случае максимальную полосу для каждого сабскрайбера в паккедже. Т.е если PBC один то максимальная полоса для сабскрайбера не может превысить значения PBC.


Сервис представляет собой набор протоколов (обычно близких по типу, например, http и https можно объединить в общий сервис Browsing). Сервисы можно создавать и собирать самостоятельно, а можно использовать стандартные.

Более того, можно самостоятельно создавать описания протоколов(например, tcp на порту 1119 на адресах 81.22.xx.xx считать протоколом игры WoW), писать свои сигнатуры (ну это уже для продвинутых) и назначать их сервисам.

Статистику всего этого великолепия можно наблюдать в Reporter, который является частью пакета SCABB. SCABB это пакет в основном предназначенный для управления application уровнем SCE и основная настройка и управление осуществляется именно через него. Reporter позволяет просматривать статистику по протоколам, сервисам, паккеджам, и многому другому и является просто незаменимым элементом контроля и управления устройством, ведь управлять в слепую согласитесь неудобно. Однако стоит учитывать, что Reporter выдает статистику с уровней L4-L7 по модели OSI и это следует учитывать при выставлении полосы на GBC, т.к на них она выставляется на L2-уровне и таким образом overhead к значениям из Reporter будет составлять около 10%. (Хочешь получить 1гбит на http - выставь 1100мбит на GBC для http). Данные статистики Reporter берет с сервера CM (Collection Manager), куда их заботливо складывает SCE (см. RDR в настройках SCE).

SM (subscriber manager) управляет сабскрайберами. Для управления может использоваться Cisco API, которое позволяет выделывать с пользователями очень многое. Из самых востребованных полезностей: перекладывание сабскрайбера в другой паккедж, назначение квот, управление календарем.

Управление через CLI или API имеет одно очень серьезное преимущество по сравнению с управлением через SCABB - дело в том, что при загрузке конфига через SCABB конфиг полностью перезаливается на SCE и применяется. В момент его применения возникает ситуация, когда никакие ограничения на трафик еще не действуют (т.е секунд 20-30 трафик никак SCE не обрабатывается и просто пролетает через нее), а после применения конфига при большом кол-ве трафика, проходящего через устройство, изменения сразу не применяются. Проблема похоже возникает из-за высокой загрузки траффик-процессоров. Реально иногда пережевывание трафика в такие моменты может достигать 30-60 минут. Впрочем такая проблема наблюдалась только с SCE2020 и при практически полной ее загрузке, за 8000 такого не замечалось, хотя и там трафика бывает более чем прилично.
Внесение изменения через CLI или API влияет только на тот параметр который реально изменяется и проблема описанная выше просто не возникает. К тому же такие изменения быстры, т.к загрузка конфига через SCABB занимает до 5 минут, а изменение параметра GBC через ту же CLI всего несколько секунд.

Еще одна прелесть это Bypass - оптический байпас, на SCE8000 представлен в виде отдельного модуля, через который подключаются оптические линки. Замечателен тем, что в случае отказа системы (т.е если пакеты перестают ходить в течении определенного времени) SCE автоматически его активирует и весь трафик начинает идти через него. DPI конечно же работать перестает, но никакого перерыва сервиса и деградации. Bypass пассивный, т.е следит за наличием света в оптоволокне и при его отсутствии (например, SCE просто померла или пропало питание) трафик автоматически устремляется через bypass. Так же в любой момент трафик на bypass можно перевести простой командой из CLI. При переключении никаких потерь пакетов просто нет(я ни разу не зафиксировал). С включенным байпасом с SCE можно делать что угодно, bypass можно просто вынуть и проводить необходимые регламентные работы, например, обновление ПО.

Cisco регулярно выкладывает обновления известных SCE протоколов. Называются эти файлы protocol pack. Обновление никаких проблем не вызывает, оно просто и удобно. К сожалению на горячее не обновляет, SCE придется выводить из эксплуатации.
SCOS - ios для SCE тоже регулярно обновляется, приносит новые фичи.

Теперь немного о запчастях:

SCE8000 имеет модульную структуру:




2 PSU, 2 слота под байпас, 4 слота под интерфейсные платы (1x10G per slot), 2 слота под SCM-E(мозг).




Каждый SCM-E может обрабытывать до 7.5Gbps трафика в каждую из сторон. Соответственно максимальная производительность SCE8000 составляет до 15Gbps в каждую из сторон.

SCE2020 это fixed версия:



2PSU, 4 гигабитных порта(два на вход, два на выход).




Основное ограничение возникает даже не по трафику, а по кол-ву пропускаемых flow. Нормально выжимает примерно 1.5Gbps в каждую из сторон.

Обе модели могут собираться в каскады, но самый простой способ задействовать несколько SCE в схеме - это прокинуть через SCE etherchannel. SCE абсолютно прозрачна для других устройств сети, таким образом поставив ее в разрыв между двумя устройствами, можно спокойно поднять между этими устройствами etherchannel. Управление трафиком в SCE2020 осуществлялось инкрементированием/декриментированием виланов на выходе, в SCE8000 такая возможность пропала. Это может вызвать некоторые сложности при миграции c 2020 на 8000. Нам, например, пришлось менять топологию ядра.


Ну и немного из опыта напоследок:

Блокирование p2p протоколов не является хорошей идеей. Дело в том, что помимо торрентов и других файлообменных сетей p2p используется и действительно нужными многим программами, в частности банк-клиентами, онлайн играми. Причем очень часто быват так, что p2p трафик составляет лишь малую часть от необходимого обмена трафика для таких узлов. Решение - p2p не блокировать, а сильно ограничивать. 16кбит будет достаточно. Качать на этой скорости, что либо не реально, а вот служебному трафику этой полосы вполне хватает.

Полосу GBC нельзя выставлять слишком низкой. SCE некорректно обрабатывает низкие значения GBC и попросту перестает шейпить трафик в этом GBC.

13 комментариев:

  1. Здравствуйте, Артем.
    Есть несколько специфичных вопросов по работе SCE8000. Но перед этим хотел спросить Вас, какую SCE (конфигурация SCM-E/SPA) Вы используйте?

    ОтветитьУдалить
    Ответы
    1. Один SCM-E, два SPA-1X10GE-L-V2. Базовый бандл для SCE-8000

      Удалить
  2. Спасибо за ответ.
    Мы на прошлой неделе, как раз обновились на такую конфигурацию. До этого вместо двух SPA-1X10G стояли карточки SPA-8X1GE-V2, в связи с этим мы использовали функционал aggregative-global-controllers.
    После обновления возникли две проблемы:
    1. Даже если задать в SCA-BB использовать "Enforce BW limitation on the sum of all links" и задать Rate Limit в конфигурации GC, то непосредственно в SCE, после применения конфига, эти настройки не передаются.
    2. Если настроить эти AGC через CLI на SCE, то все работает, кроме отражение скорости Actual-Rate в AGC с индексом 0 и side subscriber, хотя трафик там есть.

    aggregative-global-controller network-side 0 cir 0 pir 2700000 al 5 parent -1 name "NetSide AGG0"
    aggregative-global-controller subscriber-side 0 cir 0 pir 3000000 al 5 parent -1 name "SubSide AGG0"
    -----------------
    SCE8000-1X10GBE#><-global-controllers side subscriber agc 0 extended
    AGCs : 0
    side : network
    CIR : 2700000 Kb/sec
    PIR : 3000000 Kb/sec
    AL : 10
    Name : SubSide AGG0
    Parent : -1
    Enforce-Rate : 3000000 Kb/sec
    Actual-Rate : 0 Kb/sec
    Is Default : 0

    Для других AGC Actual-Rate отражается корректно.

    Тут возникает несколько вопросов:
    1. Такое поведение наблюдается только у нас или
    это ограничение/bug платформы (типа, если только 2 линка, то зачем использовать функционал AGC)?
    2. Вы можете посмотреть у себя на железе (SCE8000) данное поведение, чтобы удостовериться?

    ОтветитьУдалить
  3. Мы AG не используем потому что его в такой конфигурации как бы и не надо. А из спортивного интереса экспериментировать на боевом железе желания у меня нет. Но думаю что если на SPA-8X1GE-V2 работало, то вряд ли это бага.

    ОтветитьУдалить
  4. Я понимаю, что экспериментировать на железе, которое сейчас в работе не совсем правильно. Так или иначе спасибо. Мы функционал AGC использовали для одной интересной фичи, а именно, динанамического распределения полосы между различными GC. А эта штука работает только в режиме AGC.

    ОтветитьУдалить
    Ответы
    1. Интересная фича, жалко не удалось ее попробовать в бытность с SCE-2020.

      Удалить
  5. День добрый!
    Цитата: "Каждый SCM-E может обрабытывать до 7.5Gbps трафика в каждую из сторон."
    Интересно, получается что если трафик не семмитричный то всеравно будет не более 7.5 Gbps в сторону?

    ОтветитьУдалить
    Ответы
    1. Насколько помню информация подтверждалась на форумах nag.ru. К тому же в настройках SCE максимально возможная полоса при одном SCM-E для GBC выставляется в 7.5 гбпс. Как на up так и на down.

      Удалить
  6. Артем, добрый день!

    Подскажите из опыта - если мы включаем пару SCE2k в общий etherchannel для балансировки нагрузки, в них есть какой-то механизм для синхронизации загрузки SBC? Т.е. если мы пользователю напилили полосу в 20Mbps downstream и 10Mbps upstream и воткнули пару SCE в одно устройство с использованием vlan translation (как это нарисовано у циски в CG http://goo.gl/bS2oN) - то как реализуется именно суммарная такая полоса для пользователя, ведь flow при этом как минимум в одну сторону будут раскидываться между SCE?

    Вопрос чисто теоретический, планирую использовать SCE в дизайне и не могу найти ответа на этот вопрос.

    ОтветитьУдалить
    Ответы
    1. Если не ошибаюсь с двумя SCE2k можно только организовать топологию в которой только одна SCE2k является активной, а вторая используется в качестве резерва. В системе N+1 (SCE8K ?) активными могут быть N SCE. Но и в этом случае накладывается условие, что flow пользователя должен проходить через единственную платформу (SCE).

      Удалить
    2. На самом деле можно и с двумя SCE организовать топологию active-active, но проблема как раз в прохождении flow через одну SCE в одну сторону (и совершенно не обязательно через ту же в другую - главное, чтобы одну единственную).

      Я уже разобрался в вопросе. Дело в том, что единственный вариант реализовать подобную схему на одном шасси - действительно платформа 76/C65 с dCEF. В этом случае можно выставлять режим балансировки etherchannel не на всё шасси в целом, а только на одну лайнкарту.
      Т.е. имея Cat65 с двумя гигабитными лайнкартами (например, 6724), можно включить на одной балансировку по src ip и воткнуть в нее subscriber ports, а на второй - по dst ip и воткнуть network ports соответственно.
      Это полностью выполняет требования задачи, особенно если не забыть включить asymmetric routing на SCE :)

      Однако, это только в случае, когда нужно воткнуть SCE в одно устройство всеми портами (хотя это наиболее гибкий вариант, разумеется). В случае же, когда мы хотим побюджетнее, можно добавить в качестве агрегатора портов в одну из сторон SCE любой Catalyst (например 3560X).
      Хотя я противник использования акцессного оборудования в опорной сети (и с теми же 3560 уже неоднократно наступал на грабли функционала), но когда край как надо сэкономить деньги - это вполне работающая схема.

      Удалить
    3. У нас было для этих целей две 3750 :) За два года проблем с функционалом не было.

      Удалить
  7. Здравствуйте Артем. У меня есть вопрос на счет sce 1010. Он у нас управляет трафиком на внешку, разумеется шейпит трафик.Может ли такое что некоторые торрент трафик он пропускает и даже не фиксирует на репортире? Sce скомплектован софтом 3,8,5 Протокол Пак 32. У клиента uTorrent 3.3 .

    ОтветитьУдалить