Про виртуальные сети (часть 16).Как привязать QoS к виртуальной сети

В предыдущих статьях здесь и здесь я рассматривал работу различных сервисов через виртуальные сети. Было рассмотрена работа PBR  и IP SLA в этих сетях. Еще одним интересным аспектом работы, отличающим виртуальные сети от реальных является то, что нескольким виртуальным сетям приходится сосуществовать в одной реальной сети одновременно. С одной стороны мы экономим на оборудовании, с другой — всем приходится ютиться под одной крышей. И вот тут встает вопрос: кому сколько места положено, или, если выражаться уже технически, как распределить ресурсы каналов между имеющимися виртуальными сетями. Конечно, перефразируя известное стихотворение, все протоколы нужны, все данные важны. Но что-то нужно срочно, а что-то подождет. Обсуждение, что более важно или срочно, выходит за рамки данной статьи, а вот на том, как распределить пропускную способность сети, остановимся поподробнее.

Одним из важных элементов маршрутизатора, который преодолевает пакет в процессе обработки, является буфер интерфейса. Есть входной буфер, в который помещаются пакеты, пришедшие из интерфейса. С точки зрения управления трафиком, он не очень интересен: пакеты, находящиеся в нем, уже использовали свою долю пропускной способности канала. А вот с точки зрения классификации и маркирования трафика, входной буфер самое подходящее место.

Есть выходной буфер, в котором находятся пакеты, предназначенные для отправки. Управление этим буфером на основе классификации и маркирования, произведенного во входном буфере, как раз и позволяет распределить ресурсы канала между различными  видами трафика. А совокупность операций во входном и выходном буфере называется  Quality of Service (QoS).

Вообще говоря, современные сети предприятий построены на высокоскоростных каналах и высокопроизводительных коммутаторах и маршрутизаторах и в правильно рассчитанной сети все пакеты успевают куда надо вовремя и ничуть не стеснены тем, что приходится «жить под одной крышей». Все это справедливо, пока речь идет о передаче данных в пределах одного здания, или, если речь идет о достаточно крупной и успешной организации, в пределах населенного пункта. А что происходит, если строить на большие расстояния собственную сеть экономически нецелесообразно? Или нужно получить доступ в интернет? Используются арендованные каналы, пропускная способность которых на порядки меньше пропускной способности каналов кампуса. Вот эти-то каналы и становятся бутылочными горлышками в сети предприятия. И оказывается, что при звонке в удаленный офис речь собеседника невозможно разобрать из-за постоянных прерываний, а шеф не может прочитать финансовые новости, потому что некоторые сотрудники качают себе фильмы. Вот в такой ситуации нам и поможет QoS.

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

За основу возьмем топологию рассматриваемую в предыдущих статьях, но для наглядности  подключим серверную подсеть через медленный канал Т1.

Physic_Topology

Физическая топология сети

QoS_Logik

Логическая топология сети

Итак, поехали. Для начала настроим вновь появившиеся интерфейсы и маршрутизатор.

Server_Side#conf t
Server_Side(config)#int lo3
Server_Side(config-if)#ip addr 10.0.3.1 255.255.255.255
Server_Side(config-if)#int s 2/0
Server_Side(config-if)#ip vrf receive FTP_Srv_Sd
Server_Side(config-if)#ip vrf receive SSH_Srv_Sd
Server_Side(config-if)#ip unnumbered Loopback3
Server_Side(config-if)#ip policy route-map Srv_Sd_Map

 

Как видим, настройки интерфейса serial2/0 почти ничем не отличаются от настройки интерфейса Fa 0/0 в предыдущих статьях. Отличие заключается только в том, что раньше мы задавали ip-адрес для интерфейса явно, здесь же мы заимствуем ip-адрес у настроенного loopback интерфейса. Я специально воспользовался таким способом назначения адреса последовательному интерфейсу, так как с таким назначением связан довольно интересный момент в настройке маршрутизации. На нем я остановлюсь чуть позже. Теперь маршрутизатор Remote_Server.

 

remote_server#conf t
remote_server (config)#interface FastEthernet0/0
remote_server (config-if)#ip address 192.168.18.254 255.255.255.0
remote_server (config-if)#interface Serial1/0
remote_server (config-if)#ip unnumbered FastEthernet0/0
remote_server (config-if)#ip route 0.0.0.0 0.0.0.0 Serial1/0

 

Полагаю, что здесь комментарии излишни. Напомню только (возможно для начинающих сетевых администраторов это будет интересно) процесс маршрутизации, кроме все прочего, должен определить в какой интерфейс должен быть направлен пакет. Поэтому вместо (или вместе) next-hop при указании маршрута, мы можем указывать имя интерфейса, в который должен быть отправлен пакет. Для Ethernet интерфейсов такой маршрут без next-hop может привести (и в большинстве случаев приведет) к неоднозначности и сбоям. А для последовательных интерфейсов, где на другом конце однозначно только один хост, такие маршруты самое то: он сразу указывает, куда слать пакет.

Проверим таблицу маршрутизации:

 

remote_server#sh ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C    192.168.18.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, Serial1/0

 

Все просто, очевидно и ожидаемо.

Возвращаемся на маршрутизатор Server_Side и донастраиваем маршрутизацию. Здесь все несколько сложнее.

 

Server_Side#sh ip route
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 1 subnets
C       10.0.3.1 is directly connected, Loopback3
S    192.168.18.0/24 is directly connected, Serial2/0

 

В данном выводе тоже никаких неожиданностей, смотрим дальше:

 

Server_Side#sh ip route vrf FTP_Srv_Sd
Gateway of last resort is not set
D EX 192.168.55.0/24 [170/33280] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D       10.2.0.0/24 [90/2565120] via 10.4.0.1, 00:24:55, FastEthernet1/0.40
C       10.3.0.0/24 is directly connected, FastEthernet1/0.30
D       10.1.0.0/24 [90/30720] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
D EX    10.0.1.0/25 [170/158720] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
C       10.4.0.0/24 is directly connected, FastEthernet1/0.40

 

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

 

Server_Side#conf t
Server_Side(config)# ip route vrf FTP_Srv_Sd 192.168.18.0 255.255.255.0 Serial2/0
Server_Side(config)# ip route vrf SSH_Srv_Sd 192.168.18.0 255.255.255.0 Serial2/0

 

И снова проверяем таблицу:

 

Server_Side#sh ip route vrf FTP_Srv_Sd
Gateway of last resort is not set
D EX 192.168.55.0/24 [170/33280] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D       10.2.0.0/24 [90/2565120] via 10.4.0.1, 00:24:55, FastEthernet1/0.40
C       10.3.0.0/24 is directly connected, FastEthernet1/0.30
D       10.1.0.0/24 [90/30720] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
D EX    10.0.1.0/25 [170/158720] via 10.3.0.1, 00:24:55, FastEthernet1/0.30
C       10.4.0.0/24 is directly connected, FastEthernet1/0.40
S    192.168.18.0/24 is directly connected, Serial2/0

Ура, товарищи! Все на месте.

Вот такой есть нюанс.

Для уверенности проверяем с Client PC, как все работает и убеждаемся, что все в порядке.

FTP_Check

Итак, сеть настроена, можно приступать к настройке непосредственно самого QoS.

 

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

Вообще говоря, оба этих этапа можно сконфигурировать непосредственно на маршрутизаторе перед «бутылочным горлышком». Так проще для администратора. Однако, в случае большого трафика, когда производится подробный его анализ по многим критериям, это может привести к неоправданно большому росту нагрузки на маршрутизатор, и как следствие, к отказам в обслуживании.

Поэтому существует возможность производить анализ и маркировку трафика на  интерфейсах маршрутизаторов, через которые трафик попадает в сеть. А на маршрутизаторе с исходящим интерфейсом применять политики уже на основе этих меток, обработать которые значительно проще и быстрее.

Метки могут быть установлены в двух местах:

— в заголовке IP пакете в поле ToS старшие 6 бит. Т.е. получаем 63 класса, например:

 

Client_Side(config-pmap-c)#set ip dscp 2

 

- в заголовке Ethernet кадра для 802.1q или ISL тагированного трафика.  Там для этого используются три младших бита в таге, т.е. всего 8 значений. (Всего 4096 VLAN, это 10^12, остается еще 4 бита, 3 из которых используется). Например:

 

Client_Side(config-pmap-c)#set cos 2

 

 

В данной статье я буду использовать dscp метки, поскольку у меня не все каналы тагированы. Да и там, где тагированы, таг после каждого маршрутизатора меняется, а cos метки этого не переживут.

 

Итак, поехали. Начинаем с маршрутизатора Client_Side. На нем мы будем маркировать трафик, входящий с клиентской машины. Прежде всего нам нужно решить, согласно каким критериям мы будем его маркировать. И тут мы вспоминаем, что сеть настроена таким образом, чтобы различать типы трафика и направлять его на разные виртуальные сети. Смотрим, как это настроено.

 

Client_Side#sh ip access-lists
Extended IP access list FTP_Cl_Sd_List
10 permit tcp 192.168.55.0 0.0.0.255 192.168.18.0 0.0.0.255 eq ftp (2 matches)
20 permit tcp 192.168.55.0 0.0.0.255 192.168.18.0 0.0.0.255 eq ftp-data
Extended IP access list SSH_Cl_Sd_List
10 permit tcp 192.168.55.0 0.0.0.255 192.168.18.0 0.0.0.255 eq 22 (48 matches)
Client_Side#
Client_Side#sh route-map
route-map Cl_Sd_Map, permit, sequence 10
Match clauses:
ip address (access-lists): FTP_Cl_Sd_List
Set clauses:
vrf FTP_Cl_Sd
Policy routing matches: 0 packets, 0 bytes
route-map Cl_Sd_Map, permit, sequence 11
Match clauses:
ip address (access-lists): SSH_Cl_Sd_List
Set clauses:
vrf SSH_Cl_Sd
Policy routing matches: 0 packets, 0 bytes

 

У нас определено два списка доступа, которые описывают два разных типа трафика: ftp-трафик и ssh-трафик. Собственно это очень подходящие критерии и для применения QoS. Файлы передавать нужно, но это ни в коем случае не должно мешать управлению (ну, будем считать, что если мы и передаем файлы по SSH, то они небольшие, но очень важные и срочные, а большие и несрочные передаем по FTP). Так и напишем:

 

Client_Side#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Client_Side(config)#class-map match-all FTP
Client_Side(config-cmap)#match access-group name FTP_Cl_Sd_List
Client_Side(config-cmap)#class-map match-all SSH
Client_Side(config-cmap)#match access-group name SSH_Cl_Sd_List

 

Здесь мы определили два класса FTP и SSH и задали критерии, согласно которым, этот трафик будет отнесен к одному из них. Как я уже упоминал, те же самые критерии мы применяем при маршрутизации через route-map, поэтому автоматически получаем, что dscp метка на каждом пакете будет выставлена в точном соответствии с виртуальной сетью, в которую впоследствии попадет пакет. Т.е. фактически, при такой настройке, мы можем определять класс QoS для каждой виртуальной сети.

Далее настраиваем политику, в соответствии с которой будут устанавливаться метки:

 

Client_Side(config)#policy-map from_client
Client_Side(config-pmap)# class FTP
Client_Side(config-pmap-c)#set ip dscp 1
Client_Side(config-pmap-c)#class SSH
Client_Side(config-pmap-c)#set ip dscp 2

 

И применяем ее к интерфейсу:

 

Client_Side(config-pmap-c)#int fa 0/0
Client_Side(config-if)#service-policy input from_client

 

Теперь весь трафик, подходящий по спискам доступа FTP_Cl_Sd_List и SSH_Cl_Sd_List, будет маркироваться соответствующим значением dscp, а остальной трафик просто никуда не уйдет, так как он не описывается route-map.

 

Переходим к маршрутизатору Server_Side. На нем мы будем разбирать промаркированный трафик. Порядок конфигурации тот же. Определяем классы:

 

Server_Side#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Server_Side(config)#class-map match-all cls1
Server_Side(config-cmap)# match ip dscp 1
Server_Side(config-cmap)#class-map match-all cls2
Server_Side(config-cmap)# match ip dscp 2

 

Здесь я сознательно не называл классы так же как и на маршрутизаторе Client_Side. Дело в том, что маршрутизатор Server_Side не анализирует тип трафика. Его интересует только класс. А администратор сети может определить, например, что к одному классу будут относиться и FTP, и HTTP.

 

Ну и настраиваем политику, что же с этим трафиком делать.

Есть три варианта, три команды, который позволяют избежать перегрузок  и распланировать трафик:
— bandwidth;
— priority;
— shape average.

 

В двух словах, что это все значит.
Bandwidth – гарантирует трафику назначенную полосу пропускания, но не ограничивает в ней. Т.е. если есть резерв, он будет использован.
Priority – гарантирует полосу пропускания, но не будет использовать резерв, даже если он есть. Причем приоритет такой трафик будет иметь только по отношение к неклассифицированному трафику. Пакеты, не вписывающиеся в гарантированную полосу пропускания, отбрасываются. Используется для трафика критичного к задержкам.
Shape average – гарантирует полосу пропускания, не будет использовать резерв, пакеты, не вписывающиеся в полосу, старается сохранить в буфере, пока не появится возможность их передать. Используется для трафика критичного к потерям.

 

Вспоминаем, что мы определили SSH трафик как не очень интенсивный, но критичный к потерям (управление), а FTP должен просто иметь приоритет. В соответствии с такими критериями будет подходящей следующая конфигурация:

 

Server_Side#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Server_Side(config)#policy-map to_server
Server_Side(config-pmap)# class cls1
Server_Side(config-pmap-c)# bandwidth percent 75
Server_Side(config-pmap-c)# class cls2
Server_Side(config-pmap-c)# shape average 64000
Server_Side(config-pmap-c)#int ser2/0
Server_Side(config-if)#service-police output to_server

 

Т.е. для управляющего SSH трафика мы определяем гарантированную полосу 64Кбит/с и просим маршрутизатор не дропать пакеты по возможности. Для FTP мы определяем, что он в любом случае имеет право на 75 процентов пропускной способности канала, но можно и больше, если есть. Пропускная способность в данном случае имеется та, которая указана в параметре bandwidth на интерфейсе. Т.е. если указать 10 Кбит/с, то будет 75% от 10 Кбит/с, несмотря на то, что реально канал работает на своей номинальной скорости.

 

Ну и для симметрии настроим QoS на маршрутизаторе remote_server. Здесь ситуация упрощается тем, что есть только один маршрутизатор и можно обойтись без предварительного маркирования трафика:

 

remote_server#conf t
remote_server(config)#ip access-list extended ftp_list
remote_server(config-ext-nacl) #permit tcp 0.0.0.0 255.255.255.0 eq ftp-data any
remote_server(config-ext-nacl) #permit tcp 0.0.0.0 255.255.255.0 eq ftp any
remote_server(config-ext-nacl) #ip access-list extended ssh_list
remote_server(config-ext-nacl) #permit tcp 0.0.0.0 255.255.255.0 eq 22 any

 

remote_server(config)#class-map match-all cls1
remote_server(config-cmap)#match access-group name ftp_list
remote_server(config-cmap)#class-map match-all cls2
remote_server(config-cmap)#match access-group name ssh_list
remote_server(config-cmap)#policy-map from_server
remote_server(config-pmap)#class cls1
remote_server(config-pmap-c)#bandwidth percent 75
remote_server(config-pmap-c)#class cls2
remote_server(config-pmap-c)# shape average 64000
remote_server(config-pmap-c)#interface FastEthernet0/0
remote_server(config-if)#service-policy output from_server

 

Теперь можно и проверить, как все работает. Честно признаюсь, цифры полученные при передаче информации не совсем равнялись заданным в конфиге, но  были близко. Скорее всего дело было в том, что виртуальная среда не совсем соответствует реальной.

 

Итак, вот как было дело с вышеописанными настройками при одновременном копировании по SSH, FTP и пинг (размер пакета 15000, т.н. jambo-пакет) из сети 192.168.55.0/24 в сеть 192.168.18.0/24:

 

WinSCP копирование:

WinSCP

Как видим, скорость около 64000 бит/с и она не меняется независимо от загрузки канала и прочих настроек (если не трогать только настройки своего класса).

FTP копирование, когда канал полностью свободен:

FTP_only

Скорость только 104 Кбайт/с, хотя должна быть ближе к 200. Причем такая же скорость  и без всяких политик в свободном канале, так что будем считать это за 100 %

FTP копирование одновременно с SSH копирование (скорость смотрим выше) и пингом.

FTP + SSH + Ping

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

А вот что будет, если отменить команду bandwidth для FTP.

FTP + SSH + Ping - bandwidth

Как видим, скорость упала еще. Не очень сильно (один поток пинга, даже с такими большими пакетами не создает такую уж большую нагрузку), но все-таки позволяет продемонстрировать, что QoS вполне может быть полезным.

Аверьянов Кирилл
network-lab.ru


Комментарии:

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

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

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me