[G@riK]

При разбиении на сети /24 получаем 499 масок, при которых превышаем $cid_max (0хFFFF).

Да и фильтров опять таки получается слишком много.

 

UPD: убрал в скрипте проверку на превышение $cid_max, ибо точно знаю, что IP у нас меньше данного лимита. В итоге все фильтры успешно создались.

Изменено 10 февраля, 2012 пользователем G@riK

[G@riK]

Добрый день.

 

Столкнулись с проблемой синхронизации с БД.

Сеть 192.168.6.0/24

Добавляю IP 192.168.6.65

scin dbadd 192.168.6.65 20mibit

 

В БД появляется такая запись:

+------------+-------+
| ip         | rate  |
+------------+-------+
| 3232237121 | 20480 | 
+------------+-------+

 

А вот при попытке синхронизации выскакивает ошибка:

scin sync
Error: argument "invalid class ID" is wrong: 1:1f143

 

Я понимаю, что class_id очень большой, но почему он таким получился?

Изменено 13 февраля, 2012 пользователем G@riK

[photon]

У вас слишком много подсетей, советую все же подумать об изменении адресации. Алгоритм вычисления classid устроен так, что все IP в указанных подсетях нумеруются подряд, поэтому на каждом шейпере может быть не более 256 сетей /24.

Изменено 13 февраля, 2012 пользователем photon

[Zohan]

G@riK, ёжики еще колятся? То ли дело ipfw/dummynet :)

[kapa]

G@riK, ёжики еще колятся? То ли дело ipfw/dummynet :)

высурковскаяпропаганда :)

[G@riK]

У вас слишком много подсетей, советую все же подумать об изменении адресации. Алгоритм вычисления classid устроен так, что все IP в указанных подсетях нумеруются подряд, поэтому на каждом шейпере может быть не более 256 сетей /24.

Тогда такой вопрос: можно ли немного изменить логику?

Я точно знаю сколько у меня в маске занято адресов.

Впринципе можно попробовать передавать в параметрах network и filter_network сети в таком виде: 192.168.1.1/24/15, т.е. маска 24, в ней 15 айпи.

Далее уже set_class_nets делать смешение на количество IP в маске (+ небольшой запас), а не 256.

 

Точнее я попробовал, но видимо не учёл где еще нужно менять логику работы в связи с такими изменениями.

Потому сейчас у меня ошибка и фильтры не появляются:

RTNETLINK answers: Invalid argument
Command failed (null):3

Изменено 14 февраля, 2012 пользователем G@riK

[photon]

Тогда это создаст проблемы при добавлении новых IP. Придется каждый раз расширять этот диапазон. Кстати, я не совсем понимаю, почему нельзя просто раздать всем адреса из одной сети /16, если юзеров мало? У вас IP статически прописаны или раздаются через DHCP?

[G@riK]

У нас около 12тыс абонентов, часть со статикой, часть по DHCP.

Тогда это создаст проблемы при добавлении новых IP. Придется каждый раз расширять этот диапазон.

Ну потому я и написал, что можно задать небольшой запас (в 20-30 IP на сегмент). Этого хватит, если ночью, например, перезапускать скрипты, которые перегенерируют правила.

Изменено 14 февраля, 2012 пользователем G@riK

[Gunner]

tc = /sbin/tc
ipset = /sbin/ipset
out_if = eth0
in_if = eth1
filter_method = u32
limit_method = policing
debug = 0
verbose = 0
quiet = 0
colored = 1
network = 194.190.72.0/22 10.10.128.0/24 192.168.251.0/24 10.50.1.0/24
filter_network = 194.190.72.0/22 10.10.128.0/24 192.168.251.0/24 10.50.1.0/24
policer_burst_ratio = 0.1
quantum = 1500
rate_unit = kibit
rate_ratio = 1.0
leaf_qdisc = 'pfifo limit 50'
#set_name = pass
chain = FORWARD

root@billing:/etc/sc# uname -a

Linux billing 3.0.13-1myversionlinux #1 SMP Mon Feb 13 20:32:22 MAGT 2012 i686 i 686 i386 GNU/Linux

Проблема в следующем.

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

Режим полисинг - вот тут не нормально, торренты быстро раскачиваются, при забитом канале пинги в норме, странички и закачка с фтп в 1 поток очень медленно. Где копать ?

мой sysctl

net.ipv4.ip_forward=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.eth1.proxy_arp=1
#form atum
net.ipv4.netfilter.ip_conntrack_max = 1048576
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 21600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1

net.core.rmem_max = 1048576
net.core.wmem_max = 1048576
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.ipv4.tcp_rmem = 8192 16777216 32777216
net.ipv4.tcp_wmem = 8192 16777216 32777216
net.ipv4.route.max_size = 4194304
net.ipv4.route.secret_interval = 300
net.core.netdev_max_backlog = 4000
net.ipv4.tcp_congestion_control = bic

net.ipv4.neigh.default.gc_thresh1 = 8192
net.ipv4.neigh.default.gc_thresh2 = 16384
net.ipv4.neigh.default.gc_thresh3 = 16384

Все это на тестовой машине eth1 включен в неуправляемый свич в который включены 2 машины.

Ситуация идентична. При ограничении в 10мбит скорость закачки с локального фтп через шлюз

была около 30кбит. После команды sc reset скорость 100мбит.

Изменено 15 февраля, 2012 пользователем Gunner

[photon]

Полисинг неточно нарезает канал и требует настройки размера приемного буфера. В начале всегда наблюдается пик, а потом скорость стабилизируется. Если получаемые скорости слишком большие, нужно уменьшить параметр policer_burst_ratio (это соотношение между скоростью и размером буфера). Рекомендую использовать шейпинг, если есть такая возможность.

Изменено 15 февраля, 2012 пользователем photon

[photon]

У нас около 12тыс абонентов, часть со статикой, часть по DHCP.

Тогда это создаст проблемы при добавлении новых IP. Придется каждый раз расширять этот диапазон.

Ну потому я и написал, что можно задать небольшой запас (в 20-30 IP на сегмент). Этого хватит, если ночью, например, перезапускать скрипты, которые перегенерируют правила.

32 IP-адреса -- это маска /27.

[G@riK]

20-30 IP на сегмент - это запас.

Т.е. предположим у меня есть занятых 70 IP в маске /24. Я делаю запас 20-30, чтобы в случае появления новых абонентов за сегодня, для них были сгенерированы правила правильно. Ночью скрипт перезапустится и будет уже другое количество занятых IP + опять таки такой же запас.

[Inversiya]

Извиняюсь заранее! Тема может быть не совсем в тему, но не подскажете ли...

Есть сервер, (Виртуальный) у него есть два сетевых интерфейса eth0 eth1.

Пытаюсь настроить шейпер с помощью данного скрипта, но возникает следующая проблема:

1. Когда создаю мост между сетевыми интерфейсами (br0) работает вроде всё нормально.

2. Когда нет моста трафик не ходит между интерфейсами, и с включённым sc и без.

ip.net.forwarding включён

В iptables добавлял

$ iptables -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -j ACCEPT

$ iptables -A FORWARD -i eth1 -o eth0 -d 192.168.0.0/24 -j ACCEPT

$ iptables -P FORWARD DROP

и пытался так

$ iptables -A FORWARD -j ACCEPT

$ iptables -A FORWARD -d 192.168.0.0/24 -j ACCEPT

$ iptables -P FORWARD DROP

 

Не подскажете в чём может быть проблема?

 

PS Маны по iptables читал.

[photon]

Естественно, что трафик не ходит, если разрешено маршрутизировать только из подсети 192.168.0.0/24, присоединенной к одному из интерфейсов. Проще поставить -P FORWARD ACCEPT.

[Inversiya]

Так и надо чтобы только этот трафик ходил.

C -P FORWARD ACCEPT тоже ничего не получается

Изменено 2 марта, 2012 пользователем Inversiya

[kayot]

А как вы себе представляете маршрутизацию внутри одной подсети?

[photon]

Я не понимаю, зачем что-то дополнительно запрещать, тем более на тестовой машине, когда в скрипте по умолчанию блокируются все IP, кроме тех, для которых созданы правила шейпинга. Приведите вывод ifconfig и последовательность команд sc. Если это маршрутизатор, то интерфейсы должны принадлежать разным подсетям.

[Inversiya]

Объясню поподробнее. Есть некий сервер который, в данном случае, занимается ограничением скорости. У него две сетевухи, на них не должно быть ни каких ip адресов. Всякие наты и т.д. стоят отдельно. Соответственно пакеты приходящие на первый интерфейс (даже с отключенным sc) должны уходить на другой.

А sc в своё время должен ограничивать скорость.

Сейчас же: что включен, что выключен sc, пакеты не проходят! Начинают они ходить только когда интерфейсы объединены в мост. Тогда начинают работать и правила iptables и sc ограничивает скорость.

По поводу работы sc вопросов вообще нету, он работает нормально! Вопросы скорее про iptables.

Вот собственно вопрос, что я делаю не так?

[photon]

Вопрос скорее не в iptables, а в конфигурации вашей тестовой сети: интерфейсов маршрутизатора и таблиц маршрутизации на присоединенных к нему компьютерах. Поскольку вы не приводите эту информацию, то я ничего не могу сказать по этому поводу.

[Inversiya]

Сеть примерно выглядит так:

1 внутренняя сеть (есть белые и серые адреса)

2 несколько серверов (виртуальных внутри одного физического) включенных по цепочке

3 граничный маршрутизатор

4 интернет

 

сервер

--eth0|PPPoeE|eth1---eth0|Shaper|eth1---eth0|NetFlow|eth1---eth0|NAT|eth1--

там ещё несколько есть

 

Граничный маршрутизатор имеет несколько белых интерфейсов

 

Вот например Shaper и NetFlow не должны иметь ip адреса а прозрачно прокидывать пакеты.

Shaper должен только вносить задержки (ограничивать скорость)

NetFlow должен только смотреть что через него проходит

[photon]

Еще раз, я говорю не про реальную, а про тестовую сеть, которая собрана на виртуальных машинах. Какие адреса и маски назначены интерфейсам шейпера и существуют ли нужные маршруты в таблицах маршрутизации на машинах, присоединенных к нему? Если эти вещи настроены неправильно, то пакеты ходить не будут, и iptables тут ни при чем.

[Inversiya]

В том то и дело что ни каких ip адресов на шейпер не назначено!

Тестовая сеть

компьютер|eth0 11.22.33.44/24 (белый)---(нет ip) eth0|shaper|eth1 (нет ip)---11.22.33.1/24 eth0|Cisco|---- internet

шлюз на компе 11.22.33.1

 

Кстати говоря на шейпере должны быть прописаны какие нибудь маршруты (он без ip)? если да, то какого вида?

Изменено 3 марта, 2012 пользователем Inversiya

[kayot]

Так если вы хотите работать тупо на интерфейсах, да еще и без адресов - единственный вариант это бридж. А вот как шейпить на бридже - это отдельный вопрос.

Зачем там нужен бридж сложно понять, нормальные люди используют маршрутизацию.

[Inversiya]

Не охота чтобы серваки были видны из сети. по этому и ip не ставятся.

Я так понял что если я хочу без ip на интерфейсах то будет работать только через мост????

Если да, тогда вопрос как правильно настроить sc (по поводу in_if и out_if)??

При мосте (br0) я настраивал на интерфейсы eth. Правильно ли это?

[photon]

Не охота чтобы серваки были видны из сети. по этому и ip не ставятся.

Я так понял что если я хочу без ip на интерфейсах то будет работать только через мост????

Если да, тогда вопрос как правильно настроить sc (по поводу in_if и out_if)??

При мосте (br0) я настраивал на интерфейсы eth. Правильно ли это?

Главное -- правильно указать интерфейсы, чтобы в полях IP-адреса источника или назначения стояли адреса ваших клиентов. in_if -- интерфейс, смотрящий во внутреннюю сеть, на нем шейпится входящий трафик, интерфейс out_if должен смотреть во внешнюю. Есть ли у этих интерфейсов IP-адреса -- для шейпинга не имеет значения.