ПредисловиеТ.к никакого другого 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.
