QoS и реальная пропускная способность канала

[fox_m]

Всем привет.

 

Есть L2 канал между двумя площадками. Тип подключения 10Gb. По факту, провайдер ограничивает канал до 5Гб. Настраиваю исходящий policy-map, в которой мне нужно выделить гарантированную полосу под мультикаст и голос. Нужно ли в этом случае канал предварительно зашейпить до реальной пропускной способности? т.е. сделать как-то так:

 

policy-map OUT-WAN
 class class-default
  service-policy OUT-POLICY
  shape average percent 50 
 
 end-policy-map
 

policy-map OUT-POLICY
 class REALTIME-DATA
  priority level 1 
  police rate percent 1 
  
  
 class IPTV
  bandwidth percent 70 
 
 class CRITICAL-DATA
  bandwidth percent 1 
  random-detect default 
 
 class class-default
  random-detect default 

 end-policy-map

 

или просто указать гарантированную полосу в Mbps? 

[alibek]

Шейпить ничего не нужно.

С обоих сторон на исходящий трафик настроить очереди, наиболее приоритетная для голоса (sp), менее приоритетная для мультикаста (wrr), обычная под остальной трафик.

[jffulcrum]

1 час назад, fox_m сказал:

Нужно ли в этом случае канал предварительно зашейпить до реальной пропускной способности?

Такое надо делать лишь при использовании Etherchannel или туннелей. Если там "чистый" Ethernet, то "крышки" сверху не требуется. 

[fox_m]

1 час назад, alibek сказал:

Шейпить ничего не нужно.

С обоих сторон на исходящий трафик настроить очереди, наиболее приоритетная для голоса (sp), менее приоритетная для мультикаста (wrr), обычная под остальной трафик.

 

Понял. Спасибо.

[zi_rus]

С ума сошли? Конечно нужно шейпить.

 

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

 

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

[alibek]

Ни голос, ни мультикаст шейпить не надо. Что не прошло вовремя, то уже не нужно.

QoS имеет смысл, когда полосы не хватает на все, но хватает на приоритетный трафик. Если полосы хватает на все, то QoS не нужен. Если полосы не хватает на приоритетный трафик, то QoS бесполезен.

Создавать искусственное узкое место, чтобы начал работать QoS, есть смысл только в туннелях и арендуемых каналов, чтобы не упираться в полисер аплинка.

[zi_rus]

В 14.12.2018 в 10:44, fox_m сказал:

провайдер ограничивает канал до 5Гб.

 

18 часов назад, alibek сказал:

и арендуемых каналов, чтобы не упираться в полисер аплинка.

учу читать, дорого.

[s.lobanov]

21 час назад, alibek сказал:

Если полосы хватает на все, то QoS не нужен.

типично ошибочное мнение, точнее не указано что такое полоса и что такое хватает. что значит полосы хватает на всё? вообще задумайтесь что такое полоса. это отношение количества трафика ко времени, за который он прошёл. и проблема в том, за какое время её считать. обычно люди смотрят на свои графики в mrtg/cacti/zabbix (хипстер в графане или что там щас модно) и видят что "полосы хватает" (с усреднением по 5-600 секунд). в самом деле на одном и том же L1-линке трафик между двумя свитчами будет дропаться, а замени их на более "крутые" - трафик уже не дропается или дропается меньше (крутизна это размер egress буфера на свитче). так вот "хватает полосы" это когда у вас нет дропов. на приличных свитчах/роутерах фиксируется и ingress- и egress-дропы и это относительно легко диагностиструется

когда же канал арендованный то вы понятия не имеете дропается там что-то или нет без дополнительных измерений (если это мультикаст, то небольшие дропы легко считаются по ts.cc полю, но сетевое оборудование обычно это не умеет делать). таким образом, нужно знать настройки полисера того кто даёт вам канал (размер бёрстов) чтобы подогнать полисеры/шейперы у себя перед отправкой трафика в этот канал

далее, нужно понимать что сам мультикаст бывает качественный и некачественный с точки зрения равномерности распределения трафика во время, проще говоря, мультикаст сам по себе может быть с бёрстами (плохой генератор, случайная синхронизация нескольких генераторов, буферблоты на сети) и в этом случае у вас даже 1Гб/с такого плохого мультикаста не пролезет в арендованный 5Гб/с канал, если бёрст на арендованном канале будет меньше бёрста потока. И если арендодатель не очень сговорчив или просто вы не можете пробиться через саппорт до инженеров, то единственный вариант для вас будет это пошейпить мультикаст (ничего страшного нет, если вы будете задерживать видеопоток на 10-100 ms, точнее нужно знать размер jit-buffer'а клиентских устройств чтобы понять страшно это или нет)

 

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

Затем, зная бёрст на арендованном канале и оценив его на передаваемом мкасте, посчитал бы бёрст для BE-трафика.

Если получится, что BE будет работать плохо из малого бёрста, то надо менять полисер на шейпер для BE-трафика

 

А вообще (с технической точки зрения), лучше арендовать два разных vlan с разными полосами - один чисто под mcast, другой для остального, так будет намного проще, чем извращаться с fine-tuning на порту, где исходит ваш мультикаст в сторону аренды

 

 

[ShyLion]

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

[fox_m]

В 15.12.2018 в 22:19, s.lobanov сказал:

типично ошибочное мнение, точнее не указано что такое полоса и что такое хватает. что значит полосы хватает на всё? вообще задумайтесь что такое полоса. это отношение количества трафика ко времени, за который он прошёл. и проблема в том, за какое время её считать. обычно люди смотрят на свои графики в mrtg/cacti/zabbix (хипстер в графане или что там щас модно) и видят что "полосы хватает" (с усреднением по 5-600 секунд). в самом деле на одном и том же L1-линке трафик между двумя свитчами будет дропаться, а замени их на более "крутые" - трафик уже не дропается или дропается меньше (крутизна это размер egress буфера на свитче). так вот "хватает полосы" это когда у вас нет дропов. на приличных свитчах/роутерах фиксируется и ingress- и egress-дропы и это относительно легко диагностиструется

когда же канал арендованный то вы понятия не имеете дропается там что-то или нет без дополнительных измерений (если это мультикаст, то небольшие дропы легко считаются по ts.cc полю, но сетевое оборудование обычно это не умеет делать). таким образом, нужно знать настройки полисера того кто даёт вам канал (размер бёрстов) чтобы подогнать полисеры/шейперы у себя перед отправкой трафика в этот канал

далее, нужно понимать что сам мультикаст бывает качественный и некачественный с точки зрения равномерности распределения трафика во время, проще говоря, мультикаст сам по себе может быть с бёрстами (плохой генератор, случайная синхронизация нескольких генераторов, буферблоты на сети) и в этом случае у вас даже 1Гб/с такого плохого мультикаста не пролезет в арендованный 5Гб/с канал, если бёрст на арендованном канале будет меньше бёрста потока. И если арендодатель не очень сговорчив или просто вы не можете пробиться через саппорт до инженеров, то единственный вариант для вас будет это пошейпить мультикаст (ничего страшного нет, если вы будете задерживать видеопоток на 10-100 ms, точнее нужно знать размер jit-buffer'а клиентских устройств чтобы понять страшно это или нет)

 

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

Затем, зная бёрст на арендованном канале и оценив его на передаваемом мкасте, посчитал бы бёрст для BE-трафика.

Если получится, что BE будет работать плохо из малого бёрста, то надо менять полисер на шейпер для BE-трафика

 

А вообще (с технической точки зрения), лучше арендовать два разных vlan с разными полосами - один чисто под mcast, другой для остального, так будет намного проще, чем извращаться с fine-tuning на порту, где исходит ваш мультикаст в сторону аренды

 

 

т.е. примерно так:

 

policy-map OUT
 class REALTIME-DATA
  priority level 1 
  police rate 150 mbps 
  ! 
 ! 
 class IPTV
  bandwidth 3500 mbps 
 ! 
 class class-default
  shape average 1000 mbps 
 ! 
 end-policy-map