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'ах? Я думаю что для разделения на клиентов корпоративных и таких... сильно не вникал. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Mikhail A Antonov wrote: На несколько тысяч клиентов использовать _любой_ VPN - гадость. ИМХО. В таких ситуациях правильнее использовать коммутаторы, умеющие привязку MAC+Port и соответственно маршрутизатор, умеющий MAC+IP. И всеравно разбивать сеть на VLAN-ы. О том и речь. PPPoE вообще не стоит внедрять, т.к. от него все равно прийдется отказаться. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Mikhail A Antonov wrote: Угу, на VLAN-ы разбили, на один сервер взвалили несколько VLAN-ов и все довольны. Один сервер будет и вланы маршрутизировать и терминировать PPPoE? Интересно, что это должен быть за сервер. Внутрисетевой трафик от нескольких тысяч клиентов, создающих пакетрейты порядка 1 mpps потянут только маршрутизирующие коммутаторы. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Dmitriy Sirant wrote: Кстати, тоже считаю что в домашних сетях pppoe более приемлем, т.к. нет нужды в поднятии маршрутизации на серых сетях - как следствие весь траффик идет через наш терминирующий сервер (ну кроме пользователей предела одного сегмента которые подключены в свитч и то если смогут договорится и поднять серые IP сами). Немаршрутизируемый протокол PPPoE приемлем только для абонентских окончаний DSL. В сетях с ним возникают проблемы, которые проявляются по мере роста. Большую сеть в любом случае придется разбивать на VLANы и маршрутизировать, чтобы урезать широковещательный трафик. И что тогда, в каждом сегменте устанавливать по серверу? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Покотиленко Костик пишет: \skip >>> Я объяснюсь, я не рекламирую это ПО, я говорю я >>> удобству такой конструкции. >> Удобству для кого? Для потребителя услуг, определенно, нет. > > Перечислите наиболее удобные для Вас способы авторизации в домашней > сети. В тех домосетях что я видел использовалось OpenVPN/pptp/pppoe Последнее уже вроде никто не использует. -- With Best Regards, Maxim Tyurin JID:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Покотиленко Костик 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 -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SOLVED] Ограничение ма ксимальной скорости п о IP
Покотиленко Костик wrote: - Добавляем только ещё один HTB класс со скоростью, например 1kbit/s - это для приземления превышения скорости. Логичнее дать каждому пользователю соразмерную минимально гарантированную (rate) и максимальную (ceil) ширину канала. (rate 64kbps ceil 128kbps, как вариант) Вопрос: есть ли дисциплина позволяющая ограничивать максимальную скорость до указанного значения для каждого 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. С уважением, Николай. -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
