Re: [SOLVED] Ограничение максимальной скорости по IP
rrd tool как раз и ведет статистику, а графики рисует по требованию. Основная идея - снимать статистику удобнее именно tc (htb) - наименее затратный и наиболее точный способ (так как это не грузит процессор вы можете ее снимать как угодно часто). tc -s -d qdisc show dev eth0 Добрый день Можно поподробнее про рисование графиков ? спасибо -- Best regards, rusty.noelmailto:[EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Вто, 05/02/2008 в 03:41 +0300, Mikhail A Antonov пишет: ,--[Stanislav V. Vlasov [EMAIL PROTECTED] 04/02/2008 14:45 (GMT +3) | On Mon, Feb 04, 2008 at 12:46:27PM +0200, Dmitriy Sirant wrote: | Система простая. В биллинге хранится информация свитч - порт - мак-адрес | - клиент. DHCP выдает статический серый IP согласно mac. Крутится | софтинка, которая проверяет остаток денег и если он ниже определенного | уровня посылает на свитч snmp команду port shutdown. | | А как насчёт разрешить заблокированному посмотреть статистику и только | статистику? | | -- | Stanislav `- А никак. Это минус таких систем. ГГ -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
,--[Покотиленко Костик [EMAIL PROTECTED] 04/02/2008 12:06 (GMT +3) | В Птн, 01/02/2008 в 19:28 +0300, Mikhail A Antonov пишет: | On 1 февраля 2008, Покотиленко Костик wrote: | Перечислите наиболее удобные для Вас способы авторизации в домашней | сети. | | Привязка port+MAC на свитче + привязка MAC+IP на роутере. | На худой конец pppoe или openvpn. | | Домашние сети разные бывают, однако. В небольших сетях умные свичи нет | смысла ставить. Так же в таких сетях некоторые провайдеры (как например | мой клиент) одним из преимуществ считают возможность клиентов видеть | друг друга напрямую. В этом случае никакой PtP не подойдёт. | | Так что, port+MAC - нельзя назвать универсальным решением для всех | сетей, а без него MAC+IP и даром не надо. И вообще привязка к MAC - это | гомор ещё тот. `- Вот я бы не стал ставить себе ничего левого что просит провайдер. А видеть напрямую в случае с pptp обходится прописыванием статических маршрутов до локальных сегментов. Через pptp ходит только инет. Я знаю несколько сетей где так сделано. По поводу умных свитчей - пожалуй их можно не ставить разве что только там, где нет необходимости контроля пользователей - например для себя дома или на работе, где в случае чего, сотрудник получит административное взыскание за попытки делать то, чего ему делать не следует. Не так дорого эти свитчи уже стоят, чтобы от них отказывается. ИМХО. P.S.: Я подписан на рассылку и отвечать в личку нет необходимости. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Чем поиграешь, тем и зашибешься. -- Русская пословица signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
В Пнд, 04/02/2008 в 12:26 +0300, Mikhail A Antonov пишет: ,--[Покотиленко Костик [EMAIL PROTECTED] 04/02/2008 12:06 (GMT +3) | В Птн, 01/02/2008 в 19:28 +0300, Mikhail A Antonov пишет: | On 1 февраля 2008, Покотиленко Костик wrote: | Перечислите наиболее удобные для Вас способы авторизации в домашней | сети. | | Привязка port+MAC на свитче + привязка MAC+IP на роутере. | На худой конец pppoe или openvpn. | | Домашние сети разные бывают, однако. В небольших сетях умные свичи нет | смысла ставить. Так же в таких сетях некоторые провайдеры (как например | мой клиент) одним из преимуществ считают возможность клиентов видеть | друг друга напрямую. В этом случае никакой PtP не подойдёт. | | Так что, port+MAC - нельзя назвать универсальным решением для всех | сетей, а без него MAC+IP и даром не надо. И вообще привязка к MAC - это | гомор ещё тот. `- Вот я бы не стал ставить себе ничего левого что просит провайдер. А видеть напрямую в случае с pptp обходится прописыванием статических маршрутов до локальных сегментов. Через pptp ходит только инет. Я знаю несколько сетей где так сделано. По поводу умных свитчей - пожалуй их можно не ставить разве что только там, где нет необходимости контроля пользователей - например для себя дома или на работе, где в случае чего, сотрудник получит административное взыскание за попытки делать то, чего ему делать не следует. Не так дорого эти свитчи уже стоят, чтобы от них отказывается. ИМХО. /me считает, что каждый человек, в следствие своего развития, перестаёт заморачиваться на простые/дешёвые решения. Однако потребность в них всегда была и будет. Я считаю Ваш вариант более правильным и технологичным, но в моём конктерном случае не оправдано дорогим во внедрении и обслуживании. P.S.: Я подписан на рассылку и отвечать в личку нет необходимости. Начните с себя. Я то нажал replay, и адрес рассылки скопировал, а вот вставить забыл :) -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Пнд, 04/02/2008 в 12:46 +0200, Dmitriy Sirant пишет: А вот интересно как это? Выдаем IP с маской /32 или/30 ? Буду благодарен, если узнаешь подробнее. Все оказалось опять на уровне костылей... Я почему-то думал, что там используются новые стандарты какие-то из RFC касательно DHCP. Система простая. В биллинге хранится информация свитч - порт - мак-адрес - клиент. DHCP выдает статический серый IP согласно mac. Крутится софтинка, которая проверяет остаток денег и если он ниже определенного уровня посылает на свитч snmp команду port shutdown. До этого все терминировалось в PPPoE на 7206 NPE2, но не тянуло больше 3к клиентов. Как по мне, все это усугубляется тем, что внутренний траффик бесплатен (и что самое плохое незашейплен) и внутри сети народ делает что хочет. Естественно это разрулено по VLAN, но всеравно все открыто (всмысле клиент из одного VLAN видет клиента из другого VLAN и траффик бесплатен). А какой тогда смысл в VLAN'ах? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
On Mon, Feb 04, 2008 at 12:46:27PM +0200, Dmitriy Sirant wrote: Система простая. В биллинге хранится информация свитч - порт - мак-адрес - клиент. DHCP выдает статический серый IP согласно mac. Крутится софтинка, которая проверяет остаток денег и если он ниже определенного уровня посылает на свитч snmp команду port shutdown. А как насчёт разрешить заблокированному посмотреть статистику и только статистику? -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
,--[Stanislav V. Vlasov [EMAIL PROTECTED] 04/02/2008 14:45 (GMT +3) | On Mon, Feb 04, 2008 at 12:46:27PM +0200, Dmitriy Sirant wrote: | Система простая. В биллинге хранится информация свитч - порт - мак-адрес | - клиент. DHCP выдает статический серый IP согласно mac. Крутится | софтинка, которая проверяет остаток денег и если он ниже определенного | уровня посылает на свитч snmp команду port shutdown. | | А как насчёт разрешить заблокированному посмотреть статистику и только | статистику? | | -- | Stanislav `- А никак. Это минус таких систем. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Медовый месяц заканчивается свадьбой. -- Евгений Кащеев signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
On 3 февраля 2008, Maxim Tyurin wrote: В тех домосетях что я видел использовалось OpenVPN/pptp/pppoe Последнее уже вроде никто не использует. Использует. А вот от pptp отказываются. Сети, где есть openvpn я вообще не видел. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Не все то солнышко, что встает signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
On 4 февраля 2008, Dmitriy Sirant wrote: Mikhail A Antonov пишет: On 3 февраля 2008, Maxim Tyurin wrote: В тех домосетях что я видел использовалось OpenVPN/pptp/pppoe Последнее уже вроде никто не использует. Использует. А вот от pptp отказываются. Сети, где есть openvpn я вообще не видел. Кстати, тоже считаю что в домашних сетях pppoe более приемлем, т.к. нет нужды в поднятии маршрутизации на серых сетях - как следствие весь траффик идет через наш терминирующий сервер (ну кроме пользователей предела одного сегмента которые подключены в свитч и то если смогут договорится и поднять серые IP сами). Рекомендуем своим убирать галочку на TCP/IP для физического подключения А лучше вообще все галочки. Таким образом никаких серых IP. А если кто-то и включил ее - ну и нам-то что. Хотя если использовать layer3 свитчи + dhcp от cisco - то там можно обойтись и без pppoe, там вроде сам dhcp отключает пользователей, которым нельзя работать. Хотя точно как это реализовано незнаю, но у нас одну сетку на такое перевели, если будет интересно могу точнее узнать. А вот интересно как это? Выдаем IP с маской /32 или/30 ? Буду благодарен, если узнаешь подробнее. Можно в личку, если еще проявивших интерес не появится. Спасибо. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- ЗАКОН ЛИБЕРМАНА Врут все, но это не имеет значения, потому что никто не слушает. signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
On 4 февраля 2008, Stanislav Kruchinin wrote: Немаршрутизируемый протокол PPPoE приемлем только для абонентских окончаний DSL. В сетях с ним возникают проблемы, которые проявляются по мере роста. Большую сеть в любом случае придется разбивать на VLANы и маршрутизировать, чтобы урезать широковещательный трафик. И что тогда, в каждом сегменте устанавливать по серверу? Угу, на VLAN-ы разбили, на один сервер взвалили несколько VLAN-ов и все довольны. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Красноречие - искусство убеждать глупцов, что белое есть белое. -- Амброз Бирс signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
On 4 февраля 2008, Stanislav Kruchinin wrote: Mikhail A Antonov wrote: Угу, на VLAN-ы разбили, на один сервер взвалили несколько VLAN-ов и все довольны. Один сервер будет и вланы маршрутизировать и терминировать PPPoE? Интересно, что это должен быть за сервер. Внутрисетевой трафик от нескольких тысяч клиентов, создающих пакетрейты порядка 1 mpps потянут только маршрутизирующие коммутаторы. На несколько тысяч клиентов использовать _любой_ VPN - гадость. ИМХО. В таких ситуациях правильнее использовать коммутаторы, умеющие привязку MAC+Port и соответственно маршрутизатор, умеющий MAC+IP. И всеравно разбивать сеть на VLAN-ы. -- Best regards, Mikhail Bart-mdv- @ SolarNet IRC: irc.solarnet.ru WWW: http://www.solarnet.ru/ -- Лицо - зеркало души. -- латинская пословица signature.asc Description: This is a digitally signed message part.
Re: [SOLVED] Ограничение максимальной скорости по IP
On Fri, Feb 01, 2008 at 11:56:50AM +0200, Покотиленко Костик wrote: Для авторизации используется биллинг со встроенной функцией авторизации + у клиентов в трее висит клиент-авторизатор. А если у клиента нет трея? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Чтв, 31/01/2008 в 13:14 -0500, Nicholas пишет: Покотиленко Костик wrote: - Добавляем только ещё один HTB класс со скоростью, например 1kbit/s - это для приземления превышения скорости. Логичнее дать каждому пользователю соразмерную минимально гарантированную (rate) и максимальную (ceil) ширину канала. (rate 64kbps ceil 128kbps, как вариант) Так сложнее получается. Чем мне не нравится править классы HTB, так это постоянным пересчётом a1=a11+a12+a13... Конечно, понятно, что это один раз надо сделать, но, опять же, придётся забить кучу классов, большая часть из которых будет простаивать, а следовательно, придётся ещё думать как не используемую ширину канала одалживать классу обычных пользователей, например. К тому же человеку заводящему клиентов в биллинг нужно будет постоянно помнить кому какие IP давать. А так он назначил тариф 128+ или 256+ и забыл. Хотя, конечно, ваш вариант - тоже вариант. Вопрос: есть ли дисциплина позволяющая ограничивать максимальную скорость до указанного значения для каждого IP отдельно, Возможно стоить выдавать анлимитчикам ip из определенной подсети и заранее сделать правила для всех (каждого) ip этой подсети. (клас, дисциплина и фильтры входящий/исходящий - по 4 правила) Процесс можно автоматизировать, примерно, так: echo tc qdisc add dev eth0 root handle 1: htb default tc.conf for i in `seq 1 254`; do echo tc class add dev eth0 parent 1: classid 1:$i htb rate 64kbps ceil 128kbps burst 150k tc.conf; done; for i in `seq 1 254`; do echo tc qdisc add dev eth0 parent 1:$i handle $i: sfq perturb 10 tc.conf; done; for i in `seq 1 254`; do echo tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src xx.xx.xx.$i flowid 1:$i tc.conf; done; for i in `seq 1 254`; do echo tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst xx.xx.xx.$i flowid 1:$i tc.conf; done; Если вы будете использовать openvpn для авторизации, то eth0 можно заменить на tap0 Кроме того, если вы используете дисциплину htb, удобно с ее подружить с rrd и смотреть графики нагрузки по ip. Для авторизации используется биллинг со встроенной функцией авторизации + у клиентов в трее висит клиент-авторизатор. Графики по каждому клиенту рисовать часто - это сильно ресурсоёмко. А не часто смысла нет, так как эту статистику биллинг ведёт. Спасибо за то что поделились опытом. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Птн, 01/02/2008 в 13:58 +0300, Иван Лох пишет: On Fri, Feb 01, 2008 at 11:56:50AM +0200, Покотиленко Костик wrote: Для авторизации используется биллинг со встроенной функцией авторизации + у клиентов в трее висит клиент-авторизатор. А если у клиента нет трея? Если Вы про Linux то есть консольный perl-авторизатор. Также, если я не ошибаюсь, есть графический QT-авторизатор. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
On Fri, Feb 01, 2008 at 01:06:14PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 13:58 +0300, Иван Лох пишет: А если у клиента нет трея? Если Вы про Linux то есть консольный perl-авторизатор. Также, если я не ошибаюсь, есть графический QT-авторизатор. Почему про линукс? Может про Hurd... Вот скажите честно, Вы поставите на свой компьютер какую-то мутную программу провайдера? Да еще, может быть, и под root? Потратите два дня на аудит перлового скрипта? Порекомендуете кому-нибудь такого стремного провайдера? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Птн, 01/02/2008 в 14:43 +0300, Иван Лох пишет: On Fri, Feb 01, 2008 at 01:06:14PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 13:58 +0300, Иван Лох пишет: А если у клиента нет трея? Если Вы про Linux то есть консольный perl-авторизатор. Также, если я не ошибаюсь, есть графический QT-авторизатор. Почему про линукс? Может про Hurd... Вот скажите честно, Вы поставите на свой компьютер какую-то мутную программу провайдера? Да еще, может быть, и под root? Потратите два дня на аудит перлового скрипта? Порекомендуете кому-нибудь такого стремного провайдера? Рута не надо. Прога работает по UDP исходящий и входящий порты одинаковые 7723. Я объяснюсь, я не рекламирую это ПО, я говорю я удобству такой конструкции. А если говорить про такого рода ПО, мне больше нравится другая реализация, но мой заказчик выбрал эту, у него на это есть причины. Вы с домашними сетями сталкивались? Знаете специфику? По поводу мутности, Вы каждый раз делаете аудит программы, когда устанавливаете Клиент-Бант клиенту? Все патчи, которые используете, изучили? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
On Fri, Feb 01, 2008 at 01:57:24PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 14:43 +0300, Иван Лох пишет: On Fri, Feb 01, 2008 at 01:06:14PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 13:58 +0300, Иван Лох пишет: А если у клиента нет трея? Если Вы про Linux то есть консольный perl-авторизатор. Также, если я не ошибаюсь, есть графический QT-авторизатор. Почему про линукс? Может про Hurd... Вот скажите честно, Вы поставите на свой компьютер какую-то мутную программу провайдера? Да еще, может быть, и под root? Потратите два дня на аудит перлового скрипта? Порекомендуете кому-нибудь такого стремного провайдера? Рута не надо. Прога работает по UDP исходящий и входящий порты одинаковые 7723. Это из серии Кручу-верчу-обмануть-хочу. Под каким пользователем она запускается? Я объяснюсь, я не рекламирую это ПО, я говорю я удобству такой конструкции. Удобству для кого? Для потребителя услуг, определенно, нет. По поводу мутности, Вы каждый раз делаете аудит программы, когда устанавливаете Клиент-Бант клиенту? Все патчи, которые используете, изучили? 1) Я не устанавливаю Клиент-Банк даже себе ;-} 2) Я, в достаточной степени, доверяю разработчикам Debian и его инфраструктуре. 3) Есть несколько крупных корпораций чье программное обеспечение я, с некоторыми мерами предосторожности, считаю возможным использовать, в-принципе. 4) Я не параноик. ;-} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Птн, 01/02/2008 в 16:25 +0300, Иван Лох пишет: On Fri, Feb 01, 2008 at 01:57:24PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 14:43 +0300, Иван Лох пишет: On Fri, Feb 01, 2008 at 01:06:14PM +0200, Покотиленко Костик wrote: В Птн, 01/02/2008 в 13:58 +0300, Иван Лох пишет: А если у клиента нет трея? Если Вы про Linux то есть консольный perl-авторизатор. Также, если я не ошибаюсь, есть графический QT-авторизатор. Почему про линукс? Может про Hurd... Вот скажите честно, Вы поставите на свой компьютер какую-то мутную программу провайдера? Да еще, может быть, и под root? Потратите два дня на аудит перлового скрипта? Порекомендуете кому-нибудь такого стремного провайдера? Рута не надо. Прога работает по UDP исходящий и входящий порты одинаковые 7723. Это из серии Кручу-верчу-обмануть-хочу. Под каким пользователем она запускается? Хоть из-под `whoami`. Я объяснюсь, я не рекламирую это ПО, я говорю я удобству такой конструкции. Удобству для кого? Для потребителя услуг, определенно, нет. Перечислите наиболее удобные для Вас способы авторизации в домашней сети. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Птн, 01/02/2008 в 09:37 -0500, Nicholas пишет: Покотиленко Костик wrote: Так сложнее получается. Чем мне не нравится править классы HTB, так это постоянным пересчётом a1=a11+a12+a13... Конечно, понятно, что это один раз надо сделать, но, каждая команда делает 256 правил автоматом (`seq 1 254` - для примера ) for i in `seq 1 254`; do echo tc class add dev eth0 parent 1: classid 1:$i htb rate 64kbps ceil 128kbps burst 150k tc.conf; done; опять же, придётся забить кучу классов, большая часть из которых будет простаивать, а следовательно, придётся ещё думать как не используемую ширину канала одалживать это делает htb автоматом - вы можете указать каждому клиенту свою минимальную и максимальную ширину, можно максимальную не указывать (ceil) - htb разделит дополнительную скорость пропорционально. Если суммарная выделенная клиентам ширина канала, наоборот, больше реальной - htb тоже все пересчитает пропорционально (при нагрузке, а пока клиентов мало всем даст столько сколько в правиле для клиента прописанно). Вы можете делать деревья - root сделать 1:, первую ветвь 1:888 для обычных поьзователей и вторую для анлимит 1:777 http://www.opennet.ru/docs/RUS/LARTC/x1075.html#THEQDISCFAMILYROOTSHANDLESSIBLINGSANDPARENTS tc qdisc add dev eth0 root handle 1: htb default 1 tc class add dev eth0 parent 1: classid 1: htb rate 2mbit burst 15k tc class add dev eth0 parent 1: classid 1:888 htb rate 1mbit ceil 1mbit burst 15k tc class add dev eth0 parent 1: classid 1:777 htb rate 1mbit ceil 1mbit burst 15k и определять общую скорость для всех пользователей группы + для каждого пользователя в группе. tc class add dev eth0 parent 1:777 classid 1:71 htb rate 128kbit ceil 256kbit burst 15k ... tc class add dev eth0 parent 1:777 classid 1:7254 htb rate 128kbit ceil 256kbit burst 15k и т.д. в этом примере комада для создания правила будет тоже с семеркой перед номером хоста (1-254) for i in `seq 1 254`; do echo tc class add dev eth0 parent 1:777 classid 1:7$i htb rate 128kbps ceil 256kbps burst 150k tc.conf; done; надо сказать что 4 правила для каждого из 255 ip для двух подситей (4*255*2=2040) совсем не грузят htb. С уважением, Николай. PS rrd tool как раз и ведет статистику, а графики рисует по требованию. Основная идея - снимать статистику удобнее именно tc (htb) - наименее затратный и наиболее точный способ (так как это не грузит процессор вы можете ее снимать как угодно часто). tc -s -d qdisc show dev eth0 Принцип ясен, спасибо за пример! -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение максимальной скорости по IP
В Срд, 16/01/2008 в 14:49 +0200, Покотиленко Костик пишет: Добрый день, есть роутер на котором настроено разделение канала по группам клиентов (HTB). Сейчас в одной группе нужно сделать подгруппу для клиентов и безлимитными пакетами. Для этого им нужно ограничить максимальную скорость. Разобрался, сам себе и отвечу. Может кому пригодится. Самый простой для моей ситуации оказался такой способ: - Оставляем HTB классы разделения канала как есть. - Добавляем только ещё один HTB класс со скоростью, например 1kbit/s - это для приземления превышения скорости. - Фильтрам к этим классам ставим приоритет повыше, например 100. - На каждого безлимитчика добавляем 2 фильтра, один с приоритетом, например, 10, который срабатывает только для скоростей меньших, чем интересуемая скорость, второй с приоритетом 11 для остального трафика (трафик превышающий лимит скорости). Вот как выглядят у меня фильтры по одному интерфейсу: # tc filter show dev eth3 filter parent 3: protocol ip pref 10 fw filter parent 3: protocol ip pref 10 fw handle 0xa14 classid 3:2200 police 0x16 rate 128000bit burst 10Kb mtu 2Kb action continue ref 1 bind 1 filter parent 3: protocol ip pref 11 fw filter parent 3: protocol ip pref 11 fw handle 0xa14 classid 3:2300 filter parent 3: protocol ip pref 100 fw filter parent 3: protocol ip pref 100 fw handle 0x7d64 classid 3:2100 filter parent 3: protocol ip pref 100 fw handle 0x799a classid 3:1130 filter parent 3: protocol ip pref 100 fw handle 0x7990 classid 3:1120 filter parent 3: protocol ip pref 100 fw handle 0x7986 classid 3:1110 filter parent 3: protocol ip pref 100 fw handle 0x79b8 classid 3:1160 filter parent 3: protocol ip pref 100 fw handle 0x79ae classid 3:1150 filter parent 3: protocol ip pref 100 fw handle 0x79a4 classid 3:1140 filter parent 3: protocol ip pref 100 fw handle 0x79d6 classid 3:1190 filter parent 3: protocol ip pref 100 fw handle 0x79cc classid 3:1180 filter parent 3: protocol ip pref 100 fw handle 0x7dc8 classid 3:2200 filter parent 3: protocol ip pref 100 fw handle 0x79c2 classid 3:1170 filter parent 3: protocol ip pref 100 fw handle 0x79e0 classid 3:1200 filter parent 3: protocol ip pref 100 fw handle 0x7e2c classid 3:2300 filter parent 3: protocol ip pref 100 fw handle 0x7e90 classid 3:2400 # С помощью iptables пакетам первого безлимитчика ставится марка 0xa14. Основной класс клиентов 3:2200, им классифицируются и пакеты безлимитчиков до лимита скорости 128kbit (фильтр с приоритетом 10). Когда начинается перебор фильтр с приоритетом 10 перестаёт срабатывать и, поскольку в нём указано continue, обработка фильтров продолжается. Пакеты трафика выше лимита скорости теперь попадают под фильтр с приоритетом 11, который классифицирует их 3:2300, классом приземления. Стоит отметить, что для фильтров я сначала использовал u32 классификатор. Потом полностью от него отказался вследствие его ограничений и перешёл на iptables -j MARK + tc filter fw. На интерфейсе смотрящем в Интернет настроен SNAT, и u32 видит адреса после SNAT, т.е. он видит всегда один адрес отправителя :/ В моём случае, в системе работает биллинг со встроенной функцией авторизатора, который при авторизации вызывает скрипт разрешения доступа пользователю в Интернет. Скрипту также передаётся помер пакета, на который подключен клиент. Скрипт добавляет разрешающие правила в iptables при подключении, и удаляет их при отключении (по IP). В скрипте я встроил проверку на принадлежность клиента к безлимитным пакетам, и в этом случае вызываю скрипт установки ограничений, который приведу для примера. Скрипту передаются $IP, $IN_RATE, $OUT_RATE. IP из сети с маской /16 и начиная с a.b.100.0: #!/bin/sh LOGFILE=/var/log/iptables/iptables.log CALL_FILE=on_unlim_up IN_DEV=eth0 IN_PARENT_CLASS=1:0 IN_BASE_CLASS=1:3220 IN_LAND_CLASS=1:3230 OUT_DEV=eth3 OUT_PARENT_CLASS=3:0 OUT_BASE_CLASS=3:2200 OUT_LAND_CLASS=3:2300 IP3=`echo $IP | cut -d. -f3` IP4=`echo $IP | cut -d. -f4` HANDLE=`printf %.3X $[($IP3-100)*256+$IP4]` HANDLE10=$[($IP3-100)*256+$IP4] ret=0 echo -n `date`: Insetring tc filter: $CALL_FILE: $IP \(ID: $HANDLE\) at $IN_RATE/$OUT_RATE $LOGFILE # Inseting downstream filtering shaper rules iptables -t mangle -I shapIN 1 -d $IP -j RETURN iptables -t mangle -I shapIN 1 -d $IP -j MARK --set-mark $HANDLE10 tc filter add dev $IN_DEV parent $IN_PARENT_CLASS protocol ip prio 10 handle $HANDLE10 fw police rate $IN_RATE buffer 10k continue classid $IN_BASE_CLASS; ret=$[$ret+$?] tc filter add dev $IN_DEV parent $IN_PARENT_CLASS protocol ip prio 11 handle $HANDLE10 fw classid $IN_LAND_CLASS; ret=$[$ret+$?] # Inseting upstream filtering shaper rules iptables -t mangle -I shapOUT 1 -s $IP -j RETURN iptables -t mangle -I shapOUT 1 -s $IP -j MARK --set-mark $HANDLE10 tc filter add dev $OUT_DEV parent $OUT_PARENT_CLASS protocol ip prio 10 handle $HANDLE10 fw police rate $OUT_RATE buffer 10k continue classid $OUT_BASE_CLASS; ret=$[$ret+$?] tc filter add dev
