Shaper #33

New Issue

Yasen6275 · 2024-05-17T16:24:57+03:00

Yasen6275 commented

2024-05-17 16:24:57 +03:00

Резервиране на 1Gbps за всичко без stream/restream

Yasen6275 added this to the Services milestone 2024-05-17 16:24:57 +03:00

Yasen6275 changed title from ~~Shaoer~~ to Shaper

2024-05-17 16:27:46 +03:00

albert commented

2024-05-17 19:03:30 +03:00

Define "резервиране" - горна или долна граница?
Не че не можем да треснем гол policer 1Gbps на всичко освен видео/стрийм, ама не ме кефи :(

Ако ще шейпим по-скоро си представям да сме малко по-гъвкави с QoS, защото може да се застреляме в крака иначе.
Вкарваме трафика (може би дори служебния?) в няколко HTB класа, като за всеки дефинираме guaranteed bandwidth.

Числата зависят от #34, но ако assume-нем че са ни пуснали тръби от 10Gbps и 5Gbps:

tc qdisc add dev {тръба1} root handle 1: htb default 2
tc class add dev {тръба1} parent 1: classid 1:1 htb rate 8gbit burst 100m cburst 20m
tc class add dev {тръба1} parent 1:1 classid 1:2 htb rate 20mbit ceil 1gbit prio 6
tc class add dev {тръба1} parent 1:1 classid 1:{mgmt vlan id} htb rate 10mbit ceil 50mbit prio 0
tc class add dev {тръба1} parent 1:1 classid 1:{video vlan id} htb rate 200mbit ceil 7gbit prio 1
tc class add dev {тръба1} parent 1:1 classid 1:{voip vlan id} htb rate 10mbit ceil 100mbit prio 1
...
tc class add dev {тръба1} parent 1:1 classid 1:{wifi vlan id} htb rate 20mbit ceil 1gbit prio 7

tc qdisc add dev {тръба2} root handle 2: htb default 2
tc class add dev {тръба2} parent 2: classid 2:1 htb rate 4gbit burst 75k cburst 15k
tc class add dev {тръба2} parent 2:1 classid 2:2 htb rate 20mbit ceil 1gbit prio 6
tc class add dev {тръба2} parent 2:1 classid 2:{mgmt vlan id} htb rate 10mbit ceil 50mbit prio 0
tc class add dev {тръба2} parent 2:1 classid 2:{video vlan id} htb rate 200mbit ceil 3gbit prio 1
tc class add dev {тръба2} parent 2:1 classid 2:{voip vlan id} htb rate 10mbit ceil 100mbit prio 1
...
tc class add dev {тръба2} parent 2:1 classid 2:{wifi vlan id} htb rate 20mbit ceil 500mbit prio 7

Kъм това добавяме нещо от рода на:

tc filter add dev {тръба1} protocol all parent 1:0 prio 1 handle {fwmark = vlan id} fw flowid 1:{vlan id}
...
tc filter add dev {тръба2} protocol all parent 2:0 prio 1 handle {fwmark = vlan id} fw flowid 2:{vlan id}
...

Правилата, по които мачваме в класовете (слагаме им fwmark, за по-лесно съответства на vlan id):

vlan id в общия случай
към видео трафика добавяме рестриймъра (вероятно това включва всичко уеб, т.е. и мониторинг)
можем да правим допълнителни изключения, мачвайки по IP адреси

Какви общо взето са съображенията:

в мениджмънт VLAN-а не очакваме нищо смислено да ходи към Интернет, 50Mbps са ако някой от нас се закачи в NOC-a все пак да има интернет (subject to обсъждане къде ще се закачим, можем да му вдигнем лимитите)
видео и стрийм ядат
VoIP трябва да работи
Wi-Fi ни е все тая, затова е и с най-нисък приоритет (но потенциално е много, така че има висок ceil)

Всяка от опашките "най-вътре" е pfifo по подразбиране, може да сменим нещо ако преценим, но не мисля че има нужда.

Как би се държало това нещо:

ако връзката е пълна всеки клас си получава гарантирания bandwidth
можем смело да сумираме ceil до число над rate на самия родител, тогава почваме по приоритети (всъщност е добре да докараме сумата от ceil на децата до нещо по-голямо от rate на родителя)
можем да добавим още burst/cburst магарии, идеята е все пак ако ние тръгнем да теглим нещо голямо да не се самозастреляме с лимита за нашата опашка
най-важното -- трафикът към тръба 1 и към тръба 2 са отделни и можем да се подсигурим че не пълним нито едната
клас тръба:2 с нисък приоритет е за служебен трафик, който не сме маркирали (примерно защото сме спали някъде)

Notes:

ако пускаме шейпъри трябва да изгасим TSO и ако можем LRO на картата
да видим къде ще се закачаме ние и ако е в мениджмънт да барнем ли шейпъра
искаме ли отделен лекторvlan / лекторwi-fi, за да не ги шейпим равностойно с останалите юзъри

Define "резервиране" - горна или долна граница? Не че не можем да треснем гол policer 1Gbps на всичко освен видео/стрийм, ама не ме кефи :( Ако ще шейпим по-скоро си представям да сме малко по-гъвкави с QoS, защото може да се застреляме в крака иначе. Вкарваме трафика (може би дори служебния?) в няколко HTB класа, като за всеки дефинираме guaranteed bandwidth. Числата зависят от #34, но ако assume-нем че са ни пуснали тръби от 10Gbps и 5Gbps: ``` tc qdisc add dev {тръба1} root handle 1: htb default 2 tc class add dev {тръба1} parent 1: classid 1:1 htb rate 8gbit burst 100m cburst 20m tc class add dev {тръба1} parent 1:1 classid 1:2 htb rate 20mbit ceil 1gbit prio 6 tc class add dev {тръба1} parent 1:1 classid 1:{mgmt vlan id} htb rate 10mbit ceil 50mbit prio 0 tc class add dev {тръба1} parent 1:1 classid 1:{video vlan id} htb rate 200mbit ceil 7gbit prio 1 tc class add dev {тръба1} parent 1:1 classid 1:{voip vlan id} htb rate 10mbit ceil 100mbit prio 1 ... tc class add dev {тръба1} parent 1:1 classid 1:{wifi vlan id} htb rate 20mbit ceil 1gbit prio 7 tc qdisc add dev {тръба2} root handle 2: htb default 2 tc class add dev {тръба2} parent 2: classid 2:1 htb rate 4gbit burst 75k cburst 15k tc class add dev {тръба2} parent 2:1 classid 2:2 htb rate 20mbit ceil 1gbit prio 6 tc class add dev {тръба2} parent 2:1 classid 2:{mgmt vlan id} htb rate 10mbit ceil 50mbit prio 0 tc class add dev {тръба2} parent 2:1 classid 2:{video vlan id} htb rate 200mbit ceil 3gbit prio 1 tc class add dev {тръба2} parent 2:1 classid 2:{voip vlan id} htb rate 10mbit ceil 100mbit prio 1 ... tc class add dev {тръба2} parent 2:1 classid 2:{wifi vlan id} htb rate 20mbit ceil 500mbit prio 7 ``` Kъм това добавяме нещо от рода на: ``` tc filter add dev {тръба1} protocol all parent 1:0 prio 1 handle {fwmark = vlan id} fw flowid 1:{vlan id} ... tc filter add dev {тръба2} protocol all parent 2:0 prio 1 handle {fwmark = vlan id} fw flowid 2:{vlan id} ... ``` Правилата, по които мачваме в класовете (слагаме им fwmark, за по-лесно съответства на vlan id): - vlan id в общия случай - към видео трафика добавяме рестриймъра (вероятно това включва всичко уеб, т.е. и мониторинг) - можем да правим допълнителни изключения, мачвайки по IP адреси Какви общо взето са съображенията: - в мениджмънт VLAN-а не очакваме нищо смислено да ходи към Интернет, 50Mbps са ако някой от нас се закачи в NOC-a все пак да има интернет (subject to обсъждане къде ще се закачим, можем да му вдигнем лимитите) - видео и стрийм ядат - VoIP трябва да работи - Wi-Fi ни е все тая, затова е и с най-нисък приоритет (но потенциално е много, така че има висок ceil) Всяка от опашките "най-вътре" е pfifo по подразбиране, може да сменим нещо ако преценим, но не мисля че има нужда. Как би се държало това нещо: - ако връзката е пълна всеки клас си получава гарантирания bandwidth - можем смело да сумираме ceil до число над rate на самия родител, тогава почваме по приоритети (всъщност е добре да докараме сумата от ceil на децата до нещо по-голямо от rate на родителя) - можем да добавим още burst/cburst магарии, идеята е все пак ако ние тръгнем да теглим нещо голямо да не се самозастреляме с лимита за нашата опашка - най-важното -- трафикът към тръба 1 и към тръба 2 са отделни и можем да се подсигурим че не пълним нито едната - клас тръба:2 с нисък приоритет е за служебен трафик, който не сме маркирали (примерно защото сме спали някъде) Notes: - ако пускаме шейпъри трябва да изгасим TSO и ако можем LRO на картата - да видим къде ще се закачаме ние и ако е в мениджмънт да барнем ли шейпъра - искаме ли отделен лекторvlan / лекторwi-fi, за да не ги шейпим равностойно с останалите юзъри

Yasen6275 commented

2024-05-18 11:30:18 +03:00

По-скоро си го мислех stream/restream да им дадем таван 9 GB. Или 9.5GB.

Sign in to join this conversation.