Защита от DOS атак - дополнение для h323.
В дополнение к первой части приводится метод расчета параметров для протокола h323.
При разработке метода использовались те же допущения, что и для SIP.
Уровень Access Control & Realm
Схема peer
Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 49600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 12480
untrusted-signal-threshold = 12480
average-rate-limit - ограничение на величину сигнального трафика, расчитывается как максимально возможная
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
H225 CallProc - 167
H225 Progress - 226
H225 Alerting - 225
H225 Facility - 135
H225 Facility - 135
H225 Facility - 135
H225 Facility - 135
H245 TermCapSetReq - 89
H245 MSDReq - 138
H245 TermCapSetAck - 73
H245 MSDAsk - 72
H225 Connect - 248
H225 Facility - 135
H245 ReqMode - 97
H245 CloseLCAck - 74
H245 CloseLCReq - 78
H245 OpenLCAck - 93
H245 OpenLCReq - 102
H245 ReqMode - 77
H245 ReqModeAck - 74
H245 CloseLCAck - 74
H245 CloseLCReq - 78
H245 OpenLCAck - 93
H225 RLC - 117
H225 Facility - 135
H245 EndSessCmd - 72
SUM(h323 message)*30*8/30= 3077*8 = 24616 byte/sec
но такая точность нам ни к чему, несколько вольно округлим:
3100*8= 24800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 49600 byte/sec.
В результате получаем формулу расчета
average-rate-limit = 6200 * Количество портов
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (см. выше), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*26=6240
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 12480, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 1560 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Setup, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.
Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold
среда, 24 ноября 2010 г.
пятница, 21 мая 2010 г.
Отражение VoIP
Эта колонна наилучшим образом отражает ситуацию с VoIP - также сложно создать, а то что создано - также ненадежно!
воскресенье, 28 февраля 2010 г.
Acme Packet - это просто. Часть II.
Защита от DOS атак.
Как известно, каждый повар готовит борщ по-своему, и следуя этому утверждению, ниже приводится всего лишь один из рецептов настройки оборудования Acme Packet.
Некоторые из приведенных параметров не относятся напрямую к системе защиты, но приведены в описании просто потому, что эти параметры требовали изучения, проверки
и корректировки.
Итак, если вы купили пакет DDOS, то у вас появляется возможность настраивать защитные механизмы системы Acme Packet.
В системе Acme Packet можно найти следующие ограничения:
- системные ограничения - максимальное число сообщений в секунду, которое может обработать система;
- максимальная длина SIP пакета;
- максимальная длина UDP пакета;
- ограничения по IP адресам и портам;
- ограничения по протоколам;
- ограничения полезного трафика (основаны на понятиях trusted and untrusted traffic).
Мы не будем следовать этому перечислению, а пойдем по пути, который предлагает SD.
Уровень SIP Config
Ограничения на длину пакета:
sip-message-len = 2000
max-udp-length = 2000
Название параметров говорит само за себя, параметр max-udp-length изменяется в поле option.
Уровень Session Agent
Ограничение на количество сессий, налагаемое на конкретное устройство.
max-sessions = 8 - количество сессий для 8-портового шлюза, равно количеству портов на шлюзе
Для контроля за колличеством сессий нужно включить опцию:
constraints enabled
Уровень Media Manager
Если на SBC включена возможность приема ICMP пакетов, то на уровне Media Manager существует системное ограничение в 8Kbs.
max-signaling-bandwidth = 1720000 - максимальное количество сообщений, которое сможет обработать SD, значение приведено для NN3800, это значение аппаратнозависимое и отличается для других SD.
Аппаратнозависимые параметры определяющие емкость ACL.
Меняются лишь при изменении аппаратной платформы.
min-media-allocation = 2000
min-trusted-allocation = 4000
deny-allocation = 64000
arp-msg-bandwidth - полоса разрешенная для ARP запросов (по умолчанию 32000) без необходимости изменять, наверное, не надо.
flow-time-limit = 28800 - 8 часов непрерывной работы сессии (по умолчанию 24 часа)
initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
Эти таймеры срабатывают при пропадании RTP потока, но также могут сработать, если передача идет лишь в одном направлении, например, при передаче факсимильного сообщения.
Далее опишу свое видение системы ограничений, налагаемых на полезный трафик, проходящий через систему; я не буду придерживаться водопроводной терминологии из документации, при желании Вы можете прочесть ее, что я настоятельно и рекомендую.
При описании модели поведения нужно описать те характеристики и ограничения, в соответствии с которыми она и будет формироваться.
- Если вызов принадлежит доверенному пользователю, этот вызов должен состояться.
- Часть злонамереннных сообщений пройдет через SD.
- Система обеспечивает обе схемы: и peer, и access.
- Схема peer запрещает любой трафик, и для разрешения требуется прописать исключение.
- Контроль за схемой access возложен на сервер регистраций.
- Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, либо при установлении соединения.
- Расчеты производим для протокола SIP.
- Для схемы peer расчет производится для входящего на шлюз вызова, а для схемы access - для исходящего, при этом учитывается максимальный сигнальный трафик.
- Каждый абонентский порт шлюза может генерировать или получать 1 вызов в секунду при максимальной нагрузке (установка сервиса автодозвон).
Весь трафик, входящий в SBC, делится на TRUSTED, UNTRUSTED и FRAGMENTED.
fragment-msg-bandwidth - полоса для фрагментированных пакетов, если fragment-msg-bandwidth = 0, то все фрагментированные пакеты идут как UNTRUSTED, и только при сборе всего пакета переходит в TRUSTED.
Предположим, что количество фрагментированных пакетов велико, для расчета предположим, что величина этого трафика может достигать половины максимально возможного, результат для NN3800: fragment-msg-bandwidth = 1720000/2 = 860000
Следующие два параметра образуют плавающее окно для UNTRUSTED трафика, окно обеспечивает прохождение сообщений, которые используются для идентификации трафика и перевода его в TRUSTED, например, Register.
max-untrusted-signaling = 6% от max-signaling-bandwidth, это максимальное значение окна в процентах от максимальной полосы, UNTRUSTED трафик не может превышать этого значения. Рекомендуемые значения для схемы peer - 1%, access - 5%, в сумме 6%.
min-untrusted-signaling = 5% от max-signaling-bandwidth, это минимальное значение окна в процентах от максимальной полосы, эта полоса всегда выделена для UNTRUSTED трафика, даже если нагрузка TRUSTED трафика приближается к 100%. Рекомендуемые значения для схемы peer - 1%, access - 4%, в сумме 5%.
Уровень Access Control & Realm
Схема peer
Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 45600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2400
untrusted-signal-threshold = 2400
average-rate-limit - ограничение на величину сигнального трафика, расчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе + сумма дополнительных сервисных сообщений в байтах * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
PRACK - 517
ACK for Invite with Authentication - 555
BYE - 495
Сервисные сообщения:
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение - каждый абонентский порт шлюза может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портового шлюза:
((1150+517+555+495)*30+916+790+344+977)*8/30= 22543.2 byte/sec
или
(2717*30+3027)*8/30= 22543.2 byte/sec
но такая точность нам ни к чему, несколько вольно округлим и упростим:
(2750+100)*8=2850*8= 22800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 45600 byte/sec.
В результате получаем формулу расчета
average-rate-limit = 5700 * Количество портов
invalid-signal-threshold - порог пакетов с ошибками, устанавливаем 0.
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (100 Trying, 183 Session Progress, 200 OK for PRACK, 200 OK for INVITE, 200 OK for BYE), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*5=1200
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2400, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 300 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Invite, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.
Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold
Схема access
Пример параметров для 8-портовой PBX.
access = permit
average-rate-limit = 81600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2880
untrusted-signal-threshold = 4
В этой схеме верны все допущения схемы peer, кроме изменения состояния; переход из UNTRUSTED в состояние TRUSTED происходит при удачной регистрации. Расчет производится для одного зарегистрированного пользователя, но так как этот пользователь может представлять из себя многопортовое устройство (например IP PBX), то и расчет производится по той же методике. Но для расчета нужно определиться с устройством, у которого будет максимальное количество портов во всей сети, скрытое за одной регистрацией, и все расчеты произвести для него.
average-rate-limit - ограничение на величину сигнального трафика, рассчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на PBX + сумма дополнительных сервисных сообщений в байтах * количество портов на PBX, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
ACK - 555
INVITE with Authentication - 1400
PRACK - 517
ACK for Invite with Authentication - 815
BYE - 495
Сервисные сообщения:
REGISTER - 564
REGISTER with Authentication - 870
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
((1150+555+1400+517+815+495)*30+564+870+916+790+344+977)*8/30= 40645.6 byte/sec
или
(4932*30+4461)*8/30= 40645.6 byte/sec
такая точность опять же ни к чему, округлим и упростим:
(4950+150)*8=5100*8= 40800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портовой PBX average-rate-limit = 81600 byte/sec.
Формула для расчета
average-rate-limit= 10200 * Количество портов
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (INVITE, ACK, INVITE, PRACK, ACK, BYE).
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
8*1*30*6=1440
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2880, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд -
maximum-signal-threshold = 360 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, для удачной регистрации требуется лишь два SIP сообщения Register. Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 4. Но как показывает практика VoIP абонент может генерировать больше сообщений до момента удачной регистрации. Методом проб и ошибок остановились на значении 8.
Результат для схемы access:
untrusted-signal-threshold = 8
Как известно, каждый повар готовит борщ по-своему, и следуя этому утверждению, ниже приводится всего лишь один из рецептов настройки оборудования Acme Packet.
Некоторые из приведенных параметров не относятся напрямую к системе защиты, но приведены в описании просто потому, что эти параметры требовали изучения, проверки
и корректировки.
Итак, если вы купили пакет DDOS, то у вас появляется возможность настраивать защитные механизмы системы Acme Packet.
В системе Acme Packet можно найти следующие ограничения:
- системные ограничения - максимальное число сообщений в секунду, которое может обработать система;
- максимальная длина SIP пакета;
- максимальная длина UDP пакета;
- ограничения по IP адресам и портам;
- ограничения по протоколам;
- ограничения полезного трафика (основаны на понятиях trusted and untrusted traffic).
Мы не будем следовать этому перечислению, а пойдем по пути, который предлагает SD.
Уровень SIP Config
Ограничения на длину пакета:
sip-message-len = 2000
max-udp-length = 2000
Название параметров говорит само за себя, параметр max-udp-length изменяется в поле option.
Уровень Session Agent
Ограничение на количество сессий, налагаемое на конкретное устройство.
max-sessions = 8 - количество сессий для 8-портового шлюза, равно количеству портов на шлюзе
Для контроля за колличеством сессий нужно включить опцию:
constraints enabled
Уровень Media Manager
Если на SBC включена возможность приема ICMP пакетов, то на уровне Media Manager существует системное ограничение в 8Kbs.
max-signaling-bandwidth = 1720000 - максимальное количество сообщений, которое сможет обработать SD, значение приведено для NN3800, это значение аппаратнозависимое и отличается для других SD.
Аппаратнозависимые параметры определяющие емкость ACL.
Меняются лишь при изменении аппаратной платформы.
min-media-allocation = 2000
min-trusted-allocation = 4000
deny-allocation = 64000
arp-msg-bandwidth - полоса разрешенная для ARP запросов (по умолчанию 32000) без необходимости изменять, наверное, не надо.
flow-time-limit = 28800 - 8 часов непрерывной работы сессии (по умолчанию 24 часа)
initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
Эти таймеры срабатывают при пропадании RTP потока, но также могут сработать, если передача идет лишь в одном направлении, например, при передаче факсимильного сообщения.
Далее опишу свое видение системы ограничений, налагаемых на полезный трафик, проходящий через систему; я не буду придерживаться водопроводной терминологии из документации, при желании Вы можете прочесть ее, что я настоятельно и рекомендую.
При описании модели поведения нужно описать те характеристики и ограничения, в соответствии с которыми она и будет формироваться.
- Если вызов принадлежит доверенному пользователю, этот вызов должен состояться.
- Часть злонамереннных сообщений пройдет через SD.
- Система обеспечивает обе схемы: и peer, и access.
- Схема peer запрещает любой трафик, и для разрешения требуется прописать исключение.
- Контроль за схемой access возложен на сервер регистраций.
- Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, либо при установлении соединения.
- Расчеты производим для протокола SIP.
- Для схемы peer расчет производится для входящего на шлюз вызова, а для схемы access - для исходящего, при этом учитывается максимальный сигнальный трафик.
- Каждый абонентский порт шлюза может генерировать или получать 1 вызов в секунду при максимальной нагрузке (установка сервиса автодозвон).
Весь трафик, входящий в SBC, делится на TRUSTED, UNTRUSTED и FRAGMENTED.
fragment-msg-bandwidth - полоса для фрагментированных пакетов, если fragment-msg-bandwidth = 0, то все фрагментированные пакеты идут как UNTRUSTED, и только при сборе всего пакета переходит в TRUSTED.
Предположим, что количество фрагментированных пакетов велико, для расчета предположим, что величина этого трафика может достигать половины максимально возможного, результат для NN3800: fragment-msg-bandwidth = 1720000/2 = 860000
Следующие два параметра образуют плавающее окно для UNTRUSTED трафика, окно обеспечивает прохождение сообщений, которые используются для идентификации трафика и перевода его в TRUSTED, например, Register.
max-untrusted-signaling = 6% от max-signaling-bandwidth, это максимальное значение окна в процентах от максимальной полосы, UNTRUSTED трафик не может превышать этого значения. Рекомендуемые значения для схемы peer - 1%, access - 5%, в сумме 6%.
min-untrusted-signaling = 5% от max-signaling-bandwidth, это минимальное значение окна в процентах от максимальной полосы, эта полоса всегда выделена для UNTRUSTED трафика, даже если нагрузка TRUSTED трафика приближается к 100%. Рекомендуемые значения для схемы peer - 1%, access - 4%, в сумме 5%.
Уровень Access Control & Realm
Схема peer
Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 45600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2400
untrusted-signal-threshold = 2400
average-rate-limit - ограничение на величину сигнального трафика, расчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе + сумма дополнительных сервисных сообщений в байтах * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
PRACK - 517
ACK for Invite with Authentication - 555
BYE - 495
Сервисные сообщения:
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение - каждый абонентский порт шлюза может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портового шлюза:
((1150+517+555+495)*30+916+790+344+977)*8/30= 22543.2 byte/sec
или
(2717*30+3027)*8/30= 22543.2 byte/sec
но такая точность нам ни к чему, несколько вольно округлим и упростим:
(2750+100)*8=2850*8= 22800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 45600 byte/sec.
В результате получаем формулу расчета
average-rate-limit = 5700 * Количество портов
invalid-signal-threshold - порог пакетов с ошибками, устанавливаем 0.
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (100 Trying, 183 Session Progress, 200 OK for PRACK, 200 OK for INVITE, 200 OK for BYE), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*5=1200
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2400, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 300 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Invite, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.
Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold
Схема access
Пример параметров для 8-портовой PBX.
access = permit
average-rate-limit = 81600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2880
untrusted-signal-threshold = 4
В этой схеме верны все допущения схемы peer, кроме изменения состояния; переход из UNTRUSTED в состояние TRUSTED происходит при удачной регистрации. Расчет производится для одного зарегистрированного пользователя, но так как этот пользователь может представлять из себя многопортовое устройство (например IP PBX), то и расчет производится по той же методике. Но для расчета нужно определиться с устройством, у которого будет максимальное количество портов во всей сети, скрытое за одной регистрацией, и все расчеты произвести для него.
average-rate-limit - ограничение на величину сигнального трафика, рассчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на PBX + сумма дополнительных сервисных сообщений в байтах * количество портов на PBX, и все это поделить на величину окна измерения (по умолчанию 30 секунд)
В установлении вызова участвуют следующие сообщения:
INVITE - 1150
ACK - 555
INVITE with Authentication - 1400
PRACK - 517
ACK for Invite with Authentication - 815
BYE - 495
Сервисные сообщения:
REGISTER - 564
REGISTER with Authentication - 870
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
((1150+555+1400+517+815+495)*30+564+870+916+790+344+977)*8/30= 40645.6 byte/sec
или
(4932*30+4461)*8/30= 40645.6 byte/sec
такая точность опять же ни к чему, округлим и упростим:
(4950+150)*8=5100*8= 40800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портовой PBX average-rate-limit = 81600 byte/sec.
Формула для расчета
average-rate-limit= 10200 * Количество портов
maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (INVITE, ACK, INVITE, PRACK, ACK, BYE).
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
8*1*30*6=1440
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2880, тем самым будут учтены возможные дополнительные сообщения.
Окончательный вариант расчета для окна 30 секунд -
maximum-signal-threshold = 360 * Количество портов
untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, для удачной регистрации требуется лишь два SIP сообщения Register. Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 4. Но как показывает практика VoIP абонент может генерировать больше сообщений до момента удачной регистрации. Методом проб и ошибок остановились на значении 8.
Результат для схемы access:
untrusted-signal-threshold = 8
среда, 24 февраля 2010 г.
Acme Packet - это просто. Часть I.
Старт.
Получив на руки SD NN3800, мы видим специализированный сервер, который по сути ничем не отличается от других. Берем документацию, вооружаемся компьютером и отверткой. И ,приступив к инсталяции, сталкиваемся с некоторыми особенностями (американизмами), а именно: крепеж нестандартный (прикрутить можно только своими винтами), кабель терминала тоже отличается от Cisco кабеля, а мы так к нему уже привыкли. Вот и получается, что для начала нужно взять прямой Ethernet кабель и через прилагаемый переходник соединить COM (RS-232) порт нашего компьютера с консольным портом SBC, который расположен на лицевой панели.
На задней панели расположены Ethernet интерфейсы, слева-направо:
1) Maintenance slot 0 port 0 - Интерфейс управления - прописывается в bootparam
2) Maintenance slot 0 port 1 - резервирование
3) Maintenance slot 0 port 2 - резервирование
4) Media slot 0 port 0 - Media потоки
5) Media slot 0 port 1 - Media потоки
7) Media slot 1 port 0 - Media потоки
8) Media slot 1 port 1 - Media потоки
Итак, мы подключились. Получили приглашение - нужен логин и пароль, ищем их в документации и ничего не находим...
Что ж, вот они:
login: user
password: acme
login: admin
password: packet
Заходим под admin, и если появилось нечто и #, то можно двигаться дальше.
Bootparam
Параметры загрузки живут в bootparam
Здесь нас интересует
inet on ethernet (e) : 192.168.2.2:ffffff00
gateway inet (g) : 192.168.2.1
ffffff00 - это маска сети.
Для изменения интересующего нас параметра вводим новое значение в той же строке.
Сеть для интерфейса управления желательно выбрать отличную от сети сигнального и потокового трафика.
После этого можно подключаться по SSH.
Если у вас планируется установка с резервированием, то те же настройки нужно произвести и на втором сервере, естественно с другим IP адресом и другим host name.
CLI
Перед дальнейшей настройкой требуется описать особенности CLI.
К сожалению, CLI Acme Packet отличается от Cisco, и, как факт, менее удобен для пользователя. В чем отличие - в выборе определенного конфигурационного элемента, то есть, если нужно отредактировать phy-interface wancom1, то нужно дать следующую последовательность:
(а вот тут появляется особенность!)
Команда select определяет конфигурируемый элемент, что не дает пользователю скопировать часть конфигурационного файла и, подправив, сконфигурировать другой элемент методом простой вставки.
Еще одно отличие (опять не в пользу Acme): для конфигурирования следующего элемента нужно закончить конфигурирование текущего командой done или exit, после exit появится запрос save yes/no.
При создании нового элемента команда select не выполняется (ну нечего пока выбирать).
Для полноты картины нужно указать, что дерево CLI сразу разделяется на несколько веток:
Зайдя в одну из веток, мы должны выйти и только затем зайти в другую, т.е. возможность конфигурирования параметра другой ветви не предусмотрена.
В логике такой системе не откажешь, но как-то неудобно...
Redundancy
Теперь конфигурируем систему резервирования (если, конечно, она у вас есть).
Ниже приведен листинг команды sh run:
Заходим на SBC-1 и программируем его.
Т.к. просто скопировать информацию с экрана и вставить ее мы не можем, придется создать всю эту красоту последовательно, руками.
Если про select забыли на консоль будет выведена ошибка и ничего не сохраниться.
Следуя далее в том же ключе, пытаемся привести конфиг к виду выше, благо большая часть параметров идет по умолчанию и не требует корректировки.
Добившись совпадения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Соединяем сервера кросс-кабелями
SBC-1 Maintenance slot 0 port 1 - SBC-2 Maintenance slot 0 port 1
SBC-1 Maintenance slot 0 port 2 - SBC-2 Maintenance slot 0 port 2
Заходим на SBC-2 и даем команду
acquire-config 192.168.xx.xx - на месте xx должен быть IP адрес SBC-1
Если все сделано верно, вы получаете зарезервированый SBC Acme Packet!
Далее все изменения достаточно производить лишь на активном сервере.
Посмотреть, какой именно активен, можно командой:
SBC-1# show health
Осталось настроить system-config:
link-redundancy-state - параметр определяющий поведение физических медиа интерфейсов.
Их всего 4, можно использовать каждый интерфейс по отдельности и тем самым увеличить пропускную способность на уровне физических интерфейсов до 2 Gb, но если принять за основу - сначала надежность, потом скорость, то параметр link-redundancy-state позволяет объединить физические интерфейсы попарно с помощью установки виртуального MAC адреса интерфейса. В результате получаем один дублированый 1GB интерфейс во внешнюю сеть и один дублированый 1GB интерфейс во внутреннюю сеть.
Какой куда, Media slot 0 или Media slot 1, определяется инженером, как удобно так нужно делать.
Результат:
Не забудем про часы:
Результат:
Для сохранения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Теперь холст готов, можно рисовать картину маслом!
Получив на руки SD NN3800, мы видим специализированный сервер, который по сути ничем не отличается от других. Берем документацию, вооружаемся компьютером и отверткой. И ,приступив к инсталяции, сталкиваемся с некоторыми особенностями (американизмами), а именно: крепеж нестандартный (прикрутить можно только своими винтами), кабель терминала тоже отличается от Cisco кабеля, а мы так к нему уже привыкли. Вот и получается, что для начала нужно взять прямой Ethernet кабель и через прилагаемый переходник соединить COM (RS-232) порт нашего компьютера с консольным портом SBC, который расположен на лицевой панели.
На задней панели расположены Ethernet интерфейсы, слева-направо:
1) Maintenance slot 0 port 0 - Интерфейс управления - прописывается в bootparam
2) Maintenance slot 0 port 1 - резервирование
3) Maintenance slot 0 port 2 - резервирование
4) Media slot 0 port 0 - Media потоки
5) Media slot 0 port 1 - Media потоки
7) Media slot 1 port 0 - Media потоки
8) Media slot 1 port 1 - Media потоки
Итак, мы подключились. Получили приглашение - нужен логин и пароль, ищем их в документации и ничего не находим...
Что ж, вот они:
login: user
password: acme
login: admin
password: packet
Заходим под admin, и если появилось нечто и #, то можно двигаться дальше.
Bootparam
Параметры загрузки живут в bootparam
SBC-1# conf t SBC-1(configure)# bootparam '.' = clear field; '-' = go to previous field; q = quit boot device : eth0 processor number : 0 host name : SBC-1 file name : /code/images/nnSCX610m2p7.gz inet on ethernet (e) : 192.168.2.2:ffffff00 inet on backplane (b) : host inet (h) : gateway inet (g) : 192.168.2.1 user (u) : vxftp ftp password (pw) (blank = use rsh) : vxftp flags (f) : 0x8 target name (tn) : SBC-1 startup script (s) : other (o) :
Здесь нас интересует
inet on ethernet (e) : 192.168.2.2:ffffff00
gateway inet (g) : 192.168.2.1
ffffff00 - это маска сети.
Для изменения интересующего нас параметра вводим новое значение в той же строке.
Сеть для интерфейса управления желательно выбрать отличную от сети сигнального и потокового трафика.
После этого можно подключаться по SSH.
Если у вас планируется установка с резервированием, то те же настройки нужно произвести и на втором сервере, естественно с другим IP адресом и другим host name.
CLI
Перед дальнейшей настройкой требуется описать особенности CLI.
К сожалению, CLI Acme Packet отличается от Cisco, и, как факт, менее удобен для пользователя. В чем отличие - в выборе определенного конфигурационного элемента, то есть, если нужно отредактировать phy-interface wancom1, то нужно дать следующую последовательность:
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# phy-interface SBC-1(phy-interface)#
(а вот тут появляется особенность!)
SBC-1(phy-interface)# select 1: wancom1 2: wancom2 selection: 1 SBC-1(phy-interface)# show phy-interface name wancom1 operation-type Maintenance port 1 slot 0 virtual-mac wancom-health-score 20
Команда select определяет конфигурируемый элемент, что не дает пользователю скопировать часть конфигурационного файла и, подправив, сконфигурировать другой элемент методом простой вставки.
Еще одно отличие (опять не в пользу Acme): для конфигурирования следующего элемента нужно закончить конфигурирование текущего командой done или exit, после exit появится запрос save yes/no.
При создании нового элемента команда select не выполняется (ну нечего пока выбирать).
Для полноты картины нужно указать, что дерево CLI сразу разделяется на несколько веток:
bootparam enter boot parameters media-manager configure media manager components ntp-sync configure time synchronization session-router configure session router components system configure general system components security configure security components
Зайдя в одну из веток, мы должны выйти и только затем зайти в другую, т.е. возможность конфигурирования параметра другой ветви не предусмотрена.
В логике такой системе не откажешь, но как-то неудобно...
Redundancy
Теперь конфигурируем систему резервирования (если, конечно, она у вас есть).
Ниже приведен листинг команды sh run:
phy-interface name wancom1 operation-type Maintenance port 1 slot 0 virtual-mac wancom-health-score 20 phy-interface name wancom2 operation-type Maintenance port 2 slot 0 virtual-mac wancom-health-score 20 network-interface name wancom1 sub-port-id 0 description hostname ip-address pri-utility-addr 169.254.1.1 sec-utility-addr 169.254.1.2 netmask 255.255.255.252 gateway sec-gateway gw-heartbeat state enabled heartbeat 10 retry-count 3 retry-timeout 1 health-score 30 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address network-interface name wancom2 sub-port-id 0 description hostname ip-address pri-utility-addr 169.254.2.1 sec-utility-addr 169.254.2.2 netmask 255.255.255.252 gateway sec-gateway gw-heartbeat state enabled heartbeat 10 retry-count 3 retry-timeout 1 health-score 30 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address redundancy-config state enabled log-level INFO health-threshold 75 emergency-threshold 50 port 9090 advertisement-time 500 percent-drift 210 initial-time 1250 becoming-standby-time 180000 becoming-active-time 100 cfg-port 1987 cfg-max-trans 10000 cfg-sync-start-time 5000 cfg-sync-comp-time 1000 gateway-heartbeat-interval 0 gateway-heartbeat-retry 0 gateway-heartbeat-timeout 1 gateway-heartbeat-health 0 media-if-peercheck-time 0 peer name SBC-1 state enabled type Primary destination address 169.254.1.1:9090 network-interface wancom1:0 destination destination-address 169.254.2.1:9090 network-interface wancom2:0 peer name SBC-2 state enabled type Secondary destination address 169.254.1.2:9090 network-interface wancom1:0 destination address 169.254.2.2:9090 network-interface wancom2:0
Заходим на SBC-1 и программируем его.
Т.к. просто скопировать информацию с экрана и вставить ее мы не можем, придется создать всю эту красоту последовательно, руками.
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# phy-interface SBC-1(phy-interface)# name wancom1 SBC-1(phy-interface)# operation-type Maintenance SBC-1(phy-interface)# port 1 SBC-1(phy-interface)# slot 0 SBC-1(phy-interface)# doneЕсли что-то ввели неправильно, для коррекции не забываем про select!
Если про select забыли на консоль будет выведена ошибка и ничего не сохраниться.
Следуя далее в том же ключе, пытаемся привести конфиг к виду выше, благо большая часть параметров идет по умолчанию и не требует корректировки.
Добившись совпадения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Соединяем сервера кросс-кабелями
SBC-1 Maintenance slot 0 port 1 - SBC-2 Maintenance slot 0 port 1
SBC-1 Maintenance slot 0 port 2 - SBC-2 Maintenance slot 0 port 2
Заходим на SBC-2 и даем команду
acquire-config 192.168.xx.xx - на месте xx должен быть IP адрес SBC-1
Если все сделано верно, вы получаете зарезервированый SBC Acme Packet!
Далее все изменения достаточно производить лишь на активном сервере.
Посмотреть, какой именно активен, можно командой:
SBC-1# show health
Осталось настроить system-config:
SBC-1# conf t SBC-1(configure)# system SBC-1(system)# system-config SBC-1(system-config)# select SBC-1(system-config)# hostname LAB SBC-1(system-config)# default-gateway 201.00.00.01 SBC-1(system-config)# link-redundancy-state enabled SBC-1(system-config)# done
link-redundancy-state - параметр определяющий поведение физических медиа интерфейсов.
Их всего 4, можно использовать каждый интерфейс по отдельности и тем самым увеличить пропускную способность на уровне физических интерфейсов до 2 Gb, но если принять за основу - сначала надежность, потом скорость, то параметр link-redundancy-state позволяет объединить физические интерфейсы попарно с помощью установки виртуального MAC адреса интерфейса. В результате получаем один дублированый 1GB интерфейс во внешнюю сеть и один дублированый 1GB интерфейс во внутреннюю сеть.
Какой куда, Media slot 0 или Media slot 1, определяется инженером, как удобно так нужно делать.
Результат:
system-config hostname LAB description location mib-system-contact mib-system-name mib-system-location snmp-enabled enabled enable-snmp-auth-traps disabled enable-snmp-syslog-notify disabled enable-snmp-monitor-traps disabled enable-env-monitor-traps disabled snmp-syslog-his-table-length 1 snmp-syslog-level WARNING system-log-level WARNING syslog-server process-log-level NOTICE process-log-ip-address 0.0.0.0 process-log-port 0 collect sample-interval 5 push-interval 15 boot-state disabled start-time now end-time never red-collect-state disabled red-max-trans 1000 red-sync-start-time 5000 red-sync-comp-time 1000 push-success-trap-state disabled call-trace disabled internal-trace disabled log-filter all default-gateway 201.00.00.01 restart enabled exceptions telnet-timeout 0 console-timeout 0 remote-control enabled cli-audit-trail enabled link-redundancy-state enabled source-routing disabled cli-more disabled terminal-height 24 debug-timeout 0 trap-event-lifetime 0
Не забудем про часы:
SBC-1# conf t SBC-1(configure)# ntp-sync SBC-1(configure)# select SBC-1(configure)# server 201.00.00.11 SBC-1(configure)# done
Результат:
ntp-config server 201.00.00.11
Для сохранения, выходим на самый верхний уровень CLI и даем команду
save-config
и
activate-config
Теперь холст готов, можно рисовать картину маслом!
воскресенье, 10 января 2010 г.
Регулятор мощности с малым уровнем помех.
Доработка конструктора мастер кит NM1041.
http://www.masterkit.ru/info/magshow.php?num=13
Идея схемы красива и потому не изменена, изменены детали.
В исходной схеме соединены выходы тригегов (вывод 1 и 13), в КМОП это недопустимо, т.к. при несовпадении скоростей переключения происходит внутреннее короткое замыкание.
Может кому-то и повезет, и схема будет работать, но как долго никто не скажет.
В приведенной схеме это устранено, а ток открывания транзистора в большей степени ограничен мощностью схемы питания устройства, чем мощностью выходных каскадов тригера.
Вторая проблема устройства - перегрев оптрона, т.к. ограничительный резистор выбран с перегрузкой по току. Решение в установке генератора тока, что обеспечивает нормальный режим работы оптрона.
И третья проблема - невозможность получения полной мощности на выходе. На компараторе уровень напряжения на инверсном входе выше необходимого. Решение устанока двух диодов включенных встречно-параллельно.
С учетом этих доработок устройство работает уже несколько лет в качестве регулятора мощности для паяльника.
Доработка конструктора мастер кит NM1041.
http://www.masterkit.ru/info/magshow.php?num=13
Идея схемы красива и потому не изменена, изменены детали.
В исходной схеме соединены выходы тригегов (вывод 1 и 13), в КМОП это недопустимо, т.к. при несовпадении скоростей переключения происходит внутреннее короткое замыкание.
Может кому-то и повезет, и схема будет работать, но как долго никто не скажет.
В приведенной схеме это устранено, а ток открывания транзистора в большей степени ограничен мощностью схемы питания устройства, чем мощностью выходных каскадов тригера.
Вторая проблема устройства - перегрев оптрона, т.к. ограничительный резистор выбран с перегрузкой по току. Решение в установке генератора тока, что обеспечивает нормальный режим работы оптрона.
И третья проблема - невозможность получения полной мощности на выходе. На компараторе уровень напряжения на инверсном входе выше необходимого. Решение устанока двух диодов включенных встречно-параллельно.
С учетом этих доработок устройство работает уже несколько лет в качестве регулятора мощности для паяльника.
Подписаться на:
Сообщения (Atom)