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

Настройка простого флага приоритета QoS для трафика VoIP на устройстве Cisco ASA 5505 через ASDM

Я пытаюсь настроить упрощенную политику QoS на нашем устройстве ASA 5505. Я не могу заставить эту вещь работать всю жизнь. По сути, мы хотим убедиться, что весь исходящий трафик VoIP имеет приоритет над всем остальным трафиком. К вашему сведению, наша АТС находится за пределами локальной сети.

Я также пытаюсь сделать это полностью в ASDM. До сих пор мне в основном удавалось избегать CLI. Однако я открыт для предложений в интерфейсе командной строки.

Я зашел в Config -> Firewall -> Service Policy Rules и настроил ту же политику (как для внутреннего, так и для внешнего интерфейса, хотя я считаю, что здесь имеет значение именно внутренний). Политика:

MATCH Источник: внутри сети / 24 Назначение: любая Услуга: voip-group Действие правила: QoS включает приоритет для этого потока.

Я также настроил исходную службу как voip-группу (я хочу, чтобы она знала, что пакеты, использующие службы в voip-группе, отправленные из внутренней сети, должны иметь приоритет).

Это не работает.

Пожалуйста помоги! Я могу предоставить дополнительную информацию, если вы скажете мне, что предоставить.

РЕДАКТИРОВАТЬ 0: Я вошел в Packet Tracer и безрезультатно посмотрел на красивую маленькую анимацию. У него нет шага QOS, что заставляет меня думать, что правило не применяется.

Для начала - просто - не то слово, которое следует использовать для описания качества обслуживания. Само слово целиком является загруженным термином.

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

Ниже ASA 8.4 CLI необходимо для создания очереди с приоритетом и обработки определенного объема вызовов на основе определенного битрейта.

  • Поймите, что применение политик происходит только в исходящем направлении на интерфейсе ASA, на котором оно настроено.
  • На основе голосового кодека G.711 при скорости передачи данных Ethernet уровня 2 87,5 килобит в секунду (включая все накладные расходы)
  • На основе среднего полного размера кадра Ethernet 218 байт на интервал голосовой полезной нагрузки. Для большего посмотри это.
  • На основе необходимости обрабатывать 10 вызовов за раз (87,5 килобит в секунду * 10 = 875 килобит в секунду). Обратите внимание, что это только в направлении наружу. Мы не можем «расставить приоритеты» для входящего трафика, если вы также не контролируете этот путь.
  • На основе максимальной задержки 200 миллисекунд между оконечными точками VoIP.
  • Использование расширенного списка доступа с IP-адресом источника и назначения для сопоставления трафика VoIP. Другой вариант - использовать IP DSCP, если телефоны маркируют. Используя простой ACL, мы можем позже проверить сервисную политику с помощью show service-policy flow.

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

access-list voip-traffic remark [[ match inside to Call Manager ]]
access-list voip-traffic extended permit ip 10.0.0.0 255.255.255.0 host 1.2.3.4

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

! create class-map

class-map voip-class
 match access-list voip-traffic

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

policy-map outside-policy
 class voip-class
  priority

! assign policy to interface, in this case outside

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

Вы можете просмотреть статистику очереди приоритетов с помощью show priority-queue statistics outside.

Вы можете убедиться, что сам трафик попадет в очередь с приоритетом, с помощью команды типа show service-policy flow host 10.0.0.100 host 1.2.3.4 который покажет вам, как существующие политики обслуживания на всех интерфейсах будут реагировать на указанный трафик.