QoS и маршрутизаторы Cisco

Опубликовано – 11.02.2010

Автор: Сгибнев Михаил

Небольшая шпаргалка для быстрой настройки QoS, сделана для личного пользования. Возможно будет дополняться.

Случай первый:
Имеется разветвленная филиальная сеть. В качестве опорной, используется сеть одного из магистральных провайдеров. По заключенному договору, он предоставляет канал со следующими условиями: 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. Соответственно окраски трафика, по предполагаемой нами схеме, не произойдет.

Команда qos-preclassify дает нам возможность «запомнить» назначенный параметр QoS и привязать его к инкапсулированному в GRE пакету:

Теперь, после описания классов трафика, необходимо назначить потребляемую полосу пропускания и 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.

Если вы захотите наложить service-policy на туннельный интерфейс типа gre multipoint, то можете получить ошибку типа GTS : Not supported on this interface. В этом случае можно посоветовать перейти на инкапсуляцию ipip или по прежнему использовать qos pre-classify:


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 mgcp
match protocol sip
match protocol h323
match protocol eigrp
match protocol telnet
match protocol ssh
match precedence 5
!
!
policy-map QoS
class Real-Time
bandwidth percent 50
class Business-Critical
bandwidth percent 30
class Best-Effort
bandwidth percent 20
class class-default
fair-queue
policy-map Tunnel
class class-default
shape average 2000000
service-policy QoS
!
interface Tunnel0
bandwidth 2048
qos pre-classify
tunnel source FastEthernet0
tunnel mode gre multipoint
!
interface FastEthernet0
bandwidth 2048
service-policy output Tunnel
!

Ссылки по теме:
Quality of Service Design Overview — книжка, которую стоит найти на просторах Интернета
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
QoS в Cisco
Per-Tunnel QoS for DMVPN




 Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!

7 комментариев в QoS и маршрутизаторы Cisco

  1. code_310:

    Уважаемый автор поправьте плиз линки в статье №2 о PF (OPENBSD).
    Заранее спасибо.

  2. CAE:

    Михаил!
    Обращаю внимание, что при использовании туннелей на Cisco сильно загружается процессор (process switching). В результате максимальная скорость, достижимая на туннелях, от 4 до 10 раз ниже, чем при умолчательном CEF switching. Что нужно чётко понимать, когда выбирается решение с туннелями.

    Кроме того, на провайдерской сети (особенно например, на Ростелекомовской и построенных поверх их первичной сети (часть Синтерры, РТКомм, Эквант)) часто используются мультилинки на промежуточных хопах. При этом для обеспечения качества используется не per-packet, а per-flow стратегия распределения пакетов между отдельными линками большого бандла (в случае per-packet jitter растёт).
    В результате ваш туннель пойдёт в один из линков бандла, и, как следствие этого, даже при небольшом всплеске трафика возможно нарушение качества (отброс пакетов). Я наблюдал как при примерно 60-70 процентной загрузке клиентского порта (клиент весь трафик направлял в туннель) промежуточный линк грузился на 100%, так как помимо трафика указанного клиента в линк шёл трафик и других клиентов. Бороться с этим на магистрали крайне сложно, даже MPLS TE не всегда спасает, сильно зависит от сети.

    Кроме того, не будем забывать о прикладном ПО, которое, как это не покажется странным, часто критично к использованию уменьшенного MTU (эффект туннелей).

    В общем, при построении наложенных сетей на MPLS-облако, если есть возможность, туннелей следует избегать. В остальном статья на «пять».

  3. GolDi:

    To CAE.
    Вопрос, а если заказывать у прова L2VPN,то что будет происходить разбиение канала по всем линкам большого бандла?

  4. Mixa:

    To CAE: Да, по поводу туннелей и всплесков Вы совершенно правы — именно на это я наткнулся, пытаясь прогнать видеоконференцию по сети РТКОММ. Проблему уменьшения MTU я решаю снятием df-bit (или установкой его в 0 — это как смотреть) — set ip df 0 через route-map и ip mtu, ip tcp adjust-mss.

  5. Vlad:

    Уважаемый автор,
    вы могли бы подробнее рассказать как указать параметр «class llq-class», в моей циске 2811 с иосом C2800NM-ADVIPSERVICESK9-M), Version 12.4(21) у меня неполучается найти его!

  6. Mixa:

    Vlad, воспользуйтесь услугами Cisco Feature Navigator для поиска подходящего IOS. Если Вы не можете найти в IOS какую-либо функцию, то скорее всего, ее там просто нет.

  7. crash:

    Насколько помню, то указание priority как раз и есть указание использовать LLQ для данного класса.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*