it-sketch

Немного про коды завершений PPP сессий

2011-11-23T23:48:00.001-08:00

http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/sec_vsa_rad_discnct.html

RADIUS Disconnect-Cause Attribute Values

PPP-Remote-Terminate =- PPP received a Terminate Request from remote end.

AC получает PPP Termination пакет от хоста (нормальное завершение сессии)

PPP can terminate the link at any time. This might happen because of
   the loss of carrier, authentication failure, link quality failure,
   the expiration of an idle-period timer, or the administrative closing
   of the link.

User-Ends-Session - User terminates a session.

AC получает PADT от клиента. Тоже нормальное завершение сессии.

The PPPoE Active Discovery Terminate (PADT) packet This packet may be sent anytime after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the Host or the Access Concentrator. When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination packets MUST NOT be sent after sending or receiving a PADT. A PPP peer SHOULD use the PPP protocol itself to bring down a PPPoE session, but the PADT MAY be used when PPP can not be used.

Если честно, я этот код получить так и не смог, но завершений сессий с таким кодом примерно 1/3.

Idle-Timeout - Timeout waiting for user input.
отсутствие активности сессии

Local-Admin-Disconnect - Administrative disconnect.
Сессия принудительно прервана со стороны AC (послан PADT)

Session-Timeout - Session timed out
вышла максимальная продолжительность сессии.

Foreign-Host-Close-TCP - TCP connection has been closed
Вот это сессия аварийно оборвалась (линк упал, хост аварийно перезагрузился, еще что то случилось)

Failed-PPP-LCP-Negotiation - PPP LCP negotiation failed
Еще до стадии PPP-authentication не дошло и прервалась установка ppp сессии (LCP не смог перейти в open state и сказал Close). Стороны не договорились о конфигурации канала, кривые настройки хоста скорее всего.

Failed-PPP-CHAP-Auth - PPP CHAP authentication failed.
отлуп по authentication (имя/пароль)

CentOS (hints)

2011-11-22T09:21:00.001-08:00

Проблемы с доступом до серверов на CentOS снаружи из за Slinux и iptables

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

#getsebool -a               - варианты политик SeLinux

/etc/selinux/targeted/booleans - оно же в файле

setsebool -P httpd_can_network_connect on - установить значение для политики SeLinux

отключение:
cat /etc/selinux/config

SELINUX=disabled
SELINUXTYPE=targeted
SETLOCALDEFS=0

iptables
выключить/включить:
/etc/init.d/iptables stop/start

Легко вычисляем dependencies для пакетов

ldd - print shared library dependencies

# ldd skype
    linux-gate.so.1 => (0xf77ae000)
    libasound.so.2 => /lib/libasound.so.2 (0xf76b2000)
    libXv.so.1 => /usr/lib/libXv.so.1 (0xf76ad000)
    libXss.so.1 => /usr/lib/libXss.so.1 (0xf76aa000)
    librt.so.1 => /lib/librt.so.1 (0xf76a1000)
    libQtDBus.so.4 => not found
    libQtGui.so.4 => not found
    libQtNetwork.so.4 => not found
    libQtCore.so.4 => not found
    libpthread.so.0 => /lib/libpthread.so.0 (0xf7685000)
    libstdc++.so.6 => not found
    libm.so.6 => /lib/libm.so.6 (0xf765a000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf763c000)
    libc.so.6 => /lib/libc.so.6 (0x007eb000)
    libdl.so.2 => /lib/libdl.so.2 (0xf7637000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0xf74fe000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0xf74ed000)
    /lib/ld-linux.so.2 (0x007c9000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf74cf000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0xf74cc000)

и ставим недостающие
yum install libQtDBus.so.4 libQtGui.so.4
Да, yum найдет нужные пакеты прямо так.

Полезные репозитории:

EPOL
rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm

RPMFORGE
rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

ELREPO
rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm

CentALT
rpm -Uvh http://centos.alt.ru/pub/repository/centos/6/x86_64/centalt-release-6-1.noarch.rpm

VPN в Gnome (мало ли пригодится) :
Поставить пакеты из EPOL репозитория:
NetworkManager-openvpn.x86_64 : NetworkManager VPN plugin for OpenVPN
NetworkManager-pptp.x86_64 : NetworkManager VPN plugin for pptp

Iptables (подробный мануал):
http://www.opennet.ru/docs/RUS/iptables/

Предотвращение автоматического обновления пакета:
например, пакет pppoe
echo pppoe hold | dpkg —set-selections

Правка timezone без правки zone файла
например, делаем ссылку файла локальной зоны на нужную нам.
# ln -sf /usr/share/zoneinfo/Etc/GMT-4 /etc/localtime

Анализатор логов (logwatch)
yum install logwatch.noarch

настройки etc/logwatch/

Ежедневный запуск в кроне
ln -s /etc/logwatch/scripts/logwatch.pl /etc/cron.daily/00-logwatch

Logwatch может анализировать логи на предмет различных событий, отслеживать конкретные сервисы, составлять репорты и отсылать уведомления о странной активности в логах на нужные емайлы.

Asterisk (hints)

2011-11-20T23:12:00.001-08:00

Периодический рестарт астериска.

Приходиться делать, т.к выжирает память и начинаются проблемы со звонками

03 5 * * 1-6 /usr/sbin/asterisk -rx 'restart when convenient' > /dev/null - каждый день в 5:30 отдается команда мягкого рестарта (когда нет активных звонков)
50 6 * * sun /usr/sbin/asterisk -rx 'restart now' > /dev/null - а по воскресениям астер дергается жестко.

Односторонняя слышимость:

1) Кодеки
2) Не стоит canreinvite=no и канал пытается завязаться напрямую на телефон.
3) firewall или NAT.
4) rtp.conf описывает малый диапазон портов

Нормальные значения:
/asterisk/rtp.conf
rtpstart=10000
rtpend=50000

Частая перерегистрация большого кол-ва клиентов вызывает рост CPU и возможные проблемы качества связи:

Нормальное значение:

sip.conf
defaultexpiry=3600

Астериск может регулярно крашиться из-за SIP session timers (1.6.x полноценно их не обрабатывает), стоит их отрубить.

sip.conf
;workaround for asteriks crash
session-timers = refuse

Диагностика потоков E1:

e1gw1*CLI> pri show spans

PRI span 1/0: Provisioned, Up, Active

PRI span 2/0: Provisioned, Up, Active

PRI span 3/0: Provisioned, Up, Active

PRI span 4/0: Provisioned, Up, Active

e1gw1*CLI> dahdi show status

Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO

T4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)

T4XXP (PCI) Card 0 Span 2 OK 0 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)

T4XXP (PCI) Card 0 Span 3 OK 0 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)

T4XXP (PCI) Card 0 Span 4 OK 0 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1

Red alarm
---

Your T1/E1 port will go into red alarm when it maintain
synchronization with the remote switch. A red alarm
typically indicates either aphysical wiring problem,
loss of connectivity, or a framing and/or line-coding
mismatch with the remote switch. When your T1/E1 port
loses sync, it will transmit a yellow alarm to the remote
switch to indicatethat it's having a problem receiving
signal from the remore switch.(The easy way to remember
this is that the R in red stands for "right here" and "receive".
.. indicating that we're having a problem right here
receiving the signal from the remote switch.)

Yellow alarm or RAI (Remote Alarm Indication)
---
Your T1/E1 port will go into yellow alarm when it receives a
signal from the remote switch that the port on that remote
switch is in red alarm.This essentially means that the remote
switch is not able to maintain sync with you, or is not receiving
your transmission. (The easy way to remember this is that t
he Y in yellow stands for "yonder"... indicating that the
remote switch (over yonder) isn't able to see what you're
sending.)

Blue alarm or AIS (Alarm Indication Signal)
---
Your T1/E1 port will go into blue alarm when it receives all
unframed 1s on all timeslots from the remote switch. This is
a special signal to indicate that the remote switch is
having problems with it's upstream connection.

pri set debug

/var/log/asterisk/messages

Шумы, скрип, хрипы:

Возможна проблема с потоком E1 (ошибки). Так же качество может страдать из-за высокой загрузки астериска.

Перевод звонка по условию утилизации определенного кол-ва каналов:

exten => _31555[15],1,Set(GROUP()=12)
exten => _31555[15],2,GotoIf($[${GROUP_COUNT(12)} > 12]?20) - при более 12 одновременных звонков идем на приоритет 20.
exten => _31555[15],3,Dial(SIP/33000/${EXTEN}) - иначе звоним на 33000
exten => _31555[15],20,Set(GROUP()=16)
exten => _31555[15],21,GotoIf($[${GROUP_COUNT(16)} > 20]?30) - при более 20 одновременных звонков идем на приоритет 30
exten => _31555[15],22,Dial(H323/33333@test/${EXTEN}) - иначе звоним 33333
exten => _31555[15],30,Goto(hangup,0,1)

Ограничение регистрации определенными IP

Данная настройка ограничивает возможность регистрации абонентов только с доверенных IP адресов. Задается для каждого extension

[vasya]
Deny=0.0.0.0/0.0.0.0
Permit=192.168.1.1
Permit=192.168.1.0/24
Где 192.168.1.0/24 – диапазон адресов, с которых будет проходить регистрация. С других адресов регистрации будут отбиваться астером.

Не посылать ответ о неверном пароле

По умолчанию Asterisk выдает одну ошибку о неверном пароле для существующего аккаунта и другую для несуществующего аккаунта. Это удобно для фродеров при подборе пароля:

Избавляемся от такой дыры:
sip.conf:

alwaysauthreject = no

Теперь для неверных авторизаций астер говорит «401 Unauthorized».

Использование Iptables b Fail2ban

Fail2ban можно настроиь на вылавливание любых событий в логах и создание правил в iptables. Например, блокировать IP с которых приходят запросы с неверными реквизитами

Дальше не мое (взято с хабра):

Однако, есть несколько неприятных ситуаций, в которых анализ лога Asterisk не поможет. Например, в случае когда злоумышленник посылает запрос REGISTER без идентификационных данных – в логе никогда не появится сообщение «Wrong password».

Дело в том, что в Asterisk вся SIP UDP сигнализация обрабатывается одним единственным тредом. Обработка SIP трафика – ресурсоёмкий процесс, 7-8 мегабит мусорных запросов заставляют Asterisk полностью скушать ядро процессора (например Intel E5335, E5405). Когда ядро полностью съедено, происходит вытеснение полезного SIP трафика – мусорным.

Перестают работать DTMF у клиентов использующих SIP INFO. Начинаются проблемы с установкой новых и завершением существующих соединений. И вот это – основная угроза которую несут роботы-брутфорсеры.

Так как же бороться с проблемами о которых нет сообщений в логах? Очень просто – необходимо сгенерировать сообщение о проблеме самому, тогда всю остальную часть нашей системы противодействия (например программу fail2ban) можно будет оставить без изменений. Характерным признаком брутфорса является большое количество SIPпакетов в единицу времени.

Посчитать количество пакетов в единицу времени можно с помощью модуля iptables под названием recent. В интернете есть много примеров как с помощью модуля recent отбрасывают пакеты приходящие с частотой выше определённой. Мы, вместо отбрасывания, будем генерировать сообщения для нашей системы обнаружения атак (например fail2ban). Такой подход имеет свои недостатки и преимущества. Основным недостатком является, то что на обработку сообщений будут тратиться ресурсы системы, тогда как отбрасывание пакета условно бесплатное.

Преимуществ чуть больше: мы сможем воспользоваться всеми возможностями нашей системы обнаружения атак, такими как белые списки IP адресов, единообразный учёт всех обнаруженных атак и так далее.

От теории – к практике! Подготовим скелет из правил iptables:

-A INPUT -p udp --dport 5060 -j SCAMBLOCK
-A INPUT -p udp --dport 5060 -m recent --set --name SIP
-A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix «SIP flood detected: „

Первое правило проверяет наш пакет по цепочке SCAMBLOCK. В данной цепочке хранятся заблокированные IP адреса, если пакет совпадает с одним из адресов этой цепочки – он отбрасывается. Если пакет не отброшен, то во втором правиле он помечается для учёта под именем SIP. Третье правило считает не превысил ли данный пакет указанное количество (60) за указанное время (2 секунды).

Если количество не превышено – правило игнорируется, если превышено – выполняется действие. В нашем случае в системный лог пишется детальная информация о пакете начинающаяся со строки «SIP flood detected: «. Количество пакетов и время считаются отдельно для каждого источника. Таким образом получается, что мы ограничили скорость приёма SIP пакетов от каждого незаблокированного IP адреса на уровне 30 пакетов в секунду.

Для меня данное ограничение является комфортным, с одной стороны все клиенты, даже самые крупнные, шлют пакеты с одного IP адреса со скоростями ниже 30 пакетов/с, с другой стороны, 30 пакетов в секунду практически не отражаютя на работе системы. Возможно, что эту величину следует подправлять в ту или иную сторону в зависимости от производительности сервера, количества и типа абонентов.

В некоторых системах встроенное ограничение модуля recent на параметр hitcount весьма небольшое, например в CentOS это ограничение составляет 20 пакетов. Если вы попробуете выполнить приведенную выше команду, то получите следующую ошибку:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix “SIP flood detected: „
iptables: Unknown error 4294967295
Или вот так, для 64 битных систем:
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix “SIP flood detected: „
iptables: Unknown error 18446744073709551615

Изменить максимальное ограничение можно передав модулю recent специальный параметр при загрузке. Для этого создадим файл /etc/modprobe.d/ipt.conf и пропишем в нём интересующий нас параметр:

options ipt_recent ip_pkt_list_tot=60

Будьте осторожны увеличивая данное ограничение, помните что вместе с ним увеличивается память, требуемая для хранения последних пакетов, а также количество циклов процессора требуемые на их обработку.

Ну вот и всё, теперь любой флуд на порт 5060 будет обнаружен с помощью модуля recent пакета iptables. Сообщение об обнаруженном флуде будет направлено в системный лог где его сможет увидеть наша любимая система обнаружения атак (например fail2ban). iptables не ограничивает нас одним лишь системным логом, действию LOG можно указать уровень (level) и facility сообщения, а в настройках Syslog перенаправить данные сообщения в отдельный файл. Сами же сообщения о SIP флуде будут выглядеть вот так:

Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:

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

2011-11-18T09:20:00.000-08:00

Предисловие

Т.к никакого другого 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.