Оставить свободным часть канала.

А кажись можно так: шейпить на двух интерфейсах сервера, чтобы один смотрел в офис, один в мир. И относительно офиса также пошейпить можно скажем не более: 6-8мбит/сек. И всё в порядке будет?

красиво, надёжно и дёшево - никак.

есть известный изврат с dummy интерфейсом (когда весь трафик через него и внешний входящий становиться его исходящим) - но это такой кривой костылищще :)

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

Для vpn, бизнес-приложений и почты лучше сделать отдельный канал

Через ifb — не костыль, а рекомендованный Linux Foundation способ.

А если представить что у меня нет NAT на этой машине, и я всё буду делать на внутреннем роутере с парой сетевых плат?

Если я правильно понял, то tc мне подойдёт. Можно порезать скорость, и выставить классы трафика.

Почитай сам принцип
http://habrahabr.ru/post/131295/

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

конечно tc подойдёт..но только у вас встанет вопрос про прокси и почту - они эе где-то крутятся ? в 99% случаев на той-же машине и поэтому их трафик _только_через_одну_карту_ и придётся юзать dummy как вторую чтобы шейпить трафик к ним.

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

ps обеспечение полосы не может быть сделано одним узлом по личной инициативе. Ну вот ну никак..Чья бы это рекомендация ни была - это кривой костыль.

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

Вопрос интересный. К примеру сейчас нужно: чтобы vpn, почта, были более приоритетны. - Завтра нужно чтобы SAP тоже не тормозил... - Постоянно теребить провайдера придётся? А как его просить? Можно ему сказать к примеру так: хочу чтобы самым приоритетным трафиком был трафик на 25,993,443 и так далее порты? К примеру: 25 самый приоритет, 993 ниже, и 443 ещё ниже. Так можно? В таком случае мне не придётся ничего делать вообще со своей стороны? Qos на стороне провайдера, и я смогу гулять?

шейпить на исходящим в сторону юзеров интерфейсе/интерфейсах(заворачивать или не заворачивать в ifb - зависит от способа выдачи юзерам интернета)

Вы мне это отвечаете? - Я в целом понял суть. Спасибо. Стал теперь я вкуривать зачем придумали этот ifb...

Насколько это всё жизнеспособно?

P.S. пока всё же уговариваю руководство на тупо расширение канала и всё.

Насколько это всё жизнеспособно?

Использую ifb для шейпинга кучи ppp-интерфейсов(300-400 штук, каждый смотрит на пользователя) в маленьком провайдере уже не первый год.

Если ppp-интерфейсов нет и на юзеров смотрит 1 интерфейс - ifb задейстовать не обязательно - можно шейпить прямо на этом интерфейсе

Да,один интерфейс смотрит в пользователей. Но к этому интерфейсу прикручен ряд других локальных подсетей - к примеру видеоподсеть. - Как тутЪ быть? По ip рулить?

Как тутЪ быть? По ip рулить?

Да. Можно еще по маркировкам iptables, если городить много правил для tc не хочется. Сказать tc «весь трафик, помеченный mark 1 - шейпить до 8 Мбит/сек, остальное - на всю скорость». А в iptables в mangle/PREROUTING промаркировать нужные подсети/адреса.

Спасибо! Весьма интересно!

хочу чтобы самым приоритетным трафиком был трафик на 25,993,443 и так далее порты?

на самом деле это не так :) обращаешся к провайдеру со словами - мне по бизнесу нужна гарантированная полоса duplex 32/64/xxx kbps от белого (абонированного у вас-же) ip. Всё прочее можно кидать и принимать через серые адреса. Если у провайдера нормальные технари, которые скажут «да, это реально» и неленивая коммерция которая скажет «угу, но это доп.соглашение и соотв. денюшка» - то получите +1 вирт.канал на провайдерскую циску в вашем шкафу или просто ещё один физ.канал.

хочу чтобы самым приоритетным трафиком был трафик на 25,993,443

никого кроме вас самих не волнуют номера ваших портов. Провайдер может ориентироваться только по ip`ам и при его доброй воле по qos`ам от собственного клиента.

обращаешся к провайдеру со словами - мне по бизнесу нужна гарантированная полоса duplex 32/64/xxx kbps от белого (абонированного у вас-же) ip.

У нас вторая сторона уже на другом провайдере. Уже пролёт?

никого кроме вас самих не волнуют номера ваших портов. Провайдер может ориентироваться только по ip`ам и при его доброй воле по qos`ам от собственного клиента.

Ну в общем в моём случае проще канал увеличить. Или как посоветовал Pinkbyte замутиться через ifb.

Сейчас руководству просто лениво вот это делать:

доп.соглашение и соотв. денюшка

Ну в общем в моём случае проще канал увеличить

тогда проще купить (ещё один) другой и использовать только для более-менее контроллируемого трафика. vpn, voice, почта и так далее - то что централизованно вами управляется.

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

Сейчас руководству просто лениво вот это делать:

доп.соглашение и соотв. денюшка

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

И что, что squid крутится на том же сервере? В нём самом можно ограничить скорость и ограничить с помощью tc весь исходящий от сервера к пользователям трафик (исключая почтовый) полосой в 8 Мбит/с.

При помощи iptables ещё можно маркировать с учётом connbytes и длинные закачки урезать совсем сильно по полосе

Весьма ценно! Спасибо!

Вопрос такой: это ведь выходит по upload только так можно сделать. По download можно как-то порезать?

К примеру так: начал качать файл большой, как только пошла закачка, она идёт, всё хорошо, но скорость: 100 кб/сек стала. Иными словами можно-ли регулировать скорость download, ограничив скорость upload (ну чтоб скажем от меня подтверждения доставки приходили с такой задержкой чтоб скорость download становилась 100 кб/сек в итоге).

downlink и uplink можно резать совершенно независимо, используя ifb.

Да я похоже затупил. Мне достаточно будет пометить пакеты в connbytes и сказать через tc, чтоб скинул до 100 кб/сек upload.

ну по отношению ко мне это будет вестимо download.

Но и про ifb спасибо что напомнили. :)

ifb работает до iptables, так что там нет меток и т.д.

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

Уважаемый mky, если не трудно, взгляни своим ЛОР взглядом, поставь диагноз: http://img841.imageshack.us/img841/1548/selection023.png

Тут показан только входящий трафик ко мне, исходящий от меня может быть настроен зеркально аналогично на eth 1 «gw just forward» который.

P.S. рисовал в LibreOffice, надеюсь поймёшь и простишь меня.

post-factum, ты тоже посмотри. Тут можно обойтись без ifb в моём случае. Т.е. не усложнять и без того большой гемморой который я сейчас имею. Тоже что-то расскажи мне по этому поводу. :)

Да, тут можно без ifb — просто на just forward шейпить на обоих интерфейсах.

Ой, и правда, тупанул... Спасибо! В остальном нормально? Будет работать?

Я вот думаю… connbytes ведь апостериори работает, если я правильно понимаю, т.е., заранее узнать размер закачки невозможно.

Нет конечно. Он работает по факту. И разумеется его легко можно обмануть. Это просто так, детская забава. Не более. - Если речь идёт о больших файлах, и download manager, то он его вообще проигнорит, установит соединение снова, тут уже можно и крепко банить на самом то деле, по ip до выяснения обстоятельв. - Но зато он протоколо независим. Хоть скайп, хоть ftp, хоть web. - Всё словит. Акромя торрентов. Но торренты можно априори просто не открывать. default deny пользовать.

Ну тогда удачи :).

Нормально. Но я бы для начала сделал бы проще. До 500 кбайт «быстро», свыше «медленно». Иерархия классов, 6 Мбит в сумме, для «быстро» гарантировать 5 Мбит, для «медленно» 1 Мбит. Чтобы не углублятся в iptables mangle, а погружатся в tc htb. http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

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

Исходящий (пакеты из вашей сети в Интернет) можно ограничивать и «Gw with NAT» на интерфейсе eth1. ЕМНИП, пакеты в tc filter будут все с одного ip (так как прошли SNAT), но метки (-j MARK) у них сохранятся, поэтому метить на eth0, шейпить на eth1.

но метки (-j MARK) у них сохранятся, поэтому метить на eth0, шейпить на eth1.

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

До 500 кбайт «быстро», свыше «медленно».

Да, порядком цифр я ошибся, это более верный порядок 500-700 кб. Свыше прям 500 кбайт делать уже медленно - плохая довольно идея. Т.к. От: 500 до 5 мегабайт могут ходить важные данные такие как: логистически-томоженные документы с ЭЦП, всякие АРМ торговые места конечных пользователей - ну это когда юзеру ставится донгл, и он может в web торгах там каких-то участвовать.

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

Исходя из вышенаписанного я не вижу особой надобности в большом кол-ве классов для трафика. - Я не вижу смысла ограничивать полосу для длительных закачек. - Потому как иногда это бывают и важные данные, а вот приоритет понизить им можно, чтоб если есть более важные данные такие как: первые 500кбайт, или 500кб.-5мб. (средний приоритет), то всё остальное было бы с максимально большим приоритетом, чтобы закачки не мешали жить другим, но в то же время канал использовался максимально эффективно. И если никого особо нету, то пусть закачка фигачит на полную.

P.S. мой онлайн: 100-150 человек.