Вопрос опытным специалистам по Cisco (QoS)

Question

[at88]

Хотим:
1. Чтобы не лажал VoIP, Skype, Google Apps for business.
2. Проходил и по честному делился на всех весь остальной трафик (в прямом смысле весь, никаких ограничений).

Имеем:
1. Cisco 7204VXR (NPE400), 15ый IOS, Catalyst 3750
2. 4.5 Mbps ADSL канал в интернет. (чем и как нас шейпят пусть будет неизвестно).
3. 10-15 адекватных пользователей (т.е. не будут специально искать способы как бы нагнуть весь канал)

Не особо важно:
1. Простота настройки и у управления (один раз настроил и забыл на год).
2. Стоимость дополнительного оборудования которое может понадобится.

То что это можно сделать в теории я в курсе, но вот вопросы:

1. Работало ли у кого это на практике?
2. Стоит ли посмотреть на решение других производителей (например Mikrotik)
3. Есть ли смысл ограничивать каждого пользователя по скорости в отдельности?
4. Есть ли хоть малейший смысл использовать Cisco ASA?

Comments

[at88]

Подписывайтесь на канал, ставьте лайки.

Answer 1

[JDima]

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

Answer 2

[Владимир Пилипчук]

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

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

Comments

[Владимир Пилипчук]

да, кстати забыл упомянуть, что если явно не указать класс трафика («не покрасить» какой-то), то в 15-м IOS он имеет высший приоритет. Поэтому нужно красить ВЕСЬ трафик, в отделный класс запикхать все. и поставить минимальный приоритет, хоть 0.0.0.0, а уже потом разруливать «интересный» трафик по приоритетам.

[JDima]

С каких пор best effort стал приоритетным? И к каким очередям это относится? WFQ? Надо в любом случае вешать сервис-полиси и определять в полиси-мапе CBWFQ/LLQ, иначе приоритезация становится неуправляемой.

[Владимир Пилипчук]

Простите, про полиси-мап как-то забыл

policy-map NSK_ENTC_IN
 class DEFAULT_NAT_IN
  set ip precedence 1
 class VIDEO_IN
  set ip precedence 4
 class LOCAL_SERVICES_IN
  set ip precedence 2

[JDima]

Это лишь маркировка (вообще необязательный пункт, если точка выхода одна, и матчить можно по «match protocol skype» и «match protocol rtp», если ресурсов хватает для NBAR).
Вы самое главное забыли — очереди :)

Answer 3

[at88]

class-map match-all ICMP
 match protocol icmp

class-map match-all HTTP
 match protocol http

class-map match-all HTTPS
 match protocol secure-http

class-map match-all PERMIT_ANY
 match access-group name PERMIT_ANY

class-map match-any VOICE
 match protocol skype
 match protocol rtp
 match protocol sip
 match protocol rtcp

policy-map QOS
 class PERMIT_ANY
    shape average 3435000
    queue-limit 512 packets
  service-policy CBQOS_OUT
 class class-default
    bandwidth remaining percent 25

policy-map CBQOS_OUT
 class VOICE
    priority percent 25
 class HTTPS
    bandwidth percent 30
 class ICMP
    priority percent 5
 class HTTP
    bandwidth percent 30
 class class-default
    fair-queue 512
   police rate 3000000

interface FastEthernet0/0
 service-policy output QOS

interface FastEthernet0/1
 service-policy output QOS

Если честно не понимаю до конца смысл «fair-queue» и «queue-limit 512 packets» — это я так, игрался. Вобщем результат неудовлетворительный.

Лагает как VoIP со скайпом так и ping. Рисую графики «Manage engine Netflow CBQOS analyzer» — ом. Толку на деле мало от всего этого QoS для realtime трафика.

Есть ли смысл играться с длинами очередей итп.?

Comments

[JDima]

Внимание, вопрос. Вы выставили priority percent. Если я правильно понимаю, за fa0/0 либо fa0/1 стоит модем. А правильно ли выставлен bandwidth на интерфейсе? Percent берется от того, что показано в show int fa0/X. Если оно не соответствует реальному, то будет печально. Либо править bandwidth, либо выставлять абсолютные значения в классах.

И:
policy-map QOS
class PERMIT_ANY
shape average 3435000
queue-limit 512 packets
service-policy CBQOS_OUT
class class-default
bandwidth remaining percent 25

Зачем так?

policy-map QOS
class class-default
shape average 4500000
service-policy CBQOS_OUT

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

Ну и не надо трогать queue-limit.

[JDima]

Ну и fair-queue тоже не трогайте. Играйтесь только параметрами bandwidth, priority, shape и т.д., не надо напрямую с очередями играться.

[at88]

>>> А правильно ли выставлен bandwidth на интерфейсе?

interface FastEthernet0/0
 description ALA-SW01_FA1/0/12
 bandwidth 4580
 ip address 10.X.X.XX 255.255.255.252
 ip nbar protocol-discovery
 ip flow monitor myflow_monitor input
 ip flow monitor myflow_monitor output
 ip nat inside
 no ip virtual-reassembly
 duplex auto
 speed auto
 !
 service-policy output QOS
end


interface FastEthernet0/1
 description ISP
 bandwidth 4580
 ip address 82.XXX.XXX.XXX 255.255.255.248
 ip access-group ISP_IN in
 ip nbar protocol-discovery
 ip nat outside
 no ip virtual-reassembly
 duplex auto
 speed auto
 !
 service-policy output QOS
end

Вот полный листинг, было лень закрашивать крестиками адреса.

>>> Зачем так?
Ок, этот момент я наверное передалаю, но проблемы с исходом можно сказать просто нет, QoS там нужен в редких случаях.

>>> Ну и fair-queue тоже не трогайте.
Даже если я копну глубже в логику работы QoS, оно мне все равно не поможет?

[JDima]

Повесьте это на fa0/1 в направлении in:
policy-map FROM-INTERNET
class ICMP
class class-default
police 4000000

(соответственно, класс ICMP надо заранее определить, в него пока только пинги; и да, в нем пусто, но он обязательно должен быть, причем выше, чем рубящий класс)
, потом пустите непрерывный пинг и жгите канал по полной торрентами, HTTP и так далее. Если есть дропы — снижать планку полисера до тех пор, пока не будет теряться от силы один пакет на несколько сотен (пингать лучше с самой циски, ибо пакеты чаще улетают).

Даже если я копну глубже в логику работы QoS, оно мне все равно не поможет?

Нет. Работайте только указанными командами.