» MikroTik RouterOS (часть 3)

Цитата:

правила prerouting для QoS в мангле должны стоять перед этими правилами или после правил для роутинга?

поскольку в правилах маркировки passthrough=no - то все последующие правила работать не будут. поэтому эти должны быть последними

дальше - да, в prerouting ещё неизвестно, куда пойдёт пакет, поэтому использовать out-interface невозможно. но, по всей видимости, имелось в виду in-interface=Lan, а не out-interface=Lan


Цитата:

max-limit=0 в правилах где указываем приоритет нужно выставить ширину канала

именно так. 6М (-5-10%, для того, чтобы не забивать канал под завязку). limit-at можно выставить для важного трафика, можно оставить нулевым, по идее

Chupaka
Подскажите, если не трудно, как правильно промаркировать трафик на исходящий\входящий для шейпера.
Интерфейсы:
ether1 - смотри на adsl modem, канал 4\0,5 мбит\с
ether2 - локальная сеть
pppое соединение поднимается на микротике.
Задача:
Приотизировать http и p2p на каждого пользователя, в том числе по исходящей\входящей скорости.( К примеру http limit-at 64K\512K, max-limit 512K\4096K priority 1; limit-at 0\0 max-limit 512K\4096K p2p priority 8)
Если можно пару строчек рабочего конфига для магла и шейпера, буду очень благодарен.

Уважаемые прошу есть ли у кого то рабочий конфиг по приоритету всего остального над torrent трафиком. Кто нибудь делал для дома чтобы не щелкать постоянно в клиенте ограничить скорость скачивания, для того чтобы сайты посмотреть. Мануалы читал и пробовал делать но результат не удовлетворил. Последнее что делал rate limit но не устраивает то что канал ночью с 2-х увеличивается до 10 Мбит.

Chupaka
Цитата:

поскольку в правилах маркировки passthrough=no - то все последующие правила работать не будут. поэтому эти должны быть последними

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

Код: add action=mark-routing chain=prerouting comment=\
"Mark routing for Unlimit 4096" disabled=no new-routing-mark=Unlim_4096 \
passthrough=no src-address-list=10.Unlimit-4096
add action=mark-packet chain=prerouting comment=www disabled=no new-packet-mark=www_in passthrough=no protocol=tcp src-port=80
add action=mark-packet chain=prerouting comment="" disabled=no dst-port=80 new-packet-mark=www_out passthrough=no protocol=tcp
add action=mark-packet chain=prerouting comment=other disabled=no new-packet-mark=in_other In.interface=PPPoE passthrough=no
add action=mark-packet chain=prerouting comment=other disabled=no new-packet-mark=out_other In.interface=Lan passthrough=no
add action=mark-packet chain=forward comment="" disabled=no dst-address-list=\
10.Unlimit-4096 in-interface=pppoe new-packet-mark=4096_In_Dom \
passthrough=nо
add action=mark-packet chain=forward comment="" disabled=no in-interface=ether4 \
new-packet-mark=4096_Out passthrough=no src-address-list=10.Unlimit-4096

Помогите разобраться с отваливающимся PPTP-клиентом.

Предистория: после 2 месяцев стабильной работы Mikrotik RB750G перестало работать PPTP-client соединение.


Код: Jan/01/2002 04:23:54    pptp ppp info    pptp-out1: authenticated
Jan/01/2002 04:23:54    pptp ppp info    pptp-out1: connected
Jan/01/2002 04:25:22    pptp ppp info    pptp-out1: terminating... - keepalives timed out
Jan/01/2002 04:25:23    pptp ppp info    pptp-out1: disconnected
Jan/01/2002 04:25:23    pptp ppp info    pptp-out1: initializing...
Jan/01/2002 04:25:23    pptp ppp info    pptp-out1: dialing...
Jan/01/2002 04:25:24    pptp ppp info    pptp-out 1: terminating...
Jan/01/2002 04:25:24    pptp ppp info    pptp-out1: disconnected
Jan/01/2002 04:25:24    pptp ppp info    pptp-out 1: initializing...
Jan/01/2002 04:25:24    pptp ppp info    pptp-out 1: dialing...
Jan/01/2002 04:25:26    pptp ppp info    pptp-out 1: terminating...
Jan/01/2002 04:25:26    pptp ppp info    pptp-out 1: disconnected
Jan/01/2002 04:25:26    pptp ppp info    pptp-out 1: initializing...
Jan/01/2002 04:25:26    pptp ppp info    pptp-out 1: dialing...
Jan/01/2002 04:25:29    pptp ppp info    pptp-out 1: authenticated
Jan/01/2002 04:25:30    pptp ppp info    pptp-out 1: connected

vlh
начнём с малого...
по поводу порядка правил: смотрим на диаграмму Packet_Flow и понимаем, что в пределах каждого блока происходит только то, что написано внутри. это к тому, что если что-то пометить в prerouting, а потом двумя правилами ниже в том же прероутинге сменить метку на другую - то первая метка уже потеряна безразвратно, и никак нельзя надеяться, что шейпер отработает между этими двумя правилами. т.е. пакет попал в Mangle Prerouting, там чё-то происходит - и на выходе мы имеем пакет, который как-то помечен. дальше он уже попадает в шейпер.

конкретно по последнему посту: первым стоит правило, которое метит роутинг - это хорошо. но оно имеет passthrough=no, а это значит, что дальнейшие правила не отрабатываются. т.о. все пакеты с src-address-list=10.Unlimit-4096 попадают в global-in непомеченными

итого: неважно, в каком порядке идут правила. главное - чтобы они друг другу не мешали на выходе из Mangle Prerouting получить правильно отмаркированный пакет


Цитата:

кто то очень много качает по UDP и забивает весь канал этим трафиком

обратимся к истории это самое худшее, что может быть - когда из провайдера на нас валится UDP под плешку. потому что в этом случае провайдер самостоятельно решает, какие пакеты втиснуть с его стороны в отданный нам канал, а какие отбросить. в http://wiki.mikrotik.com/wiki/NetworkPro_on_Quality_of_Service#The_TCP_Window как раз и описывается, что происходит с TCP при "переполнении" канала (congestion control). а наша задача - как раз шейпером создать видимость этого самого congestion для пользователя, путём задерживания и дропанья некоторых пакетов

erne
а пинг на vpn-сервер после подключения сохраняется? перестало работать на ровном месте, никакого изменения конфигурации не было?..

Chupaka
да, пинг на vpn-сервер пропадает.
Никаких изменений конфигурации не было.

Chupaka
Цитата:

начнём с малого...
по поводу порядка правил: смотрим на диаграмму Packet_Flow и понимаем, что в пределах каждого блока происходит только то, что написано внутри. это к тому, что если что-то пометить в prerouting, а потом двумя правилами ниже в том же прероутинге сменить метку на другую - то первая метка уже потеряна безразвратно, и никак нельзя надеяться, что шейпер отработает между этими двумя правилами. т.е. пакет попал в Mangle Prerouting, там чё-то происходит - и на выходе мы имеем пакет, который как-то помечен. дальше он уже попадает в шейпер.

конкретно по последнему посту: первым стоит правило, которое метит роутинг - это хорошо. но оно имеет passthrough=no, а это значит, что дальнейшие правила не отрабатываются. т.о. все пакеты с src-address-list=10.Unlimit-4096 попадают в global-in непомеченными

вроде начинает прояснятся...
ты говоришь, что не важно как стоят правила в Мангле, но ведь они отрабатываются сверху вниз и вот думаю что еще теперь надо разобраться с passthrough=no, ты пишешь, что после того как я пометил пакеты группы 10.Unlimit-4096 для роутинга и поставил passthrough=no то они попадут в global-in не помеченными, но мне же и не нужен global-in я же этим правилом мечу для роутинга, а не для шейпера и что бы одна метка не помешала другой поэтому и ставлю passthrough=no так меня научили.....и что теперь получается, если в Prerouting пометить пакеты для Васи Пупкина, а дальше в том же Prerouting метим пакеты для Оли Залетаевой, то что пакеты для Васи будут перемечены? наверное нет, а иначе в Мангле наверное можно было бы сделать всего несколько правил, вот я и думал что passthrough=no как раз и не дает следующему правилу помешать первому....
теперь я так понимаю это все не так и все правила которые у меня созданы работают не правильно....
можно по подробнее про passthrough=no как его ставить?
например: пометил пакеты для группы 10.Unlimit-4096 в Prerouting для роутинга и если дальше в Мангле я с этой группой еще что нибудь делаю например мечу для шейпера в форварде то мне нужно ставить в passthrough=yes?
или еще в форварде мечу пакеты для этой группы на входящий трафик, а ниже на исходящий, то что мне в правиле на входящий трафик тоже ставить passthrough=yes?
объясни мне это для понимания вопроса....

Доброго времени суток!!!

Вот, собсна, решил выложить свой "шейпер" на Ваш суд

Может кому пригодиться как руководство...
А вообще может кто и дополнит, или поправит (хотелось бы увидеть дополнения)



Добавлено:
vlh

Цитата:

passthrough=yes?

Передать пакеты для дальнейшей обработки....

Добавлено:

Цитата:

passthrough=no

изять пакеты...

Добавлено:
erne

Цитата:

Помогите разобраться с отваливающимся PPTP-клиентом.

Предистория: после 2 месяцев стабильной работы Mikrotik RB750G перестало работать PPTP-client соединение

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

hatny
Цитата:

Передать пакеты для дальнейшей обработки....

то есть значит если я например хочу группу направить на один из внешних интерфейсов,
и больше с ней ни чего не делать, то надо ставить NO, а если я еще например хочу ограничить скорость для этой группы или еще что, то надо ставить YES?
если это так, значит двигаемся дальше, теперь форвард, если я пометил пакеты
для группы на вход In.interface=PPPoE для шейпера а потом на выход In.interface=Lan
и дальше с этими пакетами в Мангле больше ни чего не делаем, то во втором правиле на выход ставим NO это понятно, а вот в первом на вход, наверное тоже NO потому что с пакетами на вход вроде все уже закончилось или нет?

vlh

Цитата:

то есть значит если я например хочу группу направить на один из внешних интерфейсов,
и больше с ней ни чего не делать, то надо ставить NO, а если я еще например хочу ограничить скорость для этой группы или еще что, то надо ставить YES?
если это так, значит двигаемся дальше, теперь форвард, если я пометил пакеты
для группы на вход In.interface=PPPoE для шейпера а потом на выход In.interface=Lan
и дальше с этими пакетами в Мангле больше ни чего не делаем, то во втором правиле на выход ставим NO это понятно, а вот в первом на вход, наверное тоже NO потому что с пакетами на вход вроде все уже закончилось или нет?

YES- передаеш для дальнейшей маркировки...
NO- изымаеш пакеты из разметки...

изымаешь из разметки, то есть если NO пакеты вообще ни куда не попадают?
сразу на выход?
или они выходят из Мангл, а дальше в шейпер....

Цитата:

изымаешь из разметки, то есть если NO пакеты вообще ни куда не попадают?
сразу на выход?
или они выходят из Мангл, а дальше в шейпер....

далше в шейпер...

Добавлено:
vlh
Предпочитаю экомить людям время, выложив конфиг, для реального анализа, а уж потом, просить совета или помощи...
Экстрасэнсы - сами понимаете где....

hatny
а можно чуть подробнее, особенно про время активной сессии?

erne

Цитата:

а можно чуть подробнее, особенно про время активной сессии?

Ну, блин, как малые дети...
В профиле, лимит - окончание сессии через сколько часов, минут, секунд...
задаецца время - через которое разорвется соединение клиента...

hatny
Цитата:

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

таких правил столько сколько групп:

Код: add action=mark-routing chain=prerouting comment="Mark routing for Limit 01" disabled=\
no new-routing-mark=Limit_01 passthrough=yes src-address-list=01.Limit

vlh
Не вижу маркировки пакетов, а только роуты...

Добавлено:
vlh
посмотри на предыдущей странице выложенный мною вариант (рабочая часть)
может почерпнеш для себя...

Добавлено:
vlh

Цитата:

далее MSS:

Код:add action=change-mss chain=forward comment="" disabled=no new-mss=1380 protocol=tcp \
tcp-flags=syn tcp-mss=1381-6553

Я делал так:

Код: / ip firewall mangle
add chain=forward in-interface=inet_1 protocol=tcp tcp-flags=syn \
action=change-mss new-mss=clamp-to-pmtu comment="" disabled=no
add chain=forward out-interface=inet_1 protocol=tcp tcp-flags=syn \
action=change-mss new-mss=clamp-to-pmtu comment="" disabled=no

hatny
Цитата:

Не вижу маркировки пакетов, а только роуты...

а в форфарде это что по твоему?

Цитата:

пинг на vpn-сервер пропадает

прописать статикой маршрут на VPN-сервер через шлюз локальной сети, чтобы пакеты тоннеля не лезли в сам тоннель

vlh
у пакета есть две независимые метки - метка пакета и метка роутинга. поэтому для начала надо определиться, что мы хотим получить на выходе Mangle Prerouting. а дальше уже составлять правила, учитывая, что они проверяются последовательно сверху вниз, и если очередное правило, например, срабатывает и маркирует роутинг, то проверяется значение passthrough. если оно yes, то к пакету применяется метка - и правила просматриваюся дальше (где может быть добавлена ещё и метка пакета). если no - то пакет в текущем состоянии выбрасывается из Mangle Prerouting и идёт дальше по Packet Flow

Chupaka
теперь вроде понятно, идем дальше...
значит пометили пакеты в прероутинге, далее если мне больше в прероутинге
ничего делать с ними не нужно то ставим NO, и пакет пошел дальше по цепочки,
а теперь мой случай, у меня для шейпера промаркировано в форварде, а что для шейпера
можно и в прероутинге маркировать? и это более грамотнее...?

Цитата:

у меня для шейпера промаркировано в форварде а что для шейпера
можно и прероутинге маркировать?

аргх!.. повторяю ещё раз конечную цель:

- маркируем в прероутинге типы трафика;
- шейпим их в глобал-ин;
- маркируем (перемаркировываем) в форварде/построутинге тарифы пользователей;
- шейпим их в global-out/interface;

Chupaka

Цитата:

описать статикой маршрут на VPN-сервер через шлюз локальной сети, чтобы пакеты тоннеля не лезли в сам тоннель

Если так (vpn-сервер: 10.10.10.13; шлюз: 10.2.16.254)

Код: /ip route add dst-address=10.10.10.13 gateway=10.2.16.254

Подскажите, можно ли MikroTik заставить работать с Wi-Fi адаптером NETGEAR wg311v3 ?

Цитата:

идею я то понял
Но знать бы что за профиль и где задается этот самый лимит.

ppp profile а дальше в используемом тобой профиле есть вкладка Limits в ней
Session Timeout.

erne
фигня какая-то... т.е. в свойствах пптп-подключения указан адрес сервера 10.10.10.13, и потом тот же адрес получается в тоннеле?..


Цитата:

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

о чём я и говорю: в активном правиле шлюзом является пптп-подключение, поэтому пакеты тоннеля уходят в тоннель, круг замкнулся

Chupaka

Код: - маркируем в прероутинге типы трафика;
- шейпим их в глобал-ин;
- маркируем (перемаркировываем) в форварде/построутинге тарифы пользователей;
- шейпим их в global-out/interface;

Цитата:

но что нельзя все метить в форварде?

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

Mikrotik 750.
C недавнего времени начал держать соединения в состоянии established с таймаутом 24 часа.
Причём он запоминает открытые сокеты и держит их открытыми эти же 24 часа, закрывать получается только вручную.
А так как коннектов открыто много, то через некоторое время сеть начинает жутко тормозить.
В фильтрах ничего нет. Загрузка по портам минимальна.
В чём может быть проблема?

Нужна консультация, правильно ли функционирует RB493AH.
(базовая конфигурация ether1 имеет ip 192.168.88.1/24)
1.    Назначаю ip address на интерфейсе ether2 192.168.0.1/24
2.    к ether2 подключаю pc с ip 192.168.0.2

PC не пингает 192.168.0.1 и роутер не пингает 192.168.0.2

Порт ether1 функционирует как положено.( и в бридже с вланом, и как транковый)

Порты ether2-9 работают только как тупой свичь (если выставить ether2 мастером для ether8-9), то PC подключены в эти порты, друг друга видят.

Если мастером не назначать порт а сделать через бридж, то PC не видят друг друга.
int bri add
int bri port add bridge=bridge1 inter=ether2
int bri port add bridge=bridge1 inter=ether3
…………..
int bri port add bridge=bridge1 inter=ether9

есть у кого идеи?

lexsi
у ether2 не выставлен мастер-порт? а если проверить arp-ping?

в случае бриджа - появляются ли маки в хостсах?