Перейти к содержимому
Калькуляторы

Идеи по поводу шейпера

Есть идея поставить между брасом (или ядром) и бордером, сервер в режиме моста, на котором шейпить и управлять доступом во внешнию сеть.

Заставить крутиться все это планирую под Linux.

 

Клиентские диапазоны подсетей (все сведения вымышленые):

Диапазон 1: 172.24.0.0/16 (тунельщики (pptp или pppoe) за NAT)

Диапазон 2: 91.114.0.0/19 (тунельщики с реальными IP)

Диапазон 3: 91.115.0.0/19 (клиенты со своими арендоваными реальными подсетями, т.е. маска от /30 до /25).

 

Классы обслуживания (в порядке убывания):

- Корпоратив VIP (крутые конторы, заводы и т.д.) 25% полосы гарантированно, 80% макс

- Корпоратив MIDDLE (все остальные) 20% полосы гарантированно, 80% макс

- Частный VIP (клиенты с предобплачиваемым трафиком) 25% полосы гарантированно, 80% макс

- Частный MIDDLE (клиенты на безлимах) 20% полосы гарантированно, 80% макс

- Частный LOW (клиенты на безлимах - безумные качальщики, с 1к открытых сессий и т.д.) 5% полосы гарантированно, 60% макс

 

Ориентировочная пропускная полоса: 500Мбит/сек

 

Если с ACL все достаточно просто и понятно: ipset + iptables, работает быстро и хорошо, то вот с шейпером не все так гладко.

 

Т.е. нужно создать 5 классов обслуживания? Это вроде бы классический случай и много раз описан в учебниках.

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

Задача усложнаяется тем, что любой из диапазонов IP, может быть включен в один из классов обслуживания.

 

Хочется услышать ваши мысли по этой идее, а так же возможные примеры и подсказки по реализации.

Изменено пользователем shicoy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Максимальную полосу для классов можно делать = внешнему каналу, зачем резать по 80% если всё равно это ceil и будет выдаваться только при простое полосы родительского класса.

И помимо rate, ещё нужно навернуть prio, так как весьма сильно влияет в реальной работе.

 

У вас получается нужно сделать 4 класса, безлимитчикам сделать ещё 2 подкласса внутри, normal и low priority. У нас я ещё разделил их на доп. подклассы внутри, main protocols и other (п2п как правило) их разрулил через prio чтобы при полке давился п2п трафик изначально и только потом основной(http итд).

 

На форуме есть примеры, ищите.

Изменено пользователем disappointed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ещё забыл, сам родительский класс подключённый к корневому на нём нужно оставить запас от полосы аплинка в 10%. Иначе вся система будет неэффективно работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пока сложность не в создании классов, а как красиво и без сильной потери производительности запихать трафик в эти классы.

 

для тунельщиков был бы хороший вариант с использованием ipset и tc flow, но он еще сырой в tc flow нет возможности указать из какого набора смотреть хэщи.

Изменено пользователем shicoy

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я так понял, что per-user шейпинг не нужен, и много клиентов будет плавать в каком-то одном классе. Тогда для классификации надо использовать хэширующие фильтры u32, а в качестве краевой дисциплины что-то для равномерного распределения полосы (например, SFQ или WRR). Вот подходящий пример: http://lartc.org/howto/lartc.adv-filter.hashing.html

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

производительнее u32 вариантов нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

производительнее u32 вариантов нет?

Более производительных вариантов классификации, чем u32 с hashing filters нет. Под такую задачу желательно взять двухсокетную материнку с хорошими интегрированными сетевухами (Intel или Broadcom).

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Каков смысл в двухсокетной? Все равно iptables сильно убивает SMP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Каков смысл в двухсокетной? Все равно iptables сильно убивает SMP.
Основную нагрузку будут создавать ksoftirqd, обрабатывающие нижние половины прерываний от сетевух. Вы еще скажите, что из-за iptables softirq перестают обрабатываться несколькими ядрами, и Linux превращается в тыкву 4.4BSD с кучей гигантских блокировок. К тому же, если не мудрить, то iptables на шейпирующем мосту должен использоваться по минимуму: два правила с -m set в цепочке FORWARD для пропускания трафика юзеров с положительным балансом. Более того, при наличии hashing filters можно вообще обойтись без iptables и ipset, блокируя должников с помощью filter actions:

tc filter change dev eth0 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip src 172.16.0.1 police mtu 1 drop
tc filter change dev eth1 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip dst 172.16.0.1 police mtu 1 drop

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У iptables действительно куча глобальных блокировок, с ними только в последних ядрах немного поборолись.

Вот пример, 2.6.31

9650.00 - 11.8% - 00000000f860813a : ipt_do_table [ip_tables]

7030.00 - 8.6% - 00000000c02b74ce : ip_route_input

4720.00 - 5.8% - 00000000c02fd06e : _spin_lock

4247.00 - 5.2% - 00000000f8301343 : e1000_clean_rx_irq [e1000]

3206.00 - 3.9% - 00000000f83028e9 : e1000_xmit_frame [e1000]

 

 

Есть еще такая штука cache coherency, и если вы пакет будете метать от процессора к процессору - обрабатываться он начнет на порядок медленнее.

И да, без multiqueue карт смысла в двухсокетных процах абсолютно нет.

Хороший Core i7 уделает большинство двухсокетных конфигураций более старых процессоров.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть еще такая штука cache coherency, и если вы пакет будете метать от процессора к процессору - обрабатываться он начнет на порядок медленнее.

И да, без multiqueue карт смысла в двухсокетных процах абсолютно нет.

Хороший Core i7 уделает большинство двухсокетных конфигураций более старых процессоров.

Так я и думал про двухсокетные 1366 с поддержкой Core i7 или новых Xeon'ов. Что-то типа этой: http://www.supermicro.com/products/motherb...500/X8DAL-i.cfm Потому что диапазоны IP-адресов достаточно большие, есть куда расти. Но скорее всего выгоднее будет увеличивать число недорогих односокетных машин.
Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.