Назад | Перейти на главную страницу

QoS на Cisco ASA 5505 по VLAN / подсети

В моем ASA 5505 три сети VLAN. Один, подключенный к Интернету, называется outside, один для нашего офиса называется office (который подключается к корпоративной VPN) и один для общедоступного resource-centre. Каждая VLAN находится в отдельной подсети.

Я хочу убедиться, что трафик из office к vpn или Интернету имеет приоритет над трафиком из resource-centre. Другими словами, я не хочу resource-centre трафик, чтобы подавить office трафик.

Я могу создать ACL для своих двух внутри vlans:

access-list resource-centre-traffic extended permit ip 192.168.0.0 255.255.255.0 any
access-list resource-centre-traffic extended permit ip any 192.168.0.0 255.255.255.0
access-list office-traffic extended permit ip 172.16.0.0 255.255.255.0 any
access-list office-traffic extended permit ip any 172.16.0.0 255.255.255.0 

Я думаю, что мне нужно настроить приоритизацию трафика, соответствующего офисному трафику - это будет означать, что трафик в / из офиса никогда не будет прерван трафиком в / из центра ресурсов, верно?

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

Хотя я большой поклонник платформы ASA, я буду первым, кто признает, что парадигмы и возможности QoS на ASA довольно ограничены. Стандартные IOS ISR работают вокруг возможностей ASA в отношении QoS.

Если вы еще не прочитали Руководство по настройке QoS ASA и Руководство по решениям QoS для iOS пожалуйста, прочтите их. Их необходимо прочитать, чтобы понять, что Cisco (и многие другие поставщики) подразумевают под действительно загруженным термином «качество обслуживания». Обратите внимание, что руководство IOS содержит много функций, которые ASA не поддерживает, и дает примеры, которые не будут работать на ASA. Однако оба содержат множество полезных концепций, терминов и деталей, касающихся различных парадигм и концепций QoS.

С IOS ваш случай будет довольно простым - настройте соответствующий bandwidth на outside интерфейс, используйте Modular QoS CLI для создания класса и shape трафик, соответствующий resource-centre-traffic ACL, fair-queue остальные.

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

Поскольку формирование не очень полезно в вашем случае, вы остаетесь с политикой и очередью приоритетов, иногда называемой организацией очереди с низкой задержкой (LLQ).

У вас есть следующие возможности

  • Полицейский трафик соответствует resource-centre-traffic ACL
  • Приоритетный трафик очереди, соответствующий office-traffic ACL
  • Делайте и то, и другое одновременно, то есть трафик полиции и очереди с приоритетом, соответствующий соответствующим ACL.

Когда дело доходит до QoS, по-прежнему применяется принцип KISS. Чем проще, тем лучше. По этой причине я бы посоветовал начать с минимальной настройки и тонкой настройки. Сначала начните с охраны.

Полицейская

Следующий пример применения политик будет ограничивать скорость (полицию) трафика, соответствующего ACL ресурсного центра, до 1 Мбит / с. Знайте, что применение политик будет отбрасывать пакеты, превышающие лимит, что в конечном итоге приводит к повторной передаче стеков сети хоста и откладыванию расчетов вокруг контролируемой скорости. Формирование позволяет избежать этого, вводя задержку, а не отбрасывая, но формирователь ASA не может формировать на основе классов.

! create class-map

class-map resource-centre-traffic-class
 match access-list resource-centre-traffic

! create policy-map, advise not using a global policy

policy-map outside-policy
 class resource-centre-traffic-class
  police input 1000000   ! rate in bits per second, 1 Mb/s listed
  police output 1000000  ! rate in bits per second, 1 Mb/s listed

! assign policy to interface, in this case outside

service-policy outside-policy interface outside

Приоритетная организация очереди / LLQ

Очередь с приоритетом применима только в направлении передачи / вывода интерфейса. Важно настроить пределы очереди и ограничение звонка TX на интерфейсе, из которого будет выходить трафик в очереди с приоритетом. Я собираюсь принять скорость передачи 3 Мбит / с и создать очередь с приоритетом примерно 2 Мбит / с на основе размера пакета 256 байт. Когда дело доходит до LLQ, размер, который следует использовать для очереди с приоритетами, - это большая магия. Обратите внимание, что любой указанный трафик, который не может поместиться в приоритетную очередь, отбрасывается, то есть отбрасывается - вероятно, это не то, что вы хотите для вашего офисного трафика.

Именно в связи с этим организация очередей с приоритетом / LLQ обычно не используется в классах трафика с высокой пропускной способностью, а вместо этого используется для низкой задержки. Тем не менее, я включаю здесь пример очередности с приоритетом, чтобы показать, что может делать ASA. - Я бы не рекомендовал использовать приоритетные очереди для любых потоков / классов трафика с высокой пропускной способностью.

  • Обычно рекомендуется сохранять LLQ как можно меньше. - без отбрасывания хвоста, так как большой LLQ может истощить обычную очередь интерфейса, если будет слишком большим.
  • Пакеты, которые квалифицироваться для LLQ, но не подходят (если он заполнен) отброшены от LLQ. Это является общим с политикой - однако с LLQ-трафик всегда «сокращается до начала линии», поскольку LLQ (программная очередь, такая же, как обычная очередь интерфейса) всегда обслуживается драйвером и помещается в физический интерфейс. сначала аппаратная очередь (аппаратный кольцевой буфер).

Числа, используемые для queue-limit и tx-ring-limit определяется с помощью таблицы в руководстве по настройке, а затем массируется.

priority-queue outside
 queue-limit 500   ! based on factors listed earlier, very important number
 tx-ring-limit 20  ! based on factors listed earlier

! create class-map

class-map office-traffic-class
 match access-list office-traffic

! create policy-map, advise not using a global policy

policy-map outside-policy
 class office-traffic-class
  priority

! assign policy to interface, in this case outside

service-policy outside-policy interface outside
  • Обе карты классов могут быть перечислены во внешней политике одновременно для контроля и постановки в очередь по приоритетам.
  • Вы по-прежнему можете реализовать глобальную политику и установить ее как глобальную - пока нет действий QoS ни в одном из классов, перечисленных в global-policy, - затем другие действия global-policy (инспекции и т. Д.) останется в силе на внешнем интерфейсе, когда внешняя политика (только с действиями QoS) будет размещена на внешнем интерфейсе.

TL; DR

ASA действительно ограничена в отношении QoS. Попробуйте полицейские. Если это не сработает, добавьте или очень осторожно попробуйте LLQ. Если это не сработает, поищите IOS ISR [G2] с шейпингом, CBWFQ и т. Д.