shicoy Опубликовано 19 сентября, 2009 (изменено) · Жалоба Есть идея поставить между брасом (или ядром) и бордером, сервер в режиме моста, на котором шейпить и управлять доступом во внешнию сеть. Заставить крутиться все это планирую под 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, может быть включен в один из классов обслуживания. Хочется услышать ваши мысли по этой идее, а так же возможные примеры и подсказки по реализации. Изменено 19 сентября, 2009 пользователем shicoy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 19 сентября, 2009 (изменено) · Жалоба Максимальную полосу для классов можно делать = внешнему каналу, зачем резать по 80% если всё равно это ceil и будет выдаваться только при простое полосы родительского класса. И помимо rate, ещё нужно навернуть prio, так как весьма сильно влияет в реальной работе. У вас получается нужно сделать 4 класса, безлимитчикам сделать ещё 2 подкласса внутри, normal и low priority. У нас я ещё разделил их на доп. подклассы внутри, main protocols и other (п2п как правило) их разрулил через prio чтобы при полке давился п2п трафик изначально и только потом основной(http итд). На форуме есть примеры, ищите. Изменено 19 сентября, 2009 пользователем disappointed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 19 сентября, 2009 · Жалоба Ещё забыл, сам родительский класс подключённый к корневому на нём нужно оставить запас от полосы аплинка в 10%. Иначе вся система будет неэффективно работать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 19 сентября, 2009 (изменено) · Жалоба Пока сложность не в создании классов, а как красиво и без сильной потери производительности запихать трафик в эти классы. для тунельщиков был бы хороший вариант с использованием ipset и tc flow, но он еще сырой в tc flow нет возможности указать из какого набора смотреть хэщи. Изменено 19 сентября, 2009 пользователем shicoy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 19 сентября, 2009 (изменено) · Жалоба Я так понял, что per-user шейпинг не нужен, и много клиентов будет плавать в каком-то одном классе. Тогда для классификации надо использовать хэширующие фильтры u32, а в качестве краевой дисциплины что-то для равномерного распределения полосы (например, SFQ или WRR). Вот подходящий пример: http://lartc.org/howto/lartc.adv-filter.hashing.html Изменено 19 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 20 сентября, 2009 · Жалоба производительнее u32 вариантов нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 20 сентября, 2009 (изменено) · Жалоба производительнее u32 вариантов нет? Более производительных вариантов классификации, чем u32 с hashing filters нет. Под такую задачу желательно взять двухсокетную материнку с хорошими интегрированными сетевухами (Intel или Broadcom). Изменено 20 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 20 сентября, 2009 · Жалоба Каков смысл в двухсокетной? Все равно iptables сильно убивает SMP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 21 сентября, 2009 (изменено) · Жалоба Каков смысл в двухсокетной? Все равно 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 Изменено 21 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 21 сентября, 2009 · Жалоба У 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 уделает большинство двухсокетных конфигураций более старых процессоров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 21 сентября, 2009 (изменено) · Жалоба Есть еще такая штука cache coherency, и если вы пакет будете метать от процессора к процессору - обрабатываться он начнет на порядок медленнее.И да, без multiqueue карт смысла в двухсокетных процах абсолютно нет. Хороший Core i7 уделает большинство двухсокетных конфигураций более старых процессоров. Так я и думал про двухсокетные 1366 с поддержкой Core i7 или новых Xeon'ов. Что-то типа этой: http://www.supermicro.com/products/motherb...500/X8DAL-i.cfm Потому что диапазоны IP-адресов достаточно большие, есть куда расти. Но скорее всего выгоднее будет увеличивать число недорогих односокетных машин. Изменено 21 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...