[47~GrAnd~74]

Кстати, насчет трафика с ТИ. Кажется я нашел траблу с этим паразитным трафиком с интерфейса OTN на него же. Короче при установке Микротика прописал внутренний интерфейс чтобы подрубиться Винбоксом. Получился маршрут 0.0.0.0/0 и шлюз ему внешний интерфейс ТИ, т.е. 172.30.0.2.

После этого соответственно прописал два остальных маршрута (уже через Винбокс) 0.0.0.0/0 ип шлюза первого прова и такой же но только ип второго шлюза прова. далее прописал свою внутреннюю подсеть 172.20.20.0/22 и шлюзом внешний интерфейс ТИ, но взял сдуру и заремарил его. Вот позавчера заремарил первый и разремарил последний. В логах теперь вижу в основном дропы ICMP ну и еще немного какой-то ерунды.

Вот такая ситуёвина.

Но вот мне немного не ясно следующее - ведь подсеть 172.20.20.0/22 - входит в 0.0.0.0/0 и он не может путать маршруты??? Хотя вообще-то читал в одном букваре что пакеты направляются в ту дырку, где присутствует максимальное совпадение адресов с подсетью, прописаной в маршруте. Так ведь?

 

 

[47~GrAnd~74]

Или сами со своего тестового компьютера запустите пинги пакетами 1450 куда-то в интернет и посмотрите что происходит.

 

C:\Users\Администратор>ping -l 1450 -f musicmp3.spb.ru

 

Обмен пакетами с musicmp3.spb.ru [78.159.122.193] с 1450 байтами данных:

Ответ от 78.159.122.193: число байт=1450 время=105мс TTL=55

Ответ от 78.159.122.193: число байт=1450 время=101мс TTL=55

Ответ от 78.159.122.193: число байт=1450 время=100мс TTL=55

Ответ от 78.159.122.193: число байт=1450 время=104мс TTL=55

 

Статистика Ping для 78.159.122.193:

Пакетов: отправлено = 4, получено = 4, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 100мсек, Максимальное = 105 мсек, Среднее = 102 мсек

 

C:\Users\Администратор>ping -l 1450 -f yandex.ru

 

Обмен пакетами с yandex.ru [87.250.251.11] с 1450 байтами данных:

Ответ от 87.250.251.11: число байт=1450 время=27мс TTL=60

Ответ от 87.250.251.11: число байт=1450 время=31мс TTL=60

Ответ от 87.250.251.11: число байт=1450 время=27мс TTL=60

Ответ от 87.250.251.11: число байт=1450 время=27мс TTL=60

 

Статистика Ping для 87.250.251.11:

Пакетов: отправлено = 4, получено = 4, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 27мсек, Максимальное = 31 мсек, Среднее = 28 мсек

 

C:\Users\Администратор>ping -l 1450 -f mail.ru

 

Обмен пакетами с mail.ru [94.100.191.201] с 1450 байтами данных:

Ответ от 94.100.191.201: число байт=1450 время=31мс TTL=60

Ответ от 94.100.191.201: число байт=1450 время=29мс TTL=60

Ответ от 94.100.191.201: число байт=1450 время=28мс TTL=60

Ответ от 94.100.191.201: число байт=1450 время=32мс TTL=60

 

Статистика Ping для 94.100.191.201:

Пакетов: отправлено = 4, получено = 4, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 28мсек, Максимальное = 32 мсек, Среднее = 30 мсек

 

Вот что показывает пингтест на Ульяновский сервер

 

Изменено 18 февраля, 2011 пользователем 47~GrAnd~74

[sherwood]

да при чем тут пинг с локального компьютера?

так, авторизация у провайдера как идет, статический IP или VPN?

пинг, трассировка с самого тика на оба внешних интерфейса идет?

в лог правило что попадает?

в рутах сколько у вас статических правил и какие?

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

[47~GrAnd~74]

ну так SAAB рекомендовал я и сделал))

 

Пров статический адрес дает. С тика все норм идет.

 

в рутах три маршрута

 

[speednet@MikroTik] > ip route print

Flags: X - disabled, A - active, D - dynamic,

C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,

B - blackhole, U - unreachable, P - prohibit

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE

0 A S 0.0.0.0/0 217.*.*.158 1

1 A S 0.0.0.0/0 217.**.**.86 1

2 X S ;;; added by setup

0.0.0.0/0 172.30.0.2 1

3 A S 172.20.20.0/22 172.30.0.2 1

4 ADC 172.30.0.0/30 172.30.0.1 OTN 0

5 ADC 172.31.0.0/29 172.31.0.1 DMZ 0

6 ADC 217.*.*.156/30 217.*.*.157 TTK1 0

7 ADC 217.**.**.84/30 217.**.**.85 TTK2 0

 

2.Если на сервере с ТИ не нужен интернет, то есть нет ни каких сторонних программ DNS и т.д.,то можно заблокировать его работу с интернетом в firewall тика.

После того как это сделал в логи попадают только дропы на сам микротик по цепочке input.

 

И кстати перевел себя в основной канал ТТК1 и вроде отмечаю значительное улучшение онлайн видео, даже QoS'а пока еще нет. Еще потестю денек другой. Может у нас второй канал не совсем стабильный??

 

[sherwood]

[speednet@MikroTik] > ip route print

Flags: X - disabled, A - active, D - dynamic,

C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,

B - blackhole, U - unreachable, P - prohibit

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE

0 A S 0.0.0.0/0 217.*.*.158 1

1 A S 0.0.0.0/0 217.**.**.86 1

2 X S ;;; added by setup

0.0.0.0/0 172.30.0.2 1

3 A S 172.20.20.0/22 172.30.0.2 1

4 ADC 172.30.0.0/30 172.30.0.1 OTN 0

5 ADC 172.31.0.0/29 172.31.0.1 DMZ 0

6 ADC 217.*.*.156/30 217.*.*.157 TTK1 0

7 ADC 217.**.**.84/30 217.**.**.85 TTK2 0

что за маршруты ADC?

 

После того как это сделал в логи попадают только дропы на сам микротик по цепочке input.

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

 

И кстати перевел себя в основной канал ТТК1 и вроде отмечаю значительное улучшение онлайн видео, даже QoS'а пока еще нет. Еще потестю денек другой. Может у нас второй канал не совсем стабильный??

а QoS у вас пока не будет работать так как канал не загружен больше 100%, на этом этапе шейпер должен справляться...

ну если конечно в QoS на определенный тип трафика не зарежете max-limit ниже чем в данный момент загружен канал :)

[47~GrAnd~74]

Маршруты ADC создались автоматически после присвоения интерфейсам их IP адресов, я их руками не вбивал...

 

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

Просто нажимаю пункт меню Log, там и смотрю, когда маршрут левый был там были пакеты и из фаервола и из мангла, щас только из фаервола. Больше не знаю как их по отдельности смотреть и можно ли в принципе это сделать).

 

а QoS у вас пока не будет работать так как канал не загружен больше 100%,

Да нет, в пики под завязку...

 

Вот теперь как бы мне проверить второй канал, сколько он максимум выдаст. Может пров тоже как и мы хитрить пытается. Торрентами я загружал его на десятку, а вот второй день обращаю внимание, что ночью, когда его загрузка метра три, то серф лучше. Как только поднимается до 6-8Мбит - то заметно медленнее.

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

[sherwood]

Просто нажимаю пункт меню Log, там и смотрю, когда маршрут левый был там были пакеты и из фаервола и из мангла, щас только из фаервола. Больше не знаю как их по отдельности смотреть и можно ли в принципе это сделать).

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

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

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

и зачем резать iсmp пакеты :)

[47~GrAnd~74]

попадает в логи в основном пакеты, которые долбятся на мои белые ИП адреса, а поскольку они не как не маркируются и dst-natне по всем прописан, то вот они и попадают в логирующий маркер.

 

Но их не много

[Voronok]

Добрый день, уважаемые.

Сам я знаком с микротиком около недели, но почитав Ваши наставления (спасибо за это) и вики, многое становится понятно. Я уже почти придумал, что сделать, но есть некоторые вопросы. Позвольте поинтересоваться.

 

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

 

С1-----|ТИК1|---\                        WAN1
                 \                     /
                   \                 /
С2-----|ТИК2|------|SW|------|ТИК-BGP|
                   /                \
                 /                    \
С3-----|ТИК3|---/                       WAN2

 

На сегментных микротиках (ТИК1-3) настроен НАТ (srcnat, masquerade) и простыми очередями нарезатся скорость каждому абоненту согласно тарифа. Можно перевести на дерево очередей, но для этого надо скрипт, который будет отслеживать сколько абонентов с каким тарифом онлайн и вносить изменения в настройки PCQ. Так как большая текучка абонентов с тарифа на тариф. А как снять с микротика количество активных IP (абонентов), я еще не выяснил.

 

На пограничном микротике настроена только BGP-маршрутизация, без балансировки. Пока острой необходимости в балансировке не было, т.к. каналы заполняются равномерно.

 

Вообще, стараемся держать каналы слегка свободными, но, перед каждым расширением (как сейчас), немного выходим за рамки и начинается поток жалоб на скорость.

 

Вообщем, во многом благодаря Вам, я понял что надо делать, как я уже писал, но есть вопросы:

 

1. Хочу поднять QOS на пограничном микротике, оставив на сегментных нарезку скоростей простыми очередями. Пройдёт ли такой номер или сегментные тики нужно переводить на деревья очередей? На сегментных тиках не хочу делать QOS, так как не известен канал между сегментным и пограничным.

 

2. Очень помог пример sherwood`а, но как его адаптировать для двух внешних интерфесов? Есть 2 варианта:

а)

/queue tree


add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=20М name=qos_in_wan1 \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=20М name=icmp_in_wan1 \
    packet-mark=icmp_in_wan1 parent=qos_in priority=1 queue=default
...
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=25М name=qos_in_wan2 \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=25М name=icmp_in_wan2 \
    packet-mark=icmp_in_wan2 parent=qos_in priority=1 queue=default
...
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=qos_out \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=icmp_out \
    packet-mark=icmp_out parent=qos_out priority=1 queue=default
...

б)

/queue tree


add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45М name=qos_in \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=20М name=icmp_in_wan1 \
    packet-mark=icmp_in_wan1 parent=qos_in priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=25М name=icmp_in_wan2 \
    packet-mark=icmp_in_wan2 parent=qos_in priority=1 queue=default
...
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=qos_out \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=icmp_out \
    packet-mark=icmp_out parent=qos_out priority=1 queue=default
...

Какой правильный? Или нужно по другому?

 

3. Как быть с двумя типами трафика с одинаковым приоритетом?

Делать так:

add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=qos_out \
    parent=global-in priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=icmp_out \
    packet-mark=icmp_out parent=qos_out priority=1 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=45M name=dns_out \
    packet-mark=dns_out parent=qos_out priority=1 queue=default
...

или маркировать оба типа трафика одним маркером?

Изменено 24 февраля, 2011 пользователем Voronok

[Saab95]

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

[Voronok]

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

То есть, допустим, на трёх будет нарезка и маршрутизация, между коммутатором и пограничным поставить НАТ, на пограничном прикрутить QoS? А почему QoS не будет работать в существующей схеме?

[sherwood]

Voronok

из приведенных вами схем рабочая это первая, вторая не имеет жизни...

но и первая технически не грамотна, например такая ситуация:

с ТИК-1 клиенты забьют весь канал, то с остальных ни кто ни чего не получит...

да,и с QoS такая же ситуевина, один ТИК будет у вас потреблять какой то трафик, а другие

будут в этот момент курить....

ваша схема имела бы смысл если бы на ТИК-BGP был бы один канал...да и то вряд ли...если только

делать все на нем, тогда вопрос - для чего вообще нужны три ТИК? :)

даже не вижу решения в вашем случае, все они корявые, даже если на ТИК-BGP использовать балансировку

PCC, все равно с приоритетом трафика будет чехарда, а именно не ровно делится между ТИК-1,2,2

думаю, что у себя, я бы вместо трех ТИК поставил один, ТИК-BGP - настроил балансировку каналов РСС и NAT,

а шейпер PCQ и QoS на втором RB.

можно все это и на одном RB сделать, но с NAT теряется гибкость настройки...шейпера и QoS, да и другого....

ну или простой вариант, например ТИК1 и ТИК2 пустить на один канал, а ТИК3 на другой и соответственно

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

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

[Voronok]

sherwood, спасибо большое за ответы. :)

 

Voronok

из приведенных вами схем рабочая это первая, вторая не имеет жизни...

но и первая технически не грамотна, например такая ситуация:

Да. Это уже понял. И она, действительно, оказалась не рабочей.

 

тогда вопрос - для чего вообще нужны три ТИК? :)

Это наследие с тех времен, когда осью была фряха. Когда нагрузка стала слишком большой, поставили три НАТа/шейпера, вместо одного. Следующим шагом заменили ось на микротик, нагрузка спала. Сейчас составляет 20-30% CPU, хватает памяти. Если сейчас шейпер+нат поставить на одну машину будет больше 70%. Возможно, облегчит ситуацию применение PCQ с деревьями вместо простых очередей. Не знаю, правда, на сколько.

Потом получили автономку и прилепили спереди BGP. Нагрузка 30-40% CPU.

 

даже не вижу решения в вашем случае, все они корявые, даже если на ТИК-BGP использовать балансировку

PCC, все равно с приоритетом трафика будет чехарда, а именно не ровно делится между ТИК-1,2,3

Мне интересно. Простые очереди тоже, наверное, влияют? Кому-то нарежет сполна, а кому-то отдаст то, что останется. Я правильно думаю?

 

можно все это и на одном RB сделать, но с NAT теряется гибкость настройки...шейпера и QoS, да и другого....

Да, читал про это.

 

ну или простой вариант, например ТИК1 и ТИК2 пустить на один канал, а ТИК3 на другой и соответственно

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

Вариант простой, но... до получения автономки так и было.

 

думаю, что у себя, я бы вместо трех ТИК поставил один, ТИК-BGP - настроил балансировку каналов РСС и NAT,

а шейпер PCQ и QoS на втором RB.

Этот вариант заинтересовал. Только боюсь, потянут ли машинки? Канал 450 недавно скушали... Около 4000 онлайн, может чуть меньше.

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

 

Еще вопрос есть. В дочерних очередях max-limit указывать обязательно или можно? А то встречал и так, и эдак.

Изменено 25 февраля, 2011 пользователем Voronok

[sherwood]

Если сейчас шейпер+нат поставить на одну машину будет больше 70%. Возможно, облегчит ситуацию применение PCQ с деревьями вместо простых очередей. Не знаю, правда, на сколько.

Во первых, с таким количеством абонентов и каналом, какие простые очереди, вы о чем....?! только PCQ с деревьями...

Во вторых, при таких нагрузках шейпер с NAT не совместим из-за того, что при их совместном использовании вы не сможете

метить соединения для нейпера и QoS конечно, а только пометка пакетов, а это на порядок ресурсо-емкое занятие, в вашем

случае только пометка соединения.... поэтому одна машинка NAT, вторая шейпер....

 

Мне интересно. Простые очереди тоже, наверное, влияют? Кому-то нарежет сполна, а кому-то отдаст то, что останется. Я правильно думаю?

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

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

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

которые качают торентом и делают по 400 сессий...

 

Этот вариант заинтересовал. Только боюсь, потянут ли машинки? Канал 450 недавно скушали... Около 4000 онлайн, может чуть меньше.

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

по поводу производительности не скажу потому как нет такой нагрузки (читайте мою подпись :) ) но думаю что про RB и даже RB1100

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

до 200Мбит\с и 40к ррс, правда без NAT и шейперов совсем немного.....так что два мощных РС справятся, но повторяюсь лучше поискать

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

вариант....

 

Еще вопрос есть. В дочерних очередях max-limit указывать обязательно или можно? А то встречал и так, и эдак.

а вы попробуйте не ставить в листьях Max-limit? у мня не получается.... ругается router :)

 

[Voronok]

в вашем случае только пометка соединения....

Я читал мысль, что соединения метить не так надежно, как пакеты. Вот не знаю, правда ли это. Хотя, в официальных доках везде сперва метят соединения, потом пакеты. Я пробовал так делать. Счетчик пакетов показывает больше, если метить пакеты без соединений.

 

читайте мою подпись :)

Не вижу. Хотя, в настройках включено.

 

думаю что про RB и даже RB1100 вам нужно забыть, а собирать на основе PC

Так и делаем.

 

а вы попробуйте не ставить в листьях Max-limit? у мня не получается.... ругается router :)

Получилось. Наверное, различия в версиях. Я такую форму записи в одном примере видел. Только оно везде нули проставило. Вот я и думаю, как правильнее. Ноль - это же без ограничений? Но, по идее, за лимит родительской очереди выйти не должно.

 

Вводил так:

/queue tree
add name=TTK_test packet-mark=dns_tcp_in_ttk parent=QoS_in_TTK priority=4

Получилось так:

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=TTK_test packet-mark=dns_tcp_in_ttk parent=\
    QoS_in_TTK priority=4 queue=default

 

Спасибо за помощь. Я понял. Сведу все в кучу.

Надо, вместо трёх ТИК1-3, все сегменты завести на один тик, на нем сделать PCQ с деревьями и QoS. После тик с маскарадингом. И, на границе, к BGP добавить балансировку.

Так высоко моя мысль не взлетала. :)

 

[sherwood]

Я читал мысль, что соединения метить не так надежно, как пакеты. Вот не знаю, правда ли это. Хотя, в официальных доках везде сперва метят соединения, потом пакеты. Я пробовал так делать. Счетчик пакетов показывает больше, если метить пакеты без соединений.

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

соединение и не все пакеты в нем.

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

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

 

Не вижу. Хотя, в настройках включено.

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

 

Получилось. Наверное, различия в версиях. Я такую форму записи в одном примере видел. Только оно везде нули проставило. Вот я и думаю, как правильнее. Ноль - это же без ограничений? Но, по идее, за лимит родительской очереди выйти не должно.

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

указывать Limit-at и в этом случае не указав Max-limit вы получите ошибку, а оказалось вы имели ввиду про QoS в котором

не указывается Limit-at и поэтому не указав Max-limit правило запишется без ошибки, но в документации написано, что очередь

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

будут работать, не проверял, мне не сложно поставить этот параметр....

 

Спасибо за помощь. Я понял. Сведу все в кучу.

Надо, вместо трёх ТИК1-3, все сегменты завести на один тик, на нем сделать PCQ с деревьями и QoS. После тик с маскарадингом. И, на границе, к BGP добавить балансировку.

Так высоко моя мысль не взлетала. :)

балансировку лучше использовать РСС. и про QoS, вы наверное в курсе что работать он будет только после полной загрузки канала?

при например загрузки канала на 80% все правила QoS бес полезны, то есть они не работают.

хотя тут читал, что канал WiMax работает по другому и мне это не понятно, например есть дорога в 10 полос и по 5 из них

в рад движутся 5 авто (udp) тут появляется еще одна машина (TCP с более высоким приоритетом) и занимает 6-ю полосу, вот не

понятно почему в WiMax машина с udp должна ее пропустить? так можно дойти до того, что канал будет на 50% заполнен а udp или

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

занимать все полосы и как только все будет занято и появится машина с более высоким приоритетом (например машина чиновника с мигалкой :) )

то ей придется уступить дорогу, то есть пакет с udp пропустит пакет TCP вперед а сам будет отброшен на обочину :)

[Saab95]

В WiMax, как и в Wi-Fi с включенным WMM очереди работают по другому принципу - если есть пакеты с более высоким приоритетом, то сперва по каналу передаются они, а пакеты с низким приоритетом буферизуются, и начинают передаваться только тогда, когда пакеты с высоким приоритетом заканчиваются. Если пакетов с высоким приоритетом столько, что они занимают весь канал - то пакеты с низкими приоритетами не передаются.

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

 

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

[sherwood]

В WiMax, как и в Wi-Fi с включенным WMM очереди работают по другому принципу - если есть пакеты с более высоким приоритетом, то сперва по каналу передаются они, а пакеты с низким приоритетом буферизуются, и начинают передаваться только тогда, когда пакеты с высоким приоритетом заканчиваются. Если пакетов с высоким приоритетом столько, что они занимают весь канал - то пакеты с низкими приоритетами не передаются.

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

 

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

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

всего(!) половину канала (например) то пакеты с меньшим приоритетом будут в буфере, то есть не передаваться тогда что мы получим,

канал у нас забит на 50% а клиент который хочет что то передать пакетами с низким приоритетом будет сосать лапу... и что самое страшное

он может вообще не получить того что хочет пока первый клиент не перестанет качать пакетами с более высоким приоритетом и это все

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

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

[Saab95]

Короче по радио передается примерно так:

 

 

Сперва идут красные квадратики с высоким приоритетом, и если еще есть время для передачи - то после них идут зеленые. На качество передачи данных это никак не влияет.

 

Во втором варианте, когда скорость уменьшилась на треть, сперва идут красные квадратики, потом 2 зеленых, оставшиеся 3 будут отброшены. На качество передачи высокоприоритетного трафика ничто не влияет, низкий же приоритет потеряет часть пакетов. Они либо будут отброшены, если буферизация отключена, либо будут оставаться в буфере до момента, пока появится свободное место в канале передачи для низкоприоритетного трафика.

 

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

[sherwood]

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

а каком времени идет речь?

 

Во втором варианте, когда скорость уменьшилась на треть, сперва идут красные квадратики, потом 2 зеленых, оставшиеся 3 будут отброшены. На качество передачи высокоприоритетного трафика ничто не влияет, низкий же приоритет потеряет часть пакетов. Они либо будут отброшены, если буферизация отключена, либо будут оставаться в буфере до момента, пока появится свободное место в канале передачи для низкоприоритетного трафика.

то есть если я врублю торент по TCP (как в данный момент он у меня качает и делает 350 соединений) то все остальные наверное будут

плохо себя чувствовать даже при открытии страничек, а про трафик UDP причем не "паразитный" (закачка в один поток) можно вообще забыть?

 

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

вот про буфер немного понятно, а в Wi-Fi такой есть и можно ли как то им управлять?

[Saab95]

Время - это определенный промежуток, требуемый для передачи трафика. В шейпере же указывают к примеру 50 мегабит в секунду, или 5 мегабит в 1/10 секунды и т.д. и тут потипо того.

 

Нифига. Если гонять по TCP какие-то данные с высоким приоритетом, то они всегда пройдут через канал. А пакеты торрента, сколько бы их не было, пойдут только тогда, когда их очередь подойдет, и своим количеством они ничего забить не смогут. Или как-то повлиять на процесс передачи.

 

К примеру есть скорость канала 30 мегабит по радио. Вы качаете онлайн видео с высоким приоритетом со скоростью 10 мегабит, и торренты с низким, они занимают скорость 20 мегабит.

Теперь скорость упала до 15 мегабит, онлайн видео как качалось, так и качается, а вот торрент тормознулся до 5-ти мегабит.

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

 

Буфер это не в wi-fi, а программный. Вы же когда смотрите в разделе Queue Tree в момент полной занятости канала, там показывается сколько пакетов буферизуется и размер этого буфера можно устанавливать в нужном размере. Так же и в WMM, если низкоприоритетный трафик не может пойти в канал, он попадает в буфер, и если канал все равно занят - при переполнении буфера пакеты из него станут отбрасываться. Тем самым приложения поймут что нужно снизить скорость.

[Voronok]

sherwood, можно задать вопрос по Вашему примеру?

 

теперь PCQ:

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=10M name=pcq_in parent=\
    LAN priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=4103k max-limit=10M name=pcq_g1_in \
    packet-mark=packet_g1_in parent=pcq_in priority=8 queue=g1_in
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=3846k max-limit=10M name=pcq_g2_in \
    packet-mark=packet_g2_in parent=pcq__in priority=8 queue=g2_in
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=2051k max-limit=10M name=pcq_g3_in \
    packet-mark=packet_g3_in parent=pcq_in priority=8 queue=g3_in
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=3M name=pcq_out parent=\
    global-out priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=1600k max-limit=3M name=pcq_g1_out \
    packet-mark=packet_g1_out parent=pcq_out priority=8 queue=g1_out
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=1000k max-limit=3M name=pcq_g2_out \
    packet-mark=packet_g2_out parent=pcq_out priority=8 queue=g2_out
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=400k max-limit=3M name=pcq_g3_out \
    packet-mark=packet_g3_out parent=pcq_out priority=8 queue=g3_out

Интересует первая строчка. Не должна ли она выглядеть так:

/queue tree

add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=10M max-limit=10M name=pcq_in parent=\

LAN priority=8

У Вас в таком виде нормально работает? А то Вы говорили, что это не копипаст из конфига, а по памяти.

 

Я просто сейчас читал по НТВ и наткнулся на следущее:

*в случае, если родительская очередь является главной родительской (корневой)

очередью CIR(parent)=MIR(parent)

вот и спрашиваю.

 

Хотя, как ни странно, там же, ниже этой строчки в примере указано как у Вас, linit-at=0.

Изменено 5 марта, 2011 пользователем Voronok

[sherwood]

Интересует первая строчка. Не должна ли она выглядеть так:

/queue tree

add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=10M max-limit=10M name=pcq_in parent=\

LAN priority=8

У Вас в таком виде нормально работает? А то Вы говорили, что это не копипаст из конфига, а по памяти.

так еще раз: Limit-at - это гарантированная ширина канала.

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

дереву (родителю), то есть от чего гарантированная от общего канала? или перед каким трафиком гарантированная?

улавливаете?

так что в дереве мы задаем ширину канала, а вот в листьях делим эту ширину между всеми листьями с помощью Limit-at.

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

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

у меня этот конфиг работает на 100% пример 4 группы с Limit-at=2M дерево Max-limit=8, все группы занимаю всю свою

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

2М и получается у нас 2 группы занимают по 2М, одна 4М, как только первая группа начинает работать и ей нужно 2М, то

она их получает и все группы опять начинают качать по 2М. освободившийся канал от одной группы все остальные делят

таким образом: весь трафик выстраивается в очередь дерева который имеет очередь pfifo, что означает кто первый пришел

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

[Voronok]

можно конечно и в дереве выставить Limit-at равным Max-limit и ни чего плохого в этом не будет, потому что этот параметр не будет работать так же как и мешать :) тогда смысл в этом параметре в дереве?

Спасибо, понятно. Значит без разницы. :)

[OniDarcK]

Может кому поможет. Долго мучался с шейпингом. Делал все как написано. И сразу трафик метил, и конекшены а потом уже трафик. И очереди строил и т.д. и т.п. Не работало не фига, хотя везде написано одно и тоже. Может из-за того что у меня на микротике завязаны vlan и нат. Т.е. на 1 порту аплинк, на втором порту пользователи во vlan (тегированы). Везде написано что в случае ната родителями для входящей очереди будет являться локальный интерфейс а для исходящей очереди внешний интерфейс. В моем случает все стало работать только тогда, когда выставил родителями очереди в обоих случаях global-out. Так же для проверки можно использовать колонку PCQ Queues. В случае с неработающим шейпором значения ее были просто астрономические порядка 2000-3000. Чего в принципе по логике быть не должно, т.к. абонентов всего порядка 100. После выставления родителей в global-out значения стали соответствовать действительности.