Часто задаваемые вопросы о QoS
Содержание
Введение
В этом документе содержатся вопросы и ответы о качестве обслуживания (QoS).
Общие сведения
Вопрос. Что такое качество обслуживания (QoS)?
А. QoS обращается к возможности сети предоставлять лучшее обслуживание выбранного сетевого трафика помощью различных основных технологий, включая Frame Relay, Технологию ATM, сети Ethernet и 802.1, SONET и сети с IP-маршрутизацией.
QoS – это совокупность технологий, позволяющих приложениям запрашивать и получать предсказуемые уровни обслуживания в терминах пропускной способности, изменения латентности (дрожание) и задержки. В частности, функции QoS предоставляют более качественное и более предсказуемое сетевое обслуживание за счет использования следующих методов:
Поддержка выделенной полосы пропускания.
Улучшение характеристик, связанных с потерями.
Уменьшение и предотвращение перегрузок сети.
Формирование сетевого трафика.
Настройка приоритетов трафика по всей сети.
Internet Engineering Task Force (IETF) определяет две следующие архитектуры QoS:
Комплексные услуги (IntServ)
Дифференцированные услуги (DiffServ)
IntServ использует протокол резервирования ресурсов (RSVP) для явной сигнализации о требуемом QoS для трафика приложения между устройствами в сквозном пути через сеть. Если каждое устройство на маршруте способно поддерживать необходимую пропускную способность, исходящее приложение сможет начать передачу. Запрос комментариев (RFC) 2205 определяет RSVP, а запрос комментариев 1633 определяет IntServ.
Услуги DiffServ в основном ориентированы на объединенное и конфигурируемое QoS. Вместо сигнализации требований QoS приложения DiffServ использует DiffServ Code Point (DSCP) в IP-заголовке для указания требуемых уровней QoS. Благодаря выпуску ПО Cisco IOS® 12.1(5)T для маршрутизаторов Cisco было обеспечено соответствие требованиям DiffServ. Дополнительные сведения см. в следующих документах:
Вопрос. Что такое перегрузка, задержка и дрожание?
Ответ. Интерфейс испытывает перегрузку, когда ему приходится обрабатывать избыточный объем трафика. Точки перегрузки сети являются наиболее вероятным местом использования механизмов качества обслуживания (QoS). Ниже приведен пример типичных точек перегрузки:
Перегрузка сети приводит к задержкам. В сети и устройствах сети могут возникать несколько видов задержек, как объясняется в разделе Общие сведения о задержках в сетях для передачи речевых пакетов. Вариации задержки известны как дрожание, см. раздел Общие сведения о дрожании в сетях для передачи речевых пакетов (платформы Cisco IOS). Как задержку, так и дрожание необходимо контролировать и сводить к минимуму для поддержки интерактивного трафика в режиме реального времени.
Вопрос. Что такое MQC?
Ответ. MQC обозначает модульный интерфейс командной строки (CLI) качества обслуживания (QoS). MQC призван упростить настройку QoS на маршрутизаторах и коммутаторах Cisco путем определения общего синтаксиса команды и результируемых характеристик QoS на всех платформах. Эта модель используется вместо предшествующей модели определения уникального синтаксиса для каждой функции QoS и для каждой платформы.
MQC включает три этапа:
Определение класса трафика путем выполнения команды class-map.
Создание политики трафика путем связи класса трафика с одной или более функцией QoS с помощью выполнения команды policy-map.
Подключение политики трафика к интерфейсу, субинтерфейсу или виртуальному каналу (VC) путем выполнения команды service-policy.
Примечание. Функции согласования трафика DiffServ, такие как маркирование и формирование, применяются с помощью синтаксиса MQC.
Дополнительную информацию см. в разделе Модульный интерфейс командной строки качества обслуживания.
Вопрос. Что означает сообщение service-policy is supported only on VIP interfaces with DCEF enabled?
Ответ. На универсальных интерфейсных процессорах (VIP) в Cisco серии 7500 поддерживаются только функции распределенного качества обслуживания (QoS), такие как Cisco IOS 12.1(5)T, 12.1(5)E и 12.0(14)S. При активации распределенной скоростной передачи Cisco (dCEF) автоматически активируется функция распределенного QoS.
Интерфейсы, не являющиеся интерфейсами универсального интерфейсного процессора (VIP), также известные как унаследованные интерфейсные процессоры (IP), поддерживают основные функции QoS, активированные на процессоре маршрутизации (RSP). Дополнительные сведения см. в следующих документах:
Вопрос. Сколько классов поддерживает политика качества обслуживания (QoS)?
Ответ. В версиях Cisco IOS ниже 12.2 можно было задать максимум 256 классов и до 256 классов внутри каждой политики, если одни и те же классы использовались в разных политиках. При наличии двух политик общее количество классов из обеих политик не должно превышать 256. Если в состав политики входит алгоритм взвешенной справедливой организации очередей на основе классов (CBWFQ) (что означает наличие инструкции о пропускной способности [или приоритете] в любом из классов), общее количество поддерживаемых классов равно 64.
В версиях Cisco IOS 12.2(12),12.2(12)T и 12.2(12)S данное ограничение в 256 глобальных карт классов было изменено; теперь существует возможность настроить до 1024 глобальных карт классов и использовать 256 карт классов внутри одной и той же карты политики.
Вопрос. Как выполняются обновления маршрутизации и поддерживается активность протокола точка-точка (PPP) / высокоуровневого управления каналом передачи данных (HDLC), когда применяется политика обслуживания?
A. Маршрутизаторы Cisco IOS используют следующие два механизма для назначения приоритетов контрольным пакетам:
Протокол IP Precedence
pak_priority
Оба механизма разработаны для того, чтобы контрольные пакеты не отбрасывались маршрутизатором или системой организации очереди (либо отбрасывались в последнюю очередь) при перегрузке исходящего интерфейса. Дополнительные сведения см. в документе Основные сведения об обновлении маршрутизации и управляющих пакетах, которые ставятся в очередь на интерфейсе с приоритетом политики службы QoS.
В. Поддерживается ли политика качества обслуживания (QoS) в интерфейсах, настроенных с использованием встроенной маршрутизации и мостов (IRB)?
О. Нет. Если интерфейс настроен с использованием IRB, настройка компонентов QoS недоступна.
Классификация и маркировка
Вопрос. Что такое предварительная классификация качества обслуживания (QoS)?
Ответ. Предварительная классификация QoS позволяет согласовывать и классифицировать содержимое первоначального заголовка IP при туннельной инкапсуляции и/или шифровании пакетов. Данная функция не описывает процесс копирования первоначального значения байта типа обслуживания (ToS) из первоначального заголовка пакета в туннельный заголовок. Дополнительные сведения см. в следующих документах:
Вопрос. Какие поля заголовка пакета могут быть помечены? Какие значения доступны?
Ответ. Функция маркировки на основе класса позволяет устанавливать или помечать уровень 2, уровень 3 или заголовок многопротокольной коммутации по меткам (MPLS) пакетов. Дополнительные сведения см. в следующих документах:
Вопрос. Можно ли задать приоритет трафика на основе URL?
Ответ: Да. Средство распознавания приложения по сетевым параметрам позволяет классифицировать пакеты по соответствию полей на уровне приложения. До введения NBAR наиболее точным средством классификации были номера портов протокола управления передачей уровня 4 (TCP) и протокола датаграмм пользователя (UDP). Дополнительные сведения см. в следующих документах:
Вопрос. Какие платформы и версии ПО Cisco IOS поддерживают средство распознавания приложения по сетевым параметрам (NBAR)?
A. Поддержка NBAR представлена в следующих версиях программного обеспечения Cisco IOS:
Платформа Минимальная версия программного обеспечения Cisco IOS 7200 12.1(5)T 7100 12.1(5)T 3660 12.1(5)T 3640 12.1(5)T 3620 12.1(5)T 2600 12.1(5)T 1700 12.2(2)T Примечание. Чтобы использовать NBAR, необходимо активировать функцию Cisco Express Forwarding (CEF).
Распределенная функция NBAR (DNBAR) доступна на следующих платформах:
Платформа Минимальная версия программного обеспечения Cisco IOS 7500 12.2(4)T, 12.1(6)E Flex WAN 12.1(6)E Примечание. NBAR не поддерживается на интерфейсах VLAN платы многоуровневой коммутации (MSFC) Catalyst 6000, в серии продуктов Cisco 12000 или на модуле переключения маршрутов (RSM) для серии Catalyst 5000. Если определенная платформа из вышеперечисленных не используется, свяжитесь с представителем службы технической поддержки Cisco.
Управление формированием очередей и устранение перегрузки
Вопрос. Какова цель формирования очередей?
Механизм постановки в очередь разработан для компенсации временных перегрузок интерфейса сетевого устройства путем хранения пакетов, которые невозможно обработать в момент получения, в буферах до освобождения канала пропускания. Маршрутизаторы Cisco IOS поддерживают несколько методов формирования очереди, которые способны удовлетворить особые требования к пропускной способности, дрожанию и задержке различных приложений.
В большинстве интерфейсов механизмом по умолчанию является FIFO. Некоторые типы трафика имеют более высокие требования к задержке/дрожанию. Thus, one of the following alternative queueing mechanisms should be configured or is enabled by default:
Взвешенная справедливая очередность (WFQ)
Взвешенная организация очередей на основе классов (CBWFQ)
Организация очереди с низкой задержкой (LLQ), которая фактически является CBWFQ с очередью по приоритету (PQ) (которая называется PQCBWFQ)
Очереди по приоритетам (PQ)
Настраиваемая очередь (CQ)
Как правило, формирование очереди происходит только на исходящих интерфейсах. Маршрутизатор помещает в очередь пакеты, которые передаются из интерфейса. Можно контролировать входящий трафик с помощью политик, но, как правило, входящий трафик невозможно формировать в очереди (исключением является буферизация стороны получателя на маршрутизаторе Cisco серии 7500 с помощью распределенной технологии Cisco Express Forwarding (dCEF)) для отправки пакетов с входящего на исходящий интерфейс; для получения дополнительных сведения см. раздел Общие сведения о VIP CPU, работающих на 99% и буферизации стороны получателя. На высокопроизводительных распределенных платформах, таких как Cisco серии 7500 и 12000 входной интерфейс может использовать собственные буферы пакетов для хранения дополнительного трафика, переданного в перегруженных выходной интерфейс, следуя решению входного интерфейса о коммутации. В некоторых случаях, обычно если входной интерфейс обеспечивает работу более медленного выходного интерфейса, во входном интерфейсе возможно увеличение числа пропущенных ошибок по причине переполнения памяти пакетов. Избыточная перегруженность может привести к удалению из очереди исходящих пакетов. Сбросы входной очереди в большинстве случаев имеют разные причины. Дополнительные сведения об устранении неполадок, связанных с удалениями, см. в следующем документе:
Дополнительные сведения см. в следующих документах:
Вопрос. Как работают механизмы взвешенной справедливой организации очередей (WFQ) и взвешенной справедливой организации очередей на основе классов (CBWFQ)?
Ответ. Принцип равноправной организации очередей заключается в равномерном распределении полосы пропускания интерфейса между активными вызовами и IP-потоками. Это классифицирует пакеты в подочередность, которая определяется с помощью идентификационного номера сообщения, с использованием хеш-алгоритма, основанного на нескольких полях IP-заголовка и длине пакета. Вес рассчитывается следующим образом:
W=K/(precedence +1)
K= 4096 на Cisco IOS 12.0(4)T и более ранних версиях, а также 32384 на 12.0(5)T и более поздних версиях.
Меньше вес, больше приоритетность и общее пользование полосой пропускания. Учитывается не только вес, но и длина пакета.
CBWFQ позволяет определить класс трафика и назначить ему гарантированную минимальную полосу пропускания. Алгоритмом этого механизма является WFQ, что объясняет имя. Для настройки CBWFQ следует указать определенные классы в инструкциях классов схем. Затем назначается политика каждому классу в карте политики. Данная карта политик будет привязана к интерфейсу. Дополнительные сведения см. в следующих документах:
Вопрос. Если класс в алгоритме взвешенной справедливой организации очередей на основе классов (CBWFQ) не использует свою полосу пропускания, могут ли другие классы использовать эту полосу пропускания?
Ответ: Да. Несмотря на то, что гарантии пропускной способности, обеспеченные командами bandwidth и priority, определены такими словами, как "резервный" и "выделенная полоса пропускания", в действительности ни одна команда не выполняет резервирования в истинном значении этого слова. Значит, если класс трафика не использует свою полосу пропускания, то любая свободная полоса пропускания разделяется между другими классами.
В системе организации очереди используется класс приоритетов, для которого это правило не выполняется. Как уже упоминалось, абонентская нагрузка для класса приоритета измеряется ограничителем скорости трафика. Во время перегрузок приоритетный класс не может использовать любую дополнительную полосу пропускания. Дополнительные сведения см. в разделе Сравнение команд пропускной способности и приоритета политики службы QoS.
Вопрос. Поддерживается ли взвешенная справедливая организация очередей на основе классов (CBWFQ) на субинтерфейсах?
Ответ. Логические интерфейсы Cisco IOS в действительности не поддерживают состояние перегруженности и не поддерживают прямое приложение служебной политики, применяющей метод постановки в очередь. Вместо этого сначала необходимо применить формирование трафика к субинтерфейсу, используя формирование общего трафика (GTS) или механизм формирования трафика на основе классов. Для получения дополнительных сведений см. раздел Применение функций QoS на субинтерфейсах Ethernet.
Вопрос. Каковы различия между командами priority (приоритета) и bandwidth (полосы пропускания) в карте политики?
Ответ. Команды priority и bandwidth отличаются как в том, что касается функциональности, так и в том, что касается обычно поддерживаемых приложений. Данные различия суммированы в следующей таблице:
Функция команда "bandwidth" команда priority Минимальная гарантированная пропускная способность Да Да Максимальная гарантированная пропускная способность Нет Да Встроенный ограничитель скорости Нет Да Обеспечивает небольшую задержку Нет Да
Вопрос. Как рассчитывается предельный размер очереди на FlexWAN и универсальных интерфейсных процессорах (VIP)?
Ответ. При условии достаточного объема SRAM на VIP или FlexWAN максимальный размер очереди рассчитывается на основе максимальной задержки в 500 мс и среднего размера пакета 250 байт. Ниже приведен пример класса с одной полосой пропускания, равной одному Мбит/с:
Предел очереди = 1000000 / (250 x 8 x 2) = 250
С сокращением объема свободной памяти пакетов и ростом числа виртуальных каналов (VC) назначаемые пределы очередей уменьшаются.
В приведенном примере PA-A3 установлен на плату FlexWAN для серии Cisco 7600 и поддерживает несколько подчиненных интерфейсов с PVC на 2 МБ. Служебная политика применяется к каждому VC.
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048KbpsИнтерфейс Технологии ATM получает ограничение очереди для всего интерфейса. Функция ограничения (limit) распространяется на все доступные буферы, все физические интерфейсы FlexWAN и значение максимальной задержки очереди, разрешенной для интерфейса. Каждый PVC получает часть предельной нормы интерфейса в зависимости от средней скорости передачи ячеек или минимальной скорости передачи ячеек PVC. Каждый класс получает часть предельной нормы PVC в зависимости от распределения его полосы пропускания.
Ниже приведены выходные данные команды show policy-map interface, полученные из сети FlexWAN c 3687 глобальными буферами. Задайте команду show buffer, чтобы просмотреть это значение. Каждому каналу PVC в 2 Мбит/с выделяется 50 пакетов на основе пропускной способности PVC, равной 2 Мбит/с (2047/149760 x 3687 = 50). Каждому классу назначена порция из 50 пакетов, как видно из следующих выходных данных:
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0Если в потоках трафика используются большие размеры пакетов, выходные данные команды интерфейса show policy-map могут сообщить об увеличивающемся значении для поля no buffer drops, так как буферы могут закончиться до момента достижения предела очереди. В данном случае попытайтесь вручную настроить ограничение очередей в неприоритетных классах до меньших значений. Дополнительные сведения см. в разделе Общие сведения о пределе очереди с классом обслуживания "IP к ATM".
Вопрос. Как проверить значение предела очереди?
Ответ. На нераспределенных платформах значение предела очереди по умолчанию равно 64 пакетам. Следующий пример выходных данных был получен на маршрутизаторе Cisco серии 3600:
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
Вопрос. Можно ли включить равномерное формирование очередей внутри класса?
Ответ. Cisco серии 7500 с распределенным качеством обслуживания (QoS) поддерживают равномерную организацию очередей по классам. Другие платформы, включая Cisco серии 7200 и Cisco серии 2600/3600, поддерживают алгоритм взвешенной справедливой организации очередей (WFQ) в классе по умолчанию; во всех классах полосы пропускания используется метод First In First Out (FIFO).
Вопрос. Какие команды можно использовать для контроля формирования очередей?
Ответ. Для контроля формирования очередей используются следующие команды:
show queue {interface}{interface number} - на платформах Cisco IOS, кроме платформ Cisco серии 7500, эта команда отображает активные очереди или разговоры. Если интерфейс или виртуальный канал (VC) не перегружен, то очереди в списке не появятся. На Cisco серии 7500 команда show queue не поддерживается.
show queueing interface interface-number [vc [[vpi/] vci] - эта команда отображает статистику формирования очередей на интерфейсе или виртуальном канале. Даже в случае отсутствия перегрузки здесь по-прежнему можно будет увидеть, что некоторые очереди используются. Причина в том, что подсчет пакетов типа process switched выполняется всегда вне зависимости от наличия перегрузки. Пакеты экспресс-пересылки Cisco и пакеты с механизмом обработки fast-switched не подсчитываются, если нет перегрузки. Устаревшие механизмы формирования очередей, например приоритетная очередь (PQ), настраиваемая организация очередей (CQ) и взвешенная справедливая организация очередей (WFQ) не предоставляют статистику классификации. Данную статистику предоставляют только функции на базе интерфейса командной строки модульного качества обслуживания (MQC) в образах версий более поздних, чем 12.0(5)T.
show policy interface {interface}{interface number} - счетчик packets подсчитывает количество пакетов, соответствующих критериям класса. Счетчик увеличивается независимо от того, перегружен ли интерфейс или нет. Счетчик packets matched указывает количество пакетов, соответствующих критериям класса, когда интерфейс перегружен. Дополнительные сведения о счетчиках пакетов см. в следующем документе:
Общие сведения о счетчиках пакетов в выходных данных команды show policy-map interface
Конфигурация QoS на основе классов Cisco и статистика управления базой административной информации предоставляют функции контроля простого протокола управления сетью (SNMP).
Вопрос. RSVP можно использовать в сочетании с алгоритмом взвешенной справедливой организации очередей на основе классов (CBWFQ). При одновременной настройке для интерфейса протокола резервирования ресурсов (RSVP) и CBWFQ - работают ли RSVP и CBWFQ независимо друг от друга, проявляя характеристики, свойственные им при работе в одиночном режиме? RSVP функционирует так, как если бы функция CBWFQ не была настроена в том, что касается доступности полосы пропускания, оценки и распределения.
Ответ. При использовании RSVP и CB-WFQ с версией ПО Cisco IOS 12.1(5)T (и более поздней) маршрутизатор может действовать таким образом, чтобы потоки RSVP и классы CBWFQ разделяли доступную пропускную способность канала на интерфейсе или PVC без превышения лимита подписки.
Программное обеспечение IOS Software версии 12.2(1)T (и более поздних версий) позволяет RSVP управлять разрешениями на подключение с помощью собстенного пула "ip rsvp bandwidth", в то время как CBWFQ управляет классификацией, контролем и планированием пакетов RSVP. Это допускает маркировку пакетов отправителем, а не-RSVP пакеты маркируются по-разному.
Предотвращение перегрузок; случайное взвешенное предварительное обнаружение (WRED)
Вопрос. Можно ли активизировать случайное взвешенное предварительное обнаружение (WRED) и очередь с низкой задержкой (LLQ) или взвешенную справедливую организацию очередей на основе классов (CBWRQ) одновременно?
Ответ: Да. Очередность задает порядок, в котором пакеты покидают очередь. Это означает, что задается механизм планирования пакетов. Данная функция также может использоваться для обеспечения равноправного назначения полосы пропускания и гарантий минимальной полосы пропускания. Напротив, в запросе на комментарий (RFC) 2475 отбрасывание пакетов определяется как "процесс исключения пакетов на базе заданных правил" Механизм отбрасывания по умолчанию представляет собой отбрасывание "с хвоста", когда интерфейс отбрасывает пакеты, если очередь заполнена. Альтернативным механизмом отбрасывания является случайное раннее обнаружение (RED) и механизм WRED Cisco, который начинает случайное отбрасывание пакетов перед переполнением очереди и поддерживает постоянную среднюю глубину очереди. Механизм очередности WRED использует IP-приоритет пакетов для принятия дифференцированного решения о сбросе пакета. Дополнительные сведения см. в разделе Взвешенное произвольное раннее обнаружение.
Вопрос. Как осуществлять мониторинг случайного взвешенного предварительного обнаружения (WRED) и как убедиться, что WRED действительно работает?
Ответ. WRED контролирует среднюю глубину очередности и начинает отбрасывать пакеты, когда вычисляемое значение превосходит минимальное пороговое значение. Введите команду show policy-map interface и проконтролируйте значение средней глубины очереди, как показано в следующем примере:
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
Назначение политик и формирование
Вопрос. В чем состоит различие между назначением политик и формированием?
Ответ. Главное различие показано на следующей схеме. В процессе формирования трафика избыточные пакеты помещаются в очередь и планируются для последующей передачи. Результатом процесса формирования трафика является более ровная выходная скорость передачи пакетов. Сравните, управление трафиком передает пакеты. Когда скорость трафика достигает заданной максимальной скорости, лишний трафик отбрасывается (или помечается). Результат скорости вывода отображается в виде пилообразной линии с гребнями и впадинами.
Дополнительные сведения см. в документе Обзор назначения политик и формирования трафика.
Вопрос. Что такое алгоритм token bucket (контейнера маркеров) и как он работает?
Ответ. Сам по себе алгоритм token bucket не использует политик отбрасывания или приоритетности. Ниже представлен пример работы token bucket:
Маркеры помещаются в сегмент с определенной частотой.
Каждый маркер является разрешением для источника отправлять определенное количество битов.
Чтобы отправить пакет, регулятор трафика должен быть способен удалить из участка памяти число маркеров, равное размеру пакета.
Если на участке памяти недостаточно маркеров для отправки пакета, пакет либо ждет, пока на участке не накопится достаточно маркеров (в случае формирователя), либо пакет отбрасывается или понижается (в случае ограничителя скорости).
"Ведро" имеет определенную вместимость. После того как буфер заполнится, поступающие в него новые маркеры будут отбрасываться и окажутся недоступны для будущих пакетов. Таким образом, в любой момент, самый большой пакет сигналов, который источник может послать в сеть, приблизительно пропорционален размеру бакета. Буфер маркеров предполагает блочную отправку, при этом ограничивая ее темпы.
Вопрос. Что означает согласованный пакет (BC) и избыточный пакет (Be), и каким образом необходимо выбирать эти значения при работе с ограничителем трафика, например при применении политики ограничения на базе классов?
Ответ. Ограничитель скорости трафика не накапливает избыточные пакеты в буфере с последующей их передачей, как в случае формирователя. Взамен ограничитель выполняет простую отправку или не отправляет политику без буферизации. Во время перегрузок, поскольку невозможно выполнить буферизацию, наилучшим действием является менее агрессивное отбрасывание пакетов за счет правильной настройки расширенного пакета. Таким образом, важно понимать, что ограничитель использует значения обычного и расширенного пакетов для обеспечения настроенной согласованной скорости передачи (CIR).
Параметры пакета нестрого моделируются в общем правиле буферизации для маршрутизаторов. В соответствии с этим правилом рекомендуется делать буферизацию равной скорости передачи битов во время передачи и подтверждения приема для размещения невыполненных окон протокола управления передачей (TCP) всех соединений во время перегрузки.
В нижеприведенной таблице описывается назначение и рекомендуемая формула для значений обычного и расширенного пакетов сигналов:
Параметр блока Цель Рекомендуемая формула обычный пакет сигналов
Применяет стандартный контейнер маркеров.
Устанавливает максимальный размер символьного сегмента памяти (также символы могут быть позаимствованы, если Be больше BC).
Определяет, насколько большим может быть Token Bucket до момента отбрасывания пришедших новых маркеров, которые становятся не доступными для будущих пакетов, если Token Bucket полностью заполнится.
Примечание. 1,5 секунды является типичным времен прохождения сигнала в прямом и обратном направлениях.
расширенный пакет
Внедряет алгоритм Token Bucket с расширенной возможностью пакетирования.
Отключается путем установки BC = Be.
Когда значение BC равно значению Be, регулятор трафика не может заимствовать маркеры и просто отбрасывает пакет, если недоступно достаточное количество маркеров.
Не все платформы используют или поддерживают одинаковый диапазон значений для ограничителя скорости. Сведения о поддерживаемых значениях для определенных платформ см. в следующем документе:
Вопрос. Каким образом согласованная скорость доступа (CAR) или назначение политики на базе классов определяют соответствие или превышение пакета согласованной скорости передачи данных (CIR)? Маршрутизатор отбрасывает пакеты и сообщает о превышенной скорости, несмотря на то, что согласованная скорость ниже настроенной CIR.
Ответ. Ограничитель трафика использует обычное и расширенное значения размера пакета для обеспечения настроенного значения CIR. Установка достаточно больших значений пакетной передачи необходимо для высокой производительности. Если длины пакетов слишком малы, достигнутая скорость может быть намного ниже настроенной скорости. Сильные временные всплески трафика могут оказывать существенное неблагоприятное воздействие на пропускную способность трафика TCP. При работе с CAR введите команду show interface rate-limit, чтобы контролировать текущий пакет импульсов и определить близость отображаемого значения граничному значению (BC) и расширенному граничному значению (Be).
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPSДополнительные сведения см. в следующих документах:
В. Действительно ли серия ограничителя и предельный размер очереди не зависят друг от друга?
О. Да, серия ограничителя и предельный размер очереди не связаны и не зависят друг от друга. Можно считать ограничитель логическим элементом, который разрешает использовать определенное число пакетов (или байтов) и очередь в блоке со значением размера Предельный размер очереди, где разрешенные пакеты хранятся до передачи по сети. В идеале этот блок должен быть достаточно большим, чтобы вмещать серию байтов/пакетов, поддерживаемых логическим элементом (ограничителем).
Качество обслуживания (QoS); технология Frame Relay (ретрансляция кадров)
Вопрос. Какие значения необходимо выбрать для согласованной скорости передачи (CIR), согласованного пакета импульсов(BC), избыточного пакета импульсов (Be) и минимальной согласованной скорости передачи (MinCIR)?
Ответ. Функция формирования трафика технологии Frame Relay, которая включается путем выполнения команды frame-relay traffic-shaping, поддерживает несколько настраиваемых параметров. Эти параметры включают в себя frame-relay cir, frame-relay mincir и frame-relay BC. Обратитесь к следующим документам за дополнительной информацией по выбранным величинам и за общей информацией по связанным командам show:
Вопрос. Поддерживается ли приоритетная очередь (PQ) на главном интерфейсе Frame Relay в Cisco IOS 12.1?
Ответ. Интерфейсы Frame Relay поддерживают как интерфейсные механизмы формирования очередей, так и механизмы формирования очередей на основе виртуального канала (VC). Для Cisco IOS 12.0(4)T очередь интерфейса поддерживает режимы FIFO ("первым пришел, первым обслужен) или PIPQ (очередь по приоритетам интерфейса) только при настройке формирования трафика Frame Relay (FRTS). Следовательно, приведенная конфигурация не будет работать после обновления Cisco IOS до 12.1.
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETFЕсли FRTS не включено, можно применить альтернативный метод формирования очереди, например, весовую справедливую очередь на основе классов (CBWFQ) к главному интерфейсу, который выступает в качестве одиночного канала с полосой пропускания. Кроме того, как и в случае Cisco IOS 12.1.1(T), можно активизировать очередь по приоритетам интерфейса (PIPQ) на основе постоянных виртуальных каналов Frame Relay (PVC) на главном интерфейсе Frame Relay. Можно задать для PVC-соединений высокий, средний, нормальный или низкий уровень приоритета и выполнить на основном интерфейсе команду frame-relay interface-queue priority, как показано в следующем примере:
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
Вопрос. Работает ли формирование трафика Frame Relay (FRTS) с распределенным механизмом переадресации Cisco (dCEF) и взвешенной справедливой организацией очередей на основе классов (dCBWFQ)?
Ответ. Что касается Cisco IOS 12.1(5)T, на VIP в Cisco серии 7500 поддерживаются только функции распределенной версии QoS. Чтобы включить формирование трафика на интерфейсах Frame Relay, используйте формирование распределенного трафика (DTS). Дополнительные сведения см. в следующих документах:
Качество обслуживания (QoS); технология ATM (Over Asynchronous Transfer Mode)
Вопрос. Где на интерфейсе технологии ATM применяется служебная политика взвешенной справедливой организации очередей на основе классов (CBWFQ) и формирования очередей с малым временем ожидания (LLQ)?
Ответ. На Cisco IOS 12.2 интерфейсы технологии ATM поддерживают служебные политики на трех уровнях или логических интерфейсах: основной интерфейс, субинтерфейс и постоянный виртуальный канал (PVC). Область применения политики относится к той функции обеспечения качества обслуживания (QoS), которую вы собираетесь задействовать. Политики формирования очередей должны применяться на VC, так как интерфейс АТМ контролирует уровень перегрузки на VC и сохраняет очереди для избыточных пакетов на VC. Дополнительные сведения см. в следующих документах:
Вопрос. Какие байты учитываются протоколом IP при организации очередей класса обслуживания ATM?
Ответ. Команды bandwidth и priority, настроенные в политике обслуживания с целью активизации взвешенной справедливой организации очередей на основе классов (CBWFQ) и формирования очередей с низкой задержкой (LLQ), соответственно используют значение в Кбит/с для подсчета тех же байтов заголовка, что отображаются в виде выходных данных команды show interface. В частности, система обслуживания очередей уровня 3 использует протокол управления логическим каналом / протокол доступа к подсети (LLC/SNAP). Не учитывается следующее:
Трейлер уровня адаптации 5 (AAL5) ATM
Заполнение последней ячейки до 48 байтов
Пятибайтовый заголовок ячейки
Какие байты учитываются протоколом IP при организации очередей ATM CoS?
Вопрос. Сколько виртуальных каналов (VCS) могут одновременно поддерживать политику обслуживания?
Ответ. В этом документе представлены полезные инструкции относительно количества поддерживаемых VCS технологии ATM. О благополучно развернутой постоянной виртуальной цепи 200 к 300 VBR-nrt (PVCs):
Также учитывайте следующее:
Используйте исправный мощный процессор. Например, VIP4-80 обеспечивает значительно более высокую производительность по сравнению с VIP2-50.
Доступный объем памяти. На NPE-400 для буфера пакетов выделяется до 32 Мбайт (в системе с 256 Мбайтами). Для NPE-200 выделяется до 16 Мб для пакетных буферов в системе с 128 Мб.
Была проведена всесторонняя проверка конфигурации с механизмом взвешенного случайного раннего обнаружения WRED в VC, обслуживающем одновременно до 200 каналов PVC, работающих в режиме ATM. Объем пакетной памяти на VIP2-50, который можно использовать в очередях виртуальных каналов, ограничен. Например, VIP2-50 с 8-MB SRAM предоставляет 1085 буферов пакетов, в которых поддерживается формирование очереди IP-ATM CoS для каждого VC, лежащее в основе работы WRED. Если 100 ATM PVC были настроены и все VCS испытали избыточную перегрузку одновременно (как может быть симулировано в тестовой среде при управлении источником не-TCP потоком), то каждый PVC будет иметь около 10 пакетов для буферизации, что может быть слишком мало для корректного функционирования WRED. Таким образом, в конфигурациях, в которых большое число постоянных виртуальных каналов ATM использует WRED для каждого виртуального канала и которые могут одновременно испытывать перегрузку, настоятельно рекомендуется использовать VIP2-50 с большой SRAM.
Чем больше количество настроенных активных PVC, тем ниже должна быть поддерживаемая скорость ячеек (SCR), следовательно, очередь, необходимая WRED для работы на PVC, должна быть короче. Таким образом, как и при использовании профилей WRED по умолчанию для функции Фазы 1 Класса обслуживания (CoS) IP-ATM, настройка нижних порогов отбрасывания WRED при включении WRED для каждого VC на очень большом числе низкоскоростных переполненных ATM PVC минимизирует риск нехватки буфера на VIP. Недостаток буфера на VIP не должен приводить ни к каким сбоям. В случае недостатка места в буфере VIP функция IP to ATM COs Phase 1 в течение этого периода просто будет отбрасывать остаток по принципу FIFO (т. е. использовать политику отбрасывания, которая применялась бы, если бы функция IP to ATM COs не была активирована для этого PVC).
Максимальное число поддерживаемых синхронных VCS.
Вопрос. Какое оборудование ATM поддерживает функции IP для ATM CO (класс обслуживания), включая CBWFQ (взвешенная справедливая организация очередей на основе классов) и LLQ (организация очередей с низкой задержкой)?
О. Класс обслуживания IP в ATM обращается к ряду параметров, включенных на основе виртуального канала (VC). Данное определение IP для ATM CoS не поддерживается в AIP (ATM Interface Processor), PA-A1 или 4500 ATM процессорах сети. Эта аппаратура ATM не поддерживает поканальные очереди виртуальных каналов, как это определяется в PA-A3 и большинстве сетевых модулей (кроме ATM 25). Дополнительные сведения см. в следующем документе:
Голосовая связь и качество обслуживания (QoS)
Вопрос. Как работает фрагментация и чередование каналов (LFI)?
Ответ. Интерактивные трафики, такие как Telnet и VoIP, имеют тенденцию увеличивать задержку обработки в сети больших пакетов, таких как пакеты протокола передачи файлов (FTP), передаваемые по глобальной сети WAN. Задержка пакета для интерактивного трафика значительна, если FTP пакеты находятся в очереди в более медленных каналах глобальной сети. Метод разработан для фрагментации крупных пакетов и организации очереди из более мелких (голосовых) пакетов между фрагментами более крупных пакетов (FTP). Маршрутизаторы Cisco IOS поддерживают несколько механизмов фрагментации уровня 2. Дополнительные сведения см. в следующих документах:
Вопрос. Какие инструменты используются для контроля производительности голосовой связи через IP?
О. В данный момент Cisco предлагает несколько способов контроля качества обслуживания (QoS) в сетях, использующих решения Cisco по передаче голоса по IP-сетям. Данные решения не измеряют качество голоса с помощью механизма измерения качества воспринимаемой речи (PSQM) или одного из новых алгоритмов для измерения качества голоса. Для решения этой задачи доступны инструменты Agilent (HP) и NetIQ. Тем не менее, Cisco предлагает инструменты, обеспечивающие некоторое представление о качестве голосовых данных при измерении задержки, дрожания и потери пакетов. Дополнительные сведения см. в разделе Использование агента контроля качества обслуживания Cisco и монитора производительности Internetwork для управления качеством обслуживания в сетях VoIP.
В. %SW_MGR-3-CM_ERROR_FEATURE_CLASS: Ошибка компонента Диспетчера подключений: Класс SSS: (QoS) — ошибка установки, игнорировать.
О. Если к шаблону применена неправильная конфигурация, описанная ошибка установки компонента является ожидаемой. Это говорит о том, что политика обслуживания не применена из-за конфликта. Как правило, не рекомендуется настраивать создание класса по умолчанию для дочерней политики в иерархических картах политики. Вместо этого следует настроить его в родительской политике интерфейса. В результате это сообщение выводится на печать вместе с данными обратной трассировки.
При использовании политик на основе сеансов класс по умолчанию необходимо создавать только в дополнительном интерфейсе или на уровне PVC. Настройка в физическом интерфейсе не поддерживается. Если настройка выполняется на физическом интерфейсе, эта ошибка является ожидаемой.
В случае с LNS причиной также может быть подготовка политики обслуживания на сервере Radius после перевода сеансов в рабочее состояние. Выполните команду show tech, чтобы просмотреть конфигурацию сервера Radius и все нелегитимные политики обслуживания, заданные на сервере Radius при переводе сеанса в рабочее состояние или его колыхании.
Обратная связь