Предварительная классификация в QoS на маршрутизаторах Cisco

При использовании туннелирования, маршрутизатор Cisco IOS выполняет классификацию на основе внешнего заголовка (post header) вместо внутреннего (pre header), что может вызвать проблемы с политиками QoS, применяемыми к физическим интерфейсам. Внешние заголовки всех пакетов, проходящих через один туннель, одинаковы, поэтому они обрабатываются идентично, даже если физический интерфейс перегружен. Это может приводить к неправильному управлению трафиком и ухудшению качества обслуживания.

Функция предварительной классификации (QoS Pre-classify) позволяет маршрутизатору учитывать исходные заголовки пакетов перед инкапсуляцией в туннель. Это обеспечивает более точную классификацию и применение политик QoS.

Содержание:

1. Введение
2. Топология
   1. Настройки маршрутизатора R1
   2. Настройки коммутатора S1
   3. Настройки маршрутизатора R3
3. Развертывание туннеля между R1 и R3
4. Стандартная классификация
5. Классификация внешнего заголовка
6. Классификация внутреннего заголовка (физический интерфейс)
7. Классификация внутреннего заголовка (туннельный интерфейс)
8. Выводы

Введение

Если пакеты инкапсулируются заголовками туннелей или шифрования, средствам QoS сложно проверить исходные заголовки пакетов и правильно их классифицировать. Пакеты, перемещающиеся по одному туннелю, имеют идентичные заголовки туннеля, поэтому они обрабатываются одинаковым образом, что может привести к проблемам, если физический интерфейс перегружен. Введение функции QoS для виртуальных частных сетей (VPN) позволяет классифицировать пакеты перед выполнением туннелирования и шифрования.

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

• Применение политики к туннельному интерфейсу без использования QoS Pre-classify: если необходимо классифицировать пакеты на основе заголовка перед туннелем, следует применять политику к туннельному интерфейсу.
• Применение политики к физическому интерфейсу без использования QoS Pre-classify: если требуется классифицировать пакеты на основе заголовка после туннеля, политику нужно применять к физическому интерфейсу. Также, если цель состоит в формировании всего трафика туннеля или назначении для него политики, политику следует применять к физическому интерфейсу, так как физический интерфейс поддерживает несколько туннелей.
• Использование QoS Pre-classify: при необходимости классифицировать пакеты на основе заголовка перед туннелем политику применяют к физическому интерфейсу и включают функцию QoS Pre-classify.

QoS Pre-classify позволяет учитывать исходные заголовки пакетов перед их инкапсуляцией, что обеспечивает более точную классификацию и управление трафиком.

Топология

Исследуемая топология состоит из трех маршрутизаторов (Cisco 1941 с образом Cisco IOS Release 15.4 IP Base). Допускается использование маршрутизаторов других моделей, а также других версий операционной системы Cisco IOS. В зависимости от модели устройства и версии Cisco IOS, доступные команды и результаты их выполнения могут отличаться от тех, которые показаны в этой статье.

Схема топологии следующая:

Настройки маршрутизатора R1

hostname R1
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface Loopback0
ip address 1.1.1.1 255.255.255.255
no shutdown
exit

interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
exit

Настройки коммутатора S1

hostname S1
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface range GigabitEthernet0/0-1
no shutdown
exit

Настройки маршрутизатора R3

hostname R3
no ip domain-lookup
line con 0
logging synchronous
exec-timeout 0 0
exit

interface Loopback0
ip address 3.3.3.3 255.255.255.255
no shutdown
exit

interface GigabitEthernet0/0
ip address 192.168.10.3 255.255.255.0
no shutdown
exit

line vty 0 4
transport input all
password cisco
login
exit

Развертывание туннеля между R1 и R3

Ниже приведена настройка туннеля. Будем использовать статический маршрут, чтобы R1 и R3 имели соединение друг с другом через loopback интерфейс:

Маршрутизатор R1:

interface Tunnel 0
ip address 172.16.13.1 255.255.255.0
tunnel source 192.168.10.1
tunnel destination 192.168.10.3
exit
ip route 3.3.3.3 255.255.255.255 172.16.13.3

Маршрутизатор R3:

interface Tunnel 0
ip address 172.16.13.3 255.255.255.0
tunnel source 192.168.10.3
tunnel destination 192.168.10.1
exit
ip route 1.1.1.1 255.255.255.255 172.16.13.1

Также делаем настройки зеркалирования на коммутаторе S1:

monitor session 1 source interface Gi0/0 - 1
monitor session 1 destination interface Gi0/2

Стандартная классификация

IOS по умолчанию скопирует информацию в байте TOS (тип обслуживания) из внутреннего заголовка IP во внешний заголовок IP. Это можно проверить на R1 с помощью утилиты ping. В строке «Target IP address» укажем 3.3.3.3, в строке «Extended commands» — yes, в строке «Source address or interface» — 1.1.1.1, «Type of service» — 160. На всех остальных параметрах нажимаем пробел:

ping
Protocol [ip]:
Target IP address: 3.3.3.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: 1.1.1.1
DSCP Value [0]:
Type of service [0]: 160
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/9 ms

Этот эхо-запрос между 1.1.1.1 и 3.3.3.3 пройдет через туннель. Байт TOS 160 в двоичном виде — это 10100000, если удалить последние два бита, останется 6 бит DSCP. 101000 в двоичном формате — это 40 в десятичном, что совпадает с CS5.

Ниже на изображении показан перехват трафика, проходящий через туннель, после выполнения эхо-запроса:

Обратите внимание на вывод информации, Cisco IOS автоматически копирует байт TOS из внутреннего заголовка IP во внешний заголовок IP. В примере используется GRE, чтобы можно было увидеть оба заголовка, но если используется зашифрованный туннель IPsec, будет виден только внешний заголовок.

Если есть политики QoS, работающие на основании байта TOS, проблем не возникнет, так как байт TOS копируется из внутреннего заголовка во внешний заголовок. Проблемы могут возникнуть, если есть политики, основанные на списках доступа (ACL), которые совпадают по адресам источника/назначения и/или номерам портов.

Классификация внешнего заголовка

На R1 создадим две карты классов (class—map), одну для трафика telnet и другую для трафика GRE. Обе карты классов будут использовать список доступа для классификации трафика:

ip access-list extended TELNET
permit tcp any any eq telnet
exit

class-map TELNET
match access-group name TELNET
exit

ip access-list extended GRE
permit gre any any
exit

class-map GRE
match access-group name GRE
exit

Две карты классов будут использоваться в карте политик (policy—map):

policy-map POLICE
class TELNET
police 128000
exit
exit
class GRE
exit
exit

Политика была добавлена для трафика Telnet, в то время как для GRE ничего не было настроено. Независимо от настроенных «действий», трафик будет классифицироваться и отображаться на карте политик даже при отсутствии действий. Давайте активируем всю эту конфигурацию на физическом интерфейсе R1:

interface GigabitEthernet 0/0
service-policy output POLICE
exit

Следует иметь в виду, что при включении политики на физическом интерфейсе она будет применяться ко всем туннельным интерфейсам. Давайте сгенерируем некоторый трафик telnet между R1 и R3, чтобы он проходил через туннель:

telnet 3.3.3.3 /source-interface loopback 0
Trying 3.3.3.3 ... Open

Теперь посмотрим на карту политик R1:

show policy-map interface GigabitEthernet 0/0

GigabitEthernet0/0

Service-policy output: POLICE

Class-map: TELNET (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name TELNET
police:
cir 128000 bps, bc 4000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps

Class-map: GRE (match-all)
36 packets, 2863 bytes
5 minute offered rate 0000 bps
Match: access-group name GRE

Class-map: class-default (match-any)
36 packets, 4259 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

Это касается трафика GRE. Для трафика Telnet совпадений нет. В реальной сети это означало бы, что трафик Telnet никогда не будет проверяться (или любое другое настроенное действие не будет применено). Причина отсутствия совпадений в том, что Cisco IOS сначала инкапсулирует IP-пакет, а затем применяет политику к трафику GRE:

Синий IP-заголовок — это оригинальный IP-пакет с трафиком Telnet , он инкапсулирован, и маршрутизатор добавляет GRE-заголовок и новый IP-заголовок (красный). Затем карта политик применяется к этому внешнему IP-заголовку.

Есть несколько вариантов как исправить данную ситуацию.

Классификация внутреннего заголовка (физический интерфейс)

Первый вариант решения — активировать предварительную классификацию на туннельном интерфейсе. Этот вид классификации указывает маршрутизатору создать копию исходного IP-заголовка и использовать его для политики. Сделаем это на R1, используя команду qos pre-classify:

interface Tunnel 0
qos pre-classify
exit

Давайте выполним ещё один тест, чтобы увидеть разницу:

clear counters
Clear "show interface" counters on all interfaces [confirm]

telnet 3.3.3.3 /source-interface loopback 0
Trying 3.3.3.3 ... Open

Теперь посмотрим на карту политик R1:

show policy-map interface GigabitEthernet 0/0

GigabitEthernet0/0

Service-policy output: POLICE

Class-map: TELNET (match-all)
29 packets, 2303 bytes
5 minute offered rate 1000 bps, drop rate 0000 bps
Match: access-group name TELNET
police:
cir 128000 bps, bc 4000 bytes
conformed 29 packets, 2303 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 1000 bps, exceeded 0000 bps

Class-map: GRE (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps
Match: access-group name GRE

Class-map: class-default (match-any)
4 packets, 587 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

Теперь видны совпадения в трафике Telnet, что позволяет его проверять при необходимости. Однако больше не наблюдаются совпадения в трафике GRE. Что же произошло:

Когда маршрутизатор инкапсулирует пакет, он создает временную копию заголовка. Эта временная копия используется для применения политики вместо внешнего заголовка и затем уничтожается.

Это достигается благодаря команде qos pre-classify, но существует и другой способ получить тот же результат.

Классификация внутреннего заголовка (туннельный интерфейс)

Вместо активации политики на физическом интерфейсе, можем активировать её на туннельном интерфейсе R1:

interface GigabitEthernet 0/0
no service-policy output POLICE
exit
interface Tunnel 0
no qos pre-classify
service-policy output POLICE
exit

Обратите внимание, что была удалена команда qos pre-classify на интерфейсе туннеля. Проводим тест:

clear counters
Clear "show interface" counters on all interfaces [confirm]

telnet 3.3.3.3 /source-interface loopback 0
Trying 3.3.3.3 ... Open

Теперь посмотрим на карту политик R1:

show policy-map interface Tunnel 0

Tunnel0

Service-policy output: POLICE

Class-map: TELNET (match-all)
28 packets, 1833 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name TELNET
police:
cir 128000 bps, bc 17916 bytes
conformed 28 packets, 1833 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps

Class-map: GRE (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps
Match: access-group name GRE

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

Если политика включена на туннельном интерфейсе, маршрутизатор будет использовать внутренний заголовок для классификации. Это точно соответствует результату, который достигается при использовании команды qos pre-classify на туннельном интерфейсе.

Выводы

Спасибо за уделенное время на прочтение статьи. Теперь Вы знаете как настроить предварительную классификацию в QoS на маршрутизаторах Cisco.

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco, курсы по кибербезопасности, полный курс по кибербезопасности, курсы DevNet (программируемые сети) от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University (Университет СЭДИКОММ).