antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 24 Сентябрь , 2010

Классификация пакетов представляет собой средство, позволяющее отнести пакет к тому или иному классу
трафика в зависимости от определённого критерия классификации. Фактически, каждое устройство
реализующее механизмы качества обслуживания должно обладать возможностью классификации трафика.
Мы же должны, к примеру, сначала понять какие из приходящих пакетов являются голосовыми, чтобы
обеспечить их приоритетное обслуживание, или применить ограничение по скорости для трафика
«мусорных» приложений. Классификация является основой любой системы качества обслуживания, и от
того, насколько гибко и эффективно реализованы средства классификации, зависит дальнейшая обработка
пакетов в устройстве. Более того, каждое устройство в сети должно уметь классифицировать трафик – в противном случае на этом устройстве будут отсутствовать возможности
обеспечения какого-либо качества обслуживания.

Каковы же критерии классификации? На основании каких полей и/или критериев мы можем отнести трафик
к тому или иному классу?

    IP адреса источника и получателя
    Порт источника и порт назначения
    Длина пакета
    MAC адреса источника и получателя
    Распознавание протокола на уровне приложений
    Входящий интерфейс
    Маркировка пакета

Маркировка пакетов и схемы маркировок – это отдельная тема, но если не вдаваться в детали, то
маркировка позволяет упростить задачу классификации трафика на вышележащих устройствах. Т.е. на
устройстве расположенном ближе к границе сети мы можем любыми (относительно сложными) методами
отклассифицировать пакет, и «раскрасить», записав в какое-то из его служебных полей (для IP заголовка –
это байт TOS, для MPLS меток – биты EXP, для Ethernet – биты приоритета в 802.1q тэгах) некоторое
значение, идентифицирующее класс трафика и позволяющее на последующих устройствах выполнить
классификацию трафика по этому значению.

Классификация без маркировки

Классификация без маркировки

 

Маркировка позволяет эффективно решить задачу классификации на последующих устройствах!

 

С технической точки зрения классификация на основе параметров потока: IP адресам источника и
получателя, порту источника и порт назначения может быть легко реализована с помощью списков
контроля доступа.
Но возникает вопрос: можно ли таким образом обеспечить классификацию пакетов
динамических приложений, например, FTP? Ответ: нет! Поэтому производители, как правило,
реализовывают средства распознавания протоколов на уровне приложений, позволяющие обеспечить
более глубокое инспектирование пакетов. Подобные средства можно разделить на следующие:

1) Отслеживание контрольных сессий по хорошо известным портам с целью определения
динамических портов сессий данных.

2) Анализ байтов пакета на уровне выше транспортного и определение протокола на основе
характерных для протокола полей на уровне приложений.

Для решения задачи отслеживания динамических сессий Cisco использует технологию NBAR (Network Based Application Recognition)

Классификация пакетов на основе длины пакета может служить лишь дополнительным критерием
классификации, например для отделения маленьких пакетов от больших.

Маршрутизаторы Cisco классифицируют пакеты как на входящем интерфейсе, так и на исходящем.
Коммутаторы Cisco выполняют классификацию исключительно на входящем интерфейсе! И тут нужно
заметить, что настройка QoS на коммутаторах и QoS на маршрутизаторах у Cisco – это 2 разные темы. В
частности NBAR, насколько я знаю, на коммутаторах поддерживает только на Cat 6K.

Приведу примеры настройки различных классов:
Общий синтаксис:

Router(config)# class-map [match-all|match-any] {CLASS_NAME}
Router(config-cmap)#match ?
access-group        Access group
any                 Any packets
class-map           Class map
cos                 IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
discard-class       Discard behavior identifier
dscp                Match DSCP in IP(v4) and IPv6 packets
flow                Flow based QoS parameters
fr-de               Match on Frame-relay DE bit
fr-dlci             Match on fr-dlci
input-interface     Select an input interface to match
ip                  IP specific values
mpls                Multi Protocol Label Switching specific values
not                 Negate this match result
packet              Layer 3 Packet length
precedence          Match Precedence in IP(v4) and IPv6 packets
protocol            Protocol
qos-group           Qos-group
source-address      Source address
vlan                VLANs to match

Match-all – является условием по умолчанию и при использовании нескольких команд match в классе
попадание пакета в класс осуществляется только при выполнении всех условий match.
Match-any – попадание пакета в класс осуществляется при совпадении по любой строке.

1) Классификация с использованием ACL

Router(config)#ip access-list extended ICMP
Router(config-ext-nacl)# permit icmp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Таким образом, в класс попадёт трафик, попадающий под разрешающие строчки ACL.

Router(config)#class-map ICMP_CLASS
Router(config-cmap)#match access-group name ICMP
Router#show class-map
Class Map match-all ICMP_CLASS (id 1)
Match access-group name ICMP

2) Классификация с использованием NBAR

Router(config)#class-map match-any NBAR
Router(config-cmap)#match protocol ftp
Router(config-cmap)#match protocol smtp

В класс NBAR попадёт трафик протоколов FTP и SMTP.
Замечание: не забывайте писать match-any в подобных случаях – иначе в класс ничего попадать не будет.

3) Вложенные классы. Как написать класс, в который должен попасть трафик идущий из сети
192.168.1.0/24 в сеть 192.168.2.0/24 по протоколам FTP или SMTP? Для этого воспользуемся классом
NBAR, созданным в примере 2, и получим следующую конфигурацию:

Router(config)#ip access-list extended NETWORKS
Router(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255


Router(config) class-map match-all MAIN
Router(config-cmap)#match access-group name NETWORKS
Router(config-cmap)#match class-map NBAR

Классификация трафика – обширная тема, я лишь пока сделал введение в этот вопрос. Напоследок замечу, что созданные классы сами по себе ничего не делают, на них нужно ссылаться при настройке политики QoS (policy-map). Но об этом поговорим в следующих статьях…

С уважением,
Сергей Сиверцев

 

Метки:
Опубликовано: Маршрутизаторы и коммутаторы

 

4 комментария “QoS. Статья2. Классификация трафика.”

comment rss - Trackback

  1. Серж, я чуток отформатировал. Ты не против?

  2. siv:

    Конечно не против. Спасибо, Серёга.

  3. Hando:

    «В частности NBAR, насколько я знаю, на коммутаторах поддерживает только на Cat 6K.»
    Only @ Sup32-PISA

  4. Anticisco…

    […] something about anticisco[…]…

» Оставить комментарий

Вы должны войти чтобы прокомментировать.