По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Интересная проблема, упомянутая как в RFC 2597, так и в RFC 3246, - это проблема сохранения метки при туннелировании помеченного пакета. Когда пакет туннелируется, исходный пакет оборачивается-или инкапсулируется-внутри нового IP-пакета. Значение байта ToS находится внутри IP-заголовка теперь инкапсулированного пакета. Ой-ой. Что только что произошло с тщательно разработанной схемой классификации трафика? Ответ заключается в том, что сетевые устройства участвуют в отражении ToS при туннелировании.
Когда пакет туннелируется, значение байта ToS в инкапсулированном пакете копируется (или отражается) в IP-заголовке туннельного пакета. Это сохраняет классификацию трафика туннелированного приложения.
Аналогичная проблема возникает при отправке маркированного трафика из сетевого домена, который вы контролируете, в тот, который вам не принадлежит. Наиболее распространенный пример - отправка помеченного трафика из вашей локальной сети в сеть вашего поставщика услуг, пересекая его глобальную сеть. Поставщики услуг, как часть контракта на обеспечение связи, также часто предоставляют дифференцированные уровни обслуживания. Однако, чтобы они могли предоставлять дифференцированные услуги, трафик должен быть помечен таким образом, чтобы они могли его распознать. Их схема маркировки вряд ли будет такой же, как ваша схема маркировки, учитывая огромное количество возможных возможных схем маркировки.
Предлагается несколько решений этой дилеммы:
Мутация DSCP: в этом сценарии сетевое устройство на границе между LAN и WAN переводит метку из исходного значения, назначенного в LAN, в новое значение, которое будет соблюдать SP. Перевод выполняется в соответствии с таблицей, настроенной сетевым инженером.
Трансляция DSCP: для провайдеров SP нередко наблюдаются только первые три бита байта ToS, что восходит к временам IP Precedence, определенным еще в RFC791.
Во втором решении сетевой инженер сталкивается с проблемой создания современной схемы маркировки DSCP с использованием шести битов, даже если поставщик услуг будет обращать внимание только на первые три. Задача состоит в том, чтобы поддерживать дифференциацию. Например, рассмотрим схему, показанную в таблице ниже. Эта схема не решит проблему.
В этой таблице определены шесть уникальных значений DSCP для использования в локальной сети. Однако эти шесть уникальных значений уменьшаются до трех уникальных значений, если только первые три бита учитываются поставщиком услуг. Это означает, что некоторый трафик, который до попадания в сеть провайдера мог обрабатываться по-разному, теперь будет помещен в одну корзину. В этом примере EF и CS5, ранее уникальные, попадают в один и тот же класс, когда они покидают граничный маршрутизатор, поскольку оба начальных бита EF и CS5 равны 101. То же самое касается AF11, AF12 и AF13 - три ранее различных классы трафика, которые теперь будут обрабатываться одинаково при прохождении SP WAN, поскольку все они имеют одинаковое начальное значение 001 в начальных трех битах.
Способ решить эту проблему - создать схему маркировки DSCP, которая будет поддерживать уникальность в первых трех битах, как показано в таблице. Однако для этого может потребоваться сокращение общего количества классов трафика. Ограничение схемы первыми тремя битами для определения классов уменьшит общее количество классов до шести.
В таблице выше показана схема маркировки, использующая сочетание значений EF, AF и Class Selector, специально выбранных для сохранения уникальности первых трех битов.
Ваш клиент хочет перестроить свою систему IP-телефона или, возможно, впервые перейти на нее. Вы придете к нему с проприетарной системой, например, CUCM, или открытой стандартной системой, например, Asterisk? Прежде чем сделать выбор, важно не упускать сразу ни один из вариантов. Понимание всех входов и выходов каждого типа системы, а также конкретных требований вашего клиента имеет важное значение.
Давайте рассмотрим некоторые сильные и слабые стороны каждого подхода.
Положительные и отрицательные стороны открытых АТС
АТС с открытым стандартом являются решениями с открытым стеком, использующими стандартный подход - например, SIP - для передачи мультимедийных сообщений. Широко распространенные и признанные благодаря своей универсальности в использовании и гибкости, системы АТС с открытым стандартом не имеют многих недостатков для многих предприятий сегодня. Наряду с необходимыми функциями телефонии, некоторые передовые решения, также предлагают высококачественные унифицированные коммуникации из коробки. В целом системы АТС с открытым стандартом обеспечивают:
Лучшее соотношение цены и качества:
Опенсорс АТС часто ассоциируется с существенной экономией, потому что ею легко управлять, и в большинстве случаев нужно беспокоиться о небольших лицензионных сборах. По сравнению с запатентованными решениями, которые заключают вас в долгосрочные контракты на обслуживание или дорогостоящий ремонт системы, решения с открытыми стандартами могут быть более рентабельными во многих бизнес-сценариях.
Устранить риск блокировки поставщика:
Истинная ценность таких АТС заключается в возможности сочетать набор стандартных компонентов для предоставления инновационных услуг. С системой можно использовать практически любой SIP-телефон, шлюз или периферийные устройства на основе стандарта, что способствует удовлетворенности пользователей и производительности бизнеса.
Проще установить и настроить:
Если вы используете проприетаруню телефонную систему, вы, вероятно, уже знаете о трудностях, возникающих при ее установке, использовании и обслуживании. Вместо этого системы АТС открытого стандарта просты в использовании и управлении. Это может быть особенно актуально для тех, кто использует Asterisk с интуитивно понятным интерфейсом.
Совместимость и настройка:
Кастомизация очень важна для телефонных систем. И на этом этапе выигрывают АТС открытого стандарта. Относительно легко интегрироваться с другими стандартными приложениями, такими как базы данных, CRM, PMS отеля, колл-центр и другие, чтобы удовлетворить специфические потребности клиентов.
Хотя АТС с открытым стандартом, по большому счету, не имеют многих недостатков, качество всей системы сильно зависит от поставщиков и интеграторов. Некоторые, выбравшие бесплатные открытые решения утверждают, что им не хватает нужных функций, профессиональной поддержки и частых обновлений.
Положительные и отрицательные стороны проприетарной АТС
Проприетарной АТС являются «закрытой» системой, разработанной специально производителями, в комплекте с собственным брендом. Большинство проприетарных решений, таких как NEC или Panasonic, считаются относительно надежными, но менее привлекательными с финансовой точки зрения. С проприетарной системой вы получаете практически все ваше оборудование и программное обеспечение от одного поставщика, который будет поддерживать и гарантировать все, от АТС до мобильных телефонов. Таким образом, некоторые из преимуществ включают в себя:
Единый пользовательский опыт:
В большинстве случаев проприетарные системы предлагают единый пользовательский интерфейс. Вся система VoIP остается согласованной для всех совместимых аппаратных и программных приложений. Таким образом, вы можете ожидать аналогичного и знакомого взаимодействия с каждым устройством.
Поддержка производителя:
Благодаря проприетарной системе ваш поставщик имеет единоличный контроль над обновлениями, обновлениями и модификациями. Как следствие, вы, как торговый посредник или дистрибьютор, могли бы иметь больший контроль над клиентами, но вам нужно будет вкладывать больше ресурсов в освоение сложных запатентованных систем и интерфейсов для лучшей поддержки клиентов.
Наряду с преимуществами проприетарного решения, есть некоторые недостатки, которыми нельзя пренебрегать. Самые большие из них могут быть связаны с затратами, риском блокировки поставщиков и ограниченной гибкостью. Многие запатентованные продукты могут функционировать должным образом только при использовании с другими продуктами того же производителя. Другими словами, вы, скорее всего, будете заложниками проприетарных мобильных телефонов и периферийных устройств, которые могут быть переоценены с ограниченной функциональностью, что приведет к негативным последствиям в процессе продаж.
Еще одна важная вещь, которую следует помнить, это то, что с проприетарной системой АТС вы не сможете достичь того же уровня гибкости, что и решения с открытыми стандартами. Поскольку проприетарные решения обычно не допускают обходных путей для разработчиков, специфичных для данной проблемы, скорее всего, вы не сможете реализовать наименьшие изменения, необходимые для лучшей адаптации решения к потребностям вашего бизнеса. И когда возникают сложные проблемы, ваш поставщик является вашей единственной резервной копией.
Предвидение: бизнес-экосистема и возможности
В условиях постоянно расширяющегося горизонта и достижений на рынке VoIP ключом к тому, чтобы телефонная система оставалась впереди, было стремление идти в ногу с рыночными тенденциями и предлагать жизнеспособные решения, чтобы вписаться в более широкий спектр потребностей клиентов. И нельзя отрицать, что решения открытых стандартов имеют конкурентные преимущества.
Роль собственности как первичного новатора на рынке ушла на второй план. Распространенность промышленных открытых стандартов, таких как SIP и телефония с открытым исходным кодом, таких как Asterisk, произвела революцию в экосистеме и принесла больше возможностей для бизнеса.
Используя коллективные усилия огромного мирового сообщества экспертов, новые непатентованные, то есть открытые, системы набирают обороты. Они приносят преимущества, связанные с открытым SIP и открытым исходным кодом: стабильность, быстрое развитие, гибкость и, самое главное, экономия затрат.
Благодаря постоянно развивающимся решениям открытого стандарта пользователям теперь предоставляется больше свободы для взаимодействия нескольких приложений и интеграции систем данных. Интеграторы все чаще хотят их, а конечные пользователи требуют от них более высокого уровня соотношения цена-качество и устранения риска привязки к поставщику.
Итого
И проприетарные, и открытые стандартные системы имеют свои явные преимущества. Важно знать своих клиентов и понимать их потребности. Сколько они могут позволить себе новую телефонную систему? Какой уровень гибкости и настройки они требуют? Есть ли у них собственный опыт по обслуживанию системы? Задавая правильные вопросы, вы сможете сделать выбор, чтобы предложить наилучшее решение.
Всем привет! Недавно мы в одной из наших статей рассматривали, как сделать резервную копию Cisco Unified Communications Manager (CUCM) при помощи системы восстановления системы Disaster Recovery System (DRS). Сегодня рассмотрим метод архивации и восстановления при помощи интерфейса командной строки (CLI), который может использоваться в случае, когда нет возможности воспользоваться графическим интерфейсом.
Создание бэкапа
Сначала нужно указать устройство, на которых будет храниться бэкап (SFTP сервер). Для начала нужно выполнить команду:
utils disaster_recovery device add network [devicename path] [server_name/ip_address] [username] [number_of_backups]
devicename – имя устройства резервного копирования;
path – путь до архива;
server_name/ip_address – имя хоста или IP - адрес устройства, где будет храниться архив
username – имя пользователя, необходимое для подключения к серверу;
number_of_backups – количество бэкапов, которое будет создано. По умолчанию 2. Опциональный параметр;
Пример:
admin: utils disaster_recovery device add network networkDevice /root 192.168.1.1 root 3
Посмотреть список добавленных устройств можно используя команду:
utils disaster_recovery device list
Далее создаем резервную копию, выполнив команду
utils disaster_recovery backup network [featurelist] [path] [servername] [username]
featurelist – список функций для создания копии, разделяется запятой;
path – путь до архива;
servername – имя хоста или ip адрес устройства, где будет храниться архив;
username – имя пользователя, необходимое для подключения к серверу;
Список функций можно получить используя команду:
utils disaster_recovery show_registration
Чтобы проверить статус бэкапа используем команду:
utils disaster_recovery status backup
Восстановление
Сначала проверим наличие файлов на SFTP сервере:
utils disaster_recovery show_backupfiles [name]
name – имя устройства резервного копирования
Выбираем файл бэкапа, из тех, которые отобразились при выводе предыдущей команды:
utils disaster_recovery restore network [restore_server] [tarfilename] [devicename]
restore_server – имя хоста или ip адрес устройства, где будет храниться архив;
tarfilename – имя файла бэкапа;
devicename – имя устройства резервного копирования;
Пример:
utils disaster_recovery restore network 192.168.1.1 2018-01-15-15-35-28 networkDevice
На вопрос действительно ли мы хотим восстановить систему отвечаем “y”.
После этого проверяем статус восстановления системы:
utils disaster_recovery status restore