Страницы: 1 2 3 4 След.
RSS
микротик, mangle, queue
 

Уважаемые господа! Прикручиваю к ТИ микротик. Собсвтенно в чем вопрос. Шейпинг буду делать маркировкой пакетов forward и отработкой их в queue.



Имеем сеть - например 192.168.1.0/24 В ней пусть 200 абонентов (200 задействованных адресов).



если создать 200 правил для маркировки пакетов, то- проверено алгоритм пробегает по всем рулам (хотя метит только по одной). Чтобы не делать подобного на каждый пакет делаю по следующей схеме.



делаю два правила с action jump в которых делю сеть на 192.168.1.0/25 и 192.168.1.128/25



в chain на эти jump делаю еще jump (в которых делю уже разделенную надвое сеть еще попалам) и т.д.



в итоге дохожу до 192.168.1.0/30 в котором делаю проверку на ip абонента и маркирую пакет. Таким образом на всякий пакет максимально отработки микротиком будет 14 правил. Т.е. некое двоичное дерево. И вместо просмотра на каждый пакет 200 рул - мы получаем гораздо меньше. Смущает то, что правил будет просто немерянно. потому как сетей имеем несколько



192.168.1.0/24,192.168.2.0/24,192.168.3.0/24.......



т.е. в итоге получим от 5000-до 7000 правил. Поделитесь пожалуйста опытом каким образом это реализовано у вас.



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



Спасибо



P.S. paththru - во первых не останавливает просмотр правил mangle, а во вторых даже если бы он это и сделал - то на строках с небольшим номером это было-бы быстро, а на строках с большими номерами - ужас как долго..... (просмотр правил в mangle последовательный)

 
200 правил? у вас что там 100 тарифных планов?

для одного тарифного плана причем не важно сколько там

абонентов нужно всего 2 правила для промаркировки

пакетов, два правила для типа очереди и два правила

для самих очередей...если тарифных планов два то умножайте

все на два, но ту придется еще выставлять limit-at без

него правильно шейпер работать не будет...
 





Цитата
200 правил? у вас что там 100 тарифных планов?

для одного тарифного плана причем не важно сколько там

абонентов нужно всего 2 правила для промаркировки

пакетов, два правила для типа очереди и два правила

для самих очередей...если тарифных планов два то умножайте

все на два, но ту придется еще выставлять limit-at без

него правильно шейпер работать не будет...

Присоединяюсь, все верно.
Виктор, не туда капаете, вернее туда, но немного не в том направлении.
morf40477.0586921296
 

Давайте попробуем разобраться.... Если я промаркирую пакеты в соответствии с тарифными планами то получится примерно следующее:



Имеем 10 абонентов на 1 мегабите. Если промаркируем пакеты для первых 10 абонентов (при помощи списка address list) то мы не сможем индивидуально каждому дать скорость 1 мегабит - они все промаркированы одинаково. Только если в max-limit поставим 10абонентовX1Мб = 10 мегабит. А это совсем не то что нужно.



Т.е. до прихода в queue все пакеты должны быть промаркированы по ip абонента. Как рулить в queue пока не трогаем - давайте разберемся с mangle.



В нем для маркировки делаем 10 правил для отметки соединения и 10 для отметки пакетов (делаем через forward). Можно конечно сделать и через prerouting - но тогда правила будут отрабатыватьcя до NAT и при вредоносном трафике (всевозможных атаках) будет лишний раз задействован процессор микротика. Поэтому forward.



Итак имеем в mangle 20 правил chain=forward для отметки пакетов.



Замечено, что при любом входящем пакете отрабатывают все 20 правил!!! т.е. действие выполняется конечно же по двум, Но операционка просматривает все! Т.е. на входящий пакет происходит простой перебор всех правил mangle. А это 20 правил.. А если абонентов не 20 а больше то на каждый пакет будет просмотров гораздо больше. Если это дейтсвительно так, то хотелось бы придумать схему, чтобы этого избежать.



Как это проверялось?



1 создаем правило для маркировки пакета по ip. и ниже создаем такое же правило (два одинаковых) - отрабатывают оба. Это конечно же не говорит 100% о всем вышесказанном. Но с другой стороны трудно представить себе такой алгоритм, который создает некую прямую выборку правил с тем расчетом что правила могут включать в себя не только ip адреса, но и порты, протоколы и многое другое.



2 В manual была найдено косвенное подтверждение вышесказанному:



As mentioned before, the firewall filtering rules are grouped together in chains. It allows a packet to



be matched against one common criterion in one chain, and then passed over for processing against



some other common criteria to another chain. For example a packet should be matched against the



IP address:port pair. Of course, it could be achieved by adding as many rules with IP



address:port match as required to the forward chain, but a better way could be to add one rule that



matches traffic from a particular IP address, e.g.: /ip firewall filter add



src-address=1.1.1.2/32 jump-target="mychain" and in case of successfull match passes control



over the IP packet to some other chain, id est mychain in this example. Then rules that perform



matching against separate ports can be added to mychain chain without specifying the IP addresses.



2 Т.е. разработчики сами пишут - если маркировка идет по ip и далее по разным портам то лучше сначала сделать chain по ip с действием jump и в нем уже рассматривать порты.

 

В правилах mangle также может быть реализована сложная логика управления со всемозможными действиями как отметками, переходами, возвратами и чтобы системе ее реализовать она просто должна пройти по правилам сверху вниз - иначе не получится!!! Поэтому я все таки предполагаю что просмотр в mangle осуществляется последовательно. А если имеем 1000 абонентов на каждого по 2 рулы. То на каждый входящий пакет 2000 просмотров правил просто ЖИРНО!!!



А если же есть вариант создания в mangle правил только для тарифных правил (например имеем тарифный план - гарантированный 1 мегабит кажому абоненту) и в queue промаркированные пакеты уже как то разруливать...... поделитесь пожалуйста логикой

 
https://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ_Examples</br><br />

я не понимаю а в чем проблем то???? смысл изобретать

велосипед



simple queue чем вас не устроило? систему грузит меньше



и маркировать ничего не нужно

 
Цитата

Давайте попробуем разобраться.... Если я

промаркирую пакеты в соответствии с тарифными планами то

получится примерно следующее:



Имеем 10 абонентов на 1 мегабите. Если промаркируем пакеты

для первых 10 абонентов (при помощи списка address list) то мы

не сможем индивидуально каждому дать скорость 1 мегабит - они

все промаркированы одинаково. Только если в max-limit поставим

10абонентовX1Мб = 10 мегабит. А это совсем не то что нужно.




с чего это вы взяли? :)



Цитата

Т.е. до прихода в queue все пакеты должны быть

промаркированы по ip абонента. Как рулить в queue пока не

трогаем - давайте разберемся с mangle.



В нем для маркировки делаем 10 правил для отметки соединения

и 10 для отметки пакетов (делаем через forward). Можно конечно

сделать и через prerouting - но тогда правила будут

отрабатыватьcя до NAT и при вредоносном трафике (всевозможных

атаках) будет лишний раз задействован процессор микротика.

Поэтому forward.



Итак имеем в mangle 20 правил chain=forward для отметки

пакетов.




для шейпера метим в форварде, в прероутинге вы не сможете

пометить пакеты in для группы. если ресурсы позволяют, то метьте

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

вторых меньше правил надо создавать...



Цитата

Замечено, что при любом входящем пакете

отрабатывают все 20 правил!!! т.е. действие выполняется конечно

же по двум, Но операционка просматривает все! Т.е. на входящий

пакет происходит простой перебор всех правил mangle. А это 20

правил.. А если абонентов не 20 а больше то на каждый пакет

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

хотелось бы придумать схему, чтобы этого избежать.



Как это проверялось?



1 создаем правило для маркировки пакета по ip. и ниже создаем

такое же правило (два одинаковых) - отрабатывают оба. Это

конечно же не говорит 100% о всем вышесказанном. Но с другой

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

некую прямую выборку правил с тем расчетом что правила могут

включать в себя не только ip адреса, но и порты, протоколы и

многое другое.



вы я так понимаю не до конца понимаете движение пакета в

микротике...

Цитата

2 В manual была найдено косвенное подтверждение

вышесказанному:

<FONT face="Times New Roman">

As mentioned before, the firewall filtering rules

are grouped together in chains. It allows a packet to



be matched against one common criterion in one

chain, and then passed over for processing against



some other common criteria to another chain. For

example a packet should be matched against the



<FONT face="Times New Roman">

IP address:port <FONT face="Times New

Roman">pair. Of course, it could be achieved by adding as many

rules with <FONT face="Times New Roman">IP



address:port <FONT face="Times New

Roman">match as required to the <FONT face="Times New

Roman">forward
<FONT face="Times New Roman">chain,

but a better way could be to add one rule that



matches traffic from a particular IP address,

e.g.: <FONT size=1 face=Courier><FONT size=1

face=Courier>/ip firewall filter add



src-address=1.1.1.2/32 jump-target="mychain"

<FONT face="Times New Roman">and in case

of successfull match passes control



over the IP packet to some other chain,

<FONT face="Times New Roman">id est
<FONT

face="Times New Roman">mychain
<FONT face="Times New

Roman">in this example. Then rules that perform



matching against separate ports can be added to

<FONT face="Times New Roman">mychain <FONT

face="Times New Roman">chain without specifying the IP

addresses.



2 Т.е. разработчики сами пишут - если маркировка

идет по ip и далее по разным портам то лучше сначала сделать

chain по ip с действием jump и в нем уже рассматривать порты.



вам уже привели пример -

https://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ

Цитата


я не понимаю а в чем проблем то???? смысл изобретать

велосипед



simple queue чем вас не устроило? систему грузит меньше



и маркировать ничего не нужно


:) если тарифных планов один, то может быть, а если их много?

вы как канал собираетесь делить? или высчитывать каждому IP

Limit=at? ну если канала с запасом то наверное можно не

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

загружаться, то получите не очереди в канале а хаос...
 

Constantin
- сколько админов - столько и мнений... я бы не прочь работать с simple но сколько общался - все говорят за маркировку против simple. Если Вы рекомендуете именно этот вариант, то по идее должны на нем работать. Сколько у вас заведено правил для simple? Я к сожалению такого опыта не имею и не хотелось бы потом менять стратегию... Если работать через simple, мне например необходимо сделать пинг без задержек для всех на любой рессурс - нужно работать с global-in(out)? Т.е. маркируем в global-in(out) а в simple рулим только не маркированными пакетами?



mr_Neo



в прероутинге вы не сможете пометить пакеты in для группы
для исходящих используем postrouting



если ресурсы позволяют, то метьте  не соединения а сразу пакеты



не согласен, как раз таки наоборот.



вы я так понимаю не до конца понимаете движение пакета в
микротике...
короче не хочу спорить....



вопрос перефразируется. забудьте пожалуйста шепинг и все остальное... просто если знаете ответьте на следующий вопрос



ip firewall mangle add chain=forward action=mark-connection new-connection-mark=I000-009 passthrough=no dst-address=192.168.0.9
ip firewall mangle add chain=forward action=mark-packet new-packet-mark=000-009I passthrough=no connection-mark=I000-009



ip firewall mangle add chain=forward action=mark-connection new-connection-mark=I000-010 passthrough=no dst-address=192.168.0.10
ip firewall mangle add chain=forward action=mark-packet new-packet-mark=000-0010I passthrough=no connection-mark=I000-010



имеем правила для двух IP адресов.



приходит пакет для 192.168.0.9



Вопрос: система просмотрит рулу для двух последних правил для принятия решения о маркировке да или нет?



Спасибо

 
Прошу прощения что вмешиваюсь.
В микротике присутсвуют проприетарные механизмы вроде того же pcq queue так что кто знает что они могли наворотить с обработками.
Но всё таки правила работы пакетных фильтров врядли отличаются от принципов которые реализованы как на железяках так и в nix/bsd системах.
Иными словами, пакет ползёт по цепочке до первого match. После этого он выходит из обработки и подвергается дейсвтиям описанным в правиле.
Частным случаем возвращения в цепочку является jump в другую цепочку и потом return из неё если пакет не заматчился не по одному из "подусловий".
Если бы у вас был обычный линупс я бы посоветовал вам ipset. С микротиком даже не подскажу.
 

ой пасибочки! логика я думаю одинаковая...



Нашел хорошую документацию по iptables для линукса... очень хорошо все расписано - все практически совпадает с router OS. Но данный нюанс не описан



1. т.е. все таки ползет по цепочке? если match встречается где то у нее в конце то это не есть хорошо.



2. Но если даже он и встретил match - неужели он не возвращается чтобы ползти дальше?



В моем случае - создаю два одинаковых правила. И маркируются оба. Т.е. пометили и вернулись обратно... следующим правилом опять пометили...



Если все таки происходит линейная обработка правил - то создавать маркировку для каждого абонента по IP - просто убийственная вещь

Страницы: 1 2 3 4 След.
Читают тему (гостей: 2)