По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Интеграция CRM – системы и корпоративной системы связи (телефонии) позволяет значительно улучшить параметры обслуживания ваших клиентов. Диапазон возможностей очень широк: прослушивание звонков в интерфейсе CRM, всплывающая карточка при входящем звонке от клиента, умная маршрутизация, которая позволяет адресовать звонок на ответственного менеджера, который закреплен за клиентом в CRM, исходящие звонки «по щелчку» мышки на номер клиента, или как его часто называют click – to – call и история звонков по каждому конкретному клиенту – все это доступно для бизнеса, который решил объединить систему управления взаимоотношениями с клиентом и офисную телефонию. . Интересно? Тогда мы рады поделиться обзором возможностей интеграции 1С CRM и IP – АТС Asterisk. Всплывающая карточка клиента При входящем звонке от клиента, в интерфейсе 1С, при совпадении номера звонящего появляется карточка контрагента. Параллельно, создается документ «событие» типа «телефонный звонок». Как видно на скриншоте, у контрагента настроен персональный менеджер. При включенной функции «Умная маршрутизация», звонок приходит прямо на указанного менеджера, минуя настроенные в Asterisk правила маршрутизации. Это означает, что если в вашей организации настроено интерактивное голосовое меню (IVR), или простое голосовое приветствие, то клиенту, у которого настроен персональный менеджер не придется слушать его – звонок сразу отправится на внутренний номер ответственного менеджера. В другом случае, если клиент звонит вам впервые, то оператору будет предложено создать нового контрагента. Важный момент, что когда вы нажмете на кнопку «Добавить контрагента», в появившейся карточке будет автоматически добавлен номер звонящего: Кстати, мы посчитали: при условии интеграции 1С и телефонии, время обработки входящего звонка уменьшается на 2 минуты – вам просто не нужно идентифицировать клиента, а затем вручную вбивать его пользовательские параметры для поиска карточки – система сразу покажет всю необходимую информацию. История звонков История звонков хранится по каждому контрагенту отдельно, а так же, есть унифицированный интерфейс, в котором можно посмотреть статистику звонков по всем операторам. В интерфейсе будут доступны как входящие, так и исходящие звонки. Помимо этого, вы можете прослушать аудио запись разговора. Важно:Сами аудио файлы хранятся на сервере IP – АТС Asterisk. По факту, на копке прослушать, будут расположены ссылки на аудио – записи в папке /var/spool/asterisk/monitor Итак, переходим во вкладку «История звонков», как показано ниже: Откроется список звонков. Значком слева, обозначено направление звонка – входящее, или исходящее. Помимо этого, в таблице мы видим дату и время начала и окончания вызова, его продолжительность в секундах, направление, ссылка на аудио – запись, ответственного пользователя, которые обработал вызов, и контрагента, с которым этот вызов связан. Вся информация представлена в наглядном и интуитивно понятном исполнении. Звонки из 1С Мы снова все посчитали, и можем сказать, что набор номер из 1С экономит от 15 секунд на исходящем звонке. Цепочка получается следующая: оператора нажимает на карточке контрагента на кнопку «Позвонить» В открывшемся окне видим все контакты по указанному контрагенту. Чтобы позвонить по номеру, достаточно левой кнопкой мыши нажать на телефон: Как только мы нажмем на номер телефона контрагента, зазвонит наш настольный телефон. Как только мы поднимаем трубку, происходит соединение с контрагентом. Умная маршрутизация Настройка умной маршрутизации происходит на уровне IP – АТС Asterisk. Для корректной работы функционала переключения вызова на менеджера, достаточно просто поставить галочку в настройках входящего маршрута.
img
YUM (Yellowdog Updater, Modified) это менеджер пакетов, используемый в Red Hat, CentOS и других дистрибутивах Linux, использующих RPM Package Manager. Yum используется для установки, обновления, удаления или других манипуляций с пакетами, установленными на этих Linux-системах. В этом руководстве мы расскажем вам о команде yum update - что она собой представляет, как ее использовать, и о различных командах, которые могут вам пригодиться, для обновления установленных пакетов в вашей системе. Как работает команда Yum Update? Yum update - это команда, используемая для обновления приложений, установленных в системе. Если команда выполняется без указания имён пакетов, она обновит все установленные в системе пакеты. $ yum update При выполнении этой команды, yum начнёт с проверки своих репозиториев на наличие обновленных версий программного обеспечения, установленных в вашей системе на данный момент. На приведенном ниже Рисунке А показан тип вывода, который вы обычно видите при первом запуске команды yum update. Как вы можете увидеть,на выводе yum сначала перечисляет запрашиваемые репозитории, которые являются стандартными репозиториями по умолчанию для CentOS: AppStream, Base и Extras.Ниже, приводится список различных пакетов, для которых были найдены обновления. В конце этого вывода yum отобразит "Сводку транзакций", которая показывает общее количество пакетов, которые должны быть установлены и обновлены. В данном примере на Рисунке Б, идёт обновление 166 пакетов и установка 6 новых пакетов. На случай, если вам интересно почему устанавливаются новые пакеты, когда мы должны были только обновить приложения, некоторые новые пакеты программного обеспечения могли стать частью этого дистрибутива Linux, или некоторые обновленные приложения могут полагаться на дополнительные пакеты, которые еще не установлены. После просмотра списка программного обеспечения, которое yum планирует обновить, вы можете подтвердить эти изменения, набрав "y" и нажав клавишу Enter. Затем Yum начнёт выполнять обновления, которые могут занять некоторое время в зависимости от скорости вашего соединения и самой системы. После его завершения вы получите итоговую сводку, как показано на рисунке В, в которой будут перечислены все пакеты, которые были успешно обновлены, а также все ошибки, которые могли возникнуть. Обновление без проверки gpg В Linux для проверки подлинности RPM пакетов используются GPG ключи. Если при запуске обычной команды обновления yum вы столкнётесь с ошибкой типа "Package NameOfPackage.rpm is not signed .. install failed!", вы можете с лёгкостью пропустить проверку подлинности RPM пакетов с помощью опции -nogpgcheck. $ yum update --nogpgcheck Данный параметр указывает команде yum игнорировать проверку GPG подписей пакетов. И будет полезен в тех случаях, когда у вас есть неподписанный пакет или просто нет ключа GPG. Обновление из локального репозитория Можно настроить локальные репозитории для команды yum при выполнении обновлений. Это зачастую делается, если вам нужно использовать yum для обновления пакетов, которые не включены в репозитории по умолчанию, или если вам нужно обновить автономную систему. Прежде всего, поместите все ваши обновленные RPM-файлы в новую папку. В этом примере мы будем использовать /root/rpms. Затем перейдите в следующую директорию, где вы можете увидеть все файлы репозитория для yum: $ cd /etc/yum.repos.d Чтобы настроить собственный репозиторий, создадим новый файл в этом каталоге. $ vi MyRepo.repo Непосредственно в вашем repo-файле задайте параметры в указанном формате, меняя строки по мере необходимости: [MyRepo] name=My Local Repo baseurl=file:///root/rpms enabled=1 gpgcheck=0 Большая разница между локальным и удаленным repo заключается в строке "baseurl", где протокол file:// указывает на локальный файл, в то время как удаленный на протоколы http:// или ftp://. Как только файл будет сохранен, примените правильные права доступа как показано ниже: $ chmod 644 MyRepo.repo Теперь репозиторий может быть готов к использованию. Перед тем, как пытаться выполнить команду yum update убедитесь, что вы очистили кэш yum использую команду: $ yum clean all Просмотр обновлений Yum может отображать доступные обновления безопасности без их установки, с помощью этой команды: $ yum updateinfo list security Если в результатах данные не возвращаются, как на рисунке выше, это означает отсутствие обновлений безопасности для всех установленных в вашей системе программных продуктов. Обновление конкретного пакета Если вам нужно обновить определенный пакет без запуска обновления для каждого установленного приложения, просто укажите имя пакета в вашей команде yum update. $ yum update name-of-package Можно указать несколько пакетов, разделенных пробелом. Вам нужно, чтобы название пакета было указано идеально, чтобы yum смог найти его в своих репозиториях; если вы не уверены в наименовании пакета, сначала проверьте, какие пакеты в настоящее время доступны для обновлений: $ yum check-update Обновить все, кроме одного пакета Если вам нужно выполнить команду yum update, но вы хотите исключить какой-либо пакет из списка обновляемых, вы можете указать опцию -exclude. Распространённая ситуация, когда администраторы могут счесть это необходимым, связана с обновлениями ядра, так как это основные обновления, которые могут привести к непредсказуемым ошибкам на рабочем сервере. Однако, они всё же могут выполнить команду для обновления менее критичных приложений. Чтобы исключить пакет (в данном примере связанные с ядром): $ yum update --exclude=kernel* Звездочка действует как подстановочный знак, в случае, если существует несколько взаимосвязанных пакетов или вы не знаете полного имени пакета. В качестве альтернативы: $ yum update -x 'kernel*' Исключение нескольких пакетов Вы можете исключить несколько пакетов с большим количеством опций -exclude. $ yum update --exclude=kernel* --exclude=httpd Используйте этот символ, как в примере выше, или же символ -x, столько раз, сколько потребуется. Проверить, когда было запущено последнее обновление Для того чтобы увидеть список транзакций с датой и временем их выполнения, воспользуйтесь командой yum history. $ yum history На приведенном выше скриншоте, вы можете видеть, что последний раз обновление программного обеспечения yum было 4 января. Откатить (отменить) обновления Отличительной особенностью "yum" является то, что она позволяет отменить последнее обновление, тем самым восстанавливая обновленные пакеты до их предыдущих версий. Каждому действию yum (установка, обновление, удаление и т.д.) присваивается идентификатор транзакции, и этот идентификатор следует указывать при отмене обновления yum.Чтобы посмотреть список идентификаторов операций для недавних действий Yum, воспользуйтесь этой командой: $ yum history На скриншоте выше вы можете видеть, что последней операцией, выполненной с помощью yum, была установка пакета httpd. Отмена установки или обновления работает таким же образом, поэтому в этом примере мы отменим последнюю установку httpd. Как показано на скриншоте, эта операция имеет ID 7. Чтобы отменить это изменение и откатить программу на предыдущую версию, выполните эту команду: $ yum history undo 7 Как обычно, yum подведёт итоги внесённых изменений и спросит, хотите ли вы продолжить с помощью подсказки Y/N.Если ввести Y, то указанная транзакция будет отменена. Чистка неудачного обновления Yum Если не удалось успешно обновить один или несколько пакетов при выполнении команды "yum update", в систему могут быть установлены дубликаты пакетов (2 версии одной и той же программы). Иногда, следуя вышеописанным инструкциям по откату, можно устранить проблему. Если это не сработает, вы можете удалить дубликаты пакетов вашей системы с помощью данной команды: $ package-cleanup --dupes Yum хранит в кэше информацию для пакетов, метаданных и заголовков. Если вы столкнулись с ошибкой,очистка кэш-памяти yum является хорошим первым шагом в устранении неполадок. Для этого используйте следующую команду: $ yum clean all Игнорирование ошибок При обновлении или установке пакета для его корректной работы может потребоваться дополнительное программное обеспечение. Yum знает об этих зависимостях и попытается разрешить их во время обновления, устанавливая или обновляя необходимые дополнительные пакеты. Если у вас возникнут проблемы с установкой необходимых компонентов, это приведёт к ошибке и не позволит продолжить работу. Это может стать проблемой, если у вас есть другие пакеты, которые необходимо обновить. Чтобы дать инструкции yum продолжить обновление других пакетов и пропустить пакеты с поврежденными зависимостями, вам следует указать параметр -skip-broken в команде yum update. $ yum update --skip-broken Вывести список пакетов, которые нужно обновить. Выполнение команды Yum update в обычном режиме без дополнительных опций выведет список всех доступных обновлений. $ yum update Если вы хотите посмотреть дополнительную информацию о доступных обновлениях пакета, введите эту команду: $ yum updateinfo Чтобы посмотреть информацию касательно обновлений безопасности, которые доступны для системы, введите эту команду: $ yum updateinfo security Разница между командами yum check update и yum list update Хотя эти две команды звучат одинаково, но есть разница между проверкой обновлений и списком обновлений в yum. $ yum list updates Команда list updates, показанная выше, перечислит все пакеты в репозиториях, для которых доступны обновления. Имейте в виду, что некоторые пакеты в репозиториях могут быть вообще не установлены в вашей системе. $ yum check-update Указанная выше команда check-update позволяет проверять наличие обновлений без вмешательства пользователя. Это команда подойдёт в тех случаях, если вы пишите скрипт для проверки обновлений. Если есть пакеты с доступными обновлениями, команда check-update вернёт значение 100, а если нет доступных обновлений, то значение 0. При обнаружении ошибки возвращается значение 1. Используйте эти значение чтобы надлежащим способом написать свой скрипт. Уведомление о наличии доступных обновлений Есть несколько пакетов, которые могут помочь управлять обновлениями yum в вашей системе.Некоторые из них могут даже уведомлять администраторов, если есть обновления, которые можно установить.Один из таких сервисов называется yum-cron. Для начала установите yum-cron используя yum: $ yum install yum-cron Установите службу yum-cron для запуска при загрузке: $ systemctl enable yum-cron.service $ systemctl start yum-cron.service Настройте параметры yum-cron внутри конфигурационного файла с помощью vi или предпочитаемого вами текстового редактора: $ vi /etc/yum/yum-cron.conf В этом файле вы можете указать, должны ли обновления применяться автоматически или нет. Если вы хотите только получать уведомления, введите данные электронной почты в файле конфигурации. В любое время, когда появятся обновления для вашей системы, yum-cron отправит вам электронное письмо. apply_updates = no #don’t apply updates automatically email_from = root@localhost email_to = admin@example.com email_host = localhost Какой порт использует yum update При проверке обновлений yum использует порт 80. Если вы загляните внутрь файлов репозитория в вашей системе, то вы увидите, что все ссылки внутри начинаются с http. Таким образом, для нормального функционирования yum на брандмауэре нужно прописать правило и открыть порт 80. Yum update против upgrade До сих пор в этом руководстве мы говорили только о команде yum update, но есть и другая очень похожая команда: yum upgrade. $ yum upgrade Существует небольшая разница между этими двумя командами. Yum update обновит пакеты в системе, но пропустит удаление устаревших пакетов. Yum upgrade тоже обновит все пакеты в вашей системе, но также удалит устаревшие пакеты. Это по своей сути более безопасный вариант команды yum update, поскольку вам не нужно беспокоиться о случайном удалении необходимого пакета при обновлении программного обеспечения. Будьте внимательны при вводе команды yum upgrade, так как она может не сохранить некоторые пакеты, которые вы всё ещё используете. Я надеюсь, что вы найдете это руководство полезным при работе с утилитой yum.
img
Определение проблемного пространства Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это. На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети. Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации. Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки. По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов. Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же. Почему бы просто не сделать линии связи достаточно большими? После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех. К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований. Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем? Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола. Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки. Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи. Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах. В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы. Классификация Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется? Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре. Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию. Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети. Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты. Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4. В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета. Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети. Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение. Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы. В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия. На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе. Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика. Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP. Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF. В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д. Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов. RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46). Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS? На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик. Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59