[taf_321]

Никто не пробовал сравнить производительность связки iptables + ipset с skbprio + tc против хэш таблиц голого tc? Хэши в tc вполне устраивают на ipv4, но на ipv6 о них можно забыть. Поэтому ищется универсальный инструмент, для обоих протоколов.

[pavel.odintsov]

А почему про хэши можно забыть в IPv6?

[photon]

Какая разница, ipv6 или ipv4, если классов все равно не больше 2^16-1? Классификацию по хэшам можно делать абсолютно так же, по уникальным четырем байтам из IPv6-адреса, изменится только смещение.

[taf_321]

При хэше по 4-м байтам идет жесткая привязка к /64. Помимо того, что на выходе будет монструозная конструкция, так еще и она не будет подходить к случаям, когда надо резать для кусков мельче /64. Да, все говорят, что надо именно по /64, но стрельнет что-то азотосодержащее в голову маркетоидам, и никуда не денешься.

[GrandPr1de]

Да, все говорят, что надо именно по /64, но стрельнет что-то азотосодержащее в голову маркетоидам, и никуда не денешься.

Если маркетоиды начнут решать что-то кроме тарифов - быть беде ;)

Есть масса обоснований почему \64, просто ткните их носом в документацию, не дойдет - ткните ещё раз и так пока нос не сломается или не дойдет до них...

[taf_321]

Если маркетоиды начнут решать что-то кроме тарифов - быть беде ;)

Есть масса обоснований почему \64, просто ткните их носом в документацию, не дойдет - ткните ещё раз и так пока нос не сломается или не дойдет до них...

 

Это все да, но принципиального технического огранчения по раздаче куском менее /64 нет. Закладываться на постулат "Да это никогда не понадобится" я зарекся очень давно. Если какое-либо явление не имеет принципиального запрета на появление, то оно рано или поздно (но всегда неожиданно и должно быть сделано вчера) объявится.

[Sergeylo]

Если подразумевается возможность дробления /64, то это попросту не будет работать на большей части абонентского оборудования.

Не, конечно, для отдельных задач вполне реально задействовать какие-нибудь /120, но проще и логичнее (тут, конечно, можно поспорить) даже для стыков хост-хост делать /64.

Предлагаю просто забыть про всяческие сущности, промежуточные для /64 и /128. Их нет и не предвидится.

[pavel.odintsov]

Ну у меня вот таска выдача IPv6 на машинах с виртуализацией и выдаю я /128 из разных /96 по несколько штук на машину. Ибо если выдавать по аж 64, то OpenVZ станет плохо от числа префиксов :( Поэтому - да, какой именно кусок адреса выдирать совершенно не ясно, он плавает. Так что проблема с дроблением, безусловно, есть.

[GrandPr1de]

Ну у меня вот таска выдача IPv6 на машинах с виртуализацией и выдаю я /128 из разных /96 по несколько штук на машину. Ибо если выдавать по аж 64, то OpenVZ станет плохо от числа префиксов :( Поэтому - да, какой именно кусок адреса выдирать совершенно не ясно, он плавает. Так что проблема с дроблением, безусловно, есть.

ээээ, а о каком числе префиксов речь?

Выдача для птп \128 из любого пула - правильное решение, насколько я пнимаю, вот только с маршрутизацией не ясно, вроде как меньше чем \64 - всё печально.

Т.е. RA работет вроде только при маске в \64 или больше, насколько помню.

Лично я понимаю так что, всё что меньше чем \64 - просто кусок этой самой \64. Т.е. висит на роутере ип с маской \64, а у конечного устройства, допустим надо дать ему 4 адреса, прописано \126 и по RA он получает шлюз и днс.

Поправте если не прав.

[taf_321]

Внезапно, но RA не обязан быть везде и всюду.

[pavel.odintsov]

У меня RA вообще нету, OpenVZ очень хитро держит IPv6 и половина его фич оторвата :)

[GrandPr1de]

Внезапно, но RA не обязан быть везде и всюду.

Да необязан, но вроде как жизнь легче делает :)

[taf_321]

Да необязан, но вроде как жизнь легче делает :)

 

Оно, конечно, да. но это сродни сидению на RIPv1.

 

В любом случае, это все оффтоп, причину обращения к вынесеной в Subj связке я указал, но и только. Интересует именно производиельность связки, а не бодания "все на /64, не все на /64"

[pavel.odintsov]

Если есть боевой пример для в6 - я могу попробовать внедрить, у меня есть солидная нагрузка и по 3 тыщи правил на сервер.

 

Сейчас все сделано тупыми линейными правилами tc htb, тыщи их!

[taf_321]

Собрал на коленке схемку для тестирования шейпера на исходящий трафик. В общем случае это выглядит так:

 

#!/bin/sh

tc qdisc del dev enp3s0 root

tc qdisc add dev enp3s0 root handle 1: est 1sec 8sec hfsc default ffff

tc class add dev enp3s0 parent 1: classid 1:1 est 1sec 8sec hfsc sc rate 2Gbit ul rate 2Gbit

tc class add dev enp3s0 parent 1: classid 1:ffff est 1sec 8sec hfsc sc umax 1500 dmax 150ms rate 1000kbit ul rate 100Mbit
tc qdisc add dev enp3s0 parent 1:ffff handle ffff: pfifo limit 50000
tc filter add dev enp3s0 parent 1: protocol ip prio 1000 u32 match u32 0 0 classid 1:ffff

#>>>>>
tc class add dev enp3s0 parent 1: classid 1:2 est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 10240kbit ul rate 10240kbit
#>>>>>

#####
ipset create test hash:net family inet6 skbinfo
ipset add test fe80::5054:ff:fe26:199b skbprio 1:2

ip6tables -t mangle -A OUTPUT -o enp3s0 -j SET --map-set test dst --map-prio

 

Пара замечаний. iptables должен быть собран или из бранча ipset, или вот с этим патчем:

https://git.netfilter.org/iptables/commit/?h=ipset&id=6d9ae2952a440b4ff28e86df6d18b53caa7ecd94 и

ipset должен быть 6.22 и новее.

 

Шейпер работает. Собственно, в первом приближении получается достаточно вменяемая человеко-понимаемая схема без принципиальных огранничений на размер шейпируемых блоков. вот как под нагрузкой оно будет шевелиться?