Jump to content
Калькуляторы

sc: скрипт для управления Linux-шейпером

Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат.

Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, in и out?

 

Что делать, если их больше, и они 802.1q vlan-ы,

ставить отдельный тазик на бордер с кваггой и отдельный на шейпер с этим скриптом?

Share this post


Link to post
Share on other sites

Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат.

Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, in и out?

 

Что делать, если их больше, и они 802.1q vlan-ы,

ставить отдельный тазик на бордер с кваггой и отдельный на шейпер с этим скриптом?

 

могу предложить вариант с использованием IMQ , когда создав два виртуальных интерфейса мы через iptables уже заворачиваем необходимый трафик дял шейпа в эти интерфейсы и всё будет резаться . Пример : вход (куча ppp+) , выход 1 - локалка 1Ж vlan1 , выход 2 (инет для ната) vlan2 , выход 3 (инет для реальников) vlan3 . sc настраиваем по умолчанию под shaper u32 in/out=IMQ(X) , потом уже в iptables вносим правила iptables -t mangle -I FORWARD -i ppp+ -o vlan2 -j IMQ --to-dev 0 и обратное iptables -t mangle -I FORWARD -i vlan2 -o ppp+ -j IMQ --to-dev 1 , такое же для vlan2 , а vlan1 будет к примеру гоняться без шейпера т.к локал , вобщем вариантов мносто милллион.

Share this post


Link to post
Share on other sites

могу предложить вариант с использованием IMQ , когда создав два виртуальных интерфейса мы через iptables уже заворачиваем необходимый трафик дял шейпа в эти интерфейсы и всё будет резаться . Пример : вход (куча ppp+) , выход 1 - локалка 1Ж vlan1 , выход 2 (инет для ната) vlan2 , выход 3 (инет для реальников) vlan3 . sc настраиваем по умолчанию под shaper u32 in/out=IMQ(X) , потом уже в iptables вносим правила iptables -t mangle -I FORWARD -i ppp+ -o vlan2 -j IMQ --to-dev 0 и обратное iptables -t mangle -I FORWARD -i vlan2 -o ppp+ -j IMQ --to-dev 1 , такое же для vlan2 , а vlan1 будет к примеру гоняться без шейпера т.к локал , вобщем вариантов мносто милллион.

 

так сейчас и сделано, с imq/iptables mangle mark/htb, но при объемах порядка 1.5гбит дуплекса

(большой класс - 700мегабит и десяток помельче),

шейпер начинает подтормаживать, растут задержки транзитного трафика,

снимаешь шейпер - все нормально, применением u32/ipset

мы значительно увеличим производительность?

Share this post


Link to post
Share on other sites

Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита.

 

применением u32/ipset мы значительно увеличим производительность?

Я никогда не пользовался iptables marks для классификации, поэтому не знаю. Очевидно, что хэш-фильтры u32 -- это наиболее быстрый метод классификации. В случае u32 ipset не нужен. Он имеет смысл только при использовании фильтра flow, т.к. в этом случае нельзя блокировать IP-адреса средствами tc, все пакеты так или иначе проходят через фильтр.

Edited by photon

Share this post


Link to post
Share on other sites

Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита.

 

Спасибо за совет, т.е. топология будет где-то такая

L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp)

 

Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7?

Share this post


Link to post
Share on other sites

Спасибо за совет, т.е. топология будет где-то такая

L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp)

 

Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7?

Теоретически, может вытянуть столько же, сколько способен маршрутизировать. Если есть желание, можно поэкспериментировать с сетевухами на 10 Гбит. Однако, больше двух гигабит мне видеть не приходилось. При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000.

Edited by photon

Share this post


Link to post
Share on other sites

не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример)

Share this post


Link to post
Share on other sites

не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример)

Патч есть на предыдущей странице. Если с помощью программы patch он не накладывается на последнюю версию, то надо в редакторе найти строки, которые начинаются с "-", и заменить на строки, начинающиеся с "+". Добавлять подсети тоже можно, если дописать код, чтобы в базе хранились еще и маски. Сейчас реализован шейпинг для отдельных IP-адресов.

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

С несколькими IP на один класс слишком много проблем возникает, поэтому я не стал реализовывать эту схему.

Share this post


Link to post
Share on other sites

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

Чтобы не подменялось, нужно в некоторых местах заменить $TC->("... replace ...") на $TC->("... add ...").

Share this post


Link to post
Share on other sites

Добрый день, поднят bridge на двух интерфейсах, запускаю sc-1.3.5, все нормально шейпится, но DHCP пакетики перестают проходить, подскажите пожалуйста, куда копнуть. Спасибо.

Share this post


Link to post
Share on other sites

Правило, блокирующее весь трафик, для которого не созданы фильтры, создается в строках 1348-1351 (файл sc).

       # block all other traffic
       $TC->(
               "filter add dev $dev parent 1:0 protocol ip pref $pref_default ".
               'u32 match u32 0 0 at 0 police mtu 1 action drop'
       );

Перед этим правилом нужно создать отдельный класс и фильтр, разрешающие прохождение DHCP-трафика (UDP, порты 67, 68). Формат пакетов описан здесь: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Technical_details

Потом, если будет время, напишу правила в явном виде.

Edited by photon

Share this post


Link to post
Share on other sites

Потом, если будет время, напишу правила в явном виде.

Если вас не затруднит...

Share this post


Link to post
Share on other sites

У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим?

Share this post


Link to post
Share on other sites

minderm, а какие ошибки при этом, у меня все прошло гладко.

Share this post


Link to post
Share on other sites

У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим?

Укажите правильный путь к исполняемому файлу tc. Я поменял его на дефолтный /sbin/tc, потому что в новых дистрибутивах tc уже достаточно новый и его не надо собирать из исходников.

Share this post


Link to post
Share on other sites

Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера?

Share this post


Link to post
Share on other sites

При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000.

 

Я бы сказал что порог приобретения для SCE 8000 начинается при 8-9 Гб/с потребления и то это достаточно больно ударяет по бюджету. А 2-3 Гб/с - это вообще-то еще объемы пионернетов, которым точно такое железо не по карману да и нет необходимости, потому что такой поток обрабатывается на паре тазиков, которые стоят вместе в 50-60 раз дешевле SCE 8000.

 

Рекламные слоганы манагеров Циско-продаванов просто убивают:

 

Решение SCE может позволить провайдерам услуг повысить свой доход на базе существующей инфраструктуры.

 

Так и хочется послать подальше с таким подходом.

 

Доход повышается напрямую и гарантированно только в двух случаях:

- рост абонентской базы (здесь SCE ни разу не поможет)

- ввод новых востребованных услуг (вопрос каких и при чем тут SCE?)

 

Есть еще один способ - рост тарифов, но покажите мне оператора, который на территории РФ поднимал тарифы стабильно и регулярно в течение последних 2-3 лет?

 

В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой.

Edited by replicant

Share this post


Link to post
Share on other sites

В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой.

Честно говоря, я тоже не являюсь сторонником такого подхода. Если есть возможность сделать open source-решение, которое работает не хуже и выполняет требуемые функции, то нет смысла тратить деньги на переоцененное железо. Иногда конторы ищут не сетевых инженеров, которые могут работать с чем угодно, а узких специалистов по Cisco. Такими проще управлять в силу большей взаимозаменяемости. Плюс к этому, фирменное оборудование -- это понты и предмет гордости.

Edited by photon

Share this post


Link to post
Share on other sites

Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера?

К этому все и идет, но часть клиентов осталось на старом DHCP сервере(IP+MAC) и его не перенести он на маршрутизаторе, а маршрутизатор в свою очередь был шейпером. Маршрутизатор мы избавляем от функции шейпера. DHCP(Option82) есть внутри сети. Вообщем свои сложности. Как бы временное решение, пока всех не перенесем на новый.

Edited by saff1000

Share this post


Link to post
Share on other sites

Если решение временное, то предлагаю применить следующий патч. Фильтровать DHCP-трафик по IP-адресам (0.0.0.0 или 255.255.255.255) в данном случае не стоит, т.к. это будет мешать работе скрипта с нормальными адресами.

 

--- a/sc        Mon Feb 04 13:17:45 2013 -0800
+++ b/sc        Mon Feb 04 13:54:23 2013 -0800
@@ -1344,6 +1344,13 @@
               }
       }

+       $TC->("class add dev $dev parent 1: classid 1:fffe htb rate 20Mbit ceil 100Mbit");
+       $TC->("qdisc add dev $dev parent 1:fffe handle fffe:0 pfifo limit 100");
+       $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ".
+         "match udp dst 68 0xffff match ip protocol 0x11 0xff flowid 1:fffe");
+       $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ".
+         "match udp dst 67 0xffff match ip protocol 0x11 0xff flowid 1:fffe");
+
       # block all other traffic
       $TC->(
               "filter add dev $dev parent 1:0 protocol ip pref $pref_default ".

Edited by photon

Share this post


Link to post
Share on other sites

photon, спасибо, все заработало. Еще один вопрос. Нужно ли при появлении новых IP в базе делать sc stop, sc start? Или можно обойтись sc sync.

Share this post


Link to post
Share on other sites

А если используется полисер, куда надо аналогичний кусок кода встатвить? И если не сложно черканите код, который будет аналогично маркированые в iptables пакеты пропускать без ограничений.

 

Если решение временное, то предлагаю применить следующий патч. Фильтровать DHCP-трафик по IP-адресам (0.0.0.0 или 255.255.255.255) в данном случае не стоит, т.к. это будет мешать работе скрипта с нормальными адресами.

 

--- a/sc        Mon Feb 04 13:17:45 2013 -0800
+++ b/sc        Mon Feb 04 13:54:23 2013 -0800
@@ -1344,6 +1344,13 @@
               }
       }

+       $TC->("class add dev $dev parent 1: classid 1:fffe htb rate 20Mbit ceil 100Mbit");
+       $TC->("qdisc add dev $dev parent 1:fffe handle fffe:0 pfifo limit 100");
+       $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ".
+         "match udp dst 68 0xffff match ip protocol 0x11 0xff flowid 1:fffe");
+       $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ".
+         "match udp dst 67 0xffff match ip protocol 0x11 0xff flowid 1:fffe");
+
       # block all other traffic
       $TC->(
               "filter add dev $dev parent 1:0 protocol ip pref $pref_default ".

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now