Вопрос опытным специалистам по Cisco (QoS)
1. Исходящий шейпинг плюс LLQ — легко. В принципе, классификацию трафика можно делать через NBAR, ресурсов должно хватить (если там ничего кроме канала на 4,5мб/с канала нет).
С приоритезацией входящего трафика сложнее. Если в какие-то моменты времени возникнет перегрузка канала (а она будет, ибо TCP всегда работает всплесками, даже если в среднем за 5 секунд канал нагружен лишь наполовину), то дропать пакеты будет железка провайдера, а она не делает различий между голосом и HTTP. У меня (дома) более-менее хорошо работает схема «полисить все кроме голоса до 3/4 от скорости канала». Увы, любая реализация красивых очередей в направлении «in» будет вызывать дропы голосового трафика, и даже предложенная схема не идеальна, кратковременные всплески будут. Ну и канал задействуется неоптимально.
3. Вряд ли.
4. С точки зрения указанной задачи — никакого.
1. Работает прекрасно уже давно. Красим траффик, потом делаем с ним все что хотим
2. Если есть Cisco, зачем искать что-то еще. ИМХО
3. Если работает QoS — особого смысла в ограничении нет. Назве что ограничить максимальную утилизацию около 80-90%, чтобы у провайдера порт не начал дропать большое количество пакетов.
4. Лично я в данном случае особого смысла в ASA не вижу.

class-map match-all VIDEO_IN
 match access-group name VIDEO_IN
class-map match-all LOCAL_SERVICES_IN
 match access-group name LOCAL_SERVICES_IN
!
!
 class VIDEO_IN
  set ip precedence 4
 class LOCAL_SERVICES_IN
  set ip precedence 2
!
!

ip access-list extended VIDEO_IN
 permit ip host 10.100.1.3 10.100.0.0 0.0.255.255
 permit ip host 10.100.1.4 10.100.0.0 0.0.255.255
 permit ip host 10.100.1.5 10.100.0.0 0.0.255.255
 permit ip host 10.100.1.6 10.100.0.0 0.0.255.255
ip access-list extended LOCAL_SERVICES_IN
 permit ip host 10.54.1.2 10.0.0.0 0.255.255.255


Ну вот как-тио так я делю приоритетность траффика по направлению и сервисам.
На уровне ядра мне этого достаточно. Можно поупражняться с другими параметрами.