[Saab95]

Вообще можно деревья не использовать, а забивать все в simple queues - там же делая приоритеты по группам.

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

[parazit74]

Может одновременно двух меток и не может быть в пакете, но в данном случае они не нужны:

 

по цепочке движения трафа (в мануале к микротику на картинках показано):

 

в Прероутинге - маркируем для QoS - далее пакет обработался в Global-in далее в Форвардинге промаркировался для Limitation и обработался в interface-out.

 

_____

Хотя интересно - как на уровне пакета маркировка происходит - какое поле IP заголовка (или не IP) - хранит значение метки, могут быть две метки одновременно?

может вы и правы, хотя HTB стоит почти самый последний, но наверное все же после отработки в global-in метка пропадает

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

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

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

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

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

но это лучше чем вообще без этого QoS и PCQ....

если бы не этот тик, даже и не знаю как бы сейчас у меня работал весь этот зоопарк...наверно ни как :))

 

Такой вопрос можете привести тогда сюда правила от метки до выставления приоритетов? хотя бы на примере двух типовв трафика.

 

У меня на данный момент реализовано следующим образом:

 

 0  ;;; P2P-Download
     chain=prerouting action=mark-packet new-packet-mark=p2p-download 
     passthrough=yes p2p=all-p2p 

1  ;;; http-download (port80)
     chain=prerouting action=mark-packet new-packet-mark=http-download 
     passthrough=yes protocol=tcp dst-port=80 connection-bytes=500000-0 

2  ;;; http-requests
     chain=prerouting action=mark-packet new-packet-mark=http-requests 
     passthrough=yes protocol=tcp dst-port=80 connection-bytes=0-500000 

3  ;;; Mails
     chain=prerouting action=mark-packet new-packet-mark=mails 
     passthrough=yes protocol=tcp dst-port=110,995,143,993,25

 

это правила маркировки пакетов (часть правил).

 

Вот правила находящиеся в /queue tree для приоритезации данного трафика:

 

10   name="P2P-Download" parent=global-in packet-mark=p2p-download limit-at=0 
     queue=default priority=8 max-limit=0 burst-limit=0 burst-threshold=0 
     burst-time=0s 

11   name="Http-downloads" parent=global-in packet-mark=http-download 
     limit-at=0 queue=default priority=7 max-limit=0 burst-limit=0 
     burst-threshold=0 burst-time=0s 

12   name="Http-requeusts" parent=global-in packet-mark=http-requests 
     limit-at=0 queue=default priority=1 max-limit=0 burst-limit=0 
     burst-threshold=0 burst-time=0s 

13   name="Mails" parent=global-in packet-mark=mails limit-at=0 queue=default 
     priority=7 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s

 

В Simple queues у меня находятся сами пользователи имеющие тот или иной тариф. Туда они попадают с помощью биллинг системы. Pcq не трогаю вообще.

 

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

Выложите ваши правила, думаю народу яснее станет...

 

 

 

[Saab95]

А вы и не увидите ничего.

Проблема в том, что при использовании очередей отличных от PCQ для каждого клиента создается только одна очередь, поэтому балансировка толком и не работает. Ведь балансировать-то щейпер может только поток от клиента, а если поток один - в нем все и идет=)

 

Если вы везде поставите очереди PCQ, сделаете не 50, а 500 грубину очереди для каждого потока, и 100000 общих - сразу заметите разницу. Дропов пакетов не будет, балансировка сразу заработает. В PCQ надо ставить классификацию по DST, SRC и порту.

 

Как раз все это подробно и расписано в wiki.

[parazit74]

Но получается PCQ создается для так называемых тарифов... а у меня уже получается в simple queues эти пользователи появляются динамичкски с указанными ограничениями по скорости. Как это все можно привязать?

 

Либо приходит в голову такая хрень:

 

Создаю PCQ_download и PCQ_Upload с максимальными для интернет канала значениями. Не зависящими с теми что находятся уже у пользователей в Simple queues, и выставляю эти pcq в queue tree где указываю приоритеты трафика.

Но возникает вопрос не будет ли это все пересекаться...стоит ли вообще городить это все, если изначально это провальная идея.

[Saab95]

Почему провальная?

 

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

Далее он качает какой-нито большой архив с FTP.

И смотрит веб странички.

 

Если у него стоит ограничение допустим 1м и вы порезали так, что веб на первом месте, на втором FTP и все остальное потом.

 

Если использовать обычные очереди, то для него создастся всего 3, одна для веб, одна для FTP, другая для всего остального. Шейпится они будут независимо от соединений внутри их.

 

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

 

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

 

Ведь у вас получается 2 типа ограничений - 1 это ограничения тарифных планов, а второе это ваш канал в интернет, которого на всех в часы пик не хватает и нужно что-то дропать, чтобы клиенты не жаловались. Поэтому ничего мешать друг другу не будет. Ведь второе правило будет выставлятся на интерфейс канала в интернет.

[parazit74]

осталось теперь придумать как через биллинг зафигачить туда PCQ((((

[Saab95]

осталось теперь придумать как через биллинг зафигачить туда PCQ((((

Нет ничего проще=)

 

[martini]

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

[parazit74]

осталось теперь придумать как через биллинг зафигачить туда PCQ((((

Нет ничего проще=)

 

 

а хватит одного PCQ? выше речь шла о входящем и исходящем. Но все равно спасибо...нада бы испробовать

[Saab95]

Вот прочитайте вдумчиво вот это сообщение - http://forum.nag.ru/forum/index.php?showto...st&p=569715

 

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

[47~GrAnd~74]

Доброго всем времени.

Нужно сказать очень волнующая тема затронута. Но вот и тут есть некоторая недосказанность.

У меня вопрос такой - как быть если внешних каналов два (допустим 50 и 10 Мбит/сек) и кроме настройки приоритезации трафика и шейперов, нужно еще и клиентов согласно адресных листов раскидать по каналам (балансировка меня не интересует группы пользователей жестко привязаны к своим внешним интерфейсам).

В данный момент Микротик использую просто как маршрутник, в прероуте ставлю метки mark-route в соответствии с классификатором - адресной группой пользователей согласно тарифа, далее прописываю маршруты и src-nat. Все согласно этого мануала http://wiki.mikrotik.com/wiki/Load_Balanci...ltiple_Gateways

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

Сенсеи и гуру прошу дайте совет.

[47~GrAnd~74]

Что ни у кого нет мыслей? Скажите хотя бы просто можно или нет на одном PCroute сделать маршрутизацию между двумя WAN интерфейсами, настроить приоритезацию и шейпер?

[sherwood]

Что ни у кого нет мыслей? Скажите хотя бы просто можно или нет на одном PCroute сделать маршрутизацию между двумя WAN интерфейсами, настроить приоритезацию и шейпер?

да, можно, в данный момент имеется 4 внешних канала, клиенты раскиданы по всем каналам (так как балансировка не интересует),

на каждом канале настроен приоритет трафика QoS (для 9-ти типов трафика) и настроен шейпер PCQ для 6 типов скоростей....

и все это на RB450G....

[Saab95]

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

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

[47~GrAnd~74]

Хотелось бы перейти от общего к частному.

В данный момент пытаюсь сконфигурировать следующим образом:

 

/ip firewall mangle

 

chain=prerouting action=mark-routing new-routing-mark=MR_Test passthrough=yes src-address-list=Test

chain=prerouting action=mark-connection new-connection-mark=MC_Test passthrough=yes p2p=!all-p2p protocol=tcp routing-mark=MR_Test \

...\src-port=1024-65535 dst-port=80

chain=prerouting action=mark-packet new-packet-mark=MP_Test passthrough=no protocol=tcp connection-mark=MC_Test

...

chain=forward action=mark-connection new-connection-mark=MC_Test_1 passthrough=yes src-address-list=Test

chain=forward action=mark-packet new-packet-mark=MP_Test_1 passthrough=no connection-mark=MC_Test_1

 

/ip firewall nat

chain=srcnat action=src-nat to-address=80.*.*.190 routing-mark=MR_Test out-interface=WAN_1

 

/route list

...

AS destination=0.0.0.0/0 gateway=217.*.*.*8 interface=WAN_1 distance=1 routing-mark=MR_Test

...

/queue tree

name="Global_QoS" parent=global-in packet-mark="" limit-at=0 queue=default priority=8 max-limit=50000000 burst-limit=0 burst-threshold=0 burst-time=0s

name="Test_http" parent=Global-QoS packet-mark=MP_Test limit-at=0 queue=default priority=1 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s

name="Global_Shape" parent=global-total packet-mark="" limit-at=0 queue=default priority=8 max-limit=50000000 burst-limit=0 burst-threshold=0 burst-time=0s

name="Shape_Test" parent=Global-Shape packet-mark="MP_Test_1" limit-at=5000000 queue=Test_Down priority=8 max-limit=20000000 burst-limit=0 burst-threshold=0 burst-time=0s

 

Если на словах, то делаю так - для тестовой группы Test метим пакеты в цепочке prerouting действием mark-routing, далее метим соединения и пакеты для http трафика указанной группы. По меткам MR_Test строим маршрутизацию этой группы в первый внешний интерфейс и НАТим. По меткам http трафика организуем приоритезацию в дереве очередей (даю наивысший приоритет).

Далее в цепочке forward снова метим соединения группы Test и далее пакеты. В дереве очередей настраиваю ограничения полосы для группы (клиенты ограничены рэйтом в pcq-type под именем Test_Down).

 

Во всем этом смущает следующее:

1.Типов трафика, которым нужно назначить приоритеты, достаточно много. По приведенному варианту я должен прописать цепочки каждой группе, причем цепочки будут одинаковые. Не пойму как бы вообще весь трафик (для всех групп, а не по отдельности каждой) приоритезировать в цепочке prerouting и одновременно маршруты группам прописать. Может есть иной вариант.

2.Шейпер трафика для каждой группы находится в global-total, не понятно для каждого внешнего интерфейса он свой или общий. Т.е. мне прописывать два корня дерева с max-limit 50Мбит и 10Мбит, или будет один, но на 60Мбит?

3.В некоторых источниках говорят, что очереди не работают если не прописаны limit-at и max-limit. В моем примере в дереве Global_QoS я их не прописал, т.к. в других источника видел примеры где все стоит в нулях. Как быть?

 

И вообще, sherwood, может приведешь в качестве примера свой конфиг? Сразу бы все ясно стало))).

[sherwood]

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

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

принцип такой: сначала делаем метку пакетам каждой группы для ротинга.

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

далее метим пакеты каждой группы для шейпера.

потом queue types создаем правила для нарезки скорости группам.

ну и queue tree делаем дерево для приоритета трафика и дерево для шейпера.

NAT делается очень просто , что вы там огород нагородили:

chain=srcnat action=masquerade src-address-list=Test 
out-interface=WAN_1

у вас какая версия OS? что как то руты прописаны, можно так:

add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=WAN_1
routing-mark=MR_Test scope=30 target-scope=10

шейпер и приоритет трафика QoS не будет работать без указания Max-limit и Limit-at, там где вы

прочитали что работает либо вы не поняли для чего это либо там не рабочий конфиг...

шейпер и приоритет нужно делать для каждого канала свой.

если хватает мощности роутера метьте пакеты а не соединения...

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

куда эффективнее для вас...

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

на свой канал. Например по 18 правил для приоритета трафика на каждый канал, и это уже с учетом

входящего и исходящего (количество правил не зависит от количества групп). Опять же если группы две

то в форварде будет 4 правила для шейпера (по два правила на группу). два правила для NAT.

queu types если обе группы имеют одинаковую скорость то правил будет всего два, то есть для каждой

скорости нужно два правила. ну и queue tree первое дерево для приоритета трафика, правил будет

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

тогда придется делать дерево и количество правил * 2 и + 2 для корня дерева, и это для каждого канала и

групп которые через него ходят....

вообщем писал дольше чем поднять этот конфиг :)

Изменено 28 января, 2011 пользователем sherwood

[47~GrAnd~74]

если хватает мощности роутера метьте пакеты а не соединения...

в чем преимущество маркировки сразу пакетов по сравнению с методом маркировки сначала соединений, а потом пакетов?

И тут - http://mum.mikrotik.com/presentations/US09/megis_qos.pdf, и тут - http://wiki.mikrotik.com/wiki/Russian/%D0%...%D0%B0_Mikrotik везде маркируют сначала соединение. Ни где не нашел объяснение в чем выигрышь, кроме как в количестве правил, ну и как сильно жрет ресурсы маркировка пакетов сразу, по сравнению с традиционным методом. Не получится так, что я набью правил удаленно и получу полный даун маршрутизатора? Пользователи на лоскутки порежут)))...

 

[sherwood]

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

какое количество пользователей и какие скорости гоняете по внешним каналам?

вот одно из правил которое маркирует тип трафика:

add action=mark-packet chain=prerouting comment="uTP unlimit" disabled=no \
    in-interface=LAN layer7-protocol="\B5TP" new-packet-mark=uTP_unlimit_out \
    passthrough=no protocol=udp src-address-list=(PCQ_Limit)
add action=mark-packet chain=prerouting comment="" disabled=no in-interface=\
    PABLIC_4 layer7-protocol="\B5TP" new-packet-mark=uTP_unlimit_in \
    passthrough=no protocol=udp

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

add action=mark-packet chain=forward comment=limit disabled=no in-interface=\
    LAN new-packet-mark=packet_limit_out passthrough=no src-address-list=\
    "(PCQ_Limit)"
add action=mark-packet chain=forward comment="" disabled=no dst-address-list=\
    "(PCQ_Limit)" in-interface=PABLIC_4 new-packet-mark=packet_limit_in \
    passthrough=no

дерзайте...

[47~GrAnd~74]

какое количество пользователей и какие скорости гоняете по внешним каналам?

Есть локалка, на 1000 хостов (реально их меньше ~650). До недавнего времени использовали в качестве шлюза Трафик Инспектор. Конечно о качестве сего продукта можно говорить много, но бюджет фирмы невелик, поэтому имеем это. Но вот в последний месяц получили некоторый наплыв пользователей и наш основной канал в 45Мбит/с. уже стал маловат. Обратились к прову, у них та же проблема - магистраль забита. Смогли окольными путями выбить второй порт с линком 10Мбит/с. Но маршрутизацию Трафик Инспектор из под винды, естественно, не реализует. Про Микротик еще два месяца назад ничего и не слыхал. Вот такая предыстория. Организовали доступ следующим образом: для клиентов шлюзом так и остался сервер с Трафик Инспектором (клиентов перенастраивать не было времени и организовать очень сложно); за ТИ стоит сервер с Микротик с двумя WAN портами (45Мбит и 10Мбит). Тарифные планы в основном безлимитные от 150кбит/сек до 3Мбит/сек, самый популярный (~300 хостов) - безлим 1000кбит.

Кроме того особенность сетки такова, что с 17.00 до 23.00 полная загрузка, в остальное время канал разгружен. Поэтому и нужен QoS. Кроме того Трафик Инспектор не хвалят за его косой шейпер, поэтому хочется и его поручить Микротику. Многие, наверное, скажут что нагородил огород, но целью преследовалось минимум потрясений для пользователей, кроме того авторизацию по прежнему выполняет ТИ.

 

sherwood, если не сложно, подскажи плюсы и минусы (кроме загрузки сервака) пакетной маркировки, минуя маркировку соединений. Официальные буквари не советуют этого делать.

Спасибо за примеры, с ними намного понятнее. Но не сочти за наглость, не подскажешь как он-лайн видео промаркировать. Больно уж наши хомячки любят этим баловаться))). Где-то видел что используют layer7, тут у меня совсем туго... Вот такое нашел:

 

/ip firewall layer7-protocol

add comment="" name=OnlineVideo regexp="http/(0\\.9|1\\.0|1\\.1)[\\x09-\\x0d]\[1-5][0-9][0-9][\\x09-\\x0d-~]*(content-type:video)"

 

Вообще мрак, набор скобок и слэшей. Буду признателен.

[sherwood]

ТИ нормально работает, руки просто у некоторых кривые :)

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

на него просто не надо навешивать всего чего он не должен делать,

шейпер, роутинг, прокси, нат, всякие фильтры - это биллинг, который

тихо стоит в углу и считает трафик и денежки (к тому же и сертифицированный, что не мало важно) :)

для этого есть железные решения, и нечего мудрить, вы еще на этот сервер FTP повесьте и т.д.

одна железка - одна роль.... имхо

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

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

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

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

переходим на маркировку соединения....либо добавляем мощи :)

по поводу L7 использую это но там не все есть,

по этому рекомендую посмотреть на каких ресурсах смотрят фильмы, какой проходит трафик и добавить его в приоритет...ведь наверное их не много...

 

[47~GrAnd~74]

шейпер и приоритет трафика QoS не будет работать без указания Max-limit и Limit-at, там где вы

прочитали что работает либо вы не поняли для чего это либо там не рабочий конфиг...

шейпер и приоритет нужно делать для каждого канала свой.

Все равно каша в голове. Прошу прощения за назойливость, но вот мне не ясно какие тогда max-limit и limit-at ставить в дереве очередей для QoS'a. Хотелось бы рассмотреть на примере http трафика, хотя очень еще интересен р2р. Поскольку внутри сети нет WEB серверов, то, по-моему, нет смысла метить входящие запросы по 80-ому порту (может я не прав?). Соответственно метим вообще все запросы с портом назначения 80.

 

chain=prerouting action=mark-packet in-interface=LAN new-packet-mark=http_out passthrough=no protocol=tcp src-port=1024-65535 dst-port=80

 

Далее помеченные пакеты http-трафика направляем в дерево очередей. Тут то и вопрос. Поскольку LAN интерфейс один, а внешних два, то мах-limit ставить как сумму каналов WAN? Если делать два дерева , тогда без маркировки пакетов для каждого тарифного плана (около 15-ти) никак не сделать. А это гора правил - не очень прикольно. С limit-at вообще не понятно, количество трафика данной категории не известно и нигде вообще не видел, чтобы ставили отличное от нуля значение при изменении приоритетов. Везде в корне дерева ставят мах-limt и все остальное в нулях.

 

 

[sherwood]

Все равно каша в голове. Прошу прощения за назойливость, но вот мне не ясно какие тогда max-limit и limit-at ставить в дереве очередей для QoS'a.

для QoS

max-limit= ширина канала минус 5-15%

limit-at=тоже самое

Хотелось бы рассмотреть на примере http трафика, хотя очень еще интересен р2р. Поскольку внутри сети нет WEB серверов, то, по-моему, нет смысла метить входящие запросы по 80-ому порту (может я не прав?). Соответственно метим вообще все запросы с портом назначения 80.

а ответ на запрос пользователя на какой порт приходит? :)

это мы метим веб трафик для одного интерфейса и только чисто открытие страничек:

add action=mark-packet chain=prerouting comment="www unlimit" \
    connection-bytes=0-500000 disabled=no dst-port=80 in-interface=LAN \
    new-packet-mark=www_unlumut_out passthrough=no protocol=tcp \
    src-address-list="(PCQ_QoS_Unlim)"
add action=mark-packet chain=prerouting comment="" connection-bytes=0-500000 \
    disabled=no in-interface=PABLIC_3 new-packet-mark=www_unlimit_in \
    passthrough=no protocol=tcp src-port=80

те же правила но connection-bytes=500000-0 будут метить то что больше чем странички, то есть закачка через 80 порт, видео и т.д.

Далее помеченные пакеты http-трафика направляем в дерево очередей. Тут то и вопрос. Поскольку LAN интерфейс один, а внешних два, то мах-limit ставить как сумму каналов WAN? Если делать два дерева , тогда без маркировки пакетов для каждого тарифного плана (около 15-ти) никак не сделать. А это гора правил - не очень прикольно. С limit-at вообще не понятно, количество трафика данной категории не известно и нигде вообще не видел, чтобы ставили отличное от нуля значение при изменении приоритетов. Везде в корне дерева ставят мах-limt и все остальное в нулях.

если каналов у вас два то и дерева для QoS будет два, где max-limit и limit-at будет тот что я написал выше, то есть в вашем случае

в одном дереве будет примерно 42М а в другом 9М. общего между этими деревьями как и трафиком проходящем через них нет.

Так еще раз - max-limit это ширина вашего канала без него ROS не знает до какой величины делать очереди, limit-at это гарантированная величина

которую в любом случае получит очередь, поэтому в дереве мы ставим max-limit а в листьях max-limit и limit-at, если какому то классу нужно

выделить больше канал, то делаем limit-at больше, но сумма всех limit-at не должна превышать max-limit.

теперь о тарифных планах, если у вас на один канал идет несколько групп, то придется в адресс листе сделать группу в которую войдут

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

у меня скрипт все это берет из ТИ и загоняет в адресс-лист роутера...

[47~GrAnd~74]

у меня скрипт все это берет из ТИ и загоняет в адресс-лист роутера...

Блинннн.... Аж слюна потекла))). А ТИ какой версии. У нас 2.0.0.634 Pro, может договоримся на счет скрипта? Трафик Инспектор в режиме прослушки, я так понимаю?

 

[sherwood]

Блинннн.... Аж слюна потекла))). А ТИ какой версии. У нас 2.0.0.634 Pro, может договоримся на счет скрипта? Трафик Инспектор в режиме прослушки, я так понимаю?

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

ТИ стоит не в прослушке, а как обычный маршрутизатор, потому как оставил авторизацию агентом, без НАТ, без прокси, два интерфейса один в локалку второй на микротик....

[47~GrAnd~74]

если каналов у вас два то и дерева для QoS будет два,

а разве не четыре? WAN1 - up и down, плюс WAN2 - up и down.

 

/queue tree

name="QoS_WAN2_up" parent=global-in packet-mark="" limit-at=0 queue=default priority=8 max-limit=9500000 burst-limit=0 burst-threshold=0 burst-time=0s

name="http_up" parent=QoS_WAN2_up packet-mark=http_up_WAN2 limit-at=9500000 queue=default priority=2 max-limit=9500000 burst-limit=0 burst-threshold=0 burst-time=0s

 

name="QoS_WAN2_down" parent=global-in packet-mark="" limit-at=0 queue=default priority=8 max-limit=9500000 burst-limit=0 burst-threshold=0 burst-time=0s

name="http_down" parent=QoS_WAN2_down packet-mark=http_down_WAN2 limit-at=9500000 queue=default priority=2 max-limit=9500000 burst-limit=0 burst-threshold=0 burst-time=0s

 

Канал симметричный 10Мбит. То же самое для второго, только с другой скоростью. Адресную группу для всех тарифов на WAN2 создал и в мангле прописал. Пакеты помечены вообще все по 80-ому порту. Но вот http-video вообще смотреть невозможно, постоянно притормаживает.

Вообще-то на этом канале уже сидят пользователи. Не может быть такое непонятное поведение из-за того, что остальным группам шейпер вообще не настроен? Соответственно они рвут канал как хотят? Когда был один шлюз с ТИ все было четко, ролик выбирал положенные, допустим для Безлима-1000, 1Мбит скорости, пока ролик не заедет. Сейчас трафик у тестового пользователя гуляет вообще как хочет, до мегабита вообще дотягивает только при заливе с торрентов. Еще раз хочу сказать что шейпер сделан только для одной группы, остальные просто маршрутизируются, не в этом ли собака зарыта?