Ключевые слова:cisco, qos, (найти похожие документы)
From: Сгибнев Михаил
Date: Mon, 25 Sep 2010 17:02:14 +0000 (UTC)
Subject: QoS и маршрутизаторы Cisco
Оригинал: http://dreamcatcher.ru/2010/02/11/
Случай первый:
Имеется разветвленная филиальная сеть. В качестве опорной, используется
сеть одного из магистральных провайдеров. По заключенному договору, он
предоставляет канал со следующими условиями: 25% трафика Real-Time, 40%
Business-Critical и 35% Best-Effort. IP Precedence должен быть
установлен в 5, 1 и 0 соответственно.
Если мы не стесняемся использовать NBAR, то конфигурация class-map
выглядит следующим образом (это пример, у вас набор протоколов может
быть другим):
class-map match-any Business-Critical
match protocol citrix
match protocol sqlnet
class-map match-any Best-Effort
match protocol notes
match protocol ftp
match protocol http
class-map match-any Real-Time
match protocol rtp audio
match protocol rtp video
match protocol sip
match protocol ssh
Если, по какой либо причине, данный вариант неприемлем, то используем
access-list:
class-map match-any Business-Critical
...
class-map match-any Best-Effort
access-group name notes
...
class-map match-any Real-Time
access-group name ...
!
...
ip access-list extended notes
permit tcp any any eq 1352
...
Трафик наш идет в GRE-туннелях. Для того, чтобы провайдер увидел
назначенный на пакет IP Precedence, мы должны назначить на внешний
интерфейс соответствующее service-policy и воспользоваться функцией
qos-preclassify на туннельном интерфейсе и вот почему:
Правила QoS будут применяться к пакетам, исходящим с физического
интерфейса только после того, как они будут упакованы в GRE.
Соответственно окраски трафика, по предполагаемой нами схеме, не
произойдет.
default_classification
Команда qos-preclassify дает нам возможность "запомнить" назначенный
параметр QoS и привязать его к инкапсулированному в GRE пакету:
pre-classification
Теперь, после описания классов трафика, необходимо назначить
потребляемую полосу пропускания и IP Precedence:
policy-map QoS
class Real-Time
priority percent 25
set ip precedence 5
class Business-Critical
set ip precedence 1
bandwidth percent 40
class Best-Effort
set ip precedence 0
bandwidth percent 25
class class-default
fair-queue
Обращаю ваше внимание на то, что IOS позволяет policy map выделять
пропускную способность не больше, чем произведение значений bandwidth и
параметра max-reserved-bandwidth (по умолчанию 75 процентов). В моем
случае, я хочу задействовать 90% полосы пропускания.
В случае, если доступная очереди полоса пропускания задается параметром
priority percent, то данной очереди, при необходимости, выделяется
требуемый объем полосы при полной загруженности канала, но не более,
чем указано. Этот параметр с одной стороны гарантирует указанную
пропускную способность очереди, с другой -- сдерживает поток пакетов
очереди. В случае, когда канал свободен, такая очередь может занимать
большую полосу пропускания. Задействовать LLQ для такой очереди можно
указав параметр class llq-class.
Параметр bandwidth задает минимальную полосу (CBWFQ), превышение
данного значения допустимо в случае наличия свободной полосы.
Таким образом, полная конфигурация будет выглядеть следующим образом:
class-map match-any Business-Critical
match protocol citrix
match protocol sqlnet
class-map match-any Best-Effort
match protocol notes
match protocol ftp
match protocol http
class-map match-any Real-Time
match protocol rtp audio
match protocol rtp video
match protocol sip
match protocol ssh
!
policy-map QoS
class Real-Time
priority percent 25
set ip precedence 5
class Business-Critical
set ip precedence 1
bandwidth percent 40
class Best-Effort
set ip precedence 0
bandwidth percent 25
class class-default
fair-queue
!
interface Tunnel0
ip address 192.168.0.1 255.255.255.252
tunnel source 10.0.0.1
tunnel destination 10.0.0.2
qos pre-classify
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.252
max-reserved-bandwidth 90
service-policy output QoS
Проверку работы service-policy можно сделать командой:
show policy-map interface FastEthernet 0/0
Упростить конфигурирование QoS можно используя команду auto discovery qos
interface FastEthernet0/0
auto discovery qos
Просмотреть результаты можно командой
show auto discovery qos
Случай второй:
Если мы решили приоритезировать трафик непосредственно в туннельном
интерфейсе, то ситуация изменяется несильно. Просто добавляется
дополнительный policy-map, убирается лишний service-policy с основного
интерфейса и qos pre-classify с туннельного интерфейса:
policy-map Tunnel
class class-default
shape average 1024
service-policy QoS
!
int Tunnel0
service-policy output Tunnel
Пример, приведенный выше, прекрасно подходит для соединения между собой
двух маршрутизаторов или для маршрутизатора, установленного в филиале.
В случае, когда в Головном офисе используются DMVPN туннели, проблема
решается использованием групп nhrp.
Ссылки по теме:
Quality of Service Design Overview - книжка, которую стоит найти на просторах ИнтернетаCisco IOS Quality of Service Solutions Configuration Guide, Release 12.4TQoS в CiscoPer-Tunnel QoS for DMVPN
заинтересовал случай с dmvpn.
имеем 10 филиалов с разными скоростями от 512кбит/с до 10мбит/с.
Головной имеет скорость 100 мбит/с.
Какой шейп в данном случае можно применить дабы сохранить пропускную способность сети.
