» MikroTik RouterOS (часть 3)

FreeLSD_md
1) Всё это просто дополнительные параметры которые клиент получит вместе с адресом. WINS сервер указывается только при его наличии в сети.
2) На служебный трафик ИМХО никак не повлияет. Скорее просто для совместимости.

Chupaka

Цитата:

и - да, у пакета может быть только одна метка, несколько установить невозможно, так задумано

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

скажем, если есть такая задача, есть 10 абонентов с шейпами в 128к, которые заполнены, то есть все абоненты чего то качают, требуется сделать так, что бы http трафик для всех абонентов имел больший приоритет нежели скажем ftp и весь остальной, для этого потребуется от маркировать трижды трафик,
1) http, маркируется для всех адресов 10 абонентов ставим passthrough=yes
2) ftp, маркируем его так же для всех, ставим passthrough=yes
3) самое интересное здесь надо от маркировать весь трафик, для шейпа каждого абонента, получается что 3 правило ремаркирует пакеты от маркированные первыми двумя правилами.

получается задача не выполнима, и в таком случае я не совсем понимаю для чего тогда сделали вообще возможность passthrough=yes, если пропуская пакеты дальше их все равно ремаркирует.

fdboss

Цитата:

я не совсем понимаю для чего тогда сделали вообще возможность passthrough=yes

Потому что в Мангле можно не только метки на пакеты ставить, но и другие операции проводить. Для того, чтобы подвергнуть один и тот же трафик последовательному воздействию разных actions в пределах одной и той же цепочки и используется passthrough=yes. Например, можно сначала определённому трафику присвоить метку роутинга, чтобы впоследствии использовать её для заворачивания трафика на нужный интерфейс, а затем уже присвоить метку пакета, для использования её в качестве классификатора в HTB. Метки роутинга и метки пакетов, на сколько понимаю, ни как друг другу не мешают и могут сосуществовать одновременно.

Цитата:

korsakoff72RU

не глобальное предназначение passthrough=yes это понятно что его можно юзать для разных целей, я имею введу прикладное значение при маркировки пакетов для queue tree, и привел задачу например которую я пока что то решить не могу, точнее не могу решить с минимальными манглами.

fdboss

Цитата:

я имею введу прикладное значение при маркировки пакетов для queue tree, и привел задачу например которую я пока что то решить не могу

Так не нужно устанавливать опцию passthrough в вашем случае в положение "yes". Пометили вы, допустим, в prerouting свой http-трафик (пакеты) с помощью dst-port=80, далее его нужно исключить из дальнейшей обработки в текущей цепочке с помощью passthrough=no, чтобы не произошло перемаркировки уже помеченных пакетов ниже стоящим(и) правил(ом/ами), принадлежащим(и) ТОЙ ЖЕ САМОЙ ЦЕПОЧКЕ (например, при пометке http и "всего остального"). Помеченные в prerouting пакеты вы используете при настройке HTB, размещённой, допустим, в Total-IN. После того, как пакеты прошли шейпер в Total-IN, вы можете перемаркировать пакеты в цепочках forward или postrouting по тому же принципу с использованием passthrough=no и использовать новые метки для HTB на Total-OUT или HTB-интерфейсе.

Добавлено:

Цитата:

с минимальными манглами.

Что есть "минимальные манглы"?

Цитата:

korsakoff72RU

да все это понятно, вы задачу внимательно прочитайте, задача не в том что бы пометить пакеты для размещения в Total-IN, я же специально привел пример задачи, там нет никаких Total-IN и т.д.


Цитата:

Что есть "минимальные манглы"?

минимальные манглы это и есть как раз то что бы не маркировать пакеты 3 раза.
я знаю как решить мою задачу но количество манглов будет не потребно велико.

для еще большей наглядности

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

Цитата:

вы задачу внимательно прочитайте

Ну и? Вы сами внимательно прочитайте мой предыдущий ответ. Не нужно для помеченных пакетов ставить passthrough=yes, нужно passthrough=NO! Если вы хотите шейпить и приоритезировать трафик для всех 10 юзеров в один проход, то да - у вас получится по 3+3 (out+in) правила для каждого юзера, т.е. в сумме 30 правил для исходящих и 30 правил для входящих пакетов=60. Чтобы избежать этой громоздкости и был предложен двупроходный шейпер, принцип которой изложен в небезызвестной презентации от Megis'а: сначала метятся пакеты по принадлежности к тому или иному протоколу в прероутинге и задаются приоритеты трафику в global-in, а затем перемаркируются в форварде или построутинге по признаку src-/dst-address и отправляются в 2 (1-out+1-in) PCQ-очереди в global-out или на исходящем интерфейсе(при отсутствии NAT) для нарезки полосы пропускания по клиентам. В вашем случае при двухпроходном варианте можно обойтись всего 8 правилами в мангле вместо 60 при однопроходном.

Цитата:

но количество манглов будет не потребно велико.

это на сколько велико?
вроде как работает, имеем 4 внешних канала, на каждом сделано по
9 приоритетов правил, как вход так и выход, так же на каждом
канале сделан шейпер для нарезки скорости 6-ти группам с разной скорости.
и заметьте что абонентов больше на несколько порядков чем вы предложили
в примере, правил в мангле 80-сят и это с еще всякими правилами на роутинг,
логирующие правила , блокировку и т.д.
а у вас всего 10 абонентов, там их будет кот наплакал...

P.S.
и где то я прочитал, что у пакета может быть только одна метка,
например пометили пакет в прероутинге на приоритет трафика,
далее он отрабатывает в Global-in, после чего попадает в форвард
уже без метки и тут мы ему делаем еще метку.
могу и ошибаться, хотя вроде логически правильно...

Цитата:

и где то я прочитал, что у пакета может быть только одна метка,
например пометили пакет в прероутинге на приоритет трафика,
далее он отрабатывает в Global-in, после чего попадает в форвард
уже без метки и тут мы ему делаем еще метку.
могу и ошибаться, хотя вроде логически правильно...

Проверить можно легко. Ставим в любой цепочке после global-in логирующее правило по признаку метки пакета, промаркированного в прероутинге, и смотрим логи.

Цитата:

Ну и? Вы сами внимательно прочитайте мой предыдущий ответ. Не нужно для помеченных пакетов ставить passthrough=yes, нужно passthrough=NO! Если вы хотите шейпить и приоритезировать трафик для всех 10 юзеров в один проход, то да - у вас получится по 3+3 (out+in) правила для каждого юзера, т.е. в сумме 30 правил для исходящих и 30 правил для входящих пакетов=60. Чтобы избежать этой громоздкости и был предложен двупроходный шейпер, принцип которой изложен в небезызвестной презентации от Megis'а: сначала метятся пакеты по принадлежности к тому или иному протоколу в прероутинге и задаются приоритеты трафику в global-in, а затем перемаркируются в форварде или построутинге по признаку src-/dst-address и отправляются в 2 (1-out+1-in) PCQ-очереди в global-out или на исходящем интерфейсе(при отсутствии NAT). В вашем случае при двухпроходном варианте можно обойтись всего 8 правилами в мангле вместо 60 при однопроходном.

вот это уже ближе к теме
только вот как выразился Chupaka вкурить до просветления пока не получается.
или я не верно представляю себе картинку прохождения пакетов, ведь пакеты попадая в global-in, потом попадут в global-out, и опять таки тормазнутся в очереди на клиента, или я не прав???


Цитата:

это на сколько велико?

ну в моем случае, в данный момент имею 1512 манглов, не хитрое умножение, и вуаля не один сервак не выдержит.

fdboss
я думаю вы как и я раньше пытался в одно дерево запихнуть
и шейпер и приоритет трафика по типу и получилось что нельзя
запихнуть не запихуемое
попросите korsakoff72RU он вам расскажет ка идет пакет от
пользователя до скажем ya.ru и обратно и вам станет ясно, что вы
пытаетесь ловить пакеты для маркировки там где их нет или они у вас
тупо пере-маркировываются...

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

fdboss
http://mum.mikrotik.com/presentations/CZ09/QoS_Megis.pdf

или

http://wiki.mikrotik.com/wiki/NetworkPro_on_Quality_of_Service

Цитата:

я думаю вы как и я раньше пытался в одно дерево запихнуть
и шейпер и приоритет трафика по типу и получилось что нельзя
запихнуть не запихуемое
попросите korsakoff72RU он вам расскажет ка идет пакет от
пользователя до скажем ya.ru и обратно и вам станет ясно, что вы
пытаетесь ловить пакеты для маркировки там где их нет или они у вас
тупо пере-маркировываются...

где и как ловить пакет для маркировки это как раз таки не проблема, проблема вкурить как всё происходит в queues tree.

vlh

Цитата:

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

Я лично не проверял, затирается ли packet-mark после прохождения той или иной HTB-очереди, т.к. необходимости в этом не было, но простой способ проверки я вам предложил. Несколько packet-mark в одном пакете существовать не могут, толко 1.

Цитата:

Несколько packet-mark в одном пакете существовать не могут, толко 1.

я про это и имел ввиду....


Цитата:

где и как ловить пакет для маркировки это как раз таки не проблема, проблема вкурить как всё происходит в queues tree.

не знаю как вам, но предложенный korsakoff72RU мануал
меня и сбивал, вот у вас я смотрю тоже самое как и у меня когда
ни чего не получалось.... делайте два разных дерева в Queue Tree
одно на приоритет трафика второе на шейпер (ограничение скорости)...
приоритет метим в прероутинге, а для шейпера в форварде...

vlh

Цитата:

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

Почему нельзя-то? Можно. Вопрос в целесообразности: повышаются трудозатраты на вбивание всех правил (в итоге вних можно будет просто запутаться) и повышается нагрузка на оборудование.

Цитата:

fdboss
http://mum.mikrotik.com/presentations/CZ09/QoS_Megis.pdf

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

Единственный способ увязать все это, если предположить что, если global-in присылает(на основе приоритетов)http трафика больше в global-out, то тогда возможно это и будет работать, даже при наличии очереди в global-out.

Цитата:

Почему нельзя-то? Можно.

если не сложно, напишите как, то есть например для входящих пакетов:
дерево в global-in далее листок с парентом на это дерево и т.д.
правила писать не нужно, меня интересует как все это увязать...

fdboss

Цитата:

как раз на основании этой доки я собственно и пришел в тупик.

ну вот еще один человек которому это мануал не понятен, значит я не один

Цитата:

не знаю как вам, но предложенный korsakoff72RU мануал

Это не я его предложил а Megis . Я ж не виноват, что он его, во-первых, оставил несколько незаконченным, а, во-вторых, допустил косяк (до сих пор почему-то неисправленный) с PCQ-очередями на внешнем интерфейсе. Оттуда можно брать только общие принципы организации двупроходного шейпа с приоритезакцией, а не слепо копипастить настройки.

Цитата:

ну вот еще один человек которому это мануал не понятен, значит я не один

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

Цитата:

как раз таки сам мануал понятен

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

Добрый день, подскажите пожалуйста что делать.

Есть такая схема:

Mikrotik 5.0rc7(x86)<--1G-->RB250GS


В Mikrotik 5.0rc7(x86) стоит две сетевые карты Planet ENW-9700

C RB250GS проброшен влан транк 3-х вланов на Mikrotik 5.0rc7(x86)
Всё работает хорошо, но периодически на x86 компе сетевая карта смотрящая на RB250GS делает link off , link on ,
соответвенно потеря на шлюз 4 или более пакетов, такая фигня может произойти раз в 30 минут, а может раз в 2 часа, закономерности я не нашел. Менял пачкорды , переподключал во вторую сетевую карту, проверял контакты ничего не помогло.


Попробывал чуть позже такую схему:

Mikrotik 5.0rc7(x86)<--1G-->RB750G<--1G-->RB250GS

Между RB750G и RB250GS связь стабильная, без потерь и переподключений интерфейсов

На RB750G порты в которые подключены Mikrotik 5.0rc7(x86) и RB250GS обьеденил в свич, всёравно периодически происходит link off , link on на сетевой Mikrotik 5.0rc7(x86)

После обновления на x86 роутере версии до 5.0rc7, увидело встроенную в материнскую плату сетевую карту, сейчас подключил через неё и буду наблюдать за потерями.

Подскажите, неужели Planet ENW-9700 не дружит с контролерами в роутер бордах ? Нормально ли что обе сетевые в IRQ отображаются не под именами интерфейсов, а набором цифр?

vlh

Цитата:

если не сложно, напишите как, то есть например для входящих пакетов:

А чего сложного-то. Возьмём, допустим условия, предложенные fdboss:

Цитата:

скажем, если есть такая задача, есть 10 абонентов с шейпами в 128к, которые заполнены, то есть все абоненты чего то качают, требуется сделать так, что бы http трафик для всех абонентов имел больший приоритет нежели скажем ftp и весь остальной

Цепляем, допустим, к global-out или локальному интерфейсу корневой класс, который описывает общую пропускную способность канала в интернет (допустим, max-limit=2M, limit-at=2M).
К корневому классу цепляем 10 дочерних внутренних (inner) классов, которые будут символизировать у нас 10 клиентов, max-limit которым задаём в размере 128k каждому, limit-at для них тоже укажем в размере 128k.
К каждому из этих 10 классов цепляем 3 оконечных дочерних (leaf) класса, каждый из которых будет символизировать у нас http, ftp и "всё остальное", задаём приритеты : http - 1, ftp - 2 , "всё остальное" - 8. Для каждого из этих оконечных классов max-limit=128k, параметр limit-at - по вкусу (но в сумме значения limit-at для http, ftp и "всего остального" каждого отдельного клиента не должны превышать 128k). В итоге полкчаем в сумме 30 leaf-классов.
К каждому leaf-классу назначаем pfifo-очередь, допустим, "default".
В Мангле метим http, ftp и "всё остальное" по dst-address и протоколу для каждого клиента в отдельности, а затем направляем помеченные пакеты в соответствующие очереди.
Итого, для пометки только входящих пакетов для 10 юзеров придётся создатать 30 правил. И ещё столько же правил придётся создать для исходящего трафика, т.е. в сумме 60(!). А теперь представьте, что протоколов необходимо приоритезировать больше... А если юзеров не 10, а 100...?

P.S. Можно уменьшить, в данном случае, нагрузку на роутер, пометив сначала соединения по src-address в forward'е, а затем пометив там же пакеты, используя метку соединения. Пакеты в данном случае не надо будет метить отдельно как исходящие и входящие, т.к. если очереди размещать непосредственно на исходящих интерфейсах, то в очереди, размещённые на локальном интерфейсе, попадут только входящие пакеты, а в очереди на внешнем интерфейсе только исходящие. Как уже сказал, роутер это разгрузит, но количество правил в мангле не уменьшится их так и останется 60: (пометка соединения+пометка пакетов соединения)x3x10.

Цитата:

А теперь представьте, что протоколов необходимо приоритезировать больше... А если юзеров не 10, а 100...?

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

korsakoff72RU
спасибо, но я не это имел ввиду, имелось ввиду, где и какие классы
вы будете ловить? и почему у вас global-out это вход?
у меня вход это LAN а выход global-out, а приоритет вообще ловится на
global-in и вход и выход, вот это мне не было понятно изначально...
то есть не могу увязать так как пакеты в Queue Tree ловятся везде по
разному...то есть если все разделить то понятно для меня где и что,
а вот когда все в куче, что то не как, конечно такое делать не буду но
для общего развития не помешало бы...

P.S.
и почему господин Chupaka отмалчивается? наверное опять загулял

P.P.S.
fdboss
вы вот только последний пост korsakoff72RU не слушайте, он конечно говорит все правильно
но вы сейчас зациклитесь на этом и будете пытаться это реализовать, а вам нужно все разделить,
тогда и правил будет меньше и легче управлять пользователями, не надо для каждого делать
отдельный шейпер, сделайте адресс-лист и будет все намного легче....

только не кидайте в меня кирпичами

vlh

Цитата:

и почему у вас global-out это вход?

а там все просто

eth1--global-in---global-out--eth2
eth2--global-in---global-out--eth1

или иными словами можно и in, и out для абонента нарезать хоть в global-in, хоть global-out


Цитата:

только не кидайте в меня кирпичами

как же тут не кидать и причем здесь вообще адрес-лист

Есть вопрос про странное поведение DHCP.
Имеется микротик с настроенным DHCP и TFTP сервером. Загрузка клиентов осуществляется из образов emb xp и линукса. Отдача адреса клиенту происходит идеально, а вот с отдачей параметров есть вопросы. Почти всё время в конце имени строки с именем образа для загрузки появляются какие-то левые символы, из за этого пришлось поднимать на винде сервер удалённой загрузки, который ложит на всё что не относится к латинской раскладке. Естественно, что если виндовый сервер не доступен то загрузка осуществляется с ближайшего tftp — микротиковского.
Вот пример кусочка сегодняшнего лога (естественно имя параметра «файл для загрузки» — «startrom.n12», без «я» на конце):



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

PS: Уже проверил на версиях от 3.13 до 3.30, поведение одинаковое.

BigElectricCat
сейчас у себя протестирую.

vlh

Цитата:

но я не это имел ввиду, имелось ввиду, где и какие классы
вы будете ловить? и почему у вас global-out это вход?

Какие ещё классы ловить? Классы у нас в Queue Tree сидят как пришпиленные, держась каждый за своего родителя. Зачем их ловить?
Я исходил из наиболее распространённой ситуации - наличие NAT/Маскарадинга на внешнем интерфейсе. Исходя из этого и из того, что метим сразу непосредственно пакеты без предварительной разметки соединений, возможность поставить очередь для входящего клиентского трафика в global-in отсутствует, т.к. для этого нужно метить пакеты в prerouting'е, но у всех входящих клиентских пакетов, валящихся на внешний интерфейс роутера в prerouting'е в качестве dst-address значится IP внешнего интерфейса роутера. Поэтому нет возможности разметить в прероутинге входящий клиентский трафик по отдельным клиентам, т.к. реальный локальный адрес назначения неизвестен, следовательно бессмысленно создавать очередь входящего клиентского трафика в global-in. Вот поэтому разместил очередь в global-out, с тем же успехом её можно разместить на локальном интерфейсе, а трафик можно метить хоть в форварде, хоть в построутинге. Если бы NAT отсутствовал, то можно входящие пакеты метить и в прероутинге, и ставить в очередь в global-in.


Цитата:

вы вот только последний пост korsakoff72RU не слушайте, он конечно говорит все правильно

Вот же ж... Я вообще-то это вам писал в ответ на вашу просьбу в качестве иллюстрации, но ни как не в качестве руководства к действию.

Цитата:

korsakoff72RU
Я исходил из наиболее распространённой ситуации - наличие NAT/Маскарадинга на внешнем интерфейсе. Исходя из этого и из того, что метим сразу непосредственно пакеты без предварительной разметки соединений, возможность поставить очередь для входящего клиентского трафика в global-in отсутствует, т.к. для этого нужно метить пакеты в prerouting'е, но у всех входящих клиентских пакетов, валящихся на внешний интерфейс роутера в prerouting'е в качестве dst-address значится IP внешнего интерфейса роутера. Поэтому нет возможности разметить в прероутинге входящий клиентский трафик по отдельным клиентам, т.к. реальный локальный адрес назначения неизвестен, следовательно бессмысленно создавать очередь входящего клиентского трафика в global-in. Вот поэтому разместил очередь в global-out, с тем же успехом её можно разместить на локальном интерфейсе, а трафик можно метить хоть в форварде, хоть в построутинге. Если бы NAT отсутствовал, то можно входящие пакеты метить и в прероутинге, и ставить в очередь в global-in.

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


Цитата:

fdboss и причем здесь вообще адрес-лист

при том что это намного упрощает настройку вашей проблемы...
так как вы пытаетесь каждому клиенту сделать отдельный шейпер в Queue Tree
с одинаковым значением 128кбит\с, это можно сделать всего двумя правилами
на вход и двумя на выход, хоть для 10 клиентов хоть для 100, в вашем же варианте без использования адресс-листа ,будет 200 правил для 100 клиентов. Для вашего варианта в Queue Tree для приорите трафика я бы сделал всего 8 правил и 4 для нарезки скорости..
или я что то не понимаю чего вы хотите сделать....

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