Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Следующая статья должна быть про imq и ifb, и про то, почему через них всё делается проще и удобнее. В частности, про то, что так проще контроллировать входящий от провайдера трафик, если локалок несколько, и контролировать трафик локалок, если провайдеров несколько.
Как раз работаю в этом направлении
Поддерживаю. Про tc уже было несколько статей, а про imq/ifb — нет.
уже как 6 лет назад (когда работал админом) я делал как раз с помощью IMQ устройства ограничение для входящего трафика.
В принципе система работала вполне себе, только все равно это в некотором роде танцы с бубнами, особенно в смысле подбора правильных цифр для бурстов и им подобным
В принципе система работала вполне себе, только все равно это в некотором роде танцы с бубнами, особенно в смысле подбора правильных цифр для бурстов и им подобным
Тема очень актуальна и интересна. И еще вопрос: если нет необходимости классифицировать трафик по внутренним ip, то виртуальный интерфейс можно не создавать, а ограничивать прямо на eth1?
Статья из разряда «побольше бы таких».
Жаль нет времени сейчас все внимательно прочитать и опробовать сразу.В мемориз!
Жаль нет времени сейчас все внимательно прочитать и опробовать сразу.В мемориз!
Как же все сложно.
Можно же использовать IPMARK + HTB — дел на 10 минут, производительность потрясающая. Пример использования здесь centos.alt.ru/?p=532.
Либо поставить ipfw который позволяет в 3 строчки порезать трафик. Пример здесь centos.alt.ru/?p=505.
Либо использовать надстройку над HTB SC которая использует либо flow классификатор либо u32 хэш фильтры и тоже показывает высокую производительность. Пример здесь centos.alt.ru/?p=504.
Можно же использовать IPMARK + HTB — дел на 10 минут, производительность потрясающая. Пример использования здесь centos.alt.ru/?p=532.
Либо поставить ipfw который позволяет в 3 строчки порезать трафик. Пример здесь centos.alt.ru/?p=505.
Либо использовать надстройку над HTB SC которая использует либо flow классификатор либо u32 хэш фильтры и тоже показывает высокую производительность. Пример здесь centos.alt.ru/?p=504.
Я описал один из методов ограничения полосы пропускания и все подробно расписал.
Ваши статьи тоже очень позновательны и, я уверен, что методы, описанные в них показывают высокую эффективность при работе.
Ваши статьи тоже очень позновательны и, я уверен, что методы, описанные в них показывают высокую эффективность при работе.
да… без хеш фильтров никуда… на носу ipv6 ;)
ipfw все же более для BSD, предпочитаю простоту и удобство, поэтому в качестве роутера freebsd(ipfw,vlan).
а ipmark + htb удобна тем, что можно развести на несколько машин при высокой нагрузке ;)
ipfw все же более для BSD, предпочитаю простоту и удобство, поэтому в качестве роутера freebsd(ipfw,vlan).
а ipmark + htb удобна тем, что можно развести на несколько машин при высокой нагрузке ;)
Тоже использую HTB.
Момент, а зачем какие-то виртуальные интерфейсы, когда ЕМНИП можно классифицировать входящие пакеты ещё до NAT? Вроде как что-то типо
eth1 — исходящий интерфейс в мир, на котором висит SNAT в POSTROUTING. А потом уже например
Или я не прав?
-t mangle -A POSTROUTING -o eth1 -s 192.168.0.0/24 -j CLASSIFY --set-class 0001:0002
eth1 — исходящий интерфейс в мир, на котором висит SNAT в POSTROUTING. А потом уже например
tc class add dev eth1 parent 1: classid 1:2 htb rate 128kbit
Или я не прав?
Трафик можно резать только на интерфейсах. А их у человека два, потому пользователь при лимите, скажем, 2 мегабита мог бы получить 4: 2 на одном и 2 на втором.
Поэтому трафик сначала прогоняется через ifb (все вместе, на оба направления) и там режется.
Поэтому трафик сначала прогоняется через ifb (все вместе, на оба направления) и там режется.
Так, стоп. Трафик всегда двунаправленный. Проще говоря для резки всегда надо ограничивать отдельно входящую и исходящую полосу на разных интерфейсах. И так собственно и делает автор. Входящая ограничивается элементарно — на внутреннем интерфейсе по IP получателя. Исходящая — соотв. на внешнем, но тут проблема — SNAT затирает адрес источника. Поэтому надо до SNAT классифицировать пакеты средствами iptables, и потом уже резать трафик средствами tc. И не надо никаких промежуточных виртуальных интерфейсов, единственное предназначение которых, насколько я понимаю, — «вешать» на них tc для работы с исходящим трафиком по IP отправителя.
Есть, к слову, ещё IPMARK для тех же целей, но про него я как-то совсем ничего не знаю.
Есть, к слову, ещё IPMARK для тех же целей, но про него я как-то совсем ничего не знаю.
> Исходящая — соотв. на внешнем
Именно, что на внешнем. А там их два.
Если повесить tc shaper на оба — получается, что юзер может получить в два раза больше положенной полосы (шейпится ведь на обеих отдельно). Предназначение ifb здесь — зашейпить трафик до того, как он растечется по внешним интерфейсам.
Именно, что на внешнем. А там их два.
Если повесить tc shaper на оба — получается, что юзер может получить в два раза больше положенной полосы (шейпится ведь на обеих отдельно). Предназначение ifb здесь — зашейпить трафик до того, как он растечется по внешним интерфейсам.
Пардон, промахнулся. Это был ответ на habrahabr.ru/blogs/sysadm/119611/#comment_3913344.
Заодно уж добавлю: возможность работать с адресом отправителя до SNAT — это скорее побочный эффект, использованный как приятная плюшка.
Заодно уж добавлю: возможность работать с адресом отправителя до SNAT — это скорее побочный эффект, использованный как приятная плюшка.
Ага, про два провайдера не заметил, обратил внимание только на то, что виртуальный интерфейс позиционируется как средство обхода проблемы SNAT. Да и в любом случае, даже с двумя провами виртуальный интерфейс только для резки трафика не нужен. Один клиент не сможет использовать одновременно два исходящих интерфейса никаким образом. Соотв. у вас будет какой-нибудь виртуальный bond интерфейс или какой-то другой способ объединения каналов. В любом случае с точки зрения исходящего трафика всегда будет только один внешний интерфейс, на который можно повесить tc.
Почему же не сможет? Вполне. Скажем, маршрут на 0.0.0.0/0 идет через один интерфейс, а на какой-нибудить IX или пиринг — через второй. Собстсвенно, у меня так сейчас и есть. Иногда даже пакеты улетают в один интерфейс, а ответ приходит из другого :).
Добавлю, чтобы понятней было: имеется в виду два разных L3-интерфейса, а не два L2, обьединенных в один, как Вы предположили.
Ну, это что-то жутко нетипичное) Тут может и надо городить какие-то виртуальные интерфейсы, в то время как обычно это совершенно не требуется.
Как раз-таки это жутко типичное. У больших маршрутизаторов явно больше, чем два интерфейса ;). У меня на бордере, например, 9 штук (специально зашел и посчитал).
В этом-то, собственно, и состоит работа маршрутизатора — выбирать путь отправки пакета. Трафик резать и менеджерам вконтакте закрывать — вторичное.
В этом-то, собственно, и состоит работа маршрутизатора — выбирать путь отправки пакета. Трафик резать и менеджерам вконтакте закрывать — вторичное.
У маршрутизаторов — безусловно. У шлюзов — уже нет. А режете же вы трафик не внутри корп. сети, а на шлюзе) И даже если они совмещены — активный канал между сетями в подавляющем большинстве случаев один и именно он и интересует, а всякие внутренние интерфейсы, VPN и прочее — это уже всё не в счёт, ибо составляет внутренние ресурсы сети. У меня по крайней мере всё именно так в сети на 5 удалённых офисов с хитрой топологией.
Я не сетевик ни разу, поэтому немножко не понимаю. Подскажите пожалуйста, что провайдер выигрывает режа входящий из инета трафик? Ну в смысле пакеты ж отбрасываются или как? Т.е. допустим клиент с тарифом 1 мбит/с делает запрос и ответный пакет до шлюза провайдера доходит же не со скоростью 1 мбит/с а на полной? или я неправ?
Еще раз сорри за глупый вопрос — трафик резал один раз в жизни, давно, и почти неправда :)
Еще раз сорри за глупый вопрос — трафик резал один раз в жизни, давно, и почти неправда :)
Передающая сторона подстраивается под это ограничение, т.е. уменьшает скорость до тех пор, пока пакеты не будут идти нормально. Выглядит это так, будто где-то по дороге узкий канал.
Кстати, отбрасывает пакеты policer. Shaper же задерживает пакеты, пока не получится нужная скорость. Помогает избежать множества проблем.
Кстати, отбрасывает пакеты policer. Shaper же задерживает пакеты, пока не получится нужная скорость. Помогает избежать множества проблем.
Передающая сторона это тот сайт с которого я тащу инфу к примеру? А каким образом подстраивается? Не подскажите где этот механизм описан? Или хотя бы дайте ключевые слова, по которым искать, плиз.
Если в общих чертах — да.
Гугл мне сказал вот это: www.conlex.kz/mexanizm-kontrolya-peregruzok-v-tcp/.
Гугл мне сказал вот это: www.conlex.kz/mexanizm-kontrolya-peregruzok-v-tcp/.
ковырялся с tc довольно долго. Не получилось заводить ни по man tc ни по скриптам с многочисленных форумах.
Есть такая очень хорошая вещь… как wondershaper.
очень простое использование. ограничение по down/up.
работает для ppp клиентов.
Есть такая очень хорошая вещь… как wondershaper.
очень простое использование. ограничение по down/up.
работает для ppp клиентов.
wondershaper хорош тем, что генерирует скрипт. Можно посмотреть, что и как оно делает :).
Еще есть sc. Живет где-то на forum.nag.ru.
Еще есть sc. Живет где-то на forum.nag.ru.
мне в короткие сроки надо было на сервере настроить ограничение полосы пропускания для ppp клиентов )) Пару ночей — и я уже почти отчаялся и хотел ставить фряху ( у меня на дебиане все работает ) в ней решаются такие задачи сравнительно просто.
С tc намучался… вандершейпер — грамотная надстройка…
единственное я заметил, что что-бы была реальная скорость 2 на 2 мегабита надо ставить слегка ( 2300-2400) завышенные параметры. Не знаю, почему… и это не служебный трафик. Так же есть приоритеты, например полностью забитый канал торрентами не мешает нормальному серфингу.
С tc намучался… вандершейпер — грамотная надстройка…
единственное я заметил, что что-бы была реальная скорость 2 на 2 мегабита надо ставить слегка ( 2300-2400) завышенные параметры. Не знаю, почему… и это не служебный трафик. Так же есть приоритеты, например полностью забитый канал торрентами не мешает нормальному серфингу.
Если PPP — то Вам надо было на специализированные форумы сходить :). Например, довольно простой и эфективный скрипт есть тут: abills.net.ua/wiki/doku.php/abills:docs:linux:pppd_radattr:ru. Варианты посложнее — там же на форуме.
Хех, а я думал разборки с микротиком — сложно).
Спасибо, познавательно.
Сам все ж сделал выбор в пользу коробки, пока эмоции крайне положительные).
Спасибо, познавательно.
Сам все ж сделал выбор в пользу коробки, пока эмоции крайне положительные).
> В теории управления трафиком мы можем ограничивать только исходящий трафик.
на самом деле мы может ограничивать оба трафика на каждом интерфейсе. И хотя входящий при этом ограничивается не так ровно, как исходящий, получается небольшая «пила», но задача выполняется, паразитный трафик не занимает весь канал и не приводит к задержкам приоритетного трафика.
на самом деле мы может ограничивать оба трафика на каждом интерфейсе. И хотя входящий при этом ограничивается не так ровно, как исходящий, получается небольшая «пила», но задача выполняется, паразитный трафик не занимает весь канал и не приводит к задержкам приоритетного трафика.
На небольших скоростях — надо ifb. А если уже считаются мегабитами (от 5 до 100), то смело можно делать ingress policer, заметно не будет. Я, например, давно уже так сделал.
Посмотрел в рабочий фильтр, действительно ingress policer.
Все равно при максимальной загрузке видна пилообразность графика, он же размером tcp окна играется, что бы скорость выставить.
Но в общем работает хорошо, приоритетный трафик никогда не лагал.
Все равно при максимальной загрузке видна пилообразность графика, он же размером tcp окна играется, что бы скорость выставить.
Но в общем работает хорошо, приоритетный трафик никогда не лагал.
На мой взгляд вся эта затея слишком крута для офиса даже из 50 машин
Мне казаться будет достаточно сказать роутеру что все выдать по 1-2m на web и по 1-10m на smtp. Люди должны работать а не фото отчеты с отпуска выкладывать.
Мне казаться будет достаточно сказать роутеру что все выдать по 1-2m на web и по 1-10m на smtp. Люди должны работать а не фото отчеты с отпуска выкладывать.
Спасибо за статью! Буду ждать дополнений!
Чувствуется что автор глубоко копнул тему — молодец. Я вот когда пришел на текущее место работы из всего зоопарка выбрал NeTAMS — не скажу что с ним нет проблем, но в данный момент он шейпит трафик и считает квоты для пользователей сети ISP, в котором я работаю. Иной раз тупо не хватает знаний и статистики — нарабатываю на ходу. :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ограничиваем входящий и исходящий трафик в Linux