как лучше реализовать qos на cisco

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/15-s/...

Тебе надо создать class-map классифицирующие твой трафик, policy-map определяющие чего с каким классом делать и прикрутить на интерфейс используя service-policy.

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

«Ограничить без дропа пакетов» — это как?

сделал вот так

class-map match-any INET-PORTS01
 match access-group name PORTS01

policy-map CHANNEL01-POLICE
 class INET-PORTS01
  police cir 15000000 bc 2812500 be 5625000
   conform-action transmit
   exceed-action drop
 class class-default
  police cir 10000000 bc 1500000 be 3000000
   conform-action transmit
   exceed-action drop

ip access-list extended PORTS01
 permit tcp any any eq 22
 permit tcp any eq 22 any


interface GigabitEthernet0/1
 description wan
 service-policy input CHANNEL01-POLICE

прогружаю канал торрентами, видосиками, скачкой файлов и ssh работает идеально. отрада глаз моих.

но есть пара вопросов.

1) по данной схеме я могу использовать 25 мбит канала или 15 ? ну максимум при всем желании.

2) как прикрутить третью policy для http и https трафика? должно быть так - 5 мбит для ssh, 5 мбит для http\https, 5 мбит на все остальное.

3) еще вопрос по «police cir 10000000 bc 1500000 be 3000000», как расчитываются эти значения? я взял из мануала и пропорционально у меньшил для своих значений.

«ограничить без дропа пакетов»

я читал что у цыски есть 2 варианта шейпинга - первый это простой дроп лишнего. tcp это нормально переварит и перевышлет дропнутое, а что будет с udp я хз.

и еще есть вариант с шейпингом, когда пакеты не дропаются а ставятся в очередь.

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

Использовать сможешь 25.

Третью полиси — создай class-map, добавь в policy-map.

Shaping vs Policing: https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policin...

Про bc/be: https://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c...

Шейпинг совсем без дропов может «работать», если доступен буфер для всего того, что придётся хранить в очереди.

Как будут переварены дропы зависит не только от протокола. У TCP встроенный механизм адаптации к условиям. Вот тут описание tail drop vs (W)RED: https://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c...

В UDP механизм congestion avoidance не предусмотрен. Обработка дропов зависит от протокола более высокого уровня. Для аудио/видео потеря небольшого числа пакетов влияет на качество, но повторная отправка недошедших данных не имеет смысла. При некотором уровне потерь клиент весьма вероятно сам примет решение прекратить приём данных и тем самым предположительно остановит их передачу и освободит полосу.

Посмотри там ещё вокруг про congestion management/avoidance, про CAR, LLQ.
Хотелки немного странные на мой взгляд (куда столько SSH?), так что возможно будет лучше сделать всё вообще иначе.

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

но хотелосьбы сделать так чтобы у других сотрудников веб сайты не тормозили когда некоторые качают торенты и смотрят видосы