вторник, 2 апреля 2024 г.
Использование монтажной пены
Кратко распишу что и зачем исходя из личного опыта.
Инструкцию читать обязательно, ниже написанное лишь дополнение к инструкции.
1 Выбор пены
Исходя из планируемых работ и условий проведения работ
А если проще, то нужно ответить на следующие вопросы:
- нужно чтоб пена была негорючая?
- работа будет проводиться при минусовой температуре?
- нужно ли чтоб пенный шов был плотный?
Первые два пункта четко позиционируют выбор, с третьим чуть сложнее - обычно пишут, что нужно брать профессиональную пену, но лучше посмотреть на коэффициент расширения.
В домашних условиях можно брать практически любую пену.
2 Состав инструментов и материалов
- пена, нужная для конкретных работ (низкотемпературная, негорючая)
- пистолет, если используется профессиональный баллон
- очиститель пены
- пульверизатор (если работы будут при плюсовой температуре)
- очки - обязательно!!!
- перчатки
- бумага, если пенить нужно потолок
- малярный скотч
- укрывочная пленка, на которой будет проводится промывка, ну и чтоб поверхности закрыть
3 Подготовка работ (только для плюсовой температуры, для минусовых температур опыта нет)
- очистить область нанесения
- если материал пылящий, то лучше предварительно обработать грунтовкой или влагоизолятором, и дать высохнуть
- заклеить малярным скотчем элементы, которые нежелательно пачкать
- постелить на пол пленку, если пол уже чистовой
- подготовить бумажный шаблон, если работы будут на потолке
4 Проведение работ
- смочить область нанесения пены водой из пульверизатора
- по сырому нанести пену, держа баллон дном вверх, слоями, давая высохнуть каждому слою, если нужно запенить большой объем
- при нанесении на потолок, приклеиваем постепенно бумажный шаблон, и пеним по чуть-чуть, постепенно приклеивая шаблон по всей длине шва
5 Очистка инструмента
- сразу, пока не засохла пена на инструменте, продуваем инструмент очистителем пены
- с бытового баллона снимаем трубку, продуваем трубку и ставим вертикально, чтоб очиститель вытек, продуваем клапан баллона и ставим баллон дном вверх на крышку от баллона, чтоб также вытек очиститель
6 Обработка шва после высыхания
- излишки убираются ножовочным полотном или ножом
- шкурим крупной шкуркой
- грунтуем
- шпатлюем после высыхания грунтовки, или красим
Закрыть пену от ультрафиолета нужно обязательно, иначе пена становится хрупкой и крошится.
7 Если пена попала на кожу - убрать салфеткой не размазывая, остатки смыть очистителем, или дать высохнуть, после высыхания само отваливается.
Если попала на одежду - тоже что и с кожей, но с очистителем можно испортить ткань, лучше остаткам дать высохнуть и потом счистить.
В глаза мне не попадала - поэтому точных данных нет, в инструкции пишут промыть водой.
вторник, 29 июня 2021 г.
Выравнивание пола
Так получилось, что выравнивать пол пришлось в жару, и потому хочется записать несколько особенностей, может пригодится в будущем.
В жару ветонит 3000 очень быстро схватывается и ему не хватает текучести, как следствие, лучше заливать при температуре до 20 градусов цельсия, т.е. лучше не летом) Ну, а уж если других вариантов нет, нужно выполнить следующие правила:
1 Заливать финишный слой ветонитом из одной партии, разные партии в жару вступают в какую-то странную реакцию и пол идет буграми.
2 Слой заливки не менее 5 мм.
3 Пользоваться бетоноступами, иначе следы остаются с вами навсегда.
4 Дополнительно проверять поверхность правилом сразу после выливания и разравнивания.
5 Через сутки зашлифовать неровности шлифмашинкой, на вторые сутки шлифовка идет уже с трудом, на третьи поможет уже только алмазный круг.
В жару ветонит 3000 очень быстро схватывается и ему не хватает текучести, как следствие, лучше заливать при температуре до 20 градусов цельсия, т.е. лучше не летом) Ну, а уж если других вариантов нет, нужно выполнить следующие правила:
1 Заливать финишный слой ветонитом из одной партии, разные партии в жару вступают в какую-то странную реакцию и пол идет буграми.
2 Слой заливки не менее 5 мм.
3 Пользоваться бетоноступами, иначе следы остаются с вами навсегда.
4 Дополнительно проверять поверхность правилом сразу после выливания и разравнивания.
5 Через сутки зашлифовать неровности шлифмашинкой, на вторые сутки шлифовка идет уже с трудом, на третьи поможет уже только алмазный круг.
вторник, 12 апреля 2016 г.
Ngrep или возвращение в телеком
Как-то в начале года задул ветер перемен и я оказался снова в телекоме.
А значит нужно поднимать инструментарий и вспоминать как с этим жить.
Итак есть у нас ngrep sniffer.
Взять его можно тут:
http://ngrep.sourceforge.net/download.html
Заливаем полученное в /usr/src
И пытаемся проинсталировать
cd /usr/src
tar jxf ngrep-1.45.tar.bz2
cd ngrep-*
./configure
make
make install
Но, что-то идет не так, а этож нам не винда, где виноват создатель, тут жеж если что-то идет не так, то знать я маны не вкурил...
Создатель даже патч сготовил, ссылка в его последнем ответе https://sourceforge.net/p/ngrep/bugs/34/, да только забыл мил человек, что проверка у него в двух файлах, а не в одном.
А раз все равно танцевать с бубном, то, по мне, проще так:
Нам понадобятся, т.е. нужно установить перед установкой ngrep
gcc
libpcap-devel
Все это ставится из стандартного репозитария.
Далее переименовываем директорию
/usr/include/pcap например в /usr/include/__pcap
./configure
Возвращаем директорию назад, к исходному виду.
make
make install
При таком подходе запуск состоялся.
Теперь можно попытать что-нибудь этакое, например
# ngrep sip:123@ port 5060
или
# ngrep port not 22
или
# ngrep port not 22 and not 5060
Примеры использования можно подсмотреть тут:
http://ngrep.sourceforge.net/usage.html
А значит нужно поднимать инструментарий и вспоминать как с этим жить.
Итак есть у нас ngrep sniffer.
Взять его можно тут:
http://ngrep.sourceforge.net/download.html
Заливаем полученное в /usr/src
И пытаемся проинсталировать
cd /usr/src
tar jxf ngrep-1.45.tar.bz2
cd ngrep-*
./configure
make
make install
Но, что-то идет не так, а этож нам не винда, где виноват создатель, тут жеж если что-то идет не так, то знать я маны не вкурил...
Создатель даже патч сготовил, ссылка в его последнем ответе https://sourceforge.net/p/ngrep/bugs/34/, да только забыл мил человек, что проверка у него в двух файлах, а не в одном.
А раз все равно танцевать с бубном, то, по мне, проще так:
Нам понадобятся, т.е. нужно установить перед установкой ngrep
gcc
libpcap-devel
Все это ставится из стандартного репозитария.
Далее переименовываем директорию
/usr/include/pcap например в /usr/include/__pcap
./configure
Возвращаем директорию назад, к исходному виду.
make
make install
При таком подходе запуск состоялся.
Теперь можно попытать что-нибудь этакое, например
# ngrep sip:123@ port 5060
или
# ngrep port not 22
или
# ngrep port not 22 and not 5060
Примеры использования можно подсмотреть тут:
http://ngrep.sourceforge.net/usage.html
воскресенье, 7 июня 2015 г.
Реанимация Orsio b731
Некоторое время назад книжка стала плохо себя вести, батарейки стало хватать на несколько часов чтения, и, самое неприятное, она стала разряжаться даже в выключенном состоянии.
Поиск практически сразу привел на два сайта, где и была найдена вся нужная информация:
http://e-ink-reader.ru
http://www.the-ebook.org
В первом источнике была найдена информация по замене аккумулятора, т.к. найти оригинальный оказалось не так то просто.
http://e-ink-reader.ru/batt.php
Мне приглянулась Nokia BL-5C
В батарейном отсеке она выглядит так:
Вторым шагом было выяснение причины разряда аккумулятора в выключенном состоянии.
Причиной оказался вышедший из строя ионистор - очень распространенная болезнь.
Об этом много написано на форуме www.the-ebook.org
В посте
http://www.the-ebook.org/forum/viewtopic.php?p=461779#461779
Приведена схема питания часов, где С611 и есть ионистор - 3R3D6F22.
http://www.100y.com.tw/pdf_file/Hiteck%20Supercap%200.22F%20spec.pdf
Ссылка взята из поста
http://www.the-ebook.org/forum/viewtopic.php?p=464115#464115
Далее там предлагают сменить стабилитрон на микромощный стабилизатор, что бесспорно хорошо:
http://www.the-ebook.org/forum/viewtopic.php?p=462506#462506
Но под рукой стабилизатора не оказалось, поэтому я ограничился заменой батареи и ионистора на конденсатор.
Прошло уже несколько месяцев - полет нормальный.
суббота, 18 апреля 2015 г.
Совещание как инструмент
Недавний спор побудил к написанию ниже следующего документа.
Руководство проектом – это управление людьми.
Совещание – это один из инструментов этого управления.
В качестве примера можно взять молоток, никто не будет использовать топор для забивания гвоздя, если рядом есть молоток, так и совещание нужно использовать только тогда, когда использование других инструментов менее эффективно.
Но, как для всякого инструмента, для совещаний есть несколько основных правил:
- Подготовка
1) Любое совещание должно иметь четко определенную цель, эту цель может знать только ведущий, но это та ось вокруг которой будут проходить все разговоры. Это та основа, которая не позволит перерасти совещанию в обсуждение совершенно не связанных тем. Цель прорабатывает ведущий и этот же ведущий следит, чтобы совещание придерживалось цели, и пресекает уходы в стороны.
2) В соответствии с целью должен быть сформирован список задач, которые должно решить совещание. Задачи формулируются глаголами в повелительном наклонении, например, принять решение, или проанализировать или разрешить проблему, или ознакомить с новой информацией, или собрать информацию о том или ином проекте.
3) По каждой задаче должен быть определен тип обсуждения (доклад, обмен мнениями, мозговой штурм, обсуждение).
4) По каждой задаче должен быть определен состав обязательных участников.
5) В соответствии со списком задач разрабатывается регламент.
6) Список задач, состав участников и регламент оформляются в повестку совещания и рассылаются всем участникам проекта (если речь идет о проекте).
- Проведение
7) Совещание проводится одним человеком, созыв совещания делается этим же человеком. Если совещание собирал кто-то другой, то часть важных вопросов может быть упущена.
8) Четко соблюдается регламент. На совещание приходят только необходимые участники и только в назначенное время, что позволяет свести количество людей к минимуму и, тем самым, улучшает управляемость совещанием и повышает общую эффективность.
9) Присутствие необязательных участников не возбраняется, но слово они могут брать только с разрешения ведущего.
- Результат
10) По результатам совещания пишется протокол с перечислением всех принятых решений. Протокол рассылается всем участникам совещания.
Следует отметить, что это лишь основные правила, общие для всех совещаний. Но даже простое использование этого списка в качестве чек листа, позволяет улучшить эффективность совещаний.
воскресенье, 15 марта 2015 г.
Ресурсы по Microsoft - заинтересовали
Как получить полный доступ к разделу реестра
http://www.windxp.com.ru/articles90.htm
Обмен и публикация скриптов для администрирования в WIndows
http://sysadmins.ru/topic79925-30.html
Хранение учетных данных в скриптах и групповых политиках на примере задачи по смене пароля локального администратора
http://rudykh.blogspot.ru/
TS RemoteApp
http://itband.ru/2010/02/ts-remoteapp/
Прав достаточно: 8 приемов для обхода групповых политик в домене
https://xakep.ru/2011/10/24/57477/
Встроенные участники системы безопасности
http://www.osp.ru/win2000/2006/01/380291/
AstroGrep
http://sourceforge.net/projects/astrogrep/?source=typ_redirect
суббота, 15 ноября 2014 г.
Acme Packet - это просто. Дополнение к Части I.
Acme Packet’s high availability (redundant) configuration.
В первой части я лишь мельком коснулся настройки резервированной системы. Постараемся восполнить этот пробел.
Итак, резервированная система состоит из двух одинаковых серверов, для них сгенерированы лицензии на одинаковое колличество услуг и есть лицензия для резервирования. Просмотреть лицензию можно командой:
show license
При функционировании на системе запущен процесс проверяющий их состояние, и при ухудшении состояния активной системы меняет активную и пассивную систему местами.
Состояние системы можно проверить командой:
show health
Вся система, со стороны внешних систем, в этом режиме рассматривается как одна логическая сущность, с одним IP и MAC адресами. И суть системы резервирования состоит в том, чтобы вся внешняя инфраструктура воспринимала два сервера как одно целое. Для этого системе присваивается единый виртуальный IP адрес и два виртуальных MAC адреса. В момент переключения с одного сервера на другой формируется ARP запрос, изменяющий маршруты следования сигнального и медиа трафиков. Документация гласит, что в режиме high availability будут сохраняться текущие вызовы и вновь устанавливаемые. Отчасти это верно, но лишь отчасти, если включается защита от DoS атак, то при переключении долна быть повторно пройдена процедура регистрации на сервере, т.к. таблица регистрации между серверами не дублируется.
Между собой сервера общаются через специальные интерфейсы wancom0 и wancon1.
Начальная настройка систем описана в части 1, т.е. включение функционала и настройка интерфейсов wancom0 и wancon1.
После первоначальной настройки, вся дальнейшая настройка производится на активном сервере. Все изменения конфигурации автоматически передаются на резервную систему при сохранении конфигурации.
После сохранения оба сервера содержат одинаковые конфигурационные файлы.
В первой части я лишь мельком коснулся настройки резервированной системы. Постараемся восполнить этот пробел.
Итак, резервированная система состоит из двух одинаковых серверов, для них сгенерированы лицензии на одинаковое колличество услуг и есть лицензия для резервирования. Просмотреть лицензию можно командой:
show license
При функционировании на системе запущен процесс проверяющий их состояние, и при ухудшении состояния активной системы меняет активную и пассивную систему местами.
Состояние системы можно проверить командой:
show health
Вся система, со стороны внешних систем, в этом режиме рассматривается как одна логическая сущность, с одним IP и MAC адресами. И суть системы резервирования состоит в том, чтобы вся внешняя инфраструктура воспринимала два сервера как одно целое. Для этого системе присваивается единый виртуальный IP адрес и два виртуальных MAC адреса. В момент переключения с одного сервера на другой формируется ARP запрос, изменяющий маршруты следования сигнального и медиа трафиков. Документация гласит, что в режиме high availability будут сохраняться текущие вызовы и вновь устанавливаемые. Отчасти это верно, но лишь отчасти, если включается защита от DoS атак, то при переключении долна быть повторно пройдена процедура регистрации на сервере, т.к. таблица регистрации между серверами не дублируется.
Между собой сервера общаются через специальные интерфейсы wancom0 и wancon1.
Начальная настройка систем описана в части 1, т.е. включение функционала и настройка интерфейсов wancom0 и wancon1.
После первоначальной настройки, вся дальнейшая настройка производится на активном сервере. Все изменения конфигурации автоматически передаются на резервную систему при сохранении конфигурации.
После сохранения оба сервера содержат одинаковые конфигурационные файлы.
понедельник, 7 апреля 2014 г.
Переход на SSD
Модернизация старенького Lifebook S7110.
Задача - модернизация без переустановки системы, осложненное заменой HDD на SSD.
Есть конечно описания как делается перенос. Можно найти, например, тут: http://www.isranet.info/main/articles/backup-and-restore/kak-perenesti-windows-xp-so-vsemi-prorammami-na-novoe-zhelezo.html
или тут:
http://delikbez.ru/komp/21-kak-perenesti-windows-xp-na-drugojj-zhestkijj-disk.html
Эксперимент показал, что сделать все можно просто и безболезненно.
Идем на сайт Сергея Стрельца:
http://www.sergeistrelec.ru/
Скачиваем его BOOT CD/USB
Подключаем диск на который будем переносить систему.
Загружаемся с LiveCD
Запускаем AOMEI Partition Assistant Professional Edition
И запускам Перенос ОС SSD или HDD.
Место на новом диске должно быть неразмеченным.
Размер нового раздела можно увеличивать.
Проблем с MBR после переноса не последовало.
Программа создала раздел на SSD диске по фэншую, что было проверено тут:
http://www.techpowerup.com/articles/other/157
Далее произвел оптимизацию в соответствии с:
http://www.finar.ru/Base/WindowsXP-SSD-Optimization
Сделать RAM диск в невидимой области не получилось из-за ограничений в 945 чипсете.
Ниже перепечатка (вдруг пропадет)
Итак, после успешной установки или переноса Windows XP на SSD, следует:
Сделать непременно:
для материнских плат на интеловских чипсетах установить (если еще не установлено) Intel Chipset Software Installation Utility и Intel Rapid Storage (у Интела неудобный сайт с софтом без поддержки прямых ссылок, так что актуальные файлы проще нагуглить);
для интеловских SSD установить Intel Solid-State Drive Toolbox , в настройках запланировать еженедельный запуск Intel SSD Optimizer (инициализатор встроенной аппаратной функции trim). Для не-интеловских SSD установить фирменные утилиты и сконфигурировать их аналогично;
отключить Wikipedia:Prefetcher . Совет принят: не нужен на SSD, т.к. время доступа не зависит от физического расположения файла, а сама операция очевидно вызывает какое-то излишнее шевеление электронов;
рекомендуют "отключать Indexing на диске через Administrative Tools -> Services". Можно согласиться с отключением индексирования (тем более, если у вас правильно организована дисковая подсистема и системный раздел полностью отделен от данных и, следовательно, быстрый поиск на нем не нужен) - однако делать это следует ни в коем случае не отключением сервиса целиком, но "по-простому" только для системного диска через свойства раздела (правой кнопкой на диске C:\ -> Свойства);
"включать кэширование записи на диск через Hardware или Device manager -> Disk Drives -> ваш SSD -> Properties -> Enable write caching on disk и Enable advanced performance". Совет однозначно справедливый и выполняется автоматически при установке Intel Rapid Storage;
Сделать подумав (если не понимаете сути процессов, лучше ничего не трогайте):
рекомендуют отключать Файл Подкачки. Ох уж этот бедный файл подкачки! Как его только не мучают. В общем случае совет неверный, но для моего конкретного компьютера AHILL я оставил 16 МБ. swap-файл на SSD, 512-3072 МБ. перенес в виртуальный диск, созданный в незадействованной ОС области ОЗУ, а еще 3 ГБ. бросил на рабочий диск. Почему я сделал именно так описано в статье "RAMDisk или настройка файла подкачки в Windows XP x86 при большом объеме ОЗУ"
советуют перенести кэш браузеров на отдельный носитель. Спорный момент. Для десктопа с постоянным широкополостным 5-10 мегабитным подключением я бы вообще отказался от кэша браузера. Для ноутбука кэш может быть оправдан, но у ноутбуков обычно только один накопитель... У себя я пока вынес кэш в RAMDrive-диск из оперативной памяти, а позже наверное совсем отключу его. Anyway, вот как это делается в FireFox:
открыть пустую вкладку, набрать about:config, нажать Enter, найти ключи browser.cache.* . Отключить понятно как, а перенести можно создав новый параметр browser.cache.disk.parent_directory, в качестве значения которого указав путь к родительской папке кэша
Не стоит делать:
ключу NtfsMemoryUsage предлагают поставить значение 2, чтобы NTFS "начала использовать больше оперативной памяти." Звучит неубедительно, пожалуй, не надо этого делать, тем более есть негативный отзыв .
рекомендуют отключать hibernation. Совет сомнительный - аппаратные средства SSD позволяют (должны) нивелировать негативные влияния от статичного расположения файла для гибернизации и частой его перезаписи. Тем более для ноутбуков эта функция более чем оправдана. Все-таки SSD накопитель для нас, а не мы для SSD-накопителя.
Как создать RAMDisk в неиспользованной ОС области оперативной памяти?
Существует масса утилит для создания RAMDisk , и среди них одна, бесплатная редакция которой позволяет использовать незадействованный 32-битной ОС объем памяти. Имя ей - VSuite Ramdisk Free Edition.
Задача - модернизация без переустановки системы, осложненное заменой HDD на SSD.
Есть конечно описания как делается перенос. Можно найти, например, тут: http://www.isranet.info/main/articles/backup-and-restore/kak-perenesti-windows-xp-so-vsemi-prorammami-na-novoe-zhelezo.html
или тут:
http://delikbez.ru/komp/21-kak-perenesti-windows-xp-na-drugojj-zhestkijj-disk.html
Эксперимент показал, что сделать все можно просто и безболезненно.
Идем на сайт Сергея Стрельца:
http://www.sergeistrelec.ru/
Скачиваем его BOOT CD/USB
Подключаем диск на который будем переносить систему.
Загружаемся с LiveCD
Запускаем AOMEI Partition Assistant Professional Edition
И запускам Перенос ОС SSD или HDD.
Место на новом диске должно быть неразмеченным.
Размер нового раздела можно увеличивать.
Проблем с MBR после переноса не последовало.
Программа создала раздел на SSD диске по фэншую, что было проверено тут:
http://www.techpowerup.com/articles/other/157
Далее произвел оптимизацию в соответствии с:
http://www.finar.ru/Base/WindowsXP-SSD-Optimization
Сделать RAM диск в невидимой области не получилось из-за ограничений в 945 чипсете.
Ниже перепечатка (вдруг пропадет)
Итак, после успешной установки или переноса Windows XP на SSD, следует:
Сделать непременно:
для материнских плат на интеловских чипсетах установить (если еще не установлено) Intel Chipset Software Installation Utility и Intel Rapid Storage (у Интела неудобный сайт с софтом без поддержки прямых ссылок, так что актуальные файлы проще нагуглить);
для интеловских SSD установить Intel Solid-State Drive Toolbox , в настройках запланировать еженедельный запуск Intel SSD Optimizer (инициализатор встроенной аппаратной функции trim). Для не-интеловских SSD установить фирменные утилиты и сконфигурировать их аналогично;
отключить Wikipedia:Prefetcher . Совет принят: не нужен на SSD, т.к. время доступа не зависит от физического расположения файла, а сама операция очевидно вызывает какое-то излишнее шевеление электронов;
рекомендуют "отключать Indexing на диске через Administrative Tools -> Services". Можно согласиться с отключением индексирования (тем более, если у вас правильно организована дисковая подсистема и системный раздел полностью отделен от данных и, следовательно, быстрый поиск на нем не нужен) - однако делать это следует ни в коем случае не отключением сервиса целиком, но "по-простому" только для системного диска через свойства раздела (правой кнопкой на диске C:\ -> Свойства);
"включать кэширование записи на диск через Hardware или Device manager -> Disk Drives -> ваш SSD -> Properties -> Enable write caching on disk и Enable advanced performance". Совет однозначно справедливый и выполняется автоматически при установке Intel Rapid Storage;
Сделать подумав (если не понимаете сути процессов, лучше ничего не трогайте):
рекомендуют отключать Файл Подкачки. Ох уж этот бедный файл подкачки! Как его только не мучают. В общем случае совет неверный, но для моего конкретного компьютера AHILL я оставил 16 МБ. swap-файл на SSD, 512-3072 МБ. перенес в виртуальный диск, созданный в незадействованной ОС области ОЗУ, а еще 3 ГБ. бросил на рабочий диск. Почему я сделал именно так описано в статье "RAMDisk или настройка файла подкачки в Windows XP x86 при большом объеме ОЗУ"
советуют перенести кэш браузеров на отдельный носитель. Спорный момент. Для десктопа с постоянным широкополостным 5-10 мегабитным подключением я бы вообще отказался от кэша браузера. Для ноутбука кэш может быть оправдан, но у ноутбуков обычно только один накопитель... У себя я пока вынес кэш в RAMDrive-диск из оперативной памяти, а позже наверное совсем отключу его. Anyway, вот как это делается в FireFox:
открыть пустую вкладку, набрать about:config, нажать Enter, найти ключи browser.cache.* . Отключить понятно как, а перенести можно создав новый параметр browser.cache.disk.parent_directory, в качестве значения которого указав путь к родительской папке кэша
Не стоит делать:
ключу NtfsMemoryUsage предлагают поставить значение 2, чтобы NTFS "начала использовать больше оперативной памяти." Звучит неубедительно, пожалуй, не надо этого делать, тем более есть негативный отзыв .
рекомендуют отключать hibernation. Совет сомнительный - аппаратные средства SSD позволяют (должны) нивелировать негативные влияния от статичного расположения файла для гибернизации и частой его перезаписи. Тем более для ноутбуков эта функция более чем оправдана. Все-таки SSD накопитель для нас, а не мы для SSD-накопителя.
Как создать RAMDisk в неиспользованной ОС области оперативной памяти?
Существует масса утилит для создания RAMDisk , и среди них одна, бесплатная редакция которой позволяет использовать незадействованный 32-битной ОС объем памяти. Имя ей - VSuite Ramdisk Free Edition.
суббота, 3 ноября 2012 г.
Плавное включение ламп накаливания
Началось все с того, что в одном из журналов мне попалась статья о продлении жизни ламп накаливания. Схема, приведенная в статье, имела массу недостатков, но идея меня заинтересовала.
Технические требования, предъявляемые мной к разработке:
1 Двухполюсник
2 Мощность нагрузки от 40 до 180 Вт
3 Плавное увеличение тока в нагрузке не менее 2 секунд до максимальной мощности
4 Готовность к повторному включению не более 2 секунд
Итак, после долгого поиска и проб трех различных решений, я остановился на микросхеме 1182пм1, и на свет появилось это устройство.
Информацию о микросхеме 1182пм1 можно найти тут:
http://www.sitsemi.ru/
Все схемы, рассмотренные мной, не подходили, большинство решений страдало тем, что выход на режим для повторного включения очень долог, иногда измеряется минутами. Схемы, предлагаемые разработчиками 1182пм1, также не подходили из-за небольшой утечки тока и невозможности полного обесточивания нагрузки. Предлагаемое устройство лишено этих недостатков. Работа микросхемы представлена в описании, поэтому опишу только суть доработки. В начальный момент времени конденсатор С3 разряжен, а транзистор VT1 открыт, при подаче напряжения пиковый детектор R2VD1C4 выделяет сетевые импульсы, и транзистор VT1 начинает закрываться, конденсатор С3 заряжается, и при полном закрытии транзистора VT1 и заряде C3 симистор открывается в начале каждого полупериода сетевого напряжения и нагрузка работает на полную мощность. При отключении напряжения конденсатор C4 быстро разряжается, транзистор VT1 открывается и разряжает конденсатор C3, вся схема возвращается в исходное состояние и готова к повторному включению.
Схема не лишена недостатков - линейность увеличения тока в нагрузке отсутствует, ток нарастает по сложной кривой, но такой задачи я перед собой не ставил.
Возможно, публикация несколько запоздала, но на прилавках магазинов появились галогеновые лампы с цоколями Е14 и Е27, а они тоже не любят резких бросков по току, и это устройство продлит и их жизнь.
понедельник, 2 мая 2011 г.
Телефонный сторож
Импульсом к разработке телефонного сторожа послужило введение поминутной оплаты городских разговоров ( ох, давно это было...). Но как бы то ни было, мимолетный разговор запустил процесс и вот появилось устройство, несколько озадачивающее монтеров, когда они пытаются позвонить с последней пары на коробке - это как раз мой телефон...
Итак, было сформировано техническое задание:
1 система должна независеть от полярности в линии
2 система должна запитываться от телефонной линии
3 система не должна влиять на качество связи
4 система не должна закорачивать линию
5 система должна устанавливаться в квартире
6 система должна блокировать наборы в импульсном режиме
7 система должна блокировать наборы в тональном режиме
8 система должна выдавать индикацию об отсутствии питания на линии
9 система должна выдавать индикацию о попытке подключения
Получившаяся схема делится на несколько функциональных блоков:
Блок питания и определения питания на линии
Блок определения занятия линии
Блок определения санкционированного занятия линии
Блок управления
Блок блокирования линии
Блок индикации
Блок выдачи блокирующих тонов
Разработка устройства началась с поиска решения для индикатора санкционированного занятия линии, а по простому - индикатор поднятия трубки. Индикатор должен не зависеть от полярности линии и вносить как можно меньше помех. После перебора всех известных решений была придумана простая и в тоже время эффективная схема. Индикатор построен на четырех диодах и двух оптронах. Идея заключатся в том, что при поднятии трубки через пару диодов, включенных последовательно, начинает протекать ток, и падение напряжения на них составляет примерно 1,2 вольта, чего вполне
достаточно для зажигания светодиода. Т.е. при подъеме трубки часть тока потечет через светодиод оптрона, что в свою очередь откроет транзистор.
Реализация блока питания и блока определения занятия линии свелась к двум классическим микромощным стабилизаторам. При занятии линии напряжение падает до 15 вольт и ниже. Это позволило применить для блока определения занятия линии схему отсечки напряжения на стабилитроне. Как только происходит занятие линии напряжение падает ниже напряжения стабилизации стабилитрона, ток перестает поступать на микромощьный стабилизатор, что приводит к разряду конденсатора на его выходе. Данная схема плюс схема задержки дали в сумме схему определения занятия линии. Информация о отсутствии питания берется с того же стабилизатора, что и питание системы.
Логика управления сводится к реализации следующего алгоритма
1 отлючается питание на линии - блокируются
все модули, кроме блока индикации отсутствия линии.
2 параллельное подключение к линии - индицируется падение напряжения на линии, при этом
информация о поднятии трубки отсутствует, тут же запускается генератор блокирования
линии и генератор выдачи блокирующего тона, после фильтрующей задержки выдается
информация на блок индикации параллельного подключения.
3 нормальное занятие линии - информация от детектора поднятия трубки блокирует схему
определения занятия линии, генераторы остановлены, система работает в ждущем режиме.
Блоки индикации выполнены по схеме аналога однопереходного транзистора, что позволило
заряжать конденсатор малым током и при достижении порогового, зажигать светодиод.
вторник, 19 апреля 2011 г.
Acme Packet - это просто. Дополнение к Части II.
При эксплуатации системы была обнаружена особенность при работе системы защиты от DDoS. Если уровень доверия выставлен в LOW, то уровень контроля может упасть до denied, при поступлении сообщений, которые отвергаются сервером или игнорируются по причине отсутствия ответа от сервера. Для изменения уровня контроля необходимо, чтобы было получено от сервера регистрации сообщение 200OK(Register), но есть особенность, при получении первого 200OK уровень изменяется на untrusted, и только при получении второго 200OK уровень изменяется на trusted. Это значит, что если произошел сбой на сервере регистраций и абонент был заблокирован, то для перехода на уровень trusted должно быть получено два сообщения 200OK. Т.к. второе сообщение генерируется по истечении таймера перерегистрации, а абонент может уже набрать номер и установить разговор после первого сообщения, то возникает ситуация, что IP адрес абонента опять превысит порог untrusted-signal-threshold и попадет в denied список. При малом пороге untrusted-signal-threshold может возникнуть ситуация, когда многопортовый шлюз не сможет перейти в trusted, т.к. для перехода в trusted два сообщения 200OK должны быть получены от одной учетной записи, а для перехода в denied достаточно любого сообщения с этого IP адреса, соответственно сообщения Register от соседних портов будут переводить весь шлюз на уровень denied. Для исключения этой ситуации изменим метод расчета untrusted-signal-threshold.
Учтем, что для успешной регистрации каждой учетной записи необходимо 2 сообщения Register, а также предусмотрим 10 сообщений для установления одного успешного разговора.
untrusted-signal-threshold = Количество портов * 2 +10
Учтем, что для успешной регистрации каждой учетной записи необходимо 2 сообщения Register, а также предусмотрим 10 сообщений для установления одного успешного разговора.
untrusted-signal-threshold = Количество портов * 2 +10
вторник, 29 марта 2011 г.
Acme Packet - это просто. Часть IV.
Upgrade
Получаем новый софт.
Далее софт нужно закачать на acme, прописать и перезагрузиться.
Если acme две, то начинаем с резервной.
Если начать с резервной, то потребуется только один переход между акмами, и будет один разрыв текущих сессий.
sftp admin@192.168.2.2
cd /code/images/
ls
nnCX_diags109.gz nnSCX620m5p4.xz nnSCX620p3.xz
В этот раздел помещается лишь три образа систем, соответственно, нужно удалить старый софт, а затем скопировать новый.
rm nnSCX620p3.xz
put nnSCX620m6.xz
Далее изменяем bootparam
Acme скажет, что система неактивна, но на это не надо обращать внимания.
Измененя в bootparam вступают в силу без записи.
Перезагружаемся.
Процесс загрузки, рекомендуется, контролировать с консоли.
Если загрузка прошла успешно, переводим сервисы на acme с новым софтом.
Повторяем на второй acme.
Получаем новый софт.
Далее софт нужно закачать на acme, прописать и перезагрузиться.
Если acme две, то начинаем с резервной.
Если начать с резервной, то потребуется только один переход между акмами, и будет один разрыв текущих сессий.
sftp admin@192.168.2.2
cd /code/images/
ls
nnCX_diags109.gz nnSCX620m5p4.xz nnSCX620p3.xz
В этот раздел помещается лишь три образа систем, соответственно, нужно удалить старый софт, а затем скопировать новый.
rm nnSCX620p3.xz
put nnSCX620m6.xz
Далее изменяем bootparam
SBC-1# conf t SBC-1(configure)# bootparam '.' = clear field; '-' = go to previous field; q = quit file name : /code/images/nnSCX620m5p4.xz /code/images/nnSCX620m6.xz
Acme скажет, что система неактивна, но на это не надо обращать внимания.
Измененя в bootparam вступают в силу без записи.
Перезагружаемся.
Процесс загрузки, рекомендуется, контролировать с консоли.
Если загрузка прошла успешно, переводим сервисы на acme с новым софтом.
notify berpd force
Повторяем на второй acme.
среда, 24 ноября 2010 г.
Acme Packet - это просто. Часть III.
Защита от 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
В дополнение к первой части приводится метод расчета параметров для протокола 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
пятница, 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), в КМОП это недопустимо, т.к. при несовпадении скоростей переключения происходит внутреннее короткое замыкание.
Может кому-то и повезет, и схема будет работать, но как долго никто не скажет.
В приведенной схеме это устранено, а ток открывания транзистора в большей степени ограничен мощностью схемы питания устройства, чем мощностью выходных каскадов тригера.
Вторая проблема устройства - перегрев оптрона, т.к. ограничительный резистор выбран с перегрузкой по току. Решение в установке генератора тока, что обеспечивает нормальный режим работы оптрона.
И третья проблема - невозможность получения полной мощности на выходе. На компараторе уровень напряжения на инверсном входе выше необходимого. Решение устанока двух диодов включенных встречно-параллельно.
С учетом этих доработок устройство работает уже несколько лет в качестве регулятора мощности для паяльника.
вторник, 26 мая 2009 г.
SBC и его место
Построение VoIP сетей постепенно переходит из состояния "лишь бы работало" к состоянию "чтобы работало". Это привело к пересмотру подходов построения сетей. Изменились и требования. И наряду с прокси-серверами, серверами-регистраторами, гейткиперами и т.д. появилась еще одна составляющая сетей SBC (Session Border Controller). Из названия следует, что этот кубик должен осуществлять контроль за VoIP сессиями. Так оно и есть, только есть нюанс: каждый производитель SBC предлагает разную функциональность.
SBC - мост, соединяющий внутреннюю сеть провайдера, которую последний должен контролировать, с неконтролируемой внешней сетью. И задача, налагаемая на SBC, - обеспечить надежное и защищенное соединение между данными сетями.
Соединение сетей подразделяется на две схемы: peer-to-peer и access.
Peer-to-peer
Оконечные устройства обладают информацией друг o друге и могут задать жесткие правила пропуска трафика. Данная схема используется при объединении сетей провайдеров, при построении распределенной сети, при подключении абонентов со статическими настройками.
Access
Информация известна только одной стороне - пользователю услуги. При этой схеме производится аутентификация и авторизация пользовательской стороны на серверной, на основе криптографических алгоритмов с использованием уникальных данных.
В теории обе эти схемы должны быть реализованы на SBC и должны работать в SIP, H.323. Для Megaco, MGCP должна поддерживаться схема peer-to-peer. (Мне не известно ни одного SBC с поддержкой всех этих протоколов.)
Задачи, решаемые SBC в схеме Peer-to-peer
-Проверка подлинности пользователя (IP address, MAC, ...).
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Задачи, решаемые SBC в схеме Access
-Аутентификация и Авторизация.
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Преодоление NAT.
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Если суммировать все эти задачи и помножить на количество протоколов, то в результате должна получиться ужасно сложная система.
Оборудование или ПО SBC, производимое сегодня, по выше изложенным причинам поддерживает только часть необходимых функций. Я не знаю наверняка, но, похоже, все производители SBC отказались от реализации протоколов Megaco и MGCP, уменьшив тем самым сложность задачи вдвое. Но на этом они не остановились, чем дальше, тем больше идет отрицание существования протокола H.323, может быть это и правильно, но этот протокол еще работает и работать будет долго. Т.е. в конечном счете, все сведется к реализации протокола SIP.
Свободно распространяемые SBC отказались от H.323 изначально, и предъявить им нечего, и так бесплатны. Коммерческие же SBC заявляют о своей поддержке этого протокола, как в варианте трансляции, так и в варианте интервокинга. Заявление отличное, вот только реализация далека от идеальной. Так тестируемый nCite1000 компании AudioCodes почему-то не может обеспечить интервокинг протокола H.323 в SIP. Есть надежда, что у других производителей дела обстоят лучше, но есть большие сомнения.
Итак:
Свободные SBC - только SIP;
Коммерческие SBC - SIP и H.323.
Определившись с протоколами, перейдем к функциям.
В нашем распоряжении оказались два типа SBC ncite1000 и OpenSBC; я понимаю, что этого мало, но мне кажется, что тенденция одинакова для всех.
OpenSBC
Поддерживает только SIP.
Реализованы обе схемы peer-to-peer и access.
Реализована нормализация SIP протокола, но при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником данного SBC, и как результат вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации, к тому же алгоритм изменяется от версии к версии, что не лучшим образом отражается на поддержании сети.
Транскодирования нет.
Прост в установке и обслуживании, но рассчитан на малый объем RTP трафика.
nCite1000
Заявлены обе схемы peer-to-peer и access для протокола SIP и H.323.
Реализованы обе схемы peer-to-peer и access для SIP.
Для H.323 только peer-to-peer.
Нормализация SIP протокола если и есть, то минимальная, при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником этого SBC, и, как результат, вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации.
Эта проблема решается установкой после SBC маршрутизатора с гигабитными интерфейсами, и прописыванием маршрутов в SBC. Маршрутизаторы делает данное решение слишком дорогим.
Транскодирования нет.
Прост в установке, но сложен в обслуживании. Система управления реализована с упором на красоту визуального восприятия, а не на удобство и гибкость управления (это беда, похоже, всех систем управления от AudioCodes). Серверная часть системы управления устанавливается на выделенный сервер, который устанавливается в том же сегменте, что и управляющий интерфейс nCite. При этом система управления предполагает, что интерфейс клиентского доступа сервера находится на внешних IP адресах. Вся система управления перестает работать, если установить на серверной стороне хотя бы статический NAT. А если клиент запускается из-за NAT, то требует открыть уйму портов, чем повергает в шок любого системного администратора.
Надеюсь, у других производителей дела обстоят лучше...
Нет сомнения, что данный кубик при построении VoIP сети является если не самым главным в системе, то одним из основных, наряду с SIP-сервером, и построение сетей с его использованием должно стать обязательным. Но для достижения этого SBC должен стать образцом для всех типов VoIP оборудования. Его надежность, управляемость, гибкость и функциональность должны быть на порядок выше, чем у SIP-серверов и шлюзов.
Пока же этого нет, оператор, прежде чем заплатить деньги, должен определиться, какая из схем ему ближе. В случае peer-to-peer, оператор теряет промежуточный контроль за сессиями, т.е. вся нагрузка ложиться либо на шлюз, либо на сервер. А в случае с access оператор вынужден поднимать STUN сервер или применять другие методы, т.к. в большинстве случаев STUN сервер просто бесполезен. Все бы не беда, если бы не доступность серверов из внешней сети, что ставит оператора в странное положение: с одной стороны, он должен обеспечить безопасность (устанавливать патчи на системы, делать апгрейд), а с другой - он не может этого сделать из-за лицензионной политики производителей, например компании VocalTec.
Если же оператор решился идти сквозь тернии и купил SBC, он должен понимать, что он будет вынужден подгонять все оставшиеся кубики схемы к кубику SBC. И осознать, что при проблемах на SBC проблемы будут на всей сети.
SBC - мост, соединяющий внутреннюю сеть провайдера, которую последний должен контролировать, с неконтролируемой внешней сетью. И задача, налагаемая на SBC, - обеспечить надежное и защищенное соединение между данными сетями.
Соединение сетей подразделяется на две схемы: peer-to-peer и access.
Peer-to-peer
Оконечные устройства обладают информацией друг o друге и могут задать жесткие правила пропуска трафика. Данная схема используется при объединении сетей провайдеров, при построении распределенной сети, при подключении абонентов со статическими настройками.
Access
Информация известна только одной стороне - пользователю услуги. При этой схеме производится аутентификация и авторизация пользовательской стороны на серверной, на основе криптографических алгоритмов с использованием уникальных данных.
В теории обе эти схемы должны быть реализованы на SBC и должны работать в SIP, H.323. Для Megaco, MGCP должна поддерживаться схема peer-to-peer. (Мне не известно ни одного SBC с поддержкой всех этих протоколов.)
Задачи, решаемые SBC в схеме Peer-to-peer
-Проверка подлинности пользователя (IP address, MAC, ...).
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Задачи, решаемые SBC в схеме Access
-Аутентификация и Авторизация.
-Интервокинг (преобразование протокола установления связи).
-Нормализация протокола (приведение сообщений от пользовательского оборудования к виду, понятному для сервера управления).
-Преодоление NAT.
-Анализ SDP (анализ схемы сети для проключения RTP трафика).
-Транскодирование (преобразование голосовой информации из одной схемы кодирования в другую).
-Управление RTP сессиями (в вариантах с проксированием и без него).
Если суммировать все эти задачи и помножить на количество протоколов, то в результате должна получиться ужасно сложная система.
Оборудование или ПО SBC, производимое сегодня, по выше изложенным причинам поддерживает только часть необходимых функций. Я не знаю наверняка, но, похоже, все производители SBC отказались от реализации протоколов Megaco и MGCP, уменьшив тем самым сложность задачи вдвое. Но на этом они не остановились, чем дальше, тем больше идет отрицание существования протокола H.323, может быть это и правильно, но этот протокол еще работает и работать будет долго. Т.е. в конечном счете, все сведется к реализации протокола SIP.
Свободно распространяемые SBC отказались от H.323 изначально, и предъявить им нечего, и так бесплатны. Коммерческие же SBC заявляют о своей поддержке этого протокола, как в варианте трансляции, так и в варианте интервокинга. Заявление отличное, вот только реализация далека от идеальной. Так тестируемый nCite1000 компании AudioCodes почему-то не может обеспечить интервокинг протокола H.323 в SIP. Есть надежда, что у других производителей дела обстоят лучше, но есть большие сомнения.
Итак:
Свободные SBC - только SIP;
Коммерческие SBC - SIP и H.323.
Определившись с протоколами, перейдем к функциям.
В нашем распоряжении оказались два типа SBC ncite1000 и OpenSBC; я понимаю, что этого мало, но мне кажется, что тенденция одинакова для всех.
OpenSBC
Поддерживает только SIP.
Реализованы обе схемы peer-to-peer и access.
Реализована нормализация SIP протокола, но при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником данного SBC, и как результат вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации, к тому же алгоритм изменяется от версии к версии, что не лучшим образом отражается на поддержании сети.
Транскодирования нет.
Прост в установке и обслуживании, но рассчитан на малый объем RTP трафика.
nCite1000
Заявлены обе схемы peer-to-peer и access для протокола SIP и H.323.
Реализованы обе схемы peer-to-peer и access для SIP.
Для H.323 только peer-to-peer.
Нормализация SIP протокола если и есть, то минимальная, при этом пользователь не может вносить изменения в формирование сообщений, что делает его заложником этого SBC, и, как результат, вся сеть подгоняется под SBC.
Алгоритм преодоления NAT реализован, но есть проблемы при пропуске RTP трафика без RTP проксирования на сервере обработки сигнализации.
Эта проблема решается установкой после SBC маршрутизатора с гигабитными интерфейсами, и прописыванием маршрутов в SBC. Маршрутизаторы делает данное решение слишком дорогим.
Транскодирования нет.
Прост в установке, но сложен в обслуживании. Система управления реализована с упором на красоту визуального восприятия, а не на удобство и гибкость управления (это беда, похоже, всех систем управления от AudioCodes). Серверная часть системы управления устанавливается на выделенный сервер, который устанавливается в том же сегменте, что и управляющий интерфейс nCite. При этом система управления предполагает, что интерфейс клиентского доступа сервера находится на внешних IP адресах. Вся система управления перестает работать, если установить на серверной стороне хотя бы статический NAT. А если клиент запускается из-за NAT, то требует открыть уйму портов, чем повергает в шок любого системного администратора.
Надеюсь, у других производителей дела обстоят лучше...
Нет сомнения, что данный кубик при построении VoIP сети является если не самым главным в системе, то одним из основных, наряду с SIP-сервером, и построение сетей с его использованием должно стать обязательным. Но для достижения этого SBC должен стать образцом для всех типов VoIP оборудования. Его надежность, управляемость, гибкость и функциональность должны быть на порядок выше, чем у SIP-серверов и шлюзов.
Пока же этого нет, оператор, прежде чем заплатить деньги, должен определиться, какая из схем ему ближе. В случае peer-to-peer, оператор теряет промежуточный контроль за сессиями, т.е. вся нагрузка ложиться либо на шлюз, либо на сервер. А в случае с access оператор вынужден поднимать STUN сервер или применять другие методы, т.к. в большинстве случаев STUN сервер просто бесполезен. Все бы не беда, если бы не доступность серверов из внешней сети, что ставит оператора в странное положение: с одной стороны, он должен обеспечить безопасность (устанавливать патчи на системы, делать апгрейд), а с другой - он не может этого сделать из-за лицензионной политики производителей, например компании VocalTec.
Если же оператор решился идти сквозь тернии и купил SBC, он должен понимать, что он будет вынужден подгонять все оставшиеся кубики схемы к кубику SBC. И осознать, что при проблемах на SBC проблемы будут на всей сети.
четверг, 21 мая 2009 г.
Music on hold
Резистор и конденсатор на выходе нужны, т.к. подключается это устройства на аналоговый порт, вместо телефонного аппарата. И как следствие, требуется нагрузочный резистор, для эмуляции занятия линии. А конденсатор для отсечки постоянного тока.
Подписаться на:
Сообщения (Atom)