Архив рубрики: Cisco

Приоритезация трафика voip и skype на cisco asa 5510 или как мы переходили на Cisco ASA — часть 3

При большом количестве людей и отсутствии нормального, полноценного PBR (policy-based routing) на cisco asa, каким-то образом необходимо уменьшить потенциальные «тормоза» в передаче звука и видео по скайпу с компьютеров в переговорных комнатах, а также звука с ip-телефонов. Обладатели cisco-роутеров удивятся «сложности» постановки задачи. В роутерах практически любой трафик можно выделять по протоколу (match protocol skype и др.). Но не тут-то было. ASA «знает» только самые распространенные протоколы типа http, ftp и др. Также, она умеет выделять трафик по регулярным выражениям, но описать регулярными выражениями трафик скайпа довольно сложно.

Решение, в общем-то, нашлось довольно быстро. С наших IP-телефонов никакой трафик кроме голосового идти не может, поэтому приоритет будет отдаваться всему трафику с их айпишников. Для упрощения дальнейшего администрирования, самый простой способ — добавить все эти адреса в object-group.

object-group network IPPHONES
network-object host 192.168.1.25
network-object host 192.168.1.26

Далее создаем access-list:

 access-list IPPHONES extended permit ip object-group IPPHONES any

Этот access-list мы используем в class-map:

class-map IPPHONES
match access-list IPPHONES

А class-map, в свою очередь, в policy-map:

policy-map LOCAL
 class IPPHONES
  priority

Таким образом, при дополнении этого policy-map политиками ограничения скорости для других типов трафика, мы отдадим приоритет исходящему трафику с телефонов.

С трафиком скайпа в переговорных комнатах можно поступить таким же образом (выдать приоритет всему трафику), но в нашем случае нашелся более изящный вариант. В переговорных комнатах установлены компьютеры под управлением ОС Windows и они входят в домен. При помощи групповых политик можно назначать значения DSCP трафику, генерируемому конкретными приложениями. Для этого надо создать новую политику QoS (Computer Configuration -> Windows Settings -> Policy-based QoS) в новом объекте (или в одном из существующих) групповой политики и назначить эту групповую политику на необходимый нам OU. В политике QoS необходимо выставить отличное от нуля (например, 1) значение DSCP для трафика TCP и UDP, генерируемого приложением skype.exe. После этого мы можем создать class-map для выделения этого трафика из потока:

class-map SKYPE
 match dscp 1

И добавить этот класс в наш policy-map:

policy-map LOCAL
 class SKYPE
  priority

И не забываем применять policy-map к интерфейсу:

 service-policy LOCAL interface LOCAL

В итоге мы получаем минимальные задержки для интересующего нас трафика довольно простыми методами.

Ограничение скорости интернета для пользователей на Cisco ASA 5510 или как мы переходили на Cisco ASA — часть 2

Итак, с PBR на Cisco ASA кое-как разобрались. Пришло время взяться за ограничение скорости для пользователей. На дебиане оно было реализовано просто и эффективно: при помощи iptables + htb у всех были выставлены минимальная (гарантированная) и максимальная скорость. Все были довольны, всем всего хватало. По необходимости, скорость конкретным пользователям весьма просто увеличивалась или уменьшалась.

Но тут пришла угрюмая и неповоротливая циска. В первую очередь хотелось бы немного рассказать о том, какие способы ограничения скорости есть в Cisco ASA.

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

Второй способ — traffic policing. Основное его отличие от шейпинга состоит в отсутствии буфера, т.е. «лишние» пакеты просто отбрасываются. Еще одним отличием от шейпинга является то, что он может применяться как к входящим пакетам, так и к исходящим. Несмотря на отсутствие буфера, приоритезация трафика возможна и в этом случае. Осуществляется она благодаря использованию очереди LLQ (Low-latency queuing). Отличие от шейпинга в данном случае состоит в том, что задержки для любого типа трафика будут ниже, но при этом возможность потери пакетов гораздо выше.

С точки зрения качества обслуживания, было бы неплохо использовать шейпинг трафика. Но тут кроется основная проблема: ASA умеет шейпить трафик только для class-default, т.е. весь трафик, да и то только исходящий. По сути, эта «фишка» реализована тут только для приближения скорости передаваемых данных к ширине канала — передать максимум, пусть и с задержками, потерять минимум.

Таким образом, ограничить входящую скорость всем и каждому мы можем только при помощи полисинга. При этом, если мы желаем ограничить скорость именно для каждого айпишника, нам придется создать по одному acl (access-list) на каждый адрес. Далее, для каждого acl необходимо создать class-map. Вот тут-то и кроется загвоздка. Общее количество class-map’ов в ASA ограничено числом 255. Если общее количество работников/серверов превышает это значение, то вы не сможете ограничить всех и каждого. Так или иначе придется разбивать всех по определенным группам и выставлять скорость уже для группы. При этом, естественно, любители скачивать торренты будут «отбирать» у группы больше скорости, чем было в случае iptables + htb — соответственно качество обслуживания остальных будет ниже.

Рассмотрим конкретный пример ограничения входящей скорости до 10 Мбит/с.

Создать access-list для интересующих нас адресов (сеть 192.168.1.0/24):

access-list LIMITED extended permit tcp any 192.168.1.0 255.255.255.0

Создать соответствующий class-map:

class-map LIMITED
match access-list LIMITED

Создать policy-map:

policy-map LIMITED
class LIMITED
police output 10000000

И применить его к интерфейсу локальной сети:

service-policy LIMITED interface LOCAL

Несколько пояснений по вышеуказанной конфигурации:

  • направление трафика output соответствует трафику, исходящему с интерфейса внутрь сети, т.е. в нашем случае это будет входящий трафик из интернета;
  • скорость для полисинга указывается в битах в секунду;
  • policy-map применяется для локального интерфейса, т.к. на внешнем интерфейсе у нас будут видны только адреса, которые прошли через NAT;

Такой вариант ограничения скорости может быть хорошим в том случае, если список адресов, у которых скорость ограничена всегда укладывается в одну подсеть или редко меняется. На практике такое встречается не часто и поэтому гораздо удобнее пользоваться группами объектов. В группы можно добавлять адреса по одному или целыми подсетями. При этом, два одинаковых адреса добавить не получится (чего не скажешь о двух одинаковых правилах access-list). Создадим группу и добавим в нее несколько хостов:

object-group network LIMITED
network-object host 192.168.1.5
network-object host 192.168.1.7
network-object host 192.168.1.8

Создадим access-list для этой группы:

access-list LIMITED extended permit tcp any object-group LIMITED

Если же нам необходимо исключить из полисинга какой-то трафик (к примеру, трафик DMZ-сети), то мы должны добавить соответствующий access-list с действием deny до этого правила. Выглядеть это будет примерно так (допустим, DMZ-сеть имеет адреса 192.168.15.0/24):

access-list LIMITED extended deny tcp 192.168.15.0 255.255.255.0 object group LIMITED
access-list LIMITED extended permit tcp any object-group LIMITED

После этого применим такие же class-map и policy-map, которые были рассмотрены выше и сохраним конфигурацию краткой командой wr. При необходимости, можно посмотреть статистику полисинга:

show service-policy police

Эта команда выведет данные по ограничению скорости для каждого class-map, перечисленного в policy-map.

На этом простая настройка ограничения скорости завершена.

Policy-based routing на Cisco ASA 5510, или как мы переходили на Cisco ASA — часть 1.

Жила-была одна небольшая аутсорсинговая компания. И был у нее шлюз на debian. И было хорошо. На одном из собраний с руководством для повышения стабильности и доступности интернета и серверов компании снаружи, было решено перейти на cisco. Причем не просто на cisco, а сразу на 2 cisco ASA 5510 в режиме Active/Passive. Сказано — сделано: две циски были куплены. Осталось дело за малым — изучить, настроить и внедрить. Так уж получилось, что задача эта была возложена на меня.

Для начала, была составлена примерная схема того, что мы должны получить на выходе:

1. Разделение трафика по каналам;

2. Ограничение скорости интернета каждому пользователю;

3. Приоритезация трафика ip-телефонов, а также трафика skype из переговорных комнат;

4. DMZ-подсеть;

5. Немаленькая кучка NAT-ов (если быть точнее, то PAT-ов) внутрь сети;

6. Failover cluster;

7. Site-to-site IPSEC VPN с одним из заказчиков;

Было решено не тратить драгоценное время на полное изучение всех возможностей Cisco ASA, а сразу приступать к выполнению конкретных подзадач, изучая все по ходу действий — знания, полученные на практике, всегда лучше усваиваются и запоминаются дольше.

В дальнейшем тексте предполагается, что у нас есть интерфейсы LOCAL (локальная сеть), ISP1 (интернет-провайдер 1), ISP2 (интернет-провайдер 2) и DMZ.

У тех, кто хорошо знаком с официальными возможностями Cisco ASA, первый пункт списка вызовет некоторое недоумение: в Cisco ASA в один момент времени может быть активен только один маршрут в одном направлении. То есть маршрутов по умолчанию вида

route ISP1 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx Y

может быть несколько (например, по одному для каждого канала), но работать будет только маршрут с наименьшей метрикой Y. При недоступности основного канала, asa автоматически начнет использовать следующий маршрут.

Однако, несмотря на все ограничения, есть способ частично разделить трафик. Конечно, это будет не полноценный PBR, но на безрыбье и рак рыба. «Фишка» в том, что asa имеет свой алгоритм выбора канала для любого пакета. В мануале он описан так:

Egress Interface Selection Process 

 1. If destination IP translating XLATE already exists, the egress interface for the packet is determined from the XLATE table, but not from the routing table. 

 2. If destination IP translating XLATE does not exist, but a matching static translation exists, then the egress interface is determined from the static route and an XLATE is created, and the routing table is not used. 

 3. If destination IP translating XLATE does not exist and no matching static translation exists, the packet is not destination IP translated. The ASA processes this packet by looking up the route to select egress interface, then source IP translation is performed (if necessary).

То есть, если этот пакет первый в данном направлении (нет созданного XLATE), то в первую очередь будут проверяться правила static nat/pat. И если при создании этого правила в качестве inside-интерфейса указать интерфейс ISP2, а outside — интерфейс LOCAL, то трафик, соответствующий этим правилам будет отправлен через интерфейс, указанный в правиле. Например:

static (ISP2,LOCAL) tcp 0.0.0.0 80 0.0.0.0 80 netmask 0.0.0.0

Это правило отправит весь http-трафик через интерфейс ISP2 даже если активен маршрут через интерфейс ISP1. Таким образом, можно получить корявенький, костыльный, но хоть как-то работающий PBR на cisco ASA.

При этом, хотелось бы отметить несколько неприятных нюансов:

1. Правила такого вида будут применяться вне зависимости от адреса назначения пакета. То есть при наличии сети DMZ, пакеты на 80 порт, адресованные в эту сеть, без дополнительных правил (о которых я расскажу в части про DMZ), будут уходить через интерфейс ISP2, т.е. фактически теряться.

2. При таком выборе канала для http-трафика, становится невозможным использование wccp — asa выбирает канал для отправки пакета до того, как узнает, что его надо переадресовать на прокси. При этом, она попытается отправить его на прокси (т.к. видит его активный статус), но через внешний канал. Таким образом, http-трафик просто потеряется.