Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: [FAQ] Ограничение скорости для клиентов на Ubuntu-Server (htb.init)  (Прочитано 321057 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн VA

  • Новичок
  • *
  • Сообщений: 32
  • Донецк
    • Просмотр профиля
Цитировать
Сейчас у меня все работает как описал VA, но нету шейпинга на eth1:1 Cry
Тогда +
iptables -t mangle -A OUTPUT  -d 192.168.10.100 -j MARK  --set-mark 10021
и два корневых класса eth0-2, eth0-3
для локального трафика 50 Мбит и для инета (сколько там у тебя) Мбит
« Последнее редактирование: 16 Декабря 2008, 02:16:17 от VA »

Оффлайн VA

  • Новичок
  • *
  • Сообщений: 32
  • Донецк
    • Просмотр профиля
Так что на счет авторизации то, знакома ли кому такая проблемка?
Поддерживаю вопрос.
VPN
PPPoE
IP+MAC
На порту оборудования
VLAN на абонента
Цитировать
В данном случае подойдет только "какой-нибудь eth0" который является внешним (уходящим в интернет) интерфейсом, и то не всегда подключение реализуется через ethernet. Так вот на этои внешнем интерфейсе можно со спокойной душой использовать HTB очереди лишь для исходящего трафика, тут же вопрос касается входящего трафика: локальные пользователи, если пускать их по VPN через PPTP, будут подключаться к шлюзу по ppp-интерфейсам.
iptables -t mangle -A FORWARD -i ppp0 -o ppp1 -j MARK --set-mark 1200
iptables -t mangle -A FORWARD -o ppp0 -i ppp1 -j MARK --set-mark 11200
ppp0 pppoe через eth0
ppp1 клиент через eth1
« Последнее редактирование: 16 Декабря 2008, 02:09:36 от VA »

Оффлайн cOnf_ua

  • Новичок
  • *
  • Сообщений: 47
    • Просмотр профиля
Да, чтобы шейпить входящий трафик в связке с PPTP: если подключать пользователей через PPTP, то будут создаваться многочисленные ppp-подключения. Задача в моем случае - шейпить весь канал поровну на всех, а для этого нужен один общий для всех пользователей интерфейс, на котором и будут создаваться HTB очереди. Вот здесь и приходит по моим рассуждениям на помощь IMQ, который будет раздавать интернет ppp-интерфейсам.
Так что на счет авторизации то, знакома ли кому такая проблемка?
Поддерживаю вопрос.
VPN
PPPoE
IP+MAC
На порту оборудования
VLAN на абонента
Цитировать
В данном случае подойдет только "какой-нибудь eth0" который является внешним (уходящим в интернет) интерфейсом, и то не всегда подключение реализуется через ethernet. Так вот на этои внешнем интерфейсе можно со спокойной душой использовать HTB очереди лишь для исходящего трафика, тут же вопрос касается входящего трафика: локальные пользователи, если пускать их по VPN через PPTP, будут подключаться к шлюзу по ppp-интерфейсам.
iptables -t mangle -A FORWARD -i ppp0 -o ppp1 -j MARK --set-mark 1200
iptables -t mangle -A FORWARD -o ppp0 -i ppp1 -j MARK --set-mark 11200
ppp0 pppoe через eth0
ppp1 клиент через eth1
Вы же как я понимаю предлагаете делить трафик пользователям статически - на каждый ppp своя очередь. А я бы хотел заполнять весь канал поровну вне зависимости от количества использующих его, для этого нужен один общий интерфейс. Если просто пускать людей по IP в интернет, то этим интерфейсом будет "какой-нибудь eth1", тут все просто, но я бы хотел прикрутить авторизацию. Надеюсь теперь прозрачно описал вопрос?
« Последнее редактирование: 16 Декабря 2008, 17:51:18 от cOnf_ua »

Оффлайн Stiff

  • Активист
  • *
  • Сообщений: 677
    • Просмотр профиля
Старгейзер умеет авторизацию через агент :)

Оффлайн cOnf_ua

  • Новичок
  • *
  • Сообщений: 47
    • Просмотр профиля
Старгейзер умеет авторизацию через агент :)

а подробней?

Оффлайн Stiff

  • Активист
  • *
  • Сообщений: 677
    • Просмотр профиля
http://stg.dp.ua/
в архиве с программой есть проробный мануал

Оффлайн xeon_greg

  • Активист
  • *
  • Сообщений: 981
    • Просмотр профиля
Привет всем! есть такой вопрос. в чем различие между такими описаниями правил в HTB.init , кроме того естественно , что они относятся к разным классам:
файл eth0-2:2.first один для нескольких
RATE=10Kbit
CEIL=1Mbit
LEAF=sfq
RULE=192.168.1.1
RULE=192.168.1.2
RULE=192.168.1.3
.......
и естественно для каждого eth0-2:2.first
.....
RULE=192.168.1.1
eth0-2:3.second
...
RULE=192.168.1.2
и тд
при всех отсальный настройках таких же, много всего читал понять тяжело что верно, согласно принципу работы sfq то трафик равномерно распределяется среди сессий tcp udp, так вот для того файла где все описано для нескольких ip этот принцип работает для равномерного распределения сессий каждого указанного IP или общего числа сессий всех указанных IP ?
общий вопрос кто может правильно объяснить разницу?   

Оффлайн чат

  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
ПОМОГИТЕ пожалуйста!!!!! поставил UBUNTU 8.10 на ноутбуке убив случайно всё. Теперь стоит только она. неделю сижу с проблемой подключения к интернету через md5 перепробывал почти всё даже сам прописывал в supplicant маршрут его действий несколькими способами.
Т.к. нету подключения к интернету не работает почти всё. Времени больше нет и желания с ней возится одному. Решил её убить и тоже не получается с загрузочного диска не грузится вылазит окно unetbootin, а ниже default внизу время 10 сек по истечению которых снова 10 сек
Подскажите как её убить и поставить Windows разбиратся времени больше нет а комп нужен срочно.
ЗАРАНИЕ СПАСИБО
vasyavasyavv@mail.ru-мой ящик

Byuik

  • Гость
ПОМОГИТЕ пожалуйста!!!!! поставил UBUNTU 8.10 на ноутбуке убив случайно всё. Теперь стоит только она. неделю сижу с проблемой подключения к интернету через md5 перепробывал почти всё даже сам прописывал в supplicant маршрут его действий несколькими способами.
Т.к. нету подключения к интернету не работает почти всё. Времени больше нет и желания с ней возится одному. Решил её убить и тоже не получается с загрузочного диска не грузится вылазит окно unetbootin, а ниже default внизу время 10 сек по истечению которых снова 10 сек
Подскажите как её убить и поставить Windows разбиратся времени больше нет а комп нужен срочно.
ЗАРАНИЕ СПАСИБО
vasyavasyavv@mail.ru-мой ящик
Вообщето месага писана не туда , ну а насчёт убить яб тебе посоветовал зделать FDISK из загрузочной дискеты WIN98 .

Оффлайн cOnf_ua

  • Новичок
  • *
  • Сообщений: 47
    • Просмотр профиля
Привет всем! есть такой вопрос. в чем различие между такими описаниями правил в HTB.init , кроме того естественно , что они относятся к разным классам:
файл eth0-2:2.first один для нескольких
RATE=10Kbit
CEIL=1Mbit
LEAF=sfq
RULE=192.168.1.1
RULE=192.168.1.2
RULE=192.168.1.3
.......
и естественно для каждого eth0-2:2.first
.....
RULE=192.168.1.1
eth0-2:3.second
...
RULE=192.168.1.2
и тд
при всех отсальный настройках таких же, много всего читал понять тяжело что верно, согласно принципу работы sfq то трафик равномерно распределяется среди сессий tcp udp, так вот для того файла где все описано для нескольких ip этот принцип работает для равномерного распределения сессий каждого указанного IP или общего числа сессий всех указанных IP ?
общий вопрос кто может правильно объяснить разницу?   

общего числа сессий всех указанных IP.

Оффлайн palladium

  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Вот часть моего шейпера (урезаная версия) показаны 3 подсети.

#!/bin/bash

shape="/sbin/tc"
iface='eth0'

#Тестовая версия


tc qdisc del dev $iface root handle 1: htb default 401
tc qdisc add dev $iface root handle 1: htb default 401

tc class add dev $iface parent 1:  classid 1:1   htb rate 100mbit quantum 65535
tc class add dev $iface parent 1:1 classid 1:401 htb rate 100mbit quantum 65535  prio 0

tc class add dev $iface parent 1:1 classid 1:a1 htb rate 100mbit quantum 65535 prio 1
tc class add dev $iface parent 1:1 classid 1:a2 htb rate 100mbit quantum 65535 prio 1
tc class add dev $iface parent 1:1 classid 1:a3 htb rate 100mbit quantum 65535 prio 1

#----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip dst 172.16.0.0/24  classid 1:a1
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip src 172.16.0.0/24  classid 1:a1
#----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip dst 172.16.10.0/24 classid 1:a2
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip src 172.16.10.0/24 classid 1:a2
#----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip dst 172.16.7.0/24  classid 1:a3
tc filter add dev $iface protocol all parent 1:0 prio 2 u32 match ip src 172.16.7.0/24  classid 1:a3
#----------------------------------------------------------------------------------------------------

tc qdisc add dev $iface parent 1:a1 handle b0:  htb
tc qdisc add dev $iface parent 1:a2 handle b10: htb
tc qdisc add dev $iface parent 1:a3 handle b7:  htb

tc class add dev $iface parent b0:  classid b0:1  htb rate 100mbit quantum 65535 prio 1
tc class add dev $iface parent b10: classid b10:1 htb rate 100mbit quantum 65535 prio 1
tc class add dev $iface parent b7:  classid b7:1  htb rate 100mbit quantum 65535 prio 1

#-----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent b0:  prio 1 u32 match ip dst 172.16.0.0/24  classid b0:1
tc filter add dev $iface protocol all parent b0:  prio 1 u32 match ip src 172.16.0.0/24  classid b0:1
#-----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent b10: prio 1 u32 match ip dst 172.16.10.0/24 classid b10:1
tc filter add dev $iface protocol all parent b10: prio 1 u32 match ip src 172.16.10.0/24 classid b10:1
#-----------------------------------------------------------------------------------------------------
tc filter add dev $iface protocol all parent b7:  prio 1 u32 match ip dst 172.16.7.0/24  classid b7:1
tc filter add dev $iface protocol all parent b7:  prio 1 u32 match ip src 172.16.7.0/24  classid b7:1
#-----------------------------------------------------------------------------------------------------


function shape {
    user_ip="172.16."${user_num}
    e=`echo ${user_num} | cut -f 2 -d "."`
    ee=`echo ${user_num} | cut -f 1 -d "."`
    user_num=${e}
    user_sub=${ee}

    tc class add dev $iface parent b${user_sub}:1 classid b${user_sub}:${user_num} htb rate "$user_speed"kbit quantum 65535  prio 1

    #Трафик в/из внутреннюю подсеть.
    tc filter add dev $iface protocol ip prio 1 parent 1:0 u32 match ip src 192.168.0.0/16 match ip dst $user_ip classid 1:401
    tc filter add dev $iface protocol ip prio 1 parent 1:0 u32 match ip dst 192.168.0.0/16 match ip src $user_ip classid 1:401

    #Транзитный трафик.
    tc filter add dev $iface protocol all prio 1 parent  b${user_sub}:1 u32 match ip dst $user_ip classid b${user_sub}:${user_num}
    tc filter add dev $iface protocol all prio 1 parent  b${user_sub}:1 u32 match ip src $user_ip classid b${user_sub}:${user_num}
          }


echo 7

user_cl_uniq=1

#test
user_num=7.20
user_speed=1000
shape

#test
user_num=10.20
user_speed=1000
shape

#test
user_num=0.20
user_speed=1000
shape


После его запуска в логах появляется это сообщение, что это может быть?

Mar 14 23:07:27  kernel: htb: class 100A1 isn't work conserving ?!
Mar 14 23:07:28  kernel: htb: class 100A6 isn't work conserving ?!
Mar 14 23:07:29  kernel: htb: class 100A4 isn't work conserving ?!

Оффлайн SergER

  • Новичок
  • *
  • Сообщений: 17
    • Просмотр профиля
Народ, подскажите плз... всплыла такая же проблема, как у Mixasik - есть 2 канала (2Mbit из сети 10.11.11.0 и 128kbit из остальных источников), которые приходят на один интерфейс eth1. в локалку смотрит интерфейс eth0, там есть два клиента, которые ходят в инет через нат. Сейчас htb нормально режет 128 kbit, а как сделать, чтобы независимо от этого 128к резался и 2-мегабитный канал? Никаких виртуальных интерфейсов нет.
Есть предположение, что на eth1 можно маркировать входящий 2-мегабитный трафик, а в htb на eth0 создать класс для исходящего маркированного трафика (MARK=101) и подклассы разбирающие его по клиентам (первый - RULE=192.168.100.1 и второй - RULE=192.168.100.2)
идея верна?

Оффлайн InkVisitor

  • Участник
  • *
  • Сообщений: 190
  • Nikopol, Ukraine
    • Просмотр профиля
Идея верна. Только в файлах правил надо пакеты отделять не по IP а по маркировке. Что-то типа такого
BURST=50Kb
RATE=4Mbit
CEIL=3Mbit
LEAF=sfq
PRIO=1
MARK=101

Оффлайн SergER

  • Новичок
  • *
  • Сообщений: 17
    • Просмотр профиля
А можно поподробнее? на интерфейс eth1 приходит пакет из сети 10.11.11.0, но кому из клиентов этот пакет предназначен - неизвестно, ибо клиенты за НАТом... пакет маркируется, а с интерфейса eth0 он сначала обрабатывается классом eth0-2:10
RATE=2Mbit
CEIL=2Mbit
LEAF=sfq
PRIO=1
MARK=101
а потом классами eth0-2:10:11
RATE=1Mbit
CEIL=2Mbit
LEAF=sfq
RULE=192.168.100.1
и eth0-2:10:12
RATE=1Mbit
CEIL=2Mbit
LEAF=sfq
RULE=192.168.100.2
по-моему, имена типа eth1-2:10:11 в htbinit допустимы и означают вложенные классы...
а для немаркированных пакетов работают классы eth0-2:21
RATE=60Kbit
CEIL=120Kbit
LEAF=sfq
RULE=192.168.100.1
и eth0-2:22
RATE=60Kbit
CEIL=120Kbit
LEAF=sfq
RULE=192.168.100.2


Пользователь решил продолжить мысль: 19 Марта 2009, 04:23:33
попробовал сделать так:
iptables -t nat -A POSTROUTING -s 192.168.100.1 -o eth1 -j SNAT --to-source 192.168.1.2

iptables -t mangle -A POSTROUTING -s 10.11.11.0/24 -j MARK --set-mark 11
iptables -t mangle -A POSTROUTING -j RETURN
и так
iptables -t nat -A POSTROUTING -s 192.168.100.1 -o eth1 -j SNAT --to-source 192.168.1.2

iptables -t mangle -A PREROUTING -s 10.11.11.0/24 -j MARK --set-mark 11
iptables -t mangle -A PREROUTING -j RETURN
при этом файлы htbinit у меня такие
eth0-3
# root class containing total bandwidth
RATE=1900Kbit
eth0-3:15
RATE=950Kbit
CEIL=1900Kbit
LEAF=sfq
PRIO=1
MARK=11
результат одинаково нулевой - и в первом и во втором случае скорость режется по старым правилам, до 128к. хотя я эти правила ради эксперимента вообще удалил... пакеты маркируются, вот вывод iptables -L -n -v -t mangle
root@gate:~# iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 3331 packets, 1739K bytes)
 pkts bytes target     prot opt in     out     source               destination
  763 1083K MARK       all  --  *      *       10.11.11.0/24        0.0.0.0/0           MARK set 0xb
 3329 1739K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 505 packets, 39402 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 2826 packets, 1700K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 491 packets, 202K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 3317 packets, 1902K bytes)
 pkts bytes target     prot opt in     out     source               destination
  656  937K MARK       all  --  *      *       10.11.11.0/24        0.0.0.0/0           MARK set 0xb
 1480 1030K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0


Кто может объяснить, в чем дело?
« Последнее редактирование: 19 Марта 2009, 04:23:33 от SergER »

Оффлайн Lion-Simba

  • Старожил
  • *
  • Сообщений: 1126
    • Просмотр профиля
Народ, подскажите плз... всплыла такая же проблема, как у Mixasik - есть 2 канала (2Mbit из сети 10.11.11.0 и 128kbit из остальных источников), которые приходят на один интерфейс eth1. в локалку смотрит интерфейс eth0, там есть два клиента, которые ходят в инет через нат. Сейчас htb нормально режет 128 kbit, а как сделать, чтобы независимо от этого 128к резался и 2-мегабитный канал? Никаких виртуальных интерфейсов нет.
Есть предположение, что на eth1 можно маркировать входящий 2-мегабитный трафик, а в htb на eth0 создать класс для исходящего маркированного трафика (MARK=101) и подклассы разбирающие его по клиентам (первый - RULE=192.168.100.1 и второй - RULE=192.168.100.2)
идея верна?
Так... я не пойму, зачем здесь нужна маркировка? Пакет, пришедший из eth1, когда он попадает на eth0, уже имеет вполне известный IP-адрес клиента, которому он предназначен. IP-адрес источника при этом не меняется. Что мешает использовать эти адреса для классификации трафика?

Скажем я бы сделал как-то так:

Файл eth0-2:10.all128kbit:
RATE=128Kbit

Файл eth0-2:10:100.Ivan:
RATE=64Kbit
CEIL=prate
LEAF=sfq
RULE=10.11.11.0/24,192.168.100.1

Файл eth0-2:10:200.Pavel:
RATE=64Kbit
CEIL=prate
LEAF=sfq
RULE=10.11.11.0/24,192.168.100.2

Файл eth0-2:20.all2mbit:
RATE=2Mbit

Файл eth0-2:20:300.Ivan:
RATE=1Mbit
CEIL=prate
LEAF=sfq
RULE=192.168.100.1

Файл eth0-2:20:400.Pavel:
RATE=1Mbit
CEIL=prate
LEAF=sfq
RULE=192.168.100.2
Оказываю индивидуальную платную техподдержку широкого профиля. Обращаться в ЛС или Jabber.

 

Страница сгенерирована за 0.022 секунд. Запросов: 21.